Comment mettre en place un WAF avec Kong Gateway

Avant d'activer quoi que ce soit, ayez les idées claires sur ce qu'est Kong et ce qu'il n'est pas. Kong est une passerelle d'API bâtie sur OpenResty/NGINX. Kong open source n'embarque ni moteur ModSecurity ni moteur Coraza et n'exécute pas l'OWASP Core Rule Set. La documentation WAF de Kong décrit le WAF comme une composition de plugins plutôt que comme un moteur de règles unique. Il existe trois approches réalistes :

• Composer les plugins de sécurité Kong (ce guide) : chaîner Injection Protection, JSON/XML Threat Protection, Bot Detection, IP Restriction, Rate Limiting et Request Size Limiting sur vos Services et vos Routes. Cela couvre les menaces API courantes, mais ce n'est pas du CRS.
• Placer un vrai WAF en frontal (managé/cloud) : pour une Dedicated Cloud Gateway publique, placez un CDN plus un WAF cloud (par exemple les règles managées AWS WAF sur CloudFront) en amont et validez le trafic d'origine. Couvert dans une étape ultérieure.
• Exécuter un plugin Coraza communautaire (auto-hébergé) : des projets communautaires embarquent le moteur OWASP Coraza et le CRS v4 dans Kong sous forme de plugin server. Ce n'est pas un plugin Kong officiel ; vous assumez la compilation et le support. Couvert dans une étape ultérieure.

Notez également la répartition par édition et par version : Bot Detection, IP Restriction, Rate Limiting et Request Size Limiting sont dans Kong open source, tandis qu'Injection Protection (Kong 3.9+), JSON Threat Protection (Kong 3.8+), XML Threat Protection (Kong 3.1+), Request Validator et Rate Limiting Advanced sont des plugins Enterprise / Konnect.

Commencez par les plugins fournis avec Kong open source. Ce kong.yaml déclaratif attache IP Restriction, Request Size Limiting et Bot Detection globalement, plus une limitation de débit de base sur un Service :

_format_version: "3.0"

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

plugins:
# Bloquer les corps surdimensionnés (renvoie HTTP 413)
- name: request-size-limiting
  config:
    allowed_payload_size: 10
    size_unit: megabytes
    require_content_length: false

# Bloquer les user agents malveillants connus par regex (renvoie HTTP 403)
- name: bot-detection
  config:
    deny:
    - "(C)|(c)url"
    - "python-requests"

# Refuser les plages source abusives (renvoie HTTP 403)
- name: ip-restriction
  config:
    deny:
    - 203.0.113.0/24
    status: 403
    message: "Access denied"

Ajoutez ensuite une limitation de débit par client. Sur Kong open source, utilisez le plugin Rate Limiting ; sur Enterprise/Konnect, préférez Rate Limiting Advanced pour les fenêtres glissantes et les compteurs partagés. Pour un nœud unique, strategy: local ne requiert aucun store externe. Pour plusieurs nœuds, utilisez strategy: redis, qui exige un bloc config.redis et fonctionne dans les déploiements hybrides, DB-less et 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

Le plugin Injection Protection (Enterprise / Konnect, Kong Gateway 3.9+) confronte le contenu des requêtes à des motifs regex intégrés pour les classes d'injection. C'est ce qui se rapproche le plus, dans Kong, de la détection WAF par signatures. Configurez les types d'injection et les emplacements de requête à inspecter, et démarrez en mode 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 référence de configuration liste l'ensemble complet des injection_types (sql, sql_low_sensitivity, js, java_exception, ssi, xpath_abbreviated, xpath_extended) et des locations (body, headers, path, path_and_query, query). Vous pouvez aussi ajouter des custom_injections avec un name et une regex pour des motifs propres à votre application. Notez les valeurs par défaut du plugin : enforcement_mode vaut block par défaut (pas log_only) et locations vaut [path_and_query] par défaut, si bien que les réglages explicites ci-dessus outrepassent les deux. Une copie partielle qui les omettrait bloquerait dès la première requête et ne scannerait jamais les corps de requête.

Les API sont attaquées via des charges utiles surdimensionnées et profondément imbriquées, autant que par des chaînes d'injection. Le plugin JSON Threat Protection (Kong 3.8+ ; la validation du corps en POST/PUT/PATCH exige Kong 3.10+) impose des limites structurelles aux corps 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 vous acceptez du XML, ajoutez le plugin XML Threat Protection (Kong 3.1+), qui plafonne de la même manière la profondeur des éléments, le nombre d'attributs et la taille des valeurs pour se défendre contre les attaques par bombe XML et par expansion d'entités. Notez une différence importante entre les deux : JSON Threat Protection propose une phase de journalisation seule via enforce_mode: log_only ; réglez-la d'abord si vous n'êtes pas sûr de la forme de vos charges utiles légitimes, puis basculez sur enforce_mode: block. XML Threat Protection n'a ni sélecteur de mode ni mode journalisation seule ; il bloque toujours en cas de violation d'une limite, validez donc soigneusement ses limites max_* contre des charges utiles XML réelles avant de l'activer.

