Tutoriel Linux

Nftables w systemie Linux, sprawdź zasady przed otwarciem portu

Débutant6 min de lecture

Port wygląda na zamknięty z zewnątrz, a potem zaczynamy szukać w aplikacji lub routerze. Zanim cokolwiek zmienisz, sprawdź zasady rzeczywiście załadowane przez nftables. Plik /etc/nftables.conf może różnić się od aktywnego stanu, a lokalna zapora nie wyjaśnia sama w sobie całej trasy sieciowej.

Ta metoda pozwala na odczytanie zestawu reguł, zlokalizowanie łańcucha, który przetwarza ruch przychodzący oraz przetestowanie zmiany bez utraty sesji SSH. Zachowaj drugie połączenie otwarte, jeśli działasz zdalnie.

Zacznij od odczytania załadowanej zapory

Naszym następnym poleceniem nic się nie zmieni. Wyświetla tabelki, łańcuchy, reguły oraz wszelkie liczniki, które obecnie znajdują się w jądrze:

sudo nft list ruleset

Jeśli wynik jest długi, najpierw wymień tabelki, a następnie celuj w tę, która Cię interesuje:

sudo nft list tables
sudo nft list table inet filter

Rodzina inet może zawierać zarówno reguły IPv4, jak i IPv6. Tabelka może również należeć do ip, ip6, bridge lub netdev. Nie zastępuj reguły IPv6 regułą IPv4, zakładając, że problem tym samym się rozwiązuje.

W tabeli filtrującej skup się szczególnie na łańcuchu podstawowym z type filter hook input. To on odbiera ruch przeznaczony dla maszyny. Linia policy drop oznacza, że pakiety, które nie napotkają żadnej reguły accept, zostaną odrzucone.

Aby zobaczyć identyfikatory reguł, co jest przydatne, jeśli musisz usunąć konkretną regułę później, dodaj -a:

sudo nft -a list chain inet filter input

Nie myl input, forward oraz output. Serwer, który odbiera połączenie SSH, zazwyczaj korzysta z input. Maszyna, która przesyła ruch do innego hosta, może zablokować pakiet w forward. Aplikacja, która wychodzi w kierunku Internetu, korzysta z output.

Sprawdź port i kolejność reguł

Reguły łańcucha są oceniane w kolejności. Reguła odrzucenia umieszczona przed zezwoleniem na port wygrywa. Szukaj protokołu, portu oraz stanu połączenia:

sudo nft list chain inet filter input
sudo ss -lntup

Dla SSH oczekiwana reguła często wygląda jak tcp dport 22 accept. Port może być inny, jeśli demon nasłuchuje w innym miejscu. Wynik ss -lntup pozwala na upewnienie się, że program naprawdę nasłuchuje na oczekiwanym porcie i adresie. Otwarta zapora nie udostępnia usługi, która jest zatrzymana.

Sprawdź także reguły ct state established,related accept i interfejs loopback iif lo accept. Unikają one zerwania odpowiedzi na wcześniej nawiązane połączenia oraz lokalne wymiany. Jeśli zestaw reguł zawiera liczniki, porównaj je przed i po teście połączenia, aby sprawdzić, która reguła widzi ruch.

Odrzucenie może również wystąpić poza maszyną: grupa bezpieczeństwa w chmurze, router, przekierowanie NAT, VLAN, zapora firmowa lub usługa powiązana tylko z 127.0.0.1. Z innego komputera przetestuj port za pomocą nc -vz adres_serwera 22 lub za pomocą swojego klienta SSH. Na serwerze upewnij się, że nasłuchuje on za pomocą ss zanim cokolwiek zrobisz z nftables.

Zidentyfikuj regułę, która naprawdę blokuje

Łańcuch może wywołać inny łańcuch z użyciem jump lub goto. Zezwolenie na port niekoniecznie jest widoczne w pierwszym wyświetlanym łańcuchu. Przeczytaj ponownie wywołania łańcuchów, zestawy nazwane i reguły noszące prefiks logowania. Reguła typu counter drop lub reject umieszczona przed portem często wyjaśnia rezultat.

