Cómo configurar un WAF con Kong Gateway

Antes de habilitar nada, ten claro qué es Kong y qué no es. Kong es un API gateway construido sobre OpenResty/NGINX. El Kong de código abierto no incluye ningún motor de ModSecurity o Coraza y no ejecuta el OWASP Core Rule Set. La documentación de WAF de Kong describe el WAF como una composición de plugins, no como un único motor de reglas. Existen tres enfoques realistas:

• Componer plugins de seguridad de Kong (esta guía): Encadena Injection Protection, JSON/XML Threat Protection, Bot Detection, IP Restriction, Rate Limiting y Request Size Limiting sobre tus Services y Routes. Esto cubre amenazas comunes de API, pero no es CRS.
• Poner un WAF real por delante del gateway (gestionado/en la nube): Para un Dedicated Cloud Gateway público, coloca por delante un CDN más un WAF en la nube (por ejemplo, las managed rules de AWS WAF en CloudFront) y valida el tráfico de origen. Se cubre en un paso posterior.
• Ejecutar un plugin comunitario de Coraza (autoalojado): Proyectos de la comunidad integran el motor OWASP Coraza y el CRS v4 en Kong como un plugin server. No es un plugin oficial de Kong; tú te haces cargo de la compilación y del soporte. Se cubre en un paso posterior.

Ten en cuenta también la división por tier y versión: Bot Detection, IP Restriction, Rate Limiting y Request Size Limiting están en el Kong de código abierto, mientras que Injection Protection (Kong 3.9+), JSON Threat Protection (Kong 3.8+), XML Threat Protection (Kong 3.1+), Request Validator y Rate Limiting Advanced son plugins de Enterprise / Konnect.

Empieza con los plugins incluidos en el Kong de código abierto. Este kong.yaml declarativo asocia IP Restriction, Request Size Limiting y Bot Detection de forma global, más un Rate Limiting básico sobre un Service:

_format_version: "3.0"

services:
- name: my-api
  url: http://upstream:8080
  routes:
  - name: my-api-route
    paths:
    - /api

plugins:
# Bloquea cuerpos sobredimensionados (devuelve HTTP 413)
- name: request-size-limiting
  config:
    allowed_payload_size: 10
    size_unit: megabytes
    require_content_length: false

# Bloquea user agents maliciosos conocidos por regex (devuelve HTTP 403)
- name: bot-detection
  config:
    deny:
    - "(C)|(c)url"
    - "python-requests"

# Deniega rangos de origen abusivos (devuelve HTTP 403)
- name: ip-restriction
  config:
    deny:
    - 203.0.113.0/24
    status: 403
    message: "Access denied"

Después añade el límite de tasa por cliente. En el Kong de código abierto usa el plugin Rate Limiting; en Enterprise/Konnect prefiere Rate Limiting Advanced por sus ventanas deslizantes y contadores compartidos. Para un único nodo, strategy: local no necesita almacenamiento externo. Para varios nodos, usa strategy: redis, que requiere un bloque config.redis y funciona en despliegues híbridos, DB-less y Konnect:

plugins:
- name: rate-limiting-advanced
  service: my-api
  config:
    limit:
    - 100
    window_size:
    - 60
    window_type: sliding
    identifier: ip
    strategy: redis
    sync_rate: 1
    redis:
      host: redis
      port: 6379

El plugin Injection Protection (Enterprise / Konnect, Kong Gateway 3.9+) coteja el contenido de la petición contra patrones regex integrados para clases de inyección. Es lo más parecido a la detección WAF basada en firmas que Kong incluye. Configura qué tipos de inyección y qué ubicaciones de la petición inspeccionar, y empieza en modo log_only:

plugins:
- name: injection-protection
  service: my-api
  config:
    injection_types:
    - sql
    - js
    locations:
    - path_and_query
    - body
    - headers
    enforcement_mode: log_only
    error_status_code: 400
    error_message: "Bad Request"

La referencia de configuración enumera el conjunto completo de injection_types (sql, sql_low_sensitivity, js, java_exception, ssi, xpath_abbreviated, xpath_extended) y de locations (body, headers, path, path_and_query, query). También puedes añadir custom_injections con un name y un regex para patrones específicos de tu aplicación. Ten en cuenta los valores por defecto del plugin: enforcement_mode es block por defecto (no log_only) y locations es [path_and_query] por defecto, así que los ajustes explícitos anteriores sobrescriben ambos. Una copia parcial que los omita bloqueará desde la primera petición y nunca escaneará los cuerpos de las peticiones.

Las APIs se atacan tanto con cargas sobredimensionadas y anidadas en exceso como con cadenas de inyección. El plugin JSON Threat Protection (Kong 3.8+; la validación del cuerpo en POST/PUT/PATCH requiere Kong 3.10+) impone límites estructurales sobre los cuerpos JSON:

plugins:
- name: json-threat-protection
  service: my-api
  config:
    max_body_size: 1000000
    max_container_depth: 20
    max_object_entry_count: 100
    max_object_entry_name_length: 100
    max_array_element_count: 1000
    max_string_value_length: 10000
    enforce_mode: block
    error_status_code: 400

Si aceptas XML, añade el plugin XML Threat Protection (Kong 3.1+), que de forma similar limita la profundidad de elementos, el número de atributos y el tamaño de los valores para defenderte de ataques de XML bomb y de expansión de entidades. Ten en cuenta una diferencia importante entre ambos: JSON Threat Protection admite una fase de solo registro mediante enforce_mode: log_only, así que actívala primero si no estás seguro de la forma de tus cargas legítimas, y luego cambia a enforce_mode: block. XML Threat Protection no tiene modo de aplicación (enforce mode) ni modo de solo registro; siempre bloquea ante una violación de límite, así que valida con cuidado sus límites max_* contra cargas XML reales antes de habilitarlo.

