Traefik — TLS, middlewares de sécurité et rate limiting

Durcissement d’un reverse proxy Traefik v3 : options TLS, middlewares d’en-têtes de sécurité et limitation de débit.

Contexte

Traefik applique la configuration TLS via des TLSOption et les politiques de sécurité via des middlewares chaînés sur les routeurs. Une TLSOption par défaut trop permissive et l’absence de middleware d’en-têtes laissent les services exposés sans HSTS ni protection transverse. Le rate limiting et l’IPAllowList se déclarent en middlewares réutilisables.

Détection

Inventaire des routeurs et middlewares actifs via l’API Traefik :

curl -s http://127.0.0.1:8080/api/http/routers | jq -r '.[] | "\(.name) -> \(.middlewares // [])"'
curl -s http://127.0.0.1:8080/api/http/middlewares | jq -r '.[].name'

Audit des en-têtes renvoyés et de la version TLS négociée par une route :

curl -sI https://app.exemple.fr/ | grep -iE 'strict-transport|content-security|x-content-type'
openssl s_client -connect app.exemple.fr:443 -tls1_3 </dev/null 2>&1 | grep -i 'TLSv1.3'

Durcissement

TLSOption moderne (configuration dynamique, fichier ou CRD) imposant TLS 1.2 minimum et des suites AEAD :

tls:
  options:
    moderne:
      minVersion: VersionTLS12
      cipherSuites:
        - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
        - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
      curvePreferences:
        - CurveP384
        - X25519
      sniStrict: true

Middlewares de sécurité : en-têtes, rate limit et restriction par IP :

http:
  middlewares:
    secure-headers:
      headers:
        stsSeconds: 63072000
        stsIncludeSubdomains: true
        stsPreload: true
        contentTypeNosniff: true
        referrerPolicy: "strict-origin-when-cross-origin"
        customResponseHeaders:
          Content-Security-Policy: "default-src 'self'; frame-ancestors 'self'"
          Permissions-Policy: "geolocation=(), camera=(), microphone=()"
          X-Frame-Options: "SAMEORIGIN"
    rate-limit:
      rateLimit:
        average: 30
        burst: 20
        period: 1s
    admin-allowlist:
      ipAllowList:
        sourceRange:
          - "192.0.2.0/24"
          - "198.51.100.10/32"

Application des middlewares et de la TLSOption sur un routeur (labels Docker) :

labels:
  - "traefik.http.routers.app.middlewares=secure-headers@file,rate-limit@file"
  - "traefik.http.routers.app.tls.options=moderne@file"
  - "traefik.http.routers.admin.middlewares=admin-allowlist@file,secure-headers@file"

En environnement Kubernetes derrière une couche SNAT, l’IPAllowList doit utiliser ipStrategy.depth ou excludedIPs correctement réglés pour lire la véritable IP source dans X-Forwarded-For, sinon toutes les requêtes apparaissent depuis l’IP du proxy.

Vérification

Confirmation des en-têtes et du refus des protocoles obsolètes :

curl -sI https://app.exemple.fr/ | grep -i strict-transport
openssl s_client -connect app.exemple.fr:443 -tls1_1 </dev/null 2>&1 | grep -i 'handshake failure'

Test du rate limiting (apparition de 429) et de l’IPAllowList (403 hors plage) :

for i in $(seq 1 40); do curl -s -o /dev/null -w '%{http_code} ' https://app.exemple.fr/; done; echo
curl -s -o /dev/null -w '%{http_code}\n' https://admin.exemple.fr/ --resolve admin.exemple.fr:443:192.0.2.1

Les requêtes au-delà du burst doivent renvoyer 429 et l’accès admin depuis une IP hors plage renvoyer 403.