Este sitio utiliza cookies propias y de terceros. Si continúa navegando consideramos que acepta el uso de cookies. OK Más Información.

Cómo instalar y configurar ModSecurity en Apache sobre servidores Debian

  • 2 Respuestas
  • 4144 Vistas

0 Usuarios y 5 Visitantes están viendo este tema.

Desconectado d0r127

  • *
  • Underc0der
  • Mensajes: 116
  • Actividad:
    0%
  • Reputación 1
  • Sin hocico y paranoico
    • Ver Perfil
« en: Enero 18, 2017, 08:34:59 am »

Descripcion

ModSecurity es un módulo para servidores HTTP cuyo propósito es reforzar la seguridad de las aplicaciones Web. Es efectivamente un sistema de prevención y detección de intrusos para servidores Web.

ModSecurity es un firewall a nivel aplicación (WAF, web application firewall) implementado como un módulo para diferentes servidores HTTP (Apache, NGINX y Microsoft IIS) multiplataforma de código abierto (open source). Esta herramienta permite ganar visibilidad dentro del tráfico HTTP(S) y provee un lenguaje de reglas y una API para implementar protecciones avanzadas. Esto significa que es posible filtrar tráfico HTTP, directamente en el servidor Web, según el contenido de las peticiones de los clientes, lo cual permite detectar y bloquear ataques de tipo XSS (Cross Site Scripting), SQLi (SQL injection), session hijacking, etc

Caracterisitcas

-Capacidad de log y filtrado.
-La auditoira del log  permite almacenar el detalle de cada petición en un archivo de log, incluyendo los payloads de los POST -HTTP.
-Los pedidos entrantes a su vez pueden ser analizados, y los pedidos ofensivos rechazados (o simplemente registrados en el log, de acuerdo a cómo se configure)

Instalacion

Código: [Seleccionar]
apt-get install libapache2-modsecurity
SI NOS ENCONTRAMOS ANTE ESTE ERROR:
Código: [Seleccionar]
(EAI 5)No address associated with hostname: mod_unique_id: unable to find IPv4 address of
Esto es a causa de que ModSecurity requiere del módulo mod_unique_id el cual construye magic tokens a partir del hostname. Si se deshabilita el módulo mod_unique_id (a2dismod unique_id && service apache2 start), el servidor Apache inicia normalmente, pero por supuesto es necesario mantener este módulo habilitado para poder utilizar ModSecurity.

Para solucionar este problema existen dos alternativas: asignar un nombre de host que resuelva a una dirección IP; o hacer que el nombre de host resuelva a una dirección IP. Para que el nombre de host actual resuelva a una dirección IP no es necesario meter mano en servidores DNS, sólo basta con que el nombre de host resuelva localmente. Para ello basta con fijar la dirección IPv4 del host en la tabla de configuración estática de búsqueda para nombres de host (dentro del archivo /etc/hosts):

Código: [Seleccionar]
vi /etc/hosts
Por ejemplo, si el nombre de host inválido es "mywebserver", fijarlo para que resuelva a localhost:

Código: [Seleccionar]
127.0.0.1 localhost mywebserver
Luego iniciar Apache:
Código: [Seleccionar]
service apache2 start
Código: [Seleccionar]
root@debian7# apachectl -M 2>/dev/null | grep security
 security2_module (shared)

En este punto queda ModSecurity correctamente instalado. Ahora resta configurarlo y ponerlo en funcionamiento, la parte más difícil. Tal como mencioné al comienzo del artículo, ModSecurity trabaja utilizando reglas para la detección y filtrado de diferentes tipos de ataques, las cuales se definen utilizando un lenguaje propio. Por defecto incluye un conjunto de reglas genéricas mantenidas por la comunidad OWASP, las cuales son liberadas de manera gratuita y protegen contra los ataques básicos. Pero también existen reglas comerciales desarrolladas por Trustwave SpiderLabs que protegen contra ataques más avanzados, como Botnets, DoS y backdoors, entre otros. Por supuesto es posible desarrollar nuestras propias reglas a medida, pero para ello es necesario contar con un elevado conocimiento sobre ataques y protocolos.

Configuración de ModSecurity

El módulo mod-security posee un archivo de configuración mod-security.conf dentro del directorio /etc/apache2/mod-available/, el cual incluye todo archivo con extensión .conf que se encuentre dentro del directorio /etc/modsecurity/:

Citar
root@debian7# cat /etc/apache2/mods-available/mod-security.conf
<IfModule security2_module>
        # Default Debian dir for modsecurity's persistent data
        SecDataDir /var/cache/modsecurity

        # Include all the *.conf files in /etc/modsecurity.
        # Keeping your local configuration in that directory
        # will allow for an easy upgrade of THIS file and
        # make your life easier
        Include "/etc/modsecurity/*.conf"
</IfModule>

Durante la instalación de ModSecurity se incluye un archivo de configuración de ejemplo, modsecurity.conf-recommended,dentro de este directorio /etc/modsecurity/, el cual inicialmente no es incluido por no tener extensión .conf:

Citar
root@debian7# ls -l /etc/modsecurity/
total 8
-rw-r--r-- 1 root root 7453 Jul 25  2014 modsecurity.conf-recommended

Copiamos el archivo de configuración de ejemplo:
Código: [Seleccionar]
cd /etc/modsecurity/
cp modsecurity.conf-recommended modsecurity.conf

Luego, editar el archivo:

Código: [Seleccionar]
vi mod-security.confPor defecto, deshabilitar ModSecurity completamente (SecRuleEngine Off), ya que sólo será habilitado en VirtualHosts específicos:

Código: [Seleccionar]
SecRuleEngine DetectionOnly
SecRuleEngine Off

Las reglas genéricas (OWASP ModSecurity CRS) que se incluyen con el paquete se encuentran en el directorio /usr/share/modsecurity-crs/:

Código: [Seleccionar]
cd /usr/share/modsecurity-crs/
Dentro del mismo existen subdirectorios que organizan las reglas en diferentes tipos (base, activadas, experimentales, etc.). El directorio activated_rules está pensado para trabajar con links simbólicos de la misma forma que los directorios mods-enabled y sites-enabled de Apache (en Debian y derivados).

Pero, para diferenciar las reglas en testing de las reglas en producción (pensando a futuro), es necesario crear un directorio aparte para las reglas en testing:

Código: [Seleccionar]
cp -a activated_rules/ activated_rules-testingPara habilitar una regla, basta entonces con crear un enlace simbólico en activated_rules (producción) o activated_rules-testing (testing). Habilitar la regla de detección de ataques SQLi en testing para probar ModSecurity:

Código: [Seleccionar]
cd activated_rules-testing/
ln -s ../base_rules/modsecurity_crs_41_sql_injection_attacks.conf
.

Hasta este punto, a pesar de que el módulo mod-security está habilitado, ModSecurity está configurado como apagado (SecRuleEngine Off). El siguiente paso consiste en editar el VirtualHost de testing a fin de habilitar ModSecurity en modo "DetectionOnly" (sólo en testing, de esta forma seguirá deshabilitado en producción):

Código: [Seleccionar]
nano /etc/apache2/sites-available/testing.linuxito.comAgregar el siguiente contenido dentro de la definición del VirtualHost:
       
Citar
# ModSecurity
        <IfModule security2_module>
      SecRuleEngine DetectionOnly
      Include "/usr/share/modsecurity-crs/*.conf"
      Include "/usr/share/modsecurity-crs/activated_rules-testing/*.conf"
        </IfModule>

La primera línea de configuración habilita ModSecurity en modo "DetectionOnly". Esto significa que los ataques son detectados y registrados en el log de auditoría, pero no son bloqueados/filtrados.

La siguiente línea se utiliza para incluir el archivo /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf, el cual posee las directivas de configuración que controlan al conjunto de reglas genéricas de OWASP ModSecurity CRS.

Por último, se incluyen todos los archivos dentro del directorio que contienen las reglas /usr/share/modsecurity-crs/activated_rules-testing/, los cuales son links simbólicos a reglas habilitadas.

Finalmente, se debe recargar la configuración de Apache para que estas modificaciones surjan efecto:

Código: [Seleccionar]
service apache2 reload
Prueba de ModSecurity

Teniendo ModSecurity habilitado en testing en modo "DetectionOnly", realizar una prueba simple de SQLi para verificar su funcionamiento (es decir, que se registre en el log de auditoría el intento de ataque). A modo de ejemplo, el vector de ataque que utilizo es simplemente:

http://testing.linuxito.com/?var=1' or '1'='1
En el archivo de configuración de ejemplo de ModSecurity se indica que el archivo de log de auditoría es /var/log/apache2/modsec_audit.log. Seguir las modificaciones sobre dicho archivo con la herramienta tail:

Código: [Seleccionar]
tail -f /var/log/apache2/modsec_audit.logSe observa que, luego de enviar el vector de ataque desde un navegador, se registra el siguiente evento:

