Re: Analyse de logs apache

Top Page

Reply to this message
Author: Olivier Allard-Jacquin
Date:  
To: guilde
Subject: Re: Analyse de logs apache
    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 !!