Rita den dekrypterade vägen: där en VPN-enhet tillämpar policy

Leverantörsdiagram stannar vanligtvis vid den krypterade lyssnaren, eftersom det är delen med en offentlig adress. Frågan som avgör säkerhetsläget är vad som händer efter dekryptering, när paketet blir vanlig IP och kan nå allt som routingtabellen tillåter. Om ingen har ritat den delen äger ingen den. Runbooken nedan ritar den först och jämför sedan placeringarna efter vad den dekrypterade begäran faktiskt korsar.

Rita paketet efter dekryptering, inte före

Den yttre vägen är delen som leverantörer dokumenterar: en offentlig ändpunkt, en transportpolicy som släpper in anslutningen och en tjänst som avslutar den. Den inre vägen börjar i samma stund som paketet tappar tunnelhuvudet, och därifrån styrs den av routing- och filterregler som inte har något med tunneln att göra. Sätt båda på samma sida, eftersom ett diagram med bara den första antyder att intag och auktorisering är ett enda beslut. Det är de inte, och just gapet mellan dem är där de flesta placeringar går fel.

Skriv den inre delen som en numrerad sekvens med namngivna enhetstyper i stället för som en pil. En pil döljer om begäran korsar ett filter, och korsar eller inte är hela frågan. Varje hopp nedan namnger enheten och regelverket som verkar där, så ett saknat filter framträder som en lucka i stället för att antydas av en linje.

1. Fjärrklient: användarens enhet som skapar tunneln.
2. Kantpolicy: regelverket som släpper in den yttre transporten till den offentliga lyssnaren.
3. Avslutande enhet: VPN-ändpunkten som dekapsulerar och lämnar paketet till vanlig IP.
4. Inre filter: regelverket för vidarebefordran eller säkerhetsgrupper som begränsar trafik från klient till tjänst.
5. Applikationsvärd: tjänsten som tar emot den dekrypterade begäran.

Två policyer, två ägare

Den yttre policyn svarar på vem som får upprätta en tunnel, och den uttrycks i reglerna som släpper in transporten till den avslutande tjänsten. Den inre policyn svarar på vilken tjänst en autentiserad användare får nå, och den lever i vidarebefordringsregler, säkerhetsgrupper eller själva applikationen. En enhet kan hysa båda, och en design med flera enheter har fortfarande båda. Det är den separata namngivningen som gör det möjligt att säga vilken som svek när en användare inte når en applikation.

Intagskontroller som certifikat och multifaktorautentisering svarar på identitet och ingenting annat. De avgör inte placeringen och ger inte behörighet per resurs när användaren väl är inne.

Placeringen avgör vilken gräns begäran korsar

Tre placeringar är vanliga, och var och en ändrar vilken gräns den dekrypterade begäran korsar. Jämför dem efter vad som avslutas där, vad som kan se klartext, vilken kontroll som fortfarande kan neka begäran och vad som fallerar tillsammans med enheten. Tabellen nedan använder de fyra kolumnerna i stället för en allmän fråga, eftersom varje svar är ett eget designbeslut.

Den tredje placeringen är den som tyst tar bort tillämpningen, eftersom en del på det skyddade segmentet ger enheten en direkt väg som diagrammet kanske inte visar. Granska gränssnitt och rutter i stället för bilden: ip route get 10.20.5.10 rapporterar vilket gränssnitt paketet skulle lämna via, och svaret är ofta inte det designen antog. Brandväggens klassiska roll att kontrollera trafik mellan positioner, som beskrivs iNIST SP 800-41, är ett användbart test här, eftersom en enhet med en obegränsad del till det skyddade nätet inte kontrollerar särskilt mycket. En ruttuppslagning är ett ärligare diagram än det i presentationen.

Administration hör hemma på sin egen uttryckligen tillåtna väg. Att låta användare nå en applikation kräver aldrig att de får nå enhetens kontrollgränssnitt, och de två behörigheterna bör ges från olika regler. Granska båda vägarna separat, eftersom en delad regel döljer vilken som öppnades.

Översättning ändrar vad regler längre ned kan se

Källöversättning är bekvämt och det förstör information. Efter masquerade ser varje klient ut som enheten, så en regel längre ned skriven för att skilja användare åt kan inte längre göra det. Det är inte bara ett loggproblem, det är ett policyproblem: en regel nycklad på klientadress blir tyst en regel nycklad på gatewayen. Om policy per användare spelar roll, bevara källan eller tillämpa policyn före översättning.

Svarsvägen förtjänar samma granskning. Notera vilken rutt destinationen väljer för returpaketet, eftersom en asymmetrisk retur kringgår tillståndsbaserad inspektion och ger en anslutning som etableras och sedan stannar. Båda riktningarna måste korsa gränsen du ritade, annars är 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

Acceptera en tillåten och en nekad åtgärd

Testa från den verkliga fjärrklienten i stället för från en administrationsvärd, eftersom administrationsvärden oftast sitter någonstans där användaren aldrig kommer att vara. En tillåten åtgärd bevisar att vägen fungerar, och en nekad bevisar att policyn överhuvudtaget gör något. Kör båda efter varje placeringsändring och notera den källidentitet och destination du använde. Ett test som bara bevisar framgång kan inte skilja en korrekt regel från en saknad.

Testa sedan fallen som ändrar tillstånd: en återanslutning, en session som överlever en nyckelrotation och ett fel i själva enheten. Jämför uppdateringar, kapacitet och återställning som del av samma upplägg, eftersom en enhet som håller flera logiska kontroller är en enda feldomän med flera etiketter. En andra box är inte heller oberoende när en delad administrativ inloggning eller en obegränsad rutt besegrar gränsen den skulle skapa.

Dokumentera ändpunkten, den dekrypterade vägen och kontrollen som begränsar den. De tre raderna förblir meningsfulla vad implementeringen än kallas.