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 !!
