Sieci w Linuksie/Netfilter/iptables/akcje

Akcje to czynności, którym zostanie poddany pakiet dopasowany przez daną regułę. Każda reguła może posiadać tylko jedną akcję, dlatego jeżeli pakiet w danym łańcuchu musi zostać poddany kilku akcjom, to należy albo użyć kilku reguł z takimi samymi dopasowaniami i różnymi akcjami, albo jeżeli nie jest to z jakiegoś powodu wskazane należy użyć podłańcuchów. Akcje, które można wykonać na danym pakiecie specyfikuje się za pomocą dwóch opcji:

-j --jump CEL|ŁAŃCUCH - wykonuje akcję zadaną przez CEL, lub przenosi przetwarzanie pakietu do łańcucha o nazwie ŁAŃCUCH (jeżeli istnieje, jeżeli nie to nie uda się dodać reguły).

-g --goto ŁAŃCUCH - przenosi przetwarzanie pakietu do łańcucha o nazwie ŁAŃCUCH.

Brak opcji oznacza, że żadna akcja nie zostanie wykonana, ale nastąpi dodanie pakietu do licznika dopasowanych przez regułę pakietów.

Różnica pomiędzy akcjami dla łańcuchów jest następująca: w przypadku użycia -j ŁAŃCUCH pakiet, którego los nie zostanie określony wewnątrz tego łańcucha (lub jego podłańcuchów) będzie dalej przetwarzany od następnej reguły po regule definiującej skok. W przypadku akcji -g ŁAŃCUCH pakiet po dojściu do końca tego łańcucha nie wróci do punktu wywołania, tylko zostanie potraktowany domyślną polityką łańcucha, od którego rozpoczął przetwarzanie.

Przykład

-j	-g
iptables -P INPUT DROP # 0 iptables -N SSH # 0 iptables -A INPUT -p tcp --dport 22 -j SSH # 1 iptables -A SSH -s 192.168.0.10 -j ACCEPT # 2 iptables -A INPUT -s 192.168.0.100 -j ACCEPT # 3	iptables -P INPUT DROP # 0 iptables -N SSH # 0 iptables -A INPUT -p tcp --dport 22 -g SSH # 1 iptables -A SSH -s 192.168.0.10 -j ACCEPT # 2 iptables -A INPUT -s 192.168.0.100 -j ACCEPT # 3
Pakiet z adresu 192.168.0.10 na port 22 TCP Pakiet przechodzi przez regułę (1), która dokonuje przeskoku przetwarzania do łańcucha SSH W łańcuchu SSH pakiet trafia na regułę (2), która przepuszcza pakiet. Pakiet z adresu 192.168.0.100 na port 22 TCP Pakiet przechodzi przez regułę (1), która dokonuje przeskoku przetwarzania do łańcucha SSH Pakiet przechodzi przez regułę (2) w łańcuchu SSH, jednak nie jest dopasowywany Pakiet wraca do łańcucha INPUT, w którym następną regułą za (1) jest (3) Pakiet zostaje zaakceptowany przez regułę (3)	Pakiet z adresu 192.168.0.10 na port 22 TCP Pakiet przechodzi przez regułę (1), która dokonuje przejścia przetwarzania do łańcucha SSH W łańcuchu SSH pakiet trafia na regułę (2), która przepuszcza pakiet. Pakiet z adresu 192.168.0.100 na port 22 TCP Pakiet przechodzi przez regułę (1), która dokonuje przeskoku przetwarzania do łańcucha SSH Pakiet przechodzi przez regułę (2) w łańcuchu SSH, jednak nie jest dopasowywany Pakiet trafia do domyślnej polityki łańcucha INPUT, czyli zostaje zrzucony

Poniżej znajduje się lista obsługiwanych celi (ang. target). Większość z nich przyjmuje dodatkowe parametry, które należy podać, aby cel był poprawnie zdefiniowany.

ACCEPT

Ten cel zawsze kończy przetwarzanie pakietu, dodatkowo ma dwojakie znaczenie, w zależności od tego, w jakiej tablicy zostanie użyty:

filter

Pakiet zostaje zaakceptowany. Następuje koniec przetwarzania tego pakietu w tej tablicy. Pakiet zostanie przekazany do aplikacji użytkownika (dla INPUT), przekazany dalej (dla FORWARD), lub wypuszczony z komputera (dla OUTPUT). Jest to domyślna akcja dla łańcuchów w tablicy filter.

raw, mangle, nat

Pakiet nie będzie podlegał zmianie w danym łańcuchu tablicy. Następuje koniec przetwarzania pakietu dla tego łańcucha tablicy. W tablicy 'nat wszystkie kolejne pakiety tego połączenia będą podlegać tej samej regule. Jest to domyślna akcja dla łańcuchów w wymienionych tablicach.

CLASSIFY

Ten cel może zostać użyty tylko w tablicy mangle. Nie kończy przetwarzania pakietu. Pozwala on na sklasyfikowanie pakietu, czyli ustawienie wartości skb->priority w jądrze. Cel ten posiada tylko jedną opcję:

--set-class major:minor - ustawia wartość pola skb->priority na zadaną wartość. major:minor jest jednocześnie adresem kolejki QoS, która ma obsłużyć dany pakiet. Obie liczby są interpretowane jako szesnastkowe niezależnie czy zostaną zapisane z prefiksem 0x.

Uwaga

Dla niektórych ustawień QoS ustawianie adresu nieistniejącej kolejki może powodować dziwne zachowanie całego QoS.

Przykłady

iptables -t mangle -A POSTROUTING -d 192.168.100.0/24 -j CLASSIFY --set-class 0:0

• Powyższe polecenie ustala dla pakietów kierowanych na adresy 192.168.100.0/24 użycie kolejki o adresie 0:0. W domyślnej konfiguracji QoS oznacza to kanał dyscypliny pfifo_fast o najniższym priorytecie.

CONNMARK

