Merci pour les explications ...
sur un serveur un peu exposé, j'ai:
wc -l /etc/hosts.deny: 23902
Faudra que je passe à des regles de firewall un jour.
On Tue, 19 Apr 2022 10:23:43 +0200
Olivier Allard-Jacquin <olivieraj@???> wrote:
> Bonjour Jerôme,
>
> Le 19/04/2022 à 07:58, Jérôme Kieffer a écrit :
> > Bonjour,
> >
> > Une petit question:
> > Pourquoi faire ca avec netfilter qui est un peu compliqué à manipuler
> > alors qu'une blacklist à la /etc/hosts.deny est plus simple a gerer et
> > plus dynamique ?
>
> Pour ce qui est du "dynamique", les deux méthodes se valent : Une fois
> détectée l'IP à bannir (fail2ban, analyse manuelle des logs, etc ...),
> il suffit de faire :
>
> - netfilter:
> iptables-legacy -I INPUT -j DROP -s $IP
>
> - "blacklist à la /etc/hosts.deny":
> Rajouter $IP à la la bonne ligne du /etc/hosts.deny:
> services_xx: w.x.y.z1 w.x.y.z2 w.x.y.z3 w.x.y.z4
>
>
> Pour ce qui est du /etc/hosts.deny , je vois divers problèmes:
> - tous les softs ne le gèrent pas forcément
> - le fichier va rapidement augmenter en taille, notamment si il y a
> plusieurs services à protéger. Alors que netfilter peut bloquer, ou pas,
> une IP pour tous les services
>
> Enfin une expérience personnelle sur son copain, le /etc/hosts:
> - Il y a quelques années, un pote m'a dit utiliser des blacklist de
> squidGuard
> http://www.squidguard.org/Doc/configure.html , afin de bannir des
> hostname : Le /etc/hosts les renvoyait sur 127.0.0.1. Son fichier
> faisait plusieurs Mo ...
> - Plus tard, il m'a dit que certains softs sous Linux marchait mal,
> notamment un soft de chat xmpp
> - Il m'a fallut une analyse à coup de "strace", pour trouver que le soft
> plantait suit à l'ingestion du /etc/hosts : Il y avait tout simplement
> trop de lignes !!!
> - Un retour à un /etc/hosts plus standard à corriger le problème
> - Donc attention aux dégâts collatéraux, il n'est pas évident que les
> lib Linux qui gèrent le /etc/hosts.deny supporte des lignes à ralonge
>
>
> > Ca revient à comperer fail2ban à denyhost (qui est moribond).
> > J'ai l'impression que de passer à fail2ban risque de changer bcp de
> > choses dans les scripts de firewall d'une part et surtout ralentir le
> > routage au niveau du kernel.
>
> Ca c'est une excellente remarque, et c'est justement la raison pour
> laquelle j'ai re-écrit mon script netfilter:
>
> - Dans le cas d'un script "monolithique", c'est à dire sans chaîne
> utilisateur, effectivement une grosse liste d'IP bannies va pourrir les
> perfs de toute la stack réseau. Exemple en mettant tout sur la chaîne INPUT:
>
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 13851 9448K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 0 0 DROP all -- eth0 * w.x.y.z1 0.0.0.0/0
> 0 0 DROP all -- eth0 * w.x.y.z2 0.0.0.0/0
> 0 0 DROP all -- eth0 * w.x.y.z2 0.0.0.0/0
> 0 0 DROP all -- eth0 * w.x.y.z3 0.0.0.0/0
> 0 0 DROP all -- eth0 * w.x.y.z4 0.0.0.0/0
> 0 0 DROP all -- eth0 * w.x.y.z4 0.0.0.0/0
> [...]
>
> - Par contre, il est possible d'utiliser les chaînes utilisateurs afin
> de pre-aiguiller les paquets. Exemple chez moi pour les règles d'INPUT:
>
> + La chaine INPUT de la table FILTER ne contient que le minimum, qui
> fait le "routage" entre des chaines utilisateur:
>
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 2M 9G ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 13M 2084M IN-Box all -- eth0 * A.B.C.0/24 0.0.0.0/0
> 2M 9G IN-WAN all -- eth0 * 0.0.0.0/0 A.B.C.9999
> 17M 3535M IN-Lan all -- eth1 * A.B.D.0/24 0.0.0.0/0
> 0 0 IN-Wifi all -- eth2 * A.B.C.0/24 0.0.0.0/0
> 0 0 NFLOG all -- * * 0.0.0.0/0 0.0.0.0/0
> => 6 règles, pas plus !
>
> A l'exception de IN-Box, l'ordre des règles est inversement
> proportionnel à leur trafic : Les premières règles traités sont celles
> qui voient le plus de flux
>
>
> + Tout ce qui vient d'Internet est renvoyée dans la chaine IN-WAN:
>
> Chain IN-WAN (1 references)
> pkts bytes target prot opt in out source destination
> 2M 3G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
> state RELATED,ESTABLISHED
> 0 0 IN-Ban all -- * * w.x.y.z1 0.0.0.0/0
> 4 240 IN-Ban all -- * * w.x.y.z2 0.0.0.0/0
> 0 0 IN-Ban all -- * * w.x.y.z3 0.0.0.0/0
> 1 44 IN-Ban all -- * * w.x.y.z4 0.0.0.0/0
> [...]
> 189 9172 ACCEPT tcp -- * * 0.0.0.0/0 A.B.C.9999 tcp
> dpt:80 state NEW
> 224 11004 ACCEPT tcp -- * * 0.0.0.0/0 A.B.C.9999 tcp
> dpt:443 state NEW
> 0 0 NFLOG all -- * * 0.0.0.0/0 0.0.0.0/0
> nflog-prefix IN-WAN
> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
>
> on voit que:
> 1) le gros du trafic est gérée par les connexions déjà établies (1ère
> règle: "state RELATED,ESTABLISHED")
>
> 2) puis vient le filtrages des IP bannies, qui sont renvoyés dans une
> 3ème table (IN-Ban), afin de faire des statistiques. Note: J'aurai pu
> aussi bien faire un DROP, et tant pis pour les statistiques
>
> 3) enfin vient les connexions NEW sur les services ouverts sur Internet.
> Certes, il passent après les centaines de règles d'IP bannies. Mais
> c'est juste pour le handshake. Après, les paquets seront traités par la
> 1ère règle "state RELATED,ESTABLISHED"
>
> + Finalement, la dernière règle qui gèrent tout ce qui est bloqué, et
> qui servira pour les statistiques :
>
> Chain IN-Ban (262 references)
> pkts bytes target prot opt in out source destination
> 96 5606 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
>
> Cordialement,
> Olivier
> --
> ~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Phoenix / _ \/ _ \ Olivier Allard-Jacquin
> / / \ / \ \ Web: http://olivieraj.free.fr/
> /___/ / \ \___\ Mail: olivieraj@???
> ~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
>
--
Jérôme Kieffer
tel +33 476 882 445
