Slik tester du hva en nødutkobling dekker på en kompromittert vert

Kjør avbruddstesten, les resultatet for hvert lag og se hvor en nødutkobling stopper: den blokkerer ruter, ikke programvare som leser data før kryptering.

Slå på nødutkoblingen, ta tunnelserveren offline og se hva maskinen fortsatt gjør. Testen er verdt det fordi den skiller det brannmuren faktisk håndhever fra det du antok, og resultatene er smalere enn de fleste produktsider antyder. En nødutkobling styrer nettverksruter; den styrer ikke programvare som allerede kjører på enheten. Jeg kjører denne sekvensen på alle maskiner der klienten hevder å være fail-closed, og den tar rundt ti minutter.

Start ved klienten, ikke ved serveren

Håndhevelsespunktet er verten du sitter ved: operativsystemets brannmur, en hjelpetjeneste eller VPN-klientens egen driver. Det betyr noe fordi alt utkoblingen kan gjøre, er begrenset av det laget ser. Implementerer klienten blokkeringen med en rutingregel og et merke, kan alt med nok rettigheter legge til en egen regel; bruker den en kjernebrannmur-tabell, kan de samme rettighetene redigere tabellen. Krypteringens styrke spiller aldri inn her.

Først må det derfor fastslås hvem som eier policyen på denne enheten og hva den får overstyre. På en administrert arbeidsmaskin er svaret vanligvis organisasjonens endepunktagent, og en personlig VPN fjerner ikke disse mulighetene, uansett hvordan tunnelen er konfigurert.

Trinn én: bekreft blokkeringen på rutene du tror den dekker

Ta tunnelen ned i den fjerne enden i stedet for ved klienten, slik at klienten fortsatt tror den burde være tilkoblet. Prøv deretter 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 ha en klient som feiler raskt og rent, ikke en som henger til nettleserens tidsavbrudd. Henging betyr vanligvis at pakker droppes stille av en regel uten avvisning, noe som er akseptabelt, men det kan også bety at klienten har etterlatt en utdatert standardrute mot et dødt grensesnitt. Les rutingtabellen mens tunnelen er nede: en standardrute som fortsatt peker på tunneleenheten, og en brannmurregel som bare blokkerer nye utgående forbindelser, er to forskjellige tilstander, og bare én av dem er fail-closed.

Gjenta de samme kommandoene med klientens allow-LAN-valg på og av. Den bryteren er der de fleste overraskelsene bor, fordi den åpner en rute som resten av policyen var skrevet for å lukke.

Trinn to: sjekk DNS og IPv6 som separate ruter

Navneoppslag er gapet som overlever de fleste implementasjoner, fordi spørringen kan gå ut gjennom noe annet enn systemets resolver. Spør med et verktøy som ignorerer resolveroppsettet ditt, og sjekk 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 navnespørringene med tunnelen nede er resultatet du vil ha. Hvis den andre spørringen svarer, er en hardkodet resolveradresse tilgjengelig, og tunnelen er ikke den eneste veien ut av maskinen. Hvis bare v6-forespørselen lykkes, dekker policyen IPv4 og ignorerer IPv6, som er samme lekkasje i en annen adressefamilie.

Nettlesere gjør dette vanskeligere å lese utenfra, fordi en nettleser satt opp for DNS over HTTPS løser spørringen via en HTTPS-forespørsel: spørringen er bare blokkert så mye som port 443 til det endepunktet er. På en vert der policyen tillater det lokale subnettet, kan den forespørselen fortsatt nå en resolver på LAN.

Trinn tre: skill netteksponering fra endepunkteksponering

Nå delen ingen brannmurregel når. En nødutkobling blokkerer ruter ut av maskinen; den hindrer ikke programvare på maskinen i å lese data før de krypteres, og den hindrer ikke den programvaren i å bruke tunnelen legitimt. En keylogger, en ondsinnet utvidelse, en skjerm som er latt ulåst, en synkroniseringsklient med brede tillatelser: alle flytter informasjon over en forbindelse utkoblingen gjerne tillater.

Det samme gjelder overvåkingsprogramvare en arbeidsgiver har installert med vilje. Å blokkere ruter fjerner den ikke, og kjøp av en ny VPN-server er ikke reparasjonen, fordi eksponeringen ligger før tunnelen.

En utklippstavlebehandler som laster opp til en skykonto, viser poenget skarpt. Trafikken er kryptert, målet er tillatt, og nødutkoblingen rapporterer en sunn tilstand hele tiden.

Trinn fire: skriv påstanden testen din støtter

Etter avbruddstesten kan du oppgi konkrete fakta: hvilke applikasjoner som feilet, hvilke ruter som stoppet, hvordan DNS og IPv6 oppførte seg, og om blokkeringen holdt da tunnelen falt. Du kan ikke si at operativsystemet er rent, og du kan ikke si at en tjeneste i den fjerne enden holder innloggingen din privat.

Hold de to problemene atskilt og gi hver sin kontroll:

  • Nødutkobling: kravet til definert feil, verifisert med en avbruddstest du gjentar etter hver klientoppdatering.
  • Enhetstillit: støttede oppdateringer, endepunktbeskyttelse fra en pålitelig kilde, gjennomgang av uforklarte tillatelser og autentiseringsforespørsler.
  • Hendelse: følg prosessen til plattformen eller organisasjonen når kompromittering mistenkes; en ny server er ikke et oppryddingstrinn.
  • Offentliggjøring: når du ber om hjelp, ikke lim inn private nøkler eller hele diagnostiske arkiver, fordi logger og skjermbilder bærer de samme hemmelighetene som forbindelsen.

Kjør sekvensen igjen etter neste oppdatering, fordi en nødutkobling er konfigurasjon som flytter seg med versjoner. Testen er det eneste beviset på at atferden du regner med, fortsatt er atferden du får.

Relaterte artikler