Archive

Posts Tagged ‘restricciones de seguridad apache’

Conceptos básicos de HSTS y configuración en Apache

febrero 19, 2015 1 comentario

HSTS o Http Strict Transport Security es un mecanismo que intenta mitigar los ataques de MITM sobre SSL obligando a los clientes a utilizar únicamente conexiones cifradas con TLS/SSL. Su funcionamiento no es demasiado complicado y aporta un mecanismo de defensa adicional que a día de hoy, es prácticamente imprescindible para mantener un buen nivel de seguridad en el canal de comunicación.
HSTS es un mecanismo que se encuentra soportado por los principales servidores web modernos, tales como Apache o NGNIX y además, navegadores a la altura de Firefox, Opera o Chrome soportan las cabeceras HTTP necesarias para obligar el uso de HSTS en el lado del cliente.
Si un servidor web soporta HSTS, todas las respuestas emitidas a los clientes contendrán la cabecera HTTP “Strict-Transport-Security”, lo cual le indica al cliente que todas las peticiones que se realicen contra el servidor web deben utilizar un certificado valido y todas las conexiones se deben realizar utilizando el protocolo HTTPS únicamente. El comportamiento de los clientes que soportan la política HSTS es bastante simple y muy efectivo ante ataques de MITM. En primer lugar, se encargan de cambiar el esquema “http://” por “https://” de todos los enlaces que hacen referencia al servidor web con HSTS y por otro lado, si la existe cualquier problema con el canal de comunicación, la comunicación es cortada automáticamente, como por ejemplo el caso típico en el que el certificado que se presenta al usuario es auto-firmado o de una identidad no verificada.
En este articulo se explicará cómo se puede habilitar HSTS en un servidor web Apache y se inspeccionarán las cabeceras de las peticiones enviadas por los clientes y las respuestas del servidor, de esta forma quedará mucho más claro el funcionamiento de HSTS en un servidor web.

Habilitando HSTS en Apache

Habilitar HSTS en un servidor web Apache es algo que inicialmente puede parecer trivial, ya que solamente es necesario cargar el módulo “headers” y utilizar la directiva “Header” con el valor HSTS correspondiente, sin embargo, algo que hay que tener presente es que los navegadores web ignoran la cabecera “Strict-Transport-Security” si no hace parte de una conexión HTTPS. Dicho de otra forma, si un cliente realiza una petición HTTP a un servidor y la respuesta de dicho servidor contiene la cabecera “Strict-Transport-Security”, dicha cabecera no tendrá ningún valor para el cliente y sera ignorada, ya que los navegadores deben recibir la cabecera “Strict-Transport-Security” en una conexión HTTPS para que la apliquen sobre el dominio en cuestión.

Dicho esto, queda claro que habilitar HSTS es solamente una pequeña parte de una configuración segura, ya que será necesario habilitar el módulo de SSL/TLS en un VirtualHost del servidor web. En un articulo de hace algún tiempo, ya hablaba sobre cómo hacer esto, así que te recomiendo visitar el siguiente enlace. El fichero de configuración completo, que se puede utilizar para habilitar HTTPS y HSTS puede ser la siguiente:

ServerAdmin debiadastra@thehackerway.comServerName Galileo:80

ServerRoot “/opt/httpd-2.4.10”

ErrorLog “logs/error_log”

LogLevel warn

Listen 80

Listen 443

LoadModule authz_core_module modules/mod_authz_core.so

LoadModule headers_module modules/mod_headers.so

LoadModule unixd_module modules/mod_unixd.so

LoadModule ssl_module modules/mod_ssl.so

<IfModule unixd_module>

User adastra

Group adastra

</IfModule>

<IfModule alias_module>

ScriptAlias /cgi-bin/ “/opt/httpd-2.4.10/cgi-bin/”

</IfModule>

<Directory “/opt/httpd-2.4.10/cgi-bin”>

AllowOverride None

Options None

Require all granted

</Directory>

<IfModule ssl_module>

SSLRandomSeed startup builtin

SSLRandomSeed connect builtin

</IfModule>

<VirtualHost *:443>

Header always set Strict-Transport-Security “max-age=63072000; includeSubDomains”

DocumentRoot “/opt/httpd-2.4.10/htdocs/hstsTesting”

SSLEngine on

<Directory /opt/httpd-2.4.10/htdocs/hstsTesting>

Options Indexes FollowSymLinks

SSLRequireSSL

</Directory>

