Archive

Posts Tagged ‘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 – 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…

WEB HACKING – Módulos y Librerias en servidores web Apache – MOD_SECURITY – Parte X

septiembre 25, 2012 1 comentario

MOD_SECURITY es una robusta librería que se encuentra disponible para servidores web Apache y que permite a un administrador, extender la seguridad del servidor con mecanismos adicionales incluidos en este módulo. Se encuentra dentro de la categoría de los WAF (Web Application Firewall) dado que contiene directivas que permiten detectar y filtrar ataques comunes contra la infraestructura de un servidor web. Una de las principales características de este módulo es su capacidad para capturar y analizar de forma dinámica el trafico HTTP, esto es una gran ventaja, dado que estas características le permiten monitorizar, registrar y controlar el acceso de todas las peticiones HTTP que son llevadas a cabo por los clientes, dándole paso a aquellas que son legitimas y filtrando aquellas que tienen altas probabilidades de no serlo. Este módulo es importante habilitarlo en servidores web ya que permite habilitar una capa extra de protección, sin embargo es también importante tener en cuenta que no puede proteger por completo un servidor web, ya que su contexto de ejecución esta limitado solamente a las aplicaciones web y hay mucho código (propio del servidor web) que se ejecuta antes de que MOD_SECURITY entre en acción.

Leer más…

WEB HACKING – Módulos y Librerias en servidores web Apache – MOD_REWRITE – Parte IX

septiembre 17, 2012 Deja un comentario

MOD_REWRITE es un potente módulo incluido en Apache que permite realizar un pre-procesamiento de las peticiones llevadas a cabo por los clientes que solicitan determinados recursos del servidor web. Su funcionamiento es sencillo, sin embargo dado que es bastante flexible, puede ser tan complejo como se desee/necesite. Lo que hace este módulo realmente es manipular las URL’s solicitadas por un cliente y realizar una redireccion interna a otro recurso, lo que significa que cuando un cliente ingresa una URL en su navegador, la página/recurso que esta solicitado simplemente es una “marca” para el servidor web que le indicará que debe realizar una redirección interna y servir un contenido determinado. Esto es útil en el sentido de que pueden escribirse URL’s amigables que son más fáciles de entender (y posiblemente de memorizar) para el usuario final. El mecanismo utilizado por este módulo para ejecutar las redirecciones internas es por medio del uso de la directiva RewriteRule y expresiones regulares que aplican sobre la URL solicitada por el cliente, de esta forma cada vez que una URL cumple alguna de las reglas definidas con esta directiva, se activa de forma automática la dirección a un recurso interno que también se define en la directiva anteriormente mencionada.

Leer más…

WEB HACKING – Módulos y Librerías en servidores web Apache – AMON y MOD_DEFLATE – Parte VIII

julio 30, 2012 Deja un comentario

Cuando se instala un servidor web Apache, es importante dedicar tiempo suficiente para realizar tareas de tunning y fortalecer la seguridad del servidor ante las múltiples amenazas que se encuentran en entornos poco fiables como internet. En este sentido, los módulos y las librerías que pueden ser instaladas, habilitadas y posteriormente configuradas representan una pieza fundamental en este puzzle de tener un servidor web en condiciones para atender usuarios de forma segura garantizando la confidencialidad e integridad de la información. En esta publicación se hablará un poco sobre la librería AMON.SO y el módulo MOD_DEFLATE, en próximas publicaciones se hablará sobre más librerías y módulos interesantes para Apache.

Leer más…

Seguir

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

Únete a otros 1.410 seguidores

A %d blogueros les gusta esto: