Autor: @RaulRenales
En episodios anteriores mostramos como obtener información
de la instalación de certificados SSL para habilitar la navegación segura.
Vimos cómo en algunos casos la nula o mala configuración de estos certificados
presenta vulnerabilidades graves y agujeros de seguridad.
En este post intentaremos hablar sobre la configuración de
estos certificados con el objetivo de obtener la calificación A+ de Qualys SSL
Labs.
Paso 1: Obtención de
los certificados. (Configuración básica)
Para la obtención de los certificados debemos o bien
autogenerarlos, o bien debemos adquirirlo en alguno de los proveedores
disponibles en internet. La oferta es muy variada y van desde precios muy
elevados a pocos euros dependiendo de la entidad certificadora que los otorga y
la calidad del certificado.
Nos centraremos en la compra de los certificados donde el
proveedor nos tiene que facilitar los siguientes archivos:
- www.dominio.com.key - es el fichero
con la Llave Privada que se ha usado para este certificado. Es privado y sólo
Apache debe de tener acceso.
- www.dominio.com.crt - es el fichero
con el Certificado SSL que queremos instalar en nuestro servidor web.
- ProveedorSSL-ca.crt - es el fichero
con el certificado de la autoridad certificadora (CA) que ha firmado el
certificado.
Paso 2: Configuración
básica de los certificados en el servidor.
Una vez subidos los archivos al servidor procedemos a la
configuración de los mismos en nuestro servidor.
Lo primero es dejar los archivos cada uno en su sitio:
- Copiamos www.dominio.com.key en
/etc/ssl/private
- Copiamos www.dominio.com.crt en
/etc/ssl/certs
- Copiamos ProveedorSSL-ca.crt en
/etc/ssl/certs
Ahora llega el momento de poner en marcha nuestro apache, lo
primero activar el módulo ssl, para ello accedemos a nuestro servidor y en la
consola habilitaremos el módulo con el siguiente comando:
sudo a2enmod ssl
Debemos asegurarnos de que el
archivo ssl.conf este bien configurado, podremos encontrarlo en la ruta:
/etc/apache2/mods-enabled/ssl.conf
Y deberíamos hacer que tuviera este aspecto añadiendo las rutas de nuestros certificados:
NameVirtualHost [Ip del
servidor]:443
< VirtualHost [Ip del
servidor]:443>
ServerSignature On
SSLCertificateFile /etc/ssl/certs/ www.dominio.com.crt
SSLCertificateKeyFile /etc/ssl/private/
www.dominio.com.key
SSLCertificateChainFile /etc/ssl/certs/
ProveedorSSL-ca.crt
SSLEngine On
Una vez con el material en su sitio comenzamos a configurar
la plantilla web que contiene los parámetros de navegación https, que podemos
encontrar en la siguiente dirección:
/etc/apache2/sites-available/default-ssl
Su configuración básica debería de tener un aspecto similar
a esto:
ServerName mysite.com:443
ServerAlias www.mysite.com
DocumentRoot /var/www/sitioseguro
Tras realizar cualquier cambio en estos archivos, ya sea en
el ssl.conf, como en el default-ssl debemos de reiniciar apache para recoger los
cambios:
#Comprobamos que las configuraciones realizadas son correctas
apache2ctl configtest
#Reiniciamos Apache2
sudo service apache2 restart
Hasta aquí lo que sería
una configuración muy básica de un servidor apache. Con ella
obtendremos una bonita F en el test de
Qualys. En el siguiente paso intentaremos subir nota y que no nos quede para
septiembre.
Paso 3: Mejorar la
configuración básica.
La idea principal de este punto
es mejorar la configuración de nuestro servidor Apache2 y conseguir una
seguridad más fuerte en el manejo de la navegación segura. Iré sugiriendo
algunas configuraciones o operaciones para mejorar los problemas concretos
detectados en estos casos.
Problema:
Heartbleed
Heartbleed es una vulnerabilidad
detectada en la versión 1.0.1f de OpenSSL, que permite a un atacante leer
la memoria de un servidor o un cliente,
permitiéndole por ejemplo, conseguir las claves privadas SSL de un servidor.
El único consejo que debemos dar
en este punto es actualizar la librería
OpenSSL y saltar la versión vulnerable. Para ello en nuestra consola
lanzaremos el siguiente comando:
sudo apt-get openssl update
o
sudo apt-get openssl upgrade
Problema:
SSL Compression (CRIME attack)
CRIME son las siglas de Compression
Ratio Info-leak Made Easy, un exploit que trabaja contra las cookies generadas
en las navegaciones HTTPS y SPDY que utilizan compresión de datos.
Básicamente, cuando recuperamos el contenido de las secret authentication
cookies se permite a un atacante obtener una sesión de usuario autenticado en
la web atacada.
Para realizar este hechizo, CRIME
utiliza SSL Compression como piedra angular con lo que puede ser muy
interesante que deshabilitemos esta funcionalidad de en nuestro módulo SSL.
A partir de la versión 2.2.24 de
Apache podemos incluir la siguiente línea en la configuración SSL para mitigar
el problema:
SSLCompression off
Para versiones anteriores a la 2.2.24 de Apache se recomienda compilar
OpenSSL sin soporte ZLIB. Con esto deshabilitamos el uso del método de
compresión.
Problema:
SSLv2 and SSLv3
La versión SSL v2 es insegura con
lo que lo más normal es que la tengamos deshabilitada en nuestro servidor,
además deshabilitaremos la versión SSLv3 para evitar que un atacante pueda
habilitarlo para deshabilitar el forward secrecy.
Además SSLv3 permite explotar el
bug de POODLE, con lo que esta es una muy buena razón para que deshabilitemos
esta versión.
De nuevo en nuestro archivo de
configuración del módulo SSL debemos incluir lo siguiente:
SSLProtocol All -SSLv2 -SSLv3
Problema: Poodle and TLS-FALLBACK-SCSV
Como hemos comentado en el punto
anterior SSLv3 permite la explotación del bug POODLE. Y como comentamos en el
punto anterior es razón suficiente para deshabilitar
esta versión.
Además, Google ha propuesto una
extensión para SSL/TLS llamada TLSFALLBACKCSV para prevenir el ataque de
downgrades de versiones forzados en SSL, esta extensión estará habilitada para
versiones recientes de OpenSSL.
Recomendación actualizar OpenSSL.
Problema: OpenSSL CCS vuln. (CVE-2014-0224)
ChangeCipherSpec, más conocido
por sus siglas CCS es una vulnerabilidad detectada en la librería OpenSSL en
junio de 2014. Para más información recomiendo leer este txt:
https://www.openssl.org/news/secadv/20140605.txt
La recomendación básica es
actualizar OpenSSL a la última versión.
Problema: OpenSSL
Padding Oracle vuln. (CVE-2016-2107)
Esta vulnerabilidad recientemente detectada abre la puerta a
un atacante para desencriptar el tráfico de una conexión que utiliza AES CBC y
está lanzándose en un servidor que soporta AES-NI
La manera más sencilla de
solucionar este punto es mediante la actualización a la última versión de la
librería OpenSSL.
Problema: OpenSSL OCSP Status Request extension unbounded memory growth
(CVE-2016-6304)
Importante vulnerabilidad detectada
en la extensión OCSP de OpenSSL mediante la cual se podría permitir el
agotamiento de la memoria del servidor provocando una denegación de servicio.
El atacante tan solo tendría que renegociar con esta extensión continuamente
hasta agotar la memoria del servidor, la mayoría de los servidores con
configuraciones por defecto son vulnerables a este ataque.
La solución a este problema es
actualizar OpenSSL
Más información: http://security.360.cn/cve/CVE-2016-6304/
Problema: The BEAST attack and RC4
The Beast attack es un ataque que
mediante la manipulación del algoritmo de encriptación CBC se puede desencriptar
parte del trafico encriptado. Para más detalles se recomienda visitar este
enlace:
Para configurar nuestro servidor
deberíamos incluir en nuestro archivo de configuración apache2.conf las
siguientes líneas:
SSLHonorCipherOrder On
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite RC4-SHA:HIGH:!MD5:!aNULL:!EDH:!ADH
SSLInsecureRenegotiation off
Problema: Fallos en SNI
SNI son las siglas de Server Name, es una extensión del protocolo TLS.1 Este indica qué nombre de host el cliente está intentando conectar antes de que el proceso de handshaking se complete. Esta funcionalidad permite a un servidor utilizar múltiples certificados en una misma dirección IP y número de puerto y permitir múltiples sitios seguros (HTTPS).
En ocasiones si tenemos mal configurado nuestro servidor los handshakes no se completan y se provocan rechazos a las llamadas de determinados user-agents.
Para tener correctamente configurado el servidor no debemos olvidar incluir en la configuración del template ssl el siguiente comando:
ServerName www.example.com
ServerAlias example.com www.example.com
Problema: supports weak Diffie-Hellman (DH)
El protocolo criptográfico Diffie-Hellman es un protocolo de establecimiento de claves entre partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autenticada).
Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión (establecer clave de sesión). Siendo no autenticado, sin embargo, provee las bases para varios protocolos autenticados.
En ocasiones este protocolo presenta deficiencias en su uso que podemos solventar con las siguientes configuraciones:
Cipher Suites
Debemos deshabilitar el soporte para SSLv2 y SSLv3 y habilitar el soporte para TLS, debemos modificar la configuración en el archivo apache2.conf o en el propio de SSL dejándolo de esta manera:
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
DH Parameters
En las últimas versiones de Apache (2.4.8 y superiores) y en OpenSSL 1.0.2 o superior se puede especificar los parámetros DH directamente, quedando de esta manera:
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"
Finalizando ...
Si se siguen estos pasos mejoraremos la seguridad de nuestro servidor y evitaremos algunos problemas. En el próximo post hablaré de cómo después de haber afinado el servidor y pasando los test con buena nota podemos joderla y tener un servidor inseguro.
