WINTXCODERS Terminal
[visitante@wintxcoders-pc ~]:$ Bienvenido a la comunidad
Recuerda que puedes participar en nuestra comunidad registrándote

Mitigar ataques MITM en un servidor Apache

Iniciado por Ruler, Marzo 03, 2015, 03:54:53 AM

« anterior - próximo »

Ruler

Visitante

  • Desconectado
  • Holaamigos, saben que a mi me fascina la seguridad y he aqui otro tutorial de como montar en apache la seguridad ante ataques a los protocolos de seguridad:

    Http Strict Transport Security o por sus siglas en ingles (HSTS) es un sistema o mecanismo que intenta miticar los ataques MITM ( Hombre en medio) que hace unos días explique, pero solo que esto va sobre SSL ( Secure Sockets Layer ) obligando a los usuariosa utilizar únicamente conexiones cifradas con TLS/SSL, el funcionamiento de este no es muy complicado y nos aporta un mecanismo de seguridad adicional que hoy en dia es indispensable para que nuestras redes tengan un buen mecanismo de seguridad, y nuestras comunicaciones no sean interceptadas.
    HTST Es un mecanismo que esta soportado por todos los servidores web modernos ( O la mayoria) , tales como Apache o Ngix y casi todos los navegadores de talla internaciónal como Firefox, Opera o chrome ( Aqui inicia la discriminación de IE ), ellos soportan las cabeceras HTTP necesarias para que se obligue el uso de HSTS en el lado del cliente.

    Si un servidor 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 ingresen se envien por protocolo seguro y utilizando un certificado valido, todas las conecciones se relizaran solamente utilizando el protocolo HTTPS,  el comportamiento de los clientes que utilicen y permitan la politica HSTS es extremadamente simple, y muy efectivo contra ataques de MITM.

    En primer lugar, se encargará de cambiar el protocolo HTTP ( Protocolo de hiper transferencia de texto ) Por HTTPS ( Protocolo de Hiper Transferencia de texto Segura ), de todos los enlaces que hagan referencia al sevidor web con HSTS, si existe algún problema de comunciación en el canal, la comunicación es cortada automaticamente, Ejemplo:

    El certificado que presenta al usuario es auto-firmado o de una entidad no verificable las comunicaciones son cortadas

    Yo les voy a explicar como pueden tener HSTS en un servidor web que tenga Apache y se inspeccionarán las cabeceras de las peticiones enviadas por los usuarios, y las respuestas que el servidor devuelve, así quedara mucho mas claro el funcionamiento de HSTS en un servidor Web

    Habilitando HSTS en Apache

    Activar HSTS en un servidor con Apache es algo que puede parecer un poco gracioso, ya que solamente es necesario subir el modulo de Headers y utilizar la directiva Header con el valor de HSTS correspondiente, pero no olvidemos que los navefadores web ignoral la cabecera HSTS si no se involucra en una coneccion HTTPS, o si lo decimos de otra forma, si un usuario realiza una peticion por el puerto 80 o bien HTTP que es lo mismo a un servidor, la respuesta de el servidor contiene la cabecera HSTS, esta cabecera no tiene ningun valor para el usuario y será ignorada, por que los navegadores deben recibir la cabecera HSTS en una coneccion SSL o HTTPS para que aplique sobre el dominio que lo contiene.

    Ya leído lo anterior supongo que tiene que quedar muy claro que habilitar HSTS es solamente una pequeña parte de una configuración segura, ya que es necesario habilitar el modulo de SSL/TLS en un VirtualHost  en el servidor web o en caso de usar cPanel se tienen que llevar a cabo muchos pasos eso lo explicare otro día,  a continuación les compartire el archivo de configuracion de un servidor que utilizo para pruebas:


    ServerAdmin [email protected]
    ServerName PruebasRul: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 sitio usando el protocolo https con el archivo de configuracion anterior, vera la siguiente pantalla ya que el certificado no es valido, esto no quiere decir que no sea segura la conección, la coneccion será segura pero el certifcado no es valido, lo explicare adelante, pero mientras tanto nos cancela la navegación:



    Retomanto lo anterior, esto sucede ya que los certificados que usamos no fueron firmados por una CA de confianza para el navegador, y dado que se ha indicado que la comunicacion debe hacerse con HSTS, la comunicacion entre el usuario y el servidor no puede continuar llevandose a cabo, esto evita que realicen ataques de SSL Stripping, con herramientas de Hack como por ejemplo SSLStrip.

    Esta configuración del lado del servidor es vital para mantener sitios con un nivel de seguridad alto, desde el usuario tambien es posible activar este OPT-IN de seguridad para determinados dominios, de esta forma que aunque el servidor no obligue la cabecera estandar HSTS, el navegados por si solo bloqueara cualquier intento de coneccion que no sea segura, evitando problemas con el canal de comunicación, un ejemplo perfecto es en el navegador Chrome, este permite gestionar dominios personalizados para sugerir la norma HSTS para entrar a esta interfaz de administración del navegador, es necesario entrar aqui:  chrome://net-internals/#hsts

    Ya estando ahí, Chrome enseñara la interfaz que se puede ver en la imagen que pongo a continuación:


    Por otro lado, si esta configuración no se ha indicado para un dominio en especial y aún que el dominio tenga HSTS activado, si las peticiones se realizan utilizando HTTP, todabia hay posibilidad de utilizar una herramienta como la que ya habiamos mencionado SSLStrip para realizar un ataque de HiJacking por ejemplo una configuración bastante comun que realizan los web masters novatos es redireccionar con .htaccess todo el trafico del puerto 80 al 443 que es el protocolo de transferencia segura, esto quiere decir que si el uduario solicita un sitio web ejemplo: http://ejemplo.com, automaticamente lo redireccionara a https://ejemplo.com y debido  a que la peticion ha sido utilizando HTTP, aún existe la posibilidad de llevar a cabo un ataque y debido a esto los navegadores como Chrome y 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 que el navegador arranca, de esta forma si el usuario solicita http://ejemplo.com , la comunicación automaticamente será cortada, obligando al usuario  a entrar en la versión segura con HTTPS para tener lo adecuado en dicha lista se utuliza un algoritmo de rastreo en busca de la cabecera HSYS en multiples sitios en internet, cualquier puede enviar una solicitud para que su sitio web sea incluido en la lista, ( esta lista es compartida por Chrome, Safari & Firefox ). Si deseamos realizar esta solicitud basta con ingresar e dominio en cuestion en el siguiente sitio:  https://hstspreload.appspot.com/

    Pues bueno compañeros en este aporte a la comunidad les explique mas o menos el funcionamiento de HSTS si tienen alguna duda me pueden responer, y les ayudo, un saludo y en mi proximo aporte le dedicare un tiempo a los certificados SSL que por cierto pueden comprar conmigo desde $4 usd, más infor por MP

    Un saludo y suerte a todos!

    Ruler

    Visitante

  • Desconectado
  • Pues yo no te recomendaría ESET, En lo personal utilizo uno de los mejores:

    @Zanut Sec

    Visitante
  • Cita de: #i[J]0SEE en Marzo 03, 2015, 09:40:37 PM
    Cita de: Ruler en Marzo 03, 2015, 08:55:30 PM
    Pues yo no te recomendaría ESET, En lo personal utilizo uno de los mejores:

    ¿Porque no me recomiendas ESET? Tiene muy buenas actualizaciones y se están poniendo las pilas y han integrado la protección contra Botnet con un firewall bidireccional para escanear todo el tráfico.

    Yo vi un post de ij0see de Eset lo probe, y es que... es increible.

    Ruler

    Visitante

  • Desconectado
  • La razón es que aún son novatos en los firewall bidireccionales, Mcafee es pionero junto con Kaspersky en Los Firewalls, ya que integran Tecnología cloud en tiempo real, a Eset aún le falta mucho, ese software lo puedes crackear facilmente, mcafee es dificil ya que no hay muchos cracks por ahí o licencias.

    Ruler

    Visitante

  • Desconectado
  • Cita de: #i[J]0SEE en Marzo 04, 2015, 09:02:45 PM
    Cita de: Ruler en Marzo 04, 2015, 08:36:29 PM
    La razón es que aún son novatos en los firewall bidireccionales, Mcafee es pionero junto con Kaspersky en Los Firewalls, ya que integran Tecnología cloud en tiempo real, a Eset aún le falta mucho, ese software lo puedes crackear facilmente, mcafee es dificil ya que no hay muchos cracks por ahí o licencias.
    Novatos xD.
    Eset no se crackea, hay licencias que es distinto.


    Por la red hay algunos cracks ;)