Re: [HS] iptables: ICMP et limit
Salut,
Le poulpe qui bloppe ! a écrit :
Je travaille actuellement mon script iptables.
C'est bien. :-)
Jusqu'a présent, j'etais en ACCEPT partout, et je forcais les drop de ce
que je ne voulais pas.
C'est mal. :-p
J'ai décidé d'etre plus propre et de mettre DROP par defaut, et d'autorisé
ce que je souhaite.
C'est bien. :-)
Mon serveur fait passerelle de mon rezo local:
WEB <--> eth0 <-->debian<--> eth1 <--> rezo local
Je travaille pour l'instant uniquement sur le ping.
Ce que j'aimerais, c'est que n'importe qui puisse me pinguer depuis
n'importe où (WAN et LAN).
C'est bien. :-)
Mais que losrsqu'une IP me ping, je reponde aux 4 premieres requettes, puis
plus rien pendant 10 minutes.
C'est sage, quoique je trouve 10 minutes très long.
J'ai donc essayé le systeme de limit et limit-burst, mais c'est
relativement trop philosophique pour moi.
Note que la correspondance 'limit' ne distingue pas entre les
différentes adresses sources. Pour cela il faudrait utiliser la
correspondance 'hashlimit' qui est supportée à partir d'iptables 1.3.0
et du noyau Linux 2.6.10 (ou inférieur avec le patch 'hashlimit' du
patch-o-matic-ng).
pour mes test, je suis donc en DROP par defaut, et je mets ca:
iptables -t filter -A INPUT -i $IF_LAN -p icmp --icmp-type echo-reply -m
limit --limit 3/minute --limit-burst 5 -j DROP
Probleme: je suis incapable de pinguer.
Normal : politique DROP par défaut + règle DROP seulement = DROP
systématique. En fait il faut une clbie ACCEPT à cette règle.
Si je me mets en ACCEPT par defaut toujours avec la meme ligne, là je ping,
mais autant que je veux.
Même en lançant un nombre illimité de pings (option -t sous Windows) ?
Il n'y a pas une autre règle qui accepterait ces paquets ?
Donc si une bonne ame arrive à m'expliquer comme à un gros debutant le
fonctionnement de limit, et de limit-burst, j'en serais tres reconnaissant.
La valeur de l'option --limit-burst signifie qu'initialement la
correspondance est positive sur les n premiers paquets. La valeur de
l'option --limit indique le nombre de paquets par unité de temps qui
donnent une correspondance positive. Si le nombre de paquets effectif ne
dépasse pas la limite, le "limit-burst" est progressivement "rechargé"
jusqu'à atteindre sa valeur initiale.
Dans ton exemple, la correspondance est positive sur les 5 premiers
paquets quel que soit leur rythme d'arrivée. Et en moyenne seuls 3
paquets par minutes (en pratique un paquet toutes les 20 secondes) donne
une correspondance positive.
Donc par exemple si tu envoies un ping par seconde :
- les 5 premiers passent,
- ensuite, un passe toutes les 20 secondes (3 par minute).
J'ai testé sur une Sarge :
iptables -A INPUT -i lo -p icmp -m icmp --icmp-type echo-request \
-m limit --limit 3/min -j ACCEPT
iptables -A INPUT -i lo -p icmp -m icmp --icmp-type echo-request -j DROP
$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.302 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.190 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.177 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.183 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.186 ms
[les 5 premiers pings passent]
64 bytes from localhost (127.0.0.1): icmp_seq=21 ttl=64 time=0.120 ms
64 bytes from localhost (127.0.0.1): icmp_seq=41 ttl=64 time=0.115 ms
64 bytes from localhost (127.0.0.1): icmp_seq=61 ttl=64 time=0.127 ms
[1 ping passe toutes les 20 secondes (3/minute)]
En laissant passer 5x20 secondes sans envoyer de ping, le limit-burst se
recharge intégralement et 5 pings peuvent à nouveau passer sans
limitation de temps.
Reply to: