Cum să limităm accesul între două birouri conectate prin VPN

Un tunel de la site la site răspunde la o întrebare, dacă cele două birouri pot schimba pachete, și lasă deschisă întrebarea importantă: ce dispozitiv al sucursalei poate ajunge la ce serviciu central. Tratarea tunelului ca încredere reciprocă este modul în care un laptop de oaspete ajunge pe aceeași rută ca serverul financiar. Soluția nu este un tunel mai bun, ci o listă explicită de permisiuni aplicată după decriptare. Acest ghid duce lista de la definiție la o respingere dovedită.

Lucrați în această ordine și nu lărgiți ruta tunelului până când pașii de politică de mai jos nu trec.

Scrieți matricea înainte de a atinge gateway-ul

O linie utilă numește trei lucruri: un grup sursă, un host sau o rețea de serviciu destinație, și protocolul și portul pe care aplicația le folosește efectiv. Sucursala și centrul de date nu sunt intrări. DNS-ul privat și serviciile de autentificare merită linii proprii doar când aplicația nu poate funcționa fără ele.

Grupați sursele după rol și nu după comoditatea subrețelei: personal, oaspeți, administrare. Când toate trei împart un LAN plat, gateway-ul nu le poate distinge la nivel de rețea, așa că controalele de identitate sau segmentarea trebuie să vină primele. Apoi puneți matricea în scris, cu un proprietar și o dată de revizuire pe fiecare linie.

Aplicați acolo unde pachetele sunt decriptate

Regulile care permit IKE și ESP construiesc doar tunelul exterior. Traficul intern ajunge în clar pe interfața tunelului, și acolo își are locul lista de permisiuni: un lanț de redirecționare pe dispozitivul care decriptează, eliminare implicită, o regulă pentru fiecare linie a matricei. Pe gateway-urile Linux asta înseamnă redirecționare activată și reguli de filtrare pe dispozitivul tunelului, nu pe legătura fizică, cum explică ghidul de redirecționare strongSwan.

Selectorii de trafic sunt o decizie de rutare, nu de autorizare. Un selector larg care acoperă ambele subrețele poate fi corect pentru rutare în timp ce firewall-ul permite în continuare doar TCP 443 către un host. Selectorul este negociat pentru tunel și descrie ce poate intra în el, nu ce poate folosi un anumit dispozitiv. Nu lărgiți niciodată o regulă de firewall pentru că selectorul este larg.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT și subrețelele suprapuse schimbă regulile

Când gateway-ul sucursalei traduce fiecare host într-o singură adresă înainte de tunel, fiecare linie bazată pe sursă se prăbușește în acea singură adresă. Fie opriți traducerea traficului tunelului, fie acceptați că regulile trebuie să se sprijine pe altceva, cum ar fi adresa sursă originală înregistrată înainte de traducere. Capătul îndepărtat are aceeași problemă, pentru că hostul destinație vede adresa de după NAT și nu pe cea originală.

Intervalele suprapuse sunt cealaltă capcană. Două birouri care folosesc amândouă 192.168.1.0/24 nu pot fi descrise într-un singur tabel de politică fără a mapa o parte, iar maparea nu înlocuiește o adresare care nu se ciocnește. Corectați planul înainte de a scrie reguli pe care va trebui să le desfaceți mai târziu.

Dovediți o respingere, nu doar un succes

Testarea doar a aplicației permise dovedește foarte puțin, pentru că o regulă permisivă undeva mai sus produce același rezultat.

Dintr-un dispozitiv obișnuit al sucursalei, ajungeți la serviciul dorit și confirmați că întreaga sesiune funcționează. Apoi încercați o destinație care trebuie să rămână închisă, cum ar fi un port administrativ pe un server cu care sucursala nu are nicio treabă, și citiți contorul sau intrarea din jurnal care a eliminat-o. Dezactivarea setului de reguli pentru a verifica dacă funcționează invalidează testul și lasă gateway-ul deschis cât timp priviți.

Țineți lista vie

Aplicațiile se mută, iar o regulă care supraviețuiește aplicației sale devine o gaură pe care nimeni nu o deține. Legați data de revizuire de linie și schimbați sfera selectorului și regula de firewall în același pas de întreținere când un serviciu își schimbă adresa.

Restricțiile la nivel de host contează în continuare în spatele tunelului: firewall-ul propriu al serverului ar trebui să accepte intervalul sucursalei doar pentru serviciul pe care îl publică. Două straturi care sunt de acord sunt mai ușor de auditat decât unul singur în care se are încredere deplină.