28 Ago 2016

Fortificar SSL/TLS en Servidores Web Apache

por | publicado en: Apache, Criptografía, Seguridad, Servicios de Red, SSL/TLS | 0
 
 

Índice General

  1. ¿Por qué fortificar SSL?
  2. Acciones recomendables para la fortificación

Enlaces externos
 

  1. ¿Por qué fortificar SSL? (Volver al índice General)
    SSL es un protocolo criptográfico que proporciona confidencialidad e integridad en las comunicaciones de datos. La evolución de SSL es TLS con múltiples mejoras.

    La implementación de SSL/TLS en nuestro sitio web seguro no es sinónimo de invulnerabilidad en cuestiones de seguridad. Por ello, en este artículo, intentaremos fortificar nuestro sitio web seguro contra vulnerabilidades que afectan a estos protocolos.

    Ataques del tipo CRIME, BEAST, BREACH, POODLE, FREAK, Heartbleed, Logjam, etc. nos recuerdan la necesidad de fortificar nuestro sitio web seguro para suavizar la acción de dichos ataques.

    2.  

  2. Acciones recomendables para la fortificación (Volver al índice General)

    • Actualizar a la versión más reciente de SSL o TLS (Volver al índice General)
      Actualizar a la versión más reciente todos los componentes de SSL o TLS, en este caso, el paquete OpenSSL. En concreto para aquellas versiones de OpenSSL que van desde la 1.0.1 hasta la 1.0.1f (inclusive), afectadas por la vulnerabilidad Heartbleed

      En sistemas basados en paquetes deb (Debian, Ubuntu, etc.)
      En estos sistemas, con el paquete OpenSSL ya instalado, realizar los siguientes pasos:

      1. Actualizar los repositorios con el siguiente comando: 
        $ sudo apt-get update
      2. Actualizar los paquetes con el siguiente comando: 
        $ sudo apt-get upgrade

      Si OpenSSL no está instalado en nuestro sistema, para instalarlo, primero ejecutar las dos órdenes anteriores para actualizar el sistema, y luego instalar el paquete ejecutando el siguiente comando:

      $ sudo apt-get install openssl

      En sistemas basados en paquetes rpm (CentOS, Fedora, Redhat, etc.)
      En estos sistemas, con el paquete OpenSSL ya instalado, ejecutar el siguiente comando:

      $ sudo yum -y install openssl

      Si OpenSSL no está instalado en nuestro sistema, para instalarlo, ejecutar el siguiente comando:

      $ sudo yum install openssl

      Tras la instalación o actualización
      Una vez instalado o actualizado el paquete OpenSSL podemos comprobar que todo ha ido bien, ejecutando siguiente comando:

      $ sudo openssl version -a

      •  

    • Eliminar uso de cifrados obsoletos (Volver al índice General)
      SSLv2 es inseguro y SSLv3 permite explotar el ataque POODLE. Por lo tanto, permitiremos el uso de todos los cifrados excepto SSLv2 y SSLv3 con la siguiente directiva:

      SSLProtocol All -SSLv2 -SSLv3

      All hace referecia a +SSLv2 +SSLv3 +TLSv1 o cuando se usa OpenSSL 1.0.1 o posterior a +SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2.

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3</virtualhost>
...

    • Deshabilitar compresión SSL (Ataque CRIME) (Volver al índice General)
      El ataque CRIME gira en torno a la fuga de información cuando los datos se comprimen antes de ser cifrados. La forma más sencilla de mitigar este ataque consiste en deshabilitar la compresión SSL.

      SSLCompression off

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11
12

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3
    SSLCompression off</virtualhost>
...

    • Cipher Suite (Volver al índice General)
      Forzar el orden de preferencia establecido por el servidor: Normalmente se usa el orden de preferencias de cifrado del cliente. Si la directiva SSLHonorCipherOrder está activa, se usará el orden de preferencia establecido por el servidor.

      SSLHonorCipherOrder on

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11
12
13

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3
    SSLCompression off
    SSLHonorCipherOrder on</virtualhost>
