Jusqu'? pr駸ent, nous avons vu comment configurer nos r鑒les avec Netfilter : d馭inir les cibles par d馭aut, et supprimer des paquets. Mais ? force de tout supprimer, il nous est difficile de conna?tre l'efficacit? de notre firewall, et si il est int駻essant de rajouter ou de supprimer des r鑒les. D'o? l'int駻黎 de logger certaines informations.
Dans ce qui suis, nous allons utiliser l'affreux anglicisme "logger" qui d馗rit l'action de stocker dans un "log" une certaine information.
C'est la m騁hode la plus standard pour logger des trames. Il s'agit simplement de cr馥r une r鑒le "iptables" dont la cible ("-j [cible]") n'est pas "ACCEPT" ou "DROP", mais tout simplement "LOG". Si nous reprenons le script "
iptables-conntrack-1.sh", nous pouvons par exemple rajouter une derni鑽e r鑒le qui va logger tout ce qui na pas 騁? accept? par la cha?ne "INPUT". C'est tr鑚 pratique, car ainsi nous serons averti de tout ce qui tente d'acc馘er aux processus utilisateurs de notre syst鑪e. Pour cela, nous rajoutons cette r鑒le en temps que
derni鑽e r鑒le de la cha?ne "INPUT" :
[root@phoenix /]# iptables -t filter -A INPUT -j LOG
Comme Netfilter est un 駘駑ent du Kernel, ses logs sont donc des logs de ce dernier. Et comme tout bon log Kernel, ils se retrouve dans le fichier "/var/log/messages". Ainsi, si
pirate.internet.net fait un "nmap" sur les ports HTTP et HTTPS de
Phoenix, nous aurons :
[intrus@pirate /]# nmap phoenix1.internet.net -p 80,443
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds
[root@phoenix /]# tail -14 /var/log/messages
Jul 8 23:04:59 phoenix nmbd[2178]: [2003年07月08日 23:04:59, 0] nmbd/nmbd_packets.c:send_netbios_packet(172)
Jul 8 23:04:59 phoenix nmbd[2178]: send_netbios_packet: send_packet() to IP 10.255.255.255 port 137 failed
Jul 8 23:04:59 phoenix nmbd[2178]: [2003年07月08日 23:04:59, 0] nmbd/nmbd_namequery.c:query_name(256)
Jul 8 23:04:59 phoenix nmbd[2178]: query_name: Failed to send packet trying to query name WORKGROUP
Jul 8 23:07:03 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=28 TOS=0x00 PREC=0x00
TTL=38 ID=41593 PROTO=ICMP TYPE=8 CODE=0 ID=58020 SEQ=0
Jul 8 23:07:03 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=40 TOS=0x00 PREC=0x00
TTL=39 ID=51459 PROTO=TCP SPT=53120 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0
Jul 8 23:07:09 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=28 TOS=0x00 PREC=0x00
TTL=38 ID=2581 PROTO=ICMP TYPE=8 CODE=0 ID=58020 SEQ=256
Jul 8 23:07:09 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=40 TOS=0x00 PREC=0x00
TTL=39 ID=27444 PROTO=TCP SPT=53121 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0
Jul 8 23:07:15 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=28 TOS=0x00 PREC=0x00
TTL=38 ID=29887 PROTO=ICMP TYPE=8 CODE=0 ID=58020 SEQ=512
Jul 8 23:07:15 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=40 TOS=0x00 PREC=0x00
TTL=39 ID=48409 PROTO=TCP SPT=53122 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0
Jul 8 23:07:21 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=28 TOS=0x00 PREC=0x00
TTL=38 ID=37813 PROTO=ICMP TYPE=8 CODE=0 ID=58020 SEQ=768
Jul 8 23:07:21 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=40 TOS=0x00 PREC=0x00
TTL=39 ID=17449 PROTO=TCP SPT=53123 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0
Jul 8 23:07:27 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=28 TOS=0x00 PREC=0x00
TTL=38 ID=57294 PROTO=ICMP TYPE=8 CODE=0 ID=58020 SEQ=1024
Jul 8 23:07:27 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 LEN=40 TOS=0x00 PREC=0x00
TTL=39 ID=64622 PROTO=TCP SPT=53124 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0
Gr稍e au log, on voit que
phoenix1.internet.net re輟it une s駻ie de commandes "ping" et de requ黎es sur son port 80 de la part de
pirate.internet.net. ノvidement, comme
Phoenix ne r駱ond pas ? ces requ黎es,
Pirate fait plusieurs essais, et finalement ne testera m麥e pas le port 443.
Un moyen pratique de suivre ses logs en temps r馥l est la commande, lanc? en temps que root : "
tail -f /var/log/messages". Cela affichera en permanence la fin de ce fichier de log. Pour l'arr黎er, il suffit d'appuyer sur CTRL+C.
Mais ce fichier sert aussi (surtout !) ? stocker tout les messages d'informations ou d'erreurs du Kernel. Il nous faut donc un moyen de retrouver ces messages de log Netfilter parmi tout les autres messages. On peut configurer avec le param鑼re "
--log-prefix=[Message de log]" la r鑒le de log afin qu'elle rajoute syst駑atiquement des messages en d饕ut de log. Ainsi :
[root@phoenix /]# iptables -t filter -A INPUT -s 10.0.0.66 -j LOG --log-prefix="AttackPirate"
[root@phoenix /]# iptables -t filter -A INPUT -s 10.0.0.200 -j LOG --log-prefix="AttackWeb"
indiquera clairement les connexions faites par les machines
pirate.internet.net et
web.internet.net :
[intrus@pirate /]$ nmap -p 80 phoenix1.internet.net
[intrus@web /]$ nmap -p 80 phoenix1.internet.net
[root@phoenix /]# tail -f /var/log/messages
Jul 8 23:26:06 phoenix kernel: AttackPirate IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:26:06 phoenix kernel: AttackWeb IN=eth1 OUT= SRC=10.0.0.200 DST=10.0.0.1 ...
Jul 8 23:26:12 phoenix kernel: AttackPirate IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:26:12 phoenix kernel: AttackWeb IN=eth1 OUT= SRC=10.0.0.200 DST=10.0.0.1 ...
Jul 8 23:26:12 phoenix kernel: AttackPirate IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:26:12 phoenix kernel: AttackWeb IN=eth1 OUT= SRC=10.0.0.200 DST=10.0.0.1 ...
Jul 8 23:26:25 phoenix kernel: AttackPirate IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:26:28 phoenix kernel: AttackPirate IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:26:34 phoenix kernel: AttackPirate IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Cependant, cette m騁hode de log a l'inconv駭ient que m麥e avec des "--log-prefix", il reste difficile de s駱arer les messages de log de Netfilter des autres messages du Kernel. Comme en t駑oigne d'ailleurs le
premier affichage du /var/log/message, o? des messages de Samba (en d饕ut de log) sont m駘ang駸 aux messages de Netfilter.
Une autre m騁hode est de d馭inir un "niveau de log" ("log level" en anglais), qui rajoute une autre information aux log, ce qui permet au demon de log (un programme appel? "syslogd") de stocker ces log dans un autre fichier. Par exemple, sur une Mandrake, on peut utiliser (voir "man syslogd", "man syslog.conf", "less /usr/include/sys/syslog.h" pour avoir plus d'informations sur ces commandes) :
[root@phoenix /]# iptables -t filter -A INPUT -j LOG --log-level=4
[root@phoenix /]# less /usr/include/sys/syslog.h
#define LOG_WARNING 4 /* warning conditions */
[root@phoenix /]# less /etc/syslog.conf
kern.=warn -/var/log/kernel/warnings
[intrus@pirate /]$ nmap -p 80 phoenix1.internet.net
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 60 seconds
[root@phoenix /]# tail -10 /var/log/kernel/warnings
Jul 8 18:55:43 phoenix kernel: MSDOS FS: Using codepage 850
Jul 8 19:26:34 phoenix kernel: i2c-amd756.o version 2.7.0 (20021208)
Jul 8 19:26:34 phoenix kernel: i2c-amd756.o: AMD768 bus detected and initialized
Jul 8 19:28:37 phoenix kernel: UDF-fs: No VRS found
Jul 8 23:53:58 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:54:01 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:54:07 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:54:10 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:54:13 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Jul 8 23:54:19 phoenix kernel: IN=eth1 OUT= SRC=10.0.0.66 DST=10.0.0.1 ...
Comme on le voit, bien que les log de Netfilter soient isol駸 dans un fichiers ? part (/var/log/warnings), ce fichier n'en est pas moins partag? avec d'autres modules du Kernel, qui utilisent eux aussi le log Kernel de niveau 4 <=> Warning. Dans le pr馗馘ent log, on voit notamment des logs de "MSDOS FS" et "i2c-amd756.0" qui n'ont rien ? voir avec Netfilter.
On pourrait s'imaginer utiliser une autre entr馥 du syslog, afin de vraiment s駱arer ces log. Le seul probl鑪e, c'est que les log de Netfilter sont des log du
Kernel, et qu'? ce titre, on sera
toujours oblig? de les d馗larer en temps que "
kern." dans le "/etc/syslog.conf".
Alors ? Stocker ces logs ? part est vraiment une chose impossible sous Linux ? Non, heureusement que non ! La solution s'appelle ULOG, et nous allons la voir tout de suite.
ULOG est
module du Kernel dont le d騅eloppement a 騁? fait par
http://www.gnumonks.org/projects/. Il a 騁? sp馗ialement con輹 pour recevoir les log de Netfilter. Il y a certaines (petites) contraintes ? son utilisation :
- Kernel r馗ent : il faut un Kernel >= 2.4.18-pre8 pour pouvoir utiliser ce module.
- Option de compilation : il faut que votre kernel soit compil? avec l'option CONFIG_IP_NF_TARGET_ULOG=m.
- Une fois compil?, le module ipt_ULOG.o doit se trouver sur votre disque dur (/lib/modules/[version du kernel]/kernel/net/ipv4/netfilter/ipt_ULOG.o.gz par exemple) :
[root@phoenix /]# find /lib/modules/`uname -r`/ -iname "*ULOG*"
/lib/modules/2.4.21-0.13mdksmp/kernel/net/ipv4/netfilter/ipt_ULOG.o.gz
Sur une distribution "Mandrake 9.1", tout ceci est fait par d馭aut.
- Vous devez r馗up駻er et installer le demon "ulogd" sur votre machine. Personnellement, j'ai t駘馗harg? la version 1.0, et je l'ai compil? et install? dans mon "/usr/local/sbin/ulogd".
- Il faut configurer le demon ulogd. Pour cela, il faut 馘iter son fichier de configuration. Vous pouvez utiliser le mien. Les 2 informations importantes sont de sp馗ifier qu'ULOG doit stocker ses logs sous forme de fichier texte, dans "/var/log/ulogd.syslogemu" par exemple.
- Le demon ULOG ("ulogd") doit tourner sur votre machine. L'id饌l est de le lancer au d駑arrage, en m麥e temps que les autres demons de votre machine. A toute fin utile, voici le script de d駑arrage du demon ULOG que j'ai 馗ris. Il se place dans le "/etc/init.d/". Pour le d駑arrer syst駑atiquement, il faut cr馥r un lien symbolique du "/etc/rc.d/rc3.d/S[un nombre]ulogd" ou du "/etc/rc.d/rc5.d/S[un nombre]ulogd" vers "/etc/init.d/ulog". Exemple :
[root@phoenix scripts]# ls -la /etc/init.d/ulogd
-rwxr--r-- 1 root root 1821 jui 9 00:30 /etc/init.d/ulogd
[root@phoenix scripts]# ls -la /etc/rc.d/rc5.d/S10ulogd
lrwxrwxrwx 1 root root 15 mai 4 21:02 /etc/rc.d/rc5.d/S10ulogd -> ../init.d/ulogd
Une fois que tout ceci est mis en place :
- D駑arrez le demon ulog . Par exemple :
[root@phoenix /]# /etc/rc.d/rc5.d/S10ulogd start
- V駻ifiez que le d駑on fonctionne correctement :
[root@phoenix /]# cat /var/log/ulogd.log
Wed Jul 9 00:50:27 2003 <3> ulogd.c:474 ulogd Version 1.00 starting
Wed Jul 9 00:50:27 2003 <5> ulogd.c:688 initialization finished, entering main loop
- Configurez Netfilter pour qu'il utilise la cible ULOG au lieu de la cible LOG. Ici, on log tout ce qui va 黎re supprim? par la cha?ne "INPUT" :
[root@phoenix /]# iptables -t filter -A INPUT -p all -j ULOG --ulog-prefix=DefaultDrop
- Et attendez qu'un intrus vienne se frotter ? votre Netfiler :
[root@phoenix /]# tail -f /var/log/ulogd.syslogemu
Jul 8 20:24:22 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21 LEN=61
TOS=00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=32796 LEN=41
Jul 8 20:24:22 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21 LEN=40
TOS=00 PREC=0x00 TTL=251 ID=0 DF PROTO=TCP SPT=110 DPT=33108 SEQ=0
ACK=1355878989 WINDOW=0 ACK RST URGP=0
Jul 8 20:24:32 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21 LEN=61
TOS=00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=32797 LEN=41
Jul 8 20:24:54 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21
LEN=61 TOS=00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=32799 LEN=41
Jul 8 20:25:04 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21
LEN=61 TOS=00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=32800 LEN=41
Jul 8 20:25:22 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21
LEN=78 TOS=00 PREC=0x00 TTL=104 ID=36090 PROTO=UDP SPT=1034 DPT=137 LEN=58
Jul 8 20:25:28 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21
LEN=40 TOS=00 PREC=0x00 TTL=251 ID=0 DF PROTO=TCP SPT=110 DPT=33220 SEQ=0
ACK=1428948021 WINDOW=0 ACK RST URGP=0
Jul 8 20:25:34 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21
LEN=61 TOS=00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=32802 LEN=41
Jul 8 20:25:38 phoenix DefaultDrop IN=ppp0 OUT= MAC= SRC=xx.xx.xx.xx DST=62.147.74.21
LEN=61 TOS=00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=32803 LEN=41
Ceci n'est qu'une simple portion de mon log de Netfilter, lors d'une connexion en RTC le 8 Juillet 2003. Remarquez le temps plut?t faible entre les acc鑚. Il s'agit en fait de plusieurs "port scan" effectu駸 par plusieurs machines... Et encore, mon Netfilter est configur? pour ne pas afficher les logs des requ黎es P2P qui, bien que je n'ai aucun client P2P, inondent r馮uli鑽ement ma machine...
Tout comme la cible LOG, la cible ULOG a des options int駻essantes :
- --ulog-prefix : pr馭ixe des log. M麥e chose que pour "--log-prefix" de la cible LOG
- --ulog-nlgroup : similaire ? "--log-level" de la cible LOG
Conclusion : si vous voulez avoir des logs bien exploitables de votre Netfilter, utilisez ULOG plut?t que LOG. Ce n'est finalement pas si compliqu? ? installer, et c'est tr鑚 pratique. Enfin, pour les maniaques de la s馗urit? qui ont plein de place disque et du CPU ? revendre, vous pouvez sp馗ifier au demon "ulogd" de stocker les paquets non pas dans un fichier, mais dans une base de donn駸
MySQL ou
PostgreSQL.