Nastny Poprzedni Spis Trei

7. Używanie iptables

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:

  1. Stworzenie nowego łañcucha (-N).
  2. Skasowanie pustego łañcucha (-X).
  3. Zmiana polityki dla wbudowanego łañcucha (-P).
  4. Wylistowanie reguł w łañcuchu (-L).
  5. Wyczyszczenie łañcucha z reguł (-F).
  6. Wyzerowanie liczników pakietów i bajtów we wszystkich regułach w łañcuchu (-Z).

Jest również parê sposobów na manipulowanie regułami w obrêbie łañcucha:

  1. Dodanie nowej reguły do łañcucha (-A).
  2. Wstawienie nowej reguły na pewnej pozycji w łañcuchu (-I).
  3. Zamiana reguły na pewnej pozycji w łañcuchu (-R).
  4. Skasowanie reguły na pewnej pozycji w łañcuchu, lub pierwszej która pasuje (-D).

7.1 Co zobaczysz gdy wystartujesz komputer

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.

7.2 Operacje na pojedyñczej regule

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
        #
Składnia polecenia -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.

7.3 Specyfikacja filtrowania

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.

Wskazanie adresów IP: źródłowego i docelowego

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
        #
Ale takich konstrukcji używa siê rzadko, ponieważ efekt jest dokładnie taki sam jak w przypadku nie podania opcji '-s' w ogóle.

Inwersja

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ół

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

Interfejs

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

Fragmenty

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
#

Rozszerzenia do iptables: Nowe cele i nowe testy

iptablesrozszerzalne, 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

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

--tcp-flags

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.

--syn

opcjonalnie poprzedzona przez '!', jest skrótem dla '--tcp-flags SYN,RST,ACK SYN'.

--source-port

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

--sport

to synonim '--source-port'.

--destination-port

i

--dport

mają takie same opcje jak powyżej, ale określają port przeznaczenia.

--tcp-option

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.

Parê słów wyjaśnienia o flagach 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.

Rozszerzenia UDP

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.

Rozszerzenia ICMP

Ładowane automatycznie po podaniu '-p icmp'. Udostêpniają one tylko jedną nową opcjê:

--icmp-type

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 testowe

Inne rozszerzenia w paczce netfiltera są rozszerzeniami demonstracyjnymi, które (jeśli je zainstalowano) mogą byæ wywołane poprzez opcjê '-m'.

mac

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

--mac-source

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

limit

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:

--limit

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

--limit-burst

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

owner (ang. właściciel)

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.

--uid-owner userid

Pasuje dla pakietów stworzonych przez proces ze wskazanym efektywnym (numerycznym) identyfikatorem użytkownika.

--gid-owner groupid

Pasuje dla pakietów stworzonych przez proces ze wskazanym efektywnym (numerycznym) identyfikatorem grupy.

--pid-owner processid

Pasuje dla pakietów stworzonych przez proces ze wskazanym efektywnym (numerycznym) identyfikatorem procesu.

--sid-owner sessionid

Pasuje dla pakietów stworzonych przez proces we wskazanej grupie sesji.

unclean (ang. brudny)

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.

Test Stanu

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

NEW (NOWY)

Pakiet który tworzy nowe połączenie.

ESTABLISHED (NAWIĄZANY)

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

RELATED (POWIĄZANY)

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.

INVALID (BŁÊDNY)

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 

7.4 Cel

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.

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

Rozszerzenia do iptables: Nowe Cele

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:

LOG

Moduł ten zapewnia logowanie w kernelu pasujących pakietów. Udostêpnia nastêpujące opcje:

--log-level

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

--log-prefix

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.

REJECT (ODRZUÆ)

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.

Specjalne cele wbudowane

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
W powyższych regułach, pakiety ICMP generowane lokalnie (tak jak na przykład przy użyciu polecenia ping) przekazywane są do modułu 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
Maksymalna długośæ kolejki (tzn. ilośæ pakietów dostarczonych do przestrzeni użytkownika bez odpowiedzi) może byæ kontrolowana przez:
/proc/sys/net/ipv4/ip_queue_maxlen
Domyślną wartością jest 1024. Kiedy zostaje osiągniêty limit, nowe pakiety bêdą wyrzucane dopóki długośæ kolejki nie spadnie poniżej wartości maksymalnej. Dobre protokoły takie jak TCP interpretują wyrzucane pakiety jako tłok i prawdopodobnie dadzą sobie spokój gdy kolejka siê wypełni. Można oczywiście trochê poeksperymentowaæ by wyznaczyæ idealną maksymalną długośæ kolejki dla określonej sytuacji, jeśli domyślna wartośæ jest zbyt mała.

7.5 Operacje na całym łañcuchu

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.

Tworzenie nowego łañcucha

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

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.

Opróżnianie łañcucha

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.

Listowanie zawartości łañcucha

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.

Resetowanie (zerowanie) liczników

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.

Określanie polityki

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
#


Nastny Poprzedni Spis Trei