Architektura Iptables i Netfilter

Zapora firewall to urządzenie bezpieczeństwa (sprzętowe/programowe), które chroni sieć poprzez filtrowanie ruchu i blokowanie niechcianego/nieautoryzowanego dostępu do prywatnych danych. Posiadanie odpowiedniej zapory sieciowej jest ważne dla ochrony serwerów i infrastruktury. Może ona nie tylko blokować niechciany ruch, ale także zapobiegać infekowaniu systemu przez złośliwe oprogramowanie.

W ekosystemie Linux, iptables to popularna zapora sieciowa, która współpracuje z netfilter w jądrze Linuksa. Większość nowoczesnych systemów Linux ma te narzędzia wbudowane fabrycznie. Aby w pełni wykorzystać te systemy, kluczowe znaczenie ma zrozumienie ich architektury. W przeciwnym razie opracowanie niezawodnych reguł zapory sieciowej może być trudne. Może to prowadzić do tworzenia skomplikowanych składni, powiązanych ze sobą części w strukturze itp.

Ten przewodnik szczegółowo omówi architekturę iptables aby pomóc użytkownikom, którzy muszą stworzyć własne reguły zapory sieciowej. Przyjrzymy się również, jak iptables współpracuje z netfilter i jak poszczególne komponenty pasują do siebie.

Iptables i Netfilter

W systemie Linux zapora iptables firewall jest najpopularniejsza. Działa poprzez współpracę z punktami zaczepienia (hooks) filtrowania pakietów w stosie sieciowym jądra systemu Linux. To właśnie te punkty zaczepienia jądra są wspólnie określane jako netfilter .

Każdy pakiet przychodzący/wychodzący w systemie wyzwala te punkty zaczepienia podczas przejścia przez stos. Dzięki temu programy zarejestrowane w tych punktach mogą wchodzić w interakcję z ruchem w kluczowych momentach. Na koniec moduły jądra powiązane z iptables łączą się z tymi punktami zaczepienia, aby wdrażać określone reguły zapory sieciowej.

Punkty zaczepienia Netfilter (Hooks)

Aby programy mogły się połączyć, istnieje pięć różnych punktów zaczepienia netfilter. Gdy pakiety przechodzą przez stos, punkty te wyzwalają zarejestrowane w nich moduły jądra. Warunek wyzwolenia zależy od takich czynników, jak:  kierunek pakietu (przychodzący/wychodzący), cel pakietu, to, czy pakiet został porzucony/odrzucony w poprzednim punkcie itp.

Oto punkty zaczepienia reprezentujące różne dobrze zdefiniowane punkty w stosie sieciowym:

• NF_IP_PRE_ROUTING: Ten punkt zaczepienia jest wyzwalany przez jakikolwiek ruch przychodzący. Wyzwolenie następuje przed podjęciem jakiejkolwiek decyzji dotyczącej routingu związanej z miejscem docelowym pakietu.

• NF_IP_LOCAL_IN: Ten punkt zaczepienia jest wyzwalany po przekierowaniu (routingu) pakietu przychodzącego. Pakiet musi być również przeznaczony dla systemu lokalnego.

• NF_IP_FORWARD: Ten punkt zaczepienia jest również wyzwalany po przekierowaniu pakietu przychodzącego. Wyzwala się jednak wtedy, gdy pakiet ma zostać przekierowany do innego hosta.

• NF_IP_LOCAL_OUT: Każdy lokalny ruch wychodzący, gdy tylko trafi do stosu sieciowego, wyzwala ten punkt zaczepienia.

• NF_IP_POST_ROUTING: Ten punkt zaczepienia jest wyzwalany przez jakikolwiek ruch wychodzący/przekazywany po zakończeniu routingu, zanim pakiet trafi do sieci.

Moduły jądra chcące zarejestrować się w tych punktach zaczepienia muszą podać numer priorytetu. Wartość ta pomaga określić kolejność, w jakiej będą wywoływane po wyzwoleniu punktu zaczepienia. Taki mechanizm pozwala wielu modułom (różnym modułom lub wielu kopiom tego samego modułu) na łączenie się z każdym z punktów zaczepienia w deterministycznej kolejności. Każdy moduł zwróci decyzję do struktury netfilter po przetworzeniu pakietów.