Citar
Message: Rule 7f548f412280 [id "950901"][file "/usr/share/modsecurity-crs/activated_rules-testing/modsecurity_crs_41_sql_injection_attacks.conf"][line "77"] - Execution error - PCRE limits exceeded (-8): (null).
Message: Warning. Pattern match "(?i:([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*)?([\\d\\w]+)([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*)?(?:=|<=>|r?like|sounds\\s+like|regexp)([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*)?\\2|([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\ ..." at ARGS:var. [file "/usr/share/modsecurity-crs/activated_rules-testing/modsecurity_crs_41_sql_injection_attacks.conf"] [line "77"] [id "950901"] [rev "2.2.5"] [msg "SQL Injection Attack"] [data " '1'='1"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]


fuente:linuxito.com

« Última modificación: Enero 22, 2017, 01:21:23 am por EPSILON »

Desconectado fran_

  • *
  • Underc0der
  • Mensajes: 4
  • Actividad:
    0%
  • Reputación 0
    • Ver Perfil
« Respuesta #1 en: Marzo 29, 2017, 06:55:55 pm »
Hola amigo.
Muy buen post!!!
He seguido tu guía y me ha resultado muy útil la información.
Que reglas debería activar para un sitio en wordpress?
« Última modificación: Mayo 04, 2017, 12:10:41 pm por fran_ »

Desconectado fran_

  • *
  • Underc0der
  • Mensajes: 4
  • Actividad:
    0%
  • Reputación 0
    • Ver Perfil
« Respuesta #2 en: Mayo 04, 2017, 12:43:34 pm »
Hola amigo.
Muy buen post!!!
He seguido tu guía y me ha resultado muy útil la información.
Que reglas debería activar para un sitio en wordpress?

Ok, voy a ampliar el tema ModSecurity y WordPress que actualmente protege mi webserver y reporta todo tipo de ataques diarios, principalmente ataques del tipo xmlrpc. Los cuales podemos visualizar con este comando.
En el caso de access.log
Código: [Seleccionar]
$grep xmlrpc /var/log/apache2/access.log
Y en el caso de modsecurity
Código: [Seleccionar]
$grep xmlrpc /var/log/apache2/modsec_audit.log
Los módulos actualmente habilitados para Wordpress son:
  • modsecurity_35_bad_robots.data
  • modsecurity_35_scanners.data
  • modsecurity_40_generic_attacks.data
  • modsecurity_50_outbound.data
  • modsecurity_50_outbound_malware.data
  • modsecurity_crs_23_request_limits.conf
  • modsecurity_crs_30_http_policy.conf
  • modsecurity_crs_35_bad_robots.conf
  • modsecurity_crs_40_generic_attacks.conf
  • modsecurity_crs_41_xss_attacks.conf
  • modsecurity_crs_42_tight_security.conf
  • modsecurity_crs_45_trojans.conf
  • modsecurity_crs_47_common_exceptions.conf
  • modsecurity_crs_49_inbound_blocking.conf
  • modsecurity_crs_59_outbound_blocking.conf
  • modsecurity_crs_60_correlation.conf
De los cuales hay dos módulos que tengo de deshabilitar cada vez que quiero realizar un nuevo post o modificar alguno de los ya publicados.
  • modsecurity_crs_40_generic_attacks.conf
  • modsecurity_crs_41_xss_attacks.conf

Citar
No olvidar que modsecurity es un firewall a nivel de aplicación
Espero les sea útil.

 

¿Te gustó el post? COMPARTILO!



Cosas que debes saber acerca de los links, urls, hipervínculos o como los llames

Iniciado por Andrey

Respuestas: 0
Vistas: 4451
Último mensaje Abril 17, 2018, 04:28:58 pm
por Andrey
¿Como debo empezar para auditar un servidor web? - Nivel Intermedio

Iniciado por BrowserNet

Respuestas: 12
Vistas: 10421
Último mensaje Octubre 09, 2016, 02:24:36 am
por ceroMee
[UNDERtip] Como empezar a identificar fallos de seguridad en aplicaciones web.

Iniciado por rollth

Respuestas: 0
Vistas: 3397
Último mensaje Octubre 24, 2016, 09:07:44 pm
por rollth
Cómo cifrar nuestro tráfico DNS para evitar que nos rastreen

Iniciado por Dragora

Respuestas: 0
Vistas: 2017
Último mensaje Febrero 19, 2019, 07:21:12 pm
por Dragora
Como protegernos de escaneos en nuestros servers (portsentry)

Iniciado por july

Respuestas: 0
Vistas: 3020
Último mensaje Noviembre 20, 2012, 12:16:38 pm
por july