Na ontsleuteling: welk beleid ziet jouw VPN-verkeer als eerste
De kabel zegt niets over welke regel de stroom heeft verwerkt. Noem de beleidshook en de volgende hop, en bewijs dat het antwoord dezelfde route volgt.
Een VPN-stroom kan perfect versleuteld en perfect geauthenticeerd zijn en toch belanden waar niemand het had gepland. De kabel die je insteekt bepaalt niet welke regel het binnenste pakket verwerkt; dat doen de beleidshook en de route. Twee ontwerpen die op een rackdiagram identiek lijken, kunnen dus een heel andere handhaving hebben. Kiezen tussen beide begint met het benoemen van de controle die de ontsleutelde stroom als eerste ziet.
Beslis op de beleidshook, niet op de poort
Elk VPN-platform beoordeelt ontsleuteld verkeer op een bepaald punt voordat het wordt doorgestuurd, en dat punt heeft een naam in de configuratie. Op het ene platform is het een groepbeleidsfilter, op het andere een interfacebeleid of een zonepaar, en op een router kan het simpelweg de forward-keten zijn. De hook handhaaft de regel, terwijl de switchpoort alleen de plek is waar de kabel eindigt. De hook vinden is de eerste beslissing, want al het andere is plaatsing ten opzichte daarvan.
Voordat je naar hardware kijkt, schrijf de stroom op: wie de bron is, waar die heen gaat, welk protocol hem draagt en welke dienst is toegestaan. Zoek daarna de controle die elk van die vier feiten handhaaft.
Twee wegen, twee verschillende handhavingsverhalen
Twee vormen komen vaak voor en elk kan juist zijn voor een andere eis.
endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnetDe eerste vorm kan alles wat nodig is op de gateway handhaven, mits het gatewaybeleid voor die bestemming is geschreven en de server geen weg eromheen heeft. De tweede vorm voegt een grens toe, maar alleen als de routes en het beleid het verkeer er echt doorheen sturen. Een server op hetzelfde segment als het eindpunt volgt misschien nooit de bedachte tussenstap. Het diagram toont de bedoeling en de routetabel toont wat er gebeurt.
Verifieer met een routeopzoeking en niet met de tekening. De interface waarlangs een pakket vertrekt en de volgende hop die het kiest, bepalen of de tweede vorm zich gedraagt zoals ontworpen.
ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20Scheid topologie van isolatie
Een subnet delen maakt een plek niet onbetrouwbaar, en een toegewijde transit maakt die niet beschermd. Wat beslist is de beperking die feitelijk wordt toegepast, de doorsturing die feitelijk gebeurt en wie elk deel beheert. Switches tellen zegt niets over een van de drie. Beslis vanuit het beleid en de route, en laat de topologie de beslissing volgen.
Behandel verkeerspopulaties ook apart. Pools voor toegang op afstand, site-naar-site-prefixen en netwerken met particuliere lijnen kunnen één apparaat delen en toch verschillende regels nodig hebben, omdat hun identiteit en risico verschillen. Een regel die voor één populatie is geschreven, dekt de andere stilzwijgend als ze een adresplan delen.
Controleer falen en beheer per plaatsing
Elke plaatsing heeft een faalmodus, en de nuttige vraag is wat nog werkt als een component stopt. Meerdere logische interfaces op één dood apparaat geven geen onafhankelijk herstel, en een stroomafwaartse firewall met dezelfde voeding of dezelfde beheerder is geen tweede grens. Vraag waar het beheerpad loopt, want een console die alleen via de tunnel bereikbaar is, is helemaal geen herstelpad; ssh [email protected] true van buiten de tunnel is de goedkoopste manier om te bewijzen dat de console daar niet van afhangt. De documentatie over groepbeleid van één platform zet het filter op verkeer na ontsleuteling en voor versleuteling, precies het soort benoemde hook dat je in elk product moet zoeken.
Schrijf het faalverhaal van elke kandidaat naast het handhavingsverhaal. Een plaatsing die wint op inspectie en verliest op herstel is een ruil, en die moet als zodanig worden vastgelegd in plaats van te worden ontdekt tijdens een incident.
Accepteer met een toegestane en een geweigerde stroom
Met een goedgekeurd testplan controleer je drie dingen vanuit de echte VPN-bron: een toepassing die zou moeten werken, een bron die dat niet zou moeten, en de richting waarin het antwoord terugkomt. De weigering is het bewijs dat het beleid actief is, terwijl de toegestane stroom alleen bewijst dat er een pad is.
Bewaar het gekozen pad en het resultaat van het beleid samen, want een resultaat zonder pad is niet reproduceerbaar en een pad zonder resultaat is niet verdedigbaar. Dat paar is veel nuttiger voor het kiezen van een aansluitpunt dan welke bewering dan ook over welke schakellaag van nature veiliger is.