Kiel testi, kion sekureca ŝaltilo kovras ĉe kompromitita gastiganto

Rulu la interrompan teston, legu la rezulton de ĉiu tavolo kaj vidu, kie sekureca ŝaltilo haltas: ĝi blokas vojojn, ne programaron, kiu legas datumojn antaŭ ĉifrado.

Ŝaltu la sekurecan ŝaltilon, malkonektu la tunelan servilon kaj observu, kion la maŝino ankoraŭ faras. La testo indas, ĉar ĝi apartigas tion, kion la fajroŝirmilo efektivigas, de tio, kion vi supozis, kaj la rezultoj estas pli mallarĝaj ol la plej multaj produktaj paĝoj sugestas. Sekureca ŝaltilo regas retajn vojojn; ĝi ne regas programaron jam kurantan sur la aparato. Mi rulas ĉi tiun sinsekvon sur ĉiu maŝino, kie la kliento asertas esti fail-closed, kaj ĝi daŭras ĉirkaŭ dek minutojn.

Komencu de la kliento, ne de la servilo

La efektiviga punkto estas la gastiganto, ĉe kiu vi sidas: la fajroŝirmilo de la operaciumo, helpa servo aŭ la propra pelilo de la VPN-kliento. Tio gravas, ĉar ĉio, kion la ŝaltilo povas fari, limiĝas per tio, kion tiu tavolo vidas. Se la kliento realigas la blokon per enkursiga regulo kaj marko, io ajn kun sufiĉaj privilegioj povas aldoni sian propran regulon; se ĝi uzas kernan fajroŝirmilan tabelon, la samaj privilegioj povas redakti la tabelon. La forto de la ĉifro neniam eniras ĉi tiun demandon.

Do la unua afero starigenda estas, kiu posedas la politikon sur ĉi tiu aparato kaj kion ĝi rajtas anstataŭigi. Sur administrata labormaŝino la respondo kutime estas la finpunkta agento de la organizo, kaj persona VPN ne forigas tiujn kapablojn, kiel ajn la tunelo estas agordita.

Unua paŝo: konfirmu la blokon sur la vojoj, kiujn vi opinias kovritaj

Mallevu la tunelon ĉe la malproksima fino, ne ĉe la kliento, por ke la kliento daŭre kredu, ke ĝi devus esti konektita. Poste provu tion, kion persono efektive provus:

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

Vi volas klienton, kiu malsukcesas rapide kaj pure, ne tian, kiu pendas ĝis la tempolimo de la retumilo. Pendado kutime signifas, ke pakaĵojn silente forĵetas regulo sen rifuzo, kio estas akceptebla, sed ĝi ankaŭ povas signifi, ke la kliento lasis malnoviĝintan defaŭltan vojon direktitan al mortinta interfaco. Legu la enkursigan tabelon dum la tunelo estas mallevita: defaŭlta vojo ankoraŭ montranta al la tunela aparato kaj fajroŝirmila regulo, kiu blokas nur novajn elirantajn konektojn, estas du malsamaj statoj, kaj nur unu el ili estas fail-closed.

Ripetu la samajn komandojn kun la opcio permesi lokan reton de la kliento ŝaltita kaj malŝaltita. Tiu ŝaltilo estas la loko de plej multaj surprizoj, ĉar ĝi remalfermas vojon, kiun la resto de la politiko estis skribita fermi.

Dua paŝo: kontrolu DNS kaj IPv6 kiel apartajn vojojn

Noma solvado estas la breĉo, kiu postvivas la plej multajn realigojn, ĉar la peto povas eliri per io alia ol la sistema solvilo. Demandu per ilo, kiu ignoras vian solvilan agordon, kaj kontrolu la v6-flankon samtempe:

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

Malplenaj respondoj al ambaŭ nomaj petoj kun la tunelo mallevita estas la rezulto, kiun vi volas. Se la dua peto respondas, malmola solvila adreso estas atingebla kaj la tunelo ne estas la sola vojo el la maŝino. Se nur la v6-peto sukcesas, la politiko kovras IPv4 kaj ignoras IPv6, kio estas la sama liko en alia adresa familio.

Retumiloj malfaciligas tion legi de ekstere, ĉar retumilo agordita por DNS per HTTPS solvas la peton per HTTPS-peto: la peto estas blokita nur tiom, kiom la pordo 443 al tiu finpunkto. Sur gastiganto, kie la politiko permesas la lokan subreton, tiu peto ankoraŭ povas atingi solvilon en la LAN.

Tria paŝo: apartigu retan elmetiĝon de finpunkta elmetiĝo

Nun la parto, kiun neniu fajroŝirmila regulo atingas. Sekureca ŝaltilo blokas vojojn el la maŝino; ĝi ne malhelpas programaron sur la maŝino legi datumojn antaŭ ol ili estas ĉifritaj, kaj ĝi ne malhelpas tiun programaron laŭleĝe uzi la tunelon. Klavregistrilo, malica etendaĵo, lasita malŝlosita ekrano, sinkroniga kliento kun larĝaj permesoj: ĉio ĉi transportas informojn per konekto, kiun la ŝaltilo volonte permesas.

La samo validas por observa programaro, kiun dunganto intence instalis. Bloki vojojn ne forigas ĝin, kaj aĉeti novan VPN-servilon ne estas riparo, ĉar la elmetiĝo situas antaŭ la tunelo.

Kopibufra administrilo, kiu alŝutas al nuba konto, montras tion akre. La trafiko estas ĉifrita, la celo permesita, kaj la sekureca ŝaltilo raportas sanan staton la tutan tempon.

Kvara paŝo: skribu la aserton, kiun via testo subtenas

Post la interrompa testo vi povas nomi konkretojn: kiuj aplikoj malsukcesis, kiuj vojoj haltis, kiel kondutis DNS kaj IPv6, kaj ĉu la bloko tenis, kiam la tunelo falis. Vi ne povas aserti, ke la operaciumo estas pura, nek ke servo ĉe la malproksima fino tenos vian salutan privata.

Tenu la du problemojn aparte kaj donu al ĉiu sian propran regadon:

  • Sekureca ŝaltilo: la difinita fiaskopostulo, kontrolita per interrompa testo, kiun vi ripetas post ĉiu klienta ĝisdatigo.
  • Fido al aparato: subtenataj ĝisdatigoj, finpunkta protekto el fidinda fonto, revizio de neklarigitaj permesoj kaj aŭtentikaj petoj.
  • Incidento: sekvu la procezon de la platformo aŭ organizo, kiam kompromitiĝo estas suspektata; nova servilo ne estas puriga paŝo.
  • Malkaŝo: kiam vi petas helpon, ne algluu privatajn ŝlosilojn aŭ tutajn diagnostikajn arkivojn, ĉar protokoloj kaj ekrankopioj portas la samajn sekretojn kiel la konekto.

Rulu la sinsekvon denove post la sekva ĝisdatigo, ĉar sekureca ŝaltilo estas agordo, kiu moviĝas kun versioj. La testo estas la sola pruvo, ke la konduto, sur kiu vi dependas, ankoraŭ estas tiu, kiun vi ricevas.

Rilataj artikoloj