Paano subukan kung ano ang saklaw ng emergency switch sa isang kompromisadong host
Patakbuhin ang pagsubok sa pagkaantala, basahin ang resulta ng bawat layer at tingnan kung saan humihinto ang emergency switch: hinaharangan nito ang mga landas, hindi ang software na nagbabasa ng data bago ang encryption.
I-on ang emergency switch, patayin ang tunnel server at panoorin kung ano pa ang ginagawa ng makina. Sulit ang pagsubok dahil inihihiwalay nito ang aktwal na ipinapatupad ng firewall sa inakala mo, at ang mga resulta ay mas makitid kaysa ipinahihiwatig ng karamihan sa mga pahina ng produkto. Ang emergency switch ay namamahala sa mga landas ng network; hindi nito pinamamahalaan ang software na tumatakbo na sa device. Ginagawa ko ang pagkakasunod-sunod na ito sa bawat makina na sinasabing fail-closed ng client, at tumatagal ito ng mga sampung minuto.
Magsimula sa client, hindi sa server
Ang punto ng pagpapatupad ay ang host na kinauupuan mo: ang firewall ng operating system, isang pantulong na serbisyo o ang driver mismo ng VPN client. Mahalaga ito dahil lahat ng magagawa ng switch ay limitado sa nakikita ng layer na iyon. Kung ipinapatupad ng client ang pagharang sa pamamagitan ng routing rule at marka, kahit ano na may sapat na pribilehiyo ay makakadagdag ng sariling panuntunan; kung gumagamit ito ng kernel firewall table, mababago ng parehong pribilehiyo ang talahanayan. Ang lakas ng cipher ay hindi kailanman pumapasok sa tanong na ito.
Kaya ang unang dapat itatag ay kung sino ang may-ari ng patakaran sa device na ito at ano ang pinapayagang lampasan. Sa isang pinamamahalaang work machine, ang sagot ay karaniwang endpoint agent ng organisasyon, at hindi inaalis ng personal na VPN ang mga kakayahang iyon, gaano man i-configure ang tunnel.
Unang hakbang: kumpirmahin ang pagharang sa mga landas na inaakala mong saklaw
Ibaba ang tunnel sa dulong bahagi, hindi sa client, upang maniwala pa rin ang client na dapat itong konektado. Pagkatapos subukan ang aktwal na susubukan ng isang tao:
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
Gusto mo ng client na mabilis at malinis na mabibigo, hindi ang nabibitay hanggang sa timeout ng browser. Ang pagbitay ay karaniwang nangangahulugan na ang mga packet ay tahimik na itinatapon ng isang panuntunan na walang pagtanggi, na katanggap-tanggap, ngunit maaari ring mangahulugan na nag-iwan ang client ng lumang default route na nakaturo sa patay na interface. Basahin ang routing table habang nakababa ang tunnel: ang default route na nakaturo pa rin sa tunnel device at ang firewall rule na humaharang lamang sa mga bagong outbound na koneksyon ay dalawang magkaibang estado, at isa lamang sa kanila ang fail-closed.
Ulitin ang parehong mga utos habang naka-on at naka-off ang allow-LAN na opsyon ng client. Ang toggle na iyon ang lugar ng karamihan sa mga sorpresa, dahil muling binubuksan nito ang landas na dapat isara ng natitirang patakaran.
Ikalawang hakbang: suriin ang DNS at IPv6 bilang magkahiwalay na landas
Ang paglutas ng pangalan ang puwang na nakakaligtas sa karamihan ng implementasyon, dahil ang query ay maaaring lumabas sa iba maliban sa system resolver. Magtanong gamit ang tool na hindi pinapansin ang iyong resolver configuration, at suriin din ang v6 na panig:
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
Ang mga walang laman na sagot sa dalawang query ng pangalan habang nakababa ang tunnel ang resultang gusto mo. Kung sumasagot ang ikalawang query, maabot ang hardcoded na resolver address at ang tunnel ay hindi lamang ang labasan mula sa makina. Kung ang kahilingan lamang sa v6 ang nagtagumpay, sinasaklaw ng patakaran ang IPv4 at hindi pinapansin ang IPv6, na siya ring pagtagas sa ibang pamilya ng address.
Pinapahirap ng mga browser na basahin ito mula sa labas, dahil ang browser na naka-configure para sa DNS over HTTPS ay nilulutas ang query sa pamamagitan ng HTTPS request: ang query ay nahaharang lamang hangga't nahaharang ang port 443 patungo sa dulong iyon. Sa host na pinapayagan ng patakaran ang lokal na subnet, maaaring maabot pa rin ng request na iyon ang resolver sa LAN.
Ikatlong hakbang: ihiwalay ang exposure ng network sa exposure ng endpoint
Ngayon ang bahagi na hindi naaabot ng anumang firewall rule. Hinaharangan ng emergency switch ang mga landas palabas ng makina; hindi nito pinipigilan ang software sa makina na magbasa ng data bago ito i-encrypt, at hindi nito pinipigilan ang software na iyon na gamitin ang tunnel nang legal. Isang keylogger, isang malisyosong extension, isang screen na naiwang naka-unlock, isang sync client na may malawak na pahintulot: lahat sila ay naglilipat ng impormasyon sa koneksyong bukas-palad na pinapayagan ng switch.
Ganoon din sa monitoring software na sadyang inilagay ng isang employer. Ang pagharang sa mga ruta ay hindi ito nag-aalis, at ang pagbili ng bagong VPN server ay hindi ang pag-aayos, dahil ang exposure ay nasa unahan ng tunnel.
Ang clipboard manager na nag-a-upload sa cloud account ay malinaw na nagpapakita nito. Naka-encrypt ang traffic, pinapayagan ang destinasyon, at nag-uulat ang emergency switch ng malusog na estado sa buong oras.
Ikaapat na hakbang: isulat ang pahayag na sinusuportahan ng iyong pagsubok
Pagkatapos ng pagsubok sa pagkaantala maaari mong sabihin ang mga tiyak na katotohanan: aling mga app ang nabigo, aling mga landas ang huminto, paano kumilos ang DNS at IPv6, at kung nanatili ang pagharang nang bumagsak ang tunnel. Hindi mo masasabi na malinis ang operating system, at hindi mo masasabi na pananatilihing pribado ng isang serbisyo sa dulong bahagi ang iyong login.
Panatilihing magkahiwalay ang dalawang problema at bigyan ang bawat isa ng sariling kontrol:
- Emergency switch: ang tinukoy na kinakailangan sa pagpalya, na na-verify sa pagsubok sa pagkaantala na inuulit mo pagkatapos ng bawat pag-upgrade ng client.
- Tiwala sa device: mga sinusuportahang update, proteksyon ng endpoint mula sa mapagkakatiwalaang pinagmulan, pagsusuri ng hindi maipaliwanag na pahintulot at mga kahilingan sa authentication.
- Insidente: sundin ang proseso ng platform o organisasyon kapag pinaghihinalaan ang kompromiso; ang bagong server ay hindi hakbang sa paglilinis.
- Pagsisiwalat: kapag humihingi ng tulong, huwag i-paste ang mga pribadong key o kumpletong diagnostic archive, dahil ang mga log at screenshot ay nagdadala ng parehong mga lihim ng koneksyon.
Patakbuhin muli ang pagkakasunod-sunod pagkatapos ng susunod na update, dahil ang emergency switch ay configuration na gumagalaw kasama ng mga bersyon. Ang pagsubok lamang ang ebidensyang ang pag-uugaling inaasahan mo ay siya pa ring pag-uugaling nakukuha mo.