Et ubetrodd VPN er tre atskilte grenser, ikke én

«Jeg stoler ikke på denne VPN-en» er vanligvis tre påstander kledd i én setning. De fjerne likemennene på det nettverket kan nå tjenester på verten din, operatøren som driver tunnelen kan observere trafikk som passerer gjennom den, og klientprogramvaren du installerte kan endre nettverkspolicyen på maskinen din. Oppfatningen som er verdt å korrigere, er at en brannmurregel, en virtuell maskin eller et nøye valg av operativsystem svarer på alle tre. Hvert tiltak svarer på nøyaktig ett av dem.

Myten: én kontroll dekker hele risikoen

Den vanlige antakelsen er at det å bli med i et ubetrodd nettverk er én beslutning med én avbøtning. Folk velger kontrollen de allerede stoler på, bruker den og anser risikoen som håndtert: brannmuren er på, arbeidsområdet er engangs, klienten kommer fra en anerkjent leverandør.

Disse kontrollene overlapper ikke slik antakelsen antyder. En vertsbrannmur begrenser hva en fjern likemann kan nå, og den gjør ingenting mot en operatør som avslutter TLS-en din. En virtuell maskin skiller et arbeidsområde fra vertens filer, og den gjør ingenting mot en klientkomponent som får rekonfigurere nettverksstakken under begge. Å navngi grensen hver kontroll faktisk skaper, er hele øvelsen.

Å skille dem forteller deg også hvilken risiko du har valgt å akseptere. De fleste reelle beslutninger avbøter én grense og tåler en annen, og det er greit så lenge endringsloggen sier hvilken som er hvilken.

Hva den fjerne likemannen faktisk kan nå

Begynn med lyttende tjenester. Tunneltilkoblingsgrensesnittet som behandles som bredt betrodd fordi pakkene ankom kryptert, er den vanlige feilen, og den gjør enhver lokal lytter til et mulig mål for alle andre på det nettverket. Kryptering beskytter ledningen mellom to endepunkter; det sier ingenting om hensikten til likemannen i andre enden.

ss -tulpn
sudo nft list ruleset
ip -br addr

Bind tjenester til adressen de trenger i stedet for til hvert grensesnitt, og tillat bare operasjonene den godkjente oppgaven krever. Hold videresending, brokobling og applikasjonsproxy eksplisitt, fordi to nettverkstilkoblinger ikke skaper en transitvei av seg selv, men en proxyregel kan absolutt gjøre det.

Et godkjent engangsarbeidsområde reduserer hva det fjerne nettverket kan nå, men bare når delingskonfigurasjonen stemmer med påstanden. Delte mapper, utklippstavleintegrasjon, legitimasjonsagenter og administrasjonskanaler krysser alle grensen arbeidsområdet skulle skape. En arbeidsområdeetikett beviser ingenting om hvilke av dem som er åpne.

NISTs nulltillitsarkitektur angir prinsippet bak alt dette: nettverksplassering alene gir ikke implisitt tillit. Ressursautentisering har fortsatt en jobb etter at tunnelen er tillatt, og det har spørsmålet om hvem andre som deler det nettverket, også.

Hva operatøren i banen kan se

En VPN flytter trafikken din til et annet sted i banen; den legger ikke til applikasjonskryptering. Hvis leverandøren avslutter TLS-en din, kan leverandøren lese det nettleseren din ellers ville ha beskyttet, og ingen lokal brannmurregel endrer det.

Behold normal sertifikatvalidering for den virkelige destinasjonen og forstå resolver- og metadatabanen, fordi et DNS-oppslag kan avsløre mer enn nyttelasten som går foran det. Metadata alene, altså hvilke adresser du kontaktet og når, svarer ofte på operatørens spørsmål uten noe behov for å lese innhold. Derfor er «trafikken er kryptert» og «trafikken er privat» forskjellige påstander.

Hvis den synligheten er uakseptabel for oppgaven, er svaret en annen godkjent arkitektur i stedet for mer lokal filtrering. Lokal filtrering kan ikke fjerne en observatør fra en bane den fortsatt sitter på.

Hva den lokale klienten kan endre

Dette er grensen folk overser, og det er den som gjør de to andre irrelevante. På Linux dekker CAP_NET_ADMIN grensesnittkonfigurasjon, brannmuradministrasjon og ruteendringer i sin nettverkskontekst. Programvare med den egenskapen kan skrive om policyen du nettopp skrev.

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

Et nettverksnavnerom er en reell grense for nettverkstilstand og en dårlig en for alt annet: det isolerer ikke filsystemet eller legitimasjonslageret. Behandle det som ett lag og ikke som en beholder for hele problemet.

Skaff klienten og konfigurasjonen fra en vedlikeholdt kilde, gjennomgå myndigheten den ber om, og hold privilegerte komponenter under administratorkontroll. En virtuell maskin kan være del av en kvalifisert evalueringsgrense uten å bli tillatelse til å kjøre en uforklart installatør ved siden av verdifulle legitimasjoner. Installatøren kjører med hvilken myndighet du enn gir den, og den myndigheten er grensen.

Skriv ned hvilken grense du aksepterte

Avslutt med en setning som navngir fire ting: den betrodde lokale koden, den tillatte fjern tilgangen, de beskyttede applikasjonsdataene og operatørforholdet som gjenstår. Den setningen er mer verdt enn en generell påstand om at en VM, et operativsystem eller et antivirusprodukt har gjort et fiendtlig nettverk trygt.

Bekreft deretter at den smale operasjonen fungerer og at den påkrevde avvisningen fortsatt holder, også etter at tunnelen faller. En grense som bare finnes mens tunnelen er oppe, er ikke grensen du dokumenterte.

Ingen test beviser at hver sårbarhet er fraværende, og en gjennomgang som påstår det motsatte, overdriver. Det ærlige resultatet navngir restrisikoen og personen som aksepterte den.