La defensa más fuerte a nivel de API que ofrece Kong es la validación positiva: rechazar todo lo que no coincida con un esquema esperado. El plugin Request Validator (Enterprise / Konnect) valida los cuerpos y parámetros de las peticiones contra un JSON Schema (Draft 4, version: draft4) o el esquema nativo de Kong (version: kong) que proporcionas directamente por Route (opcionalmente generado a partir de una especificación OpenAPI con deck file openapi2kong, una herramienta de decK independiente, no una función del propio plugin):

plugins:
- name: request-validator
  route: my-api-route
  config:
    version: draft4
    body_schema: |
      {
        "type": "object",
        "required": ["id"],
        "properties": {
          "id": { "type": "integer", "minimum": 1 }
        },
        "additionalProperties": false
      }
    allowed_content_types:
    - application/json
    verbose_response: false

Como aplica una lista de permitidos sobre la estructura en lugar de una lista de bloqueo de ataques conocidos, un request validator captura clases enteras de inyección y manipulación de parámetros que el cotejo por firmas se pierde, a cambio de mantener un esquema por Route.

Ninguno de los plugins anteriores ejecuta el OWASP Core Rule Set. Si tu cumplimiento normativo o tu modelo de amenazas exige CRS, elige una de las dos rutas honestas:

Ruta gestionada / en la nube (Dedicated Cloud Gateways): Un Dedicated Cloud Gateway público expone un nombre de host DNS, así que pones por delante un CDN capaz de asociar un WAF en la nube. Según la guía de seguridad de red pública de Kong, coloca las managed rules de AWS WAF en una distribución de CloudFront y luego blinda el origen para que el tráfico no pueda saltarse el CDN. CloudFront inyecta una cabecera con un secreto compartido y Kong la exige:

# Rechaza cualquier petición que no haya pasado por el CDN
plugins:
- name: request-termination
  config:
    status_code: 403
    message: "Direct origin access denied"
# ...habilitado mediante una Route que hace match cuando la
# cabecera X-Origin-Verify falta o es incorrecta.
# Añade también a la lista de permitidos los rangos de egress del CDN:
- name: ip-restriction
  config:
    allow:
    - 130.176.0.0/16   # rango de egress de CDN de ejemplo

Kong recomienda almacenar el valor de la cabecera secreta en un Vault y rotarlo periódicamente.

Ruta autoalojada (plugin comunitario de Coraza): Proyectos de la comunidad integran el motor OWASP Coraza y el CRS v4 en Kong como un plugin server en Go, compatible con topologías híbridas, tradicionales y DB-less. Compilas una imagen de Kong personalizada y habilitas el plugin server mediante variables de entorno, por ejemplo:

KONG_PLUGINS=bundled,kong-waf
KONG_PLUGINSERVER_NAMES=kong-waf
KONG_PLUGINSERVER_KONG_WAF_QUERY_CMD="/usr/local/bin/kong-waf -dump"

El plugin se configura luego de forma dinámica a través de la Admin API con directivas SecLang/CRS.

Envía la configuración declarativa a tu control plane con decK, que valida y sincroniza el estado completo:

# Valida primero el archivo
deck gateway validate kong.yaml

# Sincronízalo con Kong (Admin API o control plane de Konnect)
deck gateway sync kong.yaml

También puedes habilitar cada plugin de forma imperativa a través de la Admin API o de la interfaz de Konnect. Confirma que los plugins están activos en tu Service o Route:

curl -s http://localhost:8001/plugins | \
  grep -o '"name":"[^"]*"'

Con Injection Protection cambiado a enforcement_mode: block, envía cargas de ataque conocidas y confirma que cada plugin las rechaza:

# Inyección SQL en la query string (Injection Protection, 400)
curl -i 'http://localhost:8000/api?id=1%20OR%201=1'

# Inyección SQL en un cuerpo JSON (Injection Protection, 400)
curl -i -X POST http://localhost:8000/api \
  -H 'Content-Type: application/json' \
  -d '{"id":"1 OR 1=1"}'

# User agent de bot denegado (Bot Detection, 403)
curl -i -A 'python-requests/2.31' http://localhost:8000/api

# Cuerpo sobredimensionado (Request Size Limiting, 413)
head -c 20000000 /dev/zero | \
  curl -i -X POST --data-binary @- http://localhost:8000/api

# Inundación por encima del límite (Rate Limiting, 429)
for i in $(seq 1 200); do \
  curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/api; done

# Una petición normal (debería devolver 200)
curl -i 'http://localhost:8000/api?id=42'

Ejecuta los plugins de inspección ajustables en modo de solo registro durante una o dos semanas y revisa los logs de Kong en busca de peticiones legítimas que habrían sido rechazadas. Injection Protection emite una línea de log estructurada nombrando el tipo de amenaza, la acción y la ubicación en cada coincidencia, y ahí es donde identificas los falsos positivos.

Ajusta acotando las locations que inspecciona Injection Protection, relajando un límite max_* concreto en los plugins de threat protection, o refinando el body_schema en Request Validator para que el tráfico real valide. Una vez que los logs estén limpios, cambia a block el enforcement_mode de Injection Protection y el enforce_mode de JSON Threat Protection, y vuelve a sincronizar con decK. XML Threat Protection no tiene modo de solo registro y ya bloquea ante cualquier violación, así que ahí no hay nada que cambiar; solo confirma que sus límites max_* coinciden con tu tráfico XML real antes de que entre en producción.

# Tras el ajuste, aplica el bloqueo
deck gateway sync kong.yaml
# Vigila nuevos falsos positivos en los logs
kubectl logs -f deploy/kong-gateway   # o logs de docker/systemd