Debugger dla Iptables

47

Szukam łatwego sposobu na śledzenie pakietu za pomocą reguł iptables. Nie chodzi o rejestrowanie, ponieważ nie chcę rejestrować całego ruchu (i chcę mieć cele LOG tylko dla kilku reguł).

Coś jak Wireshark dla Iptables. A może nawet coś podobnego do debuggera dla języka programowania.

Dzięki Chris

Uwaga: To nie musi być fantazyjne narzędzie GUI. Ale musi zrobić coś więcej niż tylko wyświetlenie licznika pakietów.

Aktualizacja: wygląda prawie tak, jakbyśmy nie mogli znaleźć niczego, co zapewni wymaganą funkcjonalność. W takim przypadku: znajdźmy przynajmniej dobrą technikę opartą na logowaniu iptables - którą można łatwo włączać i wyłączać i która nie wymaga redundantnego pisania reguł iptables (pisanie tej samej reguły dla -j LOGi -j ...)

Chris Lercher
źródło

Odpowiedzi:

10

Nie mogę wymyślić bezpośredniego rozwiązania, ale mogę wymyślić sposób na śledzenie pakietu.

  1. Zaloguj każdą regułę za pomocą dyrektywy dotyczącej przedrostka dziennika (--log-prefix „Reguła 34”)
  2. Wygeneruj pakiet testowy lub strumień pakietów za pomocą scapy i ustaw pole TOS na coś wyjątkowego
  3. grep wyjście pliku dziennika dla tego ustawienia TOS i zobacz, które reguły je rejestrowały.
Haakon
źródło
Dzięki za pomysł. Niestety nie mogę zarejestrować każdej reguły (w jednym systemie dysk prawdopodobnie nie byłby wystarczająco szybki, aby to zrobić. W innym przypadku rejestrowanie iptables nie jest dostępne w jądrze.)
Chris Lercher
1
Użyj nazwanego potoku jako pliku softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Jednak ponieważ nie możesz zalogować się do swojego jądra, jesteś trochę SOL
Haakon
Dzięki, prawdopodobnie to nie rozwiąże mojego problemu, ale ogólnie miło jest wiedzieć, że syslog z potokami byłby możliwy - może się przydać w innym momencie!
Chris Lercher,
Jedno powiązane pytanie dotyczące rejestrowania: czy iptables obsługuje jednocześnie wiele pakietów (aby wpisy dziennika mogły być przeplatane)? W takim przypadku myślę, że pomysł TOS byłby absolutną koniecznością dla wielu analiz LOG iptables!
Chris Lercher,
Nie znam odpowiedzi na to. Oczekuję jednak, że każdy interfejs będzie obsługiwany co najmniej przez iptables.
Haakon,
82

Jeśli masz wystarczającą ilość jądra i wersji iptables, możesz użyć celu TRACE (Wydaje się, że jest wbudowany przynajmniej w Debian 5.0). Powinieneś ustawić warunki śledzenia tak, aby były jak najbardziej szczegółowe i wyłączyć wszelkie reguły ŚLEDZENIA, gdy nie debugujesz, ponieważ powoduje to wyrzucanie dużej ilości informacji do dzienników.

TRACE
ten cel znaki packes tak, że jądro będzie rejestrować wszelkie reguły, pasujące pakiety jak te przemieszczenia tabel, łańcuchy reguł. (Do rejestrowania wymagany jest moduł ipt_LOG lub ip6t_LOG). Pakiety są rejestrowane z prefiksem ciągu: „ŚLAD: tablename: nazwa łańcucha: typ: reguła” gdzie typ może być „regułą” dla reguły prostej, „powrót” dla reguły ukrytej na końcu łańcucha zdefiniowanego przez użytkownika i „polityki” dla polityki wbudowanych łańcuchów. Można go używać tylko w surowym stole.

Jeśli dodałeś takie reguły

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

Otrzymasz wyjście, które wygląda następująco.