SSLCertificateFile /opt/httpd-2.4.10/webserver.crt

SSLCertificateKeyFile /opt/httpd-2.4.10/webserver.key

<IfModule mime_module>

AddType application/x-x509-ca-cert .crt

AddType application/x-pkcs7-crl .crl

</IfModule>

</VirtualHost>

Si el usuario intenta visitar el servidor utilizando el protocolo HTTPS, verá la siguiente pantalla de error indicando que la conexión no es segura y por ese motivo se ha cancelado la navegación.

hsts1

El motivo de esto, es que los certificados utilizados por el servidor web no han sido emitidos por una CA de confianza para el cliente y dado que se ha indicado que la comunicación debe realizarse con HSTS, la comunicación entre el cliente y el supuesto servidor no puede continuar llevándose a cabo. Esto evita que se realicen ataques de “SSL Stripping” con herramientas tan conocidas como SSLStrip.

Esta configuración del lado del servidor es vital para mantener sitios web con un nivel de seguridad añadido. Por otro lado, desde el cliente también es posible habilitar este “opt-in” de seguridad para determinados dominios, de tal forma que aunque el servidor no incluya explícitamente la cabecera estándar HSTS, el navegador por si solo bloqueará cualquier intento de conexión no segura, evitando problemas con el canal de comunicación. Un buen ejemplo de configuración de HSTS en el lado del cliente se encuentra en el navegador Chrome, el cual permite gestionar dóminos personalizados que deben seguir la norma HSTS. Para entrar a esta interfaz de administración del navegador, es necesario ingresar a la siguiente ruta: chrome://net-internals/#hsts

Una vez allí, Chrome enseñará la interfaz que se puede ver en la siguiente imagen para la gestión de dominios con HSTS.

hsts2

Por otro lado, si la configuración anterior no se ha aplicado para un dominio concreto y aunque dicho dominio tenga HSTS habilitado, si las peticiones iniciales se realizan utilizando HTTP, aun cabe la posibilidad de utilizar una herramienta como “sslstrip” para realizar un ataque de “hijacking”. Por ejemplo, una configuración bastante común consiste en redireccionar todo el trafico por HTTP a HTTPS, es decir, en el caso que el usuario solicite el sitio web “http://example.com”, automáticamente se realizará la redirección a “https://example.com” y dado que la petición inicial ha sido utilizando HTTP, aun existe la posibilidad de llevar a cabo un ataque. Por este motivo, navegadores como Chrome y posteriormente otros como Firefox y Opera implementan un mecanismo conocido como “HSTS Preload List” o lista de dominios HSTS precargada. Dicho mecanismo, como su nombre lo indica, carga una lista de dominios que deben cumplir con la normativa HSTS en el momento en el que el navegador arranca, de esta forma si el usuario solicita el recurso “http://example.com” la comunicación automáticamente será cortada, obligando al usuario a ingresar en la versión segura con HTTPS. Para tener los valores adecuados en dicha lista, se utiliza un algoritmo de rastreo en busca de la cabecera HSTS en múltiples sitios en Internet, además, cualquiera puede enviar una solicitud para que su sitio web sea incluido en dicha lista (la cual es compartida entre Chrome, Safari y Firefox). Para realizar dicha solicitud, basta con ingresar el dominio en cuestión en el siguiente sitio: https://hstspreload.appspot.com/
Este articulo ha sido una introducción al funcionamiento de HSTS y en uno próximo, veremos en detalle el funcionamiento de “sslstrip2”.

Un Saludo y Happy Hack!

Adastra.

WEB HACKING – Módulos y Librerias en servidores web Apache – Uso de MOD_CACHE – Parte XVI

diciembre 18, 2012 Deja un comentario

Partiendo de la publicación anterior a está, intentaré profundizar un poco más sobre el uso del módulo MOD_CACHE haciendo uso de las directivas disponibles.

Más Directivas para controlar HTTP headers

Ademas las directivas que se han explicado en la anterior publicación existen algunas otras directivas bastante interesantes que permiten realizar operaciones muy concretas sobre algunos headers HTTP que suelen ser muy importantes no solo para las aplicaciones web, sino también para el funcionamiento de algunas características propias del servidor web.

Leer más…

WEB HACKING – Módulos y Librerias en servidores web Apache – Uso de MOD_CACHE – Parte XV

diciembre 4, 2012 2 comentarios

