Indgående advarsel på en VPN-server: læs observationspunktet

En server bag en VPN holder sine offentlige serviceposter, og folk bliver ved med at finde dem. Det, der ankommer i advarselskøen, er ikke ét fund, men tre mulige, og de betyder forskellige ting. Den første opgave er at skelne en eksponeret tjeneste fra en eksponeret legitimationsoplysning.

Gå observationspunkterne igennem i rækkefølge. Stop, når beviserne skifter kategori, fordi næste trin besvarer et andet spørgsmål.

Trin et: hvad optagelsen faktisk så

En pakkeoptagelse registrerer, hvad der var synligt på dens eget punkt på vejen. Det punkt kan ligge før en senere filtreringsbeslutning. En optaget pakke beviser, at trafikken nåede dertil. Den beviser intet om, hvad der skete bagefter.

Læg også mærke til grænsefladen. En optagelse på den offentlige adapter og en optagelse inde i tunnelen beskriver forskellige ankomstpunkter, og en advarsel, der citerer den forkerte, fører til den forkerte konklusion.

Windows filtrerer også på flere lag af stakken, så den pæne model, hvor optagelsesværktøjet sidder på lag to og firewallen på lag tre, overlever ikke mødet med et rigtigt produkt. Oversigten over Windows Filtering Platform beskriver filtrering på tværs af staklag, og derfor skal observationsrækkefølgen fastslås i stedet for antages.

Trin to: hvad drop-loggen fastslår

En drop-log siger, at en policygrænse afviste den pakke. Det er stærkt bevis. Det er også snævert bevis, fordi det dækker én beslutning ved én grænse. Intet andet i stakken beskrives af det.

Korrelér på tuplen og tidsstemplet. Samme kilde, samme destination, samme port, inden for samme sekund. Uden det match er en lignende hændelse i en anden log blot en anden hændelse, og parring af dem giver 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 droppet pakke ser identiske ud udefra og helt forskellige i disse to output. Den forskel er hele grunden til at læse den lokale log.

Trin tre: hvad godkendelseshændelsen beviser

En godkendelseshændelse siger, at en komponent behandlede anmodningen langt nok til at registrere et resultat. Det er det eneste af de tre trin, der taler om identitet, og det siger intet om, hvor mange pakker der ankom før det.

Læs hændelsens faktiske kontekst. En mislykket logon for en konto, der ikke findes, er støj fra scanning. En mislykket logon for en rigtig konto fra en plausibel kilde er en anden prioritet. En vellykket session er en helt anden hændelseskategori.

Hold også øje med protokolnavnene. RPC og RDP er separate tjenester med separate porte. En detektor, der overvåger den ene, dækker ikke den anden. Værktøjer, der opsummerer netværksaktivitet, siger ikke altid, hvilken af de to der skabte hændelsen.

Én korreleret prøve slår et dashboard

Vælg én autoriseret test, kør den med vilje, og følg den fra ende til anden: destinationsadresse og grænseflade, sand kildeadresse, serviceport, effektiv firewallprofil og -regel samt det matchende serviceresultat. Medtag enhver upstream-mapping eller cloud-firewall i den kæde, fordi en tilladende regel der kan tilsidesætte en pæn lokal en.

Adskil derefter de to forpligtelser. Hvis administrationen skal være VPN-only, så håndhæv det på både den offentlige vej og tunnelvejen, mens der bevares en godkendt gendannelsesrute. At overvåge et afvist forsøg er ikke samme opgave som at beslutte, hvad serveren skal acceptere.

En geografiregel eller en blokeret urelateret protokol erstatter ikke at finde den observerede indgang og den beslutning, den fik. Det gør en VPN heller ikke: at route udgående trafik gennem en tunnel dokumenterer intet om indgående autorisation.