Exercices corrigés de supervision type E6 et E7

1. La sécurité des ports détecte et bloque (le port passe en état err-disabled) et écrit un message dans le journal local du switch, mais elle n'envoie rien à personne : sans supervision, l'événement reste dans la mémoire du switch.

2. Envoyer un trap SNMPv3 au serveur de supervision au moment de la violation :

   textCopier le code de la réponse de l'exercice 1

   snmp-server group SUPERVISION v3 priv access SNMP-SUPERVISION
   snmp-server user zabbix SUPERVISION v3 auth sha <phrase d'authentification> priv aes 128 <phrase de chiffrement>
   snmp-server host 192.168.10.180 version 3 priv zabbix
   snmp-server enable traps port-security
   

   Côté serveur : snmptrapd reçoit le trap (utilisateur SNMPv3 déclaré avec l'engine ID du switch) et le transmet à Zabbix ; sur l'hôte SW-ETAGE1, un élément de type SNMP trap et un déclencheur de gravité High sur le trap de sécurité de port, avec une action qui alerte le service informatique par courriel. En complément, l'interrogation régulière de l'état des ports (modèle Cisco IOS by SNMP) signale le port passé à l'état down, même si le trap se perd. Enfin, envoyer aussi les journaux du switch au serveur de journaux (logging host 192.168.10.180).

3. Sur l'interface ADMIN de pfSense : source 192.168.10.211 (ou l'alias des équipements), destination 192.168.10.180, UDP 162, autoriser. Ce flux figure déjà dans la matrice de Sorbier. Si le serveur interroge aussi le switch : source 192.168.10.180, destination l'alias des équipements, UDP 161, sur l'interface SERVEURS. Pour les journaux du switch : source l'alias des équipements, destination 192.168.10.180, UDP 514 (syslog), sur l'interface ADMIN, à ajouter à la matrice ; le switch ne sait pas faire de syslog TLS, d'où ce flux en clair limité au réseau d'administration.

1. La supervision interroge pfSense en SNMP v1 ou v2c avec la communauté par défaut public : la communauté, qui sert de mot de passe, circule en clair dans chaque requête.
2. Toute personne qui capture le trafic, ou qui essaie simplement public (la valeur que testent tous les outils d'audit), peut lire les informations du pare-feu : interfaces, adresses, table de routage, nombre d'états, version. C'est une reconnaissance gratuite pour un attaquant. Si la communauté donnait aussi l'écriture, il pourrait modifier la configuration.
3. La meilleure : passer en SNMPv3 authPriv (paquet net-snmp sur pfSense, utilisateur en lecture seule, SHA et AES) et configurer l'hôte Zabbix en conséquence. La plus simple, si l'on garde le démon intégré : remplacer public par une communauté longue et aléatoire, limiter l'écoute à l'interface SERVEURS, et n'autoriser que 192.168.10.180 vers le pare-feu sur UDP 161 ; le risque résiduel (communauté en clair dans le VLAN des serveurs) doit être écrit et accepté par le responsable.

1. 30 × 1 440 = 43 200 minutes ; (1 − 0,998) × 43 200 = 86,4 minutes.
2. La maintenance du 14, annoncée quatre jours avant, est exclue. Indisponibilité comptée : 22 + 9 + 17 = 48 minutes. Disponibilité : (43 200 − 48) ÷ 43 200 = 99,889 %.
3. Oui, l'engagement est tenu : il reste 86,4 − 48 = 38,4 minutes de marge (le budget d'erreur). Si la maintenance n'avait pas été annoncée, on aurait compté 113 minutes, soit 99,74 %, et l'engagement aurait été dépassé de 26,6 minutes.
4. Avec un service (Services > Services) rattaché par un tag au déclencheur du scénario web, et un SLA (Services > SLA) : SLO 99,8, période mensuelle, planification 24 h sur 24, et la maintenance déclarée en temps d'arrêt exclu. Le rapport Services > SLA report donne chaque mois le SLI, les temps d'arrêt et le budget d'erreur restant.

Le flux 1 reste dans le VLAN 20 : il ne traverse pas le pare-feu, aucune règle n'est nécessaire. Le flux 3 est une exception à la règle de Sorbier « aucune zone n'ouvre de connexion vers ADMIN » : elle doit être limitée à la seule source 192.168.10.180 et au seul port UDP 161, et documentée. Toutes les règles sont des autorisations explicites, placées avant le blocage par défaut ; les réponses reviennent grâce au filtrage avec état.

