Un VPN nesigur sunt trei granițe separate, nu una

„Nu am încredere în acest VPN” sunt de obicei trei afirmații îmbrăcate într-o singură propoziție. Parții de la distanță din acea rețea pot ajunge la servicii de pe gazda dvs., operatorul care rulează tunelul poate observa traficul care trece prin el, iar software-ul client pe care l-ați instalat poate schimba politica de rețea a mașinii dvs. Convingerea care merită corectată este că o regulă de firewall, o mașină virtuală sau o alegere atentă a sistemului de operare răspund la toate trei. Fiecare măsură răspunde exact la una dintre ele.

Mitul: un singur control acoperă întregul risc

Presupunerea obișnuită este că intrarea într-o rețea nesigură este o singură decizie cu o singură atenuare. Oamenii aleg controlul în care au deja încredere, îl aplică și consideră riscul închis: firewallul este pornit, spațiul de lucru este de unică folosință, clientul vine de la un furnizor respectabil.

Aceste controale nu se suprapun așa cum sugerează presupunerea. Un firewall pe gazdă limitează la ce poate ajunge un part de la distanță și nu face nimic împotriva unui operator care vă termină TLS-ul. O mașină virtuală separă un spațiu de lucru de fișierele gazdei și nu face nimic împotriva unei componente client căreia i se permite să reconfigureze stiva de rețea de sub ambele. A numi granița pe care fiecare control o creează efectiv este tot exercițiul.

Separarea lor vă spune și ce risc ați ales să acceptați. Majoritatea deciziilor reale atenuează o graniță și tolerează alta, ceea ce este în regulă atâta timp cât registrul modificării spune care este care.

La ce poate ajunge efectiv partul de la distanță

Începeți cu serviciile care ascultă. Interfața de tunel tratată ca larg de încredere pentru că pachetele ei au sosit criptate este greșeala obișnuită, și transformă fiecare ascultător local într-o țintă candidată pentru oricine altcineva din acea rețea. Criptarea protejează firul dintre două capete; nu spune nimic despre intenția partului de la celălalt capăt.

ss -tulpn
sudo nft list ruleset
ip -br addr

Legați serviciile de adresa de care au nevoie în loc de fiecare interfață, și permiteți doar operațiile cerute de sarcina aprobată. Păstrați explicite redirecționarea, puntea și proxy-ul de aplicații, pentru că două atașamente de rețea nu creează singure o cale de tranzit, dar o regulă de proxy poate cu siguranță.

Un spațiu de lucru de unică folosință aprobat reduce la ce poate ajunge rețeaua de la distanță, dar numai când configurația sa de partajare corespunde afirmației. Folderele partajate, integrarea clipboardului, agenții de acreditări și canalele de administrare traversează toate granița pe care spațiul de lucru trebuia să o creeze. Eticheta spațiului de lucru nu dovedește nimic despre care dintre ele sunt deschise.

Arhitectura zero-trust a NIST enunță principiul din spatele tuturor acestora: numai locația în rețea nu acordă încredere implicită. Autentificarea resurselor are încă de lucru după ce tunelul este admis, la fel și întrebarea cine altcineva partajează acea rețea.

Ce poate vedea operatorul din cale

Un VPN mută traficul dvs. în alt loc pe cale; nu adaugă criptare de aplicație. Dacă furnizorul vă termină TLS-ul, poate citi ce browserul dvs. ar fi protejat altfel, și nicio regulă de firewall locală nu schimbă asta.

Păstrați validarea normală a certificatelor pentru destinația reală și înțelegeți calea resolverului și a metadatelor, pentru că o interogare DNS poate dezvălui mai mult decât încărcătura care o precede. Numai metadatele, adică ce adrese ați contactat și când, răspund adesea la întrebarea operatorului fără nicio nevoie de a citi conținut. De aceea „traficul este criptat” și „traficul este privat” sunt afirmații diferite.

Dacă acea vizibilitate este inacceptabilă pentru sarcină, răspunsul este o altă arhitectură aprobată, nu mai multă filtrare locală. Filtrarea locală nu poate elimina un observator de pe o cale pe care încă se află.

Ce poate schimba clientul local

Aceasta este granița pe care oamenii o ratează, și ea este cea care le face pe celelalte două irelevante. Pe Linux, CAP_NET_ADMIN acoperă configurarea interfețelor, administrarea firewallului și modificările de rute în contextul său de rețea. Un software care deține această capacitate poate rescrie politica pe care tocmai ați scris-o.

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

Un spațiu de nume de rețea este o graniță reală pentru starea rețelei și una slabă pentru orice altceva: nu izolează sistemul de fișiere sau depozitul de acreditări. Tratați-l ca un strat, nu ca un container pentru întreaga problemă.

Obțineți clientul și configurația lui dintr-o sursă întreținută, examinați autoritatea pe care o solicită și țineți componentele privilegiate sub controlul administratorului. O mașină virtuală poate face parte dintr-o graniță de evaluare calificată fără a deveni permisiunea de a rula un instalator neexplicat lângă acreditări valoroase. Instalatorul rulează cu orice autoritate îi acordați, și acea autoritate este granița.

Scrieți ce graniță ați acceptat

Încheiați cu o propoziție care numește patru lucruri: codul local de încredere, accesul de la distanță permis, datele aplicației protejate și relația cu operatorul care rămâne. Acea propoziție valorează mai mult decât o afirmație generală că un VM, un sistem de operare sau un produs antivirus au făcut o rețea ostilă sigură.

Apoi confirmați că operația îngustă funcționează și că refuzul cerut încă rezistă, inclusiv după ce tunelul cade. O graniță care există doar cât timp tunelul este ridicat nu este granița pe care ați documentat-o.

Niciun test nu dovedește că fiecare vulnerabilitate este absentă, iar o verificare care afirmă contrariul exagerează. Rezultatul onest numește riscul rezidual și persoana care l-a acceptat.