☰

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

tag-icon • tag-icon apache-2.2 ssl apache-2.4 httpd vulnerability
Cómo solucionar la vulnerabilidad 'logjam' en Apache (httpd)

Recientemente se ha publicado una nueva vulnerabilidad en Diffie-Hellman, denominada informalmente 'logjam', por la cualesta páginase ha elaborado sugiriendo cómo contrarrestar la vulnerabilidad:

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

  1. Deshabilite Exportar conjuntos de cifrado.Aunque los navegadores modernos ya no admiten suites de exportación, los ataques FREAK y Logjam permiten que un atacante intermediario engañe a los navegadores para que utilicen criptografía de grado de exportación, después de lo cual se puede descifrar la conexión TLS. Los cifrados de exportación son un vestigio de la política de la década de 1990 que impedía la exportación de protocolos criptográficos sólidos desde Estados Unidos. Ningún cliente moderno depende de las suites de exportación y deshabilitarlas tiene pocas desventajas.
  2. Implementación (efímera) de curva elíptica Diffie-Hellman (ECDHE).El intercambio de claves Elliptic-Curve Diffie-Hellman (ECDH) evita todos los ataques criptoanalíticos viables conocidos, y los navegadores web modernos ahora prefieren ECDHE al campo finito original, Diffie-Hellman. Los algoritmos de registro discreto que utilizamos para atacar los grupos Diffie-Hellman estándar no obtienen una ventaja tan importante del cálculo previo, y los servidores individuales no necesitan generar curvas elípticas únicas.
  3. Generar un grupo Diffie Hellman fuerte y único. Millones de servidores utilizan unos pocos grupos fijos, lo que los convierte en un objetivo óptimo para el cálculo previo y posibles escuchas ilegales. Los administradores deben generar grupos Diffie-Hellman únicos, de 2048 bits o más potentes, utilizando números primos "seguros" para cada sitio web o servidor.

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

Respuesta1

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

  1. Deshabilitar exportar conjuntos de cifrado

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

  1. Implementación (efímera) de curva elíptica Diffie-Hellman (ECDHE)

Para esto, necesita editar algunas configuraciones en sus archivos de configuración de Apache, es decir 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 utilizar, esto siempre cambia y es una buena idea consultar recursos comoÉstepara comprobar la última configuración recomendada.

3. Generar un grupo Diffie Hellman fuerte y único

Para hacerlo, puedes ejecutar

openssl dhparam -out dhparams.pem 2048.

Tenga en cuenta que esto supondrá 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 usando scpo similar para transferirlos al servidor en cuestión para su uso.

Para utilizar estos recién generados dhparamsen Apache, desde elDocumentación de Apache:

Para generar parámetros DH personalizados, utilice el comando openssl dhparam. Alternativamente, puedesanexar lo siguienteParámetros DH estándar de 1024 bits de RFC 2409, sección 6.2al archivo SSLCertificateFile respectivo:

(el énfasis es mío)

que luego es seguido por un parámetro DH estándar de 1024 bits. De esto podemos inferir que los parámetros DH generados de forma personalizada 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 elsubsección apachedel artículo que vinculó originalmente, también puede especificar el archivo dhparams personalizado que ha creado si prefiere no alterar el archivo del certificado, de esta manera:

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

en cualquier configuración de Apache que sea relevante para su implementación SSL/TLS particular; 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úneste enlace,

Antes de Apache 2.4.7, el parámetro DH siempre estaba establecido en 1024 bits y no es configurable por el usuario. Esto se ha solucionado en mod_ssl 2.4.7 que Red Hat ha adaptado a 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, utilice lo siguiente segúneste 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, de lo contrario, actualizarla si es posible.

Una vez que haya realizado los pasos anteriores para actualizar su configuración y haya reiniciado el servicio Apache para aplicar los cambios, debe verificar que la configuración sea la deseada ejecutando las pruebas enSSLLabsy enel artículorelacionados con esta vulnerabilidad particular.

Respuesta2

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

Respuesta3

En lugar de seguir el complejo camino de los 'trucos' anteriores, considerecambiando a nginxcomo su software de servidor web principal (no solo almacenamiento en caché o proxy). Obviamente, parece estar más a la altura de los estándares actuales, en cuanto a seguridad, que los viejos motores Apache. Al utilizar el repositorio nginx, le brinda un motor de servidor web estable mucho más actualizado que Apache.

Cambié por completo. Me ahorró mucho tiempo resolviendo problemas relacionados con TLS y, para nuestras configuraciones, también liberó una gran cantidad de RAM al mismo tiempo. De hecho, el uso de nginx me pareció 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, había adquirido bastante fluidez 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. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

información relacionada