Cel ten może zostać użyty w dowolnej tablicy, nie kończy przetwarzania pakietu. Służy do ustawiania znacznika połączenia w pakietach. Znacznik połączenia (ctmark) dotyczy całego połączenia i jest niezależnym bytem względem znacznika pakietu (nfmark). ctmark podobnie jak nfmark posiada rozmiar 32bitów. Dostępne opcje:

--set-xmark wartość[/maska] - zeruje bity podane w masce, a następnie XORuje ctmark z wartością. Zgodnie z równaniem ctmark = (ctmark & ~maska) ^ wartość.

--save-mark [--nfmask nfmask] [--ctmask ctmask] - kopiuje znacznik pakietu nfmark do znacznika połączenia ctmark używając podanych masek. Nowa wartość nfmask jest obliczana zgodnie ze wzorem: nfmark = (ctmark & ~ctmask) ^ (nfmark & nfmask).

--restore-mark [--nfmask nfmask] [--ctmask ctmask] - kopiuje znacznik połączenia ctmark do znacznika pakietu nfmark używając podanych masek. Nowa wartość nfmark obliczana jest zgodnie ze wzorem: nfmark = (nfmark & ~nfmask) ^ (ctmark & ctmask). Tej opcji można użyć tylko w tablicy mangle.

--and-mark bity - wykonuje operację AND pomiędzy ctmark a bity (skrót dla --set-xmark 0/invbits, gdzie inbits to odwórcone bity).

--or-mark bity - wykonuje operację OR pomiędzy ctmark a bity (skrót dla --set-xmark bity/bity).

--set-mark wartość[/maska] - ustawia ctmark na wartość. Jeżeli podana jest maska, tylko bity ustawione w masce są zmieniane.

--save-mark [--mask maska] - kopiuje nfmark do ctmark, jeżeli podana jest maska, tylko bity z maski są modyfikowane.

--restore-mark [--mask maska] - kopiuje ctmark do nfmark, jeżeli podana jest maska, tylko bity z maski są modyfikowane. Tej opcji można użyć tylko w tablicy mangle.

Uwagi

• Należy pamiętać, że nfmark jest własnością pakietu przechowywaną w jądrze w strukturze skb, natomiast ctmark jest własnością połączenia śledzonego przez mechanizm conntrack.
• Ponieważ nfmark jest własnością pakietu, pomimo że cel CONNMARK można używać w dowolnej tablicy, to opcja --restore-mark jest dopuszczalna tylko w tablicy mangle.
• Jeżeli mechanizm conntrack nie jest używany (np. z powodu użycia celu NOTRACK), to nie da się używać celu CONNMARK na nieśledzonych pakietach (co wynika bezpośrednio z uwagi pierwszej).

Przykłady

iptables -A FORWARD -p tcp --dport 80 -m statistic --mode random --probability 0.01 -j MARK --set-mark 0x80	# 1
iptables -t mangle -A POSTROUTING -m mark --mark 0x80/0x80 -j CONNMARK --save-mark				# 2
iptables -t mangle -A POSTROUTING -m connmark --mark 0x80/0x80 -j CONNMARK --restore-mark			# 3

• Powyższe 3 reguły pozwalają na propagację znacznika pakietu przypisanego jednemu pakietowi (losowo wybranemu) na wszystkie kolejne pakiety danego połączenia. Reguła (1) ustawia losowo wybranym pakietom przekazywanym na port 80 znacznik nfmark na 0x80. Reguła (2) kopiuje znacznik nfmark do znacznika ctmark, jeżeli ustawiony jest 7 bit w nfmark. Reguła (3) kopiuje z powrotem nfmark do ctmark dla wszystkich pakietów, dla których ustawiony jest 7 bit w ctmark. W ten sposób nfmark został rozpropagowany na wszystkie pakiety należące do połączenia.

DNAT

Ten cel może zostać użyty tylko w tablicy nat w łańcuchach PREROUTING i OUTPUT (oraz łańcuchach wywoływanych tylko przez reguły z tych łańcuchów). Cel ten kończy przetwarzanie pakietu. Służy do modyfikacji adresu docelowego pakietu (oraz opcjonalnie portu docelowego dla TCP i UDP). Dzięki mechanizmowi śledzenia połączeń wszystkie kolejne pakiety tego połączenia podlegać będą tej samej regule DNAT nawet po skasowaniu samej reguły. Odwracanie DNAT w pakietach powracających realizowane jest automatycznie bez dodatkowych reguł iptables. Nazwa DNAT jest angielskim akronimem od Destination Network Adress Translation. Parametry tego celu:

--to-destination adres1[-adres2][:port1[-port2]] - specyfikuje docelowy adres IP (lub zakres adresów) oraz ewentualnie docelowy port (lub zakres portów). Specyfikacja portów docelowych może zostać podana tylko w regule, w której użyte jest dopasowanie -p udp, lub -p tcp. W przypadku nie podania portu docelowego pozostaje on bez zmian.

--random - wymusza użycie losowego wyboru mapowanych portów (w jądrach >= 2.6.22).

--persistent - gwarantuje użycie tego samego adresu źródłowego/docelowego dla danego hosta przy kolejnych połączeniach. Opcja ta pozwala zastąpić cel SAME (w jądrach >= 2.6.29-rc2).

Uwagi

Uwagi analogiczne jak dla celu SNAT.

Przykłady

iptables -t nat -A PREROUTING -i eth0 -d 195.4.5.6 -j DNAT --to-destination 192.168.55.7

Powyższa reguła pozwala przekierowywać ruch kierowany na np. zewnętrzny adres IP serwara dostępnego w sieci lokalnej na jego lokalny adres IP. Aby tego typu konfiguracja zadziałała maszyna, na której stosuje się tę regułę musi obsługiwać również ruch powracający (np. adres 192.168.55.7 nie może być dostępny bez pośrednictwa routera, na którym robi się DNAT).

DROP

