Zmiana reguły zapory nie działa: kolejność reguł i stan połączenia

Zmieniłeś regułę, ponownie wczytałeś zestaw reguł, a tunel zachowuje się dokładnie tak jak wcześniej. Ten wynik ma dwie częste przyczyny i wymagają one różnych testów. Albo nowa reguła stoi po wcześniejszej regule, która już przyjęła pakiet, albo obserwowana wymiana to śledzone połączenie, którego zmiana nigdy nie ocenia ponownie. Reguła w pliku wyraża intencję; o losie pakietu decyduje aktywna ścieżka, którą napotyka. Przejdź kolejno przez poniższe kontrole i przez cały czas trzymaj otwartą drogę powrotną.

Kolejność reguł i stan połączenia to różne usterki

Uporządkowane łańcuchy są oceniane od góry do dołu, a pierwsza reguła, która osiągnie ostateczny werdykt, kończy przejście przez ten łańcuch. Umieść szeroką akceptację nad starannie napisaną regułą blokady, a reguła blokady staje się dokumentacją: jest w zestawie, jej licznik wynosi zero i żaden pakiet nigdy do niej nie dotrze. Ten sam tekst zastosowany do innego łańcucha też niczego nie dowodzi. W nftables łańcuchy bazowe podłączają się do hooków według priorytetów, więc akceptacja w jednym łańcuchu nie przeszkadza innemu łańcuchowi na innym hooku lub priorytecie zobaczyć tego samego pakietu.

Śledzenie połączeń tworzy drugi objaw, a z zewnątrz wygląda identycznie. Gdy przepływ jest już w tabeli stanów, akceptacja dla established-or-related blisko szczytu łańcucha wraca, zanim nowa reguła zostanie w ogóle rozpatrzona. Mapowania NAT mają tę samą właściwość: tłumaczenie zostało ustalone, gdy przepływ się zaczynał, więc edytowana reguła postrouting nie przepisuje sesji, która już trwa. Dlatego zmiana wygląda na działającą o 09:00 dla nowego połączenia i wygląda na nic nierobiącą dla sesji, którą ktoś otworzył o 08:55.

Grupy zabezpieczeń w chmurze dodają trzeci model, który łapie osoby uczące się na iptables. Ich reguły przychodzące to lista zezwoleń oceniana jako zbiór, a nie jako przejście po pierwszym dopasowaniu, są stanowe, a usunięcie reguły zezwolenia nie kończy przepływów już śledzonych. Zakładanie semantyki pierwszego dopasowania na platformie, która jej nie ma, prowadzi do pewnych siebie, błędnych wniosków.

Czytaj aktywny zestaw reguł, a nie plik, który edytowałeś

Zacznij od tego, co jądro właśnie egzekwuje. Zapisana konfiguracja, która nigdy nie została zastosowana, wyjaśnia zaskakująco wiele niezmienionych zachowań, a jej wykluczenie kosztuje jedno polecenie:

nft list ruleset
iptables-save

Potem zapytaj, czy twoja reguła jest w ogóle osiągana. Liczniki pakietów odpowiadają na to wprost i odpowiadają lepiej niż jakiekolwiek rozumowanie o intencji:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Reguła blokady z zerem pakietów po rzeczywistej próbie testu nie jest problemem polityki, to problem pozycji. Przesunięcie jej to zmiana jednej linii, a składnia jest dokładnie tym, co spowodowało pierwotny błąd. W iptables -I wstawia, a -A dodaje na końcu; w nftables insert umieszcza regułę na początku łańcucha, a add dodaje na końcu. Gdy reguła musi wygrać, powiedz to wprost, zamiast ufać kolejności, która przypadkiem została wczytana.

Udowodnij, czy przepływ jest śledzony

Zanim obwinisz regułę, sprawdź, czy ruch jest w ogóle śledzonym połączeniem. Zapytaj tabelę stanów o konkretny przepływ, zamiast wylewać ją całą:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Lista pokazuje stan i pozostały limit czasu, i tak odróżniasz sesję ustaloną od świeżej próby; tryb zdarzeń wypisuje aktualizacje na bieżąco, co jest przydatne podczas ponownego łączenia klienta. Jeśli przepływ jest obecny w stanie ustalonym, zanim czegokolwiek dotknąłeś, żadna edycja reguł filtra nie zmieni jego losu. To nie błąd zapory, to umowa filtrowania stanowego.

Oprzyj się pokusie wyczyszczenia całej tabeli na bramie produkcyjnej. conntrack -F jest dostępne, a ono niszczy także każdy śledzony przepływ na maszynie, w tym sesję zarządzania, z której pracujesz, i tunel, który niesie twoją powłokę. Pojedyncze wpisy można usuwać, gdy naprawdę trzeba, ale nowy przepływ z nowego portu źródłowego jest zwykle czystszym eksperymentem.

Niektóre ścieżki nie są śledzone i zachowują się odwrotnie. Ruch oznaczony jako notrack w tabeli raw, niektóre tunele omijające zwykłe hooki i routing asymetryczny, który dzieli przepływ między dwie bramy, wszystkie dają pakiety oceniane pojedynczo albo stan, który nigdy nie powstaje po obu stronach. Jeśli liczniki ruszają się przy każdym pakiecie, podejrzewaj taką ścieżkę, zanim podejrzysz kolejność.

Testuj z nowego przepływu z drogą powrotną

Zanim przetestujesz regułę, która może odciąć dostęp zdalny, ustanów drogę odzyskiwania: konsolę dostawcy, konsolę szeregową, adres zarządzania poza pasmem lub drugi interfejs, którego reguła nie może trafić. Timer wycofania to rozsądny towarzysz, ponieważ przywróci poprzedni zestaw reguł, nawet jeśli twoja sesja umrze w połowie testu.

Następnie testuj wymianą, której stan nie mógł już pokryć. Rozłącz i ponownie połącz klienta, aby powstała nowa piątka, i obserwuj oba końce, gdy to się dzieje:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Wykonaj test w obu kierunkach. Reguła blokująca nowy przychodzący uścisk dłoni może nadal przepuszczać ścieżkę odpowiedzi, albo odwrotnie, a wynik jednokierunkowy to zwykły powód, dla którego blokada działa tylko połowicznie. Połącz się jeszcze raz po teście, aby potwierdzić stan ustalony, i sprawdź, czy legalny dostęp administracyjny przetrwał; reguła napisana dla jednego portu ma zwyczaj pasować do szerszego zakresu, niż zamierzano.

Zapisz cel i pozycję razem z regułą

Reguła bez zapisanego celu to reguła, której nikt nie odważy się usunąć. Przy każdym wpisie blokady trzymaj przepływ, który chroni, łańcuch i hook, w którym żyje, pozycję, którą musi utrzymać względem szerszych akceptacji, oraz test, który to udowodnił. Gdy ktoś pół roku później zmieni otaczający zestaw reguł, ta notatka będzie jedynym ostrzeżeniem, że pozycja była zamierzona.

Zanim zamkniesz zmianę, potwierdź cztery rzeczy: działający zestaw reguł odpowiada plikowi, nowa reguła ma po świeżej próbie liczniki różne od zera, kierunek odwrotny i dostęp administracyjny nadal działają, a ty połączyłeś się raz ponownie, aby udowodnić stan ustalony, a nie stan sesji starszej niż zmiana. Jeśli cokolwiek z tego nie zostało zweryfikowane, zmiana nie jest skończona, cokolwiek robi tunel.