Reguły wejścia SSH i VPN: czym naprawdę steruje lista dozwolonych

Połącz się raz, zanim zmienisz regułę, i zanotuj, czy klient wisi, czy jest od razu odrzucany. Ta jedna różnica mówi, która decyzja porzuciła pakiet, i oszczędza godzinę czytania plików polityki. Reszta drogi jest krótka: pakiet przekracza hak, pasuje do reguły i albo dociera do nasłuchującego, albo nie. Lista dozwolonych to tylko księgowość wokół tych trzech faktów.

Prześledź jedną próbę SSH do haka wejściowego

Klient wysyła SYN na adres hosta na porcie 22, a jądro decyduje, czy ten pakiet jest dla usługi lokalnej. Jeśli tak, uruchamia się ścieżka wejściowa i zestaw reguł przyjmuje pakiet albo go odrzuca. Cisza oznacza, że SYN zginął, zanim nasłuchujący go zobaczył, a szybka odmowa oznacza, że coś odpowiedziało resetem. To różne wyroki z różnych reguł i oba są prawomocnymi wynikami.

Następnie potwierdź nasłuchującego, bo żadna reguła nie uratuje usługi, której nie ma. Uruchom ss -ltnp i sprawdź, czy coś jest przypisane do oczekiwanego portu i rodziny adresów, a potem przeczytaj ssh -v na kliencie, żeby zobaczyć, gdzie się zatrzymuje.

Przekazywanie to odrębna decyzja

Na serwerze VPN ciekawszym hakiem jest forward, bo ruch klienta jest routowany przez maszynę, a nie jej dostarczany. Host, który uruchamia tylko własnego klienta VPN, potrzebuje znacznie mniejszego zestawu reguł niż ten, który przekazuje pakiety innych osób. Mieszanie obu projektów na jednej maszynie daje reguły, które wyglądają poprawnie i nic nie przepuszczają.

Zapisz politykę wewnętrzną jako osobne pytanie: które adresy klientów mogą dotrzeć do których celów przez tunel. Trzymaj ścieżkę administracyjną, na przykład SSH, na ścieżce wejściowej z własnym ograniczeniem źródła. Zbyt pobłażliwa reguła forward dodana podczas testów to klasyczny defekt, który przeżywa test, więc po zmianie przejrzyj cały zestaw reguł, a nie tę jedną linię, którą edytowałeś. Otwarcie nasłuchującego tunelu nie jest zgodą, by każdy podłączony klient administrował hostem.

Odrzucanie i odrzucenie to działania, nie polityki

Polityka łańcucha bazowego przyjmuje albo odrzuca i to jest cała lista wyborów, jak podaje dokumentacja nftables. Odrzucenie istnieje jako działanie reguły z wybraną odpowiedzią, dlatego zapisanie go jako polityki zawodzi zarówno na nftables, jak i na iptables. W praktyce drop nie daje klientowi żadnej informacji, a reject daje mu błąd, na którym może działać.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Czytaj ten szkic jako kształt decyzji, a nie plik do wklejenia, bo zakresy adresów są przykładami. Jawne reject na porcie SSH sprawia, że nieuprawniony klient zawodzi w sekundę zamiast czekać na przekroczenie limitu czasu, co skraca twoje własne debugowanie. Cisza zniechęca do przypadkowego skanowania i nie mówi uprawnionemu użytkownikowi absolutnie nic. Wybieraj dla każdej usługi i zapisuj dlaczego, inaczej następna osoba to cofnie.

Zachowaj ruch sterujący, którego naprawdę potrzebujesz

Blokowanie całego ICMP to popularne ustawienie domyślne, które psuje wykrywanie MTU ścieżki, a objawem jest połączenie, które się nawiązuje, a potem zastyga na większych pakietach. Wykrywanie sąsiadów w IPv6 zależy od własnych typów ICMPv6, a ich porzucenie psuje łącze, zanim zostanie sprawdzona jakakolwiek reguła TCP. Oba należą do listy dozwolonych jako nazwane zależności, a nie jako ogólne pozwolenia. Polityka, która po cichu psuje wykrywanie, jest gorsza od takiej, która dopuszcza trochę ruchu diagnostycznego.

Zezwalaj na stany established i related dla połączeń, które sam zainicjowałeś, i pozwól silnikowi stanów obsłużyć odpowiedzi. Potem potwierdź, że ścieżka odpowiedzi nie jest zablokowana dalej, bo ograniczenie tylko ruchu wychodzącego wyżej w łańcuchu daje ten sam limit czasu, który chciałeś zrzucić na host.

Udowodnij odtworzenie, zanim porzucisz starą ścieżkę

Trzymaj otwartą sesję konsoli, zastosuj zmianę i otwórz całkowicie nowe połączenie zarządzające z innego terminala. Istniejąca sesja niczego nie dowodzi, bo może przetrwać regułę blokującą każde nowe logowanie, co czyni ją najbardziej przekonującym fałszywym alarmem w pracy z zaporą. Jeśli system monitorowania sprawdza host, dodaj jego adres źródłowy przed zmianą, a nie po pierwszym alercie. Potem przetestuj jeden duży i jeden mały pakiet, żeby udowodnić, że wykrywanie nadal działa.

Dla usługi VPN powtórz to z klienta, który nigdy się nie łączył, bo wznowiona sesja może ponownie użyć stanu, który świeża musi wynegocjować. Zapisz dokładny zestaw reguł, który przeszedł, z sumą kontrolną lub kopią, żeby późniejszą edycję można było porównać, a nie zgadywać. Skonsultuj to z właścicielem kolejności reguł, bo wcześniejsza reguła po cichu wygrywa z tą, którą dodałeś.