...

      Forzar el uso de algoritmos seguros: Esto tiene la ventaja de permitir Perfect Forward Secrecy (PFS).
      La configuración recomendada por Fundación Mozilla para servicios que no necesitan compatibilidad regresiva es la siguiente:

      SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

      Esta configuración es compatible con navegadores como Firefox 27, Chrome 30, IE 11 en Windows 7, Edge, Opera 17, Safari 9, Android 5.0, y Java 8.

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3
    SSLCompression off
    SSLHonorCipherOrder on
    SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"</virtualhost>
...

      La configuración recomendada por Fundación Mozilla para servicios que no necesitan compatibilidad con clientes antiguos es la siguiente:

      SSLCipherSuite "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"

      Esta configuración es compatible con navegadores como Firefox 1, Chrome 1, IE 7, Opera 5 y Safari 1.

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3
    SSLCompression off
    SSLHonorCipherOrder on
    SSLCipherSuite "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"</virtualhost>
...

       

       
       
      Lógica de priorización (Volver al índice General)

      • ECDHE+AESGCM cifrados que se seleccionan primero. Son cifrados de TLS 1.2. Actualmente no se conoce ningún ataque a estos cifrados.
      • Perfect Forward Secrecy (PFS) Cipher Suites se prefieren ECDHE primero y luego DHE.
      • AES 128 es preferido a AES 256. Ha habido discusiones sobre si la seguridad extra de AES256 ha valido su coste, y el resultado dista de ser evidente. Por el momento, el preferido es AES128 porque ofrece buena seguridad, es realmente rápido y parece ser más resistente a ataques de sincronización.
      • En las Cipher Suites con compatibilidad regresiva, se prefiere AES a 3DES. Los ataques BEAST contra AES son mitigados en TLS 1.1 y versiones superiores, difícil de conseguir en TLS 1.0. En las Cipher Suites sin compatibilidad regresiva, 3DES no se incluye.
      • RC4 se ha eliminado por completo. Se usa 3DES para la compatibilidad regresiva.

       
      Descartes obligatorios (Volver al índice General)

      • aNULL contiene claves de intercambio no autenticadas Diffie-Hellman que son objeto de ataques Man In The Middle (MitM).
      • eNULL contiene cifrado nulo (texto no cifrado).
      • EXPORT son cifrados débiles heredados que fueron marcadas como exportables por la ley Estadounidense.
      • RC4 contiene cifrados que utilizan el obsoleto algoritmo ARCFOUR.
      • DES contiene cifrados que utilizan el obsoleto algoritmo Data Encryption Standard (DES).
      • SSLv2 contiene todos los cifrados que se definieron en la vieja versión del estándar SSL, ahora obsoleto.
      • MD5 contiene todos los cifrados que utilizan el obsoleto Message Digest 5 (MD5) como algoritmo de resumen

       
      Descartes obligatorios recomendados (Volver al índice General)
      Se aconseja añadir a la directiva SSLCipherSuite los siguientes descartes:

      • !EXPORT. Evita la exportación de suites de cifrado. Esta contramedida sirve para minimizar el impacto de ataques tales como FREAK, Logjam.
      • !RC4. Deshabilitando RC4 los usuarios con navegadores como IE en Windows XP usarán 3DES en su lugar. 3DES es más seguro que RC4. Si que es verdad que RC4 mitiga el ataque BEAST pero los defectos en RC4 superan significativamente los riesgos de sufrir un ataque BEAST
      • Además sería conveniente añadir los descartes !aNULL, !eNULL, !DES, !MD5 y !PSK

       
      Nuestra directiva SSLCipherSuite quedaría como sigue:

      SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3
    SSLCompression off
    SSLHonorCipherOrder on
    SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"</virtualhost>
