Fiches réflexes — gérer un incident sur le lab (exercice d’incident de la S7)

Document autonome. Préparation de l’exercice d’incident du vendredi 08/01/2027 (séance S7, réalisation R1, compétence 16 « identifier, qualifier et résoudre un incident ») : le formateur provoque une panne inconnue sur le lab ; il faut identifier, qualifier, résoudre ou escalader, puis écrire un rapport d’incident. Tâche 7.14 du suivi. Le modèle de rapport est dans Modele-rapport-incident.md. Les engagements (99 %, réponse en moins de 2 s, reprise en 4 h) et l’escalade sont ceux du contrat de service (dat/contrat-de-service.md). Adresses : Documentation-pfSense.md §2.

Dernière mise à jour : 12/11/2026 (fiches 4.12 à 4.17 : les 6 règles ajoutées depuis le 02/11 ; 11 services sondés)

Sommaire

1 · La méthode en cinq temps

  IDENTIFIER ──► QUALIFIER ──► RÉSOUDRE ou ESCALADER ──► VÉRIFIER ──► RAPPORTER
  quoi, depuis    gravité,       une hypothèse à la fois,   le service      symptôme → cause →
  quand, où ?     impact,        la plus probable d'abord   est revenu ?    correction → prévention
                  niveau

Noter l’heure de chaque étape au fil de l’eau (un fichier texte ouvert à côté suffit). Le délai de reprise (engagement : 4 h) se mesure entre l’alerte critique et le retour de la sonde à 1. Sans heures, pas de rapport.

Ne rien changer avant d’avoir regardé. Une correction faite au hasard efface les traces de la cause, et peut aggraver la panne (H-39 : relancer un cluster sans lire l’état des nœuds).

2 · Les deux premières minutes, quelle que soit la panne

Journaux des 15 dernières minutes, par machine (sur srv-supervision, compte en lecture seule) :

mariadb -h 127.0.0.1 -u grafana_lecture -p -e "SELECT hote, programme, gravite, LEFT(message,120) FROM syslog.journaux WHERE recu_le > UTC_TIMESTAMP() - INTERVAL 15 MINUTE AND gravite <= 4 ORDER BY recu_le DESC LIMIT 30;"

les erreurs (gravite 3) et avertissements (4) récents, avec la machine et le programme. Les heures de la base sont en UTC (heure de Paris − 1 h en hiver).

3 · Qualifier : gravité, impact, escalade

Trois questions pour qualifier : combien d’utilisateurs ou de services sont touchés ? Le service est-il coupé ou dégradé ? Y a-t-il un contournement (un nœud de secours, un second serveur web) ? Un service redondé qui perd un élément est dégradé, pas coupé : on le répare sans urgence, mais on le répare (il n’y a plus de secours).

4 · Les fiches, une par alerte

Chaque fiche : ce que ça veut dire, puis quoi vérifier, dans l’ordre, les causes probables, et le retour à la normale. Toutes les machines s’ouvrent par Termix (bastion 10.0.30.12) ; en dernier recours, la console Proxmox ne dépend d’aucun réseau.

4.1 Service injoignable (critique)

Sens : une sonde « comme un utilisateur » échoue depuis 2 min. L’étiquette service dit lequel (11 services au 12/11) : site web, GLPI, site public (par Internet), Matomo, PBS, DNS de l’AD, DNS de pfSense, LogAnalyzer, Termix, Pangolin, Wazuh.

Retour : mail [RESOLVED], sonde à 1, et le service testé depuis un poste (navigateur sur poste-win11).

4.2 Machine injoignable (critique)

Sens : Prometheus ne lit plus l’exporteur de la machine depuis 2 min. Ce n’est pas forcément la machine qui est tombée : ça peut être seulement son exporteur, ou le réseau entre les deux.

Causes vues : exporteur arrêté (test du 29/10), VM éteinte (test du 30/10), carte débranchée (test 7.11).

4.3 Galera incomplet (critique)

