Le 21 juin 2015 à 16:26, Pascal Hambourg <pas...@plouf.fr.eu.org> a écrit :
> Samuel a écrit : >> >> C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur >> une chaine FORWARD à compléter selon besoins ): >> >> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED >> --icmp-type source-quench -j ACCEPT > > Ce type ICMP est obsolète est considéré comme dangereux car il peut > facilement être détourné pour provoquer un déni de service. Oui, j'ai compris pourquoi :-) Quand le serveur a instruction de DROP, il n'écoute pas. Il ignore. Quand il a instruction de REJECT, il écoute et prend sa décision ensuite. De ce fait, REJECT est pratiquement inopérant contre les attaques en masse. Par contre, c'est vraiment très bien contre les spammeurs, qui règlent leur bot afin de visiter une masse de site, puis de reprendre la liste du début. À ce sujet, je viens de comprendre et d'apprendre autre chose. Comme vous le savez maintenant, je mets mes règles de base dans un script. Maintenant, j'affine mes règles en ligne de commande, ce qui me fait 2 couches pour Netfilter (+ 1 autre encore avec fail2ban). Le problème avec fail2ban, c'est qu'à chaque fois que je modifiais mon script de base je devais recharger (reload) fail2ban pour qu'il réécrive par-dessus. C'est pourquoi je préfère maintenant écrire des règles circonstancielles à la volée. Le problème, c'est qu'il n'est pas facile de s'y retrouver. Mais on peut quand même mettre un commentaire à sa règle : https://major.io/2010/07/26/adding-comments-to-iptables-rules/ Ce qui nous donne par exemple : # iptables -t filter -I INPUT -p tcp --dport 80 -s 121.205.238.186 -j REJECT --reject-with icmp-port-unreachable -m comment --comment "spamco soldat" # iptables -n -v -L Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 121.205.238.186 0.0.0.0/0 tcp dpt:80 /* spamco soldat */ L'autre truc que j'ai compris, c'est la différence entre -I (insert) et -A (append). Quand on met ses règles dans un script, on le fait avec -A et toutes s'exécutent dans l'ordre du script. Par contre, si on fait pareil à la volée, cette règle qu'on ajoute ainsi a l'inconvénient de s'exécuter tout à la fin de la table (INPUT par ex.). Ce qui a pour conséquence de ne rien changer du tout ! Ce qu'il faut faire, c'est le mettre en -I insertion pour que la nouvelle règle se place au dessus des autres. Avant de comprendre cela (j'ai le cerveau lent) j'ai fait plein d'erreurs. On peut corriger facilement, car les lignes sont numérotées : # iptables -L --line-numbers On supprime ensuite la ligne eronée : # iptables -D INTPUT X où X est le numéro de la ligne à effacer :-) Par contre, est-ce que je peux effacer une ligne eronnée qui se trouve dans mon script sans toucher à mon script ? > > -- > Lisez la FAQ de la liste avant de poser une question : > http://wiki.debian.org/fr/FrenchLists > > Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" > vers debian-user-french-requ...@lists.debian.org > En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org > Archive: https://lists.debian.org/5586c99e.4010...@plouf.fr.eu.org > -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/afc98dfc-d150-4905-adef-3642a921f...@worldonline.fr
