# ExploitationFaire tourner le pare-feu en production : drills de bascule, revue de logs, tests de frontières, entretien.

## Drill de bascule trimestriel

L'intérêt même d'un setup HA dual-provider est que la bascule
fonctionne **quand l'uplink primaire tombe pour de vrai**. Le
seul moyen d'en avoir la certitude est de tester délibérément.

Cadence suggérée : **chaque trimestre**, pendant une fenêtre de
trafic faible, avec l'opérateur à la console.

Procédure :

1. Annoncer le drill sur le canal d'équipe — la bascule doit être
   invisible, mais si quelque chose tourne mal, vous voulez le
   savoir immédiatement.
2. Désactiver l'uplink primaire au niveau interface (pas au modem
   du fournisseur — cela simule le mauvais mode de panne).
3. En moins de cinq secondes, le moniteur de bascule devrait
   commuter la route par défaut sur le secondaire.
4. Vérifier la joignabilité externe : une requête depuis une
   zone doit toujours résoudre, télécharger et revenir.
5. Réactiver l'uplink primaire.
6. Le moniteur devrait rétablir la route par défaut sur le
   primaire dans son intervalle configuré.
7. Consigner le drill dans un logbook : date, time-to-detect,
   time-to-recover, tout ce qui est inhabituel.

Si la bascule prend plus longtemps que prévu, l'intervalle ou les
seuils du moniteur sont à ajuster. Si la bascule ne se produit
pas du tout, la config du moniteur est cassée — corriger avant de
rentrer. Un moniteur de bascule non fonctionnel est pire que pas
de moniteur du tout ; il donne à l'opérateur une fausse confiance.

## Revue des logs

Trois flux de logs comptent :

- **Événements pare-feu.** Décisions de drop, ajouts de table,
  état NAT. Bruyant pendant les scans de reconnaissance, calme en
  charge normale.
- **Événements offloading SSL.** Erreurs de terminaison, échecs
  de validation de certificats, verdicts du scanner. Des pics ici
  signifient que quelque chose a changé — rotation de certificat
  en amont, nouveau client qui ne fait pas confiance à la racine
  CA interne, ou un motif de malware qui a contourné un filtre
  précédent.
- **Événements du moniteur de bascule.** Transitions de lien.
  Devrait être vide la plupart des semaines. Des transitions
  fréquentes pointent un uplink instable — à remonter au
  fournisseur.

Habitude opérateur suggérée : un scan hebdomadaire de quinze
minutes de ces trois flux. Signaler tout ce qui est inhabituel,
créer des tickets de suivi pour la prochaine revue trimestrielle.

## Vérification des frontières de zones

Les zones sont définies dans le ruleset. Le ruleset peut être
incorrect. Le moyen de savoir lequel est vrai est de tester.

Cadence suggérée : **tous les six mois**, ou après tout
changement significatif du ruleset.

Pour chaque paire de zones (Clients ↔ DMZ, Clients ↔ VPN,
Anonymisation ↔ tout le reste, etc.) :

1. Depuis un host de la zone A, tenter de joindre un service de
   la zone B qui n'est pas censé être joignable.
2. Confirmer que la connexion échoue — TCP RST, ICMP
   unreachable ou timeout, selon le type de règle.
3. Consigner le résultat dans le même logbook.

Si un chemin attendu comme bloqué est joignable, c'est un bug de
règle. Corriger le jour même.

## Entretien de la blocklist

Les tables de blocklist grossissent dans le temps. Deux modes de
défaillance courants :

- **Entrées obsolètes.** Une IP qui était abusive il y a six
  mois est aujourd'hui une ligne DSL résidentielle avec un nouveau
  propriétaire. La rotation périodique du fichier blocklist (voir
  la doc [configuration d'Abusive HTTP
  Watch](../../abusive-http-watch/configuration/)) borne cela.
- **Drift de whitelist.** Les plages d'IP du bureau et du VPN
  changent dans le temps. Les entrées whitelist obsolètes ne
  causent pas d'incident directement, mais réduisent la valeur
  de la whitelist comme contrôle. Réviser le fichier whitelist
  chaque trimestre.

## Rotation de certificats

La couche de terminaison TLS utilise des certificats émis par la
[Sovereign Certificate Authority](../../sovereign-certificate-authority/).
La rotation est automatique via ACME, mais :

- **Confirmer la rotation** au moins mensuellement —
  `openssl s_client` contre la passerelle, vérifier que le
  `notAfter` du certificat est dans le futur, vérifier que la
  chaîne valide toujours contre la racine interne.
- **Tester la confiance client** après tout changement côté CA —
  choisir un client représentatif par zone, naviguer vers un
  service HTTPS dans le réseau, confirmer l'absence
  d'avertissement de certificat.

Mode de défaillance : une rotation réussit côté CA mais le
pare-feu ne reprend pas le nouveau certificat (rechargement de
config manquant, permissions de fichier incorrectes). Le cert
précédent reste valide un moment, masquant le bug. La
vérification mensuelle l'attrape.

## Entretien de routine

- **Patches OS.** Appliquer les patches de sécurité dans la
  fenêtre recommandée par le vendor. Redémarrer — le pare-feu
  n'est pas une appliance style cattle, mais un uptime au-delà
  de neuf mois invite des problèmes.
- **Revue de dépendances.** Les daemons Tor, I2P, Squid et
  Privoxy ont chacun leur cycle de patch. Suivre les releases
  amont.
- **Vérification de capacité.** Remplissage de la table d'état,
  CPU au pic, marge mémoire. Le pare-feu devrait tourner
  confortablement sous la moitié de sa capacité. Sinon,
  planifier le prochain renouvellement matériel.

## Quand ça casse

L'habitude opérateur la plus utile : **noter ce qui s'est passé**.

Une courte note par incident — quand, ce que vous avez vu, ce
que vous avez changé, ce qui a marché, ce qui n'a pas marché —
transforme un événement en gain permanent. La prochaine fois que
le même motif apparaît, la même personne ou son successeur le
résout en minutes au lieu d'heures.

Si l'incident dépasse l'expertise ou le temps disponible de votre
équipe, le service [Exploitation](/fr/services/support/) est le
chemin d'escalade.