Inkomende melding op een VPN-server: lees het observatiepunt

Een server achter een VPN houdt zijn openbare service-ingangen bij, en mensen blijven ze vinden. Wat in de meldingswachtrij binnenkomt is niet één vondst maar drie mogelijke, en ze betekenen verschillende dingen. De eerste taak is een blootgestelde service scheiden van blootgestelde inloggegevens.

Doorloop de observatiepunten op volgorde. Stop wanneer het bewijs van categorie verandert, want de volgende fase beantwoordt een andere vraag.

Fase één: wat de capture werkelijk zag

Een packet capture legt vast wat op zijn eigen punt langs het pad zichtbaar was. Dat punt kan vóór een latere filterbeslissing liggen. Een gevangen packet bewijst dat het verkeer daar aankwam. Het bewijst niets over wat daarna gebeurde.

Let ook op de interface. Een capture op de openbare adapter en een capture binnen de tunnel beschrijven verschillende aankomstpunten, en een melding die het verkeerde punt noemt leidt tot de verkeerde conclusie.

Windows filtert ook op meerdere lagen van de stack, dus het nette model waarin het capture-gereedschap op laag twee zit en de firewall op laag drie overleeft de kennismaking met een echt product niet. Het overzicht van Windows Filtering Platform beschrijft filtering over stacklagen heen, en daarom moet de observatievolgorde worden vastgesteld in plaats van aangenomen.

Fase twee: wat het drop-record vaststelt

Een drop-record zegt dat een beleidsgrens dat packet heeft geweigerd. Het is sterk bewijs. Het is ook smal bewijs, want het dekt één beslissing bij één grens. Niets anders in de stack wordt erdoor beschreven.

Correleer op de tuple en de tijdstempel. Zelfde bron, zelfde bestemming, zelfde poort, binnen dezelfde seconde. Zonder die overeenkomst is een vergelijkbaar uitziende gebeurtenis in een ander log gewoon een andere gebeurtenis, en ze aan elkaar koppelen levert een verhaal op dat niemand kan verdedigen.

# 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

Een gesloten poort en een gedropt packet zien er van buiten identiek uit en in deze twee uitvoer volledig verschillend. Dat verschil is de hele reden om het lokale record te lezen.

Fase drie: wat de authenticatiegebeurtenis bewijst

Een authenticatiegebeurtenis zegt dat een component het verzoek ver genoeg heeft verwerkt om een resultaat vast te leggen. Het is de enige van de drie fasen die over identiteit spreekt, en het zegt niets over hoeveel packets ervoor aankwamen.

Lees de werkelijke context van de gebeurtenis. Een mislukte aanmelding voor een account dat niet bestaat is ruis van scannen. Een mislukte aanmelding voor een echt account met een plausibele bron is een andere prioriteit. Een geslaagde sessie is een heel andere incidentcategorie.

Let ook op de protocolnamen. RPC en RDP zijn aparte services met aparte poorten. Een detector die er één volgt, dekt de ander niet. Gereedschap dat netwerkactiviteit samenvat, vermeldt niet altijd welke van de twee de gebeurtenis produceerde.

Eén gecorreleerd monster verslaat een dashboard

Kies één geautoriseerde test, voer die met opzet uit en volg hem van begin tot eind: bestemmingsadres en interface, echt bronadres, servicepoort, effectief firewallprofiel en effectieve regel, en het bijbehorende serviceresultaat. Neem eventuele upstream-mapping of cloudfirewall in die keten mee, want een toestemmende regel daar kan een nette lokale regel overrulen.

Scheid daarna de twee verplichtingen. Als beheer alleen via VPN hoort te gaan, handhaaf dat dan op zowel het openbare pad als het tunnelpad en houd een goedgekeurde herstelroute aan. Een geweigerde poging monitoren is niet dezelfde taak als beslissen wat de server hoort te accepteren.

Een geografieregel of een geblokkeerd irrelevant protocol is geen vervanging voor het vinden van de waargenomen ingang en de beslissing die erop volgde. Een VPN is dat ook niet: uitgaand verkeer door een tunnel routeren documenteert niets over inkomende autorisatie.