En ubetrodd VPN er tre atskilte grenser, ikke én

«Jeg stoler ikke på denne VPN-en» er som regel tre utsagn som har kledd seg i én setning. De fjerne likemennene i det nettverket kan nå tjenester på vertsmaskinen din, operatøren som driver tunnelen kan observere trafikken som passerer gjennom den, og klientprogramvaren du installerte kan endre nettverkspolicyen på maskinen. Oppfatningen som fortjener korreksjon, er at en brannmurregel, en virtuell maskin eller et omhyggelig valg av operativsystem besvarer alle tre. Hvert enkelt tiltak besvarer nøyaktig ett av dem.

Myten: én kontroll dekker hele risikoen

Den vanlige antakelsen er at det å koble seg til et ubetrodd nettverk er én beslutning med én avbøtende handling. Folk velger kontrollen de allerede har tillit til, anvender den og regner risikoen som håndtert: brannmuren er slått på, arbeidsområdet er engangs, klienten kommer fra en anerkjent leverandør.

Disse kontrollene overlapper ikke på den måten antakelsen antyder. En brannmur på vertsmaskinen begrenser hva en fjern likemann kan nå, og den gjør ingenting mot en operatør som avslutter TLS-forbindelsen din. En virtuell maskin skiller et arbeidsområde fra vertsmaskinens filer, og den gjør ingenting mot en klientkomponent som har lov til å rekonfigurere nettverksstakken under begge. Å navngi grensen som hver kontroll faktisk skaper, er hele øvelsen.

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

Hva den fjerne likemannen faktisk kan nå

Begynn med tjenester som lytter. Tunneltilkoblingen som behandles som bredt betrodd fordi pakkene ankom kryptert, er den vanlige feilen, og den gjør hver lokal lytter til et mulig mål for alle andre i det nettverket. Kryptering beskytter ledningen mellom to endepunkter; den sier ingenting om hensikten til likemannen i den 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 som 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 samsvarer med påstanden. Delte mapper, utklippstavleintegrasjon, legitimasjonsagenter og administrasjonskanaler krysser alle grensen som arbeidsområdet skulle skape. En etikett på arbeidsområdet beviser ingenting om hvilke av dem som er åpne.

NISTs nulltillitsarkitektur formulerer prinsippet bak alt dette: nettverksposisjon alene gir ingen implisitt tillit. Ressursautentisering har fortsatt en oppgave etter at tunnelen er tillatt, og det samme har spørsmålet om hvem andre som deler det nettverket.

Hva operatøren i banen kan se

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

Behold vanlig 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. Bare metadata, altså hvilke adresser du kontaktet og når, besvarer ofte operatørens spørsmål uten noe behov for å lese innhold. Derfor er «trafikken er kryptert» og «trafikken er privat» forskjellige utsagn.

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 som den fortsatt sitter på.

Hva den lokale klienten har lov til å 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 innenfor sin nettverkskontekst. Programvare med denne 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 grense 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 en 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 virker 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 alle sårbarheter er fraværende, og en gjennomgang som påstår det motsatte, overdriver. Det ærlige resultatet navngir restrisikoen og personen som aksepterte den.