Tabele i łańcuchy w Iptables

Do organizowania swoich reguł zapora iptables używa tabel. Tabele kategoryzują reguły na podstawie rodzaju podejmowanych decyzji. Na przykład, jeśli reguła dotyczy NAT (translacji adresów sieciowych), jest ona umieszczana w tabeli nat. Podobnie, jeśli reguła decyduje o zezwoleniu lub odmowie dostępu pakietu do miejsca docelowego, jest dodawana do tabeli filter .

Wewnątrz każdej tabeli iptables, reguły są dalej organizowane w ramach oddzielnych “łańcuchów”. Podczas gdy tabela reprezentuje typ przechowywanych reguł, łańcuchy opisują punkty zaczepienia netfilter , które wyzwalają te reguły. Krótko mówiąc, łańcuchy określają, kiedy reguła zostanie oceniona.

Oto wbudowane łańcuchy iptables. Co ciekawe, nazwy łańcuchów odzwierciedlają również nazwę powiązanych netfilter haków:

Używając łańcuchów, administratorzy mogą określić, na którym etapie dostarczania pakietu reguła będzie oceniana. Ponieważ każda tabela zawiera wiele łańcuchów, może ona również rozszerzyć swój wpływ na wiele punktów przetwarzania. Niektóre decyzje mają sens tylko w określonych punktach stosu sieciowego. W związku z tym nie każda tabela będzie miała łańcuch zarejestrowany przy każdym haku jądra.

Framework netfilter oferuje tylko 5 haków jądra. W związku z tym łańcuchy z wielu tabel są rejestrowane w każdym punkcie haków. Na przykład, jeśli trzy łańcuchy mają PREROUTING łańcuchy, to są one rejestrowane z NF_IP_PRE_ROUTING hakiem. Każdy z nich musi określić priorytet, który decyduje, w jakiej kolejności łańcuch PREROUTING każdej tabeli jest wywoływany. Łańcuch PREROUTING o najwyższym priorytecie jest oceniany jako pierwszy, ten o kolejnym najwyższym priorytecie jako drugi i tak dalej.

Tabele iptables

Zróbmy krok wstecz i przyjrzyjmy się tabelom, które oferuje iptables. Jak wspomniano wcześniej, każda tabela reprezentuje inne zestawy reguł, uporządkowane według obszaru zastosowania, służące do oceny pakietów.

• Tabela filter

W iptables , tabela filter jest jedną z najpopularniejszych. Służy do określania, czy pakiet będzie mógł kontynuować podróż do miejsca docelowego, czy nie. W terminologii zapór sieciowych proces ten jest znany jako “filtrowanie” pakietów.

To właśnie do funkcji tabeli filter odnosi się większość ludzi, gdy dyskutują o zaporach sieciowych (w większości przypadków).

• Tabela nat

Ta tabela wdraża reguły regulujące NAT. Gdy pakiety trafiają do stosu sieciowego, reguły opisane w tej tabeli decydują o sposobie modyfikacji adresu źródłowego/docelowego pakietu, co wpływa na trasowanie pakietu i wszelki ruch zwrotny.

Często tabela nat jest używana do kierowania pakietów do sieci, do których nie ma bezpośredniego dostępu.

• Tabela mangle

Ta tabela zawiera reguły, które na różne sposoby modyfikują nagłówki IP pakietów. Na przykład może modyfikować wartość TTL (Time to Live) pakietu poprzez wydłużenie/skrócenie liczby prawidłowych przeskoków sieciowych, które pakiet może przetrwać. Ponadto tabela mangle może w podobny sposób modyfikować inne nagłówki IP.

Tabela ta pozwala również na nałożenie na pakiet wewnętrznego “znacznika” jądra, który inne tabele i narzędzia sieciowe mogą odczytać w celu dalszego przetwarzania. Znacznik ten nie wpływa na sam pakiet, lecz dodaje oznaczenie do reprezentacji pakietu w jądrze.

• Tabela raw

