Korleis teste kva ein naudbrytar dekkjer på ein kompromittert vert

Køyr avbrotstesten, les resultatet for kvart lag og sjå kvar ein naudbrytar stoppar: han blokkerer ruter, ikkje programvare som les data før kryptering.

Slå på naudbrytaren, ta tunnelserveren offline og sjå kva maskina framleis gjer. Testen er verdt det fordi han skil det brannmuren faktisk handhevar frå det du antok, og resultata er smalare enn dei fleste produktsidene antydar. Ein naudbrytar styrer nettverksruter; han styrer ikkje programvare som alt køyrer på eininga. Eg køyrer denne sekvensen på alle maskiner der klienten hevdar å vere fail-closed, og det tek om lag ti minutt.

Start ved klienten, ikkje ved serveren

Handhevingspunktet er verten du sit ved: brannmuren til operativsystemet, ein hjelpeteneste eller drivaren til VPN-klienten sjølv. Det tel fordi alt naudbrytaren kan gjere, er avgrensa av det det laget ser. Implementerer klienten blokkeringa med ein ruteringsregel og eit merke, kan alt med nok rettar leggje til sin eigen regel; brukar han ein kjernebrannmur-tabell, kan dei same rettane redigere tabellen. Styrken til krypteringa kjem aldri inn her.

Fyrst må ein derfor fastslå kven som eig policyen på denne eininga og kva han får overstyre. På ei styrt arbeidsmaskin er svaret vanlegvis endepunktagenten til organisasjonen, og ein personleg VPN fjernar ikkje dei moglegheitene, uansett korleis tunnelen er sett opp.

Steg éin: stadfest blokkeringa på rutene du trur ho dekkjer

Ta tunnelen ned i den fjerne enden i staden for ved klienten, slik at klienten framleis trur han burde vere tilkopla. Prøv deretter det ein person faktisk ville prøve:

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

Du vil ha ein klient som feilar raskt og reint, ikkje ein som heng til tidsavbrotet i nettlesaren. Henging betyr vanlegvis at pakkar blir sleppte stille av ein regel utan avvising, noko som er akseptabelt, men det kan òg bety at klienten har late att ei utdatert standardrute mot eit dødt grensesnitt. Les rutetabellen medan tunnelen er nede: ei standardrute som framleis peikar på tunneleininga, og ein brannmurregel som berre blokkerer nye utgåande samband, er to ulike tilstandar, og berre éin av dei er fail-closed.

Gjenta dei same kommandoane med allow-LAN-valet til klienten på og av. Den brytaren er der dei fleste overraskingane bur, fordi han opnar ei rute som resten av policyen var skriven for å lukke.

Steg to: sjekk DNS og IPv6 som separate ruter

Namneoppslag er gapet som overlever dei fleste implementasjonar, fordi spørjinga kan gå ut gjennom noko anna enn systemresolveren. Spør med eit verktøy som ignorerer resolveroppsettet ditt, og sjekk v6-sida samstundes:

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

Tomme svar på begge namnespørjingane med tunnelen nede er resultatet du vil ha. Svarar den andre spørjinga, er ei hardkoda resolveradresse tilgjengeleg, og tunnelen er ikkje den einaste vegen ut av maskina. Viss berre v6-førespurnaden lukkast, dekkjer policyen IPv4 og ignorerer IPv6, som er same lekkasjen i ein annan adressefamilie.

Nettlesarar gjer dette vanskelegare å lese utanfrå, fordi ein nettlesar sett opp for DNS over HTTPS løyser spørjinga via ein HTTPS-førespurnad: spørjinga er berre blokkert så mykje som port 443 til det endepunktet er. På ein vert der policyen tillèt det lokale subnettet, kan den førespurnaden framleis nå ein resolver på LAN.

Steg tre: skil netteksponering frå endepunkteksponering

No delen ingen brannmurregel når. Ein naudbrytar blokkerer ruter ut av maskina; han hindrar ikkje programvare på maskina i å lese data før dei blir krypterte, og han hindrar ikkje den programvara i å bruke tunnelen legitimt. Ein keylogger, ei vondsinna utviding, ein skjerm som er late ulåst, ein synkroniseringsklient med breie rettar: alle flyttar informasjon over ei samband som naudbrytaren gjerne tillèt.

Det same gjeld overvakingsprogramvare ein arbeidsgivar har installert med vilje. Å blokkere ruter fjernar henne ikkje, og kjøp av ein ny VPN-server er ikkje reparasjonen, fordi eksponeringa ligg før tunnelen.

Ein utklippstavlehandsamar som lastar opp til ein skyskonto, viser poenget skarpt. Trafikken er kryptert, målet er tillate, og naudbrytaren rapporterer ein sunn tilstand heile tida.

Steg fire: skriv påstanden testen din støttar

Etter avbrotstesten kan du oppgi konkrete fakta: kva program som feila, kva ruter som stoppa, korleis DNS og IPv6 oppførte seg, og om blokkeringa heldt då tunnelen fall. Du kan ikkje seie at operativsystemet er reint, og du kan ikkje seie at ein teneste i den fjerne enden held innlogginga di privat.

Hald dei to problema skilde og gje kvar si eiga kontroll:

  • Naudbrytar: kravet til definert feil, stadfesta med ein avbrotstest du gjer om att etter kvar klientoppdatering.
  • Einingstillit: støtta oppdateringar, endepunktvern frå ein påliteleg kjelde, gjennomgang av uforklarte rettar og autentiseringsførespurnader.
  • Hending: følg prosessen til plattforma eller organisasjonen når kompromittering blir mistenkt; ein ny server er ikkje eit oppryddingssteg.
  • Offentleggjering: når du ber om hjelp, lim ikkje inn private nøklar eller heile diagnostiske arkiv, fordi loggar og skjermbilete ber dei same løyndomane som sambandet.

Køyr sekvensen att etter neste oppdatering, fordi ein naudbrytar er konfigurasjon som flyttar seg med versjonar. Testen er det einaste provet på at åtferda du reknar med, framleis er åtferda du får.

Relaterte artiklar