Tegn den dekrypterede vej: hvor en VPN-enhed håndhæver politik

Leverandørers diagrammer stopper normalt ved den krypterede listener, fordi det er den del, der har en offentlig adresse. Spørgsmålet, der afgør sikkerhedspositionen, er, hvad der sker efter dekryptering, når pakken bliver almindelig IP og kan nå alt, hvad routingtabellen tillader. Hvis ingen har tegnet det ben, ejer ingen det. Runbooken nedenfor tegner det først og sammenligner derefter placeringer efter, hvad den dekrypterede anmodning faktisk krydser.

Tegn pakken efter dekryptering, ikke før

Den ydre vej er den del, leverandører dokumenterer: et offentligt endepunkt, en transportpolitik, der optager forbindelsen, og en tjeneste, der terminerer den. Den indre vej begynder i det øjeblik, pakken mister sin tunnelheader, og derfra styres den af routing- og filterregler, som intet har med tunnelen at gøre. Sæt begge på samme side, fordi et diagram med kun den første antyder, at optagelse og autorisation er én beslutning. Det er de ikke, og netop mellemrummet mellem dem er, hvor de fleste placeringer går galt.

Skriv det indre ben som en nummereret sekvens med navngivne enhedstyper i stedet for som en pil. En pil skjuler, om anmodningen krydser et filter, og krydser eller ikke krydser er hele spørgsmålet. Hvert hop nedenfor navngiver enheden og det regelsæt, der virker der, så et manglende filter fremstår som et hul i stedet for at være antydet af en linje.

1. Fjernklient: brugerens enhed, som opretter tunnelen.
2. Kantpolitik: det regelsæt, der optager den ydre transport til den offentlige listener.
3. Terminerende enhed: VPN-endepunktet, der dekapsulerer og overdrager pakken til almindelig IP.
4. Indre filter: regelsættet for videresendelse eller sikkerhedsgrupper, der begrænser trafik fra klient til tjeneste.
5. Applikationsvært: tjenesten, der modtager den dekrypterede anmodning.

To politikker, to ejere

Den ydre politik svarer på, hvem der må etablere en tunnel, og den udtrykkes i de regler, der optager transporten til den terminerende tjeneste. Den indre politik svarer på, hvilken tjeneste en autentificeret bruger må nå, og den lever i videresendelsesregler, sikkerhedsgrupper eller selve applikationen. Én enhed kan huse begge, og et design med flere enheder har stadig begge. Det er den særskilte navngivning, der gør det muligt at sige, hvilken der svigtede, når en bruger ikke kan nå en applikation.

Optagelseskontroller som certifikater og multifaktor-autentifikation svarer på identitet og intet andet. De afgør ikke placeringen og giver ikke tilladelse pr. ressource, når brugeren først er inde.

Placeringen afgør, hvilken grænse anmodningen krydser

Tre placeringer er almindelige, og hver især ændrer, hvilken grænse den dekrypterede anmodning krydser. Sammenlign dem efter, hvad der terminerer der, hvad der kan se klartekst, hvilken kontrol der stadig kan afvise anmodningen, og hvad der fejler sammen med enheden. Tabellen nedenfor bruger de fire kolonner i stedet for et generelt spørgsmål, fordi hvert svar er en særskilt designbeslutning.

Den tredje placering er den, der stille fjerner håndhævelsen, fordi et ben på det beskyttede segment giver enheden en direkte vej, som diagrammet måske ikke viser. Undersøg interfaces og ruter i stedet for billedet: ip route get 10.20.5.10 rapporterer, hvilket interface pakken ville forlade via, og svaret er ofte ikke det, designet antog. Firewallens klassiske rolle med at kontrollere trafik mellem positioner, som beskrevet iNIST SP 800-41, er en nyttig test her, fordi en enhed med et ubegrænset ben til det beskyttede netværk ikke kontrollerer meget. Et ruteopslag er et mere ærligt diagram end det i præsentationen.

Administration hører til på sin egen udtrykkeligt tilladte vej. At lade brugere nå en applikation kræver aldrig, at de kan nå enhedens kontrolinterface, og de to tilladelser bør gives fra forskellige regler. Revider begge veje separat, fordi en delt regel skjuler, hvilken der blev åbnet.

Oversættelse ændrer, hvad regler længere nede kan se

Kildeoversættelse er bekvemt, og det ødelægger information. Efter masquerade ser hver klient ud som enheden, så en regel længere nede, skrevet til at skelne brugere, kan ikke længere gøre det. Det er ikke kun et logproblem, det er et politikproblem: en regel, der er nøglet på klientadresse, bliver stille en regel, der er nøglet på gatewayen. Hvis politik pr. bruger betyder noget, så bevar kilden eller håndhæv politikken før oversættelse.

Svarvejen fortjener samme granskning. Noter, hvilken rute destinationen vælger til returpakken, fordi en asymmetrisk retur omgår stateful inspektion og giver en forbindelse, der etableres og derefter går i stå. Begge retninger skal krydse den grænse, du tegnede, ellers er grænsen dekoration.

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

Accepter en tilladt og en afvist handling

Test fra den rigtige fjernklient i stedet for fra en administrationsvært, fordi administrationsværten normalt sidder et sted, hvor brugeren aldrig kommer. Én tilladt handling beviser, at vejen virker, og én afvist handling beviser, at politikken overhovedet gør noget. Kør begge efter hver ændring af placeringen, og noter den kildeidentitet og destination, du brugte. En test, der kun beviser succes, kan ikke skelne en korrekt regel fra en manglende.

Test derefter de tilfælde, der ændrer tilstand: en genopkobling, en session, der overlever en nøglerotation, og en fejl i selve enheden. Sammenlign opdateringer, kapacitet og genopretning som en del af samme layout, fordi én enhed, der holder flere logiske kontroller, er ét fejldomæne med flere etiketter. En ekstra boks er heller ikke uafhængig, når en delt administrativ adgang eller en ubegrænset rute besejrer den grænse, den skulle skabe.

Dokumentér endepunktet, den dekrypterede vej og den kontrol, der begrænser den. De tre linjer forbliver meningsfulde, uanset hvad implementeringen kaldes.