Fișierul dumneavoastră .ovpn poate executa cod, nu doar ruta traficul

Majoritatea oamenilor citesc un fișier .ovpn așa cum citesc pagina de setări a unui router: adrese, rute, o listă de cifruri. Partea care execută cod stă aproape de partea de jos, lângă directive care arată ca lucrări de instalații, și rulează cu orice privilegii are deja clientul. Aceasta este breșa pe care o exploatează un profil neglijent sau rău intenționat, și este totodată breșa care transformă un ajutor DNS util într-o problemă de suport trei săptămâni mai târziu. Directiva de eveniment, nivelul de securitate și proprietatea fișierului decid ce se poate întâmpla; conținutul scriptului decide ce se întâmplă de fapt. Citiți toate patru înainte de a vă conecta.

Un profil care rulează un ajutor este un program, nu un fișier de setări

Directive precum route și dhcp-option descriu starea pe care clientul ar trebui să o stabilească, iar clientul le tratează ca date. Un script up este diferit: clientul îl lansează ca proces și îi dă un mediu plin de detalii de conexiune, așa că tot ce a scris autorul rulează cu drepturile contului dumneavoastră. Pe un laptop unde utilizatorul este administrator, aceasta este o ușă largă pentru un fișier care a venit ca atașament sau lipit dintr-un fir de forum. Distincția nu este stilistică, este diferența dintre configurație și cod.

Mitul de care merită să scăpăm este că un profil poate doar redirecționa traficul. Un ajutor care execută ip route add și unul care execută curl către un host îndepărtat sunt același mecanism, iar profilul arată identic din exterior. Nimic din aspectul fișierului nu vă spune pe care îl aveți, de aceea revizuirea trebuie să ajungă la scriptul însuși.

Ce decide de fapt execuția și cum arată liniile care o permit

Trei lucruri controlează un ajutor: directiva de eveniment care îl numește, nivelul script-security care îl permite și implementarea proprie a platformei clientului. Un profil poate cere un cârlig și totuși să nu vadă nimic întâmplându-se, pentru că un client mobil sau o construcție de desktop redusă poate să nu implementeze deloc acel eveniment. La fel, un profil care cere mai multă permisiune decât are nevoie funcția lui vă spune ceva despre originea sa. Un nivel de permisiune este o capacitate, nu o aprobare. Liniile care o permit arată așa, cu o cale care stă în locul celei a dumneavoastră.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Nivelul 0 refuză programele externe, iar nivelul 1, cel implicit, permite doar fișierele executabile integrate ale clientului, deci un cârlig are nevoie de 2 sau mai mult; nivelul 3 există mai ales pentru transmiterea vechilor parole și e mai bine să fie evitat. Un profil livrat cu un cârlig are nevoie atât de directivă, cât și de acel nivel, de aceea o singură linie aproape de fundul fișierului merită aceeași examinare ca blocul de certificat. manualul OpenVPN enumeră nivelurile de permisiune, iar formularea lui merită citită alături de ceea ce cere profilul de fapt.

Proprietate, cale și cu ce este hrănit ajutorul

Un profil în care aveți încredere, dar care trimite la un script pe care alt cont îl poate rescrie, nu este o înțelegere de încredere, pentru că revizuirea de ieri nu mai descrie ce rulează astăzi. Verificați proprietarul și modul ajutorului și verificați că calea configurată duce la fișierul pe care l-ați inspectat, nu la un nume pe care altceva îl poate umbri. Argumentele și mediul merită aceeași privire: clientul transmite detalii de conexiune cârligului, iar un ajutor care înregistrează tot mediul său poate scrie credențiale într-un tichet de suport. Preferați o integrare documentată de la operator sau platformă unui script DNS copiat dintr-o postare nelegată, pentru că doi manageri de resolveri care se ceartă pe același fișier produc o defecțiune care arată ca un VPN stricat.

Când raportați un cârlig care eșuează, redactați mediul înainte de a-l lipi oriunde. Descărcarea care vă ajută la depanare poate purta și tokenul care vă autentifică.

Eșecurile de curățare apar după ce tunelul a dispărut

Un ajutor up adaugă rute și setări de resolver, iar ajutorul down ar trebui să le scoată din nou. Când cârligul down lipsește, eșuează în silențiu sau nu rulează niciodată pentru că clientul a fost omorât, resturile supraviețuiesc sesiunii. Traficul ia atunci o cale pe care nimeni nu a planificat-o și numele se rezolvă printr-un resolver care ar fi trebuit eliminat, în timp ce tunelul în sine pare sănătos. Aceste simptome apar după deconectare, de aceea e vinovată rețeaua, nu profilul.

Testați demontarea ca pas separat: ridicați tunelul, notați rutele și resolverul, coborâți-l, apoi confirmați că amândouă au dispărut. Un profil care se conectează curat poate lăsa totuși stare în urmă, iar un cod de ieșire zero al ajutorului nu dovedește că resolverul a ajuns unde credeți.

Revizuirea ajutorului și păstrarea unei ieșiri

Citiți scriptul de la început la sfârșit căutând trei lucruri: comenzi care au nevoie de privilegii, căi codificate fix care s-ar putea să nu existe pe sistemul dumneavoastră și orice apel de rețea pe care îl face. Apoi priviți cum eșuează, pentru că un ajutor care înghite erori transformă o greșeală de configurare într-un mister. Dacă nu puteți spune într-o propoziție ce face scriptul și cine îl poate modifica, nu sunteți gata să îl activați. Un profil care cere mai multe privilegii decât cere acea propoziție este semnalul de oprire.

Păstrați ultimul profil funcțional și ajutorul la care trimitea în stocare protejată, cu ambele versiuni notate, astfel încât o revenire să fie o copie și nu o reconstrucție în cel mai rău moment posibil. Dacă ajutorul există doar pentru o distribuție sau o versiune de client care nu mai are nevoie de el, retrageți-l în configurația care deține setarea în loc să ridicați privilegii până când erorile se opresc. Aceasta este ieșirea: mai puține piese mobile, nu mai multă permisiune.