Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

giovedì 28 maggio 2015

Nuova normativa europea sui cookie, in breve

Da qualche tempo ed in quasi ogni sito si vede spuntare la fatidica domanda "questo sito utilizza i cookie, acconsenti?". Proviamo a riepilogare, banalmente e con un linguaggio comprensibile a tutti (questo blog viene seguito da addetti ai lavori, ma anche da utenti comuni), di cosa si tratta.


Cosa sono i cookies in due parole?


I cookies sono delle informazioni che un sito memorizza all'interno del browser per ricordarsi di impostazioni e preferenze, ma non solo. Quando, ad esempio, accediamo a facebook cliccando su "ricorda login", le volte successive non inseriamo alcuna password. Questo perchè un cookie viene memorizzato nel nostro browser e, all'accesso successivo, viene richiamato dal sito per ricordarsi di noi.
Sto banalizzando, intendiamoci, ma indicativamente il cookie contiene informazioni che ci rendono riconoscibili.






Quindi? Perchè non dovrei accettarne l'utilizzo?


Perchè non tutti i cookie sono di natura tecnica. Alcuni cookie "traccianti" memorizzano informazioni che poi altri siti consultano per scopi pubblicitari. Se ora vado su un grande negozio online e cerco uno smartphone, mi ritroverò probabilmente per almeno una settimana la pubblicità mirata sempre su quello  stesso oggetto. Questo perchè il sito ha salvato un cookie contenente le mie preferenze (categorie ed oggetti consultati) ed altri siti nello stesso circuito pubblicitario vengono informati. Di conseguenza subirò una tartassante pubblicità riguardante quell'oggetto o quella categoria di oggetti. E' capitato a tutti.


Cosa è cambiato?


Una legge europea, cambiata svariate volte nel corso dell'ultimo quinquennio, stabilisce che l'utilizzatore venga esplicitamente informato sulle modalità con cui il sito stesso utilizza i dati raccolti. Tutto questo richiamando la Privacy Policy chiaramente visibile all'interno del sito e contenente anche le modalità di utilizzo dei cookie.
L'ultima variazione di questa legge prevede che l'utente debba accettare esplicitamente i cookie. Pena, multe da 6.000 fino a 120.000 euro per i rappresentati legali del sito web (in caso di omessa informativa e/o installazione dei cookie senza consenso).
Entro il 2 Giugno 2015, quindi, ogni sito deve chiedere esplicitamente l'autorizzazione all'utilizzo dei cookie. 

"Individuazione delle modalità semplificate per l'informativa e l'acquisizione del consenso per l'uso dei cookie” (Gazzetta Ufficiale n. 126 del 3 giugno 2014)


Solo pochi grandi brand hanno potuto strutturare una politica di accettazione davvero pienamente aderente alla normativa, in grado di consentire una scelta granulare.


E' una legge giusta?


A mio modesto avviso: no. Innanzitutto perchè i cookie sono fondamentali per la navigazione, quindi la maggior parte dei siti pone l'utente dinnanzi ad un out-out "se non accetti, esci". 
In secondo luogo perchè ogni messaggio ripetuto diventa inesorabilmente inutile, se ogni sito chiede di utilizzare i cookie e ti fa cliccare su "ok", alla fine diventa solo un'operazione in più, senza alcuna riflessione da parte dell'utente. Un pò come le escalation di permessi di Windows, quando ne chiedi troppi, l'utente tipico cliccherà sempre su OK, senza leggere di cosa si tratta ma solo per effetto della familiarità che genera il messaggio.
Terzo, non vi è grande distinzione tra i cookie lesivi della privacy e quelli tecnici, la legge (pur cercando di discernere) ha fatto, in realtà, di tutta un'erba un fascio. Ci sono cookies innocui e cookies estremamente lesivi della propria privacy, ma la difficoltà nel capire il sottile limite che li differenzia, ha spinto quasi tutti i gestori di siti web a generalizzare ed adottare una formula di tipo "o tutto o niente".
Quarto: da sempre i browser consentono di bloccare i cookies, un utente smaliziato poteva già intervenire in tal senso. E per l'utente medio non cambierà comunque nulla e cliccherà sempre su "accetta".
Sarebbe stato molto meglio che la richiesta esplicita fosse stata obbligatoria solo per i cookie traccianti e lesivi della privacy, escludendo completamente i cookie tecnici, ma anche quelli statistici senza profilazione. Solo allora un utente poteva giudizievolmente accettare o meno. Invece ora è costretto a cliccare sempre sull'autorizzazione, altrimenti i servizi sono negati, trasformando questa legge in un'inutile mossa con l'unico effetto di essere stata in grado di molestare centinaia e centianaia di milioni di utenti.


Plugin


Ci sono innumerevoli plugin per Joomla, WP e quant'altro. Io ne ho provati diversi ed ho deciso di utilizzare questo (per Joomla, gratuito). Non bisogna, tuttavia, dimenticarsi di inserire una Privacy Policy perfettamente compliant all'interno del proprio sito. Fatevi consigliare sempre da professionisti del settore. Se vi serve, ne conosco un paio davvero in gamba su questi argomenti.

martedì 12 maggio 2015

Raspberry PI, w1 Linux Raspian Kernel bug & Process Priority

Scenario

In alcune particolari condizioni, abbiamo avuto modo di verificare, io ed il mio collaboratore Senior Luca, dei Kernel Panic sollecitati dalla lettura del modulo 1wire.

Il kernel panic si verifica:

  • su kernel 3.18.9+, Raspian armv6l (non ho informazioni circa versioni differenti, più o meno recenti rispetto a questa)
  • solo su CPU mono core (quindi RaspBerry Pi 1 e non RaspBerry Pi 2)
  • quando istruzioni pygame sono in esecuzione
  • quando si verifica un overload della CPU (tuttavia questo non è estremamente rilevante)
  • quando il numero di processi python aumenta
  • a prescindere dalle sonde (ne abbiamo cambiate 10 e abbiamo cambiato 5 raspberry, riproducendo il problema anche con hardware completamente differente)

Cosa Accade

Inizialmente una serie di letture delle sonde w1 danno errori di CRC:


May 11 20:11:16 AS15C3101B kernel: [  392.757953] w1_slave_driver 28-000005a01d7f: Read failed CRC check
May 11 20:11:43 AS15C3101B kernel: [  419.917527] w1_slave_driver 28-00000696eb99: Read failed CRC check
May 11 20:12:30 AS15C3101B kernel: [  466.413438] w1_slave_driver 28-00000696eb99: Read failed CRC check
May 11 20:12:44 AS15C3101B kernel: [  480.799177] w1_slave_driver 28-0000054ebd49: Read failed CRC check
May 11 20:12:50 AS15C3101B kernel: [  486.936962] w1_slave_driver 28-000005a01d7f: Read failed CRC check
May 11 20:13:06 AS15C3101B kernel: [  502.939939] w1_slave_driver 28-0000054ebd49: Read failed CRC check
May 11 20:13:14 AS15C3101B kernel: [  510.917800] w1_slave_driver 28-000005a01d7f: Read failed CRC check
May 11 20:13:28 AS15C3101B kernel: [  524.425806] w1_slave_driver 28-0000054ebd49: Read failed CRC check
May 11 20:13:36 AS15C3101B kernel: [  532.149026] w1_slave_driver 28-000005a01d7f: Read failed CRC check
May 11 20:13:51 AS15C3101B kernel: [  547.247455] w1_slave_driver 28-0000054ebd49: Read failed CRC check
May 11 20:22:55 AS15C3101B kernel: [  394.467714] w1_slave_driver 28-0000054e5d76: Read failed CRC check
May 11 20:23:35 AS15C3101B kernel: [  433.749331] w1_slave_driver 28-00000696eb99: Read failed CRC check
May 11 20:23:49 AS15C3101B kernel: [  448.129373] w1_slave_driver 28-0000054e5d76: Read failed CRC check
May 11 20:23:59 AS15C3101B kernel: [  457.658434] w1_slave_driver 28-00000696eb99: Read failed CRC check
May 11 20:24:55 AS15C3101B kernel: [  513.698751] w1_slave_driver 28-000005a137c6: Read failed CRC check
May 11 20:27:48 AS15C3101B kernel: [  687.187439] w1_slave_driver 28-000005a137c6: Read failed CRC check
May 11 20:28:02 AS15C3101B kernel: [  701.376795] w1_slave_driver 28-000005a137c6: Read failed CRC check
May 11 20:33:18 AS15C3101B kernel: [ 1017.072088] w1_slave_driver 28-00000696eb99: Read failed CRC check