Zapora sieciowa iptables jest stanowa, co oznacza, że pakiety są oceniane w kontekście ich relacji z poprzednimi pakietami. Funkcja śledzenia połączeń opracowana na bazie netfilter pozwala iptables postrzegać pakiety jako część trwającego połączenia lub sesji, a nie jako strumień oddzielnych, niepowiązanych pakietów. Zazwyczaj logika śledzenia połączeń jest stosowana bardzo szybko po dotarciu pakietu do interfejsu sieciowego.

Tabela raw ma bardzo wąsko zdefiniowaną funkcję. Jedynym celem tej tabeli jest zapewnienie mechanizmu znakowania pakietów w celu wyłączenia ich ze śledzenia połączeń.

• Tabela security

Tabela security nakłada na pakiety wewnętrzne znaczniki kontekstu bezpieczeństwa SELinux. To z kolei wpływa na to, jak SELinux (lub jakakolwiek inna aplikacja interpretująca konteksty bezpieczeństwa SELinux) będzie obsługiwać te pakiety.

Znaczniki SELinux mogą być stosowane dla każdego pakietu osobno lub dla całego połączenia.

Łańcuchy zaimplementowane w każdej tabeli

Do tej pory mówiliśmy o tabelach i łańcuchach osobno. Czas omówić, które łańcuchy są dostępne w poszczególnych tabelach. Temat ten rozwija dyskusję na temat kolejności oceniania łańcuchów zarejestrowanych przy tym samym haku. Na przykład, co się stanie, jeśli trzy tabele mają PREROUTING łańcuchy? Jaka jest kolejność ich oceniania?

Następnie spójrz na poniższą tabelę. Wskazuje ona łańcuchy dostępne w każdej z tabel iptables.

Czytana od lewej do prawej opisuje, jakie tabele zawierają jakie łańcuchy. Na przykład tabela raw zawiera zarówno łańcuchy PREROUTING, jak i OUTPUT. Czytana od góry do dołu opisuje, w jakiej kolejności wywoływany jest każdy łańcuch, gdy powiązany z nim netfilter hook zostanie wyzwolony.

Zauważ, że tabela nat została podzielona na operacje DNAT (modyfikujące cel pakietu) oraz SNAT (modyfikujące źródło pakietu), aby wyraźniej określić ich kolejność. Tabela zawiera również punkty reprezentacji, w których podejmowane są decyzje dotyczące routingu oraz włączane jest śledzenie połączeń.

Hooki (kolumny), które pakiet wyzwoli, zależą od charakteru pakietu (przychodzący/wychodzący), podejmowanych decyzji dotyczących routingu oraz tego, czy pakiet spełnia kryteria filtrowania.

Niektóre zdarzenia mogą pomijać łańcuch tabeli podczas przetwarzania. Na przykład tylko pierwszy pakiet w połączeniu będzie oceniany pod kątem reguł NAT opisanych przez tabelę nat. Każdy kolejny pakiet w tym samym połączeniu będzie miał zastosowane te same decyzje nat bez żadnej dodatkowej oceny. Odpowiedzi na połączenia NAT będą automatycznie miały zastosowane odwrotne reguły NAT w celu zapewnienia prawidłowego routingu.

Kolejność przechodzenia przez łańcuchy

Zakładając, że serwer zna reguły routingu pakietów, a reguły zapory sieciowej zezwalają na transmisję, poniższe przepływy przedstawiają, jak będą pokonywane poszczególne ścieżki:

• Pakiety przychodzące przeznaczone dla systemu lokalnego: PREROUTING >> INPUT

• Pakiety przychodzące przeznaczone dla innego hosta: PREROUTING >> FORWARD >> POSTROUTING

• Pakiety generowane lokalnie: OUTPUT >> POSTROUTING

Podsumowując, łącząc wszystkie omówione dotychczas informacje, widzimy, że każdy pakiet przychodzący przeznaczony dla systemu lokalnego będzie oceniany pod kątem łańcuchów PREROUTING tabel raw, mangle, oraz nat. Następnie przejdzie przez łańcuchy INPUT tabel mangle, filter, security, oraz nat zanim ostatecznie dotrze do lokalnego gniazda.

Reguły iptables

