Monitoring reseau

Quand un utilisateur tape beepass.io dans son navigateur, la requete traverse plusieurs couches avant d'atteindre le serveur. Chacune de ces couches peut etre source de problemes (certificat expire, configuration reseau incorrecte, attaque DDoS). La page de monitoring reseau permet de surveiller les deux couches principales de cette chaine : le reverse proxy Traefik (l'aiguilleur interne qui dirige chaque requete vers le bon service Docker) et le CDN Cloudflare (le bouclier externe qui filtre le trafic malveillant, met en cache les assets et gere le chiffrement SSL).

Traefik (Reverse Proxy)

Traefik agit comme un aiguilleur : chaque requete HTTP qui arrive sur le serveur est examinee et redirigee vers le bon service Docker. Une requete vers beepass.io va vers le frontend, une requete vers monitoring.beepass.io va vers Grafana, etc. Sans Traefik, il faudrait exposer chaque service sur un port different et les utilisateurs devraient taper des URLs comme beepass.io:3000 ou beepass.io:8090.

Traefik v3.6 est le point d'entree unique de toute l'infrastructure BeePass. Il route les requetes HTTP/HTTPS vers les containers Docker appropries et applique les middlewares de securite (des couches intermediaires qui ajoutent des headers, verifient des identifiants, etc.).

Architecture reseau

Voici le chemin complet d'une requete, depuis le navigateur de l'utilisateur jusqu'au service Docker :

Utilisateur
    |
    v
Cloudflare (WAF / DDoS / CDN / SSL edge)
    |
    v
