Exploitation

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) 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. 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 est le chemin d’escalade.