Reguły firewalla tylko dla NEW nie zamykają każdej ścieżki WAN

Odrzucanie nowych połączeń wychodzących na WAN wygląda jak polityka zamykająca się przy błędzie, ale jest węższą obietnicą, niż się wydaje. Pakiety należące do już istniejących przepływów jej nie pasują, podobnie jak wiele odpowiedzi. Tę lukę łatwo przeoczyć, bo reguła czyta się tak, jakby obejmowała interfejs, a nie jeden stan połączenia na nim. A czytanie dopasowania stanu jako wyroku to właśnie to, co tworzy fałszywe poczucie zamknięcia.

Stan to warunek dopasowania, nie wyrok

Śledzenie połączeń klasyfikuje pakiety według tego, co firewall już widział, a nie według tego, w co wierzy aplikacja. Przepływ zaobserwowany w obu kierunkach jest ustanowiony, a jego późniejsze pakiety pozostają ustanowione nawet wtedy, gdy trasa pod nim zmienia się z tunelu na zwykłe łącze wyjściowe. Odpowiedź na połączenie przychodzące również może być ruchem ustanowionym. Te pakiety nigdy nie stają się ponownie nowe.

Dlatego reguła ograniczona do nowych połączeń nie może dowieść, że każdy chroniony pakiet jest blokowany. Pozostawia inne stany temu, co robi z nimi reszta zestawu reguł, a to może być zezwolenie umieszczone wcześniej w łańcuchu.

Czytaj regułę w jej otoczeniu

Szerokie zezwolenie dla ruchu ustanowionego i powiązanego umieszczone przed blokadą przepuszcza pakiet, zanim blokada zostanie w ogóle oceniona. Usunięcie warunku stanu z późniejszej reguły tego nie zmieni, ponieważ ocena nigdy do niej nie dociera. O wyniku decyduje kolejność, a o tym, które pakiety docierają do tej kolejności, decyduje dopasowanie stanu.

Sprawdź obowiązujący zestaw reguł, a nie plik, który edytowałeś, wraz ze skokami do innych łańcuchów i wszystkim, co generuje platforma. Na routerze zarządzanym przez iptables wylistowanie łańcucha pokazuje definicje reguł, a łańcuchy, do których się odwołuje, również trzeba prześledzić. Rodzimy system nftables wymaga zbadania własnego zestawu reguł i priorytetów hooków, ponieważ firmware rzadko generuje identyczne łańcuchy.

Liczniki mówią, która reguła faktycznie zadziałała, i zwykle są bardziej informacyjne niż przechwycenie pakietów wykonane po decyzji. Reguła z licznikiem zero nie została osiągnięta, cokolwiek sugerowałaby jej pozycja.

Wyraź zakaz niezależnie od stanu

Jeśli grupa klientów nigdy nie ma dotrzeć do internetu poza tunelem, powiedz to wprost, zamiast przybliżać to jednym stanem. Reguła musi wybierać według źródła, wyjścia i celu bez zależności od stanu połączenia i musi stać tam, gdzie żadne wcześniejsze zezwolenie nie może jej obejść. Wtedy dostęp administracyjny i wyjątki dla sieci lokalnej dostają własne jawne reguły, więc intencja jest widoczna w polityce.

Wybór reject zamiast drop zmienia sposób, w jaki zawodzi dopasowany ruch, i nie powiększa zbioru pakietów wybieranych przez regułę. Odrzucone połączenie i ciche przekroczenie czasu to różne objawy wskazujące na ten sam wybór.

Polityka, która świadomie zezwala na odpowiedzi na dostęp zainicjowany zdalnie przez WAN, jest obronna. Trzeba ją tylko tak opisać, zamiast przedstawiać jako całkowitą izolację wyłącznie przez tunel.

Sprawdź, kto naprawdę jest w grupie

Przykład obejmuje przekazywany ruch IPv4 z jednego prefiksu przez jeden interfejs. Nie mówi nic o IPv6, drugim łączu wyjściowym ani o ruchu, który inicjuje sam router. Router działający jako resolver DNS wysyła własne zapytania w górę, a te w ogóle nie przechodzą przez łańcuch forward.

Potwierdź, że chronieni klienci nadal mają adresy w wybranym prefiksie, ponieważ urządzenie, które z niego wyszło, jest bezpośrednie przez przypadek, a nie z polityki. Rozszerzenie blokady na całą sieć LAN bez przeglądu projektu wyjątków również zwykle usuwa własną ścieżkę administracyjną.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Następnie przetestuj stary przepływ obok nowego. Nowa próba połączenia i już aktywna transmisja dwukierunkowa zachowują się inaczej pod tą regułą, i tylko przetestowanie obu pokazuje, jaką politykę naprawdę masz.