Cum testați ce acoperă un întrerupător de urgență pe un host compromis

Activați întrerupătorul de urgență, scoateți serverul tunelului din rețea și observați ce mai face mașina. Testul merită rulat, pentru că separă ce impune firewall-ul de fapt de ce presupuneați, iar rezultatele sunt mai înguste decât sugerează majoritatea paginilor de produs. Un întrerupător de urgență guvernează căi de rețea; nu guvernează software care rulează deja pe dispozitiv. Rulez această secvență pe orice mașină al cărei client susține că este fail-closed, și durează aproximativ zece minute.

Începeți de la client, nu de la server

Punctul de aplicare este gazda la care stați: firewall-ul sistemului de operare, un serviciu auxiliar sau driverul clientului VPN însuși. Asta contează pentru că tot ce poate face întrerupătorul este limitat de ce vede acel strat. Dacă clientul implementează blocarea cu o regulă de rutare și un marcaj, orice cu privilegii suficiente poate adăuga propria regulă; dacă folosește un tabel de firewall din nucleu, aceleași privilegii pot edita tabelul. Forța cifrului nu intră niciodată în această întrebare.

Așadar, primul lucru de stabilit este cine deține politica pe acest dispozitiv și ce i se permite să suprascrie. Pe o mașină de lucru gestionată, răspunsul este de obicei agentul de punct final al organizației, iar un VPN personal nu elimină acele capacități, oricum ar fi configurat tunelul.

Primul pas: confirmați blocarea pe căile pe care credeți că le acoperă

Coborâți tunelul la capătul îndepărtat, nu la client, astfel încât clientul să creadă în continuare că ar trebui să fie conectat. Apoi încercați ce ar încerca de fapt o persoană:

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

Vreți un client care eșuează rapid și curat, nu unul care atârnă până la expirarea timpului browserului. Atârnarea înseamnă de obicei că pachetele sunt aruncate în tăcere de o regulă fără respingere, ceea ce este acceptabil, dar poate însemna și că clientul a lăsat o rută implicită învechită îndreptată spre o interfață moartă. Citiți tabelul de rutare cu tunelul coborât: o rută implicită care încă indică dispozitivul tunelului și o regulă de firewall care blochează doar conexiunile de ieșire noi sunt două stări diferite, și doar una dintre ele este fail-closed.

Repetați aceleași comenzi cu opțiunea de permitere LAN a clientului pornită și oprită. Acel comutator este locul unde stau cele mai multe surprize, pentru că redeschide o cale pe care restul politicii fusese scrisă să o închidă.

Al doilea pas: verificați DNS și IPv6 ca căi separate

Rezolvarea numelor este golul care supraviețuiește majorității implementărilor, pentru că interogarea poate ieși prin altceva decât rezolvatorul sistemului. Întrebați cu un instrument care ignoră configurația rezolvatorului și verificați partea v6 în același timp:

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

Răspunsuri goale la ambele interogări de nume cu tunelul coborât sunt rezultatul dorit. Dacă a doua interogare răspunde, o adresă de rezolvator codificată fix este accesibilă și tunelul nu este singura ieșire din mașină. Dacă reușește doar cererea v6, politica acoperă IPv4 și ignoră IPv6, ceea ce este aceeași scurgere într-o altă familie de adrese.

Browserele fac asta mai greu de citit din exterior, pentru că un browser configurat pentru DNS prin HTTPS rezolvă interogarea printr-o cerere HTTPS: interogarea este blocată doar în măsura în care portul 443 către acel punct final este. Pe o gazdă unde politica permite subrețeaua locală, acea cerere poate ajunge încă la un rezolvator din LAN.

Al treilea pas: separați expunerea de rețea de expunerea punctului final

Acum partea pe care nu ajunge nicio regulă de firewall. Un întrerupător de urgență blochează căi dinspre mașină; nu împiedică software-ul de pe mașină să citească date înainte de criptare și nu împiedică acel software să folosească legitim tunelul. Un keylogger, o extensie malițioasă, un ecran lăsat deblocat, un client de sincronizare cu permisiuni largi: toate mută informație printr-o conexiune pe care întrerupătorul o permite bucuros.

Același lucru este valabil pentru software de monitorizare pe care un angajator l-a instalat intenționat. Blocarea rutelor nu îl elimină, iar cumpărarea unui server VPN nou nu este reparația, pentru că expunerea se află înaintea tunelului.

Un manager de clipboard care încarcă într-un cont cloud arată asta tăios. Traficul este criptat, destinația este permisă, iar întrerupătorul de urgență raportează o stare sănătoasă tot timpul.

Al patrulea pas: scrieți afirmația pe care o susține testul

După testul de întrerupere puteți afirma fapte concrete: ce aplicații au eșuat, ce căi s-au oprit, cum s-au comportat DNS și IPv6 și dacă blocarea a rezistat când tunelul a căzut. Nu puteți afirma că sistemul de operare este curat și nici că un serviciu de la capătul îndepărtat vă va păstra autentificarea privată.

Țineți cele două probleme separate și dați fiecăreia propriul control:

• Întrerupător de urgență: cerința de eșec definită, verificată cu un test de întrerupere pe care îl repetați după fiecare actualizare a clientului.
• Încredere în dispozitiv: actualizări acceptate, protecție de punct final dintr-o sursă de încredere, revizuirea permisiunilor și cererilor de autentificare neexplicate.
• Incident: urmați procesul platformei sau al organizației când se suspectează o compromitere; un server nou nu este un pas de curățare.
• Divulgare: când cereți ajutor, nu lipiți chei private sau arhive de diagnostic complete, pentru că jurnalele și capturile poartă aceleași secrete ca conexiunea.

Rulați din nou secvența după următoarea actualizare, pentru că un întrerupător de urgență este configurație care se mișcă împreună cu versiunile. Testul este singura dovadă că comportamentul pe care vă bazați este încă cel pe care îl obțineți.