Nowa reguła UFW, stare połączenie: wygrywa stan ustanowiony

Dodanie reguły odmowy i widok trwającego otwartego pobierania to nie błąd UFW. Dodana reguła stoi po regułach, które już zaakceptowały ten przepływ, a ustanowione wcześniej połączenie nadal do nich pasuje. Naprawa oznacza wstawienie we właściwym miejscu i zrozumienie, co obiecują wcześniejsze reguły. Wąska wersja tej zmiany jest poniżej.

Decyduje kolejność, nie istnienie reguły

UFW to interfejs, który zapisuje reguły netfilter etapami: sekcja szkieletu uruchamiana przed regułami użytkownika, potem same reguły użytkownika, potem sekcja uruchamiana po nich. Standardowe reguły wcześniejsze akceptują ruch połączeń ustanowionych i powiązanych, a reguły te są oceniane przed wszystkim, co dodasz zwykłym allow lub deny. Dokumentacja poleceń UFW opisuje składnię wstawiania i numerowany widok stanu, od których zależy ta zmiana.

Ta kolejność wyjaśnia niespodziankę. Nowa reguła jest prawdziwa i znajduje się we właściwej tabeli, ale nie jest pierwszą decyzją, na którą trafia pakiet. Połączenie już śledzone jako ustanowione nigdy do niej nie dociera.

Do tego zadania używaj reguł route, ponieważ pakiet jest przekazywany przez bramę, a nie adresowany do jej własnych usług. Reguła wejściowa filtrowałaby niewłaściwy ruch i wyglądała, jakby nic nie robiła.

Wstaw ją nad szerokim zezwoleniem

Podejrzyj wstawienie przed zastosowaniem i potwierdź, że reguła nie istnieje już gdzie indziej na liście. Duplikowanie identycznej polityki czyni późniejsze usunięcie niejednoznacznym, a osoba, która usunie niewłaściwą kopię, nie zauważy tego tygodniami.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Jeśli podgląd pokazuje dokładnie jedną regułę w oczekiwanym miejscu, zastosuj to samo polecenie bez flagi dry-run. Pozycja 1 umieszcza ją nad szerszymi zezwoleniami użytkownika, a nie nad omówionymi wcześniej regułami szkieletu. Potwierdź, że nazwa interfejsu odpowiada urządzeniu tunelowemu na tej bramie, ponieważ reguła przypisana do interfejsu, którego już nie ma, będzie stać na liście i wyglądać poprawnie, nie pasując do niczego. Zmień nazwę odwołania do urządzenia przed zastosowaniem, a nie po nieudanym teście.

W tej regule nie ma portu docelowego, więc odmawia ona każdego portu TCP na tym adresie, a nie tylko HTTPS. Jeśli intencją jest jedna usługa, nazwij port; reguła szersza niż polityka to przyszły incydent, który czeka na pierwszego czytelnika.

Ogranicz źródło do jednego adresu tylko wtedy, gdy ten adres jest powiązany z zamierzoną tożsamością. Pula VPN z dynamicznym przydziałem może jutro dać ten sam adres innemu klientowi, a odmowa podąży za adresem, a nie za osobą.

Ustanowione przepływy przetrwają nową regułę

Śledzenie połączeń jest powodem, dla którego istniejąca sesja trwa. Gdy przepływ zostanie zapisany jako ustanowiony, wcześniejsze reguły akceptują jego pakiety, zanim twoja odmowa zostanie w ogóle sprawdzona, a transfer kończy się tak, jakby nic się nie zmieniło. Dlatego test z przeglądarką, która używa ponownie otwartego połączenia, nie mówi nic o nowej polityce. Odmowa może wydawać się bezużyteczna kilka minut po wdrożeniu i być całkowicie skuteczna dla następnego użytkownika, który się połączy.

Jeśli wymaganie obejmuje odcięcie ruchu na żywo, ta zmiana reguły użytkownika tego nie zapewni. Wycofanie śledzonego stanu to osobna czynność z własnym promieniem rażenia i należy do właściciela zapory, a nie do tego, kto dodał regułę. Wyczyszczenie wszystkich połączeń na bramie, aby jedna sesja zniknęła, to rodzaj poprawki, która rodzi drugi incydent.

Pamiętaj też o granicach. Ta reguła nic nie mówi o ICMP, UDP ani IPv6, więc udany ping nie jest dowodem, że odmowa zawiodła. Jeden adres IPv4 to też nie strona internetowa: nazwa może się rozwiązywać na kilka adresów, a pokryty jest tylko ten, który wymieniłeś.

Testuj na świeżym przepływie

Przeczytaj numerowane reguły użytkownika i skuteczny widok surowy, a następnie otwórz nowe połączenie z wybranego klienta:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Widok surowy ma znaczenie, ponieważ status pomija reguły szkieletu zapisane ręcznie, więc kolejność może wyglądać inaczej niż ta, którą egzekwuje jądro. Porównaj oba, zanim uznasz, że reguła jest w złym miejscu.

Następnie sprawdź dwie kontrole dowodzące, że reguła jest wąska, a nie szeroka: dozwolony cel z tego samego klienta nadal działa, a drugi klient nadal dociera do odmówionego celu, jeśli jego polityka na to pozwala. Odmowa, która psuje oba testy, jest zmianą polityki, a nie działaniem celowym.

Gdy test się skończy, usuń tylko dodaną regułę, powtarzając ją dokładnie. Jeśli polityka jest trwała, przekaż ją właścicielowi zapory wraz z tożsamością klienta, właścicielem celu i datą przeglądu, aby ponownie przydzielony adres tunelu nie pozostawił nieaktualnej odmowy.