Cel ten może zostać użyty tylko w tablicy filter we wszystkich łańcuchach. Cel ten kończy przetwarzanie pakietu. Pakiet jest zrzucany - nie zostaje wpuszony, przekazany, wypuszczony (kolejno w łańcuchach INPUT, FORWARD, OUTPUT), nie jest również generowany żaden komunikat ICMP o błędzie. Cel ten służy do cichego znikania pakietów. W przypadku łańcucha OUTPUT aplikacja próbująca otworzyć połączenie, które jest dropowane otrzymuje błąd EINVAL w funkcji socket. Jest to najczęściej stosowany cel do blokowania ponieważ jego użycie nie generuje dodatkowego ruchu sieciowego (w przeciwieństwie do celu REJECT). Skanery portów typu nmap oznaczają porty, z których nie wraca żadna odpowiedź jako filtered (ang. filtrowany) domniemując istnieje po drodze firewalla, który dropuje pakiety.

DSCP

Cel ten może zostać użyty tylko w tablicy mangle. Cel ten nie kończy przetwarzania pakietu. Pozwala na zmianę wartości bitów DSCP w nagłówku TOS dla IPv4. Cel ten posiada dwie opcje:

--set-dscp wartość - ustawia wartość pola DSCP. wartość może być liczbą dziesiętną, lub szesnastkową z przedziału 0-32.

--set-dscp-class klasa - ustawia wartość pola DSCP na podstawie podanej nazwy klasy protokołu DiffServ.

Dostępne klasy DiffServ

IMQ

Cel ten pozwala na przesłanie pakietu do urządzenia IMQ (ang. intermediate queueing device), w którym można przeprowadzić sterowanie przepływem. Cel ten nie ma wpływu na przejście pakietu przez iptables, ponieważ IMQ jest urządzeniem wirtualnym, które nie jest widoczne w iptables. Cel ten można użyć w zależności od konfiguracji IMQ, albo w tablicy mangle, albo nat w łańcuchach PREROUTING, lub POSTROUTING, albo w tablicy filter w łańcuchach FORWARD, lub OUTPUT. Cel ten nie kończy przetwarzania pakietu. Cel ten posiada jedną opcję:

-to-dev liczba - wybiera numer urządzenia IMQ, do którego trafi pakiet. Domyślna wartość to 0.

Uwagi

• Istnieje nowocześniejsze rozwiązanie niż IMQ służące do tego samego celu - IFB, urządzenia IFB są wywoływane przez filtry definiowane za pomocą polecenia tc
• Moduł IMQ nie jest standardowym komponentem jądra, ani iptables. W większości sytuacji należy samemu dodać odpowiednie łatki do jądra i iptables.
• Dodanie modułu IMQ do niewspieranego jądra może spowodować, że po uruchomieniu urządzeń IMQ i przekierowaniu do nich pakietów pakiety te znikną! Dlatego należy przetestować ten moduł na systemie nieprodukcyjnym.
• Przed użyciem celu IMQ należy się upewnić, że urządzenie imq jest włączone (`ip link set dev imqX up`).
• Moduł IMQ w jądrze może być skonfigurowany na jeden z 4 sposobów (wybieranymi podczas konfiguracji jądra na sztywno). Sposoby te określają moment, w którym pakiety są kierowane do urządzeń imqX w trakcie przetwarzania przez Netfilter.

ustawienie | PREROUTING | POSTROUTING
-----------+------------+-------------
    AA     |  po NAT    |  po NAT
    AB     |  po NAT    |  przed NAT
    BA     |  przed NAT |  po NAT
    BB     |  przed NAT |  przed NAT

Oznacza to, że dla poszczególnych konfiguracji należy w następujących momentach użyć tego celu:

ustawienie	pakiety przychodzące		pakiety wychodzące
	najwcześniej	najpóźniej	najwcześniej	najpóźniej
AA	-t mangle -A PREROUTING	-t nat -A PREROUTING	-t mangle -A POSTROUTING	-t nat -A POSTROUTING
AB	-t mangle -A PREROUTING	-t nat -A PREROUTING	-t mangle -A POSTROUTING	-t mangle -A POSTROUTING
BA	-t mangle -A PREROUTING	-t mangle -A PREROUTING	-t mangle -A POSTROUTING	-t nat -A POSTROUTING
BB	-t mangle -A PREROUTING	-t mangle -A PREROUTING	-t mangle -A POSTROUTING	-t mangle -A POSTROUTING

Przykłady

modprobe imq numdevs=2
ip link set dev imq0 up
ip link set dev imq1 up
# tc ...
# konfiguracja tc dla urządzenia imq 
# tc ...
iptables -t mangle -A PREROUTING -i ppp+ -j IMQ --to-dev 0
iptables -t nat -A POSTROUTING -o ppp+ -j IMQ --to-dev 1

Powyższy przykład umożliwia realizowanie QoS w urządzeniach imq0 i imq1 dla wszystkich interfejsów ppp na raz (imq0 dla połączeń wchodzących, a imq1 dla połączeń wychodzących). Elementy QoS konfiguruje się za pomocą polecenia tc wchodzącego w skład narzędzi iproute2 (opisanego w rozdziale Sieci:Linux/iproute2/tc). W powyższym przykładzie przyjęte jest założenie, że urządzenie IMQ jest w konfiguracji BA. Jest to bardzo ważna informacja, jeżeli planuje się klasyfikować ruch na podstawie adresów źródłowych/docelowych w pakietach.

LOG

Cel ten może zostać użyty w dowolnej tablicy/łańcuchu. Cel ten nie kończy przetwarzania pakietu. Pozwala na logowanie przez jądro informacji o pakiecie. Logowane informacje są dostępne za pomocą polecenia dmesg oraz w logach systemowych. Nie jest to optymalna metoda logowania pakietów, obecnie zaleca się stosowanie celu ULOG. Opcje przyjmowane przez ten cel:

--log-level poziom - poziom istotności w systemie logowania (0-7). W zależności od ustawień systemowych wyższe poziomy mogą powodować np. informowanie na konsoli wszystkich zalogowanych użytkowników, wysyłanie maila do administratora, itp.

--log-prefix prefix - prefiks dodawany do każdej logowanej linijki. Maksymalna długość to 29 znaków. Przydatne do filtrowania zawartości logów.

