Blog elhacker.NET: Tutorial Apache modsecurity (WAF)

Tutorial Apache modsecurity (WAF)

viernes, 15 de diciembre de 2023 | Publicado por el-brujo | Editar entrada

Este tutorial muestra cómo instalar y usar ModSecurity con Apache en servidores Debian/Ubuntu. ModSecurity es el cortafuegos de aplicaciones web (WAF) de código abierto muy conocido, que proporciona una protección completa para sus aplicaciones web (como WordPress, Nextcloud, Ghost, etc.) contra una amplia gama de ataques de Capa 7 (HTTP), como inyección SQL, cross-site scripting e inclusión de archivos locales (LFI)

Las aplicaciones web son intrínsecamente inseguras. Si eres un administrador de WordPress, probablemente escuche noticias de vulnerabilidades en plugins y temas de WordPress de vez en cuando. Es esencial que despliegues un WAF en tu servidor web, especialmente cuando tienes aplicaciones antiguas que no reciben actualizaciones. ModSecurity fue creado originalmente por Ivan Ristić en 2002, y actualmente lo mantiene Trustwave SpiderLabs. Es el WAF más desplegado del mundo, utilizado por más de un millón de sitios web. cPanel, el panel de control de hosting más utilizado, incluye ModSecurity como su WAF.

Puede que haya oído hablar de otros cortafuegos basados en host como iptables, UFW y Firewalld, etc. La diferencia es que estos trabajan en las capas 3 y 4 del modelo OSI y toman acciones basadas en la dirección IP y el número de puerto. ModSecurity, o los cortafuegos de aplicaciones web en general, está especializado para centrarse en el tráfico HTTP (capa 7 del modelo OSI) y toma acciones basadas en el contenido de la petición y respuesta HTTP.

ModSecurity 3

ModSecurity fue diseñado originalmente para el servidor web Apache. Podía funcionar con Nginx antes de la versión 3.0 pero sufría de bajo rendimiento. ModSecurity 3.0 (también conocido como libmodsecurity) fue lanzado en 2017. Es un hito, especialmente para los usuarios de Nginx, ya que es la primera versión que funciona de forma nativa con Nginx. La advertencia de ModSecurity 3 es que todavía no tiene todas las características de la versión anterior (2.9), aunque cada nueva versión añadirá algunas de las características que faltan. Los usuarios de Nginx deberían usar ModSecurity 3. Sin embargo, si usas Apache, se recomienda seguir usando la rama 2.9 por el momento.

Instalación básica

El módulo ModSecurity para Apache está incluido en el repositorio por defecto de Debian/Ubuntu. Para instalarlo, ejecuta:

sudo apt install libapache2-mod-security2

A continuación, habilita este módulo

sudo a2enmod security2

Reinicia Apache para que el cambio surta efecto.

sudo systemctl restart apache2

Configurar ModSecurity

En el fichero de configuración /etc/apache2/mods-enabled/security2.conf, puede encontrar la siguiente línea.