Traefik v3.6 (SSL interne, Origin Certificate)
    |
    +-- beepass.io              --> beepass-web (:3000)
    +-- admin.beepass.io        --> beepass-web (:3000)  [ipallowlist 10.0.0.0/24]
    +-- monitoring.beepass.io   --> beepass-grafana (:3000)  [basicauth-admin]
    +-- beszel.beepass.io       --> beepass-beszel (:8090)
    +-- traefik.beepass.io      --> dashboard Traefik  [basicauth-admin]
    +-- beepass.io/docs/*       --> beepass-docs (:80)  [StripPrefix, priority=200]
    +-- beepass.io/support/*    --> beepass-peppermint (:3000)  [StripPrefix, priority=200]
    +-- beepass.io/support/api/* --> beepass-peppermint (:5003)  [StripPrefix, priority=210]

Configuration statique (`traefik.yml`)

Ce fichier definit le comportement de base de Traefik --- les points d'entree, les certificats SSL, les metriques. Il est lu une seule fois au demarrage :

api:
  dashboard: true
  insecure: false

ping: {}                                   # Requis pour healthcheck --ping

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
  websecure:
    address: ":443"
  metrics:
    address: ":8082"                       # Entrypoint interne (non expose)

providers:
  docker:
    exposedByDefault: false                # Routing explicite par labels uniquement
    network: traefik-public

certificatesResolvers: {}                  # Pas de Let's Encrypt (Cloudflare Origin Cert)

tls:
  certificates:
    - certFile: /certs/origin.pem          # Cloudflare Origin Certificate
      keyFile: /certs/origin-key.pem

metrics:
  prometheus:
    entryPoint: metrics

accessLog:
  format: json

log:
  level: ERROR                             # DEBUG en staging

Entrypoints

Les entrypoints sont les "portes d'entree" par lesquelles les requetes arrivent sur Traefik. La redirection automatique de HTTP vers HTTPS garantit que toutes les connexions sont chiffrees :

Entrypoint	Port	Role
`web`	80	HTTP --- redirection automatique vers `websecure` (HTTPS)
`websecure`	443	HTTPS --- terminaison TLS avec Cloudflare Origin Certificate
`metrics`	8082	Metriques Prometheus (interne uniquement, non expose publiquement)

Vue d'ensemble des metriques

Ces metriques permettent d'evaluer la charge reseau et de detecter des anomalies (pic de trafic, hausse du taux d'erreur pouvant indiquer une attaque ou un bug) :

Metrique	Description
Requetes HTTP totales	Nombre cumule de requetes traitees depuis le dernier redemarrage
Connexions ouvertes	Nombre de connexions TCP actuellement actives
Bande passante entrante	Volume de donnees recues (bytes in)
Bande passante sortante	Volume de donnees envoyees (bytes out)
Taux d'erreur	Pourcentage de reponses 4xx et 5xx sur le total des requetes

Routing par labels (docker-compose)

Traefik decouvre automatiquement les services Docker grace a des labels (des etiquettes de configuration) declares dans le fichier docker-compose.yml. Chaque service declare les domaines qu'il gere et les middlewares a appliquer :

Service	Host Rule	Middlewares	Priorite	Reseau
`beepass-web`	`Host(\`beepass.io`)`	`security-headers`	---	`traefik-public`
`beepass-web` (admin)	`Host(\`admin.beepass.io`)`	`security-headers`, `admin-no-cache`	150	`traefik-public`
`beepass-grafana`	`Host(\`monitoring.beepass.io`)`	`basicauth-admin`, `security-headers`	---	`traefik-public`
`beepass-beszel`	`Host(\`beszel.beepass.io`)`	`security-headers`	---	`traefik-public`
`traefik` (dashboard)	`Host(\`traefik.beepass.io`)`	`basicauth-admin`	---	interne
`beepass-docs`	`PathPrefix(\`/docs`)`	`stripprefix-docs`, `security-headers`	200	`traefik-public`
`beepass-peppermint`	`PathPrefix(\`/support`)`	`stripprefix-support`	200	`traefik-public`
`beepass-peppermint` (API)	`PathPrefix(\`/support/api`)`	`stripprefix-support`	210	`traefik-public`
`prometheus`	Non expose	---	---	`beepass-internal`
`node_exporter`	Non expose	---	---	`beepass-internal`
`postgres_exporter`	Non expose	---	---	`beepass-internal`

Priorite des routers

Traefik v3 calcule automatiquement la priorite des routers en fonction de la longueur de la regle. Pour les services sous-chemin (/docs, /support), une priorite explicite (200, 210) est necessaire pour eviter que Traefik ne route ces chemins vers beepass-web (regle plus generale Host(beepass.io)). Sans cette priorite, une requete vers beepass.io/docs/intro serait envoyee au frontend Next.js au lieu du site de documentation.

Middlewares actifs

Les middlewares sont des couches intermediaires que Traefik applique aux requetes avant de les transmettre au service cible. Ils ajoutent des headers de securite, verifient des identifiants, ou modifient les URLs :

Middleware	Type	Configuration
security-headers	Headers	HSTS (31536000s, includeSubdomains), X-Frame-Options DENY, X-Content-Type-Options nosniff, X-XSS-Protection
basicauth-admin	BasicAuth	Fichier htpasswd monte via Docker secrets (`/run/secrets/traefik_htpasswd`)
admin-no-cache	Headers	`Cache-Control: no-store, no-cache, must-revalidate, private` + `Pragma: no-cache` (defense en profondeur sur `admin.beepass.io`)
stripprefix-docs	StripPrefix	Supprime `/docs` avant forwarding vers Nginx (Nginx recoit `/intro` au lieu de `/docs/intro`)
stripprefix-support	StripPrefix	Supprime `/support` avant forwarding vers Peppermint

# Exemple de middlewares declares dans docker-compose.yml
- "traefik.http.middlewares.security-headers.headers.stsSeconds=31536000"
- "traefik.http.middlewares.security-headers.headers.stsIncludeSubdomains=true"
- "traefik.http.middlewares.security-headers.headers.frameDeny=true"
- "traefik.http.middlewares.security-headers.headers.contentTypeNosniff=true"
- "traefik.http.middlewares.security-headers.headers.browserXssFilter=true"
- "traefik.http.middlewares.admin-no-cache.headers.customResponseHeaders.Cache-Control=no-store, no-cache, must-revalidate, private"
- "traefik.http.middlewares.admin-no-cache.headers.customResponseHeaders.Pragma=no-cache"

Headers de securite (3 couches)

Pourquoi trois couches au lieu d'une seule ? Par principe de defense en profondeur : si une couche est mal configuree ou contournee, les autres prennent le relais. C'est comme avoir une serrure, un verrou et une alarme --- chacun fonctionne independamment :

Couche	Source	Headers
1. Next.js	`next.config.mjs` headers()	HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, CSP, X-DNS-Prefetch-Control. `poweredByHeader: false`.
2. Traefik	Middleware `security-headers`	HSTS, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection. Strip X-Powered-By.
3. Nginx (docs)	Configuration Nginx `beepass-docs`	Headers supplementaires pour le site de documentation

Cache-Control (2 couches)

Le cache permet d'accelerer le chargement des pages qui ne changent pas souvent (comme la liste des eleveurs), tout en garantissant que les pages dynamiques (comme le dashboard admin) affichent toujours les donnees les plus recentes :

Type	Routes	Header
Anti-cache	`/api/`, `/backoffice/`, `/auth/`, `/dashboard/`, `/theme-pages/*`	`no-store, no-cache, must-revalidate, private`
Cache public	`/q/`, `/breeders/`, `/pricing`	`public, max-age=3600, s-maxage=3600`

Couche principale dans next.config.mjs. Middleware Traefik admin-no-cache en defense en profondeur sur admin.beepass.io uniquement.

SEO Protection

Certaines pages (dashboard, backoffice, API) ne doivent jamais apparaitre dans les resultats de recherche Google. Le SEO protection empeche l'indexation des pages privees tout en autorisant celle des pages publiques :

robots.txt : Disallow sur toutes routes privees et template
X-Robots-Tag : noindex, nofollow, noarchive via next.config.mjs sur /dashboard/*, /apps/*, /auth/*, /backoffice/*, /api/*, /theme-pages/*
Pages indexables : /, /breeders, /pricing, /q/*, /contact, /status, /mentions-legales, /confidentialite, /cgu

Reseaux Docker

Docker utilise des reseaux virtuels pour isoler les services. Imaginez deux groupes de discussion : les services qui doivent etre accessibles depuis Internet sont dans le groupe "public", et les services internes communiquent dans un groupe "prive" :

Reseau	Services	Description
`traefik-public`	traefik, web, grafana, beszel, docs, peppermint	Expose via Traefik (ports 80/443) --- accessible depuis Internet
`beepass-internal`	web, worker, redis, prometheus, grafana, node_exporter, postgres_exporter	Communication inter-services uniquement --- invisible depuis Internet

web et grafana sont sur les deux reseaux : accessibles depuis Traefik (pour les utilisateurs) ET depuis les services internes (pour les communications inter-services).

Certificats TLS

Le certificat TLS (le "cadenas" dans la barre d'adresse) garantit que la connexion entre le navigateur et le serveur est chiffree. BeePass utilise un certificat Cloudflare Origin plutot que Let's Encrypt, car Cloudflare gere deja la connexion SSL cote utilisateur :

Information	Description
Type	Cloudflare Origin Certificate (wildcard `*.beepass.io` --- couvre tous les sous-domaines)
Duree	15 ans
Mode Cloudflare	Full (Strict) --- chiffrement verifie de bout en bout, du navigateur au serveur
Stockage	`infra/traefik/certs/origin.pem` + `origin-key.pem` (gitignored --- jamais commite dans le depot)
Let's Encrypt	Non utilise (Traefik est derriere Cloudflare, pas d'acces direct ACME)

Certificat Origin et proxy Cloudflare

Le certificat SSL est un Cloudflare Origin Certificate. Les navigateurs ne font pas confiance a ces certificats directement --- ils sont concu pour etre utilises uniquement entre Cloudflare et le serveur d'origine. Le proxy Cloudflare (nuage orange dans le dashboard Cloudflare) doit etre ON pour que la connexion HTTPS fonctionne. Si le proxy est desactive, les visiteurs verront une erreur de certificat dans leur navigateur.

TLS Hardening

Le TLS hardening (durcissement TLS) consiste a desactiver les anciennes versions du protocole SSL/TLS qui ont des failles de securite connues. Configuration dans infra/traefik/dynamic.yml :

tls:
  options:
    default:
      minVersion: VersionTLS12
      sniStrict: true
      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
        - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Exclusion automatique des containers unhealthy

Traefik v3 surveille le statut de sante Docker de chaque container. Un container marque unhealthy est automatiquement retire du pool de routing --- Traefik cesse de lui envoyer du trafic. Ce comportement protege les utilisateurs (ils ne tombent pas sur un service defaillant) mais signifie qu'un healthcheck mal configure rend le service completement inaccessible.

Cloudflare (CDN / WAF)

Cloudflare est la couche la plus externe de l'infrastructure --- le premier rempart entre les utilisateurs (et les attaquants) et le serveur BeePass. Il remplit trois roles principaux : CDN (Content Delivery Network --- met en cache les fichiers statiques sur des serveurs repartis dans le monde pour accelerer le chargement), WAF (Web Application Firewall --- pare-feu applicatif qui bloque les requetes malveillantes), et bouclier anti-DDoS (filtre les attaques par saturation).

Page admin dediee : /backoffice/cloudflare (sidebar MONITORING > Cloudflare) --- 8 onglets de gestion.

Les 8 onglets Cloudflare

Chaque onglet donne acces a un aspect different de la configuration Cloudflare, permettant de gerer l'ensemble sans quitter le backoffice BeePass :

Onglet	Description
Traffic	Analytics trafic via Cloudflare GraphQL API : requetes totales, bandwidth, menaces bloquees, repartition par pays, status codes HTTP
WAF	Evenements WAF recents : regles declenchees, IPs bloquees, actions (block, challenge, log)
Cache	Stats cache + purge (tout le cache ou URLs specifiques)
DNS	Enregistrements DNS de la zone (A, AAAA, CNAME, MX, TXT) --- l'annuaire qui traduit les noms de domaine en adresses IP
Security	Security level actuel + modification (essentially_off, low, medium, high, under_attack), regles firewall actives
SSL/TLS	SSL mode (off/flexible/full/strict), version TLS minimale (1.0-1.3), Always Use HTTPS toggle, certificate packs actifs
Performance	Toggles Brotli (compression), HTTP/2, HTTP/3, Early Hints, Rocket Loader + Auto Minify (JS/CSS/HTML) + Browser Cache TTL
Page Rules	Table read-only des page rules actives (priorite, pattern URL, actions, statut)

Routes API Cloudflare

10 routes sous /api/admin/cloudflare/ (auth HMAC admin) :

Route	Methode	Description
`/api/admin/cloudflare`	GET	Vue d'ensemble zone
`/api/admin/cloudflare/analytics`	GET	Trafic analytics GraphQL
`/api/admin/cloudflare/waf`	GET	Evenements WAF recents
`/api/admin/cloudflare/cache`	GET, POST	Stats cache + purge
`/api/admin/cloudflare/dns`	GET	Enregistrements DNS
`/api/admin/cloudflare/security`	GET, PUT	Security level
`/api/admin/cloudflare/firewall`	GET	Regles firewall actives
`/api/admin/cloudflare/ssl`	GET, PATCH	SSL mode, min TLS version, Always Use HTTPS, certificate packs
`/api/admin/cloudflare/performance`	GET, PATCH	Brotli, HTTP/2, HTTP/3, Early Hints, Rocket Loader, Auto Minify, Browser Cache TTL
`/api/admin/cloudflare/pagerules`	GET	Page rules actives

Prerequis

Variables d'environnement requises pour que le backoffice puisse communiquer avec l'API Cloudflare :

CLOUDFLARE_API_TOKEN=     # Token API (permissions Zone.Analytics, Zone.Firewall, Zone.DNS, Zone.Cache Purge, Zone.Zone Settings)
CLOUDFLARE_ZONE_ID=       # Zone ID pour beepass.io (identifiant unique de la zone DNS)

Cache DNS

Le cache Cloudflare evite au serveur BeePass de traiter des requetes pour des contenus qui n'ont pas change (images, CSS, JavaScript). Plus le hit ratio est eleve, moins le serveur est sollicite :

Information	Description
Statut du cache	Etat global du cache Cloudflare (actif/desactive)
Hit ratio	Pourcentage de requetes servies depuis le cache edge (les serveurs Cloudflare les plus proches de l'utilisateur)
Bandwidth saved	Volume de bande passante economisee grace au cache (trafic que le serveur n'a pas eu a servir)

WAF (Web Application Firewall)

Le WAF analyse chaque requete entrante pour detecter et bloquer les tentatives d'attaque (injections SQL, XSS, etc.) avant qu'elles n'atteignent le serveur. C'est un garde du corps qui filtre les visiteurs malveillants :

Element	Description
Regles actives	Configuration des regles WAF (managed rules gerees par Cloudflare, custom rules definies par l'admin)
Mode	`block` (bloque directement), `challenge` (demande une verification humaine) ou `simulate` (enregistre sans bloquer --- utile pour tester) par ensemble de regles
Exceptions	URL ou IP exemptees des controles WAF (ex : API interne qui genere des faux positifs)

Journal des evenements pare-feu

Ce journal enregistre chaque requete qui a declenche une regle du pare-feu. Il permet d'identifier les menaces recurrentes et d'ajuster les regles si necessaire :

Colonne	Description
Date	Horodatage de l'evenement
IP source	Adresse IP de l'attaquant potentiel
Action	`block` (bloque), `challenge` (captcha), `js_challenge` (verification JavaScript invisible), `managed_challenge` (Cloudflare decide automatiquement)
Regle	Identifiant de la regle WAF declenchee
URI	Chemin de la requete bloquee
Pays	Pays d'origine de la requete

Actions de cache

Lorsqu'un contenu change (nouveau deploiement, mise a jour d'une page), il peut etre necessaire de vider le cache pour que les utilisateurs voient immediatement la nouvelle version :

Action	Description
Purge URL individuelle	Invalide le cache pour une URL specifique (rapide, sans impact sur le reste)
Purge complete	Invalide l'ensemble du cache Cloudflare

Purge complete

Une purge complete du cache Cloudflare force le rechargement de tous les assets depuis le serveur origin. Cela genere un pic temporaire de charge sur le serveur Hetzner car toutes les requetes qui etaient servies par le cache devront etre traitees directement. Privilegiez la purge ciblee par URL lorsque possible.

Protection DDoS

Les attaques DDoS (Distributed Denial of Service) tentent de saturer le serveur avec un volume massif de requetes. Cloudflare absorbe ce trafic malveillant avant qu'il n'atteigne le serveur :

Statistique	Description
Attaques mitigees	Nombre d'attaques DDoS bloquees sur la periode
Volume bloque	Volume total de trafic malveillant filtre
Type d'attaque	Repartition par type (L3/L4 = attaques reseau, L7 = attaques applicatives, DNS amplification, etc.)

Commandes de diagnostic reseau

Ces commandes sont utiles pour diagnostiquer un probleme reseau depuis le serveur. Elles permettent de verifier que les certificats, les headers et les services fonctionnent correctement :

# Verifier le certificat SSL origin (confirme que Traefik utilise le bon certificat)
openssl s_client -connect 127.0.0.1:443 -servername beepass.io 2>/dev/null | openssl x509 -noout -issuer -subject

# Test HTTPS depuis l'exterieur (verifie que le site repond)
curl -I https://beepass.io

# Verifier les headers de securite (confirme que les 3 couches fonctionnent)
curl -sI https://beepass.io | grep -iE "(strict|x-frame|x-content|referrer|permissions|content-security)"

# Metriques Traefik (consulter les metriques Prometheus exposees par Traefik)
curl -s http://localhost:8082/metrics | head -50

# Logs Traefik (suivre les logs en temps reel pour diagnostiquer un probleme de routage)
docker compose logs -f beepass-traefik

# Verifier les routes actives (dashboard Traefik)
# Acces via https://traefik.beepass.io (basicAuth)

Voir aussi : Monitoring serveur | Monitoring operations | Centre de securite

Traefik (Reverse Proxy)​

Architecture reseau​

Configuration statique (traefik.yml)​

Entrypoints​

Vue d'ensemble des metriques​

Routing par labels (docker-compose)​

Middlewares actifs​

Headers de securite (3 couches)​

Cache-Control (2 couches)​

SEO Protection​

Reseaux Docker​

Certificats TLS​

TLS Hardening​

Cloudflare (CDN / WAF)​

Les 8 onglets Cloudflare​

Routes API Cloudflare​

Prerequis​

Cache DNS​

WAF (Web Application Firewall)​

Journal des evenements pare-feu​

Actions de cache​

Protection DDoS​

Commandes de diagnostic reseau​