Diagramele furnizorilor se opresc de obicei la listenerul criptat, pentru că aceea este partea cu adresă publică. Întrebarea care decide postura de securitate este ce se întâmplă după decriptare, când pachetul devine IP obișnuit și poate ajunge oriunde permite tabela de rutare. Dacă nimeni nu a desenat acel segment, nimeni nu îl deține. Runbook-ul de mai jos îl desenează mai întâi și apoi compară plasările după ce traversează efectiv cererea decriptată.

Desenați pachetul după decriptare, nu înainte

Calea exterioară este partea pe care furnizorii o documentează: un endpoint public, o politică de transport care admite conexiunea și un serviciu care o termină. Calea interioară începe în momentul în care pachetul pierde antetul tunelului, iar de acolo este guvernată de reguli de rutare și filtrare care nu au nimic de-a face cu tunelul. Puneți ambele pe aceeași pagină, pentru că o diagramă doar cu prima sugerează că admiterea și autorizarea sunt o singură decizie. Nu sunt, iar decalajul dintre ele este locul unde majoritatea plasărilor greșesc.

Scrieți segmentul interior ca o secvență numerotată cu tipuri de dispozitiv numite, nu ca o săgeată. O săgeată ascunde dacă cererea traversează un filtru, iar traversarea sau nu este toată întrebarea. Fiecare pas de mai jos numește dispozitivul și setul de reguli care acționează acolo, astfel încât un filtru lipsă apare ca o lipsă, nu ca ceva sugerat de o linie.

  1. Client la distanță: dispozitivul utilizatorului care creează tunelul.
  2. Politica de margine: setul de reguli care admite transportul exterior către listenerul public.
  3. Appliance-ul de terminare: endpointul VPN care decapsulează și predă pachetul către IP obișnuit.
  4. Filtrul intern: setul de reguli de forwardare sau de grupuri de securitate care limitează traficul de la client la serviciu.
  5. Gazda aplicației: serviciul care primește cererea decriptată.

Două politici, doi proprietari

Politica exterioară răspunde cine poate stabili un tunel și este exprimată în regulile care admit transportul către serviciul de terminare. Politica interioară răspunde la ce serviciu poate ajunge un utilizator autentificat și trăiește în regulile de forwardare, în grupurile de securitate sau în aplicația însăși. Un singur dispozitiv le poate găzdui pe amândouă, iar un proiect cu mai multe dispozitive le are tot pe amândouă. Tocmai numirea lor separată vă permite să spuneți care a eșuat când un utilizator nu ajunge la o aplicație.

Controalele de admitere precum certificatele și autentificarea multifactor răspund la identitate și la nimic altceva. Nu decid plasarea și nu acordă permisiune pe resursă după ce utilizatorul este înăuntru.

Plasarea decide ce graniță traversează cererea

Trei plasări sunt obișnuite și fiecare schimbă ce graniță traversează cererea decriptată. Comparați-le după ce se termină acolo, ce poate vedea textul clar, ce control mai poate refuza cererea și ce cade împreună cu appliance-ul. Tabelul de mai jos folosește aceste patru coloane în locul unei întrebări generale, pentru că fiecare răspuns este o decizie de proiectare separată.

PlacementWhat terminates thereWhat sees plaintextWhich control can still denyFailure domain
Termination in a dedicated segmentA dedicated VPN endpointThe endpoint and anything on its segmentThe filter between that segment and the applicationThe segment path can bypass the filter if no rule sits on it
Termination on the edge firewallThe firewall's public listenerThe firewall, after decapsulationThe firewall's inner rule setAdmission and inspection fail together
Termination on the protected LANThe appliance's LAN legEvery host on the protected LANOnly a host control or a downstream gatewayThe appliance and the protected hosts fail together

A treia plasare este cea care elimină în tăcere aplicarea, pentru că un segment pe rețeaua protejată îi dă appliance-ului o cale directă pe care diagrama poate nu o arată. Inspectați interfețele și rutele, nu imaginea: ip route get 10.20.5.10 raportează prin ce interfață ar pleca pachetul, iar răspunsul nu este adesea cel presupus de proiectare. Rolul clasic al firewall-ului de a controla traficul între posturi, așa cum este descris înNIST SP 800-41, este un test util aici, pentru că un dispozitiv cu un segment nelimitat către rețeaua protejată nu controlează mare lucru. O interogare de rută este o diagramă mai onestă decât cea din prezentare.

Administrarea aparține propriei căi permise explicit. A permite utilizatorilor să ajungă la o aplicație nu cere niciodată să le permiți să ajungă la interfața de control a appliance-ului, iar cele două permisiuni ar trebui acordate din reguli diferite. Auditați ambele căi separat, pentru că o regulă comună ascunde care a fost deschisă.

Traducerea schimbă ce pot vedea regulile din aval

Traducerea sursei este comodă și distruge informație. După masquerade fiecare client arată ca appliance-ul, așa că o regulă din aval scrisă pentru a distinge utilizatori nu mai poate face asta. Nu este doar o problemă de loguri, este o problemă de politică: o regulă legată de adresa clientului devine în tăcere o regulă legată de gateway. Dacă politica pe utilizator contează, păstrați sursa sau aplicați politica înainte de traducere.

Calea de răspuns merită aceeași examinare. Înregistrați ce rută alege destinația pentru pachetul de retur, pentru că o întoarcere asimetrică ocolește inspecția cu stare și produce o conexiune care se stabilește și apoi se blochează. Ambele direcții trebuie să traverseze granița pe care ați desenat-o, altfel granița este decor.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Acceptați o operație permisă și una refuzată

Testați din clientul la distanță real, nu dintr-un host de administrare, pentru că hostul de administrare stă de obicei unde utilizatorul nu va fi niciodată. O operație permisă dovedește că calea funcționează, iar una refuzată dovedește că politica face ceva. Rulați ambele după fiecare schimbare de plasare și înregistrați identitatea sursei și destinația folosite. Un test care dovedește doar succesul nu poate distinge o regulă corectă de una lipsă.

Apoi testați cazurile care schimbă starea: o reconectare, o sesiune care supraviețuiește unei rotații de chei și o defecțiune a appliance-ului însuși. Comparați actualizările, capacitatea și recuperarea ca parte a aceleiași scheme, pentru că un appliance care ține mai multe controale logice este un singur domeniu de defecțiune cu mai multe etichete. Nici a doua cutie nu este independentă când o acreditare administrativă partajată sau o rută nelimitată învinge granița pe care trebuia să o creeze.

Documentați endpointul, calea decriptată și controlul care o restricționează. Acele trei linii rămân semnificative oricum s-ar numi implementarea.

Articole similare