Cómo reparar la vulnerabilidad 'logjam' en Apache (httpd)

Recientemente, se ha publicado una nueva vulnerabilidad en Diffie-Hellman, conocida informalmente como 'logjam', para la cual se ha reunido esta página que sugiere cómo contrarrestar la vulnerabilidad:

Tenemos tres recomendaciones para implementar correctamente Diffie-Hellman para TLS:

Deshabilite Exportar conjuntos de cifrado. A pesar de que los navegadores modernos ya no admiten suites de exportación, los ataques FREAK y Logjam permiten que un atacante hombre en el medio engañe a los navegadores para que usen criptografía de grado de exportación, después de lo cual se puede descifrar la conexión TLS. Las cifras de exportación son un remanente de la política de la era de la década de 1990 que impidió que se exportaran protocolos criptográficos fuertes desde Estados Unidos. Ningún cliente moderno confía en las suites de exportación y hay pocas desventajas en deshabilitarlas.

Implementar (efímero) Curva elíptica Diffie-Hellman (ECDHE). El intercambio de claves Diffie-Hellman de curva elíptica (ECDH) evita todos los ataques criptoanalíticos factibles conocidos, y los navegadores web modernos ahora prefieren ECDHE sobre el campo finito original, Diffie-Hellman. Los algoritmos de registro discreto que utilizamos para atacar a los grupos Diffie-Hellman estándar no obtienen una ventaja tan fuerte de la precomputación, y los servidores individuales no necesitan generar curvas elípticas únicas.

Genera un grupo fuerte y único de Diffie Hellman . Millones de servidores utilizan unos pocos grupos fijos, lo que los convierte en un objetivo óptimo para la precomputación y el posible espionaje. Los administradores deben generar grupos únicos de Diffie-Hellman de 2048 bits o más fuertes utilizando primos "seguros" para cada sitio web o servidor.

¿Cuáles son los pasos de mejores prácticas que debo seguir para asegurar mi servidor según las recomendaciones anteriores?

— Christophe De Troyer
fuente

Relacionado: ¿Qué es Logjam y cómo lo evito?

— Restablece a Monica - M. Schröder

Respuestas:

Del artículo que vinculó , hay tres pasos recomendados para protegerse contra esta vulnerabilidad. En principio, estos pasos se aplican a cualquier software que pueda usar con SSL / TLS, pero aquí trataremos los pasos específicos para aplicarlos a Apache (httpd) ya que ese es el software en cuestión.

Desactivar Exportar conjuntos de cifrado

Tratemos los cambios de configuración que haremos en 2. a continuación ( !EXPORTcerca del final de la SSLCipherSuitelínea es cómo deshabilitaremos los conjuntos de cifrado de exportación)

Implementar (efímero) Curva elíptica Diffie-Hellman (ECDHE)

Para ello, es necesario editar algunos ajustes en los archivos de configuración de Apache - a saber SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderpara tener una configuración de "mejores prácticas". Algo como lo siguiente será suficiente:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Nota: en cuanto a qué SSLCipherSuiteconfiguración usar, esto siempre está cambiando, y es una buena idea consultar recursos como este para verificar la última configuración recomendada.

3. Genere un grupo fuerte y único de Diffie Hellman

Para hacerlo, puedes correr

openssl dhparam -out dhparams.pem 2048.

Tenga en cuenta que esto generará una carga significativa en el servidor mientras se generan los parámetros: siempre puede solucionar este problema potencial generando los parámetros en otra máquina y utilizando scpo similares para transferirlos al servidor en cuestión para su uso.

Para usar estos recientemente generados dhparamsen Apache, desde la Documentación de Apache :

Para generar parámetros DH personalizados, use el comando openssl dhparam. Alternativamente, puede agregar los siguientes parámetros DH estándar de 1024 bits desde RFC 2409, sección 6.2 al archivo SSLCertificateFile respectivo :

(énfasis mío)

que luego es seguido por un parámetro DH estándar de 1024 bits. A partir de esto, podemos inferir que los parámetros DH generados a medida pueden simplemente agregarse a los relevantes SSLCertificateFileen cuestión.

Para hacerlo, ejecute algo similar a lo siguiente:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Alternativamente, según la subsección de Apache del artículo que vinculó originalmente, también puede especificar el archivo dhparams personalizado que ha creado si prefiere no alterar el archivo de certificado en sí mismo, por lo tanto:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

en cualquier configuración de Apache que sea relevante para su implementación particular de SSL / TLS, generalmente en conf.d/ssl.confo conf.d/vhosts.confpero esto diferirá dependiendo de cómo haya configurado Apache.

Vale la pena señalar que, según este enlace ,

Antes de Apache 2.4.7, el parámetro DH siempre se establece en 1024 bits y no es configurable por el usuario. Esto se ha solucionado en mod_ssl 2.4.7 que Red Hat ha incorporado en su distribución RHEL 6 Apache 2.2 con httpd-2.2.15-32.el6

En Debian Wheezy, actualice apache2 a 2.2.22-13 + deb7u4 o posterior y openssl a 1.0.1e-2 + deb7u17. El SSLCipherSuite anterior no funciona perfectamente, en su lugar use lo siguiente según este blog :

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Debe verificar si su versión de Apache es posterior a estos números de versión dependiendo de su distribución, y si no, actualícela si es posible.

Una vez que haya realizado los pasos anteriores para actualizar su configuración y reiniciado el servicio Apache para aplicar los cambios, debe verificar que la configuración sea la deseada al ejecutar las pruebas en SSLLabs y en el artículo relacionado con esta vulnerabilidad en particular.

