iptables (Polski)

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