iptables (Polski)
iptables to narzędzie wiersza poleceń do konfigurowania zapory sieciowej jądra Linuksa, zaimplementowanej w projekcie Netfilter. Termin iptables jest również powszechnie używany w odniesieniu do tej zapory sieciowej na poziomie jądra. Można ją konfigurować bezpośrednio przy użyciu iptables lub za pomocą jednego z wielu interfejsów konsoli i graficznych. iptables jest używane dla IPv4, a ip6tables dla IPv6. Zarówno iptables, jak i ip6tables mają tę samą składnię, ale niektóre opcje są specyficzne dla IPv4 lub IPv6.
Instalacja
Standardowe jądro Arch Linux jest kompilowane z obsługą iptables. Wystarczy zainstalować narzędzia przestrzeni użytkownika, które zapewnia pakiet iptables. Pakiet iptables jest pośrednią zależnością metapakietu base, dlatego powinien być domyślnie zainstalowany w systemie.
Front-ends
Console
- Zapora Arno — Bezpieczna zapora dla maszyn z jednym lub wieloma interfejsami sieciowymi. Bardzo łatwa w konfiguracji, wygodna w zarządzaniu i wysoce konfigurowalna. Obsługuje: NAT i SNAT, przekierowanie portów, modemy Ethernet ADSL ze statycznymi i dynamicznie przydzielanymi adresami IP, filtrowanie adresów MAC, wykrywanie ukrytego skanowania portów, przekierowanie DMZ i DMZ-2-LAN, ochronę przed zalewaniem SYN/ICMP, zaawansowane logowanie konfigurowalne przez użytkownika z ograniczaniem liczby wpisów zapobiegającym zalewaniu dziennika, wszystkie protokoły IP oraz sieci VPN takie jak IPsec, obsługa wtyczek do rozszerzania funkcjonalności.
- ferm — Narzędzie do zarządzania złożonymi firewallami bez konieczności wielokrotnego przepisywania reguł. Umożliwia przechowywanie całego zestawu reguł w osobnym pliku i ładowanie go jednym poleceniem. Konfiguracja wykorzystuje składnię przypominającą strukturalny język programowania, obsługującą zagnieżdżenia i listy.
- FireHOL — Język do wyrażania reguł firewalla, a nie tylko skrypt tworzący firewall. Umożliwia łatwe budowanie nawet zaawansowanych firewall'i – dokładnie w taki sposób, jaki chcesz.
- Firetable — Narzędzie do zarządzania zaporą iptables. Każdy interfejs można konfigurować oddzielnie za pomocą własnego pliku konfiguracyjnego z prostą i czytelną składnią.
- firewalld (firewall-cmd) — Demon i interfejs konsoli do konfigurowania stref firewall'a oraz ustalania reguł zapory.
- Shorewall — Narzędzie wysokiego poziomu do konfiguracji Netfilter. Konfigurację firewall/gateway definiuje się poprzez wpisy w plikach konfiguracyjnych.
- Uncomplicated Firewall — Prosty interfejs użytkownika dla iptables.
- PeerGuardian (pglcmd) — Aplikacja zapory sieciowej ukierunkowana na bezpieczeństwo. Blokuje połączenia do i z hostów określonych na listach blokowania (zawierające tysiące lub miliony zakresów IP).
- Vuurmuur — Potężny menedżer zapory. Ma prostą i łatwą w obsłudze konfigurację, umożliwiającą zarówno proste, jak i złożone scenariusze. Całą konfigurację można przeprowadzić za pośrednictwem interfejsu GUI opartego na ncurses, który umożliwia bezpieczne zdalne administrowanie przez SSH lub konsolę. Vuurmuur obsługuje kształtowanie ruchu i oferuje zaawansowane funkcje monitorowania, pozwalające administratorowi obserwować logi, połączenia i wykorzystanie przepustowości w czasie rzeczywistym.
Graphical
- Firewall Builder — Narzędzie do konfiguracji i zarządzania zaporą sieciową obsługujące iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA) oraz listy dostępu routerów Cisco. Program działa w systemach Linux, FreeBSD, OpenBSD, Windows i macOS, umożliwiając zarządzanie zaporami lokalnymi i zdalnymi.
- firewalld (firewall-config) — Usługa i graficzny interfejs do konfigurowania stref zapory oraz reguł firewall'a.
- Gufw — Oparty na GTK front-end do ufw, który jest jednocześnie front-endem CLI do iptables (gufw->ufw->iptables). Jest niezwykle łatwy i prosty w użyciu.
- PeerGuardian GUI (pglgui) — Aplikacja zapory sieciowej zorientowana na prywatność. Blokuje połączenia do i od hostów określonych na rozbudowanych listach blokowania (tysiące lub miliony zakresów IP).
- Portmaster — Portmaster to darmowa i otwartoźródłowa zapora sieciowa z domyślnymi ustawieniami, które zwiększają Twoją prywatność.
Podstawowe koncepcje
iptables służy do inspekcji, modyfikacji, przekazywania, przekierowywania i/lub odrzucania pakietów IP. Kod filtrowania pakietów IP jest wbudowany w jądro i zorganizowany w zbiór tabeli, z których każda ma określone przeznaczenie. Tabele składają się z predefiniowanych łańcuchów, zawierających reguły przeglądane sekwencyjnie. Każda reguła zawiera predykat potencjalnych dopasowań i odpowiadającą akcję (zwaną celem), wykonaną gdy predykat jest spełniony. Jeśli pakiet IP dotrze do końca łańcucha (w tym łańcucha pustego), jego ostateczne przeznaczenie określa polityka łańcucha. iptables to narzędzie użytkownika umożliwiające pracę z łańcuchami i regułami. Większość początkujących użytkowników postrzega routing IP w Linuksie jako złożony, jednak w praktyce typowe zastosowania (NAT lub podstawowa zapora sieciowa) są znacznie prostsze.
Kluczem do zrozumienia działania **iptables** jest ten diagram. Słowo małymi literami na górze to tabela, a słowo dużymi literami poniżej to łańcuch. Każdy pakiet IP przychodzący na dowolnym interfejsie sieciowym przechodzi przez ten diagram przepływu od góry do dołu. Powszechnym błędnym przekonaniem jest założenie, że pakiety przychodzące z interfejsu wewnętrznego są obsługiwane inaczej niż pakiety z interfejsu zwróconego do Internetu. Wszystkie interfejsy są obsługiwane w ten sam sposób; to od Ciebie zależy zdefiniowanie reguł, które będą je traktować inaczej. Oczywiście niektóre pakiety są przeznaczone dla procesów lokalnych i przychodzą z góry diagramu, zatrzymując się w punkcie <Local Process>, podczas gdy inne są generowane przez procesy lokalne; zaczynają się w punkcie <Local Process> i przechodzą w dół diagramu. Szczegółowe wyjaśnienie tego diagramu można znaleźć tutaj.
W zdecydowanej większości przypadków użycia nie będzie potrzeby korzystania z tabel raw, mangle ani security. W związku z tym poniższy wykres przedstawia uproszczony przepływ pakietów sieciowych przez „iptables”:
XXXXXXXXXXXXXXXXXX
XXX Network XXX
XXXXXXXXXXXXXXXXXX
+
|
v
+-------------+ +------------------+
|table: filter| <---+ | table: nat |
|chain: INPUT | | | chain: PREROUTING|
+-----+-------+ | +--------+---------+
| | |
v | v
[local process] | **************** +--------------+
| +---------+ Routing decision +------> |table: filter |
v **************** |chain: FORWARD|
**************** +------+-------+
Routing decision |
**************** |
| |
v **************** |
+-------------+ +------> Routing decision <---------------+
|table: nat | | ****************
|chain: OUTPUT| | +
+-----+-------+ | |
| | v
v | +-------------------+
+--------------+ | | table: nat |
|table: filter | +----+ | chain: POSTROUTING|
|chain: OUTPUT | +--------+----------+
+--------------+ |
v
XXXXXXXXXXXXXXXXXX
XXX Network XXX
XXXXXXXXXXXXXXXXXX
Tabele
iptables zawiera pięć tabel:
-
rawsłuży wyłącznie do konfigurowania pakietów w taki sposób, aby nie były one objęte śledzeniem połączeń. -
filterto domyślna tabela, w której odbywają się wszystkie czynności zwykle kojarzone z zaporą sieciową. -
natsłuży do network address translation (np. przekierowania portów). -
manglesłuży do specjalistycznych zmian pakietów. -
securitysłuży do określania reguł sieciowych Mandatory Access Control (np. SELinux — więcej szczegółów można znaleźć w tym artykule).
W większości przypadków użytkownik będzie potrzebować tylko dwóch z nich: filter i nat. Pozostałe tabele są przeznaczone dla złożonych konfiguracji z wieloma routerami i decyzjami routingu, co wykracza poza zakres tego wprowadzenia.
Więzy
Tabele składają się z „łańcuchów", czyli list reguł przetwarzanych sekwencyjnie. Główna tabela filter zawiera trzy wbudowane łańcuchy: INPUT, OUTPUT i FORWARD, które są aktywowane w różnych punktach procesu filtrowania pakietów, jak pokazano na diagramie przepływu. Tabela nat zawiera łańcuchy PREROUTING, POSTROUTING i OUTPUT.
zobacz iptables(8) — opis wbudowanych łańcuchów w innych tabelach.
Domyślnie żaden z łańcuchów nie zawiera żadnych reguł. Musisz dołączyć reguły do łańcuchów, których chcesz używać. Łańcuchy posiadają domyślną politykę, która jest zazwyczaj ustawiona na ACCEPT, ale można ją zresetować na DROP, aby upewnić się, że nic nie przejdzie przez zestaw reguł. Polityka domyślna zawsze obowiązuje tylko na końcu łańcucha. Pakiet musi przejść przez wszystkie istniejące reguły w łańcuchu, zanim polityka domyślna zostanie zastosowana.
Łańcuchy użytkownika można dodawać, aby uczynić zestawy reguł bardziej efektywnymi lub łatwiejszymi w modyfikacji. Przykład użycia łańcuchów użytkownika znajduje się w artykule Simple stateful firewall
Zasady
Filtrowanie pakietów opiera się na regułach, które są określone przez wiele warunków (kryteria, które pakiet musi spełnić, aby reguła mogła być zastosowana) oraz jeden cel (akcja wykonywana gdy pakiet spełnia wszystkie warunki). Typowe kryteria, na podstawie których reguła może się stosować, to interfejs, na którym pakiet się pojawił (np. eth0 lub eth1), typ pakietu (ICMP, TCP lub UDP) lub port docelowy pakietu.
Targety są określane opcją -j lub --jump. Targety mogą być łańcuchami zdefiniowanymi przez użytkownika (jeśli warunki są spełnione, wykonywany jest skok do wskazanego łańcucha i przetwarzanie kontynuuje się tam), jednym ze specjalnych wbudowanych targetów lub rozszerzeniem target'u. Wbudowane targety to ACCEPT, DROP, QUEUE i RETURN; rozszerzeniami target'u są na przykład REJECT i LOG. Gdy targetem jest wbudowany target, los pakietu jest ustalany natychmiast i przetwarzanie pakietu w bieżącej tabeli się kończy. Gdy targetem jest łańcuch użytkownika, a przetwarzanie tego łańcucha nie ustali losu pakietu, pakiet zostanie porównany z pozostałymi regułami oryginalnego łańcucha. Rozszerzenia target'u mogą być kończące (jak wbudowane targety) lub niekończące (jak łańcuchy użytkownika); szczegóły — iptables-extensions(8).
Traversing Chains
Pakiet sieciowy odebrany na dowolnym interfejsie przechodzi przez traffic control chains tabel w kolejności pokazanej na schemacie przepływu. Pierwsza decyzja routingu polega na określeniu, czy ostatecznym celem pakietu jest maszyna lokalna (wtedy pakiet przechodzi przez INPUT chains), czy inny host (wtedy pakiet przechodzi przez FORWARD chains). Kolejne decyzje routingu dotyczą wyboru interfejsu dla pakietu wychodzącego. W każdym chain na ścieżce każda reguła jest oceniana w kolejności, a gdy reguła się dopasuje, wykonywana jest odpowiadająca jej akcja target/jump. Trzy najczęściej używane targety to ACCEPT, DROP oraz skok do chain zdefiniowanego przez użytkownika. Podczas gdy wbudowane chains mogą mieć domyślne policy, user-defined chains nie mogą. Jeśli żadna reguła w chain, do którego nastąpił skok, nie zapewni pełnego dopasowania, pakiet wraca do chain wywołującego; patrz ilustracja. Gdy reguła z targetem DROP się dopasuje, pakiet jest odrzucany i dalsze przetwarzanie zostaje zatrzymane. Jeśli pakiet osiągnie target ACCEPT, nie przechodzi już przez pozostałe reguły chain ani kolejne chains tabeli — przetwarzanie przechodzi do pierwszego chain kolejnej tabeli. Patrz również Traversing of tables and chains oraz Accept Target w tutorialu frozentux.
Moduły
Istnieje wiele modułów, które można wykorzystać do rozszerzenia iptables, takich jak connlimit, conntrack, limit i recent. Moduły te dodają dodatkową funkcjonalność, umożliwiając stosowanie złożonych reguł filtrowania.
Konfiguracja i użytkowanie
Domyślnie iptables udostępnia pusty zestaw reguł w pliku /etc/iptables/iptables.rules. Aby automatycznie ładować reguły iptables podczas rozruchu, możesz włączyć jednostkę iptables.service udostępnianą przez iptables lub uruchomić ją za pomocą systemd, aby załadować reguły natychmiast.
Podobnie, reguły iptables dla IPv6 są domyślnie przechowywane w pliku /etc/iptables/ip6tables.rules, który jest odczytywany przez ip6tables.service. Możesz go uruchomić w ten sam sposób, jak powyżej.
Po dodaniu reguł za pomocą wiersza poleceń, jak pokazano w poniższych sekcjach, plik konfiguracyjny nie zmienia się automatycznie — należy go zapisać ręcznie:
# iptables-save -f /etc/iptables/iptables.rules
Jeśli edytujesz plik konfiguracyjny ręcznie, musisz reload iptables.
Można też załadować go bezpośrednio przez iptables:
# iptables-restore /etc/iptables/iptables.rules
Z wiersza poleceń
Wyświetlanie aktualnej reguły
Podstawowym poleceniem do wyświetlenia listy bieżących reguł jest --list-rules (-S), które ma podobny format wyjściowy do narzędzia iptables-save. Główna różnica: iptables-save domyślnie wyświetla reguły wszystkich tabel, podczas gdy polecenia iptables domyślnie działają na tabeli filter.**
Podczas pracy z iptables w wierszu poleceń polecenie --list (-L) przyjmuje więcej opcji i wyświetla więcej informacji. Na przykład możesz wyświetlić bieżący zestaw reguł i liczbę dopasowań na regułę, używając polecenia:
# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Jeśli wynik wygląda jak powyżej, oznacza to, że w domyślnej tabeli filter nie ma żadnych reguł (tj. nic nie jest blokowane). Inne tabele można określić za pomocą opcji -t.
Aby wyświetlić numery wierszy podczas wyświetlania reguł, dodaj do tego pola --line-numbers. Numery wierszy są przydatnym skrótem podczas #Editing rules w wierszu poleceń.
Resetowanie reguł
Możesz wyczyścić i przywrócić domyślne ustawienia iptables za pomocą następujących poleceń:
# iptables -F # iptables -X # iptables -t nat -F # iptables -t nat -X # iptables -t mangle -F # iptables -t mangle -X # iptables -t raw -F # iptables -t raw -X # iptables -t security -F # iptables -t security -X # iptables -P INPUT ACCEPT # iptables -P FORWARD ACCEPT # iptables -P OUTPUT ACCEPT
Polecenie -F bez argumentów opróżnia wszystkie łańcuchy w bieżącej tabeli. Podobnie, -X usuwa wszystkie puste, inne niż domyślne łańcuchy w tabeli.
Poszczególne łańcuchy można opróżnić lub usunąć, podając po -F i -X argument [chain].
Zasady edycji
Reguły można edytować poprzez: dołączenie -A reguły do łańcucha, wstawienie -I jej w określonym miejscu łańcucha, zastąpienie -R istniejącej reguły lub usunięcie -D jej. Poniżej przedstawiono przykłady trzech pierwszych poleceń.
Po pierwsze, komputer nie jest routerem (chyba że jest routerem). Chcemy zmienić domyślną politykę łańcucha FORWARD z ACCEPT na DROP.
# iptables -P FORWARD DROP
Funkcja synchronizacji LAN Dropbox rozgłasza pakiety co 30 sekund do wszystkich dostępnych komputerów. Jeśli w sieci LAN znajdują się klienty Dropbox, a ta funkcja nie jest używana, można rozważyć odrzucenie tych pakietów.
# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
REJECT zamiast DROP, ponieważ RFC 1122 wymaga, aby hosty zwracały błędy ICMP w miarę możliwości, zamiast porzucać pakiety. Ta strona wyjaśnia, dlaczego prawie zawsze lepiej jest używać REJECT niż DROP.Załóżmy, że rezygnujemy z Dropboxa i chcemy go zainstalować na naszym komputerze. Chcemy również włączyć synchronizację LAN, ale tylko z jednym konkretnym adresem IP w naszej sieci. Powinniśmy zatem użyć -R, aby zastąpić starą regułę. Gdzie 10.0.0.85 to inny adres IP w sieci:
# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Zastąpiliśmy naszą pierwotną regułę regułą, która zezwala adresowi IP 10.0.0.85 na dostęp do portu 17500 na naszym urządzeniu. Uświadamiamy sobie jednak, że to rozwiązanie nie jest skalowalne. Jeśli użytkownik Dropbox próbuje uzyskać dostęp do portu 17500 na naszym urządzeniu, powinniśmy go natychmiast dopuścić, zamiast testować względem kolejnych reguł zapory sieciowej.
Piszemy nową regułę, aby natychmiast zezwolić zaufanemu użytkownikowi. Używając -I, wstawiamy nową regułę przed starą:
# iptables -I INPUT -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */ 2 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Następnie zastąp naszą drugą regułę taką, która odrzuca wszystko na porcie 17500:
# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
Nasza ostateczna lista zasad wygląda następująco:
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */ 2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Allowing multicast traffic
Protokoły wykorzystujące identyfikację multicast (np. SANE wyszukujące skanery sieciowe) wysyłają ruch na adres broadcast sieci, a odpowiedzi przychodzą z adresu IP konkretnego klienta. Ponieważ adresy IP są różne, iptables nie rozpozna odpowiedzi jako RELATED ani ESTABLISHED, i je zablokuje. Aby zaakceptować ruch multicast bez tworzenia zbyt permisywnej zapory, zobacz [1].
Najpierw utwórz kontener hash ipset. Limit czasu to okno czasowe na akceptację odpowiedzi klienta.
# ipset create upnp hash:ip,port timeout 3
Po drugie, utwórz regułę, aby dodać ruch wychodzący multicast do hasha ipset.
# iptables -A OUTPUT -d 239.255.255.250/32 -p udp -m udp -j SET --add-set upnp src,src --exist
Po trzecie, utwórz regułę zezwalającą na ruch przychodzący zgodny z hashem ipset.
# iptables -A INPUT -p udp -m set --match-set upnp dst,dst -j ACCEPT
Na koniec pamiętaj o zapisaniu nowych reguł (zobacz #Configuration and usage i ipset#Making ipset persistent) i upewnij się, że iptables.service i ipset.service są enabled, aby reguły załadowały się przy starcie systemu.
Przewodniki
Logging
Cel LOG może służyć do rejestrowania pakietów spełniających regułę. W przeciwieństwie do innych celów, takich jak ACCEPT lub DROP, pakiet będzie nadal przechodzić przez łańcuch po napotkaniu celu LOG. Oznacza to, że aby włączyć rejestrowanie wszystkich odrzuconych pakietów, należy dodać duplikat reguły LOG przed każdą regułą DROP. Ponieważ zmniejsza to wydajność i zmniejsza przejrzystość, zamiast tego można utworzyć łańcuch logdrop.
Utwórz łańcuch za pomocą:
# iptables -N logdrop
Następnie dodaj następujące reguły do nowo utworzonego łańcucha:
# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG # iptables -A logdrop -j DROP
Wyjaśnienie opcji limit i limit-burst podano poniżej.
Teraz, gdy chcemy odrzucić pakiet i zalogować to, po prostu przeskakujemy do łańcucha logdrop, na przykład:
# iptables -A INPUT -m conntrack --ctstate INVALID -j logdrop
Limiting log rate
Powyższy łańcuch logdrop wykorzystuje moduł limit, aby zapobiec nadmiernemu wzrostowi logu iptables lub niepotrzebnym zapisom na dysku. Bez limitowania błędnie skonfigurowana usługa próbująca się połączyć lub atakujący mógłby zapełnić dysk (lub przynajmniej partycję /var poprzez wpisy do logu iptables.
Moduł limit jest wywoływany za pomocą -m limit. Następnie można użyć --limit do ustawienia średniego tempa oraz --limit-burst do ustawienia tempa początkowego. W powyższym przykładzie logdrop:
iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
Dodaje regułę, która loguje wszystkie pakiety przechodzące przez nią. Pierwsze 10 kolejnych pakietów będą logowane, a następnie tylko 5 pakietów na minutę. Licznik limit burst jest resetowany za każdym razem, gdy limit rate nie zostanie przekroczony, czyli logowanie automatycznie wraca do normy.
Przeglądanie zarejestrowanych pakietów
Zarejestrowane pakiety są widoczne jako komunikaty jądra w systemd journal.
Aby wyświetlić wszystkie pakiety zarejestrowane od momentu ostatniego uruchomienia komputera:
# journalctl -k --grep="IN=.*OUT=.*"
syslog-ng
Zakładając, że używasz syslog-ng, możesz kontrolować, gdzie w pliku syslog-ng.conf będą zapisywane wyniki logów iptables. Zastąp:
filter f_everything { level(debug..emerg) and not facility(auth, authpriv); };
Do
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables); };
Spowoduje to zatrzymanie rejestrowania danych wyjściowych iptables w /var/log/everything.log.
Jeśli chcesz, aby iptables logował do innego pliku niż /var/log/iptables.log, możesz po prostu zmienić wartość pliku docelowego d_iptables tutaj (nadal w syslog-ng.conf):
destination d_iptables { file("/var/log/iptables.log"); };
ulogd
ulogd to specjalistyczny demon rejestrujący pakiety przestrzeni użytkownika dla netfilter, który może zastąpić domyślny cel LOG.