— BE77Y
fuente

En cuanto a la carga puesta en el servidor al generar los parámetros, siempre puede generarlos en otra máquina y simplemente scp o incluso copiar y pegar el archivo en el servidor de destino. No es necesario generar los parámetros en el servidor de producción.

— Erathiel

Después de que haya cambiado su configuración, es posible que desee realizar una verificación en SSLLabs.com también para asegurarse.

— user2428118

¿Hay alguna manera de corregir esta vulnerabilidad en Apache / 2.2.22 (Ubuntu 12.04)? Agregué dhparams.pem a certificate.crt pero weakdh.org/sysadmin.html aún se queja

— tersmitten

@tersmitten Esa es una pregunta completamente diferente a esta.

— Michael Hampton

siempre puede ejecutar la generación de claves mediante un comando 'agradable'. así que puedes ponerlo como: nice 19 openssl dhparam -out dhparams.pem 2048. Esto funcionará más tiempo, pero solo consumirá tiempo de CPU no utilizado.

— Znik

Basado en un parche de Winni Neessen, publiqué una solución para Apache / 2.2.22 (Debian Wheezy, quizás también utilizable en Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . para tu retroalimentación.

— Flo
fuente

Esto es más un hackeo que una solución. poner un nginx reciente frente a su apache como proxy inverso sería mucho más fácil, y uno no confía en un apache de terceros.

— Ese tipo de allá

¿Por qué deberíamos confiar en estos binarios?

— un CVn

No tienes que confiar en los binarios; puede recompilar apache2.2.x usted mismo muy fácilmente siguiendo los pasos explicados si se toma el tiempo. Además, esto aumentaría su seguridad, porque su configuración tiene claves primarias únicas.

— Flo

Sugeriría que la gente no se queje de los parches que solucionan un problema en un software de código abierto.

— Florian Heigl

@FlorianHeigl Ni siquiera estoy seguro de qué hacer con ese comentario ...

— BE77Y

-7

En lugar de seguir la ruta compleja de los 'hacks' anteriores, considere cambiar a nginx como su principal software de servidor web (no solo el almacenamiento en caché o el proxy). Obviamente, parece más a la altura de los estándares actuales, en cuanto a seguridad, que los viejos motores apache. Al usar el repositorio nginx, le brinda un motor web estable más actualizado que apache.

Me cambié por completo. Me ahorró una gran cantidad de tiempo de resolución de problemas con respecto a TLS y, para nuestras configuraciones, también liberó una gran cantidad de RAM al mismo tiempo. De hecho, encontré el empleo de nginx refrescantemente simple y directo, en comparación con la gran cantidad de complicaciones de configuración de httpd / apache a las que me había acostumbrado. Podría ser una cuestión de gustos, me había vuelto bastante fluido en httpd / apache rewrite / config / maintenance antes de convertirme, y fue más fácil de lo que temía. Hay información reciente apropiada sobre la configuración de nginx disponible en línea, y su base de usuarios es enorme, muy activa y amigable con el soporte. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

— Julius
fuente

La configuración de nginx para permitir las cifras de exportación sería exactamente tan vulnerable al ataque de Logjam como la configuración de un servidor Apache para permitir las cifras de exportación. Además, la pregunta pide soluciones en Apache.

— un CVn el

En realidad, la solución: cambiar a una distribución que proporcione paquetes más actualizados para el software donde absolutamente necesita una versión más nueva (no solo correcciones de errores retroportadas, como es el caso de Debian o CentOS), o compile paquetes usted mismo desde la fuente (no es difícil) e instálelos usando el administrador de paquetes, o la instalación antigua simple desde el código fuente (tampoco es difícil, pero requiere un poco más de trabajo para administrar). Para una pregunta que pregunta "¿cómo mitigar la vulnerabilidad X dentro del software Y?", Una respuesta que dice "reemplazar el software Y con el software Z" a menudo no es una respuesta útil.

— un CVn

Apache to Nginx no es una actualización, es un reemplazo. El backporting es una posibilidad. Si tiene mucho trabajo invertido en la solución Apache, desecharlo por completo y reemplazarlo por otra cosa también requiere mucho trabajo. Y esta pregunta todavía se trata de soluciones centradas en Apache , no en Nginx. No voy a pasar más tiempo discutiendo sobre esto; cuando publique respuestas, asegúrese de que respondan la pregunta tal como se le pregunta en la parte superior de la página. Si desea publicar una respuesta alentando a las personas a cambiar de Apache a Nginx, hágalo, pero a una pregunta que permita Nginx.

— un CVn

Entonces, ¿configurar correctamente un software para que sea seguro contra ataques conocidos es "una ruta compleja de piratería"? Obtengo A + en ssllabs.com con una configuración simple de apache, solo tienes que tomarte tu tiempo e investigar un poco para comprender cómo configurar correctamente el software que estás utilizando, no hacks aquí ...

— Chazy Chaz

@Julius: es probable que los votos negativos tengan más que ver con la falta de valor en su respuesta con respecto a la pregunta formulada, que cualquier "agenda" oculta que la gente aparentemente pueda tener contra nginx vs apache. Resulta que uso exclusivamente nginx debido a mi preferencia, pero fui yo quien respondió esta pregunta. "Cambiar a otro software" no es una respuesta aceptable a "cómo solucionar (cualquier problema)". Sin mencionar que también se perdió por completo el punto de la vulnerabilidad real: fue en el intercambio de claves de diffie-hellman, no apache (o nginx, o sshd, o ...)

— BE77Y