56 votes

Débogueur pour Iptables

Je cherche un moyen facile de suivre un paquet à travers les règles d'iptables. Ce n'est pas tant une question de journalisation, car je ne veux pas journaliser tout le trafic (et je ne veux avoir des cibles LOG que pour très peu de règles).

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

Remerciements Chris

Nota: Il ne doit pas nécessairement s'agir d'un outil à interface graphique sophistiqué. Mais il doit faire plus que simplement afficher un compteur de paquets.

Mise à jour : Il semble que nous n'ayons rien trouvé qui offre la fonctionnalité demandée. Dans ce cas : Trouvons au moins une bonne technique basée sur la journalisation iptables - qui peut être facilement activée et désactivée, et qui ne nécessite pas d'écrire des règles iptables de manière redondante (avoir à écrire la même règle pour -j LOG y -j ... )

97voto

jammus Points 1796

Si vous avez un noyau et une version d'iptables suffisamment récents, vous pouvez utiliser la cible TRACE (semble être intégrée dans au moins Debian 5.0). Vous devriez définir les conditions de votre trace de manière aussi spécifique que possible et désactiver toutes les règles TRACE lorsque vous n'êtes pas en train de déboguer parce que cela crache beaucoup d'informations dans les journaux.

TRACE
Cette cible marque les paquets de manière à ce que le noyau enregistre toutes les règles qui correspondent aux paquets lorsqu'ils traversent les tables, les chaînes, les règles. (L'option ipt_LOG ou ip6t_LOG est nécessaire. pour la journalisation). Les paquets sont Les paquets sont enregistrés avec le préfixe de la chaîne : "TRACE : tablename:chainname:type:rulenum " où le type peut être "rule" pour une règle simple, "return" pour une règle implicite à la fin d'un implicite à la fin d'une chaîne définie par l'utilisateur et "policy" pour la politique des chaînes intégrée. Il ne peut être utilisé que dans la chaîne tableau brut.

Si vous ajoutez des règles comme celles-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 un résultat ressemblant à celui-ci.

# 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)

10voto

titaniumdecoy Points 1011

Je ne vois pas de solution directe, mais je peux imaginer un moyen détourné de suivre un paquet.

  1. Enregistrer chaque règle avec une directive de préfixe d'enregistrement (--log-prefix "Règle 34").
  2. Générer un paquet ou un flux de paquets de test avec scapy et définir le champ TOS de manière à ce qu'il soit unique
  3. grep la sortie du fichier journal pour ce paramètre TOS et voir quelles règles l'ont enregistré.

6voto

Marc Riera Points 1567

Trois réponses sur un seul poste :

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ébogage par syslog

A partir 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, une belle édition d'iptables :

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

2voto

pisaruk Points 483

J'ai eu la même question et j'ai trouvé que Zoredache pointant vers TRACE / ipt_LOG était la solution !

De plus, j'ai trouvé un script qui insère/supprime les règles LOG avant toutes les règles iptables actives. Je l'ai essayé et j'ai trouvé que c'était un outil vraiment sympa. - La sortie est similaire à la solution TRACE - Avantage : il fonctionne sur la configuration active d'iptables, quel que soit l'endroit d'où elle a été chargée. Vous pouvez activer/désactiver la journalisation à la volée ! Vous n'avez pas besoin de modifier les scripts firewall-script qui ont pu être générés par Firewall Builder ou tout autre outil 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 restreindrez probablement la journalisation aux adresses/services/connexions pour lesquels vous voulez examiner le traitement d'iptables maintenant.

Quoi qu'il en soit, j'aime l'approche :) Bravo à Tony Clayton, jetez-y un coup d'œil : http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Voir aussi, Chris

0voto

Vi. Points 821

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

Vous pouvez les visualiser en utilisant "iptables -nvL".

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X