IPsec mellom to verter: hvor beskyttelsen begynner og slutter

Beskyttelse på et vertspar begynner der sikkerhetsassosiasjonen avsluttes, og det er det faktumet som intuisjon formet av gatewayer oftest overser. En applikasjonsserver og databaseserveren dens kan beskytte sin egen samtale direkte, uten noen fjernakseskonsentrator i veien, og beskyttelsesgrensen ligger da inne i hver vert i stedet for i en brannmur. Det dette gir deg, er dekning fra ende til ende for utvalgte flyter. Det det ikke gir deg, er en beslutning om hvem som kan lese hvilken rad.

Grensen er der SA-en avsluttes

RFC 4301 beskriver sikkerhetsassosiasjoner i transportmodus som ordningen som vanligvis brukes mellom et vertspar for beskyttelse fra ende til ende. Disse to vertene holder nøklene, og hver av dem bestemmer hvilke av sine egne pakker som går inn i assosiasjonen. En gatewaytunnel avsluttes helt andre steder og når verten gjennom et ekstra internt segment, noe som er en annen tillitsgrense selv når pakken er kryptert store deler av reisen.

Vert-til-vert og transportmodus er likevel ikke synonymer. To verter kan like riktig bygge en assosiasjon i tunnelmodus mellom seg, så velg modusen først og beskriv deretter endepunktene. Skriv begge i designnotatet ved siden av peer-adressene, fordi en gjennomleser som bare kjenner modusen vil anta den andre.

SPD-en avgjør beskyttelsen, ruten avgjør retningen

En rutetabell svarer på hvor en pakke går. Databasen for sikkerhetspolicy svarer på hvordan den utvalgte trafikken krysser beskyttelsesgrensen, og den gjør det per retning med sine egne selektorer. Denne delingen er grunnen til at en fungerende rute til databasen ikke beviser noe om hvorvidt forespørselen var beskyttet, og til at en etablert forhandling ikke beviser noe om hvorvidt nettopp denne applikasjonen samsvarte med den. Sammenlign selektorene før du sammenligner tellerne, siden tellerne bare beskriver flytene som kom så langt.

På Linux skriver ip xfrm policy ut disse oppføringene med retning, prioritet, selektor og handlingen tillat, blokker eller fange, mens ip xfrm state viser assosiasjonene som blir resultatet og tellerne deres. Å lese de to sammen er måten du finner flyten som stille gikk utenom tunnelen fordi en bredere tillat-oppføring samsvarte først.

Prioritetsrekkefølge er en del av policyen, ikke en implementasjonsdetalj. En smal oppføring som skulle beskytte databaseporten taper mot en bredere oppføring med høyere prioritet, og feilen ser ut som om policyen aldri ble konsultert.

Transportmodus dekker neste lag, ikke IP-headeren

I transportmodus sitter ESP-headeren mellom IP-headeren og nyttelasten, og adressefeltene i den headeren forblir synlige for hver enhet på veien. Det er greit når adressene ikke er hemmeligheten og nyttelasten er det. Det er feil valg hvis du også må skjule den interne topologien, fordi bare tunnelmodus pakker den opprinnelige headeren inn i en ny.

Begge modusene kan bære flere protokoller på neste lag, og ESP beskytter det selektoren samsvarer med i stedet for alt verten sender.

Utvalget er smalere enn forbindelsen

En enkelt assosiasjon kan bære flere flyter, men bare dem policyen velger ut. Registrer peer-identitetene, kilde- og destinasjonsadressene, protokollen og tjenesteomfanget for forholdet du har tenkt, og avgjør deretter separat om ikke-samsvarende trafikk kan gå i klartekst, må beskyttes, eller må forkastes når assosiasjonen ikke er tilgjengelig. Den siste beslutningen er den som gir overraskelser, fordi en regel som krever beskyttelse for feil kilde kan blokkere din egen administrasjonstilgang like effektivt som den blokkerer en inntrenger.

Hold en godkjent utenforbånd-sti mens du endrer håndhevelsen, og test den før du trenger den i stedet for etter at begge vertene er blitt utilgjengelige.

Maskinidentitet er ikke applikasjonstillatelse

IPsec autentiserer en konfigurert peer og beskytter utvalgte pakker. Det avgjør ikke hvilken databaserad en person kan redigere, og det gjør ikke en klarert serveridentitet om til en tildeling av alle applikasjonsrettigheter. Applikasjonskontoer, roller og autorisasjon blir nøyaktig der de var, og et TLS-krav på applikasjonsnivå beholder sitt eget formål selv når nettverksveien allerede er beskyttet.

Godta designet med én operasjon fra den tiltenkte kilden og én som må avvises, og ta med hva som skjer når den påkrevde assosiasjonen ikke kan etableres. En vanlig tilgjengelighetstest forteller deg at pakker beveger seg; den forteller deg ikke at de beveget seg under policyen du skrev.