Auf der Netzwerkebene können verschiedene Protokolle eingesetzt werden, um die Sicherheit bei der Anbindung an das öffentliche Internet zu erhöhen. Dazu zählen:
-
Encryption-Protokolle, wobei IPsec von besonderem Interesse, aber leider auch von besonderer Komplexität ist
-
Filter-Protokolle, die als Access Control Lists implementiert werden,
-
und Umsetzungsprotokolle, die ein Verstecken von Rechnern (Masquerading) ermöglichen.
Da die beiden letzten Typen eng miteinander verbunden sind und oft in einem Gerät implementiert werden, erläutern wir sie hier zusammen. Der Schwerpunkt dieses Teils unserer Reihe liegt aber auf der Darstellung der außerordentlich unübersichtlichen IPsec-Standardfamilie.
|
Teil 1 |
|
|---|---|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 |
|
|
Teil 6 |
IPsec
IPsec wird in den IETF-Standards RFC2401 ff beschrieben. Es handelt sich dabei um ein Verfahren zur Verschlüsselung, Integrität und Authentifizierung sicherheitsrelevanter Daten auf der Netzwerkschicht. IPsec versucht, allen Teilnehmern und denkbaren Anwendungsszenarios gerecht zu werden, was eine ungeheure Vielzahl von Kombinationen auf allen Stufen ermöglicht.
Zusätzlich ist noch der Aufbau der RFCs, deren unmittelbare Bestandteile die unten stehende Tabelle zeigt, so unübersichtlich, dass ein eigener RFC2410 deren gegenseitige Abhängigkeiten beschreibt. Darüber hinaus gibt es noch weitere RFCs, die durch IPsec betroffen sind und zum Teil obsolet wurden, sowie mehrere RFCs, welche die in den IPsec-RFCs verwendeten kryptographischen Verfahren definieren.
Titel | RFC |
|---|---|
| |
Security Architecture for the Internet Protocol | |
IP Authentication Header | |
The Use of HMAC-MD5-96 within ESP and AH | |
The Use of HMAC-SHA-1-96 within ESP and AH | |
The ESP DES-CBC Cipher Algorithm with Explicit IV | |
IP Encapsulation Security Payload (ESP) | |
The Internet IP Security Domain of Interpretation for ISAKMP | |
Internet Security Association and Key Management Protocol (ISAKMP) | |
The Internet Key Exchange (IKE) | |
The NULL Encryption Algorithm and It5s Use With IPsec | |
IP Security Document Roadmap | |
The Oakley Key Determination Protocol |
IPsec-Struktur
Durch seine unübersichtliche Struktur widerspricht IPsec vollkommen dem Grundsatz, die Architektur sicherer Systeme so einfach wie möglich zu gestalten. Dennoch erfreut es sich einer großen Beliebtheit bei der Implementierung von Virtuellen Privaten Netzwerken (VPN). Die Komplexität von IPsec ist aber ein wesentlicher Grund dafür, dass insbesondere die VPN-Produkte auf der Netzwerkschicht oftmals in proprietären Produkten angeboten werden.
IPsec umfasst zwei große Funktionsgruppen: die Übertragungsprotokolle sowie das Schlüsselmanagement. Zum Datentransfer dienen Verfahren wie Authentication Header (AH, RFC2402) und Encapsulation Security Payload (ESP, RFC2403).
Die Verwaltung der Schlüssel beschreiben die eng zusammenhängenden Funktionen Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), Internet Key Exchange (IKE, RFC 2409) sowie Domain of Interpretation (DOI, RFC2407).
Security Association
Der Realisierung von IPsec liegt das Konzept der Security Association (SA) zu Grunde. Unter einer Security Association versteht man eine kryptographisch geschützte Verbindung. Die SA wird vom Protokoll-Stack je Kommunikationspartner und verwendetem Protokoll eingerichtet. Das heißt, dass für eine bidirektionale Verbindung zwischen zwei Kommunikationspartnern mindestens zwei SA aufgebaut werden müssen.
Eine SA wird für IPsec eindeutig beschrieben durch das Tripel: (SPI, IP-Zieladresse, Security Protocol). Beim Security Parameter Index (SPI) handelt es sich um eine 32-Bit-Zahl, die der Empfänger beim Aufbau der SA willkürlich auswählt. Das ermöglicht, in Kombination mit der IP-Adresse des Empfängers jedes empfangene Paket mit einem IPsec-Header eindeutig einer SA zuzuordnen. Falls ein IPsec-Paket mit IP-Multicast-Adresse als Empfänger und einem vergebenen SPI eintrifft, kann es zurückgewiesen werden. Der Eintrag für das Security Protocol beschreibt das Übertragungsverfahren, beispielsweise AH oder ESP.
Security Association Database
Anhand des Tripels lässt sich die SA als Index in der Security Association Database (SAD) verwalten. Dazu werden zu jeder geschützten Netzwerkverbindung folgende sicherheitsrelevante Konfigurationsdaten gespeichert:
IPsec-Dienst (AH oder ESP)
Übertragungsmodus (Transport vs. Tunnel Modus)
Authentifikations- und Verschlüsselungsalgorithmus
Schlüssel
Sequenznummer
Angaben zur Lebensdauer der SA
Der gesamte Datenverkehr auf einem IPsec-System richtet sich nach Sicherheitsregeln, die in einer weiteren Datenbank, der Security Policy Database (SPD) definiert werden. Die Regeln legen - unter anderem über die Einträge von Absender- und Zieladresse, Absender- und Zielport sowie Protokoll (TCP/UDP) - fest, welche Verbindungen mit Sicherheitsfunktionen versehen werden. Die SPD wertet diese Liste ähnlich aus wie eine Firewall ihre Regelbasis: Alle Einträge werden sequenziell untersucht. Trifft keines der Selektionskriterien zu, kann IPsec das Paket nicht bearbeiten.
Protokoll-Auswahl
IPsec arbeitet zwischen IP und TCP/UDP, wobei es in der Regel der Netzwerkschicht zugeordnet wird. Unsere Abbildung zeigt die grundsätzliche Architektur sowie die Zuordnung der Protokoll- und Portnummern.
Die Abbildung ist folgendermaßen zu lesen:
Enthält das Protokollfeld eines IP-Headers die Zahl 6, dann handelt es sich um ein TCP-Paket.
Enthält das Protokollfeld eines IP-Headers die Zahl 50, dann folgt dem IP-Header ein ESP-Header, es findet eine Übertragung nach IPsec-ESP statt.
Enthält das Protokollfeld des IPsec-Headers die Zahl 6, dann folgt ein TCP-Header.
Zusätzlich sind die Spezialfälle des Tunnelns zu berücksichtigen:
Enthält das Protokollfeld eines IP-Headers die Zahl 4, dann enthält das IP-Paket wiederum ein IP-Paket.
Enthält das Protokollfeld des IPsec-Headers mit dem Typ AH die Zahl 51, dann folgt dem IPsec-Header ein ESP-Header.
IPsec-Modi
IPsec unterscheidet zwei grundsätzliche Übertragungsmodi. Der Transport-Modus fügt zusätzliche IPsec-Informationen zwischen IP-Header und Datenpaket ein und erlaubt einen günstigen Einsatz bei der sicheren Ende-zu-Ende-Kommunikation.
Der Tunnel-Modus ergänzt einen kompletten IP-Header und IPsec-Informationen (Abbildung 6). Er wird dann benötigt, wenn die originalen IP-Quell- und Zieladressen unbedingt beibehalten werden sollen. Damit findet der Tunnel-Modus Anwendung in Firewall-to-Firewall, bzw. Firewall-to-End-Kommunikation.
Dazu ist anzumerken, dass man beim Entwurf von IPsec durchaus auf den Transport-Modus hätte verzichten können. Sein einziger Vorteil besteht darin, dass man sich beim Transfer den zusätzlichen IP-Header spart. Angesichts der hohen Komplexität von IPsec bei der Realisierung in den Endpunkten erscheint dieser Vorteil allerdings nur marginal.
Oft findet man die Anmerkung, das IPsec bereits in IPv6 integriert sei. Das betrifft aber nicht - wie manchmal fälschlicherweise impliziert wird - die Authentifizierung oder der Verschlüsselung, sondern lediglich das Konzept der Extension Header. Die obige Abbildung zeigt, wie sich AH- und ESP-Header in die Reihe der anderen möglichen IPv6-Extension-Header einfügen.
Authentication Header (AH)
Das Übertragungsverfahren mit Hilfe des Authentication Header (AH) beschreibt RFC2402. AH gewährt eine verbindungslose Integrität sowie die Authentifizierung eines IP-Pakets und erlaubt den Schutz gegen so genannte Replay-Angriffe. Die Absicherung schließt auch die IP-Header ein, mit Ausnahme allerdings solcher Felder, die von den Routern auf dem Weg eines Pakets durch ein IP-Netz verändert werden (mutuable fields).
Das Next-Header-Feld gibt Auskunft über das dem AH-Header folgende Protokoll (etwa 6 für TCP). Payload Len beschreibt die Länge des AH in 32 Bit-Wörtern. Auf das derzeit noch nicht genutzte Reserved-Feld folgt der schon besprochene Security Parameter Index (SPI). Die Sequence Number identifiziert die Reihenfolge des Paketes in der Kommunikation. Pakete mit doppelten oder nicht plausiblen Sequenznummer verwirft IPsec, was einfacher Replay-Angriffe unterbindet
Das Feld Authentication Data beinhaltet die kryptographische Prüfsumme, die nach dem in der SA definierten Algorithmus berechnet wurde. Dabei kommen entweder HMAC-MD5 oder HMAC-SHA-1 zum Einsatz. Deren Verwendung mit AH und ESP beschreiben RFC2403 (HMAC-MD5-96) und RFC2404 (HMAC-SHA-1-96). Eine Reihe von Implementierungen verwendet MD5/SHA-1 nur mit der Keyed-Variante. Dann erfolgt ein Hashing nur mit dem Shared Key, was lediglich eine Integritätskontrolle ermöglicht. Bei der HMAC-Variante (Hashed Message Authentication Code) wird das Keyed-Ergebnis zusätzlich mit dem Secret Key (Integrität und Authentifizierung) verarbeitet.
Encapsulating Security Payload (ESP)
Die Übertragung mittels Encapsulating Security Payload (ESP) beschreibt RFC2406, das den originalen RFC1827 ablöst. ESP erlaubt über die Mechanismen des AH hinaus auch eine Verschlüsselung des Datenpakets. Hierfür ist ESP etwas komplexer aufgebaut als AH. Insbesondere verwendet ESP nicht nur einen eigenen Header, sondern hängt auch einen Trailer an.
Der ESP-Header besitzt die in der obigen Abbildung gezeigten Bestandteile. Security Parameter Index (SPI) und Sequence Number kennen wir bereits aus der Beschreibung des AH. Die Nutzdaten (Payload Data) transferiert ESP üblicherweise verschlüsselt. Dazu nutzt es den DES-Algorithmus im CBC-Modus (RFC2405). Alternativ lassen sich die Daten auch ohne Verschlüsselung übermitteln. Die sogenannte Null Encryption beschreibt der humorige RFC2410.
Die Authentifizierung (Authentication Data) erfolgt ebenfalls verschlüsselt. Dazu nutzt ESP wahlweise HMAC-MD5 (RFC2403) oder HMAC-SHA-1 (RFC2404). Optional kann auch hier eine Null Authentication zum Einsatz kommen. Jedoch dürfen nicht gleichzeitig Nutzlast und Authentifizierung unverschlüsselt übermittelt werden.
AH/ESP-Kombinationen
AH und ESP lassen sich nicht nur einzeln einsetzen, sondern dürfen auch kombiniert werden. Grundsätzlich unterscheidet man zwei Kombinationsverfahren:
Transport Adjacency: Beide Sicherheitsprotokolle werden im Transport-Modus auf das gleiche IP-Datagramm angewendet.
Nested Tunneling: Beide Sicherheitsprotokolle arbeiten im Tunnel-Modus zusammen. Da das Tunneling jeweils wieder ein neues IP-Datagramm zusammenstellt, lassen sich hier die beiden Protokolle theoretisch beliebig oft anwenden.
Auf den unterschiedlichen Stufen einer Übertragung dürfen beide Varianten ihrerseits wiederum kombiniert werden. So ergibt sich eine schier endlose Zahl von Varianten. RFC2406 beschreibt deswegen verpflichtende Kombinationen, die jede IPsec-Implementierung abdecken muss:
Der Transport-Modus muss AH allein, ESP allein sowie AH nach ESP (im Sinn der Transport Adjacency) unterstützen.
Der Tunnel-Modus muss sowohl AH allein als auch ESP allein implementieren.
Weitere Kombinationen können optional realisiert werden, was allerdings zu Lasten der Interoperabilität geht: Eine lediglich standardkonforme Gegenstation ist nicht verpflichtet, zusätzliche Varianten ebenfalls zu unterstützen.
Schlüsselmanagement
Die AH- und ESP-RFCs beschreiben lediglich die IPsec-Übertragungsverfahren. Sie treffen jedoch keine Aussage darüber, wie die gemeinsamen Schlüssel und deren Sicherheitsparameter in der Security Association Database zwischen den Kommunikationspartnern ausgehandelt werden. Hier existieren (wie stets bei IPsec) zwei Möglichkeiten: Eine manuelle Verteilung und Konfiguration sowie ein automatisierter Verwaltungsmechanismus.
Kleinere, dedizierte Applikationen wählen auf Grund der relativ hohen Komplexität der automatisierten Protokolle recht häufig den manuellen Ansatz. Um das automatisierte Verfahren zu beschreiben, gilt es zunächst die Begriffe ISAKMP, DOI und IKE zu klären:
Das Internet Security Association and Key Management Protocol (ISAKMP, RFC2408) bildet eine Rahmenarchitektur für die Verwaltung von Security Associations (SA) und Schlüsseln. Darüber hinaus beschreibt es auch die Organisation der Datenpakete zum Generieren von Schlüsseln und der Authentifizierungsdaten. ISAKMP selbst stellt aber kein Protokoll zum Schlüsselaustausch dar. Es ist auch keineswegs nur auf den Einsatz mit IPsec beschränkt, sondern für die Verwaltung von beliebig strukturierten SAs ausgelegt.
Die Domain of Interpretations (DOI, RFC2409) beschreiben verschiedene Protokolle, die mit ISAKMP verwendet werden können. In Bezug auf die Verwendung in IPsec instanziiert DOI ISAKMP für die Verwendung bei IP.
Bei Internet Key Exchange (IKE, RFC2409) handelt es sich um ein Protokoll zum Austausch von Schlüsseln und zur Verwaltung von SAs für die AH- und ESP-Protokolle von IPsec. Hierzu nutzt IKE Bestandteile sowohl von ISAKMP als auch von Oakley (RFC2412), das ein Diffie-Hellman-Schlüsselaustauschverfahren beschreibt.
ISAKMP
IKE besteht aus zwei Stufen. In der ersten Phase finden eine wechselweise Authentifizierung und das Aushandeln eines langfristigen Sitzungsschlüssels statt. Dazu handeln die miteinander kommunizierenden Systeme eine Security Association für die sichere Übertragung von ISAKMP-Nachrichten aus. Darauf aufbauend können in der zweiten Phase beliebig viele SAs für IPsec-Verbindungen oder andere Protokolle über IKE möglichst effizient aufgebaut werden.
Für den gegenwärtig in der Praxis üblichen Fall, dass nur zwei SAs ausgehandelt werden müssen, wirkt sich diese Aufteilung eher nachteilig aus und kompliziert den Ablauf unnötig. Hinzu kommt, dass in der Phase 1 zwischen zwei Modi und in der Phase 2 zwischen drei Modi ausgewählt werden kann.
Für die Phase 1 muss die Implementation den Main Mode unterstützen, der sechs Datagramme austauscht. Optional lässt sich der Aggressive Mode mit einem vereinfachten Austausch von nur drei Datengrammen realisieren. Darüber hinaus gilt es noch zu unterscheiden, auf welche Weise die Schlüssel generiert und ausgetauscht werden sollen. Hier existieren die Varianten pre-shared secret key, public-encryption key (alias public signature key) sowie original public key-encryption.
ISAKMP Phase 1
Die folgenden Grafiken zeigen schematisch den Ablauf von Phase 1 einer ISAKMP-Verhandlung.
Message 1: Der Initiator konfrontiert den Responder mit einer Auswahl von verschiedenen Vorschlägen (Proposals), nach welchen Verschlüsselungs- und Authentifizierungsalgorithmen (Transform) die ISAKMP-SA ausgehandelt werden könnte. Im ISAKMP-Header wird das Feld Initiator-Cookie auf einen Pseudozufallswert C(i) gesetzt, der dann später zusammen mit dem Responder-Cookie C(r) den Nachrichtenfluss authentifiziert. Nachrichten innerhalb eines ISAKMP-Paketes können sich in langen Folgen aneinander reihen. Dabei gibt jede Nachricht über das Feld Next Payload an, ob noch weitere Nachrichten folgen. Dabei können mehrere Transform-Nachrichten zu einer Proposal-Nachricht und mehrere Proposal-Transform-Kombinationen zu einer SA gehören.
Message 2: Der Responder antwortet, indem er sich aus den Vorschlägen einen heraussucht. Das Rahmenformat ist identisch mit der Message 1. Im ISAKMP-Header setzt der Responder das Feld Responder-Cookie auf einen Pseudozufallswert C(r). Zusätzlich repliziert er auch C(i), so dass eine erste (schwache) Authentifizierung stattfindet. C(r) und C(i) bilden zusammen als SPI den Index für den Zugriff auf die Security Association Database mit den gemeinsamen Verbindungsparametern.
Message 3: Mit der dritten Nachricht beginnt nun der Austausch der kryptographischen Informationen. Der Initiator teilt seinen öffentlichen Diffie-Hellman-Schlüssel g(i) mit. Zudem liefert er eine pseudozufällige und große Zahl, die man als Nonce (engl. für Ad-hoc) N(i) bezeichnet.
Message 4: Der Responder antwortet mit seinem öffentlichen Diffie-Hellman-Schlüssel g(r) und seiner Nonce N(r). Aus diesen Informationen berechnen nun beide Stationen eine Reihe von unterschiedlichen Schlüsseln. Hierzu zählt insbesondere der Master-Key SKEYID. Aus diesem werden verschiedene weitere Schlüssel abgeleitet, die zur Verschlüsselung beim nachfolgenden Datentransfer zum Einsatz kommen. SKEYID_d ist der Schlüssel, der in der zweiten IKE-Phase zur Verschlüsselung von nicht-ISAKMP-konformen SAs eingesetzt wird. SKEYID_a wird zur Authentifizierung von ISAKMP-Nachrichten verwendet, SKEYID_e zur deren Verschlüsselung.
Nun haben beide Stationen die für die Übertragung benötigten Schlüssel generiert und überprüfen diesen Status mit den beiden letzten Nachrichten Message 5 und Message 6. Hierbei übertragen sie eine verschlüsselte Authentifizierung.
ISAKMP Phase 2
Der Aggressive Mode verkürzt die Phase 1 auf nur drei Nachrichtentransfers. Der Initiator schickt im ersten Paket neben dem vorgeschlagenen Verfahren auch gleich seinen öffentlichen Diffie-Hellman-Schlüssel mit. Dem Responder bleibt nichts anderes übrig, als das Angebot anzunehmen oder zu verwerfen.
Auf der Grundlage der gesicherten Kommunikation zur Übermittlung von ISAKMP-Nachrichten können nun Initiator und Responder in Phase 2 beginnen, beliebig viele SAs für IPsec-Verbindungen einzurichten. Dazu tauschen sie im so genannten Quick Mode Exchange drei Nachrichten, die sie allesamt mit dem in Phase 1 generierten Schlüssel SKEYID_e chiffrieren. Außerdem versehen sie die Nachrichten mit einer kryptographischen Prüfsumme, in deren Berechnung SKEYID_a eingeht.
Im ersten Schritt schlägt der Initiator wieder mögliche Algorithmen zur Einrichtung einer oder mehrerer SAs sowie deren Verwendungszweck vor. Die Gegenstelle trifft eine Auswahl und übermittelt diese mit der zweiten Nachricht. Neben Main-, Aggressive- und Quick-Mode definiert IKE noch zwei weitere Exchanges:
Der Informational Exchange dient zum Übermitteln von Status- und Fehlerinformationen sowie Löschen von SAs.
Mit dem New Group Exchange kann ein neuer Diffie-Hellman-Modus für die ISAKMP-SA ausgehandelt werden.
IP Masquerading
Neben IPsec zählt IP-Masquerading zu den bekanntesten Sicherheitsmechanismen auf der Netzwerkschicht. Das auch als IP Network Address Translation (NAT) bezeichnete Verfahren wird in RFC3022 beschrieben.
NAT erlaubt eine transparente Umsetzung zwischen den internen Adressen eines LAN und der Adresszuordnung im öffentlichen Netz. Ursprünglich wurde es entwickelt, um zusätzliche Hosts ans Internet anschließen zu können, ohne dafür knappe öffentliche IPv4-Adressen nutzen zu müssen. Mittlerweile hat es sich aber auch zum Sicherheits-Feature speziell für kleinere LANs entwickelt, die nicht über weitergehende Sicherheitsmechanismen wie SOCKS- oder Proxy-Server verfügen.
NAT schafft eine Zuordnung zwischen (in der Regel privaten) IP-Adressen in einem sicheren Netz und einer IP-Adresse im unsicheren, öffentlichen Netz. Dem gemäß ist NAT immer in einem Router implementiert. Aus der Außensicht treten alle internen Rechner im Internet so auf, als würden sie alle die gleiche, öffentliche IP-Adresse verwenden.
Sicherheitsaspekte
Bei der Adressumsetzung via NAT ergeben sich eine Reihe von interessanten Aspekten:
NAT beschreibt keinen Tunnelmechanismus. Es wird also kein zusätzlicher IP-Header angehängt, sondern der bestehende IP-Header modifiziert. Dieses Verfahren arbeitet prinzipiell sehr effizient, da es keine zusätzlichen Daten generiert. Allerdings bringt es bei einigen Applikationen, die auch auf Anwendungsebene IP-Adressen berücksichtigen, Probleme mit sich.
Sind mehrere interne IP-Adressen auf eine externe IP-Adresse abzubilden, wie dies bei typischen Dial-up-Routern der Fall ist, dann muss die Umsetzungstabelle noch zusätzliche Informationen abspeichern. Anhand der verwendeten Source-TCP-Ports bleibt eine eindeutige Zuordnung möglich. Dies bedeutet aber einen deutlich höheren Verwaltungsaufwand für den NAT-Router, der die Zuordnung verbindungsorientiert treffen muss.
Im gleichen Schritt kann auch die Entscheidung fallen, ein Paket mit einer bestimmten Zieladresse (outbound) oder Quelladresse (inbound) gar nicht umzusetzen, sondern statt dessen zu blockieren. Diese Filterung auf Adressebene kann als IP-Firewall verstanden werden. Auf der Basis der entsprechenden Cisco-Nomenklatur hat sich dafür auch der Begriff der Access-Control-Lists durchgesetzt.
Ausblick
Im vorigen und im aktuellen Teil unserer Artikelserie zu Security haben wir uns näher mit den grundlegenden Sicherheitsverfahren auf den beiden untersten Schichten des Netzwerks vertraut gemacht. Davon ausgehend nehmen wir im nächsten Teil der Serie die wichtigsten Sicherheitsprotokolle auf der Anwendungsschicht des Netzwerks näher unter die Lupe.
Zu deren bekanntesten Vertretern zählen SSL/TLS und das darauf basierende HTTPS. Daneben kommen auch eigenständige Protokolle wie S/MIME und S/HTTP sowie das Lieblingswerkzeug des Administrators, SSH, zur Sprache. (jlu)
| |
Teil 1 | |
|---|---|
Teil 2 | |
Teil 3 | |
Teil 4 | |
Teil 5 | |
Teil 6 | Security mit VPNs |