Teken het ontsleutelde pad: waar een VPN-appliance beleid afdwingt
Een diagram dat bij de versleutelde listener stopt, toont niet het beleid dat ertoe doet. Teken het ontsleutelde pad en vergelijk daarna de plaatsingen op wat het verzoek passeert.
Leveranciersdiagrammen stoppen meestal bij de versleutelde listener, omdat dat het deel met een openbaar adres is. De vraag die de beveiligingspositie bepaalt, is wat er na ontsleuteling gebeurt, wanneer het pakket gewoon IP wordt en alles kan bereiken wat de routingtabel toestaat. Als niemand dat been heeft getekend, is er geen eigenaar. De runbook hieronder tekent het eerst en vergelijkt daarna de plaatsingen op wat het ontsleutelde verzoek werkelijk passeert.
Teken het pakket na ontsleuteling, niet ervoor
Het buitenste pad is het deel dat leveranciers documenteren: een openbaar eindpunt, een transportbeleid dat de verbinding toelaat, en een dienst die hem termineert. Het binnenste pad begint op het moment dat het pakket zijn tunnelheader verliest, en van daaraf wordt het bestuurd door routing- en filterregels die niets met de tunnel te maken hebben. Zet beide op dezelfde pagina, want een diagram met alleen het eerste suggereert dat toelating en autorisatie één beslissing zijn. Dat zijn ze niet, en juist de kloof ertussen is waar de meeste plaatsingen misgaan.
Schrijf het binnenste been als een genummerde reeks met benoemde apparaattypen in plaats van als een pijl. Een pijl verbergt of het verzoek een filter passeert, en passeren of niet is de hele vraag. Elke stap hieronder noemt het apparaat en de regelset die daar werkt, zodat een ontbrekend filter als een gat verschijnt in plaats van door een lijn te worden gesuggereerd.
- Externe client: het gebruikersapparaat dat de tunnel opzet.
- Randbeleid: de regelset die het buitenste transport naar de openbare listener toelaat.
- Terminerende appliance: het VPN-eindpunt dat decapsuleert en het pakket aan gewoon IP overhandigt.
- Binnenfilter: de regelset voor doorsturen of beveiligingsgroepen die verkeer van client naar dienst beperkt.
- Applicatiehost: de dienst die het ontsleutelde verzoek ontvangt.
Twee beleidsregels, twee eigenaren
Het buitenbeleid beantwoordt wie een tunnel mag opzetten, en het wordt uitgedrukt in de regels die het transport naar de terminerende dienst toelaten. Het binnenbeleid beantwoordt welke dienst een geauthenticeerde gebruiker mag bereiken, en het leeft in doorstuurregels, beveiligingsgroepen of de applicatie zelf. Eén apparaat kan beide huisvesten, en een ontwerp met meerdere apparaten heeft nog steeds beide. Juist het apart benoemen maakt het mogelijk te zeggen welke faalde wanneer een gebruiker een applicatie niet bereikt.
Toelatingscontroles zoals certificaten en multifactorauthenticatie beantwoorden identiteit en niets anders. Ze bepalen de plaatsing niet en verlenen geen toestemming per resource zodra een gebruiker binnen is.
De plaatsing bepaalt welke grens het verzoek passeert
Drie plaatsingen zijn gebruikelijk, en elk verandert welke grens het ontsleutelde verzoek passeert. Vergelijk ze op wat daar termineert, wat platte tekst kan zien, welke controle het verzoek nog kan weigeren, en wat samen met de appliance uitvalt. De tabel hieronder gebruikt die vier kolommen in plaats van een algemene vraag, omdat elk antwoord een aparte ontwerpbeslissing is.
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
De derde plaatsing is degene die handhaving stilzwijgend wegneemt, omdat een been op het beschermde segment de appliance een directe route geeft die het diagram misschien niet toont. Inspecteer interfaces en routes in plaats van de afbeelding: ip route get 10.20.5.10 meldt via welke interface het pakket zou vertrekken, en het antwoord is vaak niet dat het ontwerp aannam. De klassieke rol van de firewall om verkeer tussen houdingen te beheersen, zoals beschreven inNIST SP 800-41, is hier een nuttige test, want een apparaat met een onbeperkt been naar het beschermde netwerk beheerst niet veel. Een routeopzoeking is een eerlijker diagram dan dat in de presentatie.
Beheer hoort op zijn eigen uitdrukkelijk toegestane pad. Gebruikers een applicatie laten bereiken vereist nooit dat zij de beheerinterface van de appliance mogen bereiken, en de twee rechten moeten uit verschillende regels worden gegeven. Controleer beide paden apart, want een gedeelde regel verbergt welke is geopend.
Vertaling verandert wat regels verderop kunnen zien
Bronvertaling is handig en het vernietigt informatie. Na masquerade ziet elke client eruit als de appliance, dus een regel verderop die is geschreven om gebruikers te onderscheiden, kan dat niet meer. Dat is niet alleen een logprobleem, het is een beleidsprobleem: een regel die op het clientadres is gesleuteld, wordt stilzwijgend een regel die op de gateway is gesleuteld. Als beleid per gebruiker ertoe doet, behoud dan de bron of dwing het beleid af vóór de vertaling.
Het antwoordpad verdient dezelfde aandacht. Noteer welke route de bestemming kiest voor het retourpakket, want een asymmetrische retour omzeilt stateful inspectie en levert een verbinding op die tot stand komt en daarna vastloopt. Beide richtingen moeten de grens passeren die je hebt getekend, anders is de grens decoratie.
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGAccepteer één toegestane en één geweigerde bewerking
Test vanaf de echte externe client en niet vanaf een beheerhost, want de beheerhost zit meestal ergens waar de gebruiker nooit zal zijn. Eén toegestane bewerking bewijst dat het pad werkt, en één geweigerde bewijst dat het beleid überhaupt iets doet. Voer beide uit na elke plaatsingswijziging, en noteer de bronidentiteit en bestemming die je hebt gebruikt. Een test die alleen succes bewijst, kan een juiste regel niet van een ontbrekende onderscheiden.
Test daarna de gevallen die de toestand veranderen: een herverbinding, een sessie die een sleutelrotatie overleeft, en een storing van de appliance zelf. Vergelijk updates, capaciteit en herstel als onderdeel van dezelfde opzet, want één appliance met meerdere logische controles is één storingsdomein met meerdere labels. Een tweede doos is ook niet onafhankelijk wanneer een gedeelde beheersreferentie of een onbeperkte route de grens verslaat die hij moest creëren.
Documenteer het eindpunt, het ontsleutelde pad en de controle die het beperkt. Die drie regels blijven betekenisvol hoe de implementatie ook heet.