Tegn den dekrypterte veien: hvor en VPN-enhet håndhever policy

Leverandørdiagrammer stopper vanligvis ved den krypterte lytteren, fordi det er delen med en offentlig adresse. Spørsmålet som avgjør sikkerhetsposisjonen, er hva som skjer etter dekryptering, når pakken blir vanlig IP og kan nå alt som rutetabellen tillater. Hvis ingen har tegnet den delen, eier ingen den. Runbooken nedenfor tegner den først og sammenligner deretter plasseringene etter hva den dekrypterte forespørselen faktisk krysser.

Tegn pakken etter dekryptering, ikke før

Den ytre veien er delen leverandører dokumenterer: et offentlig endepunkt, en transportpolicy som slipper forbindelsen inn, og en tjeneste som terminerer den. Den indre veien begynner i det øyeblikket pakken mister tunnelheaderen, og derfra styres den av ruting- og filterregler som ikke har noe med tunnelen å gjøre. Sett begge på samme side, fordi et diagram med bare den første antyder at opptak og autorisasjon er én beslutning. Det er de ikke, og nettopp gapet mellom dem er der de fleste plasseringene går galt.

Skriv den indre delen som en nummerert sekvens med navngitte enhetstyper i stedet for en pil. En pil skjuler om forespørselen krysser et filter, og krysser eller ikke krysser er hele spørsmålet. Hvert hopp nedenfor navngir enheten og regelsettet som virker der, slik at et manglende filter fremstår som et hull i stedet for å være antydet av en linje.

1. Fjernklient: brukerens enhet som oppretter tunnelen.
2. Kantpolicy: regelsettet som slipper den ytre transporten inn til den offentlige lytteren.
3. Terminerende enhet: VPN-endepunktet som dekapsulerer og overleverer pakken til vanlig IP.
4. Indre filter: regelsettet for videresending eller sikkerhetsgrupper som begrenser trafikk fra klient til tjeneste.
5. Applikasjonsvert: tjenesten som mottar den dekrypterte forespørselen.

To policyer, to eiere

Den ytre policyen svarer på hvem som kan etablere en tunnel, og den uttrykkes i reglene som slipper transporten inn til den terminerende tjenesten. Den indre policyen svarer på hvilken tjeneste en autentisert bruker kan nå, og den lever i videresendingsregler, sikkerhetsgrupper eller selve applikasjonen. Én enhet kan huse begge, og et design med flere enheter har fortsatt begge. Det er den separate navngivningen som gjør det mulig å si hvilken som sviktet når en bruker ikke når en applikasjon.

Opptakskontroller som sertifikater og multifaktorautentisering svarer på identitet og ingenting annet. De avgjør ikke plasseringen og gir ikke tillatelse per ressurs når brukeren først er innenfor.

Plasseringen avgjør hvilken grense forespørselen krysser

Tre plasseringer er vanlige, og hver endrer hvilken grense den dekrypterte forespørselen krysser. Sammenlign dem etter hva som terminerer der, hva som kan se klartekst, hvilken kontroll som fortsatt kan avslå forespørselen, og hva som feiler sammen med enheten. Tabellen nedenfor bruker de fire kolonnene i stedet for et generelt spørsmål, fordi hvert svar er en egen designbeslutning.

Den tredje plasseringen er den som stille fjerner håndhevelsen, fordi en del på det beskyttede segmentet gir enheten en direkte vei som diagrammet kanskje ikke viser. Undersøk grensesnitt og ruter i stedet for bildet: ip route get 10.20.5.10 rapporterer hvilket grensesnitt pakken ville forlate via, og svaret er ofte ikke det designet antok. Brannmurens klassiske rolle med å kontrollere trafikk mellom posisjoner, som beskrevet iNIST SP 800-41, er en nyttig test her, fordi en enhet med en ubegrenset del til det beskyttede nettet ikke kontrollerer stort. Et ruteoppslag er et ærligere diagram enn det i presentasjonen.

Administrasjon hører hjemme på sin egen uttrykkelig tillatte vei. Å la brukere nå en applikasjon krever aldri å la dem nå enhetens kontrollgrensesnitt, og de to tillatelsene bør gis fra forskjellige regler. Revider begge veiene separat, fordi en delt regel skjuler hvilken som ble åpnet.

Oversettelse endrer hva regler lenger nede kan se

Kildeoversettelse er praktisk, og det ødelegger informasjon. Etter masquerade ser hver klient ut som enheten, så en regel lenger nede som ble skrevet for å skille brukere, kan ikke lenger gjøre det. Dette er ikke bare et loggproblem, det er et policyproblem: en regel nøklet på klientadresse blir stille en regel nøklet på gatewayen. Hvis policy per bruker betyr noe, bevar kilden eller håndhev policyen før oversettelse.

Svarveien fortjener samme gransking. Noter hvilken rute destinasjonen velger for returpakken, fordi en asymmetrisk retur omgår tilstandsbasert inspeksjon og gir en forbindelse som etableres og deretter stopper. Begge retninger må krysse grensen du tegnet, ellers er grensen dekorasjon.

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

Godta én tillatt og én avvist operasjon

Test fra den ekte fjernklienten i stedet for fra en administrasjonsvert, fordi administrasjonsverten vanligvis sitter et sted brukeren aldri vil være. Én tillatt operasjon beviser at veien virker, og én avvist beviser at policyen i det hele tatt gjør noe. Kjør begge etter hver plasseringsendring, og noter kildeidentiteten og destinasjonen du brukte. En test som bare beviser suksess, kan ikke skille en riktig regel fra en manglende.

Test deretter tilfellene som endrer tilstand: en gjenoppkobling, en økt som overlever en nøkkelrotasjon, og en feil i selve enheten. Sammenlign oppdateringer, kapasitet og gjenoppretting som del av samme oppsett, fordi én enhet som holder flere logiske kontroller, er ett feildomene med flere etiketter. En ekstra boks er heller ikke uavhengig når en delt administrativ pålogging eller en ubegrenset rute beseirer grensen den skulle skape.

Dokumenter endepunktet, den dekrypterte veien og kontrollen som begrenser den. De tre linjene forblir meningsfulle uansett hva implementasjonen kalles.