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»
