Debugger pour Iptables

47

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

ip  iptables  debugging  packet-analyzer 
— Chris Lercher
source

Réponses:

10

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é.
— Haakon
source
Merci pour l'idée. Malheureusement, je ne peux pas enregistrer toutes les règles (sur un système, le disque ne serait probablement pas assez rapide pour le faire. Sur un autre, l'enregistrement dans iptables n'est pas disponible dans le noyau.)
— Chris Lercher
1
Utilisez un canal nommé comme fichier. Softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Cependant, comme vous ne pouvez pas vous connecter à votre noyau, vous êtes un peu SOL
— Haakon
Merci, cela ne résoudra probablement pas mon problème, mais il est généralement bon de savoir que la tuyauterie syslog serait possible - pourrait être utile à un autre moment!
— Chris Lercher
Une question connexe à propos de la journalisation: iptables gère-t-il plusieurs paquets simultanément (pour que les entrées de journal puissent être entrelacées)? Dans ce cas, je pense que l’idée des TOS serait un must absolu pour beaucoup d’analyses iptables LOG!
— Chris Lercher
Je ne connais pas la réponse à cela. Je pense que chaque interface serait au moins gérée simultanément par iptables.
— Haakon
82

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)
— Zoredache
source
8
Merci, c'est génial! C'est en fait la meilleure réponse, j'aimerais pouvoir l'accepter (c'était une question de prime, donc la réponse acceptée est définitive). Bien que je ne puisse pas l'utiliser sur tous mes systèmes (en raison des limitations du noyau), je le peux sur certains systèmes. Cette réponse mérite un vote positif, car elle est très proche de ce que je cherchais.
— Chris Lercher
J'ai trouvé cette fonctionnalité hier soir en relisant la page de manuel iptables afin de pouvoir répondre à une question différente. Semble être une fonctionnalité relativement nouvelle. Pas de souci de ne pas pouvoir le marquer comme accepté. Peut-être que cela sera suffisamment voté avec le temps pour me rapporter un autre badge populiste.
— Zoredache
C'est vraiment la réponse canonique pour tracer les paquets dans iptables. Il est dommage que certains noyaux récents ne l'activent pas par défaut.
— Peter Grace
Depuis combien de temps le noyau prend-il en charge TRACE? J'ai utilisé avec succès sur CentOS 6.4 mais pas dans CentOS 6.2
— sebelk
6

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/

— Marc Riera
source
1
Merci. Les points 1) et 3) n'ont pas grand-chose à voir avec le suivi des paquets via les règles iptables, mais le point concernant la redirection des entrées de journal en fonction de "--log-level" peut être utile, si je dois finalement revenir à enregistrement (au cas où il n'y aurait absolument aucune autre solution).
— Chris Lercher
2

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

— chris
source
0

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".

— Vi.
source
2
Je peux voir ce que l'auteur veut, cependant; Si vous essayez de tester vos règles iptables sur une interface occupée, le simple fait de regarder des compteurs ne vous aidera pas beaucoup, en particulier si le paquet est susceptible de correspondre à plusieurs règles et de contourner les chaînes définies par l'utilisateur dans le processus. filtrage des adresses IP indésirables et des règles de protection contre les inondations).
— PP.
@PP: Exactement, vous lisez dans mes pensées. @Vi: Merci, cela peut être utile dans certaines circonstances, et je l'ai utilisé parfois. Maintenant, j'ai besoin de quelque chose de plus puissant.
— Chris Lercher
-2

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.

— Anonyme
source
Pas vrai. Les paquets peuvent correspondre à plusieurs règles, et ils le font. À moins qu'une règle ne comporte une action (comme -j DROPou -j ACCEPT), elle continuera simplement à apparier plus loin dans la chaîne.
— PP.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.