Corrección de una vulnerabilidad OpenSSL en el firewall

Question

Corrección de una vulnerabilidad OpenSSL en el firewall

#1 de gowenfawr (4 votos)

2

Hicimos una prueba de Qualys en dos de nuestras URL más temprano hoy. Las URL son de dos aplicaciones similares (las mismas versiones) alojadas en servidores idénticos ubicados en dos centros de datos diferentes. La prueba devolvió 'A-' para uno y 'F' para el otro. El motivo de la calificación 'F' se dio como:

Este servidor es vulnerable a la vulnerabilidad de Oracle OpenSSL Padding (CVE-2016-2107) e inseguro. Grado establecido en F.

Sin embargo, la versión de OpenSSL que tenemos en ambos servidores es antigua e idéntica:

[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

¿Por qué la prueba de Qualys no identificó la vulnerabilidad en el servidor que dio 'A-' aunque está ejecutando una versión vulnerable de OpenSSL como la otra? ¿Es la vulnerabilidad de OpenSSL Padding Oracle algo que puede solucionarse a nivel de firewall? Sospecho que el servidor de seguridad en el servidor que recibió la 'A-' tuvo éxito al filtrar el paquete que intentaba probar esta vulnerabilidad. Estoy en lo cierto ¿Es esto algo que se puede arreglar a nivel de firewall? (Dado que ambos servidores web están ubicados en diferentes centros de datos y detrás de diferentes cortafuegos)

firewalls openssl

pregunta Sree 13.03.2017 - 13:17

fuente

1 respuesta

Lea otras preguntas en las etiquetas firewalls openssl

vulnerabilidad de inyección de URL ¿Dónde está ubicado el certificado BurpSuite CA HTTPS?

score 4 · Accepted Answer

¿Es OpenSSL Padding la vulnerabilidad de Oracle algo que se puede arreglar? el nivel de firewall? Sospecho que el firewall en el servidor que recibió la 'A-' tuvo éxito en filtrar el paquete que intentaba prueba esta vulnerabilidad. Estoy en lo cierto Es esto algo que puede ser arreglado en el nivel de firewall?

No. Los protocolos SSL / TLS tienen protecciones contra manipulación indebida; Si, por ejemplo, el cortafuegos alterara alguno de los apretones de manos, el apretón de manos fallaría porque ambas partes validan que lo que enviaron fue lo que vio el otro lado.

Otras configuraciones pueden protegerte. Si tenía un descargador de SSL o un proxy de hombre en el medio, algo que terminó y luego volvió a abrir las conexiones para que tenga conexiones # 1 y # 2:

[Servidor] < --- 1 --- > [Proxy] < --- 2 --- > [Escáner]

Entonces eso lo haría, porque la biblioteca SSL vulnerable en el servidor no está siendo tocada por el escáner.

Sin embargo, la versión de OpenSSL que tenemos en ambos servidores es antigua e idéntico:
[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

Y viejo. Esa versión está reemplazada por openssl-1.0.1e-48.el6_8.4.x86_64.rpm . Recomendaría actualizarlo en ambos lugares y ver si eso hace que desaparezca. Reinicie sus servicios después de actualizar, por supuesto.

Tenga en cuenta que no he abordado realmente la pregunta raíz de "¿Por qué dos servidores con las mismas bibliotecas dan resultados diferentes?" Eso es porque realmente no hay suficiente información para contar. ¿Son iguales los demonios del servidor en ambos hosts? ¿Podría uno estar usando diferentes bibliotecas SSL? ¿Ejerció el escáner el mismo nivel de prueba contra ambos? ¿Cuántas veces has escaneado cada host? ¿Son los resultados sólidamente consistentes?

Con todo lo desconocido, y dado que está ejecutando una versión obsoleta de OpenSSL, mi recomendación es parchear y probar nuevamente.