Inkommande larm på en VPN-server: läs observationspunkten

En server bakom en VPN behåller sina offentliga tjänsteposter, och folk fortsätter att hitta dem. Det som kommer in i larmkön är inte ett fynd utan tre möjliga, och de betyder olika saker. Den första uppgiften är att skilja en exponerad tjänst från en exponerad inloggningsuppgift.

Gå igenom observationspunkterna i ordning. Stanna när beviset byter kategori, eftersom nästa steg svarar på en annan fråga.

Steg ett: vad fångsten faktiskt såg

En paketfångst registrerar det som var synligt vid dess egen punkt på vägen. Den punkten kan ligga före ett senare filtreringsbeslut. Ett fångat paket bevisar att trafiken kom dit. Det bevisar ingenting om vad som hände sedan.

Notera gränssnittet också. En fångst på den offentliga adaptern och en fångst inne i tunneln beskriver olika ankomstpunkter, och ett larm som anger fel punkt leder till fel slutsats.

Windows filtrerar också på flera lager i stacken, så den prydliga modellen där fångstverktyget sitter på lager två och brandväggen på lager tre överlever inte mötet med en verklig produkt. Översikten över Windows Filtering Platform beskriver filtrering över stacklager, och därför måste observationsordningen fastställas i stället för att antas.

Steg två: vad blockeringsposten fastställer

En blockeringspost säger att en policygräns avvisade det paketet. Det är starkt bevis. Det är också smalt bevis, eftersom det täcker ett beslut vid en gräns. Ingenting annat i stacken beskrivs av det.

Korrelera på tupeln och tidsstämpeln. Samma källa, samma mål, samma port, inom samma sekund. Utan den träffen är en liknande händelse i en annan logg bara en annan händelse, och att para ihop dem ger en historia som ingen kan försvara.

# 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

En stängd port och ett blockerat paket ser identiska ut utifrån och helt olika i dessa två utskrifter. Den skillnaden är hela skälet att läsa den lokala posten.

Steg tre: vad autentiseringshändelsen bevisar

En autentiseringshändelse säger att en komponent behandlade begäran tillräckligt långt för att registrera ett resultat. Den är den enda av de tre stegen som talar om identitet, och den säger ingenting om hur många paket som kom före den.

Läs händelsens faktiska sammanhang. En misslyckad inloggning för ett konto som inte finns är brus från skanning. En misslyckad inloggning för ett verkligt konto med en trovärdig källa är en annan prioritet. En lyckad session är en helt annan incidentkategori.

Håll koll på protokollnamnen också. RPC och RDP är separata tjänster med separata portar. En detektor som övervakar en av dem täcker inte den andra. Verktyg som sammanfattar nätverksaktivitet anger inte alltid vilken av de två som producerade händelsen.

Ett korrelerat prov slår en instrumentpanel

Välj ett auktoriserat test, kör det med avsikt och spåra det från början till slut: måladdress och gränssnitt, sann källadress, tjänsteport, gällande brandväggsprofil och regel, och det matchande tjänsteresultatet. Ta med eventuell överordnad mappning eller molnbrandvägg i den kedjan, eftersom en tillåtande regel där kan åsidosätta en prydlig lokal regel.

Skilj sedan de två åtagandena. Om administration ska ske endast via VPN, genomdriv det på både den offentliga vägen och tunnelvägen medan en godkänd återställningsväg behålls. Att övervaka ett avvisat försök är inte samma uppgift som att avgöra vad servern ska acceptera.

En geografiregel eller ett blockerat orelaterat protokoll ersätter inte att hitta den observerade posten och det beslut den fick. Inte heller en VPN: att dirigera utgående trafik genom en tunnel dokumenterar ingenting om inkommande auktorisering.