Sens : le cluster a moins de 3 nœuds. Avec 2 nœuds, le site marche (mode dégradé) ; avec 1 seul, il refuse d’écrire (non-Primary) et le site tombe. Si Grafana tombe aussi, seule l’alerte « Supervision aveugle » arrive, avec Error 1047 (H-66).

Sur chaque nœud (srv-mysql-01, 02, 03) :

sudo mariadb -e "SHOW STATUS WHERE Variable_name IN ('wsrep_cluster_size','wsrep_cluster_status','wsrep_local_state_comment','wsrep_ready');"

Retour : 3, Primary, Synced sur les trois nœuds, site à 200.

4.4 Sauvegarde trop ancienne (critique)

Sens : une VM n’a pas de sauvegarde de moins de 26 h (une nuit manquée).

Action : relancer une sauvegarde de la VM à la main (Backup now) une fois la cause corrigée. Retour : âge < 26 h.

4.5 Disque presque plein (avertissement, > 85 %)

df -h

sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -15

journalctl --disk-usage

Causes probables : journaux qui grossissent (un programme trop bavard, H-34), paquets en cache (sudo apt clean), fichier de test oublié. Sur srv-supervision, vérifier aussi que la purge des journaux tourne (systemctl list-timers purger-journaux.timer). Ne jamais supprimer dans /var/lib/mysql à la main.

4.6 Mémoire saturée (avertissement, > 90 % pendant 15 min)

D’abord vérifier que ce n’est pas l’hyperviseur (H-67) : si la mémoire totale de la VM a baissé, c’est le ballooning de Proxmox, pas un programme.

free -h

ps aux --sort=-%mem | head -8

Windows : Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 8 Name, @{n='Mo';e={int}}. Action : relancer le service fautif s’il fuit ; sinon, la VM manque réellement de mémoire (à augmenter dans Proxmox, en tenant compte de l’hyperviseur partagé).

4.7 Processeur saturé (avertissement, > 90 % pendant 15 min)

ps aux --sort=-%cpu | head -8

Windows : Get-Process | Sort-Object CPU -Descending | Select-Object -First 8 Name, CPU. Causes déjà vues : analyse de Windows Defender et défragmentation planifiée sur les VM Windows (étape 49.1). Un processus inconnu qui consomme tout peut aussi être un signe d’intrusion : noter son nom, son compte, sa ligne de commande avant de l’arrêter.

4.8 Datastore PBS presque plein (avertissement, > 80 %)

PBS → Datastore → Summary et Content. Vérifier que l’élagage (Prune, 7 jours) et le ramasse-miettes (Garbage Collection) tournent chaque nuit (Tasks). Une VM qui a beaucoup écrit (les VM Windows, étape 49.1) fait grossir le datastore. Action : réduire la rétention en dernier recours, après accord (niveau 2).

4.9 Connexions refusées en rafale (critique, ≥ 5 refus en 5 min sur une machine)

Sens : quelqu’un se trompe de mot de passe à répétition, ou essaie d’entrer. À traiter comme un incident de sécurité tant que ce n’est pas expliqué.

mariadb -h 127.0.0.1 -u grafana_lecture -p -e "SELECT recu_le, hote, LEFT(message,160) FROM syslog.journaux_auth WHERE recu_le > UTC_TIMESTAMP() - INTERVAL 30 MINUTE AND (message LIKE '%Failed password%' OR message LIKE '%invalid user%' OR message LIKE 'EventID 4625%' OR message LIKE 'EventID 4740%') ORDER BY recu_le DESC LIMIT 30;"

Action : si la source est inconnue ou extérieure, la bloquer (pfSense, ou sshguard déjà actif sur pfSense) ; changer le mot de passe du compte visé ; prévenir le niveau 2 (incident de sécurité). Si c’est une faute de frappe, le noter et clore.

4.10 Supervision aveugle (Grafana ne calcule plus les alertes) (critique)

Sens : Grafana n’arrive plus à exécuter ses requêtes : aucune autre alerte ne peut arriver tant que ça dure. Lire le champ Error du mail :

