🛡️ DDoS / Bot Management — Protection L7, Bots & Abus Automatisés

La pyramide de défense

Ce qui casse les architectures en production

Références de départ

• OWASP Automated Threats to Web Applications
• OWASP API4:2023 — Unrestricted Resource Consumption
• Cloudflare — Proactive DDoS defense
• AWS — Protecting application layer with WAF rate-based rules

Indicateurs à corréler

• RPS par endpoint : moyenne, p95, p99, écart-type, cardinalité des IPs.
• Coût backend : CPU, DB QPS, cache hit ratio, queue depth, temps resolver GraphQL.
• Distribution : User-Agent, JA3/JA4, ASN, pays, TLS version, HTTP version.
• Comportement : ratio erreurs, absence de ressources statiques, absence de navigation humaine.

# Requête observabilité type — pseudo LogQL / SIEM
count_over_time({service="edge"} | json | path="/search" [1m]) by (ip, asn, ja4, country)
quantile_over_time(0.99, {service="api"} | json | unwrap latency_ms [5m]) by (route)

Contrôles progressifs

1. Cache agressif sur pages publiques et assets, respect stale-while-revalidate.
2. Rate limit par endpoint, pas seulement global.
3. Challenge adaptatif si score bot bas + endpoint cher + anomalie.
4. Circuit breaker : dégrader la recherche, couper génération PDF, mettre files d’attente.
5. Origin shielding : IP d’origine masquée, accès direct bloqué.

# NGINX — exemple défensif basique pour endpoint coûteux
limit_req_zone $binary_remote_addr zone=search_zone:20m rate=30r/m;
location /search {
    limit_req zone=search_zone burst=20 nodelay;
    proxy_cache my_cache;
    proxy_cache_valid 200 30s;
    proxy_pass http://app_backend;
}

Runbook de crise L7

Signaux utiles

• Réseau : ASN, IP réputation, proxy/VPN/Tor, datacenter vs résidentiel.
• TLS/HTTP : JA3/JA4, ALPN, ordre headers, HTTP/2 settings, accept-language incohérent.
• Client : JS telemetry, canvas/webgl, webdriver, timings, storage, plugins.
• Comportement : vitesse clics, séquence pages, absence assets, répétition paramètres.
• Identité : compte, token, device, cookie ancienneté, historique achat.

Réponses graduées

# Pseudo-politique
IF endpoint in ["/login", "/checkout", "/api/token"]
AND bot_score < 25
AND reputation in ["datacenter_proxy", "credential_stuffing_source"]
THEN challenge_or_block WITH reason="high_risk_bot_transaction"

Solutions typiques

• Cloudflare Bot solutions docs
• AWS WAF Bot Control
• Akamai Bot Manager
• Imperva Advanced Bot Protection

Mesurer autrement que par RPS

• Login : ratio échec/succès, usernames distincts par IP, IPs par username.
• Panier : add-to-cart sans checkout, hold duration, abandons synchronisés.
• Scraping : profondeur catalogue, ordre séquentiel, absence assets, bytes sortants.
• Checkout : refus paiement, BIN/card velocity, adresse de livraison répétée.
• API : coût unitaire par endpoint, quotas consommés, appels tiers déclenchés.

Contrôles centrés métier

# Pseudo-contrôle inventory abuse
IF product_drop=true
AND add_to_cart_per_device > 3 in 10m
AND checkout_completion_rate < 10%
THEN require_queue_token AND reduce_reservation_ttl

# Pseudo-contrôle scraping
IF pages_viewed_category > 200 in 5m
AND static_asset_ratio < 0.1
AND mouse_or_touch_events = 0
THEN throttle_to_1_rps AND serve_canary_links

Références

• OWASP Automated Threats to Web Applications
• OWASP Credential Stuffing Prevention Cheat Sheet
• OWASP API Security Project

Algorithmes classiques

Exemples concrets

# NGINX — login sensible
limit_req_zone $binary_remote_addr zone=login_ip:10m rate=5r/m;
limit_req_zone $http_authorization zone=login_token:10m rate=20r/m;

location = /login {
    limit_req zone=login_ip burst=5 nodelay;
    proxy_pass http://auth_backend;
}