Możesz monitorować pakiety za pomocą nft monitor trace, ale to polecenie generuje dużo danych na aktywnej maszynie. Zarezerwuj je na krótki okres diagnostyczny i filtruj ruch według adresu lub portu w tymczasowej regule. Następnie usuń tę regułę ze swoim uchwytem wyświetlonym przez nft -a list ruleset.

Nie zostawiaj reguły śledzenia lub logowania na serwerze eksponowanym. Może to wypełnić dzienniki lub dodać szum do diagnozy. Do wstępnej kontroli liczniki łańcucha i test z innego komputera są często wystarczające.

Aktywny zestaw reguł i trwały plik mogą się różnić

nft list ruleset odczytuje aktywny stan. Nie mówi, który serwis załadował reguły ani który plik zostanie podjęty po restarcie. Na Debianie i Ubuntu zazwyczaj spójrz na /etc/nftables.conf oraz stan usługi:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

Na dystrybucji, która korzysta z firewalld, UFW, Dockera lub narzędzi hostingowych, wiele komponentów może zapisywać reguły. Nie kopiuj zestawu reguł widocznego w poradniku do /etc/nftables.conf, jeśli inna usługa już nim zarządza. Najpierw zidentyfikuj menedżera zadeklarowanego przez swoją maszynę i ponownie przeczytaj reguły po jego przeładowaniu.

Reguły dodane przez polecenie w linii komend często znikają przy następnym restarcie lub ponownym załadowaniu usługi. Z drugiej strony, modyfikacja trwałego pliku nie zmienia nic, dopóki nie zostanie załadowana. To właśnie z tego powodu należy kontrolować obie strony przed stwierdzeniem, że port jest otwarty.

Zrób kopię zapasową i przetestuj przed zastosowaniem reguły

Zachowaj aktualny stan przed jakąkolwiek pisownią. Plik zapasowy powinien być czytelny tylko dla administratora:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Następnie przygotuj modyfikację w pliku tymczasowym. nft -c sprawdza składnię bez ładowania reguł:

sudo nft -c -f /etc/nftables.conf

To sprawdzenie nie dowodzi, że nowy zestaw reguł pozwoli Ci wejść. Zachowaj drugą sesję SSH połączoną, zastosuj plik w pierwszej, a następnie spróbuj nowego połączenia z innego terminala. Jeśli stracisz dostęp, sesja zapasowa pozwala na przywrócenie kopii zapasowej:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# W przypadku przerwy lub błędnej reguły:
sudo nft -f /root/nftables-before-change.nft

Unikaj flush ruleset uruchomionego samodzielnie na zdalnym serwerze. Usuwa on wszystkie bieżące reguły, zanim potwierdzisz plik zastępczy. Załaduj pełny i zweryfikowany plik, a następnie natychmiast sprawdź aktywny zestaw reguł.

Kontrole po modyfikacji

  • Przywróć sudo nft list ruleset i upewnij się, że oczekiwana tabelka i łańcuch są nadal obecne.
  • Przetestuj usługę z innej maszyny za pomocą rzeczywiście używanego portu.
  • Sprawdź sudo ss -lntup, jeśli port pozostaje niedostępny.
  • Zweryfikuj dziennik jądra za pomocą sudo journalctl -k -b, jeśli Twoje reguły logują odrzucone pakiety.
  • Po restarcie upewnij się, że usługa nftables prawidłowo ładuje trwały plik Twojej dystrybucji.

W przypadku prostych przypadków artykuł na temat UFW w systemie Linux jest bardziej odpowiedni. Jeśli musisz zdiagnozować dostępność usługi przed modyfikacją zapory, sprawdź także otwarte porty za pomocą ss. Dokumentacja nft(8) szczegółowo opisuje rodziny, łańcuchy i opcję -c.

Tux bada zaporę sieciową za pomocą lupy
Inspekcja aktywnych reguł zapory nftables w systemie Linux.
sudo apt update && sudo apt upgrade