En obetrodd VPN är tre separata gränser, inte en

«Jag litar inte på den här VPN:en» är vanligtvis tre påståenden klädda i en mening. De fjärranslutna jämlikarna i det nätet kan nå tjänster på din värd, operatören som driver tunneln kan observera trafik som passerar genom den, och klientprogramvaran du installerade kan ändra nätverkspolicyn på din maskin. Den övertygelse som är värd att korrigera är att en brandväggsregel, en virtuell maskin eller ett noggrant val av operativsystem svarar på alla tre. Varje åtgärd svarar på exakt en av dem.

Myten: en kontroll täcker hela risken

Det vanliga antagandet är att det att ansluta till ett obetroget nätverk är ett enda beslut med en enda åtgärd. Människor väljer den kontroll de redan litar på, tillämpar den och anser risken hanterad: brandväggen är på, arbetsytan är engångs, klienten kommer från en ansedd leverantör.

Dessa kontroller överlappar inte så som antagandet antyder. En brandvägg på värden begränsar vad en fjärransluten jämlike kan nå, och den gör ingenting mot en operatör som avslutar din TLS. En virtuell maskin separerar en arbetsyta från värdens filer, och den gör ingenting mot en klientkomponent som får konfigurera om nätverksstacken under båda. Att namnge den gräns som varje kontroll faktiskt skapar är hela övningen.

Att skilja dem åt berättar också vilken risk du har valt att acceptera. De flesta verkliga beslut mildrar en gräns och tolererar en annan, och det är okej så länge ändringsloggen säger vilken som är vilken.

Vad den fjärranslutna jämliken faktiskt kan nå

Börja med lyssnande tjänster. Tunnelgränssnittet som behandlas som brett betrott eftersom dess paket anlände krypterade är det vanliga misstaget, och det gör varje lokal lyssnare till ett möjligt mål för alla andra i det nätet. Kryptering skyddar ledningen mellan två ändpunkter; den säger ingenting om avsikten hos jämliken i andra änden.

ss -tulpn
sudo nft list ruleset
ip -br addr

Bind tjänster till den adress de behöver i stället för till varje gränssnitt, och tillåt bara de operationer som den godkända uppgiften kräver. Håll vidarebefordran, bryggning och applikationsproxy explicita, eftersom två nätverksanslutningar inte skapar en transitväg av sig själva, men en proxyregel kan absolut göra det.

En godkänd engångsarbetsyta minskar vad det fjärranslutna nätet kan nå, men bara när dess delningskonfiguration stämmer med påståendet. Delade mappar, urklippsintegration, autentiseringsagenter och hanteringskanaler korsar alla den gräns som arbetsytan skulle skapa. En etikett på arbetsytan bevisar ingenting om vilka av dem som är öppna.

NIST:s nolltillitsarkitektur anger principen bakom allt detta: enbart nätverksposition ger ingen implicit tillit. Resursautentisering har fortfarande en uppgift efter att tunneln har släppts in, och det har även frågan om vem andra som delar det nätet.

Vad operatören i vägen kan se

En VPN flyttar din trafik till en annan plats i vägen; den lägger inte till applikationskryptering. Om leverantören avslutar din TLS kan leverantören läsa det som din webbläsare annars skulle ha skyddat, och ingen lokal brandväggsregel ändrar det.

Behåll normal certifikatvalidering för den verkliga destinationen och förstå resolver- och metadatavägen, eftersom en DNS-fråga kan avslöja mer än nyttolasten som föregår den. Enbart metadata, det vill säga vilka adresser du kontaktade och när, svarar ofta på operatörens fråga utan något behov av att läsa innehåll. Därför är «trafiken är krypterad» och «trafiken är privat» olika påståenden.

Om den synligheten är oacceptabel för uppgiften är svaret en annan godkänd arkitektur i stället för mer lokal filtrering. Lokal filtrering kan inte ta bort en observatör från en väg där den fortfarande sitter.

Vad den lokala klienten får ändra

Detta är gränsen som folk missar, och det är den som gör de andra två irrelevanta. På Linux täcker CAP_NET_ADMIN gränssnittskonfiguration, brandväggsadministration och ruttändringar inom sin nätverkskontext. Programvara med den förmågan kan skriva om policyn du just skrev.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

Ett nätverksnamnrymd är en verklig gräns för nätverkstillstånd och en dålig för allt annat: den isolerar inte filsystemet eller autentiseringslagret. Behandla den som ett lager och inte som en behållare för hela problemet.

Skaffa klienten och dess konfiguration från en underhållen källa, granska den behörighet den begär och håll privilegierade komponenter under administratörskontroll. En virtuell maskin kan ingå i en kvalificerad utvärderingsgräns utan att bli tillstånd att köra ett oförklarat installationsprogram bredvid värdefulla autentiseringsuppgifter. Installationsprogrammet körs med vilken behörighet du än ger det, och den behörigheten är gränsen.

Skriv ner vilken gräns du accepterade

Avsluta med en mening som namnger fyra saker: den betrodda lokala koden, den tillåtna fjärråtkomsten, de skyddade applikationsdata och den operatörsrelation som kvarstår. Den meningen är värd mer än ett allmänt påstående att en VM, ett operativsystem eller en antivirusprodukt har gjort ett fientligt nätverk säkert.

Bekräfta sedan att den smala operationen fungerar och att den begärda nekandet fortfarande håller, även efter att tunneln faller. En gräns som bara finns medan tunneln är uppe är inte den gräns du dokumenterade.

Inget test bevisar att varje sårbarhet saknas, och en granskning som påstår motsatsen överdriver. Det ärliga resultatet namnger kvarstående risk och personen som accepterade den.