iptables ma całkiem szczegółowy podrêcznik (man iptables),
do którego warto zajrzeæ jeśli chodzi ci o coś konkretnego. Ci z was którzy
znają ipchains mogą po prostu zajrzeæ do
różnic pomiêdzy iptables i ipchains; oba narzêdzia są bardzo
podobne.
Istnieje wiele rzeczy które możesz zrobiæ przy użyciu iptables.
Zaczynasz z trzema wbudowanymi łañcuchami INPUT, OUTPUT i
FORWARD, których nie możesz skasowaæ. Spójrzmy na listê możliwych
operacji na całych łañcuchach:
Jest również parê sposobów na manipulowanie regułami w obrêbie łañcucha:
iptables może byæ modułem, ('iptable_filter.o'), który powinien
byæ automatycznie ładowany gdy po raz pierwszy uruchomisz iptables.
Może byæ również skompilowany w kernelu.
Zanim nie zostaną wykonane jakieś komendy (zwróæ uwagê, że niektóre
dystrybucje wykonują już operacje z iptables w skryptach
startowych) nie ma żadnych reguł we wbudowanych łañcuchach
('INPUT', 'FORWARD' i 'OUTPUT') i wszystkie mają domyślną
politykê ACCEPT. Możesz zmieniæ domyślną politykê łañcucha
FORWARD przez podanie opcji 'forward=0' do modułu
iptable_filter.
Manipulowanie regułami to bułka z masłem filtrowania pakietów.
Najczêściej bêdziesz zapewne dodawał (-A) i kasował (-D).
Inne komendy (-I dla wstawiania i -R do
zamieniania) są prostymi rozwiniêciami tych koncepcji.
Każda reguła jest zestawem warunków które pakiet musi spełniæ i zawiera informacjê co zrobiæ jeśli tak siê stało (czyli cel, ang. target). Na przykład, możesz chcieæ odrzucaæ wszystkie pakiety ICMP nadchodzące z adresu IP 127.0.0.1. W tym przypadku naszymi warunkami są zatem: protokołem musi byæ ICMP, a adresem źródłowym 127.0.0.1. Naszym celem bêdzie 'DROP'.
127.0.0.1 to adres pêtli zwrotnej (ang. loopback), który posiadasz nawet wtedy gdy nie masz żadnego połączenia sieciowego. Możesz użyæ programu 'ping' by wygenerowaæ pakiety takie jak powyżej. Polecenie wysyła pakiety ICMP typ 8 - żądanie echa (ang. echo request) na które wszystkie współpracujące hosty odpowiedzą pakietem ICMP typu 0 - echo. To sprawia, że polecenie to jest wygodne dla testów.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#
Widaæ powyżej że pierwszy ping dociera (opcje '-c 1'
powoduje wysłanie tylko jednego pakietu).
Dodajemy teraz (-A) do łañcucha 'INPUT' regułê, która mówi
że pakiety z 127.0.0.1 ('-s 127.0.0.1') protokołu ICMP
('-p icmp') powinny zostaæ przeznaczone do wyrzucenia
('-j DROP').
Testujemy nastêpnie działanie naszej reguły, wykonując drugi ping. Nastąpi pauza po której program siê podda, po krótkim oczekiwaniu na odpowiedź która nigdy nie nadejdzie.
Możemy skasowaæ naszą regułê na dwa sposoby. Po pierwsze, ponieważ wiemy że jest to jedyna reguła w łañcuchu wejściowym, możemy użyæ numerowania reguł, tak jak poniżej:
# iptables -D INPUT 1
#
Co spowoduje skasowanie reguły numer 1 w łañcuchu INPUT.
Drugi sposób to dokładne przepisanie poleceñ po opcji -A, ale
zamiast opcji -A podajemy opcjê -D. Przydaje siê to w
przypadku gdy masz skomplikowany zestaw reguł i nie chce ci siê liczyæ
ich wszystkich by ustaliæ w koñcu że chcesz pozbyæ siê reguły numer 37.
W tym wypadku użyjemy:
# iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP
#
-D musi dokładnie odpowiadaæ opcjom
które podałeś przy poleceniu -A (lub -I czy -R).
Jeśli istnieje wiele identycznych reguł w tym samym łañcuchu,
tylko pierwsza pasująca zostania skasowana.
Widzieliśmy już jak używaæ opcji '-p' by wskazaæ protokół
i '-s' by wskazaæ adres źródłowy, ale są jeszcze inne opcje
których możemy użyæ by scharakteryzowaæ pakiet. Poniżej znajdziesz
wyczerpujące kompendium.
Adres IP źródłowy ('-s', '--source' lub '--src')
i docelowy ('-d', '--destination' lub '--dst')
mogą byæ podane na cztery sposoby. Najczêściej robi siê to przez podanie
pełnej nazwy, takiej jak 'localhost' czy `www.linuxhq.com'. Drugim sposobem
jest podanie adresu IP, tak jak np. '127.0.0.1'.
Trzeci i czwarty sposób pozwalają na wskazanie grupy adresów IP, tak jak na przykład '199.95.207.0/24' lub `199.95.207.0/255.255.255.0'. Oba wskazują na zakres adresów IP od 199.95.207.0 do 199.95.207.255 włącznie; cyfry po '/' mówią która czêśæ adresu IP ma znaczenie. '/32' czy inaczej `/255.255.255.255' jest domyślne (i mówi że wszystkie liczby w adresie IP są ważne). By wskazaæ dowolny adres, można użyæ '/0' tak jak poniżej:
[ UWAGA: `-s 0/0' jest tu całkowicie zbêdne. ]
# iptables -A INPUT -s 0/0 -j DROP
#
-s' w ogóle.
Wiele flag, włączając '-s' (lub '--source') i
'-d' ('--destination') można poprzedziæ znakiem '!'
(wymawianym 'nie') by wskazaæ adresy nie pasujące do tych podanych.
Na przykład '-s ! localhost' bêdzie
pasowaæ do wszystkich pakietów nie pochodzących z localhost.
Protokół podaje siê po parametrze '-p' (lub '--protocol').
Protokół może byæ numerem (jeśli znasz wartości numeryczne protokołów IP) lub
nazwą dla 'TCP', 'UDP' i 'ICMP'. Wielkośæ liter nie ma znaczenia,
wiêc 'tcp' działa tak samo jak 'TCP'.
Nazwa protokołu może byæ poprzedzona przez znak '!' by
wskazaæ na wszystkie oprócz wymienionego, tak jak na przykład
'-p ! TCP' (warunek dotyczy wszystkich protokołów prócz TCP).
Opcje '-i' (lub '--in-interface' czyli interfejs
wejściowy) i '-o' (lub '--out-interface' czyli interfejs
wyjściowy) używane są dla wskazania interfejsu. Interfejs to
fizyczne urządzenie do którego pakiety przychodzą ('-i') i
z którego są wysyłane ('-o'). Możesz użyæ programu
ifconfig by wylistowaæ interfejsy które są 'podniesione'
(tzn. aktualnie pracujące).
Pakiety podróżujące w łañcuchu INPUT nie mają interfejsu
wyjściowego, wiêc podanie opcji '-o' w regule w tym łañcuchu
spowoduje że nie bêdzie ona pasowaæ do żadnego pakietu. Podobnie,
pakiety podróżujące przez łañcuch OUTPUT nie mają interfejsu
wejściowego, wiêc podanie opcji '-i' w regule tego
łañcucha spowoduje że nie bêdzie ona nigdy pasowała.
Tylko pakiety podróżujące przez łañcuch FORWARD mają
zarówno interfejs wejściowy i wyjściowy.
Jest całkowicie poprawne wskazanie interfejsu który aktualnie
nie istnieje; reguła nie bêdzie pasowała do niczego, dopóki
interfejs nie zostanie podniesiony. Jest to bardzo przydatne
dla połączeñ wdzwanianych PPP (zwykle interfejs ma nazwê
ppp0) i podobnych.
Można również wskazaæ interfejs koñcząc jego nazwê przez '+'
co spowoduje że reguła bêdzie pasowała do wszystkich interfejsów których
nazwa zaczyna siê od podanego ciągu znaków (bez znaczenia czy interfejs
aktualnie istnieje czy nie). Na przykład, by wskazaæ regułê która pasuje
do wszystkich interfejsów PPP użyæ należy polecenia '-i ppp+'.
Interfejs może byæ poprzedzony przez '!' ze spacjami wokół,
co spowoduje że pasowaæ bêdą pakiety które nie są powiązane ze
wskazanym interfejsem (tzn. pakiet nim nie dotarł do systemu, lub
nie zamierza nim go opuściæ), np. -i ! ppp+.
Czasami pakiet jest zbyt duży by zmieściæ siê cały w jednostce transmisji. Kiedy siê tak dzieje, jest on dzielony na fragmenty i wysyłany jako osobne pakiety. Komputer docelowy składa fragmenty by zrekonstrukowaæ cały pakiet.
Problem z fragmentami polega na tym, że pierwszy fragment posiada komplet pól nagłówka (IP+TCP, UDP i ICMP) który można sprawdzaæ, ale nastêpne fragmenty mają tylko podzbiór nagłówków (IP bez dodatkowych pól specyficznych dla protokołów które przenosi pakiet). W związku z tym niemożliwe jest analizowanie pewnych informacji z nagłówków fragmentów (tak jak robi siê to dla typowych pakietów TCP, UDP i ICMP).
Jeśli prowadzisz śledzenie połączeñ lub NAT, to wszystkie fragmenty zostaną najpierw złożone a dopiero później przekazane do kodu filtrującego pakiety, wiêc nie powinieneś siê martwiæ fragmentami.
W każdym innym przypadku ważne jest by zrozumieæ jak fragmenty
traktowane są przez reguły filtrujące. Każda reguła która ma
sprawdziæ informacje których nie posiadamy dla danego pakietu, nie
bêdzie pasowała. Oznacza to, że tylko pierwszy fragment
traktowany jest tak, jak można by siê tego spodziewaæ. Drugi pakiet
i kolejne już nie bêdą. W związku z tym reguła '-p TCP --sport www'
(podająca port źródłowy 'www') nigdy nie bêdzie pasowała
do fragmentu pakietu (innego niż pierwszy). Nie bêdzie również
pasowaæ reguła odwrotna '-p TCP --sport ! www'.
Możesz jednak dodaæ reguły specjalnie dla drugiego i nastêpnych
fragmentów, poprzez użycie opcji '-f' (lub '--fragment').
Poprawne jest również dodanie reguły która nie pasuje do drugiego i
nastêpnych fragmentów, przez poprzedzenie opcji '-f'
opcją '!'.
Zwykle uważa siê za bezpieczne umożliwienie drugiemu i nastêpnym fragmentom przejśæ, ponieważ filtrowanie zajmie siê pierwszym fragmentem i w związku z tym zapobiegnie złożeniu pakietu na maszynie docelowej; z drugiej strony znane były pluskwy które powodowały zawieszanie siê maszyn tylko poprzez wysyłanie do nich fragmentów. To twoja decyzja.
Mała uwaga do speców od sieci: pakiety zniekształcone (TCP, UDP i ICMP które są zbyt krótkie by kod ściany ogniowej mógł odczytaæ porty, czy w przypadku ICMP kod i typ) są również wyrzucane gdy prowadzone są takie analizy. Dokładnie tak samo jest z fragmentami TCP które rozpoczynają siê od pozycji 8.
Jako przykład, poniższa reguła wyrzuci wszystkie fragmenty przeznaczone dla 192.168.1.1:
# iptables -A OUTPUT -f -d 192.168.1.1 -j DROP
#
iptables są rozszerzalne, co oznacza że
funkcjonalnośæ zarówno kernela jak i narzêdzia iptables może byæ
rozszerzana by dodaæ nowe opcje.
Niektóre rozszerzenia są standardowe, inne są trochê bardziej egzotyczne. Oczywiście, mogą byæ one dodawane przez innych ludzi i dystrybuowane niezależnie dla użytkowników niszowych.
Fizycznie rozszerzenia znajdują siê zwykle w podkatalogu modułów
kernela, tak jak na przykład
'/lib/modules/2.4.0-test10/kernel/net/ipv4/netfilter'.
Ladowane są na żądanie gdy kernel został skompilowany z opcją
CONFIG_KMOD, wiêc nie powinno byæ potrzeby ładowania ich rêcznie.
Rozszerzenia do narzêdzia iptables są współdzielonymi
bibliotekami, które znajdują siê zwykle w '/usr/local/lib/iptables/',
choæ dystrybucje mogą umieściæ je w katalogach takich jak
'/lib/iptables/' czy '/usr/lib/iptables'.
Rozszerzenia mogą należeæ do jednego z dwóch typów: nowych celów, lub nowych testów (porozmawiamy o nowych celach za moment). Niektóre protokoły oferują automatycznie nowe testy: aktualnie są nimi TCP, UDP i ICMP tak jak pokażemy to poniżej.
Możesz dla nich podaæ nowe testy w linii poleceñ po opcji
'-p', który ładuje rozszerzenie. Dla samodzielnych
nowych testów, używa siê opcji '-m' by załadowaæ
rozszerzenie, po której dostêpne są nowe opcje.
By uzyskaæ pomoc do rozszerzenia, użyj opcji ładującej go
('-p', '-j' lub '-m') po której podaj
'-h' lub '--help', np.:
# iptables -p tcp --help
#
Rozszerzenia TCP ładowane są automatycznie gdy podano opcjê
'-p tcp'. Dodają one nastêpujące opcje (z których
żadna nie pasuje do fragmentów).
Po której nastêpuje opcjonalny znak '!',
a nastêpnie dwa ciągi flag które pozwalają wskazaæ zestaw
flag do zbadania. Drugi ciąg mówi, które mają byæ ustawione.
Na przykład:
# iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DROP
mówi że sprawdzone powinny zostaæ wszystkie flagi ('ALL'
to synonim dla 'SYN,ACK,FIN,RST,URG,PSH'), ale tylko
flagi SYN i ACK powinny byæ ustawione. Istnieje
również argument 'NONE' który oznacza że żadna flaga
nie może byæ ustawiona.
opcjonalnie poprzedzona przez '!', jest
skrótem dla '--tcp-flags SYN,RST,ACK SYN'.
po której nastêpuje opcjonalny '!',
a nastêpnie pojedyñczy port lub grupa portów TCP. Porty mogą byæ
wskazywane przez nazwy takie jak w /etc/services lub przez
numery. Grupy portów wskazuje siê albo przez dwie nazwy portów
podzielone przez ':', lub (by wskazaæ wiêksze lub równe
wskazanemu) przez port z dodanym ':', lub (by wskazaæ
mniejsze lub równe wskazanemu), port poprzedzany przez ':'.
to synonim '--source-port'.
i
mają takie same opcje jak powyżej, ale określają port przeznaczenia.
po którym nastêpuje opcjonalny znak
! i numer, które wskazują na opcjê TCP równą wskazanemu
numerowi. Pakiet który nie posiada kompletnego nagłówka TCP
jest automatycznie odrzucany jeśli wykonana zostanie próba
sprawdzenia jego opcji TCP.
Czasami użyteczne jest, by zezwoliæ na połączenia TCP w jednym kierunku ale nie w drugim. Na przykład, możesz chcieæ zezwoliæ na połączenia do zewnêtrznego serwera WWW, ale nie połączenia od tego serwera.
Naiwnym rozwiązaniem byłoby blokowanie pakietów TCP nadchodzących z tego serwera. Niestety, połączenia TCP wymagają by pakiety mogły poruszaæ siê w jedną i w drugą stronê.
Rozwiązaniem jest blokowanie tylko pakietów używanych do nawiązania połączenia. Nazywa siê je pakietami SYN (dobrze, technicznie rzecz biorąc są to pakiety z ustawioną flagą SYN i zgaszonymi flagami RST i ACK, ale nazywamy je pakietami SYN by było krócej). Poprzez zabronienie ruchu tylko tym pakietom, możemy zapobiec takim połączeniom u samego ich źródła.
Używa siê do tego opcji '--syn': która jest dozwolona
tylko dla reguł które wskazują na protokół TCP. Na przykład,
by wskazaæ połączenia TCP z 192.168.1.1:
-p TCP -s 192.168.1.1 --syn
Działnie flagi można odwróciæ poprzedzając ją '!',
co oznacza, że chodzi nam o pakiety różne od tych które
inicjują połączenie.
Są one ładowane automatycznie po podaniu '-p udp'.
Udostêpniają opcjê '--source-port', '--sport',
'--destination-port' i '--dport', dokładnie
takie same jak dla TCP powyżej.
Ładowane automatycznie po podaniu '-p icmp'.
Udostêpniają one tylko jedną nową opcjê:
po której nastêpuje opcjonalny znak '!',
a nastêpnie albo nazwa typu pakietu ICMP (np. 'host-unreachable', czyli
komputer nieosiągalny), lub numer typu (np. '3'), lub numer
typu i kod oddzielone przez '/' (np. '3/3'). Lista dostêpnych
nazw typów ICMP dostêpna jest po podaniu '-p icmp --help'.
Inne rozszerzenia w paczce netfiltera są rozszerzeniami
demonstracyjnymi, które (jeśli je zainstalowano) mogą byæ
wywołane poprzez opcjê '-m'.
Moduł ten musi byæ wskazany przez '-m mac' lub
'--match mac'. Używa siê go do sprawdzania źródła
Ethernetowego (tzw. adresu MAC) adresu nadchodzącego pakietu i w
związku z tym działa tylko w łañcuchach PREROUTING i INPUT.
Udostêpnia on tylko jedną opcjê:
po którym nastêpuje opcjonalny
'!' a nastêpnie adres ethernetowy w formacie
heksdecymalnym oddzielanym dwukropkami, np.
`--mac-source 00:60:08:91:CC:B7'.
Moduł ten musi byæ wskazany przez '-m limit'
lub '--match limit'. Używa siê go do ograniczania czêstotliwości
pasowania reguły, tak jak na przykład do ograniczanie wiadomości generowanych
do logów. Spowoduje że pakiety bêdą pasowaæ z taką czêstotliwością jak
podana w tej opcji w czasie jeden sekundy (domyślnie 3 krotnie na godzinê,
z serią 5). Moduł umożliwia podanie dwóch argumentów opcjonalnych:
po którym nastêpuje numer; określa maksymalny
średni numer testów pozytywnych na sekundê. Numer może również
wskazywaæ wprost jednostki, przez użycie '/second',
'/minute', '/hour' lub '/day', albo
ich skrótów (np. '5/second' to to samo co '5/s').
po którym nastêpuje numer, określający maksymalną seriê po której powyższy limit siê włącza.
Używa siê tego testu zwykle w połączeniu z celem LOG by zrealizowaæ ograniczone logowanie. By zrozumieæ jak to działa, popatrzmy jak działa nastêpująca reguła, która loguje pakiety z domyślnymi limitami:
# iptables -A FORWARD -m limit -j LOG
Gdy pierwszy raz dochodzimy do reguły, pakiet jest logowany; tak naprawdê, ponieważ domyślną serią jest 5, pierwsze piêæ pakietów zostanie zalogowane. Nastêpnie, minie dwadzieścia minut zanim zalogowany zostanie nastêpny pakiet pasujący do tej reguły, niezależnie od tego ile pakietów do niej dotrze. Jednocześnie, każde dwadzieścia minut które minie bez pakietu który pasowałby do tej reguły, spowoduje odnowienie jednego numeru z serii; jeśli żaden pakiet nie dotrze do reguły w ciągu 100 minut, seria zostanie w pełni odnowiona; do 5 sztuk, tak jak zaczêliśmy.
Nota: nie możesz aktualnie stworzyæ reguły które ma czas odnawiania siê powyżej 59 godzin, wiêc jeśli ustawisz średnią czêstotliwośæ na jeden pakiet na dzieñ, numer serii musi byæ mniejszy niż 3.
Możesz również użyæ tego modułu by zapobiec rozmaitym atakom Odmowy Usługi (ang. Denial of Service), z wiêkszym współczynnikiem czêstotliwości by zwiêkszyæ szybkośæ reakcji.
Zabezpieczenie przed powodzią pakietów SYN (ang. Syn-flood):
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
Skaner portół Furtive:
# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Ping of death:
# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
Moduł ten działa jak "drzwi histerii", tak jak pokazano to na diagramie poniżej.
rate (pkt/s)
^ .---.
| / DoS \
| / \
Edge of DoS -|.....:.........\.......................
= (limit * | /: \
limit-burst) | / : \ .-.
| / : \ / \
| / : \ / \
End of DoS -|/....:..............:.../.......\..../.
= limit | : :`-' `--'
-------------+-----+--------------+------------------> time (s)
LOGIC => Match | Didn't Match | Match
Powiedzmy że pasuje jeden pakiet na sekundê z serią piêciu pakietów, ale pakiety zaczynają dochodziæ w ilości czterech na sekundê przez trzy sekundy, a nastêpnie znowu po trzech sekundach.
<--Flood 1--> <---Flood 2--->
Total ^ Line __-- YNNN
Packets| Rate __-- YNNN
| mum __-- YNNN
10 | Maxi __-- Y
| __-- Y
| __-- Y
| __-- YNNN
|- YNNN
5 | Y
| Y Key: Y -> Matched Rule
| Y N -> Didn't Match Rule
| Y
|Y
0 +--------------------------------------------------> Time (seconds)
0 1 2 3 4 5 6 7 8 9 10 11 12
Widaæ, że pierwsze piêæ pakietów przekracza limit jednego pakietu na sekundê, a nastêpnie włącza siê ograniczanie (limit). Jeśli nastąpi pauza, kolejna seria zostanie wpuszczona ale nie powyżej maksymalnej czêstotliwości określonej przez regułê (1 pakiet na sekundê po tym jak dotarła seria).
Ten moduł stara siê ustaliæ pewne charakterystyki twórcy pakietu, dla pakietów generowanych lokalnie. Jego użycie jest możliwe tylko w łañcuchu OUTPUT, a nawet nie dla wszystkich pakietów (takich jak odpowiedzi na ICMP ping) które mogą nie mieæ właściciela, a w związku z tym nie bêdą pasowały.
Pasuje dla pakietów stworzonych przez proces ze wskazanym efektywnym (numerycznym) identyfikatorem użytkownika.
Pasuje dla pakietów stworzonych przez proces ze wskazanym efektywnym (numerycznym) identyfikatorem grupy.
Pasuje dla pakietów stworzonych przez proces ze wskazanym efektywnym (numerycznym) identyfikatorem procesu.
Pasuje dla pakietów stworzonych przez proces we wskazanej grupie sesji.
Jest to eksperymentalny moduł którego
używa siê przez podanie '-m unclean' lub '--match unclean'.
Wykonuje różne losowe testy sprawdzające na pakiecie. Moduł ten nie
był sprawdzany i nie powinien byæ używany jako test związany z
bezpieczeñstwem (prawdopodobnie sprawia że wszystko wygląda jeszcze
gorzej, ponieważ sam może mieæ pluskwy). Nie udostêpnia żadnych opcji.
Najbardziej użytecznym testem jest ten dostarczany przez rozszerzenie
'state', który interpretuje analizê śledzenia połączeñ modułu
'ip_conntrack'. Generalnie bardzo zaleca siê jego
wykorzystanie.
Podanie w regule opcji '-m state' udostêpnia dodatkową
opcjê '--state', która jest listą oddzielonych stanów do
przetestowania (opcja '!' wskazuje na pakiety nie pasujące
do wskazanych stanów). Stanami które można sprawdzaæ są:
Pakiet który tworzy nowe połączenie.
Pakiet który należy do istniejącego połączenia (np. pakiet odpowiedzi, lub pakiet wychodzący w połączeniu które otrzymało już odpowiedzi).
Pakiet który jest powiązany z istniejącym połączeniem, ale nie jest jego czêścią, tj. np pakiet z błêdem ICMP, lub (jeśli załadowany jest moduł FTP) pakiet ustanawiający połączenie ftp dla danych.
Pakiet który nie może byæ zidentyfikowany z jakiś powodów: mogą to byæ wyczerpanie siê pamiêci, lub błêdy ICMP które nie należą do żadnego znanego połączenia. Generalnie, pakiety tego typu powinno siê odrzucaæ.
Przykładem wykorzystania tego potêżnego rozszerzenia mogłoby byæ:
# iptables -A FORWARD -i ppp0 -m state ! --state NEW -j DROP
Znamy już testy które możemy przeprowadziæ na pakiecie, potrzebujemy zatem sposobu by wskazaæ co robiæ z pakietami które pasują do naszych testów. Nazywa siê to celem (ang. target) reguły.
Są dwa proste wbudowane cele : DROP (wyrzuciæ) i ACCEPT (zaakceptowaæ). Już je widzieliśmy. Jeśli reguła pasuje do pakietu a jej cel jest jednym z tych dwóch, nie analizuje siê już innych reguł: los pakietu został już określony.
Istnieją jeszcze dwa inne typy celów: rozszerzenia i łañcuchy zdefiniowane przez użytkownika.
Bardzo potêżną własnością którą iptables dziedziczy z
ipchains jest możliwośæ tworzenia przez użytkownika nowych
łañcuchów, oprócz wbudowanych (INPUT, FORWARD i OUTPUT).
Zgodnie z przyjêtą konwencją, wszystkie łañcuchy generowane przez
użytkownika pisane są małymi literami by odróżniæ je od wbudowanych
(opiszemy jak tworzyæ nowe łañcuchy użytkownika poniżej,
w sekcji
Operacje na całym łañcuchu).
Kiedy do reguły dociera pakiet który pasuje, a cel tej reguły zdefiniowany jest jako łañcuch zdefiniowany przez użytkownika, rozpoczyna on testy w tym właśnie łañcuchu. Jeśli w obrêbie tego łañcucha los pakietu nie zostanie zdecydowany, przemierzanie reguł rozpoczyna siê w pierwotnym łañcuchu, w miejscu w którym zostało przerwane (dokładnie od nastêpnej reguły).
Czas na trochê rysunków ASCII. Rozważmy dwa (śmiesznie proste)
łañcuchy: INPUT (łañcuch wbudowany) i test
(łañcuch zdefiniowany przez użytkownika).
`INPUT' `test'
---------------------------- ----------------------------
| Rule1: -p ICMP -j DROP | | Rule1: -s 192.168.1.1 |
|--------------------------| |--------------------------|
| Rule2: -p TCP -j test | | Rule2: -d 192.168.1.1 |
|--------------------------| ----------------------------
| Rule3: -p UDP -j DROP |
----------------------------
Rozważmy pakiet TCP nadchodzący z 192.168.1.1 i wysłany do 1.2.3.4.
Wchodzi on do łañcucha INPUT i rozpoczyna siê sprawdzanie.
Reguła 1 (Rule1) nie pasuje, natomiast druga tak. Ponieważ cel zdefiniowany
jest jako 'test', nastêpna reguła która jest sprawdzana pochodzi
z łañcucha 'test'. Pierwsza reguła w tym łañcuchu pasuje ale nie
podaje celu, wiêc sprawdzana jest nastêpna reguła. Ona nie pasuje i
osiągany jest koniec łañcucha 'test'. Wracamy do łañcucha
INPUT, w którym ostatnio sprawdzaliśmy regułê drugą, teraz wiêc
sprawdzamy trzecią która również nie pasuje.
Zatem droga pakietu wygląda w sposób nastêpujący:
v __________________________
`INPUT' | / `test' v
------------------------|--/ -----------------------|----
| Rule1 | /| | Rule1 | |
|-----------------------|/-| |----------------------|---|
| Rule2 / | | Rule2 | |
|--------------------------| -----------------------v----
| Rule3 /--+___________________________/
------------------------|---
v
Łañcuchy zdefiniowane przez użytkownika mogą jako cel wskazywaæ inne łañcuchy również zdefiniowane przez użytkownika (ale nie mogą tworzyæ pêtli: twój pakiet zostanie wyrzucony jeśli okaże siê że jest sprawdzany w pêtli).
Innym typem rozszerzenia jest cel. Cel składa siê z modułu
kernela i opcjonalnych rozszerzeñ iptables, które zapewniają
opcje dla linii poleceñ. Jest kilka takich rozszerzeñ w standardowej
dystrybucji netfilter:
Moduł ten zapewnia logowanie w kernelu pasujących pakietów. Udostêpnia nastêpujące opcje:
Po którym nastêpuje nazwa poziomu logowania
lub odpowiednik numeryczny. Prawidłowymi nazwami są (wielkośæ
liter nie jest ważna) 'debug', 'info', 'notice',
'warning', 'err', 'crit',
'alert' i 'emerg', którym odpowiadają cyfry
od 7 do 0. Sprawdź stronê podrêcznika syslog.conf
by dowiedzieæ siê co oznaczają poszczególne poziomy. Domyślnym jest
`warning`.
po którym nastêpuje ciąg do 29 znaków, który dodawany jest do logowanej informacji by umożliwiæ jej jednoznaczną identyfikacjê.
Moduł ten używany jest najczêściej z testem limit, dziêki czemu nie zaśmiecasz sobie logów.
Moduł ten ma takie samo działanie jak 'DROP', poza tym że to nadawcy pakietu odsyłany jest pakiet ICMP 'port unreachable'. Weź jednak pod uwagê fakt, że błąd ICMP nie zostanie odesłany jeśli (sprawdź RFC 1122):
Do REJECT można również dodaæ opcjonalny argument '--reject-with'
który pozwala na zadeklarowanie jaki dokładnie pakiet ICMP ma zostaæ
odesłany zamiast domyślnego 'port unreachable'. Sprawdź
stronê podrêcznika.
Są dwa wbudowane specjalne cele: RETURN (POWRÓT) i
QUEUE (KOLEJKA).
RETURN ma dokładnie ten sam efekt jak zakoñczenie sprawdzania
łañcucha: dla reguły w łañcuchu wbudowanym sprawdzana jest wtedy polityka.
Dla reguły w zdefiniowanym przez użytkownika łañcuchu, oznacza to
powrót do poprzedniego łañcucha, zaraz po regule która spowodowała skok
do tego łañcucha.
QUEUE to cel który kolejkuje pakiety dla przetwarzania w
przestrzeni użytkownika. Żeby można było ten cel zastosowaæ, potrzebne
są jeszcze dwa składniki:
Standardowym programem obsługującym kolejki dla IPv4 jest w iptables
moduł ip_queue, który dystrybuowany jest z kernelem i
oznaczony jako eksperymentalny.
Poniżej przedstawiono krótki przykład jak użyæ iptables z kolejką pakietów do przetwarzania w przestrzeni użytkownika:
# modprobe iptable_filter
# modprobe ip_queue
# iptables -A OUTPUT -p icmp -j QUEUE
ip_queue, który stara siê dostarczyæ pakiety do aplikacji
działającej w przestrzeni użytkownika. Jeśli nie ma takiej
aplikacji, pakiety są wyrzucane.
By napisaæ taką aplikacjê, należy użyæ API libipq. Dystrybuowana
jest ona razem z iptables. Kod przykładowy znajduje siê w narzêdziach
testsuite (np. redirect.c) z CVS.
Status modułu ip_queue może byæ sprawdzony przez wywołanie:
/proc/net/ip_queue
/proc/sys/net/ipv4/ip_queue_maxlen
Bardzo przydatną opcją w iptables jest możliwośæ grupowania
reguł w łañcuchy. Możesz je nazwaæ jak chcesz, ale zalecam raczej używanie
małych liter by nie pomyliæ ich z wbudowanymi łañcuchami i celami.
Nazwy ograniczone są do 31 liter.
Stwórzmy nowy łañcuch. Ponieważ jestem kolesiem z wyobraźnią,
nazwijmy go 'test'. Możemy użyæ albo '-N' albo
'--new-chain':
# iptables -N test
#
Proste. Możesz teraz dodaæ do niego swoje reguły tak jak to już opisano.
Kasowanie łañcucha również jest proste, używa siê do tego opcji
'-X' lub '--delete-chain'. A dlaczego '-X'?
Cóż, wszystkie dobre literki były już zajête.
# iptables -X test
#
Jest jednak parê ograniczeñ dotyczących kasowania łañcuchów: muszą byæ puste (sprawdź sekcjê Opróżnianie łañcucha poniżej) i nie mogą byæ wskazywane jako cel w innej regule. Nie możesz również skasowaæ żadnego z trech wbudowanych łañcuchów.
Jeśli nie podasz nazwy łañcucha, skasowane zostaną w miarê możliwości wszystkie łañcuchy zdefiniowane przez użytkownika.
Istnieje oczywiście również sposób by wykasowaæ wszystkie reguły
z łañcucha. Używa siê do tego opcji '-F' (lub '--flush').
# iptables -F FORWARD
#
Jeśli nie wskażesz konkretnego łañcucha, opróżnione zostaną wszystkie.
Możesz wylistowaæ reguły w łañcuchu, używając opcji '-L'
(lub '--list').
Pozycja 'refcnt' przy każdym łañcuchu zdefiniowanym
przez użytkownika podaje numer reguł które odwołują siê do tego
łañcucha. Wartośæ ta musi byæ równa zero (a łañcuch musi byæ pusty),
by taki łañcuch można było skasowaæ.
Jeśli pominiêto nazwê łañcucha, wylistowane zostaną wszystkie łañcuchy, nawet te puste.
Istnieją trzy opcje które mogą towarzyszyæ opcji '-L'.
Opcja '-n' (numerycznie) jest o tyle przydatna, że
zapobiega sprawdzaniu nazw odpowiadającym adresom IP przez iptables,
co może spowodowaæ duże zwłoki jeśli twój DNS (a zakładamy że
używasz DNS jak wiêkszośæ ludzi) nie jest prawidłowo skonfigurowany,
lub odfiltrowałeś zapytania DNS. Powoduje ona również podanie portów
TCP i UDP numerycznie zamiast nazw.
Opcja '-v' pokazuje wszystkie detale reguł, takie jak
liczniki pakietów i bajtów, porównania TOS (Typu Usługi, ang.
Type of Service) i interfejsy. Bez tej opcji wszystkie
te informacje zostaną pominiête.
Zwróæ uwagê że liczniki pakietów i bajtów drukowane są przy
użyciu suffiksów 'K', 'M' lub 'G', dla odpowiednio 1000, 1,000,000
i 1,000,000,000. Poprzez użycie opcji '-x' (rozwiñ liczby)
można uzyskaæ pełne liczby, bez wzglêdu na to jak są duże.
Czasami przydatne jest móc wyzerowaæ liczniki. Wykonuje siê to przez
użycie opcji '-Z' (lub '--zero').
Rozważ poniższy przykład:
# iptables -L FORWARD
# iptables -Z FORWARD
#
Pewna liczba pakietów mogłaby przejśæ pomiêdzy wydaniem polecenia z opcją
'-L' a '-Z'. W związku z tym, możesz tych opcji używaæ
razem, by wyzerowaæ liczniki dokładnie w momencie ich wyświetlenia.
Wspomnieliśmy już co dzieje siê gdy pakiet dociera do koñca
wbudowanego łañcucha, kiedy rozmawialiśmy o tym jak pakiet podróżuje przez
łañcuchy. W tym przypadku o losie pakietu decyduje polityka dla
łañcucha. Tylko wbudowane łañcuchy (INPUT, OUTPUT
i FORWARD) mają przypisaną politykê, ponieważ jeśli pakiet
dociera do koñca łañcucha zdefiniowanego przez użytkownika, sprawdzanie
wraca do poprzedniego łañcucha.
Polityką może byæ ACCEPT lub DROP, na przykład:
# iptables -P FORWARD DROP
#