Désactiver le service snmpd
Garantit que le service snmpd.service (agent SNMP) n'est ni activé au démarrage ni en cours d'exécution, sauf si la supervision SNMP est réellement nécessaire.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
L'agent SNMP (snmpd, UDP 161) expose des informations système détaillées, interfaces, routes, processus en cours, parfois tables ARP et de routage, à quiconque peut l'atteindre. SNMPv1/v2c utilisent une "community string" en clair comme unique identifiant, souvent laissée à la valeur par défaut public, ce qui divulgue des données aux renifleurs passifs et permet aux attaquants de cartographier l'hôte ; SNMP est aussi un réflecteur connu d'attaques DDoS par amplification UDP. Là où aucune supervision n'utilise SNMP, l'agent n'est qu'exposition. Si nécessaire, il ne doit tourner qu'en SNMPv3 (authentification + chiffrement) avec des ACL strictes ; sinon il doit être arrêté et désactivé.
Ce que vérifie Pavois
Pavois lit l'état effectif de snmpd.service depuis systemd, en vérifiant qu'il n'est ni enabled ni running. Cela reflète ce qui est réellement lié à l'UDP 161 indépendamment de l'existence de /etc/snmp/snmpd.conf, et détecte un démon démarré par une surcharge drop-in ou installé mais masqué. Une vérification de fichier/paquet ne peut pas indiquer l'état d'écoute réel.
describe service('snmpd.service') do
it { should_not be_enabled }
it { should_not be_running }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled snmpd.service et systemctl is-active snmpd.service ; attendez disabled/masked et inactive. Confirmez qu'aucun service n'écoute avec ss -ulnp | grep :161.
Inspecter et investiguer
Inspectez journalctl -u snmpd.service pour le démarrage/arrêt et l'activité des requêtes. systemctl show snmpd.service -p ActiveState -p UnitFileState donne l'état lisible par machine que Pavois vérifie. Confirmez la fermeture de l'UDP 161 avec ss -ulnp | grep :161.
Remédiation
Le plan de durcissement de Pavois agit sur la ressource service nommée snmpd avec les actions disable puis stop : il supprime l'activation au démarrage et arrête l'agent. Appliqué avec pavois harden apply. La configuration existante dans /etc/snmp/ reste intacte.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| action | disable, stop |
|---|---|
| name | snmpd |
| resource | service |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Désactiver snmpd empêche cet hôte d'être interrogé via SNMP : les plateformes de supervision (Zabbix, LibreNMS, Nagios, Cacti, PRTG…) perdront ses compteurs d'interfaces, métriques de santé et traps, déclenchant potentiellement des alertes « hôte injoignable ». Avant d'appliquer : confirmez que l'hôte n'est pas supervisé via SNMP, ou que la supervision dispose d'un agent alternatif (node_exporter, agent Zabbix). Si SNMP est requis, excluez cette règle et durcissez plutôt l'agent : SNMPv3 uniquement, pas de community par défaut, ACL par source. Désactiver snmpd n'affecte pas les émetteurs de traps SNMP sortants configurés ailleurs.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.1.15 | direct | per OS, see the benchmark table | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.