Vaše VPN brána je kompromitovaná: co je skutečně ohroženo

VPN brána stojí na konci tunelu, který chrání, což znamená, že toto šifrování ukončuje, místo aby je propouštěla dál. Pokud útočník ovládá hostitel, tunel zvenčí stále vypadá zdravě, zatímco stroj uprostřed už není důvěryhodný. Užitečná otázka není, zda se všechno dešifruje. Je to, co mohl tento hostitel vidět, kam se mohl dostat a která tajemství na něm byla skutečně uložena. Tyto tři odpovědi se hodně liší a reakce se liší spolu s nimi.

Brána ukončuje tunel, takže vidí dovnitř

Šifrování ve VPN jde skok za skokem a brána je ten skok. Sundá vnější vrstvu, uplatní politiku a přepošle vnitřní paket, takže každý přenášený paket v určité chvíli existuje v čitelné podobě v paměti tohoto hostitele. To je návrh, ne chyba. Proto je kompromitace brány jiná událost než kompromitace kryptografie tunelu.

Útočník nejprve získá pozici: možnost sledovat přenášený provoz, měnit přeposílání nebo odpovídat místo backendu. Co získá dál, závisí na hostiteli, a právě tady lidé přeceňují. Pouhý přístup k bráně nepředá relace TLS klíče prohlížeče, protože ty na bráně nikdy nebyly.

Tři expozice, které nemají stejnou velikost

Rozdělte otázku na přenášený provoz, dosažitelné systémy a uložená tajemství a pak odpovězte na každou zvlášť.

Prostřední řádek je ten, který se přeskakuje. Brána obvykle má trasu do privátních sítí a zdrojovou adresu, které backendy už důvěřují, takže zajímavá otázka je, co tyto backendy z této adresy dovolují. Úzká politika klientského přístupu je dobrá kontrola, ale útočník na hostiteli není omezen rozhraním, které by použil běžný klient.

Spodní řádek rozhoduje, jak dlouho incident potrvá. Klíč serveru a klíč CA mají zcela odlišný dosah a stejně tak místní administrátorský účet a monitorovací token pouze pro čtení.

HTTPS uvnitř tunelu je pořád HTTPS

TLS aplikace se ukončuje v aplikaci, ne na VPN bráně, takže kompromitovaná brána u těchto toků vidí šifrovaný text. To je skutečné omezení toho, co útočník získá, a stojí za to to říct jasně, protože opačné tvrzení šíří paniku a špatná rozhodnutí. Dvě podmínky to narušují. Pokud je v cestě inspekční komponenta s důvěryhodným certifikátem, brána může podle návrhu vidět čistý text. Pokud je kompromitován samotný koncový bod aplikace, tunel je irelevantní.

Odpověď na to, co viděli, je tedy podmíněná, a měla by se zapsat jako podmínky, ne oznámit jako verdikt.

Co se musí změnit, než jí znovu uvěříte

Znovu postavit hostitele je nutné a zřídka dostačující. Útočník, který stále drží účet správy, přihlašovací údaje pro nasazení nebo podepisovací klíč, může hostitele vrátit tak, jak se mu líbí. Obnova musí začít z administrativní cesty, která nezávisí na kompromitovaném stroji.

Než rozhodnete, co rotovat, udělejte inventuru toho, co na něm bylo. Klíče, servisní účty, API tokeny, místní uživatelé, naplánované úlohy, vztahy důvěry a nasazovací pipeline jsou všichni kandidáti a každý má vlastníka, který to má potvrdit.

ss -lntup
getent passwd
crontab -l
ip route show table all

Tento výpis je nejrychlejší způsob, jak vidět, co hostitel nabízel a kam mohl dosáhnout. Nejprve uchovejte důkazy, podle postupu vlastníka reakce, protože přestavba ničí právě to, co vyšetřování potřebuje. NIST SP 800-61 Revize 3 považuje přípravu, detekci, reakci a obnovu za součásti jednoho procesu rizik, ne za pokyn k restartu.

Hranice, které udělají tu příští levnější

Čtyři hranice stojí za to postavit dřív, než je budete potřebovat. Udržujte nezávislou cestu obnovy, která se neověřuje přes bránu. Udržujte podepisovací pravomoc odděleně od hostitele, který obsluhuje provoz. Omezte, kam brána může dosáhnout, aby kompromitovaná brána nebyla automaticky kompromitovanou správní sítí. A zaznamenejte, kdo vlastní každý údaj, aby rotace byla telefonátem místo archeologického projektu.

Nic z toho kompromitaci nezabrání. Ohraničuje ji a dělá rozdíl mezi špatným týdnem a špatným čtvrtletím.