Hogyan teszteljük, mit fed le egy vészkapcsoló egy fertőzött hoszton

Futtassa a kieséstesztet, olvassa el minden réteg eredményét, és lássa, hol áll meg a vészkapcsoló: útvonalakat blokkol, nem a titkosítás előtt adatot olvasó szoftvert.

Kapcsolja be a vészkapcsolót, vegye le a hálózatról az alagút-kiszolgálót, és figyelje, mit tesz még a gép. A teszt megéri, mert elválasztja azt, amit a tűzfal ténylegesen kikényszerít, attól, amit feltételezett, és az eredmények szűkebbek, mint amit a legtöbb termékoldal sugall. A vészkapcsoló hálózati útvonalakat szabályoz; nem szabályozza az eszközön már futó szoftvert. Minden olyan gépen lefuttatom ezt a sorrendet, amelynek kliense azt állítja, hogy fail-closed, és körülbelül tíz percig tart.

A kliensnél kezdje, ne a kiszolgálónál

A kikényszerítés pontja az a hoszt, amelynél ül: az operációs rendszer tűzfala, egy segédszolgáltatás vagy maga a VPN-kliens illesztőprogramja. Ez számít, mert minden, amit a kapcsoló tehet, arra korlátozódik, amit ez a réteg lát. Ha a kliens útválasztási szabállyal és jelöléssel valósítja meg a blokkolást, bármi, aminek elegendő jogosultsága van, saját szabályt adhat hozzá; ha kernel tűzfaltáblát használ, ugyanaz a jogosultság szerkesztheti a táblát. A titkosítás erőssége soha nem kerül ebbe a kérdésbe.

Először tehát azt kell tisztázni, ki birtokolja a szabályzatot ezen az eszközön, és mit írhat felül. Kezelt munkagépen a válasz általában a szervezet végponti ügynöke, és a személyes VPN nem távolítja el ezeket a képességeket, akárhogy is konfigurált az alagút.

Első lépés: erősítse meg a blokkolást azokon az útvonalakon, amelyekről úgy véli, hogy lefedi

A távoli végponton vegye le az alagutat, ne a kliensnél, hogy a kliens továbbra is azt higgye, kapcsolódva kellene lennie. Utána próbálja ki azt, amit egy ember tényleg kipróbálna:

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

Olyan klienst szeretne, amely gyorsan és tisztán meghibásodik, nem olyat, amely a böngésző időtúllépéséig lóg. A lógás általában azt jelenti, hogy a csomagokat egy visszautasítás nélküli szabály csendben eldobja, ami elfogadható, de azt is jelentheti, hogy a kliens elavult alapértelmezett útvonalat hagyott egy halott interfész felé. Olvassa el az útválasztási táblát, amíg az alagút le van: az alagút-eszközre még mutató alapértelmezett útvonal és a csak új kimenő kapcsolatokat blokkoló tűzfalszabály két különböző állapot, és közülük csak az egyik fail-closed.

Ismételje meg ugyanezeket a parancsokat a kliens allow-LAN opciójával be- és kikapcsolva. Ez a kapcsoló a legtöbb meglepetés helye, mert újra megnyit egy útvonalat, amelyet a szabályzat többi része bezárni hivatott.

Második lépés: ellenőrizze a DNS-t és az IPv6-ot külön útvonalként

A névfeloldás az a rés, amely a legtöbb megvalósítást túléli, mert a lekérdezés a rendszer feloldójától eltérő úton is kimehet. Kérdezzen olyan eszközzel, amely figyelmen kívül hagyja a feloldó beállításait, és közben ellenőrizze a v6 oldalt:

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

Üres válaszok mindkét névlekérdezésre, leengedett alagút mellett, az az eredmény, amit szeretne. Ha a második lekérdezés válaszol, egy beégetett feloldócím érhető el, és az alagút nem az egyetlen kifelé vezető út a gépről. Ha csak a v6 kérés sikerül, a szabályzat lefedi az IPv4-et és figyelmen kívül hagyja az IPv6-ot, ami ugyanaz a szivárgás másik címcsaládban.

A böngészők ezt nehezebben olvashatóvá teszik kívülről, mert a DNS over HTTPS-re beállított böngésző HTTPS-kéréssel oldja fel a lekérdezést: a lekérdezés csak annyira blokkolt, amennyire a 443-as port az adott végpont felé az. Olyan hoszton, ahol a szabályzat engedi a helyi alhálózatot, ez a kérés még mindig elérhet egy feloldót a LAN-on.

Harmadik lépés: válassza szét a hálózati kitettséget a végponti kitettségtől

Most az a rész, ahová egyetlen tűzfalszabály sem ér el. A vészkapcsoló a gépből kifelé vezető útvonalakat blokkolja; nem akadályozza meg a gépen lévő szoftvert abban, hogy titkosítás előtt adatot olvasson, és nem akadályozza meg ugyanezt a szoftvert az alagút jogszerű használatában. Billentyűnaplózó, rosszindulatú bővítmény, nyitva hagyott képernyő, széles jogosultságú szinkronizáló kliens: mindegyik olyan kapcsolaton visz információt, amelyet a kapcsoló szívesen engedélyez.

Ugyanez igaz a munkáltató által szándékosan telepített megfigyelő szoftverre. Az útvonalak blokkolása nem távolítja el, és egy új VPN-kiszolgáló vásárlása nem a javítás, mert a kitettség az alagút előtt van.

A felhőfiókba feltöltő vágólapkezelő élesen mutatja ezt. A forgalom titkosított, a cél engedélyezett, és a vészkapcsoló végig egészséges állapotot jelent.

Negyedik lépés: fogalmazza meg azt az állítást, amelyet a tesztje alátámaszt

A kiesésteszt után konkrét tényeket mondhat: mely alkalmazások hibáztak, mely útvonalak álltak le, hogyan viselkedett a DNS és az IPv6, és hogy tartott-e a blokk, amikor az alagút leesett. Nem állíthatja, hogy az operációs rendszer tiszta, és azt sem, hogy egy távoli végponti szolgáltatás privátban tartja a bejelentkezését.

Tartsa külön a két problémát, és adjon mindegyiknek saját ellenőrzést:

  • Vészkapcsoló: a meghatározott hiba követelménye, amelyet a minden kliensfrissítés után megismételt kiesésteszt igazol.
  • Eszközbizalom: támogatott frissítések, végpontvédelem megbízható forrásból, a megmagyarázatlan engedélyek és hitelesítési kérések átvizsgálása.
  • Incidens: fertőzés gyanúja esetén kövesse a platform vagy a szervezet folyamatát; egy friss kiszolgáló nem tisztítási lépés.
  • Nyilvánosságra hozatal: segítségkéréskor ne illesszen be privát kulcsokat vagy teljes diagnosztikai archívumokat, mert a naplók és a képernyőképek ugyanazokat a titkokat hordozzák, mint a kapcsolat.

A következő frissítés után futtassa újra a sorrendet, mert a vészkapcsoló verziókkal együtt mozgó konfiguráció. A teszt az egyetlen bizonyíték arra, hogy a viselkedés, amelyre támaszkodik, még mindig az, amit kap.

Kapcsolódó cikkek