// AWS WAF — extrait JSON défensif rate-based
{
  "Name": "RateLimitLoginByIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 300,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "TextTransformations": [{"Priority": 0, "Type": "NONE"}],
          "PositionalConstraint": "EXACTLY"
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Design propre

• Retourner 429 Too Many Requests avec Retry-After pour APIs légitimes.
• Utiliser count/log mode avant blocage.
• Prévoir des allowlists partenaires et des quotas contractuels.
• Différencier lecture publique, login, checkout, admin, API interne.
• Conserver les logs de décisions : règle, seuil, clé, fenêtre, score.

• Cloudflare — Rate limiting best practices
• AWS WAF — Rate-based rule statement

Télémétrie navigateur

Les solutions bot injectent souvent un script léger pour mesurer des signaux difficiles à reproduire parfaitement : événements, timings, rendu, stockage, intégrité navigateur, webdriver, cohérence platform/language/timezone.

// Pseudo-signal côté client — exemple pédagogique
{
  "events": {"mousemove": 42, "keydown": 8, "touch": 0},
  "timing": {"first_interaction_ms": 1320, "form_fill_ms": 8400},
  "env": {"webdriver": false, "timezone": "Europe/Paris", "lang": "fr-FR"},
  "integrity": {"cookie_age_days": 54, "local_storage": true}
}

Score composite

Un score fiable doit être expliqué : pourquoi un client a été challengé ou bloqué ? Sans raison exploitable, impossible de réduire les faux positifs.

Conformité et minimisation

• Documenter les signaux collectés et leur finalité sécurité.
• Limiter la conservation des fingerprints bruts ; préférer scores et raisons.
• Permettre une voie de support pour faux positifs.
• Éviter les décisions opaques sur fonctionnalités critiques sans fallback.

Friction proportionnée

Le bon modèle est progressif : laisser passer les clients sûrs, ralentir les suspects, challenger les risqués, bloquer les malveillants confirmés.

IF risk < 30      THEN allow
IF risk 30..60    THEN add_rate_limit AND log
IF risk 60..80    THEN managed_challenge
IF risk > 80      THEN block OR MFA_STEP_UP on sensitive endpoints

Préserver le business

• Ne jamais challenger les callbacks paiement/webhooks partenaires : utiliser mTLS/signature.
• Éviter CAPTCHA sur endpoints SEO et assets.
• Conserver une allowlist pour monitoring synthétique et partenaires.
• Tester accessibilité : lecteurs d’écran, faibles connexions, mobile ancien.
• Mettre une page d’erreur explicite avec identifiant de blocage support.

Politique par endpoint

Limiter par identité, pas uniquement par IP

# Exemple de quotas API
anonymous:       60 req/min/IP + endpoints lecture seulement
auth_user:       600 req/min/user + burst 100
partner_app:     quota contractuel par client_id + mTLS
tenant/org:      budget journalier + alertes 80/95/100%
expensive_route: coût = base + rows + external_calls + payload_size

Contrôles GraphQL

# Pseudo-policy GraphQL
max_depth: 8
max_complexity: 1000
max_aliases: 20
max_batch_operations: 5
introspection: disabled_in_prod_for_public_clients
persisted_queries: required_for_mobile_app

• Calculer un coût par champ/resolver.
• Refuser les aliases massifs.
• Limiter les variables de pagination.
• Journaliser operationName + hash de query.

Validation de contrat

# Exemple JSON Schema défensif
{
  "type": "object",
  "required": ["page", "page_size"],
  "properties": {
    "page": {"type": "integer", "minimum": 1, "maximum": 1000},
    "page_size": {"type": "integer", "minimum": 1, "maximum": 100},
    "sort": {"type": "string", "enum": ["date", "price", "name"]}
  },
  "additionalProperties": false
}

• OWASP API4:2023 — Unrestricted Resource Consumption

Défense multicouche

• Ne pas révéler si email existe.
• Détecter passwords compromis à l’inscription/changement.
• MFA adaptatif, pas MFA aveugle partout.
• Limiter username velocity et IP velocity.
• Surveiller changements sensibles post-login.

# Pseudo décision
IF login_success=true
AND device_new=true
AND ip_reputation="proxy"
AND country_distance_from_last_login > 2000km
THEN require_mfa_step_up AND mark_session_high_risk

Champs de logs indispensables

{
  "event":"login_attempt",
  "result":"failed",
  "username_hash":"sha256:...",
  "ip":"203.0.113.10",
  "asn":"AS64500",
  "device_id":"dvc_abc",
  "bot_score":18,
  "rule":"login_velocity_user_ip",
  "action":"challenge",
  "request_id":"req_123"
}

Runbook ATO

1. Passer login en challenge/rate-limit renforcé.
2. Identifier comptes avec succès anormal après échecs.
3. Forcer reset/MFA pour comptes à risque.
4. Bloquer IP/ASN uniquement si faible impact business.
5. Notifier support et fraude.

• OWASP Credential Stuffing Prevention Cheat Sheet

Scalping et drops

• Utiliser une file d’attente avec jeton signé.
• Limiter le nombre d’articles par compte/device/adresse/paiement.
• TTL de réservation court et renouvellement contrôlé.
• Détecter comptes fraîchement créés avant drop.
• Ralentir l’accès API stock/checkout.

# Pseudo token de queue
queue_token = HMAC(secret, user_id + device_id + drop_id + position + expires_at)
reject_if: expired OR reused OR mismatched_device OR position_not_reached

Honeypots défensifs

Les honeypots doivent être invisibles aux humains mais tentants pour les bots : liens CSS-hidden, champs formulaire invisibles, endpoints canary dans sitemap interne non public.

<a href="/product/__canary-price-feed" class="visually-hidden" aria-hidden="true" tabindex="-1"></a>

IF request.path contains "__canary"
THEN increase_bot_score(50) AND block_if_repeated

Mesurer l’effet

Empêcher le bypass de l’edge

• Firewall origine : n’autoriser que les ranges du CDN/WAAP.
• Utiliser mTLS entre edge et origin si possible.
• Changer IP origine après onboarding si déjà exposée.
• Surveiller accès direct Host header et IP brute.
• Désactiver DNS historiques et vieux sous-domaines.

# NGINX — exemple blocage Host/IP non attendu
if ($host !~* ^(www\.example\.com|api\.example\.com)$) { return 444; }

# Firewall cloud/on-prem : allowlist IP ranges fournisseur edge
# Deny all direct internet -> origin:443

Exemples d’offres edge

Plan de migration DNS

1. Basculer en mode monitor/log.
2. Réduire TTL DNS 24h avant.
3. Configurer certificats, Hostnames, cache, règles de base.
4. Tester chemins critiques : login, paiement, API, webhooks.
5. Changer DNS/CNAME.
6. Bloquer accès direct origine après validation.
7. Passer progressivement certaines règles en block.

Google Cloud Armor

Cloud Armor protège les applications derrière les load balancers Google Cloud avec politiques de sécurité, règles WAF, rate limiting et Adaptive Protection pour les attaques L7 à haut volume.

# Pseudo architecture GCP
Cloud DNS → Global External HTTPS Load Balancer + Cloud Armor → Cloud CDN → GKE/Cloud Run/Compute
Logs: Cloud Logging → BigQuery/SIEM

• Google Cloud Armor
• Cloud Armor Adaptive Protection overview

Azure Front Door / Application Gateway / DDoS Protection

• Azure Front Door WAF : protection edge globale pour HTTP/S.
• Application Gateway WAF : WAF régional proche workloads.
• Azure DDoS Protection : protection réseau pour ressources Azure exposées.
• Rate limit : selon combinaison WAF/policies/API Management.

# Pseudo architecture Azure
Azure Front Door + WAF → Private Link / App Gateway WAF → AKS/App Service/API Management
Logs: Diagnostic settings → Log Analytics / Sentinel

Quand choisir cloud provider vs edge SaaS ?

Contrôles reverse proxy

# NGINX — timeout anti-slow clients
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 15s;
large_client_header_buffers 4 8k;

# Protection méthodes
if ($request_method !~ ^(GET|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 405; }

# HAProxy — stick-table rate limit simplifié
frontend fe_https
  stick-table type ip size 1m expire 10m store http_req_rate(10s)
  http-request track-sc0 src
  http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
  default_backend app

F5 / NGINX App Protect DoS

Les solutions F5/NGINX ciblent le L7 DoS en environnement DevOps, avec déploiement sur NGINX Plus, Ingress Controller ou plus près des pods selon l’architecture.

# Exemple conceptuel NGINX App Protect DoS
# 1) Activer module DoS sur location critique
# 2) Associer policy JSON
# 3) Envoyer logs vers Prometheus/SIEM
location /api/ {
    app_protect_dos_enable on;
    app_protect_dos_policy_file /etc/app_protect_dos/api-policy.json;
    proxy_pass http://api_backend;
}

• F5 DoS for NGINX documentation

Limites du on-prem seul

• Ne peut pas absorber une attaque volumétrique supérieure à la bande passante opérateur.
• Peut protéger finement L7 mais doit être précédé d’un scrubbing en cas de gros volume.
• Nécessite HA, capacity planning, logs centralisés et playbooks d’urgence.

Ingress rate limit — exemple générique NGINX Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "10"
    nginx.ingress.kubernetes.io/limit-burst-multiplier: "5"
    nginx.ingress.kubernetes.io/proxy-body-size: "1m"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1/search
        pathType: Prefix
        backend:
          service:
            name: api
            port:
              number: 8080

Autoscaling ≠ protection

Scaler sous attaque peut transformer un incident disponibilité en facture cloud. L’autoscaling doit être couplé à des limites d’entrée, budgets, circuit breakers et backpressure.

• HPA sur CPU seul peut amplifier le coût.
• Limiter requêtes avant création massive de pods.
• Mettre des quotas namespaces et PDB.
• Protéger DB/cache, pas seulement pods web.
• Utiliser files/queues pour opérations coûteuses.

eBPF et runtime security

eBPF peut aider à observer et filtrer à bas niveau : connexions, drops, latences, appels réseau. Il complète mais ne remplace pas la logique L7/bot.

# Objectifs eBPF typiques
- détecter spikes connexions par pod/service
- appliquer network policies efficaces
- profiler latence réseau
- exporter métriques vers Prometheus/SIEM
- identifier origine interne d’un flood est-ouest

Exemples de règles défensives

# Cloudflare expression — exemple conceptuel
(http.request.uri.path eq "/login" and http.request.method eq "POST" and cf.bot_management.score lt 30)
→ Managed Challenge or Block depending on sensitivity

# ModSecurity CRS style — limiter méthodes inattendues
SecRule REQUEST_METHOD "!^(GET|POST|PUT|PATCH|DELETE|OPTIONS)$"   "id:100100,phase:1,deny,status:405,msg:'Unexpected HTTP method'"

Gérer les exceptions sans trouer la sécurité

• Exception par route précise, pas par domaine entier.
• Exception temporelle avec ticket et propriétaire.
• Conditionner par mTLS/IP/secret header pour partenaires.
• Loguer les exceptions autant que les blocages.
• Revue mensuelle des exceptions expirées.

Pipeline de changement

1. Créer règle en count/simulate.
2. Comparer faux positifs sur 24/72h.
3. Restreindre scope si besoin.
4. Activer block/challenge sur subset endpoints.
5. Ajouter dashboard et alerte.
6. Documenter raison et rollback.

Dashboard à construire

Alertes utiles

# Conditions d’alerte typiques
- blocked_requests > baseline * 5 for 5m
- origin_5xx_rate > 2% AND edge_allowed_rps > baseline * 3
- bot_score_lt_10 on /login > 1000 in 10m
- cache_hit_ratio drops below 40% on public pages
- WAF rule false_positive_report > threshold
- queue_depth/payment/login latency p99 critical

Postmortem DDoS/Bot

• Début/fin, volume, endpoints, pays/ASN, actions edge.
• Impact client : erreurs, latence, perte conversion.
• Règles activées, seuils, faux positifs, rollback.
• Coûts : cloud, SMS/email, DB, autoscaling.
• Mesures durables : cache, quotas, code app, runbook.

Runbook minute par minute

1. 0-5 min : confirmer attaque vs incident interne, ouvrir war room.
2. 5-10 min : identifier endpoints, actions edge temporaires.
3. 10-20 min : activer rate limits/challenges ciblés.
4. 20-40 min : protéger origine, cache, dégrader features coûteuses.
5. 40-60 min : analyser faux positifs, stabiliser règles.
6. Après : postmortem, durcissement durable.

Décider vite sans casser tout le business

Messages prêts

Interne:
Incident DDoS/Bot L7 en cours. Impact: latence sur /search et /login. Actions: rate limit ciblé + challenge adaptatif. Prochaine update dans 15 min.

Support:
Certains utilisateurs peuvent voir une vérification supplémentaire. Demander request_id ou code d’erreur pour analyse faux positif.

Post-incident:
L’incident est stabilisé. Les protections temporaires restent en surveillance 24h avant revue.

Rejouer le trafic réel

# Pipeline conceptuel de tuning
1. Exporter logs edge anonymisés
2. Étiqueter: legit / bot / partner / monitoring / attack
3. Simuler nouvelles règles en offline
4. Mesurer: block rate, false positive rate, coverage
5. Déployer en count mode
6. Activer progressivement

KPIs de qualité

Exercices Purple Team

• Credential stuffing simulé avec comptes de test.
• Scraping de catalogue factice.
• HTTP flood contrôlé sur endpoint staging.
• GraphQL complexity sur queries de test.
• Bypass origine : vérification firewall/mTLS.
• Incident tabletop avec décisions de blocage.

Cloud provider-native

On-prem / ADC / Kubernetes

Questions à poser au fournisseur

• Détection bot : quels signaux exacts ? score explicable ? mobile/API couverts ?
• DDoS L7 : mitigation automatique ? baselines ? time-to-mitigate ?
• Rate limiting : clés composites, par token/user/org ? fenêtres ? logs ?
• Déploiement : SaaS, private edge, on-prem, Kubernetes ?
• Origin protection : mTLS, IP ranges, private link ?
• Observabilité : logs bruts, SIEM, dashboards, API, rétention ?
• Faux positifs : workflow d’exception, mode count, simulation offline ?