iptables (Polski) - ArchWiki

Jump to content

# iptables (Polski)

From ArchWiki

Related articles

- nftables
- Fail2ban
- sshguard
- Simple stateful firewall
- Sysctl#TCP/IP stack hardening
- Uncomplicated Firewall

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.

Note iptables to przestarzały framework, nftables ma na celu zapewnienie nowoczesnego zamiennika, zawierającego warstwę kompatybilności.

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

  https://rocky.eld.leidenuniv.nl/ || arno-iptables-firewallAUR

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

  http://ferm.foo-projects.org/ || ferm

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

  https://firehol.sourceforge.net/ || fireholAUR

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

  https://gitlab.com/hsleisink/firetable || firetableAUR

- firewalld (firewall-cmd) — Demon i interfejs konsoli do konfigurowania stref firewall'a oraz ustalania reguł zapory.

  https://firewalld.org/ || firewalld

- Shorewall — Narzędzie wysokiego poziomu do konfiguracji Netfilter. Konfigurację firewall/gateway definiuje się poprzez wpisy w plikach konfiguracyjnych.

  http://www.shorewall.net/ || shorewallAUR

- Uncomplicated Firewall — Prosty interfejs użytkownika dla iptables.

  https://launchpad.net/ufw || ufw

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

  https://sourceforge.net/projects/peerguardian/ || pglAUR

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

  https://www.vuurmuur.org/ || vuurmuurAUR

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

  https://fwbuilder.sourceforge.net/ || fwbuilder

- firewalld (firewall-config) — Usługa i graficzny interfejs do konfigurowania stref zapory oraz reguł firewall'a.

  https://firewalld.org/ || firewalld

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

  https://gufw.org/ || gufw

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

  https://sourceforge.net/projects/peerguardian/ || pglAUR

- Portmaster — Portmaster to darmowa i otwartoźródłowa zapora sieciowa z domyślnymi ustawieniami, które zwiększają Twoją prywatność.

  https://safing.io/ || portmaster-binAUR

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

1. `raw` służy wyłącznie do konfigurowania pakietów w taki sposób, aby nie były one objęte śledzeniem połączeń.
2. `filter` to domyślna tabela, w której odbywają się wszystkie czynności zwykle kojarzone z zaporą sieciową.
3. `nat` służy do network address translation (np. przekierowania portów).
4. `mangle` służy do specjalistycznych zmian pakietów.
5. `security` sł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

Warning Pozostała część tej sekcji omawia składnię i koncepcje reguł iptables. Nie stanowi ona przewodnika do zabezpieczania serwerów. Aby poprawić bezpieczeństwo systemu, zobacz Simple stateful firewall (minimalnie bezpieczna konfiguracja iptables) oraz Security (hardening Arch Linux).

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

Note Tutaj używamy `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

- Simple stateful firewall
- Router

## 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`.

## Zobacz także

- Wikipedia article
- Port knocking
- Official iptables web site
- iptables Tutorial 1.2.2 by Oskar Andreasson
- Debian Wiki - iptables
- Secure use of connection tracking helpers

Category:

- Firewalls (Polski)

iptables (Polski)
Add topic