Successivamente tendono persino a scomparire per poi ricomparire a breve e, per finire, il kernel va in panic dando messaggi di errore anche in broadcast. 

Message from syslogd@AS15C1302B at May 11 20:39:56  ...
 kernel:[ 2614.966264] 5f00: 5550f5f9 37b02fc0 00001a62 dcef5f78 dcef5f3c dba05320 01825000 dcef4000
Message from syslogd@AS15C1302B at May 11 20:39:56 ...
 kernel:[ 2614.966286] 5f20: dcef5f78 00008000 01825000 00000000 dcef5f74 dcef5f40 c0137e6c c01a9a38
Segmentation fault


Nei /var/log/messages non c'è molto, a dire il vero:


May 11 20:34:56 AS15C3101B kernel: [ 1115.363581] Modules linked in: i2c_dev stmpe_ts snd_bcm2835 snd_pcm snd_seq snd_seq_device snd_timer snd evdev uinput fb_ili9340(C) fbtft(C) syscopyarea sysfillrect sysimgblt fb_sys_fops spi_bcm2708 i2c_bcm2708 8192cu w1_therm lirc_rpi(C) w1_gpio wire lirc_dev cn rc_core uio_pdrv_genirq uio
May 11 20:34:56 AS15C3101B kernel: [ 1115.363724] CPU: 0 PID: 24237 Comm: cat Tainted: G         C     3.18.9+ #768
May 11 20:34:56 AS15C3101B kernel: [ 1115.363742] task: dbb0b600 ti: daf0e000 task.ti: daf0e000
May 11 20:34:56 AS15C3101B kernel: [ 1115.363778] PC is at w1_slave_show+0x2d8/0x398 [w1_therm]
May 11 20:34:56 AS15C3101B kernel: [ 1115.363804] LR is at vsnprintf+0x27c/0x3e0
May 11 20:34:56 AS15C3101B kernel: [ 1115.363820] pc : [<bf04336c>]    lr : [<c02fb36c>]    psr: 20000113
May 11 20:34:56 AS15C3101B kernel: [ 1115.363820] sp : daf0fe08  ip : bf0435c0  fp : daf0fe54
May 11 20:34:56 AS15C3101B kernel: [ 1115.363840] r10: 0000001f  r9 : daf0fe27  r8 : daf0fe27
May 11 20:34:56 AS15C3101B kernel: [ 1115.363854] r7 : dcf70a50  r6 : dcfb8000  r5 : 00000fe5  r4 : 00000000
May 11 20:34:56 AS15C3101B kernel: [ 1115.363867] r3 : 00000000  r2 : 1002ff7f  r1 : 464b01de  r0 : 0000000d
May 11 20:34:56 AS15C3101B kernel: [ 1115.363882] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
May 11 20:34:56 AS15C3101B kernel: [ 1115.363896] Control: 00c5387d  Table: 1ad54008  DAC: 00000015
May 11 20:34:56 AS15C3101B kernel: [ 1115.364356] [<bf04336c>] (w1_slave_show [w1_therm]) from [<c0361650>] (dev_attr_show+0x2c/0x58)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364394] [<c0361650>] (dev_attr_show) from [<c01aa838>] (sysfs_kf_seq_show+0x9c/0x104)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364424] [<c01aa838>] (sysfs_kf_seq_show) from [<c01a9168>] (kernfs_seq_show+0x34/0x38)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364452] [<c01a9168>] (kernfs_seq_show) from [<c015c310>] (seq_read+0x1b8/0x488)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364481] [<c015c310>] (seq_read) from [<c01a9b50>] (kernfs_fop_read+0x124/0x16c)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364511] [<c01a9b50>] (kernfs_fop_read) from [<c0137e6c>] (vfs_read+0x98/0x188)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364538] [<c0137e6c>] (vfs_read) from [<c0138580>] (SyS_read+0x4c/0xa0)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364573] [<c0138580>] (SyS_read) from [<c000e800>] (ret_fast_syscall+0x0/0x48)
May 11 20:34:56 AS15C3101B kernel: [ 1115.364679] ---[ end trace d47c3c19eebad7da ]---

Da questo momento in poi qualsiasi interrogazione sulle sonde w1 rimarrà in hang e bloccherà la shell o qualsiasi script che richiami questa informazione. Anche un semplice cat del valore di w1_slave.

rmmod e modprobe dei moduli w1 rimarranno in hang esattamente come tutto ciò che riguarda anche il modulo w1_thermal w1_slave e w1_bus.


Scatenare l'errore

Più interrogazioni si fanno sulle sonde w1, più avremo probabilità di scatenare il Kernel Panic.

Un modo efficace per mandare in hang il sistema può essere questo:

(bash)# while [ true ]; do cat /sys/bus/w1/devices/28-*/w1_slave; sleep 1; done

Se il sistema è affetto dal problema, nel giro di 60 minuti diventerà instabile.


Ipotesi

Una delle ipotesi che abbiamo formulato si basa sull'assenza di clock hardware nel Raspberry. Tale mancanza, emulata a livello software tramite timer interrupt, potrebbe produrre (in determinate e rare circostanze di carico e utilizzo di risorse) una dilatazione del clock, causando difficoltà nella gestione dell'hardware comunicante in half-duplex (che quindi utilizza dei timing precisi) come quello w1.

E' solo un'ipotesi, ma nel paragrafo successivo vedremo come lavorando sui nice del processore si producano dei miglioramenti.


Soluzioni (più o meno artigianali)

Intendiamoci, può accadere qualsiasi cosa, ma un Kernel deve gestire questo tipo di problema. Il fatto che si pianti (non del tutto, perchè riusciamo ancora a riavviare mediante un reset di tipo echo 1 > /proc/sys/kernel/sysrq ), non è comunque normale. Di fatto tutta la parte w1 entra irrimediabilmente in hang fino al riavvio del sistema.

Perdendoci la testa, correlando l'errore non presente sui sistemi multicore e seguendo la traccia dell'ottimizzazione dell'utilizzo della singola risorsa CPU, ci siamo accorti di una cosa:

# ps -lfax | grep w1_bus_master
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
1     0      247     2    20   0        0        0     w1_pro           S    ?              0:17   \_ [w1_bus_master1]

# nice
0

