Come tutti sanno, oggi giorno il 90% del traffico web è criptato questo rende
l'utilizzo di
NIDScome
snortpiuttosto problematico. Anche nel caso di intrusioni il
semplice log dei pacchetti, senza conoscerne il contenuto, può risultare assolutamente inutile.
Ci sono diversi modi per avere il traffico in chiaro al fine di poterlo analizzare con
un software di intrusion detection:
- il primo è semplicemente far terminare il flusso criptografico dei dati che dovrebbero arrivare al webserver prima ponendo davanti a quest'ultimo un reverse proxy. In pratica il client si collega al reverse proxy in modo criptato ma quest'ultimo si collega al webserver in chiaro. Fra il proxy e il webserver è possibile inserire un sensore per il rilevamento delle intrusioni.
- il secondo consiste nell'effettuare tutte le operazioni di monitoraggio direttamente dall'interno del webserver e quindi aumentandone il livello di logging applicativo.
- Il terzo modo consiste nell'attrezzare il nostro sensore della possibilità di decriptare il traffico.
Decriptare SSL
Prima di procedere è necessario approfondire dal punto di vista teorico come funziona
la decriptazione dei dati, per fare questo potete leggere
questo articolo in inglese.
Per dirla in due parole ci sono due condizioni che devono essere
rispettate prima di procedere:
- Il server deve usare il meccanismo per scambio delle chiavi RSA (leggi questo articolo e l' RFC2246) e per fortuna questo è il sistema più comune usato dai webserver che usano SSL. Mentre se stai usando DSA keypairs oppure il meccanismo di scambio chiavi Diffie-Hellman allora ti è andata male.
- Devi poter accedere alla chiave privata RSA per copiarla sul server di sguil/snort.
Adesso dove sono le chiavi ?
Ottenere le chiavi private dal nostro server per copiarle sul server dello
sguil/snort può comportare un po' di lavoro. La chiave potrebbe essere conservata in un file
.pem da qualche parte nel webserver e copiarla sul server dello sguil/snort dovrebbe essere piuttosto
semplice. Tuttavia, alcuni sistemi operativi come per esempio Windows conservano la chiavi in un "certificate
store" piuttosto che in
.pem file.
Quindi per ottenere la chiave private abbiamo bisogno prima di tutto di esportare il
certificate e la chiave insieme in un file
PKCS12 (leggi
quiper sapere come fare). Poi, una volta esportato il certificato, bisogna esportare la chiave
usando il comando
openssl nel seguente modo:
C:>openssl pkcs12 -in c:\MIOCERTIFICATO.pfx –out c:\MIO_CERTIFICATO.pem -nodes
Quando ottieni il prompt inserisci la password che hai fornito durante la proc
edura di esportazione del certificato. Il file MIO_CERTIFICATO .pem ottenuto co
nterrà un blocco di testo come il seguente:
—–BEGIN PRIVATE KEY—–
MISLKJWLKERJNBgkAELRJWELKASDFAASCBKcwggSjAgEAAoIBAQCvHJFIpFwXZJ0x 2DzEY2B4MDBBKSLJFWELIKFSoEGTAARh3OAP+UMedNf2t8/MVJdEEAM7TQ
<snip>
EZq3T23K3K3KSDKGSjVRorB0YGvDSLDFJSLKEJFRLWEJKSFcLCC4lGQeTg+usZmtcx4VI wGI70e4Byd+Lba01K3KS398SK=
—–END PRIVATE KEY—–
MISLKJWLKERJNBgkAELRJWELKASDFAASCBKcwggSjAgEAAoIBAQCvHJFIpFwXZJ0x 2DzEY2B4MDBBKSLJFWELIKFSoEGTAARh3OAP+UMedNf2t8/MVJdEEAM7TQ
<snip>
EZq3T23K3K3KSDKGSjVRorB0YGvDSLDFJSLKEJFRLWEJKSFcLCC4lGQeTg+usZmtcx4VI wGI70e4Byd+Lba01K3KS398SK=
—–END PRIVATE KEY—–
A questo punto copia il blocco di testo ottenuto e incollalo all'interno del file
myExportedCertificate.pem poi salva il file sul server sensore di sguil/snort.
C'è da aggiungere che windows non puo' esportare le chiavi private neppu
re col software di gestione dei certificati. Ma sembra che jailbreak
possa farlo.
Avviso
Come spiegato in
questo articolo in Inglese,
la chiave privata del tuo server è davvero un'informazione molto sensibile. C
on essa, un utente malintenzionato potrebbe decrittografare il traffico SSL del
server o utilizzarla insieme al certificato del server per mascherarsi come un
sito legittimo. È necessario prestare estrema attenzione alla gestione della
chiave privata:
- non lasciarne copie in giro in directory temporanee,
- assicurati che non finisca accidentalmente su Internet
- assicurati che il server sgui/snort sul quale andrai a copiare la chiave sia molto ben configurato e hardenizzato. Pensa a questa chiave privata come alla combinazione per proteggere i tuoi oggetti di valore: assicurati di condividerla solo con fonti attendibili.
Usare la chiave privata
Una volta che abbiamo la nostra chiave privata, potremmo puntare
Wireshark
alle directory di acquisizione del contenuto di sguil/snort. Ma questo approcci
o non si presta a un monitoraggio efficiente, mentre sarebbe molto meglio se potessimo
convogliare le nostre decrittazioni direttamente in
sguil/Snort
quasi in tempo reale, sfruttando i vantaggi di
SANCP,
PADS
e qualsiasi altra cosa stia girando.
Il software viewssld
di Dmitry Plashchynski è lo strumento di cui
abbiamo bisogno per decriptare i dati. Di recente sono state apportate
alcune aggiunte al codice per facilitare l'integrazione con
sguil/Snort e per produrre decrittazioni più ricche. Concettualmente,
viewssld
ha questo aspetto:
|
| Software viewssld
|
viewssld
ascolta su una data interfaccia tramite il solito
libpcap.
I frame catturati vengono quindi passati alla libreria
libdssl
di Atomic Labs che gestisce la decrittazione vera e propia (l'ultima versione
di libdssl al momento della scrittura è 2.1.1, disponibile tramite
svn qui).
L'output di libdssl è il contenuto del solo pacchetto decifrato ( quindi nessuna intestazione o cose del genere), quindi libnet viene utilizzato per creare un flusso di traffico "falso" contenente i pacchetti SSL decrittografati. Questo flusso falso viene pompato attraverso l'interfaccia di output, dove Sguil/Snort è in ascolto.
Le versioni precedenti di viewssld restituivano il solo traffico client->server (ad es. Richieste HTTP). Ma le versioni successive includono:
Il punto cinque aiuta a integrare viewssld e Sguil come mostrato nel diagramma seguente:
L'output di libdssl è il contenuto del solo pacchetto decifrato ( quindi nessuna intestazione o cose del genere), quindi libnet viene utilizzato per creare un flusso di traffico "falso" contenente i pacchetti SSL decrittografati. Questo flusso falso viene pompato attraverso l'interfaccia di output, dove Sguil/Snort è in ascolto.
Le versioni precedenti di viewssld restituivano il solo traffico client->server (ad es. Richieste HTTP). Ma le versioni successive includono:
- Emissione di un falso handshake TCP a 3 vie per il traffico decrittografato
- Emissione delle risposte del server decifrate così come le richieste del client, mantenendo i numeri di sequenza TCP (falsi) correttamente aggiornati. I numeri di sequenza e altri "mobili" di intestazione TCP/IP sono ovviamente una finzione completa: poiché il traffico decrittografato ha dimensioni diverse rispetto al traffico crittografato, non è possibile utilizzare i valori "reali". Il flusso decifrato può anche essere frammentato/segmentato in modo diverso da quello crittografato, ma anche in questo caso c'è poco che puoi fare al riguardo
- Emissione di un falso RST alla fine di ogni sessione
- Utilizzo di un numero di identificazione (ID) IP facilmente ricercabile per tutti i frame falsi in modo da poter dire quali sono stati emessi da viewssld (54609 == 0xd551 == DSSL)
- Emettere i frame decifrati su una porta diversa su cui sono stati catturati (es. 443->80, 465->25, 993->143, ecc.)
Il punto cinque aiuta a integrare viewssld e Sguil come mostrato nel diagramma seguente:
il flusso viaggia nel modo seguente:
Sguil/SANCP/Snort/PADS/ecc. quindi vedono sia il traffico crittografato che quello decifrato, come mostrato nello screenshot qui sotto. Sullo sfondo puoi vedere una query SANCP con due righe di risultati. La prima riga è il traffico SSL grezzo catturato da Sguil sulla porta 443; la seconda riga mostra Sguil che cattura l'output del flusso decifrato falso corrispondente da viewssld sulla porta 80. Le due finestre di trascrizione raccontano il resto della storia:
- Il traffico non elaborato (frecce blu) entra nell'interfaccia di monitoraggio di Sguil.
- Questo traffico viene catturato sia da Sguil che da viewssld.
- viewssld decifra ciò che può e lo invia all'interfaccia da cui lo ha catturato (frecce rosse). Ciò è reso possibile solo utilizzando una porta TCP diversa per i frame decrittografati: se utilizzasse la stessa porta, rientrerebbe in viewssld.
- Il flusso falso di SSL decifrato viene raccolto da Sguil.
Sguil/SANCP/Snort/PADS/ecc. quindi vedono sia il traffico crittografato che quello decifrato, come mostrato nello screenshot qui sotto. Sullo sfondo puoi vedere una query SANCP con due righe di risultati. La prima riga è il traffico SSL grezzo catturato da Sguil sulla porta 443; la seconda riga mostra Sguil che cattura l'output del flusso decifrato falso corrispondente da viewssld sulla porta 80. Le due finestre di trascrizione raccontano il resto della storia:
Ho testato viewssld con
HTTPS,
SMTPS,
POP3Se
IMAPS: tutti funzionano come previsto. Un file
viewssld.confdi esempio per questi quattro protocolli potrebbe essere simile a questo:
# PID-file percorso(default: /var/run/viewssl.pid)
pid = /var/run/viewssl.pid
# rendi demone ? on/off (default: off)
daemon = on
# loglevel 0-10 (default: 0)
loglevel = 10
# SSL protocols to decrypt
[webserver]
src = eth1
dst = eth1
ip = 10.11.12.13
port = 443
key = /etc/viewssld/webserver.key
dsslport = 80
[mailserverSMTP]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 465
key = /etc/viewssld/mailserver.key
dsslport = 25
[mailserverIMAP]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 993
key = /etc/viewssld/mailserver.key
dsslport = 143
[mailserverPOP3]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 995
key = /etc/viewssld/mailserver.key
dsslport = 110
Notare come le interfacce src e dst siano le stesse in tutti i casi e che
sia specificata la porta non-SSL (dsslport=) così come la porta SSL (port=).
Secondo avviso
Ci sono un paio di cose da considerare quando si utilizza viewssld su un sensore Sguil:
- La decrittazione di SSL ha un costo computazionale importante. Se la CPU del tuo Sguil/Snort è normalmente molto occupata, il carico computazionale associato alla decrittazione potrebbe spingerla oltre ogni limite.
- Il processo di decrittazione è molto sensibile alla perdita di pacchetti. Se viewssld perde un pacchetto, la decrittazione del flusso si fermerà a quel punto; se manca l'handshake SSL all'inizio di una sessione crittografata, non decrittograferà assolutamente nulla.
- Ora stai archiviando sia il traffico crittografato che decrittografato, quindi potrebbe esserci un impatto sull'utilizzo dello spazio disco.