IncludeOptional /etc/modsecurity/*.conf

Esto significa que Apache incluirá todos los ficheros *.conf en el directorio /etc/modsecurity/. Necesitamos renombrar el archivo modsecurity.conf-recommended para que funcione.

modsecurity en Apache 2.4

modSecurity filtra ataques por XSS, SQL Injection, comportamientos anómalos en protocolos, robots, troyanos, LFI ... incorporando además reglas específicas para algunos de los gestores de contenido más populares como Joomla o Wordpress. modSecurity también funciona con nginx e IIS.

modSecurity es un firewall de aplicaciones Web embebible bajo licencia GNU que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.

ModSecurity cuenta con una consola de administración que permite recopilar registros de monitorización y alertas en tiempo real así como de opciones automatizadas de mantenimiento, entre otras características.

yum install mod_security mod_security_crs

Edita el fichero /etc/httpd/conf.d/mod_security.conf

On: The rules are enforced and connections will be terminated when matching rules are found.
Detect Only: The rules are enforced and connections will be logged when matching rules are found. Not traffic will be dropped.
Off: Rules are not enforced.

Mod Security Config File – /etc/httpd/conf.d/mod_security.conf
Debug Log – /var/log/httpd/modsec_debug.log
Audit log – /var/log/httpd/modsec_audit.log
Rules – /etc/httpd/modsecurity.d/activated_rules

#SecRuleEngine DetectionOnly
SecRuleEngine On
SecAuditLog /var/log/apache2/modsec_audit.log

Para entender los registros de auditoría de ModSecurity, necesita conocer las 5 fases de procesamiento en ModSecurity, que son:

Phase 1: Inspeccionar las cabeceras de la petición
Phase 2: Inspeccionar el cuerpo de la petición
Phase 3: Inspeccionar las cabeceras de la respuesta
Phase 4: Inspeccionar el cuerpo de la respuesta
Phase 5: Acción (registrar/bloquear peticiones maliciosas)

También hay dos tipos de archivos de registro.

Serial: un archivo para todos los registros. Este es el predeterminado.
Concurrent: varios archivos de registro. Esto puede proporcionar un mejor rendimiento de escritura. Si nota que sus páginas web se ralentizan después de activar ModSecurity, puede elegir usar el tipo de registro concurrente.

Los eventos en el registro se dividen en varias secciones (sections)

sección A: cabecera del registro de auditoría
sección B: cabecera de la petición
sección C: cuerpo de la petición
sección D: reservado
sección E: cuerpo de la respuesta intermedia
sección F: cabecera de la respuesta final
sección G: reservada
sección H: tráiler del registro de auditoría
sección I: alternativa al cuerpo compacto de la solicitud, que excluye los archivos
sección J: información sobre los archivos cargados
sección K: todas las reglas coincidentes con un evento, por orden de coincidencia
sección Z: límite final

Si tienes un sitio web con mucho tráfico, el log de auditoría de ModSecurity puede volverse demasiado grande muy rápidamente, por lo que necesitamos configurar la rotación de logs para el log de auditoría de ModSecurity. Crea un fichero de configuración logrotate para ModSecurity.

sudo nano /etc/logrotate.d/modsecurity

Añada las siguientes líneas a este fichero.

/var/log/httpd/modsec_audit.log
{
rotate 10
daily
missingok
compress
delaycompress
notifempty
}

Esto rotará el archivo de registro cada día (daily), comprimiendo las versiones antiguas (compress). Los 10 archivos de registro anteriores se mantendrán (rotate 10), y no se producirá ninguna rotación si el archivo está vacío (notifempty).

Excluir reglas por ID (identificador)

SecRuleRemoveById 920350

Excluir rango de reglas:

SecRuleRemoveById "9000-9010"

Excluir reglas según tipo:

SecRuleRemoveByTag "WEB_ATTACK/XSS"

OWASP ModSecurity CRS incluye:

AUTOMATION/MALICIOUS
AUTOMATION/MISC
AUTOMATION/SECURITY_SCANNER
LEAKAGE/SOURCE_CODE_ASP_JSP
LEAKAGE/SOURCE_CODE_CF
LEAKAGE/SOURCE_CODE_PHP
WEB_ATTACK/CF_INJECTION
WEB_ATTACK/COMMAND_INJECTION
WEB_ATTACK/FILE_INJECTION
WEB_ATTACK/HTTP_RESPONSE_SPLITTING
WEB_ATTACK/LDAP_INJECTION
WEB_ATTACK/PHP_INJECTION
WEB_ATTACK/REQUEST_SMUGGLING
WEB_ATTACK/SESSION_FIXATION
WEB_ATTACK/SQL_INJECTION
WEB_ATTACK/SSI_INJECTION
WEB_ATTACK/XSS

Excluir reglas según directorio:

<LocationMatch "/wp-admin/post.php">
SecRuleRemoveById 980130 941180 949110
</LocationMatch>

Excluir reglas según IP (WhiteList) (cambia IP por tu dirección IP)

SecRule REMOTE_ADDR "@IPMatch IP" "id:932160,ctl:ruleEngine=Off"
SecRule REMOTE_ADDR "@IPMatch IP" "id:980130,ctl:ruleEngine=Off"

SecRule REMOTE_ADDR "@ipMatch IP" "id:980130,phase:2,t:none,log,allow"
SecRule REMOTE_ADDR "@ipMatch IP" "id:941180,phase:2,t:none,log,allow"

Para la IP 127.0.0.1

SecRule REMOTE_ADDR "^127\.0\.0\.1" "id:1004,phase:1,allow,ctl:ruleEngine=off"

Para una subred 10.10.10.0/24

SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"

Ejemplo configuración básico:

<IfModule mod_security2.c>
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream
SecDataDir /tmp
</IfModule>

Reglas OWASP ModSecurity Core Rule Set (CRS)

Para hacer que ModSecurity proteja tus aplicaciones web, necesita definir reglas para detectar actores maliciosos y bloquearlos. Para los principiantes, es una buena idea instalar conjuntos de reglas existentes, para que pueda empezar rápidamente y luego aprender los detalles más adelante. Hay varios conjuntos de reglas gratuitos para ModSecurity. El OWASP Core Rule Set (CRS) es el conjunto de reglas estándar usado con ModSecurity.

Es gratuito, mantenido por la comunidad y el conjunto de reglas más utilizado que proporciona una configuración por defecto vendida para ModSecurity.
Contiene reglas para ayudar a detener vectores de ataque comunes, incluyendo SQL injection (SQLi), cross-site scripting (XSS), y muchos otros.
Puede integrarse con Project Honeypot y Fail2ban
También contiene reglas para detectar bots y escáneres.
Ha sido ajustado a través de una amplia exposición para tener muy pocos falsos positivos.

Cuando se instala ModSecurity desde el repositorio por defecto de Debian/Ubuntu, el paquete modsecurity-crs también se instala como dependencia. Este paquete contiene el conjunto de reglas del núcleo OWASP versión 3.x. Sin embargo, puede quedar desactualizado. Si te preocupa la seguridad, deberías utilizar la última versión del conjunto de reglas básicas.

Descarga la última versión de OWASP CRS desde GitHub.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.tar.gz

Extrae el archivo.

tar xvf v3.3.5.tar.gz

Crea un directorio para almacenar los archivos CRS.

sudo mkdir /etc/apache2/modsecurity-crs/

Mueve el directorio extraído a /etc/apache2/modsecurity-crs/.

sudo mv coreruleset-3.3.5/ /etc/apache2/modsecurity-crs/

Ves al directorio.

cd /etc/apache2/modsecurity-crs/coreruleset-3.3.5/

Cambia el nombre del archivo crs-setup.conf.example.

sudo mv crs-setup.conf.example crs-setup.conf

Edita el archivo /etc/apache2/mods-enabled/security2.conf.

sudo nano /etc/apache2/mods-enabled/security2.conf

Busca la siguiente línea, que carga los archivos CRS por defecto.

IncludeOptional /usr/share/modsecurity-crs/*.load

Cambia por la siguiente, para que se utilice el último CRS de OWASP.

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.5/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.5/rules/*.conf

Cómo funciona OWASP CRS

Echemos un vistazo al archivo de configuración de CRS, que te proporciona una buena documentación sobre cómo funciona CRS.

sudo nano /etc/apache2/modsecurity-crs/coreruleset-3.3.5/crs-setup.conf

Puedes ver que OWASP CRS puede ejecutarse en dos modos:

modo autónomo. Este es el modo tradicional usado en CRS v2.x. Si una petición HTTP coincide con una regla, ModSecurity bloqueará la petición HTTP inmediatamente y dejará de evaluar las reglas restantes.
Modo de puntuación de anomalías. Este es el modo por defecto usado en CRS v3.x. ModSecurity comprobará una petición HTTP con todas las reglas, y añadirá una puntuación a cada regla que coincida. Si se alcanza un umbral, entonces la petición HTTP se considera un ataque y será bloqueada. La puntuación por defecto para peticiones entrantes es 5 y para respuestas salientes es 4.

Cuando se ejecuta en modo de puntuación de anomalías, hay 4 niveles de paranoia.

Paranoia nivel 1 (por defecto)
Paranoia nivel 2
Paranoia nivel 3
Paranoia nivel 4

Con cada aumento del nivel de paranoia, el CRS activa reglas adicionales que le proporcionan un mayor nivel de seguridad. Sin embargo, los niveles de paranoia más altos también aumentan la posibilidad de bloquear parte del tráfico legítimo debido a falsas alarmas.

Estos son los dos conceptos básicos que hay que entender antes de utilizar el SIR. Ahora podemos cerrar el archivo. Las reglas individuales del CRS se almacenan en el directorio /etc/apache2/modsecurity-crs/coreruleset-3.3.5/rules/. Cada regla coincidente incrementará la puntuación de anomalía.

Encadenamiento de reglas

Si tu servidor Apache tiene múltiples hosts virtuales, puede que quieras poner tu dirección IP en la lista blanca de un host virtual específico. Necesitas encadenar dos reglas de la siguiente manera

SecRule REMOTE_ADDR "@ipMatch 12.34.56.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:none"

La palabra clave chain al final de la primera regla indica que la acción ruleEngine=off sólo se llevará a cabo si la condición de la siguiente regla también es verdadera.

Falsos Positivos

Editar el fichero

crs-setup.conf

Ves a la sección Exclusiones de reglas específicas de la aplicación y busca las siguientes líneas.

#SecAction \
# "id:900130,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.crs_exclusions_cpanel=1,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_dokuwiki=1,\
# setvar:tx.crs_exclusions_nextcloud=1,\
# setvar:tx.crs_exclusions_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=1"

Por ejemplo, si quiero activar las exclusiones de WordPress, las líneas anteriores deben cambiarse por las siguientes:

SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_wordpress=1"

Exclusiones para un subdominio:

SecRule REQUEST_HEADERS:Host "@streq blog.elhacker.net" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"

Por ejemplo un subdominio con nextcloud:

SecRule REQUEST_HEADERS:Host "@streq nextcloud.elhacker.net" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"

modsecurity + Fail2ban + AbuseIpDB

modsecurity se puede integrar fácilmente con Fail2Ban

[apache-modsecurity]
enabled = true
filter = apache-modsecurity
#logpath = /var/log/httpd/modsec_audit.log
backend = pyinotify
action = abuseipdb[abuseipdb_category="15,21"]
bantime = 1h
logencoding = UTF-8

Fuentes:

https://www.linuxbabe.com/security/modsecurity-apache-debian-ubuntu

Etiquetas: apache , crs , lfi , manual , modserurity , nginx , owasp , tutorial , xss

1 comentarios :

Anónimo dijo...: bla bla bla; 19 de enero de 2024, 0:32

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.

Tienda Wifi

Tutoriales y Manuales

Entradas Mensuales

Síguenos en:

Blogroll

Etiquetas

Entradas populares