Debugger pour Iptables

Je cherche un moyen facile de suivre un paquet à travers les règles iptables. Il ne s’agit pas tant de journalisation, car je ne veux pas journaliser tout le trafic (et je veux seulement avoir des cibles LOG pour très peu de règles).

Quelque chose comme Wireshark pour Iptables. Ou peut-être même quelque chose de semblable à un débogueur pour un langage de programmation.

Merci chris

Remarque: il n'est pas nécessaire que ce soit un outil graphique sophistiqué. Mais il doit faire plus que simplement afficher un compteur de colis ou autre.

Mise à jour: Il semble presque que nous ne trouvions rien qui offre la fonctionnalité demandée. Dans ce cas: trouvons au moins une bonne technique basée sur la journalisation iptables - pouvant être facilement activée et désactivée, et ne nécessitant pas d'écriture redondante des règles iptables (devoir écrire la même règle pour -j LOGet -j ...)

Je ne peux pas penser à une solution directe, mais je peux penser à un moyen génial de suivre un paquet.

1. Consigner chaque règle avec une directive de préfixe de journalisation (--log-prefix "Règle 34")
2. Générez un paquet de test ou un flux de paquets avec scapy et définissez le champ TOS sur quelque chose d'unique
3. grep la sortie du fichier journal pour ce paramètre TOS et voir quelles règles l'ont consigné.

Si vous avez assez de noyau et de version récente d'iptables, vous pouvez utiliser la cible TRACE (semble être intégrée à au moins Debian 5.0). Vous devez définir les conditions de votre trace de manière à être aussi spécifiques que possible et désactiver toutes les règles TRACE lorsque vous ne procédez pas au débogage, car elles génèrent de nombreuses informations dans les journaux.

TRACE
Cette cible marque les paquets de sorte que le noyau enregistre toutes les règles qui correspondent aux paquets tels que ceux qui traversent les tables, les chaînes, les règles. (Les modules ipt_LOG ou ip6t_LOG sont requis pour la journalisation.) Les paquets sont consignés avec le préfixe de chaîne suivant: "TRACE: nom du tableau: nom de la chaîne: type: rulenum" où type peut être "règle" pour règle simple, "retour" pour règle implicite à la fin d'une chaîne définie par l'utilisateur et "politique" pour la politique des chaînes intégrées. Il ne peut être utilisé que dans la table brute.

Si vous avez ajouté des règles comme celle-ci

iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

Vous obtiendrez une sortie qui ressemble à ceci.

# cat /var/log/kern.log | grep 'TRACE:'
Mar 24 22:41:52 enterprise kernel: [885386.325658] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325689] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325713] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: nat:nat.1:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_all_c1:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_irc_c2:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)

Trois réponses sur un post:

1) Débogage par script:

#!/bin/bash
debug() {
    if [ -n "$debug" ]; then
        $@ || echo -e "The command which launched the error:\n$@"
    else
        $@
    fi
}
debug=1
IPTABLES="debug /sbin/iptables"

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
....

2) déboguer par syslog

De ce site Web: http://www.brandonhutchinson.com/iptables_fw.html

If you want to make a syslog entry of dropped packets, change:

# Drop all other traffic
/sbin/iptables -A INPUT -j DROP

To:

# Create a LOGDROP chain to log and drop packets
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP


You may also want to configure the --log-level to log dropped packets to a separate file instead of /var/log/messages:

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP --log-level debug


/etc/syslog.conf change:

# Send iptables LOGDROPs to /var/log/iptables
kern.=debug                                             /var/log/iptables

Reload the syslogd service for the change to take effect.
/sbin/service syslog reload

3) Pas de débogage, belle édition iptables:

Cela peut aussi être utile: http://www.fwbuilder.org/

A eu la même question et a trouvé Zoredache pointant vers TRACE / ipt_LOG était la solution!

De plus, j'ai trouvé un script qui insère / supprime les règles LOG précédant toutes les règles iptables actuellement actives. J'ai essayé et trouvé que c'était un très bon outil. - La sortie est similaire à la solution TRACE. - Avantage: cela fonctionne sur la configuration active d'iptables, peu importe d'où elle a été chargée. Vous pouvez activer / désactiver l'enregistrement à la volée! Vous n'avez pas besoin de modifier les scripts de pare-feu éventuellement générés par Firewall Builder ou les outils que vous utilisez ... - Inconvénient: sans modification, le script crée des règles LOG pour TOUTES les règles actives. Au lieu de cela, lorsque vous utilisez des règles TRACE, vous limiterez probablement la journalisation aux adresses / services / connexions pour lesquels vous souhaitez examiner le traitement iptables maintenant.

Quoi qu'il en soit, j'aime bien l'approche :) Félicitations à Tony Clayton, consultez: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Cordialement, Chris

J'utilise généralement des compteurs de paquets et d'octets pour voir comment les règles fonctionnent et trouver ce qui manque ou est erroné.

Vous pouvez les voir avec "iptables -nvL".

Autant que je sache, un paquet IP parcourt la chaîne de règles jusqu'à la première correspondance. Donc, je ne vois pas vraiment quel est le problème ici. Si tu as:

1. règle 1
2. règle 2
3. règle 3 LOG

Et un paquet figure dans le journal, cela signifie que la règle 3 est la première règle correspondante.