Debugger für Iptables

47

Ich suche nach einer einfachen Möglichkeit, ein Paket anhand der iptables-Regeln zu verfolgen. Hier geht es nicht so sehr um die Protokollierung, da ich nicht den gesamten Datenverkehr protokollieren möchte (und nur für sehr wenige Regeln LOG-Ziele haben möchte).

So etwas wie Wireshark für Iptables. Oder vielleicht sogar so etwas wie ein Debugger für eine Programmiersprache.

Danke Chris

Hinweis: Es muss kein schickes GUI-Tool sein. Aber es muss mehr als nur einen Paketzähler oder so anzeigen.

Update: Es sieht fast so aus, als ob wir nichts finden können, das die gewünschte Funktionalität bietet. In diesem Fall: Lassen Sie uns zumindest eine gute Technik finden, die auf der iptables-Protokollierung basiert - die einfach ein- und ausgeschaltet werden kann und keine redundanten iptables-Regeln erfordert (für -j LOGund muss dieselbe Regel geschrieben werden -j ...).

ip iptables debugging packet-analyzer Chris Lercher
quelle

Antworten:

10

Ich kann mir keine direkte Lösung vorstellen, aber ich kann mir überlegen, wie ich ein Paket verfolgen kann.

  1. Protokolliere jede Regel mit einer Protokollpräfix-Direktive (--log-Präfix "Regel 34")
  2. Generieren Sie ein Testpaket oder einen Paketstrom mit scapy und stellen Sie das TOS-Feld auf etwas Einzigartiges ein
  3. Überprüfen Sie die Protokolldatei-Ausgabe für diese TOS-Einstellung und überprüfen Sie, welche Regeln sie protokolliert haben.
Haakon
quelle
Danke für die Idee. Leider kann ich nicht jede Regel protokollieren (Auf einem System wäre die Festplatte wahrscheinlich nicht schnell genug, um das zu tun. Auf einem anderen ist die iptables-Protokollierung im Kernel nicht verfügbar.)
Chris Lercher
1
Verwenden Sie eine Named Pipe als Datei. Softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Da Sie sich jedoch nicht in Ihren Kernel einloggen können, sind Sie ein bisschen SOL
Haakon
Vielen Dank, es wird wahrscheinlich nicht mein Problem lösen, aber es ist im Allgemeinen gut zu wissen, dass Piping-Syslog möglich wäre - könnte sich zu einem anderen Zeitpunkt als nützlich erweisen!
Chris Lercher
Eine verwandte Frage zur Protokollierung: Behandelt iptables mehrere Pakete gleichzeitig (so dass Protokolleinträge verschachtelt werden können)? In diesem Fall denke ich, dass die TOS-Idee für viele iptables LOG-Analysen ein absolutes Muss wäre!
Chris Lercher
Ich kenne die Antwort darauf nicht. Ich gehe jedoch davon aus, dass jede Schnittstelle zumindest von iptables gleichzeitig behandelt wird.
Haakon
82

Wenn Sie einen Kernel und eine Version von iptables haben, die aktuell genug sind, können Sie das TRACE-Ziel verwenden (Scheint in mindestens Debian 5.0 eingebaut zu sein). Sie sollten die Bedingungen für Ihre Ablaufverfolgung so genau wie möglich festlegen und alle TRACE-Regeln deaktivieren, wenn Sie nicht debuggen, da sie viele Informationen in die Protokolle einspeisen.

TRACE
Dieses Ziel markiert Pakete, damit der Kernel jede Regel protokolliert, die mit den Paketen übereinstimmt, wenn diese die Tabellen, Ketten und Regeln durchlaufen. (Das Modul ipt_LOG oder ip6t_LOG ist für die Protokollierung erforderlich.) Die Pakete werden mit dem Zeichenfolgepräfix "TRACE: Tabellenname: Kettenname: Typ: Regelum" protokolliert, wobei Typ "Regel" für einfache Regel und "Rückgabe" für implizite Regel sein kann am Ende einer benutzerdefinierten Kette und "Richtlinie" für die Richtlinie der eingebauten Ketten. Es kann nur in der rohen Tabelle verwendet werden.

Wenn Sie Regeln wie diese hinzugefügt haben

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

Sie erhalten eine Ausgabe, die so aussieht.

