Désactiver le paramètre noyau d'acceptation des redirections ICMP sécurisées sur toutes les interfaces IPv4
Force net.ipv4.conf.all.secure_redirects à 0 afin que l'hôte rejette même les redirections ICMP « sécurisées » (celles des passerelles par défaut répertoriées) sur chaque interface IPv4.
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
secure_redirects permet à l'hôte d'accepter des messages de redirection ICMP, mais uniquement depuis les passerelles figurant dans sa liste de passerelles par défaut. Même cette forme restreinte réécrit la table de routage sur la base de paquets ICMP non authentifiés. Une redirection usurpée provenant (ou semblant provenir) d'une passerelle connue peut détourner le trafic via un saut contrôlé par un attaquant, permettant un homme du milieu. Les usages légitimes sont rares ; il convient donc de la désactiver (0) sauf nécessité absolue.
Ce que vérifie Pavois
Pavois lit la valeur d'exécution en direct de net.ipv4.conf.all.secure_redirects depuis le noyau (ressource InSpec kernel_parameter, équivalente à sysctl), et non un fichier /etc/sysctl.d/. Un drop-in pourrait déclarer 0 alors qu'un fichier ultérieur ou un sysctl -w à l'exécution l'a réactivé. Auditer le paramètre effectif montre ce que le noyau applique réellement aux redirections ICMP entrantes ; lire un fichier rate ces surcharges.
describe kernel_parameter('net.ipv4.conf.all.secure_redirects') do
its('value') { should cmp 0 }
end
describe command("grep -hsE '^[[:space:]]*net.ipv4.conf.all.secure_redirects[[:space:]]*=[[:space:]]*0([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez sysctl net.ipv4.conf.all.secure_redirects. Sortie attendue :
net.ipv4.conf.all.secure_redirects = 0
Inspecter et investiguer
Aucun journal dédié n'existe pour ce paramètre. Avec log_martians activé, les paquets anormaux liés aux redirections apparaissent via dmesg | grep -i martian et journalctl -k. Inspectez l'état avec sysctl net.ipv4.conf.all.secure_redirects et tous les réglages de redirection avec sysctl -a | grep redirects.
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour définir net.ipv4.conf.all.secure_redirects à 0, en l'appliquant au noyau en cours d'exécution et en le persistant dans un drop-in géré par Pavois sous /etc/sysctl.d/ afin qu'il survive au redémarrage. Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| key | net.ipv4.conf.all.secure_redirects |
|---|---|
| resource | sysctl |
| value | 0 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Désactiver les redirections sécurisées est sûr sur les hôtes terminaux et les serveurs ordinaires ; les réseaux modernes s'appuient sur des protocoles de routage, et non sur les redirections ICMP, pour converger. L'exception rare est un hôte qui dépend volontairement de sa passerelle envoyant des redirections pour optimiser les chemins. À noter que shared_media, s'il est activé, peut réactiver implicitement les redirections sécurisées, gardez les deux alignés (voir net.ipv4.conf.all.shared_media). Définir cette valeur à 0 ne présente aucun risque pour l'accès distant.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R12 | direct | 2.0 | haute |
| CIS | 1.4.3, 3.3.6, 3.3.1.10 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.20, CM-6(a), CM-7(a), CM-7(b), SC-7(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 1.4.3 | support | 4.0.1 | moyenne |
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.