--log-tcp-sequence - logowanie numerów sekwencyjnych w TCP. Opcja ta narusza bezpieczeństwo, jeżeli zwykli użytkownicy mają dostęp do logów (w większości dystrybucji zwykły użytkownik może wywołać polecenie dmesg!).

--log-tcp-options - logowanie opcji z nagłówka TCP.

--log-ip-options - logowanie opcji z nagłówka IP.

--log-uid - logowanie UID (identyfikator liczbowy użytkownika) procesu, który wygenerował pakiet (tylko dla pakietów wygenerowanych lokalnie).

Poziomy logowania

emergency (0)

alert (1)

critical (2)

error (3)

warning (4)

notice (5)

info (6)

debug (7)

Przykłady

iptables -N LOGDROP #1
iptables -A LOGDROP -j LOG --log-level 7 --log-prefix 'FW logdrop ' #2
iptables -A LOGDROP -j DROP #3
iptables -A INPUT -i eth1 -p tcp --dport 22 -j LOGDROP #4

Reguły (1-3) tworzą łańcuch LOGDROP, który loguje przechodzący przez niego pakiet, a następnie go dropuje. Następnie do tego łancucha można wysyłać pakiety, które z jednej strony chcemy zrzucić, ale z drugiej warto, aby pozostawiły ślad w logach. Reguła (4) jest tego przykładem.

MARK

Ten cel może zostać użyty tylko w tablicy mangle. Cel ten nie kończy przetwarzania pakietu. Służy do ustawiania znaczników w pakietach (ang. fwmark, firewall mark, nfmark, netfilter mark). Znaczniki te są jedynie elementami struktury skb przechowującej w jądrze pakiet, nie są dostępne ani na zewnątrz lokalnego komputera (nie są elementem pakietu jako takiego), ani dla aplikacji użytkownika. Znaczniki mogą być natomiast odczytywane przez różne elementy podsystemu obsługi sieci w jądrze (znaczniki mogą zapisywać/odczytywać m. in. iptables, ebtables, mechanizm routingu, czy QoS). Cel ten posiada następujące opcje:

--set-xmark wartość[/maska] - Zeruje bity znacznika ustawione w masce, a następnie wykonuje operację XOR z wartość. nfmark = (nfmark & ~maska) ^ wartość. Domyślną wartością maski jest 0xFFFFFFFF (znacznik jest wartością 32bitową).

--set-mark wartość[/maska] - Zeruje bity znacznika ustawione w masce, a następnie wykonuje operację OR z wartość. nfmark = (nfmark & ~maska) | wartość. Domyślną wartością maski jest 0xFFFFFFFF.

Poniższe 3 opcje są wersjami skróconymi powyższych:

--and-mark wartość - Wykonuje operację AND pomiędzy znacznikiem, a wartością. Jest równoważne z --set-xmark 0/invbits, gdzie invbits to zanegowana (binarnie) wartość.

--or-mark wartość - Wykonuje operację OR pomiędzy znacznikiem, a wartością. Jest równoważne z --set-mark wartość/0.

--xor-mark wartość - Wykonuje operację XOR pomiędzy znacznikiem, a wartością. Jest równoważne z --set-xmark wartość/0.

Uwagi

• Istnieją dwie szkoły stosowania znaczników - jedna polega na przypisywaniu znacznikom konkretnej wartości liczbowej, a potem dopasowywaniu tej wartości, a druga polega na ustawianiu w znacznikach flag - pojedynczych bitów, których ustawienie na 1 niesie pewną informację oraz późniejsze sprawdzanie ustawienia poszczególnych bitów.

Przykłady

iptables -t mangle -A PREROUTING -s 192.168.129.77 -j MARK --set-mark 77

• Ustawia znacznik na wartość 77 dla pakietów z źródłowym adresem IP 192.168.129.77.

iptables -t mangle -A PREROUTING -s 192.168.129.1 -j MARK --or-mark 0x10000

• Ustawia 16 bit (licząc od 0) znacznika na 1.

MASQUERADE

Ten cel może zostać użyty tylko w tablicy nat w łańcuchu POSTROUTING. Cel ta kończy przetwarzanie pakietu. Służy do modyfikacji adresu źródłowego pakietu (oraz opcjonalnie portu źródłowego dla TCP i UDP). Odwracanie MASQUERADE w pakietach powracających realizowane jest automatycznie bez dodatkowych reguł iptables. Parametry tego celu:

--to-ports [port1[-port2]] - specyfikuje źródłowy port (lub zakres portów). Specyfikacja portów źródłowych może zostać podana tylko w regule, w której użyte jest dopasowanie -p udp, lub -p tcp. W przypadku niepodania portów stosowana jest następująca zasada: porty <512 są mapowane na porty <512, porty >=512 i <=1023 będą mapowane na porty <1024, a porty >=1024 będą mapowane na porty >=1024. Tam, gdzie będzie to możliwe nie będzie mapowania portów.

--random - wymusza użycie losowego wyboru mapowanych portów (w jądrach >= 2.6.21).

Uwagi

• conntrack posiada moduły pomocnicze pozwalające na natowanie (a więc i maskaradę) połączeń w takich protokołach jak PPTP, SIP, FTP
• Mapowanie MASQUERADE w protokołach TCP i UDP jest realizowane na podstawie 4 liczb (ang. touple): src.ip, src.port, dst.ip, dst.port. Oznacza to, że poniższa reguła:

iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 22 -j MASQUERADE --to-ports 1278

Sprawi, że można będzie się połączyć z dowolną liczbą serwerów SSH na raz, ale tylko jednym połączeniem z danym IP. Spowodowane jest to tym, że dla dwóch połączeń SSH do tego samego serwera touple w pakietach obu połączeń będzie identyczna.

• MASQUERADE ustawia tylko poprawny adres źródłowy przypisany do interfejsu, przez który wychodzi ruch. Aby pakiety wróciły na inny adres musisz użyc celu SNAT
• MASQUERADE stosujemy zamiast SNAT w przypadku gdy nie jest znany adres IP interfejsu, przez który wychodzi ruch. Tak bywa gdy adres ten jest dynamiczny (na przykład usługa neostrada w TPSA). Jeśli adres ten jest stały i znany to lepiej zastosować SNAT gdyż jest on szybszy.