Reguły zapory sieciowej iptables są umieszczane w określonym łańcuchu określonej tabeli. Po wywołaniu łańcucha dany pakiet będzie oceniany pod kątem każdej reguły w tym łańcuchu. Każda reguła składa się z dwóch komponentów: komponentu dopasowania i komponentu akcji.

• Dopasowanie

Część dopasowująca reguły określa warunki, które pakiet musi spełnić, zanim zostanie wykonana określona akcja (lub “cel”).

System dopasowywania oferuje niesamowitą elastyczność. Jego funkcjonalność można również rozszerzyć za pomocą rozszerzeń iptables. Reguły mogą być opisywane w celu dopasowania pakietów według typu protokołu, adresu źródłowego/docelowego, portu źródłowego/docelowego, sieci źródłowej/docelowej, interfejsu wejściowego/wyjściowego, nagłówków, stanu połączenia i innych kryteriów. Reguła może również zawierać kombinację tych warunków, co pozwala na tworzenie złożonych zestawów reguł w celu rozróżniania różnego rodzaju ruchu.

• Cele (Targets)

Cel (target) to akcja podejmowana, gdy pakiet spełnia kryteria dopasowania reguły. Ogólnie cele dzielą się na dwie grupy:

• • Cele kończące (Terminating targets): Kończy on proces oceny wewnątrz łańcucha i zwraca kontrolę do hooka netfilter. Na podstawie wartości zwracanej hook pozwoli pakietowi kontynuować podróż lub go odrzuci.

  • Cele niekończące (Non-terminating targets): Cel wykonuje akcję, a ocena w łańcuchu jest kontynuowana. Chociaż każdy łańcuch musi zakończyć się ostateczną decyzją kończącą, wcześniej może mieć miejsce dowolna liczba celów niekończących.

Dostępność każdego celu w regułach zależy od kontekstu. Na przykład typ łańcucha i tabeli może wpływać na dostępność celów. Inne możliwe czynniki to aktywowane rozszerzenia w regule oraz klauzule dopasowania.

Łańcuchy zdefiniowane przez użytkownika

Istnieje również specjalna klasa celów niekończących działania: cel skoku (jump target). Cele skoku to akcje wykonywane, gdy ewaluacja przechodzi z jednego łańcucha do drugiego w celu dalszego przetwarzania. Do tej pory mówiliśmy o wbudowanych łańcuchach, które są ściśle powiązane z netfilter punktami zaczepienia, które je wywołują. Jednak iptables pozwala również administratorom na tworzenie własnych łańcuchów.

Reguły w łańcuchach zdefiniowanych przez użytkownika są również podobne do tych we wbudowanych łańcuchach. Kluczowa różnica polega na tym, że łańcuchy zdefiniowane przez użytkownika są osiągalne tylko poprzez “skok” do nich z reguły. Wynika to z faktu, że łańcuchy zdefiniowane przez użytkownika nie są powiązane z żadnymi netfilter punktami zaczepienia.

Można myśleć o łańcuchach zdefiniowanych przez użytkownika jako o rozszerzeniach łańcucha, który pierwotnie je wywołał. Na przykład w łańcuchu zdefiniowanym przez użytkownika ewaluacja powróci do łańcucha wywołującego, jeśli osiągnie koniec listy reguł lub gdy pasująca reguła wykona RETURN cel. Co ciekawe, łańcuch zdefiniowany przez użytkownika może również “przeskoczyć” z ewaluacją do innego łańcucha zdefiniowanego przez użytkownika.

Funkcja ta kładzie podwaliny pod lepszą organizację i zapewnia niezbędne ramy dla solidnego rozgałęziania.

Śledzenie połączeń

Podczas omawiania tabeli raw i kryteriów dopasowania stanu połączenia, omówiliśmy system śledzenia połączeń zaimplementowany na bazie frameworku netfilter . Ta funkcja pozwala iptables  na przeglądanie pakietów w kontekście trwającego połączenia. System śledzenia połączeń zapewnia również iptables niezbędną funkcjonalność potrzebną do wykonywania operacji “stanowych”.

Zaraz po wejściu pakietu do stosu sieciowego stosowane jest śledzenie połączeń. Łańcuchy tabeli raw i kilka podstawowych kontroli spójności to cała logika, która służy do powiązania pakietów z połączeniem.

