Si të testoni çfarë mbulon një ndërprerës emergjence në një host të komprometuar

Aktivizoni ndërprerësin e emergjencës, hiqni serverin e tunelit nga rrjeti dhe vëzhgoni çfarë vazhdon të bëjë makina. Testi ia vlen, sepse ndan atë që zbaton vërtet muri i zjarrit nga ajo që supozuat, dhe rezultatet janë më të ngushta se sa sugjerojnë shumica e faqeve të produktit. Një ndërprerës emergjence qeveris rrugët e rrjetit; nuk qeveris softuerin që tashmë ekzekutohet në pajisje. E ekzekutoj këtë sekuencë në çdo makinë, klienti i së cilës pretendon se është fail-closed, dhe zgjat rreth dhjetë minuta.

Filloni nga klienti, jo nga serveri

Pika e zbatimit është hosti ku jeni ulur: muri i zjarrit i sistemit operativ, një shërbim ndihmës ose vetë drejtuesi i klientit VPN. Kjo ka rëndësi, sepse gjithçka që ndërprerësi mund të bëjë kufizohet nga ajo që sheh ai shtresë. Nëse klienti e zbaton bllokimin me një rregull rrugëtimi dhe një shenjë, çdo gjë me privilegje të mjaftueshme mund të shtojë rregullin e vet; nëse përdor një tabelë të murit të zjarrit të kernelit, të njëjtat privilegje mund ta modifikojnë tabelën. Forca e shifrimit nuk hyn kurrë në këtë pyetje.

Prandaj gjëja e parë që duhet përcaktuar është kush e zotëron politikën në këtë pajisje dhe çfarë lejohet të anashkalojë. Në një makinë pune të menaxhuar përgjigjja është zakonisht agjenti i pikës fundore i organizatës, dhe një VPN personal nuk i heq ato aftësi, sido që të jetë konfiguruar tuneli.

Hapi i parë: konfirmoni bllokimin në rrugët që mendoni se i mbulon

Zbritni tunelin në skajin e largët, jo në klient, që klienti të vazhdojë të besojë se duhet të ishte i lidhur. Pastaj provoni atë që një person do të provonte vërtet:

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

Dëshironi një klient që dështon shpejt dhe pastër, jo një që varet deri në skadimin e kohës së shfletuesit. Varja zakonisht do të thotë se paketat hidhen në heshtje nga një rregull pa refuzim, gjë e pranueshme, por mund të thotë gjithashtu se klienti la një rrugë të paracaktuar të vjetruar drejt një ndërfaqeje të vdekur. Lexoni tabelën e rrugëtimit ndërsa tuneli është poshtë: një rrugë e paracaktuar që ende tregon pajisjen e tunelit dhe një rregull muri zjarri që bllokon vetëm lidhjet e reja dalëse janë dy gjendje të ndryshme, dhe vetëm njëra prej tyre është fail-closed.

Përsëritni të njëjtat komanda me opsionin allow-LAN të klientit të ndezur dhe të fikur. Ai çelës është vendi ku banojnë shumica e surprizave, sepse rihap një rrugë që pjesa tjetër e politikës ishte shkruar ta mbyllte.

Hapi i dytë: kontrolloni DNS dhe IPv6 si rrugë të ndara

Zgjidhja e emrave është boshllëku që i mbijeton shumicës së zbatimeve, sepse pyetja mund të dalë përmes diçkaje tjetër përveç zgjidhësit të sistemit. Pyetni me një mjet që injoron konfigurimin tuaj të zgjidhësit, dhe kontrolloni anën v6 ndërkohë:

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

Përgjigje bosh për të dy pyetjet e emrave me tunelin poshtë janë rezultati që dëshironi. Nëse pyetja e dytë përgjigjet, një adresë zgjidhësi e koduar fort është e arritshme dhe tuneli nuk është e vetmja rrugë dalëse nga makina. Nëse vetëm kërkesa v6 ka sukses, politika mbulon IPv4 dhe injoron IPv6, që është e njëjta rrjedhje në një familje tjetër adresash.

Shfletuesit e bëjnë këtë më të vështirë për t'u lexuar nga jashtë, sepse një shfletues i konfiguruar për DNS mbi HTTPS e zgjidh pyetjen përmes një kërkese HTTPS: pyetja bllokohet vetëm aq sa bllokohet porti 443 drejt atij skaji. Në një host ku politika lejon nënrrjetin lokal, ajo kërkesë ende mund të arrijë një zgjidhës në LAN.

Hapi i tretë: ndani ekspozimin e rrjetit nga ekspozimi i pikës fundore

Tani pjesa ku nuk arrin asnjë rregull muri zjarri. Një ndërprerës emergjence bllokon rrugët jashtë makinës; nuk e pengon softuerin në makinë të lexojë të dhëna para se të kriptohen, dhe nuk e pengon atë softuer ta përdorë tunelin në mënyrë legjitime. Një keylogger, një shtesë keqdashëse, një ekran i lënë i shkyçur, një klient sinkronizimi me leje të gjera: të gjithë lëvizin informacion përmes një lidhjeje që ndërprerësi e lejon me kënaqësi.

E njëjta gjë vlen për softuerin e monitorimit që një punëdhënës e instaloi me qëllim. Bllokimi i rrugëve nuk e heq atë, dhe blerja e një serveri të ri VPN nuk është riparimi, sepse ekspozimi qëndron përpara tunelit.

Një menaxher i kujtesës së përkohshme që ngarkon në një llogari cloud e tregon këtë me mprehtësi. Trafiku është i kriptuar, destinacioni i lejuar, dhe ndërprerësi i emergjencës raporton gjendje të shëndetshme gjatë gjithë kohës.

Hapi i katërt: shkruani pohimin që testi juaj mbështet

Pas testit të ndërprerjes mund të deklaroni fakte konkrete: cilat aplikacione dështuan, cilat rrugë u ndalën, si u sollën DNS dhe IPv6 dhe nëse bllokimi qëndroi kur tuneli ra. Nuk mund të deklaroni se sistemi operativ është i pastër, as se një shërbim në skajin e largët do ta mbajë hyrjen tuaj private.

Mbajini dy problemet të ndara dhe jepini secilit kontrollin e vet:

• Ndërprerës emergjence: kërkesa e përcaktuar e dështimit, e verifikuar me një test ndërprerjeje që e përsëritni pas çdo përditësimi të klientit.
• Besimi i pajisjes: përditësime të mbështetura, mbrojtje e pikës fundore nga një burim i besueshëm, rishikim i lejeve dhe kërkesave të pa shpjeguara të vërtetimit.
• Incident: ndiqni procesin e platformës ose organizatës kur dyshohet kompromis; një server i ri nuk është hap pastrimi.
• Zbulimi: kur kërkoni ndihmë, mos ngjitni çelësa privatë ose arkiva të plota diagnostikuese, sepse regjistrat dhe pamjet e ekranit mbartin të njëjtat sekrete si lidhja.

Ekzekutoni përsëri sekuencën pas përditësimit të ardhshëm, sepse një ndërprerës emergjence është konfigurim që lëviz me versionet. Testi është prova e vetme se sjellja ku mbështeteni është ende ajo që merrni.