Arquitectura de Seguridad Defensiva: Implementación de WAF con ModSecurity

Paradigma de Defensa en Profundidad: El Rol del WAF#

En entornos corporativos de alta criticidad, la protección en la capa de red (L3/L4) resulta insuficiente contra vectores de ataque modernos. Las amenazas orientadas a la capa de aplicación (L7), tales como Inyecciones SQL (SQLi), Cross-Site Scripting (XSS) y Server-Side Request Forgery (SSRF), exigen inspección profunda de tráfico HTTP/HTTPS. Aquí es donde una arquitectura basada en Web Application Firewall (WAF) se vuelve imprescindible.

ModSecurity, originalmente diseñado como un módulo para Apache, ha evolucionado hacia un motor agnóstico (libmodsecurity o ModSecurity v3) que se integra de manera nativa con NGINX y Envoy. Cuando se combina con el OWASP Core Rule Set (CRS), proporciona una línea base de detección de anomalías altamente efectiva y adaptable.

[!NOTE] En arquitecturas modernas (Microservicios, Kubernetes), el WAF suele desplegarse en el Ingress Controller o en un API Gateway perimetral, aplicando políticas de mitigación antes de que el payload alcance los servicios del backend.

Arquitectura de Despliegue con NGINX y libmodsecurity#

La implementación como módulo dinámico en NGINX permite procesar el tráfico con una latencia mínima, bloqueando peticiones maliciosas en el perímetro.

1. Compilación e Inyección del Módulo

Para entornos Linux (ej. Ubuntu/Debian), es crítico compilar libmodsecurity y el conector de NGINX de manera paralela a la versión exacta del servidor web en producción:

# Instalación de dependencias core
apt-get install -y apt-utils autoconf automake build-essential git libcurl4-openssl-dev libgeoip-dev liblmdb-dev libpcre++-dev libtool libxml2-dev libyajl-dev pkgconf wget zlib1g-dev

# Clonación y compilación de libmodsecurity
git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
git submodule init && git submodule update
./build.sh && ./configure && make -j$(nproc) && make install

# Compilación del conector dinámico para NGINX
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git
wget http://nginx.org/download/nginx-$(nginx -v 2>&1 | awk -F/ '{print $2}').tar.gz
tar zxvf nginx-*.tar.gz && cd nginx-*/
./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
make modules
cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

2. Integración del OWASP Core Rule Set (CRS)

El CRS opera bajo un modelo de Paranoia Levels (PL). Un PL1 ofrece una protección fundamental con mínimos falsos positivos, mientras que un PL4 aplica validaciones estrictas ideales para transacciones financieras, aunque requiere un proceso exhaustivo de tuning.

# Descarga del CRS oficial
cd /usr/local/
git clone https://github.com/coreruleset/coreruleset.git
mv coreruleset/crs-setup.conf.example coreruleset/crs-setup.conf

# Configuración base de ModSecurity (recomendado iniciar en SecRuleEngine DetectionOnly)
cp /opt/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/nginx/modsec/modsecurity.conf

Para habilitar el motor en los server blocks de NGINX, debemos inyectar la configuración del módulo y cargar los archivos de reglas:

# /etc/nginx/nginx.conf
load_module modules/ngx_http_modsecurity_module.so;

http {
    # Inclusión del archivo principal de ModSec
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    server {
        listen 443 ssl http2;
        server_name api.forgenex.com;

        # Activación del WAF para este vHost
        modsecurity on;

        location / {
            proxy_pass http://backend_upstream;
            proxy_set_header Host $host;
        }
    }
}

El archivo main.conf actúa como orquestador, cargando tanto la configuración del motor como el conjunto de reglas de OWASP:

# /etc/nginx/modsec/main.conf
Include /etc/nginx/modsec/modsecurity.conf
Include /usr/local/coreruleset/crs-setup.conf
Include /usr/local/coreruleset/rules/*.conf

Estrategias Avanzadas: Tuning y Observabilidad#

Implementar un WAF sin observabilidad es volar a ciegas. ModSecurity genera logs de auditoría en formato JSON o nativo. En arquitecturas empresariales, estos eventos deben ser ingestados por un SIEM (Security Information and Event Management) como Splunk, Elastic Security o Wazuh.

Parseo de Logs para Ingesta en Elastic/Logstash

Configurar ModSecurity para que genere logs en formato concurrente y estructurado:

# modsecurity.conf
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Concurrent
SecAuditLogFormat JSON
SecAuditLogStorageDir /var/log/modsec/audit/

[!WARNING] La directiva SecAuditEngine debe estar configurada en RelevantOnly en producción. Registrar todas las transacciones (On) consumirá rápidamente el I/O del disco y saturará los pipelines de ingestión de logs.

Excepciones de Reglas (Rule Tuning)

El falso positivo es el mayor enemigo de la operatividad. Si el WAF bloquea tráfico legítimo (por ejemplo, un campo JSON complejo interpretado como inyección SQL), se debe implementar una exclusión basada en ID de regla y URI:

# /etc/nginx/modsec/custom-exclusions.conf
# Excluir la regla 942100 para la ruta /api/v1/data en el argumento "payload"
SecRule REQUEST_URI "@beginsWith /api/v1/data" \
    "id:10001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:payload"

El correcto despliegue de ModSecurity requiere una fase de perfilado ("Detection Only") de al menos dos semanas, analizando comportamientos y afinando el CRS. Sólo tras estabilizar la tasa de falsos positivos se debe transicionar al modo de bloqueo ("SecRuleEngine On"), garantizando la resiliencia del negocio sin comprometer la integridad de las aplicaciones.