Przykłady

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

• Powyższa reguła realizuje maskaradę umożliwiający komputerom w sieci lokalnej dostęp do Internetu poprzez interface eth1

iptables -t nat -A POSTROUTING -o eth1 -p tcp -j MASQUERADE --to-ports 1024-2048

• Za pomocą MASQUERADE można w prosty sposób ograniczyć wybór portów, przez które będzie wychodził ruch z lokalnej maszyny

MIRROR

Ten cel może zostać użyty tylko w tablicy ??, w łańcuchach INPUT, FORWARD, PREROUTING lub łańcuchach z nich wywoływanych. Powoduje on zamianę adresu źródłowego i docelowego w pakiecie oraz retransmisję. W celu uniknięcia zapętleń, pakiety podlegające zwierciadlanemu odbiciu nie są widzane w tablicy filter, ani przez mechanizm NAT, czy conntrack.

NETMAP

Ten cel może zostać użyty tylko w tablicy nat. Cel ten kończy przetwarzanie pakietu. Pozwala na dokonanie translacji adresów 1:1 (tzw. NAT 1:1). Oznacza to, że adresy pochodzące z danej sieci są natowane na adresy z innej sieci o tym samym rozmiarze. Cel ten przyjmuje jedną opcję:

--to adres/maska - ustawia adres sieci używany do NAT (w formacie CIDR). W natowanym adresie ilość bitów maska jest zastępowana bitami z adres.

Uwagi

• Cel NETMAP w zależności od tego, czy znajduje się w łańcuchu PREROUTING, czy POSTROUTING (lub OUTPUT) dokonuje DNAT, lub SNAT.
• W regułach wykorzystujących NETMAP warto zawsze użyć dopasowania z siecią mniejszą, lub równą sieci, na którą się natuje. Dla poniższej reguły:

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j NETMAP --to 172.16.16.0/24

Adresy ip 192.168.10.100 i 192.168.20.100 zostaną natowane na ten sam adres 172.16.16.100!

Przykłady

iptables -t nat -A PREROUTING -d 192.168.0.0/24 -j NETMAP --to 172.16.16.0/24

• Dokonuje DNAT pakietów przychodzących w taki sposób, że dowolny adres docelowy z sieci 192.168.0.0/24 zostanie zastąpiony przez odpowiadający adres z sieci 172.16.16.0/24. Na przykład adres docelowy 192.168.0.125 zostanie zamieniony na adres 172.16.16.125.

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j NETMAP --to 172.16.16.0/24

• Powyższa linijka dokonuje SNAT pakietów przychodzących z sieci 192.168.0.0/24 na odpowiadające adresy z sieci 172.16.16.0/24

• Poniższy przykład pokazuje w jaki sposób mając pulę adresów publicznych (np. 140.0.120.64/27) można natować je na adresy z sieci prywatnej (np. fragment sieci 192.168.150.0/24).

iptables -t nat -A PREROUTING -i eth1 -d 140.0.120.64/27 -j NETMAP --to 192.168.150.0/27	# 1
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.150.0/27 -j NETMAP --to 140.0.120.64/27	# 2

Linijka (1) dokonuje natowania adresów publicznych na adresy prywatne, dzięki czemu serwery będąc w sieci prywatnej będą widoczne w internecie pod odpowiadającymi adresami publicznymi. Linijka (2) pozwala serwerom wychodzić na świat za pomocą przyporządkowanych adresów publicznych. Warto zwrócić uwagę, że ponieważ operacje natowania są realizowane na reprezentacji binarnej adresów IP ich reprezentacje dziesiętne nie muszą zaczynać się w tym samym miejscu - w powyższym przykładzie zachodzi np. translacja 192.168.150.10 <=> 140.0.120.74.

NOTRACK

Cel ten może zostać użyty tylko w tablicy raw, służy do wyłączenia mechanizmu conntrack dla danego połączenia.

Uwaga

• Jeżeli cel NOTRACK zostanie użyty tylko na pakiecie TCP SYN (zamiast na wszystkich pakietach połączenia, które jest inicjowane) spowoduje to oznaczenie kolejnych pakietów tego połączenia jako stan INVALID, ponieważ mechanizm conntrack nie widział nawiązywania połączenia.

Przykłady

iptables -t raw -A PREROUTING -p tcp --dport 389 -j NOTRACK

• Powyższa reguła sprawi, że wszystkie nadchodzące pakiety na port LDAP nie będą śledzone przez mechanizm conntrack.

REDIRECT

Ten cel może zostać użyty tylko w tablicy nat w łańcuchach PREROUTING i OUTPUT (oraz łańcuchach wywoływanych tylko przez reguły z tych łańcuchów). Cel ten kończy przetwarzanie pakietu. Przekierowuje pakiet do lokalnej maszyny przez DNATowanie adresu docelowego na główny adres IP interfejsu, przez który pakiet wszedł (dla ruchu generowanego lokalnie 127.0.0.1). Opcje:

--to-ports port1[-port2] - Ustawia docelowy adres portu na zadany port (lub zakres portów). Tej opcji można użyć tylko w regule, w której użyto dopasowania -p tcp, lub -p udp.

--random - - wymusza użycie losowego wyboru mapowanych portów (w jądrach >= 2.6.22).

Uwagi

• Poniższa reguła:

iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 3128

Jest równoważna grupie reguł:

iptables -t nat -A PREROUTING -i $interfejs -p tcp -j DNAT --to-destination $adres:3128

Gdzie $interfejs są kolejnymi nazwami interfejsów sieciowych, a $adres przyporządkowanymi im adresom IP

• Pakiety przekierowywane przez tą regułę są normalnie przetwarzane w tablicy filter łańcuchu INPUT, więc jeśli domyślną polityką nie jest ACCEPT, należy dodać reguły wpuszczające przekierowany ruch