(Per chi non lo sapesse, nice è il comando linux in grado di forzare una priorità di CPU durante l'esecuzione di un processo. Renice è il suo omonimo in grado di cambiarla ad un processo esistente.)

Nonostante il nice di default fosse 0, w1_bus_master veniva eseguito con nice 20. In situazioni di high-cpu-load, quindi, un processo "tradizionale" parrebbe essere eseguito con una priorità maggiore di un processo di sistema così delicato.

Tanto per iniziare, quindi, abbiamo dato una priorità di utilizzo CPU a -20 (il massimo impostabile "tradizionalmente"):

# renice -n -20 $( ps -aux | grep w1_bus_master | grep -v "grep" | sed -n 1p | awk '{ print $2 }' );

Successivamente abbiamo trovato una profonda correlazione scatenante con l'esecuzione di uno script python contenente librerie pygame. Abbiamo, quindi, startato lo script con nice -n 39 python script.py

Questi due accorgimenti, insieme ad un'ottimizzazione dello script python e al numero di processi che esso generava, sono bastati a ridurre drasticamente i kernel panic e gli errori CRC in lettura del bus w1. Ad ora, dopo quasi 4.000 interrogazioni, non ho avuto nemmeno un CRC error e, ovviamente, di conseguenza nessun Kernel Panic o Kernel Mod Hang. 
Senza gli accorgimenti di cui sopra, ricevevo circa il 20% di errori CRC, prima di causare (prima o poi) un prevedibile crash del Kernel e del suo modulo di gestione w1.

lunedì 4 maggio 2015

Active Directory Domain Services: Domini, Siti, Alberi e Foreste pur non avendo il pollice verde

Come visto nel precedente articolo, Active Directory è diventata una suite di più servizi di cui il ruolo regina rimane AD DS, ovvero Active Directory Domain Services.

AD DS è in grado di raccogliere account, computer, stampanti, gruppi, etc. e di racchiuderli all'interno di un dominio Active Directory.


Domini, UO e Gruppi

Immaginiamo di avere un'azienda con 20 postazioni e di volerne centralizzare la gestione, l'autenticazione e l'attribuzione di permessi di sicurezza. AD è lo strumento principe in ambienti Microsoft ed il contesto entro il quale racchiuderemo i nostri oggetti viene definito Dominio.

All'interno del Dominio AD possiamo creare delle "Unità Organizzative" (con oggetti coerenti tra di loro) che condividono Group Policy, ovvero gruppi di regole prestabilite. A loro volta possiamo scendere ulteriormente nel dettaglio creando dei gruppi di distribuzione all'interno dell'Unità Organizzativa o del dominio madre.


Questa è una tipica e classica infrastruttura AD DS monodominio, dove le risorse all'interno dell'azienda sono sufficientemente contenute da essere racchiuse entro i limiti logici di un singolo dominio.

Questo, ovviamente, prescinde dallo strato hardware e da quanti Domain Controller avremo.


Siti

Mediante l'introduzione di una politica di Sito, è possibile stabilire che un gruppo di utenti debba autenticarsi su un Domain Controller ed un altro gruppo su un altro, pur rimanendo all'interno dello stesso dominio. Normalmente i Siti sono WAN differenti le cui connessioni non sono affidabili e performanti come quelle di LAN.
Si tratta di una soluzione comoda e relativamente rapida per aziende multisede. I vantaggi sono evidenti: sopravvivenza in caso di problemi di connessione e contenimento del traffico geografico.




Alberi e Foreste

I Domini possono avere "profondità" a piacimento e concettualmente possiamo vederli come dei rami di un albero. Facciamo finta di non aver creato i Siti e, per necessità organizzative, sentire l'esigenza di creare uno o più altri sotto-domini chiamati a loro volta bari.azienda.loc e milano.azienda.loc. A sua volta su milano.azienda.loc potrei voler creare spinoff.milano.azienda.loc.

Ho creato un albero di domini, ognuno con le proprie risorse.

Qualora io decida di creare un nuovo dominio chiamato azienda2.loc ed abbia deciso di creare una relazione di "Trust" tra i due domini, ho creato sostanzialmente una foresta.


Intendiamoci, sono situazioni abbastanza limitate, probabilmente una multinazionale sentirà l'esigenza di strutturare una foresta, ma difficilmente ci troveremo a dover andare oltre il concetto di albero. Nella maggior parte delle installazioni contenute, una gestione accurata di Unità organizzative e Siti risulta più che sufficiente.

Quando utilizzare i siti e le foreste? Bella domanda, probabilmente uno dei motivi principali che ci spinge a creare più domini è l'assegnazione di amministratori di dominio in grado di far tutto, ma entro i limiti del proprio dominio. Ovviamente diversi dagli amministratori dell'intera foresta. Possiamo semplificare dicendo che due domini possono essere amministrati singolarmente da due amministratori e da un terzo (gerarchicamente più importante) in grado di amministrarli entrambi. Ed è già un buon motivo per creare due domini o sottodomini separati.

Ok, anche le Unità Organizzative possono avere amministratori diversi. Ma questa è un'altra storia...


Relazioni di Trust (o di fiducia) tra Domini

Il trust è automatico, bidirezionale e transitivo tra più domini della stessa foresta. Gli Enterprise Admin e gli Schema Admin potranno modificare tutto di tutti, gli amministratori di dominio, invece, solo il singolo dominio.

Per transitivo si intende l'estensione del concetto di fiducia a tutti i domini di cui il dominio in trust si fida. Se A si fida di B, che a sua volta si fida di C, A si fida automaticamente di C.

Viene definito Trusting Domain quello che contiene le risorse (immaginiamo ad un account e le sue relative credenziali) e il Trusted Domain quello che le richiama.


Cataloghi Globali

I server che detengono il ruolo di Catalogo Globale sono adibiti a facilitatori per le query extradominio. Se sono un utente alla ricerca di una stampante in un dominio diverso dal mio (ma all'interno di una foresta ove vige una relazione di Trust), posso contattare N server alla ricerca della stampante oppure posso contattare un Catalogo Globale che detiene l'indice di tutti gli oggetti di tutti i domini, facilitandomi e velocizzandomi il lavoro.
Ovviamente i Cataloghi Globali non hanno senso qualora io abbia un unico Dominio AD.



Conclusioni

I Servizi di Dominio Active Directory possono facilitare la gestione di reti molto semplici o molto complesse. E' bene trovare il giusto equilibrio, altrimenti invece di semplificare le cose, le renderemo più complicate. 
Morale della favola: se ho 20 macchine in un'unica sede, semplificherò la gestione creando un singolo dominio e magari più Unità Organizzative. Al tempo stesso se ho 30 sedi con EDP locali, semplificherò la mia gestione creando 30 sottodomini e strutturando magari una foresta. 
Ma se ho 20 macchine e creo una foresta con 15 domini, probabilmente ho molto tempo libero e sono consapevole che la gestione diventerà facilmente un incubo. Ad ognuno, il suo.
AD DS si presta ad essere inserito in ogni realtà, dal microbusiness all'enterprise. E' sufficiente utilizzare gli strumenti giusti contestualizzandoli alle dimensioni e alle architetture in essere.
Sembra banale? Eppure è pieno di aziende con un solo dominio pur avendo 300 macchine con IT dipartimentali.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

L'evoluzione di Active Directory

Per chi ha avuto di interfacciarsi con Microsoft Active Directory a partire da Windows 2000 Server in poi, diventa spesso innaturale comprendere cosa è diventato AD oggi (ovvero una suite di componenti estremamente vasta che amplia il concetto originario di Dominio).
Ma andiamo con ordine.

In principio...

In principio Active Directory era identificato principalmente con il servizio di gestione dominio. Consentiva, difatti, di raggruppare oggetti (principalmente utenti, gruppi e computer) sotto un unico "cappello" denominato Dominio AD.

Nel 2000 esisteva un Domain Controller primario ed uno di backup che replicava. La differenza maggiore con l'introduzione di Windows Server 2003 consisteva nell'architettura "multimaster" in grado di rendere tutti i Domain Controller paritetici.

Da Windows Server 2008 vediamo sempre più strutturate le Group Policy (non che prima non lo fossero, ma da qui in poi le possibilità si ampliano esponenzialmente, anche grazie a Windows Vista e 7) e inizia a prendere forma la Suite AD come la conosciamo attualmente.


Lo stato dell'arte

Oggi, da Windows Server 2012 in poi, Active Directory è diventato una suite vera e propria che include staticamente 5 fondamentali strumenti che, seppur separati tra di loro, compongono i ruoli AD.




Servizi di Dominio (AD DS)

Si tratta di tutto il sistema di directory e gestione utenti, computer e dispositivi. Ovvero Active Directory esattamente come lo conoscevamo prima.

Nel prossimo articolo parleremo meglio di AD DS, di dove salva i file di schema, dei Cataloghi Globali e di Domini, Siti, Alberi e Foreste. E no, se ve lo state chiedendo, non mi è venuto il pollice verde.


Servizi di Federazione (AD FS)

Consente l’accesso alle risorse esterne mediante meccanismi di autenticazione ibridi. Non aggiunge nulla ad AD DS, ma consente di ampliare l'autenticazione e l'accesso alle risorse oltre i confini del proprio dominio AD.

Gli scenari sono tipicamente dei trust monodirezionali B2B oppure B2U.

La federation Trust è la possibilità di un’organizzazione di fidarsi di un’altra utilizzando, ad esempio, componenti autenticativi.


Servizi di Certificati (AD CS) 

Tutta la gestione delle chiavi, dei certificati e della relativa creazione e revoca. Sostanzialmente AD CS crea una Certification Authority attendibile per il dominio stesso (pur gestendo certificati di terze parti pubblicamente riconosciuti, ad esempio da utilizzarsi su webserver).

Sono molti i servizi che possono utilizzare un certificato interno (seppur self-signed). Servizi di Load Balancing, HA, autenticazione degli utenti, etc...

Il sistema AD CS supporta, inoltre, un meccanismo di enrollment (o reclutamento, in italiano) in grado di generare un certificato al primo accesso.


Lightweight Directory (AD LDS)

AD LDS è un archivio vuoto simil AD DS, con accesso LDAP, ma senza le restrizioni dello schema AD normale. Tipicamente viene utilizzato per non "sporcare" lo schema AD DS, pur utilizzandolo per altre applicazioni.


Supporta Istanze Multiple, ed ogni istanza contiene 3 partizioni: Schema, Configurazione e Applicazione.

Le porte predefinite 389 e 636 possono essere cambiate in fase di configurazione. Se il server è anche un controller di dominio, lui proporrà porte libere, ovvero 50000 e 50001.

Possiede una serie di tools:
Wizard > crea nuove istanze e nuove repliche

ADSIEdit > visualizza e modifica i dati
LDP > come sopra + creazione istanze applicative
Ldifde e Csvde > importa/esporta dati
Dsacls > setta i permessi
AdamSync > sincronizza delle istanze ADDS con ADLSD
ADSchemaAnalyzer > usato nella migrazione dello schema AD in ADAM


Gestione Diritti (AD RMS)

A mio avviso uno dei servizi più interessanti, dopo l'immancabile AD DS, ovviamente. Gestisce la sicurezza del dato (utilizzandolo con un software compatibile), estendendone i permessi anche al di fuori del perimetro o del dominio aziendale.

Facciamo qualche esempio:

Word/Excel/PowerPoint: posso impostare un permesso di lettura e di scrittura anche per singolo destinatario ed anche vincolato da un periodo di validità (oltre il quale il file diventa non più utilizzabile). Posso impedire la stampa pur consentendone la visualizzazione a video, ad esempio.

Outlook: Posso impostare il blocco dell'inoltro dell'email o, come sopra, impedirne la stampa ma non la visualizzazione a video.

E così via per Explorer e indicativamente tutti i software Microsoft RMS compatibili.



Affinchè il servizio RMS funzioni correttamente, un server RMS deve essere pubblicato. L'applicativo dell'utente destinatario che aprirà il file riconoscerà la crittografia mediante servizio RMS e saprà, quindi, a quale server pubblico rivolgersi per ricevere i permessi riguardanti le operazioni consentite.





sabato 18 aprile 2015

Il Deep Web spiegato a mia nonna

Era un po' che avevo voglia di scrivere due righe su questo argomento e di recente le mie letture hanno risvegliato l'esigenza di spiegare, con parole povere, cos'è il Deep Web (o web profondo, darkweb, web oscuro, etc.). Per lavoro, occupandomi di sicurezza informatica, sono portato a conoscere alcuni argomenti come questo. Almeno in minima parte e seppur non condividendo, da ferreo sostenitore della legalità anche in un mondo pseudoanarchico come quello informatico, la maggior parte dei contenuti che vi è possibile trovare all'interno.

Molto spesso anche i più informati ignorano cosa ci sia dietro e quanto sia pericolosa quella zona dove tutto è concesso e, man mano che ci si spinge oltre, tutto è illegale. Non è inusuale parlare di sicurezza informatica e vedere facce stupite quando si affrontano le tematiche relative al mercato nero della compravendita di server o computer compromessi. La domanda che sorge spesso spontanea è "si, ok, ma dove avviene?".



Percezione comune

Nell'immaginario comune il web è a dir poco sterminato. E' sufficiente cercare qualsiasi cosa con google per rendersi conto dei milioni di risultati che questo comporta. Ora immaginate per un attimo che (da una recente statistica) google e tutti i motori di ricerca riescano a raccogliere appena il 4% dei siti (l'immagine sotto è decisamente ottimistica).




Immaginate, ora, che una parte di server web sia stata volontariamente fatta rimanere all'oscuro e nell'anonimato. E immaginate quanto questo sia in contrasto con ciò che vediamo quotidianamente: profilazione, pubblicità mirata, informazioni riservate nelle mani di grandi gruppi (facebook e google, per dirne una).


Il Deep Web: strati e profondità

Molto spesso il deep web viene considerato come un oceano o, meglio, come un iceberg. Ciò che sbuca è il visibile e, man mano che ci si addentra in profondità, l'ambiente diventa sempre più ostile, sempre più opaco.


Diamo una misura al nostro iceberg, diciamo 3000mt. di profondità.


In superficie c'è Google, c'è Facebook, Twitter, il sito di ricette di cucina e quello dell'azienda di commercio online. Tutto ciò che è classificabile con un motore di ricerca è lì, per essere consultato. Anzi, si spendono un mucchio di soldi per ottimizzare il proprio sito affinchè compaia in alto nelle ricerche di google.

Poi c'è un limbo subito sotto la superficie, diciamo 100 mt sotto. In questo limbo molti accedono, ma senza alcuna precauzione. Si scaricano torrent, video coperti da copyright e ci si vede la partita in streaming. Lo si fa più che altro perchè ci si ritrova per necessità e perchè si è trovato il link giusto. Sempre da google (tenete a mente questo particolare, non è da poco). I più smanettoni si fermano qui pensando che questo sia il "dark web". Bhè, probabilmente non siamo arrivati nemmeno al 10%.



Continuiamo il nostro viaggio, scendiamo a 500 mt. Ora non possiamo più andare in apnea. Abbiamo bisogno di un'attrezzatura adeguata, la vita è pericolosa a queste profondità. La nostra attrezzatura si chiama Tor. Tor è un sistema di anonimizzazione, il più famoso, in grado di far rimbalzare la nostra connessione su svariati nodi, facendone perdere le tracce. Ad oggi, pare che quasi metà della rete Tor sia stata compromessa dall'NSA, ma non vi è certezza. Rimane, comunque, un metodo rapido e veloce per diventare anonimi.


Da questo momento in poi, i motori di ricerca convenzionali non riescono più a catalogare nulla e chi si trova qui, del resto, non vuole essere catalogato, se non da motori di ricerca specialistici. Per cercare qualcosa, bisogna andare su Grams (il nome, letteralmente "grammi", la dice lunga sulla tipologia di richiesta in cui il motore di ricerca è specializzato),  Torch e motori "particolari", in cui si entra solo se il proprietario del sito lo ha voluto. Motori, tra l'altro, che hanno politiche molto diverse sulla raccolta delle informazioni degli utenti. Qui ognuno tende a farsi i fatti suoi.

Da qui in poi, inoltre, il web diventa scarno, le immagini rarefatte. Sembra di essere tornati indietro di un decennio. C'è un motivo: l'anonimato comporta una serie di rimbalzi che abbassano di molto la banda a disposizione. Se un'immagine non serve, non va messa. Qui non si punta all'estetica, ma alla sostanza.

Ovviamente, da qui in poi, scordatevi tutti i vincoli legali che ha il web tradizionale. Sito collegato alla persona fisica o giuridica, leggi che regolamentano il commercio online, tracciabilità finanziaria.. roba da farsi una risata. Da questo momento in poi inizia il far west. Non esistono regole. E per fare questo serve una moneta libera da vincoli: il bitcoin. Ma questa è un'altra storia...


Con il nostro sommergibile siamo arrivati a 2000 mt. Nessuno sa nulla di nessuno, qui puoi accedere a quanto più viscido possa produrre la razza umana. Se ci sei arrivato "in chiaro", sei un pazzo e stai rischiando grosso, e seriamente. Non come aver venduto l'iPad guasto per funzionante ad un tipo su Subito.it, qui la faccenda si fa seria.

Se sei qui, allora teoricamente parrebbe tu possa:
  • accedere a pornografia illegale
  • comprare e vendere armi
  • comprare e vendere droga o farmaci
  • assoldare un killer (pare che i prezzi si aggirino intorno ai 12.000 dollari in america e 10.000 euro in europa, previa approvazione)
  • vendere e comprare botnet, computer e server compromessi
  • vendere e comprare qualsiasi cosa normalmente non vendibile
  • accedere a materiale normalmente censurato (vivisezioni, cadaveri, documenti riservati, c'è di tutto)
  • acquistare carte di credito clonate
  • acquistare moneta e titoli falsificati
  • accedere a forum decisamente illegali e di organizzazione di attività criminose
Intendiamoci, qui tutto è ofuscato, opaco. Nessuno vi saprà dire quanto sia vero o falso. Nessuno può garantire che il vostro acquisto venga poi onorato. Avvalersi del diritto di recesso sembra essere alquanto difficile a queste profondità.


Se vuoi qualcosa, devi conoscere i siti giusti, probabilmente devono averteli comunicati le persone giuste e comunque rassegnati, qui tutto cambia in fretta. Un sito oggi raggiungibile ad un indirizzo (scordatevi i link comodi, questi sono perlopiù stringhe di caratteri), domani non lo può essere più.




Scendendo tra i 2000 ed i 3000mt i server utilizzeranno la rete onion per rendere anonimi e non tracciabili i loro servizi. I link in genere terminano per .onion. In questa fascia non ci capiti per caso e le informazioni non le trovi attraverso un motore di ricerca. Sostanzialmente nulla è legale qui.


Conclusioni

C'è poco da dire, il web è sterminato. E' una città. E come ogni città, ha dei vicoli bui che è meglio non percorrere. Dei vicoli dove sai bene prima di entrarci che potresti uscirci molto male.
E' uno dei motivi per cui, volontariamente, questo articolo vuole avere esclusivamente carattere informativo, non tecnico. Parla in maniera superficiale e banale di un argomento invece estremamente vasto. E se mi permetti un cosiglio (considerando il titolo di questo articolo probabilmente non hai dimestichezza con il deep web, altrimenti non l'avresti letto), se puoi, evita di giocare con il fuoco. Perchè ci si può anche bruciare. C'è chi paragona uno sprovveduto che naviga nel deep web ad un turista con un vistoso Rolex al polso mentre gira per vicoli malfamati.

mercoledì 8 aprile 2015

Utilizzo di un Antivirus in un contesto aziendale

Differenze

L'utilizzo di un antivirus in un contesto aziendale differisce di molto rispetto ad un uso esclusivamente domestico. Salvo rare eccezioni, difatti, gli antivirus free non sono consentiti ad uso commerciale. Quindi utilizzare un antivirus free su una macchina aziendale equivale a non avere affatto la licenza, esponendoci ad una violazione della stessa. Gli antivirus free, inoltre, solitamente non possono essere installati sui server. Non che questo serva sempre (anzi), ma comunque è un aspetto da tenere in considerazione.

Quali caratteristiche deve possedere un antivirus aziendale?
  • Innanzitutto deve disporre di una console centralizzata in grado di monitorare i dispositivi connessi.
  • In secondo luogo, è opportuno che un server centrale distribuisca gli aggiornamenti ai client, evitando quindi che le stesse definizioni vengano scaricate decine, a volte centinaia, di volte generando del traffico superfluo.

Diamo uno sguardo

Intendiamoci, lungi da me esprimere delle opinioni sull'affidabilità o sulla bontà dei vari motori antivirus. Lo scopo di questo articolo non è definire chi sia il migliore, ma dare uno sguardo agli strumenti in grado di gestire più macchine contemporaneamente.
Personalmente ritengo che sia estremamente difficile stabilire una classifica dell'efficacia di un antivirus, per vari motivi. Primo: la situazione è estremamente variabile ed una considerazione fatta oggi può già non valere più tra una settimana. Secondo: semplicemente alcuni antivirus rilevano dei virus che altri non rilevano, e viceversa. E ritengo che la situazione sia tutto sommato estremamente equilibrata. Manca, sostanzialmente, un parametro di valutazione. Anche il numero di signature è irrilevante, perchè un numero inferiore può anche corrispondere ad una maggiore capacità di rilevare un virus trovando la sua "radice" (molti virus sono piccole modifiche di virus già esistenti).


Premessa:
Ho avuto modo di lavorare con le console elencate di seguito, non ho citato altri antivirus semplicemente perchè non li ho utilizzati in scenari professionali oppure li utilizzo da troppo poco tempo per trarne delle, seppur banali, conclusioni. 
Non disponendo di sfere di cristallo in grado di prevedere il futuro successivo alla stesura di questo articolo, vi consiglio sempre, in caso di prodotti gratuiti, di rileggere le condizioni contrattuali degli stessi.


AVG Business

Un ottimo prodotto, semplice da installare e semplice da distribuire. La console è intuitiva e l'antivirus snello, completo e soprattutto molto automatizzato.

- Ha una console centralizzata di gestione
- Distribuisce gli aggiornamenti ai client
- Gestisce device MAC e Windows




Sophos EndPoint Protection

Sophos è un prodotto di fascia enterprise. Molto complesso da installare e difficile da distribuire se si hanno sedi remote non connesse in VPN (è necessario creare un server di distribuzione, e l'operazione non è proprio immediata). Ha funzionalità estese e, nella sua licenza EndPoint, è in grado di effettuare operazioni particolarmente utili (content filtering, blocco dei supporti di memorizzazione USB e masterizzatori, crittografia del disco, etc..).

- Ha una console centralizzata di gestione
- Distribuisce gli aggiornamenti ai client
- In licenza EndPoint consente una serie di funzioni aggiuntive
- Gestisce device MAC e Windows

In un caso mi è capitato di segnalare un virus non rilevato (e ignoto a tutti gli antivirus, a detta di VirusTotal https://www.virustotal.com/it/ ). Ci hanno lavorato di notte (la sede è Americana) ed il giorno dopo era l'unico antivirus in grado di bloccare la minaccia. Del resto è l'antivirus utilizzato da quasi ogni istituto governativo USA.

Degno di nota è il supporto Italiano, competente ed immediatamente disponibile.




Avast! Business

Avast ha di recente cambiato la sua politica commerciale ed è, ad oggi, uno dei pochissimi antivirus free ad uso aziendale. Le funzioni sono certamente limitate (salvo passare alla versione premium) ma indubbiamente si tratta di una soluzione "low cost" (anzi, zero cost) perfettamente in regola.

- Ha una console centralizzata di gestione, via web (quindi semplicissima da gestire e non richiede installazione lato server, tuttavia la comunicazione con i client non è immediata)
- NON distribuisce gli aggiornamenti, i client continuano ad aggiornarsi autonomamente
- La versione Premium ha funzionalità estremamente interessanti (tra cui la crittografia in caso di hotspot pubblico, etc..)
- Gestisce device MAC e Windows

A breve rilasceranno la versione mobile, completando la soluzione già di per se interessante.





Altri Antivirus

Immunet

Immunet è una soluzione standalone, non dispone di console centralizzata e di distribuzione degli aggiornamenti. Ha tuttavia un vantaggio interessante, ovvero la possibilità di essere installato come "second line of defense" (volendo parafrasare un termine tipico della sicurezza perimetrale). Non interferisce con gli antivirus già installati. Dispone, inoltre, di una vivace e collaborativa community.


ClamAV

Se le vostre email transitano da un server Linux, avete una ragionevole probabilità che le stesse siano passate da questo antivirus. E' sostanzialmente un must per i mailserver (vuoi perchè gratuito, vuoi perchè veloce, vuoi perchè molto seguito), ed esiste un porting anche per altri sistemi operativi. Non ha centralizzazione con console e distribuzione degli aggiornamenti (salvo non implementarla autonomamente) ma consente l'adozione di database extra spesso estremamente efficaci.




Conclusioni

Personalmente ritengo le tre alternative valide, pur coprendo segmenti ed esigenze diverse.

Di sicuro, se avete antivirus scaduti o free (ad uso esclusivamente domestico), passate alla versione gratuita di Avast Business. Almeno sarete in regola ed avrete un antivirus aggiornato. Le soluzioni standalone sono valide, ma potrebbero essere scomode da gestire con un numero di postazioni e server superiore ad una decina.


mercoledì 18 febbraio 2015

CryptoLocker e strategie difensive in contesti aziendali

Ultimamente si sente sempre più spesso parlare di CryptoLocker et simila. La modalità è sempre la stessa: un malware crittografa i dati dell'utente rendendoli inservibili salvo corrispondere un contributo e ricevere la chiave di sblocco. Si tratta, sostanzialmente, di una forma di estorsione informatica purtroppo estremamente comune.

Come possiamo proteggerci o limitare i danni?

Partiamo con il dire che le nostre azioni non possono che essere preventive perchè, una volta crittografati i file, la questione si complica e diventa molto difficile uscirne illesi.

Prendiamo uno scenario tipico: azienda con N utenti in Dominio AD, percorsi di rete con dischi mappati e file in comune.

In uno scenario di questo tipo, valgono le regole generali di buon senso:

1. Un utente è un utente, non un amministratore (anche della sua macchina).
L'ABC della sicurezza informatica detta, in testa, la regola base per cui un utente è solo un utente, non un amministratore di sistema. Sarà più scomodo, ma è così che funziona. Il metodo più rapido per farsi male è lasciare agli utenti la possibilità di installarsi ogni tipo di programma in maniera anarchica ed incontrollata. In questo specifico caso, tuttavia, è bene precisare che CryptoLocker agisce sulla possibilità o meno dell'utente di accedere ai file, anche senza alcuna permission escalation. Quindi questa regola rimane in testa, ma la sua efficacia in questo scenario è abbastanza marginale.

2. Limitare l'accesso alle risorse strettamente indispensabili
Se non vi sono motivi specifici affinchè il magazziniere debba accedere ai dati amministrativi, questa possibilità deve essere inibita. Se un utente, facente parte di un'Unità Organizzativa o di un Gruppo, non ha necessità di scrivere (ma solo di leggere) in un percorso solitamente utilizzato da altri utenti, limitarne i permessi. Questi accorgimenti ci consentiranno di limitare i danni ad aree relativamente circoscritte.

3. Limitare l'esecuzione dei file non necessari
File eseguibili, script e file pericolosi spesso vengono erroneamente accettati dai sistemi di frontend. Nel caso delle varianti di CryptoLocker, ho assistito principalmente alla diffusione di file .scr. E' opportuno che i MailServer impediscano la ricezione di email contenenti allegati di questo tipo (anche all'interno di file compressi).
Un altro ottimo modo per gestire l'esecuzione di file è dotare la struttura di EndPoint Protection in grado di inibire l'esecuzione di allegati pericolosi, a prescindere dal contenuto malevolo o meno, direttamente sui client. Valutare l'investimento di un Antivirus che abbia anche funzionalità di EndPoint Protection non è mai una cattiva idea.

Ecco un esempio di blocco di allegati pericolosi su un mailserver Linux Postfix con controllo dei file compressi tramite ClamAV:

Aggiungere il Reject per gli allegati con estensione specifica:
/etc/postfix/mime_header_checks (aggiungere il riferimento a main.cf)
/name=[^>]*\.(bat|com|exe|dll|vbs|scr)/ REJECT tipo di allegato eseguibile non consentito
Aggiungere il blocco per gli allegati contenuti in file compressi, anche crittografati (ma con nome in chiaro):
/var/lib/clamav/extfile.rmd
Allegato.con.Estensione.non.consentita.1a:0:.*\.(bat|com|exe|dll|vbs|scr)$:*:*:*:*:*:*
Allegato.con.Estensione.non.consentita.1b:1:.*\.(bat|com|exe|dll|vbs|scr)$:*:*:*:*:*:*
copiare extfile.rmd in extfile.zmd e riavviare clamd e postfix

4. Centralizzare i dati su FileServer
Ovviamente, gli utenti devono lavorare su FileServer e mai in locale. Per svariati motivi che spaziano dalla maggiore ridondanza hardware che un Server possiede ad una facilità di gestione dei dati stessi. Sembra scontato, ma non lo è. In caso di utenti recidivi, è sempre possibile mappare le cartelle di profilo direttamente sul proprio Server.



4. Backup, backup e backup
Inutile soffermarsi oltre, un backup salva la situazione. Sempre. E' necessario, tuttavia, ricordarsi che CryptoLocker può cercare dischi connessi, quindi i backup devono essere fatti correttamente, ovvero su supporti non accessibili dagli utenti (ma solo dai sistemi di backup). Possibilmente devono andare offline, su supporti a scrittura sequenziale e locati altrove. A volte questo è l'unico modo per recuperare un file crittografato. Perderemo qualche ora di lavoro, ma nessuno si lamenterà conoscendo l'alternativa: perdere definitivamente il file.
Ad oggi le varianti in grado di leggere i dati dai dischi di rete mappati e crittografarne il contenuto sono abbastanza poco diffuse, ma esistono ed è necessario tenerne conto. Molto più frequente, invece, è la possibilità che Desktop, Documenti e cartelle legate al profilo utente vengano crittografate a prescindere dalla locazione fisica (se sul disco locale o su un FileServer in rete).

5. ShadowCopy
Questo è indubbiamente il metodo più rapido per ripristinare il contenuto delle directory compromesse. Abilitando l'utilizzo delle ShadowCopy sui FileServer (ma anche sui client, se volete), avremo la possibilità di ripristinare una directory in una condizione precedente.


Durante la fase di configurazione delle copie Shadow, visto anche il basso impatto computazionale anche su FileServer relativamente carichi, potrebbe essere opportuno incrementare il numero di SnapShot giornalieri. Normalmente io ne pianifico due o tre, in base al contenuto del volume.




6. Una macchina compromessa, è una macchina compromessa
Non perdete tempo a recuperare la situazione, una macchina compromessa può essere solo formattata. Punto. Ogni altra operazione crea l'illusione di offrire una strada più rapida verso il ripristino delle funzionalità della macchina stessa, ma il più delle volte si dimostra essere una lotta del tutto inutile e "donchishiottesca".




In bocca al lupo, e ricordatevi la premessa: queste sono azioni preventive. Se siete giunti qui perchè avete già il problema, questa pagina non vi sarà d'aiuto. Se siete giunti qui, invece, per un approfondimento, allora questo è il momento giusto (se necessario) per sistemare qualche aspetto dell'infrastruttura IT. Non dopo.


mercoledì 3 dicembre 2014

Attacchi di tipo Social Engineering nel reale

Durante la giornata di ieri sono stato coinvolto da un mio cliente, che ovviamente lascerò anonimo, per un attacco di tipo Social Engineering, ovvero che conteneva un aspetto "sociale" estremamente forte. L'attacco ha causato una perdita economica estremamente considerevole e difficilmente recuperabile.

Il social engineering consiste nell'introdurre una componente sociale importante in un attacco che di tecnico potrebbe avere anche poco o nulla. Un esempio "didattico" lo introdussi quando uno dei miei attuali collaboratori iniziò a lavorare per noi. Per trasferire l'importanza della sensibilizzazione degli utenti, gli chiesi di chiamare dei clienti a caso, presentarsi come uno dei nuovi tecnici dell'azienda manutentrice e chiedere loro, con una scusa qualsiasi, la password d'accesso ai propri computer. Con suo immenso stupore, una percentuale molto alta diede la password pur non avendo mai sentito la voce ed il nome del nuovo collaboratore. Da quel giorno nacque una continua campagna di sensibilizzazione, perchè investire tempo su un utente non è meno nobile di investirlo nella revisione delle regole di firewalling o nella messa in sicurezza di un server pubblico.

Tutti noi, chi più chi meno, abbiamo fatto gli anticorpi ai file .zip o .exe, o, in genere, agli allegati via posta. Più o meno sappiamo riconoscere il phishing quotidiano e, con gradi di perspicacia certamente differente, ne stiamo alla larga. Ci sono, tuttavia, degli attacchi in grado di portare l'effetto ad un livello superiore.


Proviamo, quindi, ad analizzare step-by-step l'attacco avvenuto, tenendo in considerazione che non solo si tratta di un attacco reale, ma che ha sortito l'effetto voluto verso utenti solitamente attenti e affatto superficiali.

- step 1: la compromissione tecnica
la casella di posta di un fornitore del mio cliente viene compromessa. L'attaccante, a differenza di quanto accade normalmente, rimane in ascolto. Legge tutte le email ed elabora un piano attendendo una situazione favorevole.

- step 2: la situazione fa l'uomo ladro
il fornitore entra, dopo qualche settimana, in una situazione debitoria. L'attaccante, quindi, registra un dominio molto simile a quello originario (utile solo ad impostare il "rispondi a") e manda un'email al mio cliente dalla casella reale e compromessa del fornitore indicando la nuova banca per effettuare il bonifico. Trattandosi di una situazione internazionale, il fatto che la banca fosse altrove non ha destato alcun sospetto.
NB: L'email riportava l'intero elenco della conversazione con svariati reforward precedenti, i riferimenti reali dell'ordine (numero, data, importo, merce), le firme, i nomi degli interlocutori, lo stile discorsivo e sintattico del mittente originario. Non è un semplice phishing, era per tutto ed in tutto assolutamente veritiera. Era studiata perfettamente nei minimi dettagli ed era frutto di un'analisi durata probabilmente settimane.

- step 3: la veridicità
il mio cliente risponde (e la risposta va in automatico sul nuovo dominio del "rispondi a", tenendo all'oscuro il fornitore originario), lo scambio di email si interrompe alla seconda risposta, dove si indica di aver effettuato il bonifico correttamente.

Dopo qualche giorno, il fornitore reale invia richiesta di saldo, e si scopre il tutto.

Morale della favola: la sicurezza informatica non può prescindere da una buona dose di diffidenza e conoscere il fenomeno degli attacchi a sfondo sociale è assolutamente fondamentale. Questo esempio è, purtroppo, un perfetto esempio di come molto spesso un grado tecnico relativamente elementare può, se sfruttato al meglio e se coadiuvato da tecniche di tipo sociale, causare gravi danni.

domenica 5 ottobre 2014

WiFi ad altissima densità (eventi sportivi, concerti, etc..)

Recentemente ho avuto l'onore di essere coinvolto come responsabile informatico di una delle sei sedi di un importante evento sportivo: un mondiale di uno degli sport più diffusi al mondo dopo il calcio.

Questa esperienza, durata per ben due settimane, mi ha consentito di accumulare nozioni in uno dei campi più ostici e meno riproducibili del mondo del wireless. Progettata fin dall'inizio seguendo determinate logiche, alcuni importanti accorgimenti, giorno dopo giorno, ci hanno consentito di trovare un equilibrio perfetto ed erogare il servizio oltre ogni più rosea aspettativa.

Lo scenario e gli obiettivi

Lo scopo era erogare connettività wireless e cablata a circa 100 giornalisti (ed operatori) internazionali per un totale di circa 350-400 apparati (tra server, sistemi di gioco, utilizzatori e devices secondari). Tutti i dispositivi avevano necessità di bande importanti, dovevano trasmettere i video ed il materiale fotografico durante e dopo le partite e molto spesso i giornalisti avevano in stream la partita stessa che stavano vedendo dal vivo, per visionare moviole ed ascoltarne i commenti live.

La location: un palazzetto dello sport, capienza circa 6000 spettatori (molto a ridosso del campo di gioco), sempre pieno durante le competizioni in cui si esibiva l'Italia.

Il sistema: 17 access point (13 2,4Ghz e 4 5Ghz), gestiti da un controller centralizzato in grado di intraprendere azioni sugli utenti (spostarli di cella, bloccarli, etc..).


Qualche numero

In due settimane di evento sono stati trasferiti circa 6 Tb di dati, di cui oltre 2 Tb su wireless.

Durante la competizione circa 450 device hanno avuto accesso ed hanno utilizzato la rete wireless almeno una volta.

Abbiamo "subito" l'accensione di circa 600 access point indesiderati ed abbiamo avuto un totale di quasi 50.000 spettatori complessivi nelle 9 giornate di manifestazione.


I problemi

In situazioni di questo tipo, all'aumentare degli spettatori aumentano i problemi. Avere 8.000 device che fanno anche solo una scansione di rete ogni 120 secondi, comporta un carico per le celle non indifferente. Basti pensare al momento in cui le squadre sono schierate e parte l'inno nazionale della nazione ospitante. Migliaia di device verranno riaccesi per filmare il momento o fare delle foto, e questo comporta delle operazioni in background che finiscono per incidere sull'impianto.

Come se non bastasse, ogni squadra, ogni sistema video, ogni sistema audio, ogni sistema di gioco (dai tablet per gli arbitri allo scoresheet) richiede l'utilizzo di apparati radio, spesso mal configurati e con ampiezze di banda larghissime e potenze estremamente alte.

Ad aggiungere una ulteriore dose di problemi non da poco, molti utilizzano i propri device come hotspot, creando a tutti gli effetti centinaia di access point in sovrapposizione ai soli 3 canali utilizzabili del wireless a 2,4ghz. Nelle due settimane dei mondiali, abbiamo avuto un incredibile numero di quasi 600 rogue access point rilevati in conflitto con il sistema installato.

(questi sono i canali in sovrapposizione superiori ai -65db, non sono visibili i circa 30 access point sotto questa soglia, fondamentalmente hotspot privati)


Per chi fa wireless, questa è la tempesta perfetta e supera di molto gli ingredienti necessari per rovinare una piacevole serata.


Chi ha dimestichezza con gli analizzatori di spettro, troverà certamente interessante la schermata di cui sopra.

Le contromisure e le precauzioni adottate

  • Aumentare il numero di access point al massimo possibile, evitando le sovrapposizioni di canali. Quindi questo significa che in ogni ambiente dovrò avere un massimo di 3 access point, rispettivamente sui canali 1,6,11. Le connessioni tenderanno a bilanciarsi naturalmente e le performance ne beneficieranno.
  • Utilizzare quanto più possibile la rete a 5Ghz; ormai molti telefoni, tablet e notebook hanno la radio a 5 e preferiranno questa modalità rispetto a quella a 2,4Ghz. Nei momenti di massima congestione, i device a 5Ghz, nel mio caso, avevano oltre 25Mbit di banda utilizzabile, contro i 3Mbit di quelli a 2,4ghz.
Riguardo questi due punti, le mie aree "critiche" erano 3: uffici, sala stampa e area giornalisti a bordo campo. Creando isole di (massimo) 3 AP a 2,4Ghz e 2 AP a 5Ghz abbiamo gestito efficacemente anche 160 connessioni simultanee e a spalti completamente pieni.

  • Abbassare le potenze: è assolutamente fondamentale avere potenze basse, meno pubblico "prende" la rete e meglio è. Le celle devono coprire delle aree ridottissime e null'altro. Questa è la chiave di tutto. Utilizzare dove possibile delle antenne fortemente direttive, diffondere omnidirezionalmente non è sempre la scelta giusta, soprattutto in questi casi.
  • DHCP veloci! Se avete dei DHCP parassiti (e ne avrete tra i mille apparati che si collegheranno), gli unici due modi per non farsi rilasciare IP sbagliati sono: 
    • 1) impostare il dhcp snooping su tutti gli switch (ma non è cosa semplice perchè questa funzione è gestita da switch di profilo medio-alto e non potrete propagare tutto questo anche sugli switch da poche porte che serviranno a gestire situazioni impreviste
    • 2) avere server DHCP veloci, in grado di rilasciare IP prima che lo facciano altri; nel mio caso ho utilizzato 3 server DHCP nei 3 armadi di distribuzione verticale.
  • Gestire le band limitation: gli abusi sono all'ordine del giorno, è importante limitare l'utilizzo di chi "esagera". E per esagera io ho definito il limite di 30Mbit di banda internet utilizzata per più di 15 minuti. Superata questa soglia il client veniva limitato a 5Mbit e successivamente a 3Mbit. Ovviamente è importante definire chi deve fare traffico perchè è il suo scopo, quindi nel mio caso i fotografi potevano caricare senza limiti in ogni caso.
  • Cercare gli AP di terzi, gestirli, limitarli, offrirsi di riconfigurarli per evitare sovrapposizioni di bande. Questo aspetto più "sociale" che tecnico non è affatto da sottovalutare.
  • Utilizzare ampiezze mai superiori ai HT20 (spesso definito come "velocità massima") sia sul 2,5 che sul 5Ghz. Eviteranno di catturare disturbi e sovrapposizioni, garantendo comunque una banda più che sufficiente in tutte le condizioni.
  • Incentivare l'utilizzo della rete cablata. Sembra banale, ma non è scontato che una patch a 20 cm dal proprio notebook venga preferita alla connessione wireless.
  • Non sottovalutare l'aspetto "networking tradizionale", laddove possibile raddoppiare i link in LACP o utilizzare percorsi ridondati in Spanning Tree non è mai una cattiva idea.
Personalmente ho ritenuto utile (purtroppo mi è venuto in mente solo alla fine della competizione) anche adottare un piccolo stratagemma: definire le potenze "a regime", ma poi mantenere gli apparati al massimo della potenza (fino a qualche minuto dal momento della "congestione radio"), lasciando libero un canale. Tutti gli Access Point parassiti (dalle chiavette agli hotspot), tenderanno a posizionarsi in "auto" sul canale più libero, quindi a regime potrete ribassare le potenze nella speranza che gli access point che non è stato possibile limitare, si siano spostati tutti sul canale lasciato volontariamente libero. Molti di loro negoziano il channel solo all'accensione, e non periodicamente.

venerdì 30 maggio 2014

TrueCrypt è morto?

TrueCrypt ha sempre destato fascino in alcuni e noie per altri. Ma andiamo con ordine.

Cos'è TrueCrypt?

Per i pochissimi che ancora non sanno cos'è TrueCrypt, basti pensare che ormai era diventato un must nel mondo della crittografia multipiattaforma. Che il tuo sistema operativo fosse Windows, Linux o Mac, poco importava, potevi montare un volume integralmente crittografato per poi smontarlo appena terminato. I volumi erano visti come macro file della dimensione del disco montato. La semplicità, la sicurezza e l'efficacia di TrueCrypt lo hanno da sempre, e per moltissimi anni, spinto in vetta nei download.

A chi crea problemi TrueCrypt?

TrueCrypt crea problemi a chi vuole accedere ai dati crittografati. 
Il suo codice opensource era trasparente, nessuna organizzazione poteva introdurre facilmente backdoor. Avevamo, quindi, un software incredibilmente stabile (io uso truecrypt da circa 10 anni, e non ricordo di gravi vulnerabilità che ne abbiano mai compromesso significativamente il sistema, del resto il rilascio degli aggiornamenti era sporadico, indice quasi sempre di un'alta affidabilità intrinseca) ed eccezionalmente sicuro (l'utilizzo di più algoritmi crittografici aumentava esponenzialmente la difficoltà nell'accesso ai dati sfruttando le vulnerabilità di un singolo algoritmo; l'utilizzo di un keyfile ed una password strong  - minimo 22 caratteri consigliava TC - lo rendevano davvero un punto di riferimento nella sicurezza dei dati).

Ha schiacciato qualche piede? Evidentemente si. Ha schiacciato i piedi di organizzazioni che hanno come scopo quello di accedere a delle informazioni sensibili. E' noto che l'NSA sotto questo punto di vista non abbia mai risparmiato metodi a dir poco discutibili e del tutto incuranti di qualsiasi diritto umano alla riservatezza e alla privacy.

Qualcosa non torna

Qualche mese fa qualcuno mise in giro voci che screditavano TrueCrypt. Si bisbigliava che contenesse backdoor, che fosse insicuro e così via. Gli sviluppatori e la community, quindi, investirono del tempo nella revisione completa del codice e dichiararono, pertanto, che non era presente alcuna backdoor e non vi era alcun dubbio legato alla sicurezza del software.

Qualche settimana dopo, tuttavia, il progetto chiuse. Il codice sorgente venne tolto (così da evitare che altri creassero dei prodotti simili), i download rimossi. Il tutto venne sostituito da una bella paginetta che puzzava di presa in giro lontano un miglio:

http://truecrypt.sourceforge.net/




Perchè?

A questo punto le domande sono molte.
  1. Perchè gli sviluppatori hanno investito del tempo a revisionare il codice, a dichiararlo tutto sommato sicuro, ed ora improvvisamente TrueCrypt è diventato pericolosissimo?
  2. Perchè non si parla di quali e quante vulnerabilità abbia TC?
  3. Perchè il codice sorgente è scomparso? (http://www.truecrypt.org/docs/source-code è stato rimosso e punta alla paginetta-farsa) E' consuetudine che un progetto opensource venga migliorato da tutti coloro i quali possano ritenerlo opportuno. Se ho un problema nel mio codice, la community può vivere di vita propria e portare avanti un progetto che io, autore, ho deciso di non seguire più. Questo è del tutto normale e sono migliaia i progetti abbandonati e ripresi da altri.
  4. Perchè non è più possibile scaricare vecchie versioni di TC?
  5. Perchè viene osannato il passaggio a BitLocker (Microsoft, codice chiuso, backdoor inseribile facile facile...)? Se a me non interessa più sviluppare un prodotto, non certo mi metto a scrivere una guida su come fare la stessa cosa con altri software. Che senso ha tutta questa spinta verso BitLocker?

Ammesso che la chiusura sia voluta e non si tratti di un banale defacement o abuso della piattaforma sourgeforge (per cui decaderebbe qualsiasi ipotesi e si risolverebbe in un banale "scherzo"), lascio a voi le conclusioni.

Viviamo davvero nell'era della libertà digitale? Forse no, forse il macchiavellico concetto del fine che giustifica i mezzi è andato persino oltre le peggiori e pessimistiche aspettative. Il motto "combattiamo il terrorismo" è diventato forse il passepartout legale per ogni azione, seppur riprovevole?