1. Le pare-feu pfSense est injoignable : il route tous les VLAN et porte l'adresse publique. Tout ce qui traverse le pare-feu devient injoignable depuis srv-journaux : les switchs du VLAN 99 (SNMP), le serveur de la DMZ (agent actif qui ne peut plus envoyer), et le site public vu depuis Marseille (la redirection de port passe par pfSense).
2. Ils sont dans le même VLAN que srv-journaux : leurs échanges avec Zabbix ne passent pas par le pare-feu, ils restent supervisés et ne sont pas en panne. (Les postes, en revanche, n'atteignent plus les serveurs : il faut s'attendre à des appels.)
3. Des dépendances : les déclencheurs de disponibilité des switchs du VLAN 99, du serveur de la DMZ et du site public dépendent de « pfsense injoignable ». Une seule alerte serait partie, la bonne, avec la gravité Disaster.

Reformulation. « Superviser les services d'annuaire, de DNS et de DHCP des deux contrôleurs de domaine, du point de vue du service rendu ; alerter par courriel et Teams en moins de 5 minutes en cas de panne, et quand une étendue DHCP dépasse 90 % ; signaler le retour à la normale. »

Implicites et hypothèses.

• Un service démarré ne prouve pas qu'il répond : je teste aussi une résolution DNS et le port LDAP depuis srv-journaux.
• « En moins de 5 minutes » : intervalle d'une minute, alerte après trois mesures en échec (le modèle Windows) ou deux échecs consécutifs pour les tests DNS ; délai de livraison compris.
• Les deux contrôleurs sont dans le VLAN 20, comme srv-journaux : aucun flux à ouvrir sur pfSense ; seul le pare-feu Windows doit laisser passer le port 10050 (l'installeur de l'agent ajoute la règle).
• Teams : le flux Workflows demande une licence Microsoft 365 ; je vérifie qu'elle existe, sinon le courriel seul répond à la demande et je le signale.
• Le redémarrage d'un contrôleur pendant une maintenance ne doit pas alerter : je propose une période de maintenance pour les mises à jour mensuelles.

Spécifications techniques.

Cahier de recette.

1. Instantanés de srv-journaux et des deux contrôleurs de domaine (ou au moins de srv-journaux).
2. Sur srv-ad et srv-ad2 : installation silencieuse de l'agent 2 (msiexec … SERVER=192.168.10.180 HOSTNAME=srv-ad TLSCONNECT=psk TLSACCEPT=psk TLSPSKIDENTITY=PSK-srv-ad TLSPSKVALUE=…). Vérification : Get-Service "Zabbix Agent 2", puis depuis srv-journaux zabbix_get avec les options PSK.
3. Data collection > Hosts > Create host : srv-ad, groupe Serveurs Windows, modèle Windows by Zabbix agent, interface agent 192.168.10.177:10050, onglet Encryption en PSK, tag service: annuaire. Même chose pour srv-ad2.
4. Monitoring > Latest data : vérifier que les services NTDS, DNS et DHCPServer sont découverts (valeur 0).
5. Sur l'hôte srv-journaux : éléments net.dns[…] et Simple check LDAP, puis leurs déclencheurs High avec le tag service: annuaire.
6. Sur srv-ad : UserParameter dans zabbix_agent2.conf, Restart-Service "Zabbix Agent 2", test avec zabbix_get -k dhcp.scope.pused[192.168.10.64], puis élément et déclencheur.
7. Alerts > Media types : Email testé ; MS Teams Workflow activé ; macro {$ZABBIX.URL}. Utilisateur « Canal Supervision » avec le média Teams.
8. Alerts > Actions > Trigger actions : action « Annuaire », opérations et opérations de rétablissement.
9. Data collection > Maintenance : période mensuelle pour les mises à jour des contrôleurs.
10. Tests T1 à T6, heure de chaque événement notée ; contrôle dans Reports > Action log.
11. Procédure d'astreinte et rapport de test.

1. « Parce qu'un service peut être démarré sans répondre : une zone mal chargée, un port bloqué, un service figé. La requête DNS teste ce que voient les postes. L'incident de vendredi aurait été vu par les deux. »
2. « Le service est mesuré chaque minute et le déclencheur du modèle attend trois mesures en échec : environ 3 minutes. La requête DNS déclenche après 2 minutes. Avec l'envoi du courriel et du message Teams, l'alerte arrive en 3 à 4 minutes, dans les 5 minutes demandées. Je l'ai mesuré pendant la recette : 3 min 20 s au test T2. »
3. « Sans chiffrement, les valeurs et les noms des services circulent en clair, et une machine pourrait se faire passer pour le serveur Zabbix auprès de l'agent. La PSK chiffre et authentifie les deux côtés ; une clé par serveur limite les dégâts si l'une est volée. »
4. « Plus aucune alerte : c'est la limite de toute supervision. J'ai proposé un signal de vie : une tâche planifiée sur srv-journaux appelle chaque minute un moniteur externe, qui alerte si l'appel n'arrive plus. Ce n'est pas dans la demande, je l'ai noté en perspective. »

