O regulă de firewall refuză traficul căruia îi corespunde. Ea nu refuză orice utilizare a unei conexiuni pe care o permite, iar în această lacună eșuează majoritatea politicilor împotriva tunelurilor neautorizate. Blocarea porturilor clientului care era popular acum cinci ani lasă neatinse tot ce trece prin 443 și nu spune nimic despre un dispozitiv care își poate rescrie propriile rute. Construiți controlul în jurul autorității și al destinațiilor, apoi citiți fluxurile pe care le permiteți cu adevărat.

De ce o listă de porturi nu este o politică

Porturile sunt un concept al stratului de transport, iar mai multe tehnologii de tunel nu folosesc niciunul. Altele partajează intenționat un port cu traficul web obișnuit, pentru că acel port este cel care trece garantat. O regulă bazată pe un port istoric enumeră așadar o mână de implementări în loc de clasa de comportament. Îmbătrânește și prost: în momentul în care un furnizor schimbă valorile implicite, lista descrie trecutul.

Mai rău, un blocaj reușit pe un port poate fi citit ca dovadă că întreaga problemă este rezolvată, ceea ce amână controalele care ar fi contat.

Numerele de protocol și porturile sunt spații de nume diferite

GRE primește numărul de protocol IP 47. Nu este portul TCP 47 și nu este portul UDP 47, iar un filtru scris pentru un port nu îl atinge. ESP și AH se află pe numerele de protocol 50 și 51 cu aceeași proprietate. Traficul încapsulat se poate ascunde și în interiorul unei conexiuni permise, motiv pentru care o categorie sau o semnătură poate ajuta, dar nu certifică niciodată scopul de una singură. Încrederea și acoperirea aparțin unui anumit produs și unei anumite versiuni, nu conceptului.

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

Prima comandă arată ce ați scris de fapt; a doua arată tabelul de protocoale pe care îl cunoaște stiva; a treia arată câte sesiuni folosesc portul web chiar acum. Niciuna dintre ele nu spune la ce servesc aceste sesiuni. Interceptarea TLS este o decizie separată, cu propriile costuri de încredere, confidențialitate și compatibilitate cu clienții. Nu este o condiție prealabilă pentru a refuza o destinație numită și nu este nici o garanție a recunoașterii tunelurilor.

Controlați autoritatea pe care o are dispozitivul

Un dispozitiv care își poate schimba propriul tabel de rutare și filtrarea are capacități pe care o aplicație obișnuită nu le are. Gestionarea admiterii și a configurației este ceea ce elimină această capacitate și acționează indiferent de portul pe care l-ar folosi tunelul.

Asta înseamnă că atașamentele aprobate primesc rolul lor declarat în loc de permisiune nelimitată de a redirecționa pentru alte dispozitive și înseamnă că drepturile de instalare și de administrare a rețelei fac parte din politică în loc să fie un gând ulterior.

Observați fluxurile care rămân. Corelați identitatea dispozitivului, rolul atribuit și metadatele fluxului și tratați clasificarea ca dovadă cu limite, nu ca verdict.

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

O sesiune criptată de lungă durată sau un număr mare de octeți nu este dovadă de abuz: copiile de rezervă, instrumentele de suport și legăturile dintre locații arată la fel. Limitați colectarea la investigație și păstrați ce găsiți sub procesul care îl deține.

Faceți excepțiile explicite

Fiecare mediu are destinații care trebuie să rămână accesibile pentru actualizări, autentificare și recuperare. Notați-le cu un scop și un responsabil și revizuiți-le în loc să le descoperiți o pană după alta.

Când afacerea permite cu adevărat un serviciu extern larg, evaluați autoritatea pe care o oferă acel serviciu, în loc să presupuneți că eticheta destinației face orice utilizare acceptabilă.

O excepție nerevizuită este o gaură cu un număr de tichet. O excepție cu un nume, un motiv și o dată de revizuire este o decizie.

Acceptați cu un plan scris, nu cu un slogan

Acceptarea are două jumătăți: munca aprobată reușește în continuare, iar cazurile interzise concrete eșuează într-un test autorizat. Ambele trebuie scrise înainte de schimbare și repetate după ea.

Includeți în acea revizuire modificările de punct final și de politică, pentru că o rută adăugată pe un laptop poate anula un filtru care funcționa perfect la margine.

Rezultatul este o limită de ieșire deținută, cu o listă cunoscută de risc rămas. A afirma că câteva porturi închise au pus capăt utilizării neautorizate a VPN nu este asta.

Articole similare