To jest proponowane pytanie kanoniczne dotyczące zrozumienia i debugowania zapory programowej w systemach Linux.

W odpowiedzi na odpowiedź EEAA i komentarz @ Shog, że potrzebujemy odpowiedniego kanonicznego pytania i odpowiedzi, aby zamknąć typowe stosunkowo proste pytania dotyczące iptables.

Jaka jest strukturalna metoda debugowania problemów z zaporą programową dla systemu Linux, strukturą filtrowania pakietów netfilter , o której często mówi interfejs użytkownika iptables ?

Jakie są typowe pułapki, powtarzające się pytania i proste lub nieco bardziej niejasne rzeczy, aby sprawdzić, czy administrator zapory sieciowej może przeoczyć lub w inny sposób skorzystać z wiedzy?

Nawet jeśli używasz narzędzi takich jak UFW , FirewallD (alias firewall-cmd), Shorewall lub podobne, możesz skorzystać z patrzenia pod maską bez warstwy abstrakcji oferowanej przez te narzędzia.

To pytanie nie jest przeznaczone do porad dotyczących budowania zapór ogniowych: sprawdź dokumentację produktu i na przykład dodaj przepisy do iptables Trips & Tricks lub przeszukaj oznaczone iptables ufw firewalld firewalld cmd w poszukiwaniu istniejących częstych i dobrze ocenianych wysoko ocenianych wyników Pytania i odpowiedzi.

Ogólnie:

Przeglądanie i modyfikowanie konfiguracji zapory wymaga uprawnień administratora ( root), podobnie jak otwieranie usług w ograniczonym zakresie numerów portów. Oznacza to, że powinieneś być zalogowany jako rootlub alternatywnie użyć, sudoaby uruchomić komendę jako root. Spróbuję oznaczyć takie polecenia opcją [sudo].

Zawartość:

1. Kolejność ma znaczenie lub różnica między -Ii-A
2. Wyświetl aktualną konfigurację zapory
3. Interpretacja wyjścia iptables -L -v -n
4. Poznaj swoje środowisko
5. Łańcuchy INPUT i FORWARD
6. Moduły jądra

1. Kolejność ma znaczenie lub różnica między -Ii-A

Należy pamiętać, że reguły zapory są sprawdzane w kolejności, w jakiej są wymienione. Jądro przestanie przetwarzać łańcuch, gdy zostanie uruchomiona reguła, która zezwoli lub odrzuci pakiet lub połączenie.

Myślę, że najczęstszym błędem początkujących administratorów zapory jest to, że postępują zgodnie z prawidłowymi instrukcjami, aby otworzyć nowy port, taki jak ten poniżej:

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

a następnie odkryć, że to nie zadziała.

Powodem tego jest to, że -Aopcja dodaje tę nową regułę, po wszystkich istniejących regułach, a ponieważ bardzo często ostateczna reguła w istniejącej zaporze sieciowej blokuje cały ruch, który nie jest wyraźnie dozwolony, co powoduje

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Lub odpowiednik w iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

i nowa reguła otwierająca port TCP 8080 nigdy nie zostanie osiągnięta. (o czym świadczą liczniki uparcie pozostające przy 0 pakietach i zerowych bajtach).

Wstawienie reguły z -Inową regułą byłoby pierwszą w łańcuchu i będzie działać.

2. Wyświetl aktualną konfigurację zapory

Moim zaleceniem dla administratora zapory jest przyjrzenie się rzeczywistej konfiguracji jądra Linuksa, a nie próba zdiagnozowania problemów z zaporą na podstawie przyjaznych narzędzi. Często po zrozumieniu podstawowych problemów można je łatwo rozwiązać w sprawie obsługiwanej przez te narzędzia.

Polecenie [sudo] iptables -L -v -nto twój przyjaciel (chociaż niektórzy lubią iptables-savelepiej). Często przy omawianiu konfiguracji przydatne jest użycie tej --line-numbersopcji również do linii numerycznych. Odwołanie się do reguły #X ułatwia omawianie ich.
Uwaga: reguły NAT są zawarte w danych iptables-savewyjściowych, ale muszą być wymienione osobno, dodając -t natopcję tj [sudo] iptables -L -v -n -t nat --line-numbers.