MOD_CACHE es un módulo del servidor web Apache que como casi todos los módulos existentes en este servidor web, existe para cubrir las funcionalidades definidas en los estándares en las múltiples RFC existentes, en este caso concreto MOD_CACHE intenta cubrir las especificaciones técnicas que se describen en la RFC 2616, la cual describe un amplio conjunto de funcionalidades para el protocolo HTTP 1.1, entre las que se incluyen, el uso de las caches y los mecanismos de control, definiendo que tipos de contenidos pueden ser “cacheables” y que tipo de elementos pueden almacenarse en dicha cache.

Leer más…

WEB HACKING – Módulos y Librerias en servidores web Apache – Usando MOD_PROXY – Parte XIV

noviembre 15, 2012 2 comentarios

Llegados a este punto, se han abarcado algunos de los módulos más interesantes que pueden utilizarse en un servidor web Apache, en esta ocasión se hablará sobre otro módulo que me parece muy útil e interesante, se trata de Mod_Proxy. Este módulo, tal como su nombre lo indica permite crear conexiones de tipo “proxy” esto quiere decir que una conexión entre dos entidades no se realiza de forma directa, sino que en su lugar hay un elemento intermedio por el que pasan todos los paquetes de datos. En algunas publicaciones anteriores en este blog, se ha hablado del uso de túneles SSH para la redirección del trafico entre distintas máquinas, existiendo túneles locales y remotos, pues la filosofía de Mod_Proxy es bastante similar, si bien no es tan robusto y potente como las mencionadas características de SSH, se trata de un módulo bastante útil en determinadas situaciones.

Leer más…

WEB HACKING – Módulos y Librerias en servidores web Apache – MOD_EVASIVE contra ataques DoS – Parte XIII

octubre 23, 2012 Deja un comentario

Actualmente, uno de los ataques más comunes y que prácticamente cualquier persona o grupo de personas puede llevar a cabo contra un sistema en internet, son los ataques de denegación de servicio (DoS) tanto desde una única ubicación (dirección IP) como desde múltiples ubicaciones (DDoS Distributed Denial Of Service), el objetivo obvio de este tipo de ataques, es interrumpir la actividad normal de un servidor durante un periodo de tiempo determinado o de forma indefinida. Se trata de un tipo de ataque que en la mayoría de los casos, solamente requiere “masa”, es decir, una gran cantidad de peticiones en intervalos de tiempo cortos contra un sistema determinado desde una o varias ubicaciones, normalmente los atacantes no necesitan tener conocimientos profundos sobre hacking (o informática general), es por este motivo que en los últimos años este tipo de ataques resultan tan frecuentes.

Leer más…

WEB HACKING – Módulos y Librerias en servidores web Apache – Reglas de OWASP para MOD_SECURITY – Parte XII

octubre 9, 2012 Deja un comentario

Después de haber leído las publicaciones anteriores sobre MOD_SECURITY, ya se contará con conocimientos suficientes para entender su funcionamiento y la potencia de las características que incluye, sin embargo no cabe duda que las características mas robustas en este módulo están relacionadas con el motor de reglas que es altamente personalizable. Como con cualquier Firewall de Aplicaciones, IDS o NIDS, las herramientas por si solas no proveen seguridad, es necesario implementar las reglas necesarias que dependen enteramente de las políticas de seguridad que se tengan, tal como se mencionaba hace algunos meses en las publicaciones relacionadas con SNORT, un IDS por si solo no puede hacer mucho ante diferentes tipos de ataques que se lleven a cabo en entornos de red, sin embargo su verdadera potencia radica en lo robustas que sean las reglas y las alarmas que se configuren sobre la herramienta. Estas mismas premisas que aplican en SNORT, también aplican en este caso a MOD_SECURITY, tener un buen conjunto de reglas es lo que hace que este módulo funcione realmente bien.

Leer más…

WEB HACKING – Módulos y Librerias en servidores web Apache – Motor de Reglas de MOD_SECURITY – Parte XI

octubre 2, 2012 Deja un comentario

En la publicación anterior a esta, se ha hablado sobre como configurar MOD_SECURITY en un servidor web Apache, así como también se ha hablado de como funciona este módulo y su ciclo de vida, en esta ocasión se hablará sobre más directivas interesantes y sobre como funciona el motor de reglas de MOD_SECURITY, de esta forma se tendrá una imagen mucho más clara del funcionamiento general de este módulo en servidores web Apache.

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.619 seguidores

A %d blogueros les gusta esto: