Le Thu Apr 28 2005 � 11:29:34PM +0200, [EMAIL PROTECTED] dit :
AMA il vaut mieux g�rer explicitement les diff�rents types de requ�tes ICMP et laisser la r�gle suivante s'occuper des ICMP qui sont des r�ponses ou des messages d'erreur relatifs � des connexions existantes.
# ICMP # Autorise tout en local iptables -A INPUT -i $LAN -p icmp -j ACCEPT iptables -A OUTPUT -o $LAN -p icmp -j ACCEPT iptables -A FORWARD -i $LAN -o $EXT -p icmp -j ACCEPT
Je fais pareil, j'ai confiance en mon r�seau. ;-)
#iptables -A FORWARD -i $EXT -o $LAN -p icmp --icmp-type source-quench -j ACCEPT iptables -A FORWARD -i $EXT -o $LAN -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
Je suppose qu'il s'agit plut�t du type echo-reply, la r�ponse au ping. Si la machine fait du NAT, il est peu courant que les requ�tes de ping soient redirig�es vers le r�seau local.
iptables -A INPUT -i $EXT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT iptables -A INPUT -i $EXT -p icmp --icmp-type host-unreachable -m limit --limit 1/s -j ACCEPT
Il manque l'indispensable time-exceeded que l'on attend notamment en r�ponse � un traceroute. Et chaque type est � prendre en compte � la fois dans INPUT et dans FORWARD.
Aussi, AMA une gestion saine des ICMP doit prendre en compte les �tats du suivi de connexion :
- echo-request -> NEW
- echo-reply -> ESTABLISHED
- erreurs (destination-unreachable, source-quench, parameter-problem, time-exceeded) -> RELATED
- le reste : inutile ou potentiellement n�faste (ex: redirect) -> DROP
# Rej�te les ICMP "dangereux" vers l'ext�rieur [1], [2] # [3] pour les limites iptables -A OUTPUT -o $EXT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT
Euh, il ne vaudrait pas mieux limiter les echo-request dans INPUT plut�t que les echo-reply dans OUTPUT ?
iptables -A OUTPUT -o $EXT -p icmp --icmp-type source-quench -m limit --limit 1/s -j ACCEPT iptables -A OUTPUT -o $EXT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT iptables -A OUTPUT -o $EXT -p icmp --icmp-type host-unreachable -m limit --limit 1/s -j ACCEPT iptables -A OUTPUT -o $EXT -p icmp -j DROP
Pas tr�s utile apr�s la r�gle du d�but qui accepte tous les ICMP dans OUTPUT.
Si quelqu'un peut m'expliquer le source-quench je suis un peu feneant sur les RFC ...
Une machine peut l'envoyer quand elle d�truit un paquet ou risque de le faire � cause par exemple d'un buffer de r�ception plein. Le but est de demander � l'exp�diteur de ralentir.
et le rejet (logs-fi est ma r�gle de "log and drop") : iptables -A logs-fi -j REJECT --reject-with icmp-port-unreachable
Pour ma part j'aime bien moduler le type d'erreur en fonction du type de paquet, par exemple :
- TCP -> tcp-reset
- UDP -> icmp-port-unreachable
- autre -> icmp-proto-unreachable
Le tout avec des limitations en cas de flood.
-- Pensez � lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez � rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