Uruchamianie polecenia wiele razy i sprawdzanie liczników inkrementacyjnych może być przydatnym narzędziem do sprawdzenia, czy nowa reguła faktycznie zostanie uruchomiona.

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Alternatywnie wyjście iptables-savedaje skrypt, który może zregenerować powyższą konfigurację zapory:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

Jest to kwestia preferencji, co łatwiej zrozumieć.

3. Interpretacja wyjścia iptables -L -v -n

Polityka określa domyślną akcję zastosowań łańcuchach, gdy nie ma wyraźnych meczów regułą. W INPUTłańcuchu ustawionym na AKCEPTUJ cały ruch.

Pierwsza reguła w łańcuchu INPUT jest od razu interesująca, wysyła cały ruch (źródło 0.0.0.0/0 i miejsce docelowe 0.0.0.0/0) przeznaczony dla portu TCP 22 ( tcp dpt:22) domyślny port SSH do niestandardowego celu ( fail2ban-SSH) . Jak sama nazwa wskazuje, reguła ta jest utrzymywana przez fail2ban (produkt bezpieczeństwa, który między innymi skanuje pliki dziennika systemu w celu wykrycia ewentualnych nadużyć i blokuje adres IP sprawcy).

Ta reguła zostałaby utworzona za pomocą wiersza polecenia iptables podobnego do iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHlub znalezionego w danych wyjściowych iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Często znajdziesz te zapisy w dokumentacji.

Liczniki wskazują, że ta reguła dopasowała 784 000 pakietów i 65 megabajtów danych.

Ruch pasujący do tej pierwszej reguły jest następnie przetwarzany przez fail2ban-SSHłańcuch, który jako łańcuch niestandardowy znajduje się na liście poniżej łańcucha OUTPUT.

Łańcuch ten składa się z dwóch reguł, po jednej dla każdego sprawcy (źródłowy adres IP 117.253.221.166 lub 58.218.211.166), który jest zablokowany (za pomocą a reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

Pakiety SSH, które nie pochodzą z tych zablokowanych hostów, nie są jeszcze dozwolone ani wyłączone, a teraz po zakończeniu łańcucha niestandardowego będą sprawdzane względem drugiej reguły w łańcuchu INPUT.

Wszystkie pakiety, które nie były przeznaczone dla portu 22, przeszły pierwszą regułę w łańcuchu INPUT i zostaną również ocenione w regule INPUT # 2.

Reguła INPUT numer 2 sprawia, że ​​ma to być stanowa zapora ogniowa , która śledzi połączenia. Ma to pewne zalety, tylko pakiety dla nowych połączeń muszą być sprawdzane pod kątem pełnego zestawu reguł, ale po dopuszczeniu dodatkowe pakiety należące do ustanowionego lub powiązanego połączenia są akceptowane bez dalszego sprawdzania.

Reguła wejściowa nr 2 pasuje do wszystkich otwartych i pokrewnych połączeń oraz pakietów zgodnych z tą regułą nie będzie wymagać dalszej oceny.

Uwaga: zmiany reguł w konfiguracji zapory stanowej wpłyną tylko na nowe połączenia, a nie na nawiązane połączenia.

Natomiast prosty filtr pakietów testuje każdy pakiet pod kątem pełnego zestawu reguł, bez śledzenia stanu połączenia. W takiej zaporze nie byłyby używane słowa kluczowe dotyczące stanu .

Reguła INPUT nr 3 jest dość nudna, cały ruch łączący się z lointerfejsem sprzężenia zwrotnego ( lub 127.0.0.1) jest dozwolony.

Reguły INPUT 4, 5 i 6 są używane do otwierania portów TCP 22, 80 i 443 (domyślne porty odpowiednio dla SSH, HTTP i HTTPS) przez udzielenie dostępu do NOWYCH połączeń (istniejące połączenia są już dozwolone przez regułę INPUT 2).

W bezstanowej zaporze ogniowej reguły te pojawiałyby się bez atrybutów stanu:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

lub

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Końcowa reguła WEJŚCIA nr 7 jest regułą, która blokuje cały ruch, który NIE uzyskał dostępu w regułach WEJŚCIA 1-7. Dość powszechna konwencja: wszystko, co niedozwolone, jest odrzucane. Teoretycznie tę zasadę można pominąć, ustawiając domyślną POLITYKĘ na ODRZUĆ.

Zawsze badaj cały łańcuch.

4. Poznaj swoje środowisko

4.1 Ustawienia zapory programowej nie będą miały wpływu na ustawienia zabezpieczeń utrzymywane gdzie indziej w sieci, tj. Pomimo otwarcia usługi sieciowej z iptablesniezmodyfikowanymi listami kontroli dostępu na routerach lub innych zaporach w sieci może nadal blokować ruch ...

4.2 Gdy żadna usługa nie nasłuchuje, nie będzie można nawiązać połączenia i otrzymać błąd odmowy połączenia , niezależnie od ustawień zapory. W związku z tym:

• Upewnij się, że usługa nasłuchuje (na odpowiednim interfejsie sieciowym / adresie IP) i używa numerów portów, których oczekujesz [sudo] netstat -plnutlub których używasz ss -tnlp.
• Jeśli twoje usługi jeszcze nie powinny działać, emuluj prostego detektora za pomocą na przykład netcat: [sudo] nc -l -p 123lub openssl s_server -accept 1234 [options] jeśli potrzebujesz detektora TLS / SSL (sprawdź man s_serveropcje).
• Sprawdź, czy możesz połączyć się z samego serwera, tj. telnet <IP of Server> 123Lub echo "Hello" | nc <IP of Server> 123podczas testowania zabezpieczonej usługi TLS / SSL openssl s_client -connect <IP of Server>:1234, zanim spróbujesz to zrobić ze zdalnego hosta.

4.3 Poznaj protokoły używane przez twoje usługi. Nie możesz poprawnie włączyć / wyłączyć usług, których nie rozumiesz w wystarczającym stopniu. Na przykład:

• czy używany jest TCP lub UDP, czy oba (jak w DNS)?
• czy usługa korzysta ze stałego domyślnego portu (na przykład coś takiego jak port TCP 80 dla serwera WWW)?
• alternatywnie, czy wybrany jest dynamiczny numer portu, który może się różnić (tj. usługi RPC, takie jak klasyczny NFS, który rejestruje się w Portmap)?
• niesławny FTP używa nawet dwóch portów , zarówno stałego, jak i dynamicznego, gdy jest skonfigurowany do używania trybu pasywnego ...
• opisy usług, portów i protokołów /etc/servicesniekoniecznie odpowiadają rzeczywistej usłudze używającej portu.

4.4 Filtr pakietów jądra nie jest jedyną rzeczą, która może ograniczać łączność sieciową:

• SELinux może również ograniczać usługi sieciowe. getenforcepotwierdzi, czy SELinux jest uruchomiony.
• Mimo, że stają się nieco niejasne, owijarki TCP są nadal potężnym narzędziem do egzekwowania bezpieczeństwa sieci. Sprawdź za pomocą ldd /path/to/service |grep libwrapi /hosts.[allow|deny]plików kontrolnych.

5. INPUTlub FORWARDłańcuchy

Pojęcie łańcuchów jest tu dokładniej wyjaśnione , ale w skrócie:

W tym INPUTłańcuchu otwierasz i / lub zamykasz porty sieciowe dla usług działających lokalnie na hoście, na którym wydajesz polecenia iptables.

W FORWARDłańcuchu stosowane są reguły do ​​filtrowania ruchu przesyłanego przez jądro do innych systemów, rzeczywistych systemów, ale także do kontenerów Docker i wirtualnych serwerów gości, gdy maszyna z systemem Linux działa jako most, router, hypervisor i / lub adres sieciowy tłumaczenie i przekierowanie portów.

Powszechnym nieporozumieniem jest to, że ponieważ kontener dokera lub gość KVM działa lokalnie, obowiązujące reguły filtrowania powinny znajdować się w łańcuchu INPUT, ale zwykle tak nie jest.

6. Moduły jądra

Ponieważ filtr pakietów działa w jądrze Linuksa, można go również skompilować jako moduł dynamiczny, w rzeczywistości wiele modułów. Większość dystrybucji zawiera netfilter jako moduły, a wymagane moduły netfilter zostaną załadowane do jądra w razie potrzeby, ale w przypadku niektórych modułów administrator zapory będzie musiał ręcznie upewnić się, że zostaną załadowane. Dotyczy to przede wszystkim modułów śledzenia połączeń, na przykład takich, nf_conntrack_ftpktóre można załadować insmod.

Moduły aktualnie załadowane do działającego jądra można wyświetlić za pomocą lsmod.

Metoda zapewnienia stałego ładowania modułów podczas ponownego uruchamiania zależy od dystrybucji systemu Linux.

Typowe problemy z różnymi protokołami

DNS: DNS domyślnie korzysta z portu 53 UDP, ale wiadomości, które nie mieszczą się w jednym datagramie UDP, będą przesyłane za pomocą protokołu TCP (zwykle transfery stref itp.) Wymagające otwarcia portu 53 TCP również po uruchomieniu serwera nazw .

E-mail: wielu konsumentów blokuje ruch SMTP (lub przynajmniej domyślny port TCP 25), co uniemożliwia bezpośrednie odbieranie lub wysyłanie wiadomości e-mail, a ich klienci są zmuszeni do korzystania z przekaźnika SMTP usługodawcy internetowego dla wszystkich wychodzących wiadomości e-mail, a czasami także dla wiadomości przychodzących . Dotyczy §1.1.

FTP: FTP jest nieparzystym protokołem, ponieważ używane są dwa połączenia. Pierwszym z nich jest połączenie sterujące, domyślnie serwer FTP nasłuchuje na porcie TCP 21 w tym celu. Połączenie sterujące służy do uwierzytelniania i wydawania poleceń. Rzeczywiste transfery plików i takie rzeczy, jak dane wyjściowe listy katalogów, przechodzą przez drugie połączenie TCP, połączenie DATA. W aktywnym FTP połączenie danych zostanie zainicjowane z serwera FTP z portu TCP 20 i połączone z klientem FTP. Aktywny FTP nie działa zbyt dobrze z użytkownikami za firewallami i bramami NAT, więc w większości przestał być używany. Większość serwerów FTP obsługuje zamiast tego pasywny FTP. Dzięki Pasywnemu FTP serwer FTP otwiera odbiornik połączenia DATA na drugim porcie, z którym może się następnie połączyć klient FTP. Problemem zapory ogniowej jest to, że port DATA może być dowolnym dostępnym nieuprzywilejowanym portem między 1024-65536.

W bezstanowej zaporze ogniowej, która jest zazwyczaj rozwiązywana przez ograniczenie liczby pasywnych portów, które serwer FTP może przypisać, a następnie jawne otwarcie tych portów. to znaczy

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

W zaporze stanowej nie trzeba jawnie otwierać portu DATA, moduł pomocniczy netfilter rozpozna przydzielony port dynamiczny i dynamicznie otworzy ten port dla poprawnego klienta, zaznaczając połączenie DATA, RELATEDpo którym będzie zgodne z ogólną regułą :

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Wymaga to załadowania poprawnego modułu jądra , w przypadku FTP ręcznie, na przykład przez uruchomienie insmod nf_conntrack_ftp, co powoduje, że trwałe zależne od ponownego uruchomienia zależy od dystrybucji.

Uwaga: moduł śledzenia połączenia FTP zawiedzie, gdy FTP jest używany z SSL, ponieważ połączenie sterujące zostanie zaszyfrowane, a nf_conntrack_ftp nie będzie już w stanie odczytać powtórzenia PASV.

NFS i podobne usługi RPC: Problem z usługami RPC polega na tym, że z założenia nie używają określonego stałego portu. Mogą losowo wybrać dowolny dostępny port, który zostanie następnie zarejestrowany w demonie Portmap RPC. Klient próbujący się połączyć wysyła zapytanie do demona Portmap, a następnie łączy się bezpośrednio z odpowiednim portem. To rozwiązało problem braku wolnych portów ...

Z punktu widzenia zapory należy otworzyć port TCP / UDP 111 oraz rzeczywisty port, z którego aktualnie korzysta usługa RPC. Problem otwierania takiego losowego portu w zaporze zwykle rozwiązuje się przez ograniczenie usługi RPC, takiej jak serwer NFS, do korzystania z predefiniowanego stałego portu.

„Wprowadzenie” do Iptables / Firewall

Zapora jest zasadniczo filtrem sieciowym opartym na zasadach. Zapory systemu Linux są zbudowane wokół Netfilter; struktura przetwarzania pakietów sieciowych jądra, która składa się z kilku modułów jądra wykonujących określone zadania:

1. Moduł FILTER (zawsze domyślnie ładowany) pozwala nam AKCEPTOWAĆ lub DROPować pakiety IP w oparciu o określone pasujące kryteria.
2. Zestaw modułów NAT pozwala nam na tłumaczenie adresów sieciowych (SNAT, DNAT, MASQUERADE).
3. Moduł MANGLE pozwala nam zmieniać niektóre pola pakietów IP (TOS, TTL).

Użytkownicy konfigurują środowisko Netfilter, aby dopasować je do swoich potrzeb zapory, używając iptables z wiersza poleceń. W iptables definiujemy reguły, które instruują jądro, co robić z pakietami IP, kiedy przychodzą do, przechodzą lub opuszczają naszą skrzynkę Linux. Każdy główny proces Netfilter jest reprezentowany przez TABELĘ (FILTER, NAT, MANGLE) w języku iptables. Mają kilka konkretnych punktów zaczepienia na mapie przepływu pakietów sieciowych, gdzie są one wywoływane przez jądro do wykonywania swoich obowiązków. Niektóre specjalnie zlokalizowane sekwencje wywołań TABELI są ogólnie nazywane wbudowanymi ŁAŃCUCHAMI odbierającymi nazwy PREROUTING, INPUT, FORWARD, OUTPUT i POSTROUTING. Łatwo jest pamiętać, jeśli TABELĘ kojarzymy z „typem procesu”, a ŁAŃCUCH z „lokalizacją” na mapie przepływu pakietów sieciowych, w której wywoływane są instancje tych procesów.

Ponieważ pakiet IP jest odbierany przez interfejs sieciowy lub tworzony przez proces lokalny, dopóki nie zostanie ostatecznie dostarczony lub odrzucony, silnik Netfilter będzie kolejno testował i stosował reguły zawarte na mapie przepływu pakietów sieciowych. W każdym bloku identyfikowanym przez parę TABELA @ ŁAŃCUCH użytkownik może dodać jedną lub więcej następujących po sobie reguł zawierających kryteria dopasowania pakietu IP i odpowiadający im kierunek działania. Istnieją akcje (tj. AKCEPTUJ, DROP itp.), Które mogą być wykonywane przez więcej niż jedną TABELĘ oraz inne akcje (np. SNAT, DNAT itp.), Które są specyficzne dla TABELI.

tzn. gdy pakiet IP przybywa z interfejsu sieciowego, jest najpierw przetwarzany przez łańcuch PREROUTING, który wywołuje reguły zdefiniowane przez użytkownika tabeli MANGLE, jeśli takie istnieją. Jeśli nie ma reguł pasujących do bieżącego pakietu, zastosowanie ma odpowiedni domyślny sposób działania MANGLE @ PREROUTING lub „policy”. W tym momencie, jeśli pakiet nie został upuszczony, proces będzie kontynuował teraz wywoływanie reguł tabeli NAT w łańcuchu PREROUTING (patrz mapa) i tak dalej. Aby ułatwić układ reguł, użytkownicy mogą również tworzyć własne łańcuchy niestandardowe i „wskakiwać” na nie z różnych punktów mapy, jak chcą.

Podczas gdy wbudowane łańcuchy mogą mieć zdefiniowane przez użytkownika polityki pakietów ACCEPT lub DROP, łańcuchy zdefiniowane przez użytkownika mają zawsze niezmienną domyślną politykę POWRÓT do wywołującego, aby kontynuować proces.

Komendy Iptables

Główne polecenia iptables wypełniają mapę przepływu pakietów sieciowych wymaganymi regułami przetwarzania.

Ogólną regułę iptables można zapisać jako:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Można to odczytać następująco:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Komendy pomocnicze iptables uzupełniają scenariusz, ustawiając domyślne warunki, reguły listy, reguły spłukiwania itp.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

Iptables ładuje nasze polecenia do silnika Netfilter w czasie wykonywania, Netfilter natychmiastowo wymusza załadowane reguły i ustawienia, ale nie są trwałe. Po ponownym uruchomieniu wszystkie wcześniej załadowane reguły i ustawienia Netfilter zostaną utracone. Z tego powodu istnieją narzędzia iptables, które pozwalają zapisać aktualnie aktywny zestaw reguł do pliku i załadować go później.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Podsumowanie Iptables

Netfilter to niezwykle elastyczny i potężny framework, ale trzeba za to zapłacić; Iptables jest złożony. Z punktu widzenia użytkownika niektóre terminy, takie jak TABELA, ŁAŃCUCH, TARGET, nie bardzo dobrze pasują do koncepcji, którą reprezentują i na początku nie mają większego sensu. Temat jest długi, polecenia wydają się mieć nieskończoną listę parametrów. Co gorsza, nie ma jednej książki, która naprawdę opanowałaby Iptables. Przeważnie dzielą się na dwie kategorie: „książkę kucharską” lub „książkę strony podręcznika”. Myślę, że to wprowadzenie przedstawia migawkę krajobrazu Netfilter / Iptables oraz niezbędną dawkę wstępnie strawionego podręcznika. Jeśli jesteś nowy w iptables, po przeczytaniu tych paragrafów kilka razy będziesz gotowy do przeczytania przykładów iptables. Przy odrobinie praktyki wkrótce okaże się, że piszesz własne zasady.

Zapory ogniowe

Zapora została zaprojektowana głównie w celu dynamicznego zezwalania na ruch sieciowy lub blokowania go w oparciu o zestaw reguł. W tym momencie łatwo zrozumieć, dlaczego platforma Linux Netfilter / Iptables jest idealna do budowy zapory ogniowej. Patrząc na mapę przepływu pakietów sieciowych, widzimy dwa szczególnie interesujące miejsca w tabeli FILTER w łańcuchach INPUT i FORWARD; Możemy zdecydować na podstawie adresu źródłowego IP, protokołu IP (UDP / TCP), portu docelowego (80, 21, 443 itd.) Itd., Jeśli AKCEPTUJEMY, ODRZUĆ, lub po prostu USUŃ konkretny pakiet IP. To właśnie robi zapora sieciowa w 80% przypadków, kiedy np. Chroni serwer WWW przed nieautoryzowanymi żądaniami sieci. Pozostałe 20% czasu to manipulowanie pakietami sieciowymi (NAT, MANGLE).

Scenariusze zapór ogniowych

Istnieją setki różnych układów zapory ogniowej odpowiadających różnym potrzebom, ale 3 z nich można uznać za najbardziej typowe scenariusze zapory ogniowej.

1. Prosty serwer WWW z co najmniej jednym interfejsem podłączonym do Internetu. Zasady obejmują podstawowe zasady zezwalające na ograniczony dostęp przychodzący, nieograniczony dostęp wychodzący oraz reguły przeciwdziałające fałszowaniu. Przekazywanie IP jest wyłączone.
2. Ta zapora łączy się z Internetem i chronionym obszarem wewnętrznym. Zasady obejmują podstawowe zasady zezwalające na ograniczony dostęp przychodzący, nieograniczony dostęp wychodzący oraz reguły przeciwdziałające fałszowaniu. Ponieważ obszar chroniony używa prywatnych adresów IP, potrzebny jest źródłowy NAT. Przekazywanie IP jest włączone.
3. Ta zapora łączy się z Internetem, wewnętrznym obszarem chronionym i zdemilitaryzowanym. Zasady obejmują podstawowe zasady zezwalające na ograniczony dostęp przychodzący, nieograniczony dostęp wychodzący i reguły przeciwdziałające fałszowaniu. Ponieważ obszary chronione i strefy DMZ używają prywatnych adresów IP, potrzebują źródłowego i docelowego NAT. Przekazywanie IP jest włączone.

Napisałem to dla: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html