Innkomande varsel på ein VPN-server: les observasjonspunktet

Ein server bak ein VPN held på dei offentlege tenesteoppføringane sine, og folk held fram med å finne dei. Det som kjem inn i varselkøen er ikkje eitt funn, men tre moglege, og dei tyder ulike ting. Den første jobben er å skilje ein open teneste frå eit ope innloggingsbevis.

Gå gjennom observasjonspunkta i rekkjefølgje. Stopp når beviset skiftar kategori, fordi neste trinn svarar på eit anna spørsmål.

Trinn ein: kva fangsten faktisk såg

Ei pakkefangst registrerer det som var synleg på sitt eige punkt langs ruta. Det punktet kan liggje før ei seinare filtreringsavgjerd. Ein fanga pakke beviser at trafikken kom dit. Ho beviser ingenting om kva som skjedde etterpå.

Legg merke til grensesnittet òg. Ei fangst på den offentlege adapteren og ei fangst inne i tunnelen skildrar ulike ankomstpunkt, og eit varsel som viser til feil punkt leier til feil konklusjon.

Windows filtrerer òg på fleire lag i stakken, så den ryddige modellen der fangstverktøyet sit på lag to og brannmuren på lag tre overlever ikkje møtet med eit reelt produkt. Oversynet over Windows Filtering Platform skildrar filtrering på tvers av stakklag, og difor må observasjonsrekkjefølgja fastsetjast i staden for å takast for gitt.

Trinn to: kva blokkeringsposten fastslår

Ein blokkeringspost seier at ei policygrense avviste den pakka. Det er sterkt bevis. Det er òg smalt bevis, fordi det dekkjer éi avgjerd ved éi grense. Ingenting anna i stakken blir skildra av det.

Korreler på tuppelen og tidsstempelet. Same kjelde, same mål, same port, innanfor same sekund. Utan det treffet er ei liknande hending i ein annan logg berre ei anna hending, og å para dei gir ei 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

Ein lukka port og ei blokkert pakke ser identiske ut utanfrå og heilt ulike ut i desse to utskriftene. Den skilnaden er heile grunnen til å lese den lokale posten.

Trinn tre: kva autentiseringshendinga beviser

Ei autentiseringshending seier at ein komponent handsama førespurnaden langt nok til å registrere eit resultat. Ho er den einaste av dei tre trinna som seier noko om identitet, og ho seier ingenting om kor mange pakkar som kom før henne.

Les den faktiske konteksten til hendinga. Ei mislukka pålogging for ein konto som ikkje finst, er støy frå skanning. Ei mislukka pålogging for ein ekte konto med ei truverdig kjelde er ein annan prioritet. Ei vellukka økt er ein heilt annan hendingskategori.

Følg med på protokollnamna òg. RPC og RDP er separate tenester med separate portar. Ein detektor som overvakar éin av dei, dekkjer ikkje den andre. Verktøy som oppsummerer nettverksaktivitet oppgir ikkje alltid kva av dei to som produserte hendinga.

Eitt korrelert utval slår eit dashbord

Vel éin autorisert test, køyr han med vilje og spor han frå ende til annan: måladresse og grensesnitt, sann kjeldeadresse, tenesteport, effektiv brannmurprofil og regel, og det samsvarande tenesteresultatet. Ta med eventuell oppstraums kartlegging eller skybrannmur i den kjeda, fordi ein tillatande regel der kan overstyre ein ryddig lokal regel.

Skil så dei to forpliktingane. Viss administrasjon skal vere berre via VPN, handhev det på både den offentlege ruta og tunnelruta medan du held på ei godkjend gjenopprettingsrute. Å overvake eit avvist forsøk er ikkje same oppgåva som å avgjere kva serveren skal godta.

Ein geografiregel eller ein blokkert urelatert protokoll er ikkje ei erstatning for å finne den observerte oppføringa og avgjerda ho fekk. Det er ikkje ein VPN heller: å rute utgåande trafikk gjennom ein tunnel dokumenterer ingenting om innkomande autorisasjon.