Este tutorial muestra cómo instalar y usar ModSecurity con Apache en servidores Debian/Ubuntu. ModSecurity es un cortafuegos de aplicaciones web (WAF) de código abierto muy conocido, que proporciona una protección completa para sus aplicaciones web (como WordPress, Nextcloud, Moodle, 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
- 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.
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
- 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)
- 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.
sección A: cabecera del registro de auditoríasección B: cabecera de la peticiónsección C: cuerpo de la peticiónsección D: reservadosección E: cuerpo de la respuesta intermediasección F: cabecera de la respuesta finalsección G: reservadasección H: tráiler del registro de auditoríasección I: alternativa al cuerpo compacto de la solicitud, que excluye los archivossección J: información sobre los archivos cargadossección K: todas las reglas coincidentes con un evento, por orden de coincidenciasecció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).
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
<LocationMatch "/wp-admin/post.php">SecRuleRemoveById 980130 941180 949110</LocationMatch>
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"
SecRule REMOTE_ADDR "^127\.0\.0\.1" "id:1004,phase:1,allow,ctl:ruleEngine=off"
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"
<IfModule mod_security2.c>
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream
SecDataDir /tmp
</IfModule>
Parámetros
SecRuleEngine
on aplica las reglas a las solicitudes recibidas
-
off no aplica las reglas
-
DetectionOnly aplica las reglas pero no realiza ningún tipo de acción de bloque. Es la configuración aconsejada cuando se instala el modulo. Solamente después de probar el servidor y tener la certeza que todo funciona bien, se puede cambiar a on
-
SecRequestBodyAccess
-
on el modulo tiene acceso a los anexos presentes en las solicitudes recibidas, que, como dijimos anteriormente, son las que se utilizan para lanzar ataques
-
off no se accede a los anexos
-
-
SecRule es el parámetro que se puede repetir más de una vez en el archivo y es donde se definen las reglas generales del modulo. El parámetro tiene la siguiente sintaxis:
-
variable
-
operator
-
action
-
ejemplo: en el archivo la primera vez que aparece es para permitir parsear los anexos XML
-
-
SecRequestBodyLimit: el tamaño máximo de un anexo que mod_security aceptará en el área de trabajo. El valor es en byte y el predefinido es 13107200 que corresponde a 12,5 MByte. Si llega alguna solicitud con un anexo de tamaño más grande, el servidor web contestará con el siguiente mensaje de error: 413 Request Entity Too Large. Limite máximo intrínseco al modulo: 1 GB
-
SecRequestBodyNoFilesLimit: el tamaño máximo de una anexo que mod_security aceptará cuando no se trata de un archivo. El valor predefinido corresponde a 128KBytes
-
SecRequestBodyInMemoryLimit: el tamaño máximo de una anexo que mod_security aceptará en la memoria de trabajo. El valor predefinido corresponde a 128 KBytes
-
SecRequestBodyLimitAction: controla que tipo de acción se toma cuando llega una solicitud con un anexo de tamaño más grande al definido en el parámetro SecRequestBodyLimit:
-
reject: se rechaza
-
ProcessPartial: se procesa parcialmente hasta llegan al tamaño máximo definido. IMPORTANTE: si SecRuleEngine = DetectionOnly el valor de este parámetro se configurará automáticamente en ProcessPartial
-
-
SecResponseBodyAccess: se define si los anexos presentes en las repuestas (no en las solicitudes) se aceptarán en el área de trabajo de mod_security.
-
On: activo
-
Off: no activo
-
-
SecResponseBodyMimeType: que tipo de anexo de las respuestas se analizarán si el parámetro anterior está en On:
-
text/plain: texto plano
-
text/html: formato HTML
-
text/xml: formato XML
-
-
SecResponseBodyLimit: tamaño maximo aceptado para el anexo presente en una respuesta; valor predefinido 524288 correspondiente a 512KBytes
-
SecResponseBodyLimitAction: acción que se tomará si el tamaño del anexo de la respuesta supera el valor presente en el parametro anterior
-
Reject: se rechaza
-
ProcessPartial: se procesa parcialmente hasta llegan al tamaño máximo definido
-
-
SecTmpDir: carpeta donde mod_security guardará los archivos temporales
-
/tmp/
-
-
SecDataDir: carpeta donde mod_security guardará los archivos persistentes
-
/tmp/
-
-
SecDebugLog: carpeta y archivo donde se guardará el debug del programa
-
/var/log/modsecurity/debug.log
-
-
SecDebugLogLevel
-
0: LOG desactivado
-
1: errores
-
2: Advertencias
-
3: noticias
-
4: detalles de como las transacciones se han procesado
-
5: como la anterior añadiendo más datos de las transacciones
-
9: cualquier tipo de operación realizada por el modulo
-
-
SecAuditEngine RelevantOnly
-
SecAuditLogParts ABIJDEFHZ
-
SecAuditLogType Serial
-
SecAuditLog /var/log/modsecurity/audit.log
Reglas OWASP ModSecurity Core Rule Set (CRS)
- 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.
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.tar.gz
tar xvf v3.3.5.tar.gz
sudo mkdir /etc/apache2/modsecurity-crs/
sudo mv coreruleset-3.3.5/ /etc/apache2/modsecurity-crs/
cd /etc/apache2/modsecurity-crs/coreruleset-3.3.5/
sudo mv crs-setup.conf.example crs-setup.conf
sudo nano /etc/apache2/mods-enabled/security2.conf
IncludeOptional /usr/share/modsecurity-crs/*.load
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.5/crs-setup.confIncludeOptional /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.
- Paranoia nivel 1 (por defecto)
- Paranoia nivel 2
- Paranoia nivel 3
- Paranoia nivel 4
Encadenamiento de reglas
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"
Par resolver el primero problema se añade Nextcloud a la lista blanca de mod_security:
nano /etc/httpd/modsecurity.d/crs-setup.conf
al final del archivo se añade:
SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_nextcloud=1"
se guardan los cambios. Para el segundo punto hay que aumentar el valor del parámetro SecRequestBodyLimit con una valor adecuado al tamaño de loas archivos que se manejan con Nextcloud ya que los archivos, del cliente al servidor, viajan como anexos a través del servidor web.
Falsos Positivos
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
Habilitar y configurar la regla de protección de denegación de servicio (DoS)
Para habilitar y configurar la regla de protección Denegación de servicio (DoS), siga los siguientes pasos:
-
Habilite la regla de protección DoS cambiando el nombre de
REQUEST-912-DOS-PROTECTION.conf.disabledaREQUEST-912-DOS-PROTECTION.conf(o quite.disabledde la extensión rulename) en la carpetadispatcher/src/conf.d/modsec/crs/rules. -
Configure la regla definiendo las variables DOS_COUNTER_THRESHOLD, DOS_BURST_TIME_SLICE, DOS_BLOCK_TIMEOUT.
- Crear un archivo de
crs-setup.custom.confen la carpetadispatcher/src/conf.d/modsec/crs. - Añada el siguiente fragmento de regla al archivo recién creado.
- Crear un archivo de
# The Denial of Service (DoS) protection against clients making requests too quickly.En esta configuración de regla de ejemplo, DOS_COUNTER_THRESHOLD tiene 25, DOS_BURST_TIME_SLICE tiene 60 segundos y el tiempo de espera de DOS_BLOCK_TIMEOUT es de 600 segundos. Esta configuración identifica más de dos incidencias de 25 solicitudes, excluidos los archivos estáticos, en un plazo de 60 segundos que cumplen los requisitos de ataque DoS, lo que provoca que el cliente solicitante se bloquee durante 600 segundos (o 10 minutos).
# When a client is making more than 25 requests (excluding static files) within
# 60 seconds, this is considered a 'burst'. After two bursts, the client is
# blocked for 600 seconds.
SecAction \
"id:900700,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:'tx.dos_burst_time_slice=60',\
setvar:'tx.dos_counter_threshold=25',\
setvar:'tx.dos_block_timeout=600'"
# Variables:
# IP:DOS_BLOCK Flag if an IP address should be blocked
# IP:DOS_BLOCK_COUNTER Counter of blocked requests
# IP:DOS_BLOCK_FLAG Flag keeping track of alert. Flag expires after 60 seconds.
# IP:DOS_BURST_COUNTER Burst counter
# IP:DOS_COUNTER Request counter (static resources are ignored)
# TX:DOS_BLOCK_COUNTER Copy of IP:DOS_BLOCK_COUNTER (needed for display reasons)
# TX:DOS_BLOCK_TIMEOUT Period in seconds a blocked IP will be blocked
# TX:DOS_COUNTER_THRESHOLD Limit of requests, where a burst is identified
# TX:DOS_BURST_TIME_SLICE Period in seconds when we will forget a burst
# TX:STATIC_EXTENSIONS Paths which can be ignored with regards to DoS
Fuentes:
https://www.linuxbabe.com/security/modsecurity-apache-debian-ubuntu
bla bla bla
ResponderEliminar