System sprawdza każdy pakiet pod kątem zestawu istniejących połączeń. W razie potrzeby system zaktualizuje stan istniejących połączeń lub utworzy nowe. Pakiety, które zostały oznaczone celem NOTRACK w dowolnym łańcuchu tabeli raw, ominą dalsze procedury śledzenia połączeń.

• Dostępne stany

Połączeniom śledzonym przez system śledzenia połączeń zostanie przypisany jeden z następujących stanów:

• • NEW : Po nadejściu pakietu, który nie jest powiązany z istniejącym połączeniem, ale nie jest nieprawidłowy jako pierwszy pakiet, do systemu dodawane jest nowe połączenie z tą etykietą. Dzieje się tak zarówno w przypadku protokołów zorientowanych na połączenie (na przykład TCP), jak i bezpołączeniowych (na przykład UDP).

  • ESTABLISHED: Stan połączenia jest aktualizowany z NEW  na ESTABLISHED, gdy otrzyma prawidłową odpowiedź z przeciwnego kierunku. W przypadku połączeń TCP oznacza to SYN/ACK. Dla ruchu UDP i ICMP oznacza to odpowiedź, w której źródło i cel oryginalnego pakietu są zamienione.

  • RELATED: Pakiety, które nie są częścią połączenia, ale są powiązane z ustanowionym połączeniem, otrzymują etykietę RELATED . Może to oznaczać połączenie pomocnicze (na przykład w połączeniu transmisji danych FTP) lub odpowiedzi ICMP na próby połączeń przez inne protokoły.

  • INVALID: Pakiety, które nie są częścią ustanowionego połączenia, zostaną uznane za nieodpowiednie do otwarcia nowego połączenia, nie mogą zostać zidentyfikowane, nie są routowalne itp., otrzymują etykietę INVALID.

  • UNTRACKED: Pakiet może zostać oznaczony jako UNTRACKED , jeśli został skierowany w łańcuchu tabeli raw w celu ominięcia śledzenia.

  • SNAT: Oznacza stan wirtualny ustawiany, gdy adres źródłowy jest modyfikowany przez operację NAT. Jest on obsługiwany przez system śledzenia połączeń, dzięki czemu adresy źródłowe są tłumaczone w pakietach odpowiedzi.

  • DNAT: Podobnie jak SNAT, oznacza to stan wirtualny, w którym adres docelowy jest modyfikowany przez operację NAT. System śledzenia połączeń obsługuje go w taki sposób, aby wiedzieć, jak przetłumaczyć adres docelowy z powrotem podczas rutowania pakietów odpowiedzi.

Stany te, śledzone przez system śledzenia połączeń, pozwalają administratorom na tworzenie określonych reguł ukierunkowanych na konkretne punkty w cyklu życia połączenia. Zapewnia to niezbędną funkcjonalność dla bardziej szczegółowych i bezpiecznych reguł.

Podsumowanie

W systemie Linux netfilter framework i iptables zapora sieciowa służą jako podstawa dla większości zapór. Haki netfilter znajdują się wystarczająco blisko stosu sieciowego, aby umożliwić potężną kontrolę nad pakietami przetwarzanymi przez system. Wykorzystując te możliwości, iptables zapora sieciowa oferuje elastyczny sposób przekazywania wymagań dotyczących polityki do jądra.

Ten przewodnik szczegółowo omawia wewnętrzną strukturę netfilter frameworku i iptables zapory sieciowej. Ponadto omówiono w nim system śledzenia połączeń. Rozumiejąc, jak te elementy do siebie pasują, możesz lepiej je wykorzystać do tworzenia bardziej solidnych i bezpiecznych środowisk serwerowych.

Na koniec, choć ten przewodnik porusza kwestie wewnętrznego działania, zapoznaj się z tym przewodnikiem dotyczącym konfiguracji iptables, aby zastosować je w praktyce. Ponadto możesz zobaczyć, jak zapora UFW dodatkowo upraszcza iptables. Co więcej, przydatne będzie dowiedzenie się, jak wyświetlić i usunąć reguły zapory iptables.

Powodzenia!