# 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
źródło
8
Dzięki, to jest niesamowite! To właściwie najlepsza odpowiedź, chciałbym móc ją zaakceptować (było to szczere pytanie, więc przyjęta odpowiedź jest jednoznaczna). Chociaż nie mogę go używać na wszystkich moich systemach (z powodu ograniczeń jądra), na niektórych systemach mogę. Ta odpowiedź zasługuje na głosowanie, ponieważ jest bardzo zbliżona do tego, czego szukałem.
Chris Lercher,
Znalazłem tę funkcję zeszłej nocy, kiedy ponownie czytałem stronę podręcznika iptables, aby móc odpowiedzieć na inne pytanie. Wydaje się być stosunkowo nową funkcją. Nie martw się, że nie będziesz mógł oznaczyć go jako zaakceptowany. Być może z czasem zostanie to przegłosowane, aby zdobyć kolejną populistyczną odznakę.
Zoredache,
To jest naprawdę kanoniczna odpowiedź na śledzenie pakietów w iptables. Szkoda, że ​​niektóre najnowsze jądra domyślnie go nie włączają.
Peter Grace,
Jak dawno temu jądro obsługuje TRACE? Z powodzeniem korzystałem z CentOS 6.4, ale nie z CentOS 6.2
wersja
6

Trzy odpowiedzi na jeden post:

1) Debuguj według skryptu:

#!/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) Debugowanie przez syslog

Z tej strony: 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) Bez debugowania, ładna edycja iptables:

Może to również być pomocne: http://www.fwbuilder.org/

Marc Riera
źródło
1
Dzięki. Punkty 1) i 3) nie mają wiele wspólnego z podążaniem za pakietami za pomocą reguł iptables, ale pomoc w przekierowaniu wpisów dziennika na podstawie „--log-level” może być pomocna, jeśli w końcu naprawdę muszę wrócić do logowanie (w przypadku, gdy absolutnie nie ma innego rozwiązania).
Chris Lercher,
2

Miałem to samo pytanie i znalazłem Zoredache wskazujący na TRACE / ipt_LOG było rozwiązaniem!

Dodatkowo znalazłem skrypt, który wstawia / usuwa reguły LOG poprzedzające wszystkie aktualnie aktywne reguły iptables. Wypróbowałem to i odkryłem, że to naprawdę miłe narzędzie. - Dane wyjściowe są podobne do rozwiązania TRACE - Zaleta: działa na aktywnej konfiguracji iptables, bez względu na to, skąd został załadowany. Możesz włączyć / wyłączyć logowanie w locie! Nie musisz modyfikować żadnych skryptów zapory, które mogły zostać wygenerowane przez Firewall Builder lub narzędzie, którego używasz ... - Wada: bez modyfikacji skrypt tworzy reguły LOG dla WSZYSTKICH aktywnych reguł. Zamiast tego, korzystając z reguł TRACE, prawdopodobnie ograniczysz rejestrowanie do adresów / usług / połączeń, dla których chcesz teraz sprawdzić przetwarzanie iptables.

W każdym razie podoba mi się podejście :) Uznanie dla Tony'ego Claytona, zobacz: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Pozdrawiam Chris

Chris
źródło
0

Zwykle używam liczników pakietów i bajtów, aby zobaczyć, jak działają reguły i znaleźć to, czego brakuje lub które są złe.

Możesz je wyświetlić za pomocą „iptables -nvL”.

Vi.
źródło
2
Widzę jednak, czego chce autor; jeśli próbujesz przetestować reguły iptables na zajętym interfejsie, samo obserwowanie liczników nie bardzo pomoże, szczególnie jeśli pakiet prawdopodobnie dopasuje się do kilku reguł i przeskoczy wokół łańcuchów zdefiniowanych przez użytkownika (co jest typowe, gdy filtrowanie niechcianych adresów IP i reguł ochrony przeciwpowodziowej).
PP.
@PP: Dokładnie, czytasz mi w myślach. @Vi: Dzięki, może to być pomocne w niektórych okolicznościach i czasami z tego korzystałem. Teraz potrzebuję czegoś mocniejszego.
Chris Lercher,
-2

AFAIK pakiet IP przechodzi przez łańcuch reguł aż do pierwszego dopasowania. Więc tak naprawdę nie rozumiem, na czym polega problem. Jeśli masz:

  1. Zasada nr 1
  2. reguła 2
  3. reguła 3 LOG

Pakiet trafia do dziennika, co oznacza, że ​​reguła 3 jest pierwszą pasującą regułą.

Anonimowy
źródło
Nie prawda. Pakiety mogą pasować do wielu reguł i tak się dzieje. O ile reguła nie ma akcji (jak -j DROPlub -j ACCEPT), po prostu będzie kontynuowała dopasowywanie dalej w dół łańcucha.
PP.