Innkommende varsel på en VPN-server: les observasjonspunktet

En server bak en VPN beholder sine offentlige tjenesteoppføringer, og folk fortsetter å finne dem. Det som kommer inn i varselkøen er ikke ett funn, men tre mulige, og de betyr forskjellige ting. Den første jobben er å skille en eksponert tjeneste fra en eksponert legitimasjon.

Gå gjennom observasjonspunktene i rekkefølge. Stopp når beviset skifter kategori, fordi neste trinn svarer på et annet spørsmål.

Trinn én: hva fangsten faktisk så

En pakkefangst registrerer det som var synlig på sitt eget punkt langs ruten. Det punktet kan ligge før en senere filtreringsbeslutning. En fanget pakke beviser at trafikken kom dit. Den beviser ingenting om hva som skjedde etterpå.

Legg merke til grensesnittet også. En fangst på den offentlige adapteren og en fangst inne i tunnelen beskriver forskjellige ankomstpunkter, og et varsel som viser til feil punkt leder til feil konklusjon.

Windows filtrerer også på flere lag i stakken, så den ryddige modellen der fangstverktøyet sitter på lag to og brannmuren på lag tre overlever ikke møtet med et reelt produkt. Oversikten over Windows Filtering Platform beskriver filtrering på tvers av stakklag, og derfor må observasjonsrekkefølgen fastslås i stedet for å antas.

Trinn to: hva blokkeringsposten fastslår

En blokkeringspost sier at en policygrense avviste den pakken. Det er sterkt bevis. Det er også smalt bevis, fordi det dekker én beslutning ved én grense. Ingenting annet i stakken beskrives av det.

Korreler på tuppelen og tidsstempelet. Samme kilde, samme mål, samme port, innenfor samme sekund. Uten det treffet er en lignende hendelse i en annen logg bare en annen hendelse, og å pare dem gir en historie ingen kan forsvare.

# 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 lukket port og en blokkert pakke ser identiske ut utenfra og helt forskjellige ut i disse to utskriftene. Den forskjellen er hele grunnen til å lese den lokale posten.

Trinn tre: hva autentiseringshendelsen beviser

En autentiseringshendelse sier at en komponent behandlet forespørselen langt nok til å registrere et resultat. Den er det eneste av de tre trinnene som sier noe om identitet, og den sier ingenting om hvor mange pakker som kom før den.

Les hendelsens faktiske kontekst. En mislykket pålogging for en konto som ikke finnes, er støy fra skanning. En mislykket pålogging for en ekte konto med en plausibel kilde er en annen prioritet. En vellykket økt er en helt annen hendelseskategori.

Følg med på protokollnavnene også. RPC og RDP er separate tjenester med separate porter. En detektor som overvåker én av dem, dekker ikke den andre. Verktøy som oppsummerer nettverksaktivitet oppgir ikke alltid hvilken av de to som produserte hendelsen.

Ett korrelert utvalg slår et dashbord

Velg én autorisert test, kjør den med vilje og spor den ende til ende: måladresse og grensesnitt, sann kildeadresse, tjenesteport, effektiv brannmurprofil og regel, og det samsvarende tjenesteresultatet. Ta med eventuell oppstrøms kartlegging eller skybrannmur i den kjeden, fordi en tillatende regel der kan overstyre en ryddig lokal regel.

Skill så de to forpliktelsene. Hvis administrasjon skal være kun via VPN, håndhev det på både den offentlige ruten og tunnelruten mens du beholder en godkjent gjenopprettingsrute. Å overvåke et avvist forsøk er ikke samme oppgave som å avgjøre hva serveren skal godta.

En geografiregel eller en blokkert urelatert protokoll er ikke en erstatning for å finne den observerte oppføringen og beslutningen den fikk. Det er ikke en VPN heller: å rute utgående trafikk gjennom en tunnel dokumenterer ingenting om innkommende autorisasjon.