Przykłady

iptables -t nat -A PREROUTING -i eth0 -s 192.168.1.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 3128

Powyższa reguła pozwala na przekierowanie ruchu kierowanego na port 80 (HTTP) na port 3128 (domyślny port serwera proxy squid). W ten sposób można zrealizować transparent proxy (w serwerze squid wymagane jest ustawienie odpowiedniej opcji, aby przekierowywane połączenia były poprawnie obsługiwane).

REJECT

Cel ten może zostać użyty jedynie w tablicy filter we wszystkich trzech łańcuchach. Podobnie jak DROP jest to cel kończący przetwarzanie pakietu oraz jego zatrzymanie przez system, jednak powoduje on wysłanie dodatkowo pakietu ICMP z informacją napotkanym błędzie. Opcje obsługiwane przez ten cel:

--reject-with typ - ustawia typ komunikatu ICMP wysyłanego po zatrzymaniu pakietu.

Możliwe typy

icmp-net-unreachable - sieć niedostępna

icmp-host-unreachable - host niedostępny

icmp-port-unreachable - port niedostępny (domyśłny komunikat). Komunikat ten jest również standardową odpowiedzią hosta na próbę połączenia z portem, na którym nie nasłuchuje żadna aplikacja

icmp-proto-unreachable - nie obsługiwany protokół warstwy 4

icmp-net-prohibited - sieć zabroniona

icmp-host-prohibited - host zabroniony

icmp-admin-prohibited - dostęp zabroniony administracyjnie (użycie tej opcji z jądrem, które jej nie obsługuje jest równoważne z użyciem DROP)

Uwagi

• Pakiety ICMP generowane przez cel REJECT przechodzą w normalny sposób przez Netfilter. Oznacza to w szczególności, że łańcuch OUTPUT musi być tak zdefiniowany, aby umożliwić ich wysłanie

Przykłady

iptables -A INPUT -p tcp --dport 80 -s 192.168.1.12 -j REJECT --reject-with icmp-port-unreachable

Dla IP 192.168.1.12 udajemy, że na porcie 80 nie ma serwera www.

SNAT

Ten cel może zostać użyty tylko w tablicy nat w łańcuchu POSTROUTING. Cel ten kończy przetwarzanie pakietu. Służy do modyfikacji adresu źródłowego pakietu (oraz opcjonalnie portu źródłowego dla TCP i UDP). Dzięki mechanizmowi śledzenia połączeń wszystkie kolejne pakiety tego połączenia podlegać będą tej samej regule SNAT nawet po skasowaniu samej reguły. Odwracanie SNAT w pakietach powracających realizowane jest automatycznie bez dodatkowych reguł iptables. Nazwa SNAT jest angielskim akronimem od Source Network Adress Translation. Parametry tego celu:

--to-source adres1[-adres2][:port1[-port2]] - specyfikuje źródłowy adres IP (lub zakres adresów) oraz ewentualnie źródłowy port (lub zakres portów). Specyfikacja portów źródłowych może zostać podana tylko w regule, w której użyte jest dopasowanie -p udp, lub -p tcp. W przypadku niepodania portów stosowana jest następująca zasada: porty <512 są mapowane na porty <512, porty >=512 i <=1023 będą mapowane na porty <1024, a porty >=1024 będą mapowane na porty >=1024. Tam, gdzie będzie to możliwe nie będzie mapowania portów.

--random - wymusza użycie losowego wyboru mapowanych portów (w jądrach >= 2.6.21).

--persistent - gwarantuje użycie tego samego adresu źródłowego/docelowego dla danego hosta przy kolejnych połączeniach. Opcja ta pozwala zastąpić cel SAME (w jądrach >= 2.6.29-rc2).

Uwagi

• conntrack posiada moduły pomocnicze pozwalające na natowanie połączeń w takich protokołach jak PPTP, SIP, FTP
• Mapowanie NAT w protokołach TCP i UDP jest realizowane na podstawie 4 liczb (ang. touple): src.ip, src.port, dst.ip, dst.port. Oznacza to, że poniższa reguła:

iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 22 -j SNAT --to-source 192.168.1.3:1278

Sprawi, że można będzie się połączyć z dowolną liczbą serwerów SSH na raz, ale tylko jednym połączeniem z danym IP. Spowodowane jest to tym, że dla dwóch połączeń SSH do tego samego serwera touple w pakietach obu połączeń będzie identyczna.

• Za pomocą SNAT można ustawić dowolny (poprawny) adres źródłowy, w szczególności nie musi to być adres przypisany do interfejsu, przez który wychodzi SNATowany ruch. Aby jednak pakiety wróciły musi to być adres IP, którego sieć docelowa jest obsługiwana przez maszynę realizującą SNAT. Dla przykładu jeżeli przez interfejs eth2 wchodzi ruch routowany przez lokalną maszynę do sieci 195.12.34.0/27 to zadziała następująca reguła

iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 195.12.34.10

• SNAT stosujemy tylko w przypadku gdy jest znany adres IP interfejsu, przez który wychodzi ruch lub ruch ten ma wracać innym interfejsem. W przeciwnym przypadku (na przykład adres ten jest dynamiczny - przykład usługa neostrada w TPSA) musimy stosować cel MASQUERADE.

Przykłady

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 80.1.42.7

• Powyższa reguła realizuje NAT umożliwiający komputerom w sieci lokalnej dostęp do Internetu

iptables -t nat -A POSTROUTING -o eth1 -s 192.168.12.0/24 -j SNAT --to-source 80.1.42.7

• Ponieważ w łańcuchu POSTROUTING nie można użyć opcji -i interfejs, aby rozpoznać interfejs wejściowy pakietu można użyć albo adresu źródłowego pakietu, albo użyć znaczników nakładanych np. w łańcuchu PREROUTING

iptables -t nat -A POSTROUTING -o eth1 -p tcp -j SNAT --to-source 80.1.42.7:1024-2048

• Za pomocą SNAT można w prosty sposób ograniczyć wybór portów, przez które będzie wychodził ruch z lokalnej maszyny

