Con server 7k plus in un ambiente con carico bilanciato F5, quali sono alcuni approcci suggeriti per identificare l'uso e l'utilizzo di TLS SSL al di sotto di 1.2?
Con server 7k plus in un ambiente con carico bilanciato F5, quali sono alcuni approcci suggeriti per identificare l'uso e l'utilizzo di TLS SSL al di sotto di 1.2?
Ci sono molti modi per ottenere queste informazioni.
È importante sondare attivamente i servizi in esecuzione sulla rete e non solo esaminare le informazioni passive poiché le crittografie negoziate e in uso attivo non rappresentano tutte le crittografie configurate per essere utilizzate dal servizio che è ciò che è veramente importante per evitare attacchi di downgrade.
Lo strumento nmap ha uno script chiamato ssl-enum-ciphers che può aiutare
nmap --script ssl-enum-ciphers -p 443 www.sitename.com
-p sta per specificare la porta 443 per https, ma può essere utilizzata su qualsiasi porta. Puoi anche testare enormi elenchi di IP in un singolo comando, ma il seguente è un test contro una porta su un IP per la semplicità del lettore.
L'output di questo comando e delle opzioni è simile al seguente:
trey@pentest01:~$ nmap --script ssl-enum-ciphers -p 443 www.verificationlabs.com
Starting Nmap 7.31 ( https://nmap.org ) at 2017-03-30 00:57 UTC
Nmap scan report for www.verificationlabs.com (198.61.176.181)
Host is up (0.0014s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Key exchange (secp256r1) of lower strength than certificate key
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Key exchange (secp256r1) of lower strength than certificate key
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Key exchange (secp256r1) of lower strength than certificate key
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 4.76 seconds
Nota: i dati SSL verranno visualizzati e non è stato configurato su questo server. È anche possibile automatizzare questo script per eseguirlo a intervalli regolari e riportare risultati non conformi.
Se si dispone già di uno scanner di vulnerabilità in questo ambiente, è possibile ottenere un elenco molto simile a quello suggerito da Trey. In Qualys, è possibile eseguire la scansione del QID 38116 e produce un elenco di versioni SSL / TLS supportate, nonché suite di crittografia per ogni porta scansionata.
Immagino che qualcosa di simile sia disponibile con altri scanner di vulnerabilità (ad esempio Nessus).
Suppongo che tu sia interessato a quantificare i protocolli TLS e i codici utilizzati dai tuoi clienti, meglio comprendere e comunicare l'impatto delle modifiche necessarie per ritirare "TLS precoce" come da PCI.
In tal caso, sei così fortunato. Puoi facilmente registrare i parametri negoziati di ogni connessione usando un iRule come questo su ogni F5 LTM virtuale:
when CLIENTSSL_HANDSHAKE {
log local0. "protocol=[SSL::cipher version] cipher_suite=[SSL::cipher name]\
virtual=[virtual name] client_addr=[IP::client_addr]"
}
Quale risultato in voci di registro come questo:
protocol=TLSv1.2 cipher_suite=ECDHE-RSA-AES256-CBC-SHA virtual=/Common/mywebsrv client_addr=172.16.31.13
Queste voci di registro vanno a / var / log / ltm su F5 e possono essere inoltrate al SIEM per l'aggregazione e l'analisi tramite syslog.
Dopo aver effettuato la registrazione per un po ', puoi analizzare i log e determinare:
Ora, alcuni avvertimenti. Questo mostrerà ciò che viene negoziato . Non ti dirà quando la negoziazione è fallita perché tu e il cliente non potreste essere d'accordo su un protocollo + suite, e non vi dirà quale protocollo + suite elencare i vostri clienti sono disposti a parlare. Conoscere quest'ultimo è molto importante quando stai pensando di aggiornare la configurazione del tuo server e vuoi sapere chi ti verrà bloccato.
Il primo può anche essere trovato nei log F5; cercare le stringhe "error" e "ssl_hs_ *" sulla stessa riga. Ecco un esempio:
01260009:7: Connection error: ssl_hs_rxv2hello:6934: unsupported version (40)
Per ottenere dettagli su ciò che i clienti sono disposti a parlare, devi andare oltre la F5 e catturare i pacchetti CLIENT_HELLO effettivi dal loro ingresso. E poi devi analizzarli. Sembra doloroso, ma è perché lo è. Puoi scrivere un filtro BPF per estrarre i pacchetti CLIENT_HELLO e puoi analizzare questi pacchetti in vari modi; Penso che l'ultima volta che ho dovuto farlo ho usato Scapy.
Leggi altre domande sui tag pci-dss