IPsec tussen twee hosts: waar bescherming begint en eindigt

Bescherming op een hostpaar begint waar de beveiligingsassociatie eindigt, en dat is het feit dat de meeste gateway-vormige intuïtie mist. Een applicatieserver en zijn databaseserver kunnen hun eigen gesprek rechtstreeks beschermen, zonder een remote-access-concentrator in het pad, en de beschermingsgrens ligt dan in elke host in plaats van in een firewall. Wat dat oplevert, is dekking van begin tot eind voor geselecteerde stromen. Wat het niet oplevert, is een beslissing over wie welke rij mag lezen.

De grens is waar de SA eindigt

RFC 4301 beschrijft beveiligingsassociaties in transportmodus als de regeling die gewoonlijk tussen een hostpaar wordt gebruikt voor bescherming van begin tot eind. Die twee hosts houden de sleutels, en elk beslist welke van zijn eigen pakketten de associatie binnengaan. Een gateway-tunnel eindigt heel ergens anders en bereikt de host via een extra intern segment, wat een andere vertrouwensgrens is, zelfs wanneer het pakket het grootste deel van zijn reis versleuteld is.

Host-naar-host en transportmodus zijn echter geen synoniemen. Twee hosts kunnen evengoed een associatie in tunnelmodus tussen zichzelf opbouwen, dus kies eerst de modus en beschrijf daarna de eindpunten. Schrijf beide in de ontwerpnotitie naast de peer-adressen, want een beoordelaar die alleen de modus kent, zal de andere aannemen.

De SPD bepaalt de bescherming, de route bepaalt de richting

Een routingtabel beantwoordt waar een pakket heen gaat. De database met beveiligingsbeleid beantwoordt hoe het geselecteerde verkeer de beschermingsgrens oversteekt, en doet dat per richting met zijn eigen selectors. Die splitsing is de reden waarom een werkende route naar de database niets bewijst over of het verzoek beschermd was, en waarom een tot stand gekomen onderhandeling niets bewijst over of deze specifieke toepassing erbij paste. Vergelijk de selectors voordat u de tellers vergelijkt, want de tellers beschrijven alleen de stromen die zo ver kwamen.

Op Linux drukt ip xfrm policy die vermeldingen af met hun richting, prioriteit, selector en actie allow, block of trap, terwijl ip xfrm state de resulterende associaties en hun tellers toont. Beide samen lezen is de manier om de stroom te vinden die de tunnel stil omzeilde omdat een bredere allow-vermelding eerst overeenkwam.

Prioriteitsvolgorde is deel van het beleid, geen implementatiedetail. Een smalle vermelding die de databasepoort zou moeten beschermen, verliest van een bredere vermelding met hogere prioriteit, en de storing ziet ernaar uit alsof het beleid nooit is geraadpleegd.

Transportmodus dekt de volgende laag, niet de IP-header

In transportmodus zit de ESP-header tussen de IP-header en de payload, en de adresvelden van die header blijven zichtbaar voor elk apparaat op het pad. Dat is prima wanneer de adressen niet het geheim zijn en de payload wel. Het is de verkeerde keuze als u ook de interne topologie moet verbergen, want alleen tunnelmodus wikkelt de oorspronkelijke header in een nieuwe.

Beide modi kunnen meerdere protocollen van de volgende laag dragen, en ESP beschermt wat de selector raakt in plaats van alles wat de host verstuurt.

De selectie is smaller dan de verbinding

Een enkele associatie kan meerdere stromen dragen, maar alleen die welke het beleid selecteert. Leg de peer-identiteiten, de bron- en bestemmingsadressen, het protocol en de dienstomvang voor de beoogde relatie vast, en beslis daarna afzonderlijk of niet-passend verkeer in het openbaar mag, beschermd moet worden, of moet worden weggegooid wanneer de associatie niet beschikbaar is. Die laatste beslissing is degene die verrassingen oplevert, want een regel die bescherming voor de verkeerde bron eist, kan uw eigen beheerstoegang net zo doeltreffend blokkeren als een indringer.

Houd een goedgekeurd out-of-band-pad aan terwijl u de handhaving wijzigt, en test het voordat u het nodig hebt in plaats van nadat beide hosts onbereikbaar zijn geworden.

Machine-identiteit is geen applicatiemachtiging

IPsec authenticeert een geconfigureerde peer en beschermt geselecteerde pakketten. Het beslist niet welk databaserecord iemand mag bewerken, en het maakt van een vertrouwde serveridentiteit geen verlening van elk applicatieprivilege. Applicatieaccounts, rollen en autorisatie blijven precies waar ze waren, en een TLS-vereiste op applicatieniveau houdt zijn eigen doel, zelfs wanneer het netwerkpad al beschermd is.

Accepteer het ontwerp met één bewerking vanaf de bedoelde bron en één die moet worden geweigerd, en neem op wat er gebeurt wanneer de vereiste associatie niet tot stand kan worden gebracht. Een gewone bereikbaarheidstest vertelt u dat pakketten bewegen; hij vertelt u niet dat ze bewogen onder het beleid dat u hebt geschreven.