En ubetroet VPN er tre adskilte grænser, ikke én

«Jeg stoler ikke på denne VPN» er normalt tre udsagn klædt i én sætning. De fjerne peers på det netværk kan nå tjenester på din vært, den operatør, der driver tunnelen, kan observere trafik, der passerer igennem, og den klientsoftware, du installerede, kan ændre din maskines netværkspolitik. Den overbevisning, der er værd at rette, er, at en firewallregel, en virtuel maskine eller et omhyggeligt valg af styresystem besvarer alle tre. Hver foranstaltning besvarer præcis én af dem.

Myten: én kontrol dækker hele risikoen

Den almindelige antagelse er, at det at tilslutte sig et ubetroet netværk er én beslutning med én afbødning. Folk vælger den kontrol, de allerede stoler på, anvender den og betragter risikoen som afsluttet: firewallen er tændt, arbejdsområdet er engangs, klienten kommer fra en velrenommeret leverandør.

Disse kontroller overlapper ikke, som antagelsen antyder. En vært-firewall begrænser, hvad en fjern peer kan nå, og den gør intet ved en operatør, der terminerer din TLS. En virtuel maskine adskiller et arbejdsområde fra dine værtfiler, og den gør intet ved en klientkomponent, der må omkonfigurere netværksstakken under begge. At navngive den grænse, hver kontrol faktisk skaber, er hele øvelsen.

At adskille dem fortæller dig også, hvilken risiko du har valgt at acceptere. De fleste rigtige beslutninger afbøder én grænse og tolererer en anden, hvilket er fint, så længe ændringsregistreringen siger hvilken, der er hvilken.

Hvad den fjerne peer faktisk kan nå

Begynd med lyttende tjenester. Tunelgrænsefladen, der behandles som bredt betroet, fordi dens pakker ankom krypteret, er den sædvanlige fejl, og den gør enhver lokal lytter til et muligt mål for alle andre på det netværk. Kryptering beskytter ledningen mellem to endepunkter; den siger intet om hensigten hos peeren i den anden ende.

ss -tulpn
sudo nft list ruleset
ip -br addr

Bind tjenester til den adresse, de har brug for, i stedet for til hver grænseflade, og tillad kun de handlinger, den godkendte opgave kræver. Hold videresending, brobygning og applikationsproxying eksplicitte, fordi to netværkstilslutninger ikke i sig selv skaber en transitvej, men en proxyregel kan bestemt.

Et godkendt engangsarbejdsområde reducerer, hvad det fjerne netværk kan nå, men kun når dets delingskonfiguration svarer til påstanden. Delte mapper, udklipsholderintegration, legitimationsagenter og administrationskanaler krydser alle den grænse, som arbejdsområdet skulle skabe. Et arbejdsområdemærke beviser intet om, hvilke af dem der er åbne.

NIST’s zero-trust-arkitektur angiver princippet bag alt dette: netværksplacering alene giver ikke implicit tillid. Ressourcegodkendelse har stadig en opgave, efter tunnelen er optaget, og det har spørgsmålet om, hvem der ellers deler det netværk, også.

Hvad operatøren i stien kan se

En VPN flytter din trafik til et andet sted på stien; den tilføjer ikke applikationskryptering. Hvis udbyderen terminerer din TLS, kan udbyderen læse, hvad din browser ellers ville have beskyttet, og ingen lokal firewallregel ændrer det.

Behold normal certifikatvalidering for den rigtige destination, og forstå resolver- og metadatastien, fordi en DNS-forespørgsel kan afsløre mere end den last, der går forud for den. Metadata alene, altså hvilke adresser du kontaktede og hvornår, besvarer ofte operatørens spørgsmål uden behov for at læse indhold. Derfor er «trafikken er krypteret» og «trafikken er privat» forskellige påstande.

Hvis den synlighed er uacceptabel for opgaven, er svaret en anden godkendt arkitektur i stedet for mere lokal filtrering. Lokal filtrering kan ikke fjerne en observatør fra en sti, den stadig sidder på.

Hvad den lokale klient må ændre

Det er den grænse, folk overser, og det er den, der gør de to andre uinteressante. På Linux dækker CAP_NET_ADMIN grænsefladekonfiguration, firewalladministration og ruteændringer i sin netværkskontekst. Software med den kapacitet kan omskrive den politik, du netop har skrevet.

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

Et netværksnavnerum er en reel grænse for netværkstilstand og en dårlig en for alt andet: det isolerer ikke filsystemet eller legitimationslageret. Behandl det som et lag i stedet for som en container for hele problemet.

Anskaff klienten og dens konfiguration fra en vedligeholdt kilde, gennemgå den myndighed, den anmoder om, og hold privilegerede komponenter under administrator kontrol. En virtuel maskine kan indgå i en kvalificeret evalueringsgrænse uden at blive tilladelse til at køre en uforklaret installatør ved siden af værdifulde legitimationsoplysninger. Installatøren kører med hvilken myndighed du end giver den, og den myndighed er grænsen.

Skriv ned, hvilken grænse du accepterede

Slut af med en sætning, der navngiver fire ting: den betroede lokale kode, den tilladte fjernadgang, de beskyttede applikationsdata og det operatørforhold, der resterer. Den sætning er mere værd end en generel påstand om, at en VM, et styresystem eller et antivirusprodukt har gjort et fjendtligt netværk sikkert.

Bekræft derefter, at den snævre operation virker, og at den krævede afvisning stadig holder, også efter tunnelen falder. En grænse, der kun findes, mens tunnelen er oppe, er ikke den grænse, du dokumenterede.

Ingen test beviser, at enhver sårbarhed er fraværende, og en gennemgang, der påstår andet, overdriver. Det ærlige output navngiver den resterende risiko og den person, der accepterede den.