Kā pārbaudīt, ko avārijas slēdzis sedz kompromitētā resursdatorā

Palaidiet pārtraukuma testu, izlasiet katras kārtas rezultātu un redziet, kur avārijas slēdzis apstājas: tas bloķē ceļus, nevis programmatūru, kas lasa datus pirms šifrēšanas.

Ieslēdziet avārijas slēdzi, izslēdziet tuneļa serveri no tīkla un vērojiet, ko mašīna joprojām dara. Šis tests ir tā vērts, jo tas atdala to, ko ugunsmūris faktiski īsteno, no tā, ko jūs pieņēmāt, un rezultāti ir šaurāki, nekā liecina lielākā daļa produktu lapu. Avārijas slēdzis pārvalda tīkla ceļus; tas nepārvalda programmatūru, kas jau darbojas ierīcē. Es veicu šo secību katrā mašīnā, kuras klients apgalvo, ka ir fail-closed, un tas aizņem apmēram desmit minūtes.

Sāciet ar klientu, nevis ar serveri

Īstenošanas punkts ir resursdators, pie kura jūs sēžat: operētājsistēmas ugunsmūris, palīgpakalpojums vai paša VPN klienta draiveris. Tas ir svarīgi, jo viss, ko slēdzis var darīt, ir ierobežots ar to, ko šī kārta redz. Ja klients bloķēšanu īsteno ar maršrutēšanas noteikumu un atzīmi, jebkas ar pietiekamām privilēģijām var pievienot savu noteikumu; ja tas izmanto kodola ugunsmūra tabulu, tās pašas privilēģijas var tabulu rediģēt. Šifra stiprums šajā jautājumā nekad neienāk.

Tāpēc vispirms jānoskaidro, kam pieder politika šajā ierīcē un ko tai ir atļauts ignorēt. Pārvaldītā darba mašīnā atbilde parasti ir organizācijas galapunkta aģents, un personīgais VPN šīs iespējas neizņem, lai kā tunneli konfigurētu.

Pirmais solis: apstipriniet bloķēšanu ceļos, kuros, jūsuprāt, tas to sedz

Nolaižam tuneli tālajā galā, nevis klientā, lai klients joprojām ticētu, ka tam vajadzētu būt savienotam. Pēc tam izmēģiniet to, ko cilvēks patiešām mēģinātu:

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

Jūs vēlaties klientu, kas neizdodas ātri un tīri, nevis tādu, kas karājas līdz pārlūka taimautam. Karāšanās parasti nozīmē, ka paketes klusi izmet noteikums bez noraidīšanas, kas ir pieņemami, taču tas var nozīmēt arī to, ka klients ir atstājis novecojušu noklusējuma maršrutu uz mirušu interfeisu. Lasiet maršrutēšanas tabulu, kamēr tunelis ir nolaists: noklusējuma maršruts, kas joprojām norāda uz tuneļa ierīci, un ugunsmūra noteikums, kas bloķē tikai jaunus izejošos savienojumus, ir divi dažādi stāvokļi, un tikai viens no tiem ir fail-closed.

Atkārtojiet tās pašas komandas ar klienta allow-LAN opciju ieslēgtu un izslēgtu. Šis slēdzis ir vieta, kur dzīvo lielākā daļa pārsteigumu, jo tas atkal atver ceļu, kuru pārējā politika bija rakstīta, lai aizvērtu.

Otrais solis: pārbaudiet DNS un IPv6 kā atsevišķus ceļus

Vārdu izšķiršana ir plaisa, kas pārdzīvo lielāko daļu ieviešanu, jo vaicājums var iziet pa kaut ko citu, nevis sistēmas izšķirtāju. Jautājiet ar rīku, kas ignorē jūsu izšķirtāja konfigurāciju, un tajā pašā laikā pārbaudiet v6 pusi:

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

Tukšas atbildes uz abiem nosaukumu vaicājumiem, tunelim esot nolaistam, ir vēlamais rezultāts. Ja otrais vaicājums atbild, cieti kodēta izšķirtāja adrese ir sasniedzama un tunelis nav vienīgais ceļš ārpus mašīnas. Ja veicas tikai v6 pieprasījums, politika sedz IPv4 un ignorē IPv6, kas ir tā pati noplūde citā adrešu saimē.

Pārlūki padara to grūtāk lasāmu no ārpuses, jo pārlūks, kas konfigurēts DNS over HTTPS, vaicājumu izšķir ar HTTPS pieprasījumu: vaicājums ir bloķēts tik, cik ir bloķēts 443 ports uz šo galapunktu. Resursdatorā, kur politika atļauj vietējo apakštīklu, šis pieprasījums joprojām var sasniegt izšķirtāju LAN tīklā.

Trešais solis: atdaliet tīkla iedarbību no galapunkta iedarbības

Tagad daļa, kuru nesasniedz neviens ugunsmūra noteikums. Avārijas slēdzis bloķē ceļus ārpus mašīnas; tas neaptur programmatūru mašīnā lasīt datus pirms to šifrēšanas un neaptur šo programmatūru likumīgi izmantot tuneli. Tastatūras reģistrētājs, ļaunprātīgs paplašinājums, atstāts neatslēgts ekrāns, sinhronizācijas klients ar plašām atļaujām: visi tie pārvieto informāciju pa savienojumu, kuru slēdzis labprāt atļauj.

Tas pats attiecas uz uzraudzības programmatūru, ko darba devējs apzināti instalējis. Maršrutu bloķēšana to neizņem, un jauna VPN servera pirkšana nav labojums, jo iedarbība atrodas pirms tuneļa.

Starpliktuves pārvaldnieks, kas augšupielādē mākoņa kontā, to parāda asi. Satiksme ir šifrēta, galamērķis atļauts, un avārijas slēdzis visu laiku ziņo par veselīgu stāvokli.

Ceturtais solis: uzrakstiet apgalvojumu, ko pamato jūsu tests

Pēc pārtraukuma testa varat nosaukt konkrētus faktus: kuras programmas neizdevās, kuri ceļi apstājās, kā uzvedās DNS un IPv6 un vai bloķēšana noturējās, kad tunelis krita. Jūs nevarat apgalvot, ka operētājsistēma ir tīra, un nevarat apgalvot, ka pakalpojums tālajā galā saglabās jūsu pieteikšanos privātu.

Turiet abas problēmas atsevišķi un katrai dodiet savu kontroli:

  • Avārijas slēdzis: noteiktā atteices prasība, ko apstiprina pārtraukuma tests, kuru atkārtojat pēc katras klienta atjaunināšanas.
  • Ierīces uzticēšanās: atbalstīti atjauninājumi, galapunkta aizsardzība no uzticama avota, neizskaidrotu atļauju un autentifikācijas pieprasījumu pārskatīšana.
  • Incidents: ja tiek aizdomas par kompromitēšanu, ievērojiet platformas vai organizācijas procesu; jauns serveris nav tīrīšanas solis.
  • Atklāšana: lūdzot palīdzību, neielīmējiet privātās atslēgas vai pilnus diagnostikas arhīvus, jo žurnāli un ekrānuzņēmumi nes tādus pašus noslēpumus kā savienojums.

Pēc nākamā atjauninājuma veiciet secību vēlreiz, jo avārijas slēdzis ir konfigurācija, kas pārvietojas kopā ar versijām. Tests ir vienīgais pierādījums, ka uzvedība, uz kuru paļaujaties, joprojām ir tā, ko saņemat.

Saistītie raksti