La défense de couche applicative la plus forte que propose Kong est la validation positive : rejeter tout ce qui ne correspond pas à un schéma attendu. Le plugin Request Validator (Enterprise / Konnect) valide les corps de requête et les paramètres contre un JSON Schema (Draft 4, version: draft4) ou le schéma natif de Kong (version: kong) que vous fournissez directement par Route (éventuellement généré à partir d'une spécification OpenAPI avec deck file openapi2kong, un outil decK distinct, qui n'est pas une fonctionnalité du plugin lui-même) :

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

Parce qu'il met la structure en liste d'autorisation plutôt que de mettre en liste de blocage les attaques connues, un validateur de requêtes attrape des classes entières d'injection et de falsification de paramètres que la correspondance par signatures manque, au prix de la maintenance d'un schéma par Route.

Aucun des plugins ci-dessus n'exécute l'OWASP Core Rule Set. Si votre conformité ou votre modèle de menace exige le CRS, choisissez l'une des deux voies honnêtes :

Voie managée / cloud (Dedicated Cloud Gateways) : une Dedicated Cloud Gateway publique expose un nom d'hôte DNS, vous la placez donc derrière un CDN capable d'attacher un WAF cloud. Conformément au guide de sécurité réseau public de Kong, placez les règles managées AWS WAF sur une distribution CloudFront, puis verrouillez l'origine pour que le trafic ne puisse pas contourner le CDN. CloudFront injecte un en-tête à secret partagé et Kong l'exige :

# Rejeter toute requête qui n'est pas passée par le CDN
plugins:
- name: request-termination
  config:
    status_code: 403
    message: "Direct origin access denied"
# ...activé via une Route qui matche quand l'en-tête
# X-Origin-Verify est absent ou erroné.
# Mettez aussi en liste d'autorisation les plages de sortie du CDN :
- name: ip-restriction
  config:
    allow:
    - 130.176.0.0/16   # plage de sortie CDN d'exemple

Kong recommande de stocker la valeur de l'en-tête partagé dans un Vault et de la faire tourner périodiquement.

Voie auto-hébergée (plugin Coraza communautaire) : des projets communautaires embarquent le moteur OWASP Coraza et le CRS v4 dans Kong sous forme de plugin server Go, compatible avec les topologies hybrides, traditionnelles et DB-less. Vous construisez une image Kong personnalisée et activez le plugin server via des variables d'environnement, par exemple :

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

Le plugin se configure ensuite dynamiquement via l'Admin API avec des directives SecLang/CRS.

Poussez la config déclarative vers votre control plane avec decK, qui valide et synchronise l'état complet :

# Valider d'abord le fichier
deck gateway validate kong.yaml

# Le synchroniser vers Kong (Admin API ou control plane Konnect)
deck gateway sync kong.yaml

Vous pouvez aussi activer chaque plugin de façon impérative via l'Admin API ou l'interface Konnect. Confirmez que les plugins sont actifs sur votre Service ou votre Route :

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

Avec Injection Protection basculé sur enforcement_mode: block, envoyez des charges utiles d'attaque connues et confirmez que chaque plugin les rejette :

# Injection SQL dans la chaîne de requête (Injection Protection, 400)
curl -i 'http://localhost:8000/api?id=1%20OR%201=1'

# Injection SQL dans un corps 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 refusé (Bot Detection, 403)
curl -i -A 'python-requests/2.31' http://localhost:8000/api

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

# Flood au-delà de la limite (Rate Limiting, 429)
for i in $(seq 1 200); do \
  curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/api; done

# Une requête normale (devrait renvoyer 200)
curl -i 'http://localhost:8000/api?id=42'

Exécutez les plugins d'inspection réglables en mode journalisation seule pendant une à deux semaines et examinez les journaux de Kong pour repérer les requêtes légitimes qui auraient été rejetées. Injection Protection émet une ligne de journal structurée nommant le type de menace, l'action et l'emplacement pour chaque correspondance, c'est là que vous identifiez les faux positifs.

Réglez en restreignant les locations qu'Injection Protection inspecte, en assouplissant une limite max_* précise dans les plugins de protection contre les menaces, ou en affinant le body_schema de Request Validator afin que le trafic réel valide. Une fois les journaux propres, basculez enforcement_mode (Injection Protection) et enforce_mode (JSON Threat Protection) sur block et resynchronisez avec decK. XML Threat Protection n'a pas de mode journalisation seule et bloque déjà à la moindre violation, il n'y a donc rien à basculer là ; confirmez simplement que ses limites max_* correspondent à votre trafic XML réel avant sa mise en service.

# Après réglage, appliquer le blocage
deck gateway sync kong.yaml
# Surveiller les nouveaux faux positifs dans les journaux
kubectl logs -f deploy/kong-gateway   # ou logs docker/systemd