# 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
quelle
8
Danke, das ist großartig! Es ist eigentlich die beste Antwort, ich wünschte, ich könnte sie annehmen (es war eine Kopfgeldfrage, daher ist die akzeptierte Antwort definitiv). Ich kann es nicht auf allen meinen Systemen verwenden (aufgrund von Kerneleinschränkungen), auf einigen Systemen jedoch. Diese Antwort verdient die Zustimmung, weil sie dem sehr nahe kommt, wonach ich gesucht habe.
Chris Lercher
Ich fand diese Funktion letzte Nacht, als ich die Manpage von iptables noch einmal las, damit ich eine andere Frage beantworten konnte. Scheint ein relativ neues Feature zu sein. Keine Sorge, dass Sie es nicht als akzeptiert markieren können. Vielleicht wird das im Laufe der Zeit genug bewertet, um mir ein weiteres populistisches Abzeichen zu verdienen.
Zoredache
Dies ist wirklich die kanonische Antwort für die Verfolgung von Paketen in iptables. Es ist schade, dass einige neuere Kernel es nicht standardmäßig aktivieren.
Peter Grace
Wie lange ist es her, dass der Kernel TRACE unterstützt? Ich habe mit Erfolg auf CentOS 6.4 verwendet, aber nicht in CentOS 6.2
3.
6

Drei Antworten auf einen Beitrag:

1) Debug per Skript:

#!/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) Debug von Syslog

Von dieser Website: 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) Kein Debug, nette Iptables bearbeiten:

Auch das kann hilfreich sein: http://www.fwbuilder.org/

Marc Riera
quelle
1
Vielen Dank. Punkt 1) und 3) haben nicht viel damit zu tun, Pakete durch die iptables-Regeln zu verfolgen, aber der Punkt über das Umleiten von Protokolleinträgen basierend auf "--log-level" kann hilfreich sein, wenn ich endlich wirklich zurückgreifen muss Protokollierung (falls es absolut keine andere Lösung gibt).
Chris Lercher
2

hatte die gleiche Frage und fand, dass Zoredache auf TRACE / ipt_LOG zeigte, die Lösung war!

Zusätzlich habe ich ein Skript gefunden, das LOG-Regeln vor allen momentan aktiven iptables-Regeln einfügt / entfernt. Ich habe es ausprobiert und fand es ein wirklich schönes Werkzeug. - Die Ausgabe ähnelt der TRACE-Lösung. - Vorteil: Sie funktioniert in der aktiven iptables-Konfiguration, unabhängig davon, woher sie geladen wurde. Sie können die Protokollierung im laufenden Betrieb ein- und ausschalten! Sie müssen keine Firewall-Skripte ändern, die möglicherweise von Firewall Builder oder einem Tool generiert wurden. - Nachteil: Ohne Änderung erstellt das Skript LOG-Regeln für ALLE aktiven Regeln. Wenn Sie TRACE-Regeln verwenden, beschränken Sie die Protokollierung wahrscheinlich auf Adressen / Dienste / Verbindungen, für die Sie jetzt die Verarbeitung von iptables untersuchen möchten.

Jedenfalls gefällt mir der Ansatz :) Ein dickes Lob an Tony Clayton, schauen Sie mal: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Grüße, Chris

chris
quelle
0

Normalerweise verwende ich Pakete und Bytezähler, um zu sehen, wie Regeln funktionieren und was fehlt oder falsch ist.

Sie können sie mit "iptables -nvL" anzeigen.

Vi.
quelle
2
Ich kann jedoch sehen, was der Autor will. Wenn Sie versuchen, Ihre iptables-Regeln auf einer ausgelasteten Schnittstelle zu testen, hilft es nicht viel, nur die Zähler zu beobachten, insbesondere wenn das Paket wahrscheinlich mit mehreren Regeln übereinstimmt und dabei benutzerdefinierte Ketten umgeht (wie es normalerweise der Fall ist) Herausfiltern unerwünschter IP-Adressen und Überschwemmungsschutzregeln).
PP.
@ PP: Genau, du liest meine Gedanken. @Vi: Danke, das kann unter bestimmten Umständen hilfreich sein, und ich habe das manchmal benutzt. Jetzt brauche ich etwas Mächtigeres.
Chris Lercher
-2

AFAIK ein IP-Paket durchläuft die Regelkette bis zur ersten Übereinstimmung. Ich verstehe also nicht wirklich, wo das Problem liegt. Wenn Sie haben:

  1. Regel 1
  2. Regel 2
  3. Regel 3 LOG

Und ein Paket schafft es ins Protokoll, das bedeutet, dass Regel 3 die erste übereinstimmende Regel ist.

Anonym
quelle
Nicht wahr. Pakete können mit mehreren Regeln übereinstimmen, und das tun sie auch. Wenn eine Regel keine Aktion (wie -j DROPoder -j ACCEPT) hat, passt sie nur weiter in der Kette zusammen.
PP.