1. pfree est l'espace libre en pourcentage : « plus de 90 % libre » n'est pas un disque plein. Correction : min(/srv-fichiers/vfs.fs.size[D:,pused],5m)>90, ou max(/srv-fichiers/vfs.fs.size[D:,pfree],5m)<10.
2. max(…)>95 se déclenche au moindre pic : il suffit d'une mesure au-dessus de 95 en 10 minutes. Pour une saturation durable : min(/srv-gestion/system.cpu.util,10m)>95.
3. Un agent muet n'envoie pas 0, il n'envoie rien : last() garde la dernière valeur reçue (1) et le déclencheur ne s'allume jamais. Correction : nodata(/srv-web/agent.ping,3m)=1.
4. web.test.time est en secondes, pas en millisecondes : 3 000 secondes ne seront jamais atteintes. Et un seul échantillon lent ne fait pas un site lent. Correction : avg(/site-public/web.test.time[Suivi des livraisons,Accueil,resp],5m)>3.
5. L'élément est un débit (en bits par seconde après prétraitement), pas un pourcentage : le comparer à 90 n'a pas de sens. Pour un lien à 100 Mbit/s, 90 % font 90 000 000 bit/s : min(/R-MARSEILLE/net.if.out[ifHCOutOctets.1],5m)>90000000 (pas 90M : dans une expression, le suffixe M vaut 1 024 × 1 024), ou mieux, utiliser le déclencheur d'utilisation des modèles réseau, qui compare à la vitesse de l'interface avec la macro {$IF.UTIL.MAX}.

1. (last(/cert-suivi/cert.not_after) - now()) / 86400 < 21 : la différence entre la date d'expiration et l'instant présent, en jours. Gravité Warning (le modèle officiel fait la même chose avec la macro {$CERT.EXPIRY.WARN}).
2. fuzzytime(/Zabbix server/zabbix[proxy,prx-mrs,lastaccess],5m)=0 : la valeur (un horodatage) s'écarte de plus de 5 minutes de l'heure du serveur. Gravité High : toute l'agence n'est plus supervisée. (L'élément interne se crée sur l'hôte du serveur Zabbix.)
3. count(/srv-gestion/log[/var/log/gestion/app.log,FATAL],10m)>5 : count sans opérateur compte les valeurs reçues sur la période, et l'élément ne reçoit que les lignes qui contiennent FATAL. Gravité Average, OK event generation Expression (le problème se résout quand le compte retombe) ou fermeture manuelle.
4. fuzzytime(/srv-ad/system.localtime,30)=0. Gravité Warning, mais à surveiller de près : au-delà de 5 minutes d'écart, l'authentification Kerberos échoue.

1. La moyenne (18 %) montre un lien peu chargé la plupart du temps. Le 95e centile (71 %) dit que 95 % du temps, le débit reste sous 71 Mbit/s : les heures chargées restent confortables. Le maximum (99 %) et les six alertes révèlent une saturation brève et régulière, toujours au même moment.
2. Pas globalement : il est saturé par un phénomène précis, à heure fixe, qui ressemble à une tâche planifiée (synchronisation, sauvegarde, déploiement de mises à jour à midi).
3. Identifier le flux avec NetFlow (ou ntopng) sur ces créneaux ; le replanifier la nuit ou en limiter le débit (qualité de service) ; ne garder l'alerte que si la saturation dure, par exemple min(…,20m) ; et suivre le 95e centile mois par mois pour décider d'une augmentation quand il approchera durablement 80 %.

1. 90 % de 2 To = 1,8 To (en comptant 1 To = 1 000 Go). Reste : 1 800 − 1 460 = 340 Go. À 12 Go par jour ouvré : 340 ÷ 12 ≈ 28,3 jours ouvrés, soit environ 5,7 semaines (un peu moins de 6 semaines calendaires).
2. timeleft(/srv-fichiers/vfs.fs.size[D:,pused],30d,90)<30d : d'après la tendance des 30 derniers jours, le temps restant avant 90 % est inférieur à 30 jours. (Ici, l'alerte n'est pas encore active : sur une tendance calendaire de 12 × 5 ÷ 7 ≈ 8,6 Go par jour, il reste 340 ÷ 8,6 ≈ 40 jours. Elle s'allumera dans une dizaine de jours et laissera alors 30 jours pour agir.)
3. timeleft ajuste une droite sur les mesures de la période, week-ends compris : la croissance « par jour calendaire » est plus faible que par jour ouvré (12 × 5 ÷ 7 ≈ 8,6 Go), ce qui est cohérent si la période est assez longue. Mais une purge, l'arrivée d'un nouveau service, la fin d'un projet ou des clichés instantanés qui se suppriment cassent la tendance. La prévision est une aide à la décision, à confronter à la courbe et aux projets connus.