Dans l'icmp il y a deux choses qui me dérangent :
· le fait qu'il soit très simple de tuneller à peu près n'importe quoi dans le ping (bon ça marche aussi avec les requêtes DNS, et d'autres trucs...)
· il y a beaucoup de types / codes inusités, qui servent beaucoup au fingerprinting et à la découverte de réseaux (http://www.securitypronews.com/securitypronews-24-20030929OS(...) est un bon résumé)
En ce qui concerne le premier point, un bon IDS fait l'affaire pour la majeure partie des cas (et quand le contenu est crypté au point d'être invisible, ben c'est qu'on est tombé sur un sacré balaise, et là on a du souci à se faire). De plus, limiter le nombre de réponses au ping va poser des problèmes à l'utilisateur du tunnel (par exemple ne répondre qu'à 1 ping sur 3).
Pour le second, il y a des méthodes qui relèvent plus de la configuration des systèmes protégés que du pare-feu lui même. Par exemple, sous linux, ne pas répondre à un ping sur l'adresse de réseau ou de diffusion. Ce genre de chose se configure à coup de sysctl. De plus, on peut limiter les réponses aux types de messages considérés comme légitimes.
Voici ce que j'ai sur un pare-feu ipv4 only (en ipv6 j'ai pas encore creusé la question) :
for icmptype in echo-request echo-reply fragmentation-needed port-unreachable host-unreachable ttl-exceeded; do
$ipcmd -A INPUT -m limit --limit 2/second -p icmp --icmp-type $icmptype -j ACCEPT
$ipcmd -A OUTPUT -p icmp --icmp-type $icmptype -j ACCEPT
done
$ipcmd contient évidemment "/sbin/iptables <les options que je veux toujours mettre>"
(dans certains cas on peut vouloir autoriser l'icmp redirect en plus, mais c'est à limiter à l'interface sur laquelle on en a besoin).
[^] # Re: Pas de réponse aux demande de ping
Posté par nodens . En réponse au journal Script Iptables. Évalué à 3.
· le fait qu'il soit très simple de tuneller à peu près n'importe quoi dans le ping (bon ça marche aussi avec les requêtes DNS, et d'autres trucs...)
· il y a beaucoup de types / codes inusités, qui servent beaucoup au fingerprinting et à la découverte de réseaux (http://www.securitypronews.com/securitypronews-24-20030929OS(...) est un bon résumé)
En ce qui concerne le premier point, un bon IDS fait l'affaire pour la majeure partie des cas (et quand le contenu est crypté au point d'être invisible, ben c'est qu'on est tombé sur un sacré balaise, et là on a du souci à se faire). De plus, limiter le nombre de réponses au ping va poser des problèmes à l'utilisateur du tunnel (par exemple ne répondre qu'à 1 ping sur 3).
Pour le second, il y a des méthodes qui relèvent plus de la configuration des systèmes protégés que du pare-feu lui même. Par exemple, sous linux, ne pas répondre à un ping sur l'adresse de réseau ou de diffusion. Ce genre de chose se configure à coup de sysctl. De plus, on peut limiter les réponses aux types de messages considérés comme légitimes.
Voici ce que j'ai sur un pare-feu ipv4 only (en ipv6 j'ai pas encore creusé la question) :
for icmptype in echo-request echo-reply fragmentation-needed port-unreachable host-unreachable ttl-exceeded; do
$ipcmd -A INPUT -m limit --limit 2/second -p icmp --icmp-type $icmptype -j ACCEPT
$ipcmd -A OUTPUT -p icmp --icmp-type $icmptype -j ACCEPT
done
$ipcmd contient évidemment "/sbin/iptables <les options que je veux toujours mettre>"
(dans certains cas on peut vouloir autoriser l'icmp redirect en plus, mais c'est à limiter à l'interface sur laquelle on en a besoin).