Przychodzący alert na serwerze VPN: odczytaj punkt obserwacji

Serwer za VPN zachowuje swoje publiczne wpisy usług, a ludzie wciąż je znajdują. To, co trafia do kolejki alertów, nie jest jednym znaleziskiem, lecz trzema możliwymi, i znaczą one różne rzeczy. Pierwszym zadaniem jest oddzielenie wystawionej usługi od wystawionych danych logowania.

Przejdź przez punkty obserwacji po kolei. Zatrzymaj się, gdy dowód zmienia kategorię, bo następny etap odpowiada na inne pytanie.

Etap pierwszy: co przechwycenie faktycznie widziało

Przechwycenie pakietów rejestruje to, co było widoczne w jego własnym punkcie na ścieżce. Ten punkt może leżeć przed późniejszą decyzją filtrowania. Przechwycony pakiet dowodzi, że ruch tam dotarł. Nie dowodzi niczego o tym, co stało się później.

Zwróć uwagę także na interfejs. Przechwycenie na publicznym adapterze i przechwycenie wewnątrz tunelu opisują różne punkty przybycia, a alert cytujący niewłaściwy punkt prowadzi do błędnego wniosku.

Windows filtruje także na kilku warstwach stosu, więc schludny model, w którym narzędzie przechwytujące siedzi na warstwie drugiej, a zapora na trzeciej, nie przetrwa zetknięcia z realnym produktem. Przegląd Windows Filtering Platform opisuje filtrowanie w poprzek warstw stosu, dlatego kolejność obserwacji trzeba ustalić, a nie założyć.

Etap drugi: co ustala zapis odrzucenia

Zapis odrzucenia mówi, że granica polityki odrzuciła ten pakiet. To mocny dowód. Jest też wąski, bo obejmuje jedną decyzję na jednej granicy. Nic innego w stosie nie jest przez niego opisane.

Koreluj po krotce i znaczniku czasu. Ten sam adres źródłowy, ten sam adres docelowy, ten sam port, w tej samej sekundzie. Bez takiego dopasowania podobnie wyglądające zdarzenie w innym logu jest po prostu innym zdarzeniem, a łączenie ich daje historię, której nikt nie obroni.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

Zamknięty port i odrzucony pakiet wyglądają identycznie z zewnątrz i całkowicie różnie w tych dwóch wynikach. Ta różnica jest całym powodem, by czytać lokalny zapis.

Etap trzeci: co dowodzi zdarzenie uwierzytelnienia

Zdarzenie uwierzytelnienia mówi, że jakiś komponent przetworzył żądanie na tyle daleko, by zapisać wynik. Jest jedynym z trzech etapów, który mówi o tożsamości, i nie mówi nic o tym, ile pakietów dotarło wcześniej.

Czytaj rzeczywisty kontekst zdarzenia. Nieudane logowanie do konta, które nie istnieje, to szum ze skanowania. Nieudane logowanie do prawdziwego konta z wiarygodnego źródła to inny priorytet. Udana sesja to zupełnie inna kategoria incydentu.

Uważaj też na nazwy protokołów. RPC i RDP to osobne usługi z osobnymi portami. Detektor pilnujący jednego z nich nie obejmuje drugiego. Narzędzia podsumowujące aktywność sieciową nie zawsze podają, który z tych dwóch wytworzył zdarzenie.

Jedna skorelowana próbka bije pulpit

Wybierz jeden autoryzowany test, uruchom go celowo i prześledź od początku do końca: adres docelowy i interfejs, prawdziwy adres źródłowy, port usługi, obowiązujący profil i regułę zapory oraz pasujący wynik usługi. Uwzględnij w tym łańcuchu wszelkie mapowanie nadrzędne lub zaporę w chmurze, bo przepuszczająca reguła tam może nadpisać schludną regułę lokalną.

Potem rozdziel dwa obowiązki. Jeśli administracja ma być tylko przez VPN, egzekwuj to zarówno na ścieżce publicznej, jak i tunelowej, zachowując zatwierdzoną drogę odzyskiwania. Monitorowanie odrzuconej próby to nie to samo zadanie co decydowanie, co serwer powinien przyjmować.

Reguła geograficzna albo zablokowany niepowiązany protokół nie zastępuje znalezienia zaobserwowanego wpisu i decyzji, jaką otrzymał. VPN też nie: kierowanie ruchu wychodzącego przez tunel nie dokumentuje niczego o autoryzacji przychodzącej.