Příchozí upozornění na serveru VPN: přečtěte si pozorovací bod

Server za VPN si drží své veřejné položky služeb a lidé je stále nacházejí. Do fronty upozornění nepřichází jeden nález, ale tři možné, a znamenají různé věci. Prvním úkolem je oddělit vystavenou službu od vystavených přihlašovacích údajů.

Procházejte pozorovací body popořadě. Zastavte se, když důkazy změní kategorii, protože další fáze odpovídá na jinou otázku.

První fáze: co zachycení skutečně vidělo

Zachycení paketů zaznamenává, co bylo viditelné v jeho vlastním bodě na cestě. Ten bod může ležet před pozdějším rozhodnutím o filtrování. Zachycený paket dokazuje, že provoz tam dorazil. Nedokazuje nic o tom, co se stalo potom.

Všimněte si také rozhraní. Zachycení na veřejném adaptéru a zachycení uvnitř tunelu popisují různé body příchodu a upozornění, které cituje špatný z nich, vede ke špatnému závěru.

Windows filtruje také v několika vrstvách zásobníku, takže úhledný model, v němž nástroj zachycení sedí ve vrstvě dvě a firewall ve vrstvě tři, nepřežije střet s reálným produktem. Přehled Windows Filtering Platform popisuje filtrování napříč vrstvami zásobníku, a proto se pořadí pozorování musí stanovit, nikoli předpokládat.

Druhá fáze: co stanoví záznam o zahození

Záznam o zahození říká, že hranice zásad odmítla tento paket. Je to silný důkaz. Je to také úzký důkaz, protože pokrývá jedno rozhodnutí na jedné hranici. Nic jiného v zásobníku jím není popsáno.

Slučujte podle tuple a časového razítka. Stejný zdroj, stejný cíl, stejný port, ve stejné sekundě. Bez této shody je podobně vypadající událost v jiném logu prostě jiná událost a jejich spárování vytvoří příběh, který nikdo neobhájí.

# 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

Zavřený port a zahozený paket vypadají zvenčí stejně a v těchto dvou výstupech zcela jinak. Právě tento rozdíl je celý důvod číst místní záznam.

Třetí fáze: co dokazuje událost ověřování

Událost ověřování říká, že komponenta zpracovala požadavek natolik, aby zaznamenala výsledek. Je to jediná ze tří fází, která mluví o identitě, a neříká nic o tom, kolik paketů před ní dorazilo.

Čtěte skutečný kontext události. Neúspěšné přihlášení k účtu, který neexistuje, je šum ze skenování. Neúspěšné přihlášení k reálnému účtu z věrohodného zdroje je jiná priorita. Úspěšná relace je úplně jiná kategorie incidentu.

Sledujte i názvy protokolů. RPC a RDP jsou oddělené služby s oddělenými porty. Detektor, který sleduje jednu z nich, nepokrývá druhou. Nástroje, které shrnují síťovou aktivitu, ne vždy uvedou, která z těch dvou událost vytvořila.

Jeden sladěný vzorek porazí dashboard

Vyberte jeden povolený test, spusťte ho záměrně a projděte ho od začátku do konce: cílová adresa a rozhraní, skutečná zdrojová adresa, port služby, účinný profil a pravidlo firewallu a odpovídající výsledek služby. Zahrňte do toho řetězce jakékoli upstream mapování nebo cloudový firewall, protože povolující pravidlo tam může přebít úhledné místní.

Potom oddělte dvě povinnosti. Pokud má být správa pouze přes VPN, vynucujte to na veřejné i tunelové cestě a zároveň zachovejte schválenou cestu obnovy. Sledování odmítnutého pokusu není stejný úkol jako rozhodnutí, co má server přijímat.

Geografické pravidlo nebo zablokovaný nesouvisející protokol nenahrazuje nalezení pozorovaného vstupu a rozhodnutí, které dostal. Nenahrazuje ho ani VPN: směrování odchozího provozu tunelem nic nedokumentuje o příchozí autorizaci.