«En luota tähän VPN:ään» on yleensä kolme väitettä yhteen lauseeseen puettuna. Tuon verkon kaukaiset vertaiset voivat tavoittaa isäntäsi palveluja, tunnelia ylläpitävä operaattori voi nähdä sen läpi kulkevan liikenteen, ja asentamasi asiakasohjelmisto voi muuttaa koneesi verkkokäytäntöä. Uskomus, joka kannattaa korjata, on että palomuurisääntö, virtuaalikone tai huolellinen käyttöjärjestelmän valinta vastaa kaikkiin kolmeen. Jokainen toimenpide vastaa täsmälleen yhteen niistä.

Myytti: yksi valvonta kattaa koko riskin

Yleinen oletus on, että epäluotettavaan verkkoon liittyminen on yksi päätös ja yksi lievennys. Ihmiset valitsevat valvonnan, johon he jo luottavat, soveltavat sitä ja pitävät riskiä käsiteltynä: palomuuri on päällä, työtila on kertakäyttöinen, asiakasohjelma tulee arvostetulta toimittajalta.

Nämä valvonnat eivät mene päällekkäin niin kuin oletus antaa ymmärtää. Isännän palomuuri rajoittaa, mihin kaukainen vertainen pääsee, eikä tee mitään operaattorille, joka päättää TLS-yhteytesi. Virtuaalikone erottaa työtilan isäntäsi tiedostoista eikä tee mitään asiakasohjelman komponentille, jonka sallitaan määrittää molempien alla oleva verkkopino uudelleen. Sen rajan nimeäminen, jonka kukin valvonta todella luo, on koko harjoitus.

Niiden erottaminen kertoo myös, minkä riskin olet valinnut hyväksyä. Useimmat todelliset päätökset lieventävät yhtä rajaa ja sietävät toista, mikä on kunnossa niin kauan kuin muutoksen kirjaus kertoo, kumpi on kumpi.

Mihin kaukainen vertainen todella pääsee

Aloita kuuntelevista palveluista. Tunnelirajapinta, jota pidetään laajalti luotettavana siksi, että sen paketit saapuivat salattuina, on tavallinen virhe, ja se tekee jokaisesta paikallisesta kuuntelijasta mahdollisen kohteen kaikille muille siinä verkossa. Salaus suojaa kahden päätepisteen välisen johdon; se ei kerro mitään toisessa päässä olevan vertaisen aikomuksesta.

ss -tulpn
sudo nft list ruleset
ip -br addr

Sido palvelut tarvitsemaansa osoitteeseen sen sijaan että sitoisit ne joka rajapintaan, ja salli vain ne toiminnot, joita hyväksytty tehtävä edellyttää. Pidä edelleenlähetys, siltaaminen ja sovellusten välitys nimenomaisina, sillä kaksi verkkoliitäntää ei sinänsä luo läpikulkureittiä, mutta välityssääntö voi todellakin luoda.

Hyväksytty kertakäyttöinen työtila vähentää sitä, mihin kaukainen verkko pääsee, mutta vain kun sen jakokokoonpano vastaa väitettä. Jaetut kansiot, leikepöytäintegraatio, tunnistetietoagentit ja hallintakanavat ylittävät kaikki sen rajan, jonka työtilan oli tarkoitus luoda. Työtilan merkintä ei todista mitään siitä, mitkä niistä ovat auki.

NISTin nollaluottamuksen arkkitehtuuri esittää periaatteen kaiken tämän taustalla: pelkkä verkkosijainti ei anna implisiittistä luottamusta. Resurssien todennuksella on työtä vielä tunnelin hyväksymisen jälkeen, ja niin on myös kysymyksellä siitä, kuka muu jakaa tuon verkon.

Mitä polulla oleva operaattori voi nähdä

VPN siirtää liikenteesi toiseen paikkaan polulla; se ei lisää sovellussalausta. Jos palveluntarjoaja päättää TLS-yhteytesi, tarjoaja voi lukea sen, mitä selain olisi muuten suojannut, eikä mikään paikallinen palomuurisääntö muuta sitä.

Säilytä tavanomainen varmennekelpoisuuden tarkistus todelliselle kohteelle ja ymmärrä nimipalvelimen ja metatietojen polku, koska DNS-kysely voi paljastaa enemmän kuin sitä edeltävä hyötykuorma. Pelkät metatiedot, eli mitä osoitteita ja milloin tavoittelit, vastaavat usein operaattorin kysymykseen ilman mitään tarvetta lukea sisältöä. Siksi «liikenne on salattu» ja «liikenne on yksityistä» ovat eri väitteitä.

Jos tämä näkyvyys on tehtävälle mahdotonta hyväksyä, vastaus on toinen hyväksytty arkkitehtuuri eikä lisää paikallista suodatusta. Paikallinen suodatus ei voi poistaa tarkkailijaa polulta, jolla se yhä istuu.

Mitä paikallinen asiakasohjelma saa muuttaa

Tämä on raja, jonka ihmiset ohittavat, ja juuri se tekee kahdesta muusta merkityksettömiä. Linuxissa CAP_NET_ADMIN kattaa rajapintojen kokoonpanon, palomuurin hallinnan ja reittimuutokset verkkoympäristössään. Ohjelmisto, jolla on tuo kyky, voi kirjoittaa uudelleen juuri kirjoittamasi käytännön.

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

Verkkonimiavaruuden raja on todellinen verkkotilalle ja huono kaikelle muulle: se ei eristä tiedostojärjestelmää tai tunnistetietovarastoa. Käsittele sitä yhtenä kerroksena, älä koko ongelman säiliönä.

Hanki asiakasohjelma ja sen kokoonpano ylläpidetystä lähteestä, tarkista sen pyytämä valtuus ja pidä etuoikeutetut komponentit järjestelmänvalvojan valvonnassa. Virtuaalikone voi olla osa kelpuutettua arviointirajaa tulematta luvaksi ajaa selittämätöntä asennusohjelmaa arvokkaiden tunnistetietojen vieressä. Asennusohjelma toimii millä valtuudella tahansa annat sille, ja tuo valtuus on raja.

Kirjoita muistiin, minkä rajan hyväksyit

Päätä lauseeseen, joka nimeää neljä asiaa: luotettu paikallinen koodi, sallittu etäkäyttö, suojatut sovellustiedot ja jäljelle jäävä operaattorisuhde. Tuo lause on arvokkaampi kuin yleinen väite, että VM, käyttöjärjestelmä tai virustorjuntatuote teki vihamielisestä verkosta turvallisen.

Vahvista sitten, että kapea toiminto toimii ja vaadittu kielto pitää yhä, myös sen jälkeen kun tunneli kaatuu. Raja, joka on olemassa vain tunnelin ollessa pystyssä, ei ole se raja, jonka dokumentoit.

Mikään testi ei osoita, että kaikki haavoittuvuudet puuttuvat, ja päinvastaista väittävä katsaus liioittelee. Rehellinen tulos nimeää jäännösriskin ja sen hyväksyneen henkilön.

Aiheeseen liittyvät artikkelit