Désactiver l'acceptation des redirections ICMP sur toutes les interfaces IPv4
Définit net.ipv4.conf.all.accept_redirects=0 pour que l'hôte ignore les messages de redirection ICMP non authentifiés susceptibles de détourner son trafic.
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
Les messages de redirection ICMP permettent à un routeur d'indiquer à un hôte qu'une route plus directe existe pour une destination, et l'hôte réécrit sa table de routage en conséquence. Ces messages sont non authentifiés : n'importe quel équipement du segment peut en forger un. Un attaquant qui injecte une redirection ICMP malveillante peut silencieusement faire transiter le trafic de l'hôte par une machine qu'il contrôle, permettant une interception de type homme du milieu ou un déni de service. Cette fonctionnalité a très peu d'usages légitimes sur les réseaux modernes ; il faut donc définir net.ipv4.conf.all.accept_redirects=0 pour les ignorer.
Ce que vérifie Pavois
Pavois lit la valeur noyau effective via kernel_parameter('net.ipv4.conf.all.accept_redirects') et vérifie qu'elle vaut 0. Lire la valeur effective prouve que le noyau ignore réellement les redirections à l'instant présent, un drop-in écrit mais non rechargé, ou masqué par un autre fichier de sysctl.d, laisserait sinon l'hôte accepter les redirections malgré un fichier de configuration d'apparence correcte. Les scanners basés sur les fichiers ratent précisément cet écart.
describe kernel_parameter('net.ipv4.conf.all.accept_redirects') do
its('value') { should cmp 0 }
end
describe command("grep -hsE '^[[:space:]]*net.ipv4.conf.all.accept_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.accept_redirects. Sortie attendue :
net.ipv4.conf.all.accept_redirects = 0
Inspecter et investiguer
sysctl net.ipv4.conf.all.accept_redirectsaffiche la valeur courante.cat /proc/sys/net/ipv4/conf/all/accept_redirectsest la valeur brute du noyau.- Vérifiez aussi les valeurs effectives par interface avec
sysctl -a | grep accept_redirects, car la cléallet la clé d'interface se combinent. Les redirections forgées qui auraient été journalisées requièrentlog_martians; les changements de route acceptés peuvent être observés avecip route show cache.
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour positionner net.ipv4.conf.all.accept_redirects à 0. Il écrit la clé dans un drop-in géré par Pavois puis le recharge, de sorte que l'hôte cesse d'honorer les redirections ICMP immédiatement et après 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.accept_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
Sur la grande majorité des hôtes, c'est la valeur recommandée par défaut, sans inconvénient opérationnel. Les seuls environnements qui utilisent légitimement les redirections ICMP sont certaines configurations avec une passerelle par défaut non optimale qui s'appuie sur les redirections pour orienter les hôtes vers un meilleur saut suivant. Avant d'appliquer, vérifiez que votre routage ne dépend pas des redirections (les réseaux modernes devraient plutôt annoncer les bonnes passerelles). Il n'y a pas de risque de blocage d'accès distant, car le changement n'affecte que le traitement des indications de route, pas la connectivité elle-même.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R12 | direct | 2.0 | haute |
| CIS | 3.3.5, 3.3.1.8 | 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 |
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.