Sådan tester du, hvad en nødafbryder dækker på en kompromitteret vært

Kør afbrydelsestesten, læs hvert lags resultat, og se hvor en nødafbryder stopper: den blokerer ruter, ikke software, der læser data før kryptering.

Slå nødafbryderen til, tag tunnelserveren offline, og se hvad maskinen stadig gør. Testen er værd at køre, fordi den skiller det, firewallen håndhæver, fra det, du antog den håndhævede, og resultaterne er snævrere, end de fleste produktsider antyder. En nødafbryder styrer netværksruter; den styrer ikke software, der allerede kører på enheden. Jeg kører denne sekvens på enhver maskine, hvor klienten hævder at være fail-closed, og den tager omkring ti minutter.

Start ved klienten, ikke ved serveren

Håndhævelsespunktet er den vært, du sidder ved: operativsystemets firewall, en hjælpetjeneste eller VPN-klientens egen driver. Det betyder noget, fordi alt, hvad afbryderen kan gøre, er begrænset af, hvad det lag kan se. Hvis klienten implementerer blokeringen med en routingregel plus et mærke, kan alt med tilstrækkelige privilegier tilføje sin egen regel; hvis den bruger en kernetabel, kan de samme privilegier redigere tabellen. Krypteringens styrke indgår aldrig i dette spørgsmål.

Så det første, der skal fastslås, er, hvem der ejer politikken på denne enhed, og hvad den må tilsidesætte. På en administreret arbejdsmaskine er svaret normalt organisationens endpoint-agent, og en personlig VPN fjerner ikke disse muligheder, uanset hvordan tunnelen er konfigureret.

Trin et: bekræft blokeringen på de ruter, du tror den dækker

Tag tunnelen ned i den fjerne ende i stedet for ved klienten, så klienten stadig tror, den burde være forbundet. Prøv derefter det, en person faktisk ville prøve:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Du vil have en klient, der fejler hurtigt og rent, ikke en, der hænger til browserens timeout. Hængning betyder normalt, at pakker droppes lydløst af en regel uden afvisning, hvilket er acceptabelt, men det kan også betyde, at klienten har efterladt en forældet standardrute mod en død grænseflade. Læs routingtabellen, mens tunnelen er nede: en standardrute, der stadig peger på tunneleenheden, og en firewallregel, der kun blokerer nye udgående forbindelser, er to forskellige tilstande, og kun én af dem er fail-closed.

Gentag de samme kommandoer med klientens allow-LAN-indstilling til og fra. Den kontakt er, hvor de fleste overraskelser bor, fordi den genåbner en rute, som resten af politikken var skrevet til at lukke.

Trin to: tjek DNS og IPv6 som separate ruter

Navneopløsning er det hul, der overlever de fleste implementeringer, fordi forespørgslen kan forlade maskinen gennem noget andet end systemets resolver. Spørg med et værktøj, der ignorerer din resolverkonfiguration, og tjek v6-siden samtidig:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Tomme svar på begge navneforespørgsler med tunnelen nede er det resultat, du vil have. Hvis den anden forespørgsel svarer, er en hårdkodet resolveradresse tilgængelig, og tunnelen er ikke den eneste vej ud af maskinen. Hvis kun v6-anmodningen lykkes, dækker politikken IPv4 og ignorerer IPv6, hvilket er den samme lækage i en anden adressefamilie.

Browsere gør det sværere at læse udefra, fordi en browser konfigureret til DNS over HTTPS opløser forespørgslen via en HTTPS-anmodning: forespørgslen er kun blokeret, så meget som port 443 til det endepunkt er. På en vært, hvor politikken tillader det lokale subnet, kan den anmodning stadig nå en resolver på LAN.

Trin tre: adskil netværkseksponering fra endpoint-eksponering

Nu den del, som ingen firewallregel når. En nødafbryder blokerer ruter ud af maskinen; den stopper ikke software på maskinen i at læse data, før de krypteres, og den stopper ikke den software i at bruge tunnelen legitimt. En keylogger, en ondsindet udvidelse, en skærm efterladt ulåst, en synkroniseringsklient med brede tilladelser: alle flytter de information over en forbindelse, som afbryderen med glæde tillader.

Det samme gælder overvågningssoftware, som en arbejdsgiver installerede med vilje. Blokering af ruter fjerner den ikke, og køb af en ny VPN-server er ikke reparationen, fordi eksponeringen ligger før tunnelen.

En udklipsholder, der uploader til en cloudkonto, viser det tydeligt. Trafikken er krypteret, destinationen er tilladt, og nødafbryderen rapporterer en sund tilstand hele tiden.

Trin fire: skriv den påstand, din test understøtter

Efter afbrydelsestesten kan du angive konkrete fakta: hvilke programmer fejlede, hvilke ruter stoppede, hvordan DNS og IPv6 opførte sig, og om blokeringen holdt, da tunnelen faldt. Du kan ikke sige, at operativsystemet er rent, og du kan ikke sige, at en tjeneste i den fjerne ende holder dit login privat.

Hold de to problemer adskilt, og giv hver sit eget kontrol:

  • Nødafbryder: det definerede fejlkrav, verificeret med en afbrydelsestest, du gentager efter hver klientopdatering.
  • Enhedstillid: understøttede opdateringer, endpoint-beskyttelse fra en pålidelig kilde, gennemgang af uforklarlige tilladelser og godkendelsesanmodninger.
  • Hændelse: følg platformens eller organisationens proces, når kompromittering mistænkes; en ny server er ikke et oprydningstrin.
  • Offentliggørelse: når du beder om hjælp, indsæt ikke private nøgler eller hele diagnostiske arkiver, fordi logs og skærmbilleder bærer de samme hemmeligheder som forbindelsen.

Kør sekvensen igen efter den næste opdatering, fordi en nødafbryder er konfiguration, der flytter sig med versioner. Testen er det eneste bevis for, at den adfærd, du regner med, stadig er den adfærd, du får.

Relaterede artikler