Con los servidores 7k plus en un entorno de carga equilibrada F5, ¿cuáles son algunos enfoques sugeridos para identificar el uso de SSL y el uso de TLS por debajo de 1.2?
Con los servidores 7k plus en un entorno de carga equilibrada F5, ¿cuáles son algunos enfoques sugeridos para identificar el uso de SSL y el uso de TLS por debajo de 1.2?
Hay MUCHAS maneras de obtener esta información.
Es importante probar activamente los servicios que se ejecutan en su red y no solo mirar información pasiva , ya que los cifrados negociados y en uso activo no representan todos los cifrados configurados para ser utilizados por el servicio que es lo que es realmente importante para evitar ataques de baja calificación.
La herramienta nmap tiene una secuencia de comandos llamada ssl-enum-ciphers que puede ayudar
nmap --script ssl-enum-ciphers -p 443 www.sitename.com
-p es para especificar el puerto 443 para https pero esto se puede usar en cualquier puerto. También puede probar enormes listas de IP en un solo comando, pero la siguiente es una prueba contra un puerto en una IP para simplificar el lector.
El resultado de este comando y la configuración de opciones es similar al siguiente:
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: los datos SSL también se mostrarán, simplemente no se configuraron en este servidor. También puede automatizar este script para que se ejecute a intervalos regulares e informar sobre hallazgos no conformes.
Si ya tiene un escáner de vulnerabilidades en este entorno, probablemente pueda obtener una lista muy similar a la que sugiere Trey. En Qualys, puede buscar el QID 38116 y produce una lista de versiones compatibles de SSL / TLS, así como conjuntos de cifrado para cada puerto escaneado.
Supongo que hay algo similar disponible con otros escáneres de vulnerabilidad (es decir, Nessus).
Supongo que está interesado en cuantificar los protocolos y cifrados TLS que utilizan sus clientes, para comprender y comunicar mejor el impacto de los cambios necesarios para retirar "TLS anticipado" según PCI.
En ese caso, estás tan con suerte. Puede registrar fácilmente los parámetros negociados de cada conexión utilizando una iRule como esta en cada F5 LTM virtual:
when CLIENTSSL_HANDSHAKE {
log local0. "protocol=[SSL::cipher version] cipher_suite=[SSL::cipher name]\
virtual=[virtual name] client_addr=[IP::client_addr]"
}
Lo que resultará en entradas de registro como esta:
protocol=TLSv1.2 cipher_suite=ECDHE-RSA-AES256-CBC-SHA virtual=/Common/mywebsrv client_addr=172.16.31.13
Esas entradas de registro van a / var / log / ltm en el F5 y se pueden reenviar a su SIEM para su agregación y análisis a través de syslog.
Una vez que haya estado logeando durante un tiempo, puede analizar los registros y determinar:
Ahora, algunas advertencias. Esto le mostrará lo que se negoció . No le dirá cuándo fracasó la negociación porque usted y el cliente no pudieron acordar un protocolo + suite, y no le dirán qué lista de protocolo + suite están dispuestos a hablar sus clientes. Saber lo último es muy importante cuando está pensando en actualizar la configuración de su servidor y quiere saber a quién bloqueará.
El primero también se puede encontrar en los registros F5; busque las cadenas "error" y "ssl_hs_ *" en la misma línea. Aquí hay un ejemplo:
01260009:7: Connection error: ssl_hs_rxv2hello:6934: unsupported version (40)
Para obtener detalles de lo que los clientes están dispuestos a hablar, debe ir más allá del F5 y capturar los paquetes CLIENT_HELLO reales del cable a medida que entran. Y luego debe analizarlos. Esto suena doloroso, pero eso es porque lo es. Puede escribir un filtro BPF para extraer los paquetes CLIENT_HELLO y puede analizar esos paquetes de varias maneras; Creo que la última vez que tuve que hacerlo utilicé scapy.
Lea otras preguntas en las etiquetas pci-dss