IPsec zwischen zwei Hosts: wo der Schutz beginnt und wo er endet

Schutz auf einem Hostpaar beginnt dort, wo die Sicherheitsassoziation endet, und genau diese Tatsache übersieht die meiste gateway-geprägte Intuition. Ein Anwendungsserver und sein Datenbankserver können ihr Gespräch direkt selbst schützen, ohne einen Remote-Access-Konzentrator im Pfad, und die Schutzgrenze liegt dann in jedem Host statt in einer Firewall. Was das einbringt, ist eine Ende-zu-Ende-Abdeckung für ausgewählte Flüsse. Was es nicht einbringt, ist eine Entscheidung darüber, wer welche Zeile lesen darf.

Die Grenze liegt dort, wo die SA endet

RFC 4301 beschreibt Sicherheitsassoziationen im Transportmodus als die Anordnung, die typischerweise zwischen einem Hostpaar für Ende-zu-Ende-Schutz verwendet wird. Diese beiden Hosts halten die Schlüssel, und jeder entscheidet, welche seiner eigenen Pakete in die Assoziation eintreten. Ein Gateway-Tunnel endet ganz woanders und erreicht den Host über ein zusätzliches internes Segment, was eine andere Vertrauensgrenze ist, selbst wenn das Paket für den größten Teil seiner Reise verschlüsselt ist.

Host-zu-Host und Transportmodus sind jedoch keine Synonyme. Zwei Hosts können ebenso richtig eine Assoziation im Tunnelmodus zwischen sich aufbauen, also wählen Sie zuerst den Modus und beschreiben Sie dann die Endpunkte. Schreiben Sie beides in die Designnotiz neben den Peer-Adressen, denn ein Prüfer, der nur den Modus kennt, wird den anderen annehmen.

Die SPD entscheidet über den Schutz, die Route über die Richtung

Eine Routing-Tabelle beantwortet, wohin ein Paket geht. Die Sicherheitsrichtlinien-Datenbank beantwortet, wie der ausgewählte Datenverkehr die Schutzgrenze überquert, und zwar pro Richtung mit eigenen Selektoren. Diese Trennung ist der Grund, warum eine funktionierende Route zur Datenbank nichts darüber beweist, ob die Anfrage geschützt war, und warum eine ausgehandelte Vereinbarung nichts darüber beweist, ob diese bestimmte Anwendung dazu passte. Vergleichen Sie die Selektoren, bevor Sie die Zähler vergleichen, denn die Zähler beschreiben nur die Flüsse, die so weit gekommen sind.

Unter Linux gibt ip xfrm policy diese Einträge mit ihrer Richtung, Priorität, ihrem Selektor und ihrer Aktion allow, block oder trap aus, während ip xfrm state die resultierenden Assoziationen und ihre Zähler zeigt. Beides zusammen zu lesen ist der Weg, den Fluss zu finden, der den Tunnel still umgangen hat, weil ein breiterer Allow-Eintrag zuerst passte.

Die Prioritätsreihenfolge ist Teil der Richtlinie und kein Implementierungsdetail. Ein enger Eintrag, der den Datenbankport schützen sollte, verliert gegen einen breiteren Eintrag mit höherer Priorität, und das Versagen sieht so aus, als wäre die Richtlinie nie befragt worden.

Der Transportmodus deckt die nächste Schicht ab, nicht den IP-Header

Im Transportmodus sitzt der ESP-Header zwischen dem IP-Header und der Nutzlast, und die Adressfelder dieses Headers bleiben für jedes Gerät auf dem Pfad sichtbar. Das ist in Ordnung, wenn die Adressen nicht das Geheimnis sind und die Nutzlast es ist. Es ist die falsche Wahl, wenn Sie zusätzlich die interne Topologie verbergen müssen, denn nur der Tunnelmodus packt den Original-Header in einen neuen.

Beide Modi können mehrere Protokolle der nächsten Schicht tragen, und ESP schützt das, was der Selektor trifft, statt alles, was der Host sendet.

Die Auswahl ist enger als die Verbindung

Eine einzige Assoziation kann mehrere Flüsse tragen, aber nur die, die die Richtlinie auswählt. Erfassen Sie die Peer-Identitäten, die Quell- und Zieladressen, das Protokoll und den Dienstumfang für die Beziehung, die Sie beabsichtigen, und entscheiden Sie dann getrennt, ob nicht passender Datenverkehr im Klartext laufen darf, geschützt werden muss oder verworfen werden muss, wenn die Assoziation nicht verfügbar ist. Die letzte Entscheidung ist die, die Überraschungen erzeugt, denn eine Regel, die Schutz für die falsche Quelle verlangt, kann Ihren eigenen Verwaltungszugang so wirksam blockieren, wie sie einen Eindringling blockiert.

Halten Sie einen genehmigten Out-of-Band-Pfad bereit, während Sie die Durchsetzung ändern, und testen Sie ihn, bevor Sie ihn brauchen, statt erst nachdem beide Hosts unerreichbar geworden sind.

Maschinenidentität ist keine Anwendungsberechtigung

IPsec authentifiziert einen konfigurierten Peer und schützt ausgewählte Pakete. Es entscheidet nicht, welchen Datenbankdatensatz eine Person bearbeiten darf, und es verwandelt eine vertrauenswürdige Serveridentität nicht in die Gewährung jedes Anwendungsprivilegs. Anwendungskonten, Rollen und Autorisierung bleiben genau dort, wo sie waren, und eine TLS-Anforderung auf Anwendungsebene behält ihren eigenen Zweck, selbst wenn der Netzwerkpfad bereits geschützt ist.

Akzeptieren Sie das Design mit einer Operation von der vorgesehenen Quelle und einer, die abgelehnt werden muss, und nehmen Sie auf, was passiert, wenn die erforderliche Assoziation nicht aufgebaut werden kann. Ein gewöhnlicher Erreichbarkeitstest sagt Ihnen, dass Pakete sich bewegen; er sagt Ihnen nicht, dass sie sich unter der von Ihnen geschriebenen Richtlinie bewegt haben.