Pendant ce temps, surveiller à la main (sondes dans Prometheus, page d’état HAProxy).

4.11 Site lent (avertissement, > 2 s pendant 5 min)

4.12 lsyncd arrêté (avertissement, 5 min)

Sens : la recopie de wp-content (et des fichiers de GLPI et Matomo) de srv-web-01 vers srv-web-02 est arrêtée : le serveur de secours peut servir un site différent (H-84, étape 64).

4.13 Copie hors site trop ancienne (avertissement, > 30 h pendant 10 min)

Sens : la dernière copie d’au moins une VM sur le NAS d’Axel date de plus de 30 h : la synchronisation de 04:00 n’a pas tourné ou a échoué (étape 65 ; éprouvée par le test T30 le 11/11).

4.14 VM absente de la copie hors site (avertissement, 1 h)

Sens : une VM est sauvegardée dans le lab mais n’existe pas sur le NAS (nouvelle VM, ou synchronisation incomplète). Normal pour une machine nouvelle : la copie de la nuit suivante la rattrape et l’alerte se résout seule (test T30).

4.15 Copie hors site injoignable (avertissement, 15 min)

Sens : la sonde signée de srv-pbs (toutes les 5 min) n’atteint plus le S3 du NAS : Internet, la box, le reverse proxy du NAS, l’application SeaweedFS ou les clés (étape 65.2 ; test T30).

4.16 Intrusion détectée (Wazuh) (critique)

Sens : Wazuh a levé une alerte de niveau 10 ou plus, ou une création de compte. L’étiquette donne la machine et la règle. Toutes ne sont pas des attaques : une vulnérabilité « High » d’un poste neuf, ou un ajout au groupe Administrateurs fait par LAPS, sont aussi de niveau 10 et plus (11/11).

4.17 Serveur retiré par HAProxy (avertissement, 5 min)

Sens : HAProxy a retiré un serveur web (ou un nœud Galera) de son pool : son contrôle de santé échoue. Le site reste servi par l’autre ; les retraits pendant les sauvegardes durent 78 s au plus et ne déclenchent rien (étape 68).

5 · Quand aucune alerte n’arrive : la plainte d’un utilisateur

Une panne peut ne déclencher aucune alerte (ce que la supervision ne mesure pas). On part alors du poste qui se plaint, et on remonte couche par couche :

La première couche qui échoue désigne le coupable. Un refus immédiat = une règle de rejet ; une attente qui finit en délai dépassé = un blocage silencieux ou une machine absente (méthode du DAT §9.4). Ouverture de session refusée sur le domaine : heure du poste et de l’AD (Kerberos refuse plus de 5 min d’écart), compte verrouillé (4740).

6 · Les pièges déjà rencontrés

7 · S’entraîner avant le 08/01

Pannes plausibles (exemples pour s’entraîner, pas une liste de ce que fera le formateur) : un service arrêté (apache2, haproxy, mariadb, unbound), une VM éteinte, une règle pfSense désactivée, une carte réseau débranchée ou une mauvaise étiquette VLAN, un disque rempli, un compte verrouillé, une heure décalée.

Déjà vécues et documentées, avec leurs preuves : arrêt de Termix, exporteur arrêté, arrêt réel de srv-web-02, nœud Galera arrêté, perte de quorum (test 7.11 : un exemple de rapport rempli est dans le modèle), Prometheus arrêté, NAS saturé (H-61).

 Le modèle de rapport ouvert, un fichier de notes horodatées prêt
 Accès vérifiés le matin : Termix, Grafana, pfSense, Proxmox, page d'état HAProxy
 Boîte de l'administrateur ouverte (les mails d'alerte)
 Ce document et le Troubleshooting sous la main
 Règle d'or : regarder → une hypothèse → la tester → noter → corriger → vérifier comme un utilisateur

La règle à retenir en une phrase : on note l’heure, on lit l’alerte en entier, on teste une hypothèse à la fois en partant de ce qui touche le plus de monde, et on ne déclare la panne résolue qu’une fois le service revu comme un utilisateur.