...

      •  

    • HTTP Strict Transport Security (HSTS) (Volver al índice General)
      Desde que Google anuncio que los sitios web que no están empleando conexiones cifradas pueden verse desplazados en el ranking de resultados o posicionamiento en Internet, son cada vez son más los sitios web que utilizan únicamente HTTPS.

      Para conseguir que nuestro sitio web sirva únicamente HTTPS, deberemos redirigir todas las conexiones HTTP a HTTPS, pero esa redirección puede ser vulnerable a un ataque Man In The Middle (MiTM). Con HSTS podremos evitarlo en gran medida.

      Esta configuración en el servidor instruye a los navegadores, inyectándoles una cabecera, para que sólo hagan conexiones HTTPS al servidor web.

      Para su implementación HSTS necesita que Apache tenga habilitado el módulo headers.

      En primer lugar, comprobamos si el módulo headers está habilitado ejecutando el siguiente comando:

      $ sudo apache2ctl -M |grep headers
Syntax OK
 headers_module (shared)

      El comando anterior comprueba la sintaxis de los archivos de configuración de apache, nos presenta los módulos habilitados y si estos son estáticos o compartidos. En este caso, el resultado nos indica que el módulo compartido headers está habilitado.

      En caso de no estar habilitado el módulo, ejecutaremos el comando siguiente para habilitarlo:

      $ sudo a2enmod headers

      Una vez habilitado el módulo, modificaremos el archivo de configuración de nuestro sitio seguro añadiendo las siguientes líneas:

      <ifmodule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</ifmodule>

      Esta cabecera forzará a almacenar la directiva en el navegador durante 1 año (max-age es la cantidad de tiempo en segundos para que el navegador continúe solicitando este recurso sólo en HTTPS) y afecta a todos los subdominios del dominio (includeSubDomains).
      HSTS tiene una debilidad, la primera vez que el navegador se conecta aún no tiene la directiva almacenada para cada dominio. En esa primera vez el proceso es vulnerable. Para solventarlo, mediante la opción preload, consentimos que los navegadores pre-carguen nuestro dominio.

      El fichero de configuración de la parte segura de nuestro servidor, contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

      ...
NameVirtualHost *:443
<virtualhost *:443>
    ServerName www.zeppelinux.es
    ServerAdmin webadmin@zeppelinux.es
    <ifmodule mod_headers.c>        Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"    </ifmodule>    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado/www.zeppelinux.es.cert"
    SSLCertificateKeyFile "/ruta/al/certificado/www.zeppelinux.es.key"
    SSLProtocol All -SSLv2 -SSLv3
    SSLCompression off
    SSLHonorCipherOrder on
    SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
</virtualhost>
...

      Además, habrá que redirigir todas las peticiones HTTP a HTTPS.
      Una forma sencilla sería editando nuestro archivo de configuración de nuestro sitio por defecto, por ejemplo, /etc/apache2/sites-available/default y añadir la siguiente línea:

      Redirect permanent / https://www.zeppelinux.es/

      El fichero de configuración de nuestro sitio por defecto contendría algo parecido a esto:

      1
2
3
4
5
6
7
8
9
10
11

      ...
NameVirtualHost *:80
<virtualhost *:80>
	ServerName www.zeppelinux.es
	ServerAdmin webadmin@zeppelinux.es
 
	## Redirigir http a https
	Redirect permanent / https://www.zeppelinux.es/...
</virtualhost>
...

      Podríamos utilizar RewriteRule, pero debido a los comentarios existentes, creo que no es una buena idea.

      •  

    • Para terminar (Volver al índice General)
      Si has aplicado las líneas más arriba indicadas en los respectivos archivos de configuración de Apache, deberás en primer lugar comprobar si la sintaxis es correcta con el comando:

      $ sudo apache2ctl -t

      Si la sintaxie es correcta, reincia Apache para que surtan efectos los cambios:

      $ sudo service apache2 restart

      o también:

      $ sudo /etc/init.d/apache2 restart

      o si tu sistema utiliza systemd, reinicia Apache con el siguiente comando:

      $ sudo systemctl restart apache2.service

 
Enlaces externos (Volver al índice General)

 

Espero que este artículo os haya sido de utilidad. Si pensáis que podéis colaborar para mejorar este artículo, que hay algo erróneo en él o simplemente deseáis comentarlo, por favor, dejad vuestra opinión más abajo.
 
Seguir J. Carlos:

Técnico Informático - Desarrollo Web - Administración de Redes

Técnico Informático. Desarrollo Web. Administración de redes.

Últimas publicaciones de

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.