Re: Analyse de logs apache

Top Page

Reply to this message
Author: Jerome Kieffer
Date:  
To: guilde
Subject: Re: Analyse de logs apache
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