TARPIT

Cel ten może zostać użyty tylko w tablicy filter w łańcuchach INPUT i FORWARD, służy do zawieszania przychodzących połączeń TCP. Pułapka (ang. tar pit oznacza jezioro asfaltowe) działa w następujący sposób: po otrzymaniu pakietu TCP SYN wysyłana jest odpowiedź TCP SYN+ACK z ustawionym rozmiarem okna na 0 bajtów. Powoduje to, że druga strona połączenia zamiast rozpocząć transmisję co jakiś czas próbuje wynegocjować powiększenie okna transmisji. W ten sposób zawieszone połączenie zostanie zerwane przez drugą stronę po 12-24 minut (w zależności od konfiguracji protokołu TCP). Dodatkowo jądro nie przechowuje żadnych dodatkowych informacji o tym połączeniu (w celu nie marnowania zasobów).

Uwagi

• Cel TARPIT nie jest domyślnie rozpowszechniany wraz ze źródłami jądra, ani pakietem iptables. Oznacza to, że należy ręcznie dodać odpowiednie patche ze strony [1], lub użyć narzędzia Patch-o-Matic.
• Jeżeli włączony jest mechanizm conntrack należy go wyłączyć dla połączeń, które będą pułapkowane (cel NOTRACK w tablicy raw) inaczej mechanizm conntrack będzie i tak alokował zasoby potrzebne do śledzenia pułapkowanego połączenia.

Przykłady

iptables -A INPUT -p tcp --dport 22 -j TARPIT

• Powyższe polecenie spowoduje pułapkowanie połączeń przychodzących na port ssh. Cel TARPIT przechwytuje połączenia, które zawierają tylko flagę SYN, w przeciwnym wypadku wysyła odpowiedź TCP RST (zgodnie z protokołem TCP). Aby poprawnie dropować ruch w przypadku skanowania portów niepoprawnymi pakietami TCP należy dodatkowo użyć opcji --syn. Zgodnie z poniższym przykładem.

iptables -A INPUT -p tcp --syn --dport 22 -j TARPIT

iptables -t raw -A PREROUTING -d 194.27.25.112 -p tcp --dport 25 -j NOTRACK              # 1
iptables -A FORWARD -d 194.27.25.112 -p tcp --dport 25 --syn -j TARPIT                   # 2

• Linijka (1) powoduje wykluczenie z mechanizmu conntrack pakietów przychodzących na port 25 (SMTP), natomiast linijka (2) je pułapkuje.
• Inną metodą stosowaną do pułapkowania jest przekierowywanie nieużywanych portów/adresów IP na dedykowaną maszynę, która realizuje tylko pułapkowanie.

TCPMSS

Cel ten nie kończy przetwarzania pakietu. Służy do ustawienia pola MSS (ang. Maximum Segment Size) w nagłówku TCP. Pole to występuje tylko w pakiecie SYN lub SYN/ACK, więc tylko wtedy użycie tego celu ma sens. Moduł posiada dwie opcje, wzajemnie się wykluczające:

--set-mss wartość - ustawia zadaną wartość,

--clamp-mss-to-pmtu - automatycznie ustawia wartość MSS wyliczoną na podstawie MTU ścieżki (najmniejszego MTU na trasie od nadawcy do odbiorcy).

Przykłady

iptables -t mangle -A POSTROUTING -o eth1 -p tcp --syn -m tcpmss --mss 1461:9000 -j TCPMSS --set-mss 1460

• Powyższa regułka zmniejsza MSS do akceptowalnej wartości w pakietach z flagą SYN, w których zdalny host (inicjujący połączenie) ustawił pożądaną wielkość segmentu na większą niż 1460 bajtów.

Uwagi

• MSS, choć ściśle związany z MTU, często jest z nim mylony. Zachodzi następująca prawidłowość: MSS + rozmiar nagłówka IP + rozmiar nagłówka TCP ≤ MTU. W praktyce maksymalny rozmiar segmentu danych dla IPv4 jest o 40B mniejszy niż MTU interfejsu. Dla IPv6 różnica ta wynosi 60 bajtów.
• Problemy ze zbyt dużym MSS objawiają się najcześciej tym, że połączenie udaje się nawiązać, gdyż pakiety SYN mają nieduże rozmiary. W momencie wysłania ramki z większą ilością danych pakiet zostaje odrzucony, co objawia się zawieszeniem połączenia.
• Współczesne systemy operacyjne są w stanie automatycznie wykryć maksymalny rozmiar segmentu dla danego połączenia. Negatywny wpływ na działanie tego mechanizmu ma blokowanie protokołu ICMP przez niektórych dostawców, gdyż metoda opiera się na wykrywaniu wielkości pakietu przy którym dowolna ze stacji na drodze od nadawcy do odbiorcy odeśle pakiet ICMP Fragmentation Needed (lub ICMP Packet Too Big dla IPv6)..

TCPOPTSTRIP

Cel ten może zostać użyty tylko w tablicy mangle w dowolnym łańcuchu. Cel ten nie kończy przetwarzania pakietu. Służy do usuwania opcji z pakietów TCP. Usunięte opcje są zastępowane NO-OP (ang. no operation) - pustą opcją

--strip-options opcja[,...] - specyfikuje opcje do usunięcia. Opcje mogą być podane w postaci numerów opcji, lub ich nazw symbolicznych.

Nazwy symboliczne opcji

wscale (3) - skalowanie okna transmisji (ang. window scaling)

mss (2) - maksymalny rozmiar segmentu (ang. Maximum Segment Size)

sack-permitted (4) - zgoda na użycie SACK (ang. Selective ACKnowledgement)

sack (5) - opcja SACK

timestamp (8) - znacznik czasowy

md5 (14) - opcja podpisu MD5

Uwagi

• W niektórych wersjach firmware firmy CISCO znajduje się błąd powodujący zrzucanie pakietów TCP z ustawioną flagą SACK. Objawia się to zrywaniem połączeń w przypadku potrzeby retransmisji (giną wszystkie pakiety informujące o retransmisjach). Aby ominąć ten problem wystarczy usuwać opcję sack-permitted podczas nawiązywania połączeń TCP.

