Näin testaat, mitä hätäkytkin kattaa kompromisoidulla isännällä

Aja katkostesti, lue jokaisen kerroksen tulos ja katso, mihin hätäkytkin pysähtyy: se estää reittejä, ei ohjelmia, jotka lukevat tietoja ennen salausta.

Kytke hätäkytkin päälle, ota tunnelipalvelin pois verkosta ja katso, mitä kone vielä tekee. Testi kannattaa, koska se erottaa sen, mitä palomuuri tosiasiassa valvoo, siitä, mitä luulit sen valvovan, ja tulokset ovat kapeampia kuin useimmat tuotesivut antavat ymmärtää. Hätäkytkin hallitsee verkkoreittejä; se ei hallitse ohjelmia, jotka jo käyvät laitteella. Ajan tämän sarjan jokaisella koneella, jonka asiakas väittää olevan fail-closed, ja se kestää noin kymmenen minuuttia.

Aloita asiakkaasta, älä palvelimesta

Toteutuskohta on isäntä, jonka ääressä istut: käyttöjärjestelmän palomuuri, apupalvelu tai VPN-asiakkaan oma ajuri. Sillä on väliä, koska kaikki, mitä kytkin voi tehdä, rajoittuu siihen, mitä tuo kerros näkee. Jos asiakas toteuttaa eston reitityssäännöllä ja merkinnällä, mikä tahansa riittävillä oikeuksilla varustettu voi lisätä oman sääntönsä; jos se käyttää ytimen palomuuritaulua, samat oikeudet voivat muokata taulua. Salauksen vahvuus ei koskaan tule tähän kysymykseen.

Ensimmäinen selvitettävä asia on siis, kuka omistaa tämän laitteen käytännön ja mitä se saa ohittaa. Hallitulla työkoneella vastaus on yleensä organisaation päätepisteagentti, eikä henkilökohtainen VPN poista näitä ominaisuuksia, miten tunnelia tahansa on määritetty.

Ensimmäinen vaihe: vahvista esto reiteillä, joiden uskot sen kattavan

Laske tunneli alas kaukopäässä, älä asiakkaassa, jotta asiakas edelleen uskoo sen kuuluvan olla yhteydessä. Kokeile sitten sitä, mitä ihminen oikeasti kokeilisi:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Haluat asiakkaan, joka epäonnistuu nopeasti ja puhtaasti, et sellaista, joka roikkuu selaimen aikakatkaisuun asti. Riippuminen tarkoittaa yleensä, että säännöt pudottavat paketit hiljaa ilman hylkäystä, mikä on hyväksyttävää, mutta se voi myös tarkoittaa, että asiakas jätti vanhentuneen oletusreitin kuolleeseen liitäntään. Lue reititystaulukko, kun tunneli on alhaalla: oletusreitti, joka osoittaa yhä tunnelilaitteeseen, ja palomuurisääntö, joka estää vain uudet lähtevät yhteydet, ovat kaksi eri tilaa, ja vain toinen niistä on fail-closed.

Toista samat komennot asiakkaan allow-LAN-valinta päällä ja pois. Juuri tämä kytkin on useimpien yllätysten paikka, koska se avaa uudelleen reitin, jonka muu käytäntö oli kirjoitettu sulkemaan.

Toinen vaihe: tarkista DNS ja IPv6 erillisinä reitteinä

Nimien ratkaisu on aukko, joka selviää useimmista toteutuksista, koska kysely voi lähteä muuta kautta kuin järjestelmän ratkaisijan kautta. Kysy työkalulla, joka jättää ratkaisijamäärityksesi huomiotta, ja tarkista samalla v6-puoli:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Tyhjät vastaukset molempiin nimikyselyihin tunnelin ollessa alhaalla ovat se tulos, jonka haluat. Jos toinen kysely vastaa, kovakoodattu ratkaisijan osoite on tavoitettavissa eikä tunneli ole ainoa reitti ulos koneesta. Jos vain v6-pyyntö onnistuu, käytäntö kattaa IPv4:n ja jättää IPv6:n huomiotta, mikä on sama vuoto toisessa osoiteperheessä.

Selaimet tekevät tästä vaikeammin ulkopuolelta luettavaa, koska DNS over HTTPS:iin määritetty selain ratkaisee kyselyn HTTPS-pyynnöllä: kysely on estetty vain niin paljon kuin portti 443 kyseiseen päätepisteeseen on. Isännällä, jonka käytäntö sallii paikallisen aliverkon, tuo pyyntö voi yhä tavoittaa ratkaisijan lähiverkossa.

Kolmas vaihe: erota verkkoaltistus päätepistealtistuksesta

Nyt osa, johon mikään palomuurisääntö ei yllä. Hätäkytkin estää reittejä koneesta ulos; se ei estä koneella olevaa ohjelmaa lukemasta tietoja ennen salausta eikä estä samaa ohjelmaa käyttämästä tunnelia laillisesti. Näppäinloki, haitallinen laajennus, lukitsematta jätetty näyttö, laajoilla oikeuksilla varustettu synkronointiasiakas: kaikki ne siirtävät tietoa yhteyden yli, jonka kytkin mielellään sallii.

Sama koskee valvontaohjelmaa, jonka työnantaja asensi tarkoituksella. Reittien estäminen ei poista sitä, eikä uuden VPN-palvelimen ostaminen ole korjaus, koska altistus on tunnelia ylempänä.

Pilvitilille lataava leikepöytähallinta osoittaa asian terävästi. Liikenne on salattua, kohde on sallittu, ja hätäkytkin raportoi tervettä tilaa koko ajan.

Neljäs vaihe: kirjoita väite, jota testisi tukee

Katkostestin jälkeen voit esittää konkreettisia tosiasioita: mitkä sovellukset epäonnistuivat, mitkä reitit pysähtyivät, miten DNS ja IPv6 käyttäytyivät ja pitikö esto, kun tunneli kaatui. Et voi väittää käyttöjärjestelmän olevan puhdas, etkä sitä, että kaukopään palvelu pitää kirjautumisesi yksityisenä.

Pidä kaksi ongelmaa erillään ja anna kummallekin oma hallintansa:

  • Hätäkytkin: määritetty epäonnistumisvaatimus, joka on vahvistettu katkostestillä, jonka toistat jokaisen asiakaspäivityksen jälkeen.
  • Laitteen luottamus: tuetut päivitykset, päätepistesuojaus luotettavasta lähteestä, selittämättömien oikeuksien ja todennuspyyntöjen tarkistus.
  • Tapaus: noudata alustan tai organisaation prosessia, kun tietomurtoa epäillään; uusi palvelin ei ole siivousvaihe.
  • Paljastaminen: kun pyydät apua, älä liitä yksityisiä avaimia tai kokonaisia diagnostiikka-arkistoja, koska lokit ja kuvakaappaukset kantavat samat salaisuudet kuin yhteys.

Aja sarja uudelleen seuraavan päivityksen jälkeen, koska hätäkytkin on määritys, joka liikkuu versioiden mukana. Testi on ainoa todiste siitä, että käyttäytyminen, johon luotat, on yhä se, jonka saat.

Aiheeseen liittyvät artikkelit