Så testar du vad en nödströmbrytare täcker på en komprometterad värd

Kör avbrottstestet, läs resultatet för varje lager och se var en nödströmbrytare stannar: den blockerar vägar, inte programvara som läser data före kryptering.

Slå på nödströmbrytaren, ta tunnelservern offline och se vad maskinen fortfarande gör. Testet är värt att köra eftersom det skiljer vad brandväggen faktiskt genomdriver från vad du antog, och resultaten är snävare än de flesta produktsidor antyder. En nödströmbrytare styr nätverksvägar; den styr inte programvara som redan körs på enheten. Jag kör den här sekvensen på varje maskin där klienten hävdar att den är fail-closed, och det tar ungefär tio minuter.

Börja vid klienten, inte vid servern

Genomdrivningspunkten är värden du sitter vid: operativsystemets brandvägg, en hjälptjänst eller VPN-klientens egen drivrutin. Det spelar roll eftersom allt brytaren kan göra begränsas av vad det lagret ser. Om klienten genomför blockeringen med en routingregel och en markering kan allt med tillräckliga privilegier lägga till en egen regel; om den använder en kärnbrandväggstabell kan samma privilegier redigera tabellen. Krypteringens styrka kommer aldrig in i den här frågan.

Först måste man alltså fastställa vem som äger policyn på enheten och vad den får åsidosätta. På en hanterad arbetsmaskin är svaret oftast organisationens slutpunktsagent, och ett personligt VPN tar inte bort de möjligheterna, hur tunneln än är konfigurerad.

Steg ett: bekräfta blockeringen på de vägar du tror den täcker

Ta ned tunneln i fjärränden i stället för vid klienten, så att klienten fortfarande tror att den borde vara ansluten. Prova sedan det en person faktiskt skulle prova:

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 vill ha en klient som misslyckas snabbt och rent, inte en som hänger till webbläsarens tidsgräns. Hängning betyder oftast att paket tystas av en regel utan avvisning, vilket är acceptabelt, men det kan också betyda att klienten lämnat en inaktuell standardväg mot ett dött gränssnitt. Läs routingtabellen medan tunneln är nere: en standardväg som fortfarande pekar på tunnelenheten och en brandväggsregel som bara blockerar nya utgående anslutningar är två olika tillstånd, och bara ett av dem är fail-closed.

Upprepa samma kommandon med klientens allow-LAN-alternativ på och av. Den brytaren är där de flesta överraskningarna bor, eftersom den öppnar en väg som resten av policyn var skriven för att stänga.

Steg två: kontrollera DNS och IPv6 som separata vägar

Namnuppslagning är gapet som överlever de flesta implementationer, eftersom frågan kan gå ut genom något annat än systemets resolver. Fråga med ett verktyg som ignorerar din resolverkonfiguration, och kontrollera v6-sidan samtidigt:

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

Tomma svar på båda namnfragorna med tunneln nere är resultatet du vill ha. Om den andra frågan svarar är en hårdkodad resolveradress nåbar och tunneln är inte den enda vägen ut ur maskinen. Om bara v6-begäran lyckas täcker policyn IPv4 och ignorerar IPv6, vilket är samma läcka i en annan adressfamilj.

Webbläsare gör det svårare att läsa utifrån, eftersom en webbläsare inställd för DNS över HTTPS löser frågan via en HTTPS-begäran: frågan är bara blockerad så mycket som port 443 till den slutpunkten är. På en värd där policyn tillåter det lokala subnätet kan den begäran fortfarande nå en resolver på LAN.

Steg tre: skilj nätverksexponering från slutpunktsexponering

Nu delen som ingen brandväggsregel når. En nödströmbrytare blockerar vägar ut ur maskinen; den hindrar inte programvara på maskinen från att läsa data innan de krypteras, och den hindrar inte den programvaran från att använda tunneln legitimt. En keylogger, ett skadligt tillägg, en skärm som lämnats olåst, en synkroniseringsklient med breda behörigheter: alla flyttar information över en anslutning som brytaren gärna tillåter.

Samma sak gäller övervakningsprogramvara som en arbetsgivare installerat med avsikt. Att blockera vägar tar inte bort den, och att köpa en ny VPN-server är inte reparationen, eftersom exponeringen ligger före tunneln.

En urklippshanterare som laddar upp till ett molnkonto visar det tydligt. Trafiken är krypterad, målet är tillåtet, och nödströmbrytaren rapporterar ett friskt tillstånd hela tiden.

Steg fyra: skriv påståendet som ditt test stöder

Efter avbrottstestet kan du ange konkreta fakta: vilka program som misslyckades, vilka vägar som stoppade, hur DNS och IPv6 betedde sig och om blockeringen höll när tunneln föll. Du kan inte säga att operativsystemet är rent, och inte att en tjänst i fjärränden håller din inloggning privat.

Håll de två problemen åtskilda och ge var och en sin egen kontroll:

  • Nödströmbrytare: det definierade felkravet, verifierat med ett avbrottstest du upprepar efter varje klientuppgradering.
  • Enhetsförtroende: stödda uppdateringar, slutpunktsskydd från en pålitlig källa, granskning av oförklarade behörigheter och autentiseringsbegäranden.
  • Incident: följ plattformens eller organisationens process vid misstänkt kompromettering; en ny server är inte ett städsteg.
  • Avslöjande: när du ber om hjälp, klistra inte in privata nycklar eller hela diagnostikarkiv, eftersom loggar och skärmbilder bär samma hemligheter som anslutningen.

Kör sekvensen igen efter nästa uppdatering, eftersom en nödströmbrytare är konfiguration som rör sig med versioner. Testet är det enda beviset på att beteendet du förlitar dig på fortfarande är det du får.

Relaterade artiklar