iptables -t mangle -A POSTROUTING -p tcp --syn -j TCPOPTSTRIP --strip-options sack-permitted

TPROXY

Cel ten może zostać użyty tylko w tablicy mangle w łańcuchu PREROUTING (oraz łańcuchach wywoływanych tylko przez ten). Cel ten kończy przetwarzanie pakietu. Służy do dostarczania pakietów do lokalnego gniazda bez modyfikowania nagłówka pakietu. Pozwala również na ustawienie znacznika firewalla w pakiecie (ang. fwmark). Cel ten posiada 3 opcje:

--on-port port - ustawia docelowy port (na lokalnej maszynie), który należy użyć. Ta opcja jest obowiązkowa. 0 oznacza, że port docelowy ma być taki sam, jak ten ustawiony w nagłówku TCP, lub UDP. Opcja ma sens tylko jeżeli użyto dopasowania -p tcp lub -p udp.

on-ip adres - ustawia docelowy adres IP. Domyślnie użyty jest adres IP przyporządkowany do interfejsu, przez który nadszedł pakiet. Opcja ma sens tylko jeżeli użyto dopasowania -p tcp lub -p udp.

--tproxy-mark wartość/maska - ustawia znacznik firewalla zgodnie z podanymi parametrami (patrz opis celu MARK).

Uwagi

• Różnica pomiędzy celem TPROXY a REDIRECT jest taka, że ten ostatni używa NAT do dostarczania pakietu lokalnie - zmieniany jest adres docelowy. Oznacza to, że aplikacja nie zna docelowego adresu IP, na który był kierowany pakiet. Niektóre protokoły warstw wyższych niż 4 można proksować bez tej informacji (np. HTTP zawiera w nagłówku URL), a niektóre można po prostu przechwycić (np. FTP, czy DNS). TPROXY pozwala na przekazywanie do gniazda niezmodyfikowanych pakietów.
• Aby aplikacja potrafiła obsługiwać połączenia przechwytywane przez TPROXY musi być specjalnie do tego przystosowana - musi umieć wysyłać pakiety z nielokalnych adresów IP. W tym celu gniazdo musi mieć włączone flagi SOL_IP i IP_TRANSPARENT. Jedną z aplikacji, które potrafią korzystać z tej funkcjonalności jest Squid w wersjach 3.1.x (ale należy ją włączyć podczas kompilacji).
• Aby wykorzystać cel TPROXY należy dodatkowo skonfigurować routing oparty o politykę (ang. policy routing), a więc ta funkcjonalność musi być wkompilowana w jądrze.

Przykłady

(poniższy przykład został zaczerpnięty z dokumentacji serwera Squid)

iptables -t mangle -N DIVERT					# 1
iptables -t mangle -A DIVERT -j MARK --set-mark 1		# 2
iptables -t mangle -A DIVERT -j ACCEPT				# 3
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT	# 4
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129	# 5
ip rule add fwmark 1 lookup 100				# 6
ip route add local 0.0.0.0/0 dev lo table 100			# 7
echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter			# 8

• Linijki (1-4) tworzą łańcuch DIVERT, w którym chronione są pakiety, które należą do nawiązanych połączeń. Jest to realizowane dzięki temu, że dopasowanie -m socket sprawdza, czy dla danego pakietu da się znaleźć gniazdo, do którego ma być dostarczony.
• Linijka (5) ustawia przechwytywanie pakietów kierowanych na port 80 i wysyłanie ich na lokalny port 3129
• Linijka (6) tworzy politykę routingu mówiącą, że pakiety z ustawionym znacznikiem firewalla 1 mają być obsługiwane przez tablicę routingu o numerze 100
• Linijka (7) tworzy w tablicy routingu o numerze 100 lokalny adres IP 0.0.0.0/0 dla interfejsu lo. Oznacza to, że pakiet o dowolnym adresie docelowym zostanie dostarczony lokalnie przez interfejs lo.
• Linijka (8) wyłącza filtrowanie na podstawie odwrotnej trasy (ang. reverse path) dla interfejsu lo, ponieważ bez tego pakiety przychodzące z dowolnego adresu na interfejs lo byłyby odrzucane, jako nieosiągalne w odwrotnej trasie.

TTL

Ten cel może być użyty tylko w tablicy mangle. Cel ten nie kończy przetwarzania pakietu w łańcuchu. Pozwala on na ustawienie TTL pakietu na daną wartość, lub zmianę wartości TTL o ustaloną liczbę. Cel ten posiada 3 możliwe parametry, z których należy zawsze podać 1:

--ttl-set liczba - ustawia wartość TTL na zadaną liczbę (0-255)

--ttl-dec liczba - obniża TTL o zadaną liczbę (1-225)

--ttl-inc liczba - podnoci TTL o zadaną liczbę (1-225)

Uwaga

Nie należy podnosić TTL pakietów ponieważ w przypadku powstania w sieci pętli, w której podnoszone jest TTL spowoduje to akumulację pakietów, a w konsekwencji przeciążenie łącz (lub urządzeń sieciowych).

Przykłady

iptables -t mangle -t POSTROUTING -d 192.168.1.84 -j TTL --ttl-set 0

Reguła ta sprawi, że adres 192.168.1.84 nie będzie mógł dalej przekazywać otrzymywanych pakietów, ponieważ będzie upuszczał pakiety z TTL równym 0. Host 192.168.1.84 może obejść ten problem podnosząc z powrotem TTL w łańcuchu PREROUTING tablicy mangle, ponieważ TTL jest analizowany w podsystemie routingu.

iptables -t mangle -t POSTROUTING -o eth1 -m ttl --ttl-gt 63 -j TTL --ttl-set 63

Reguła ta sprawi, że pakiety opuszczające interfejs eth0 będą miały TTL mniejsze bądź równe 63 (ponieważ wyższe zostaną obcięte do 63, a mniejsze pozostawione bez zmian).