test

Systemverwaltungshandbuch: IP Services

Kapitel 19 IP Security Architecture (Übersicht)

Die IP Security Architecture (IPsec) bietet grafischen Schutz für IP-Datagramme in IPv4- und IPv6-Netzwerkpaketen.

Dieses Kapitel enthält die folgenden Informationen:

Informationen zur Implementierung von IPsec in Ihrem Netzwerk finden Sie in Kapitel 20Konfiguration von IPsec (Aufgaben). Referenzinformationen finden Sie in Kapitel 21IP Security Architecture (Referenz).

Neuerungen in IPsec

Solaris 10 4/09: Ab dieser Version wird IPsec in der Service Management Facility (SMF) als Satz verschiedener Services verwaltet.

Standardmäßig werden beim Booten des Systems zwei IPsec-Services aktiviert:

Standardmäßig sind die Schlüsselmanagement-Services beim Booten des Systems deaktiviert:

Gehen Sie wie folgt vor, um die IPsec-Richtlinien in SMF zu aktivieren:

  1. Fügen Sie der Datei ipsecinit.conf IPsec-Richtlinieneinträge hinzu.

  2. Konfigurieren Sie die Internet Key Exchange (IKE), oder konfigurieren Sie die Schlüssel manuell.

  3. Aktualisieren Sie den Service für die IPsec-Richtlinie.

  4. Aktivieren Sie den Schlüsselmanagement-Service.

Weitere Informationen zu SMF finden Sie in Kapitel 18, Managing Services (Overview) in System Administration Guide: Basic Administration. Lesen Sie hierzu auch die Manpages smf(5) und svcadm(1M).

Ab dieser Version steht für die Befehle ipsecconf und ipseckey die Option -c zur Verfügung. Hiermit wird die Syntax der jeweiligen Konfigurationsdateien überprüft. Außerdem wird das neue Rechteprofil für das Netzwerk-IPsec-Management bereitgestellt. Dies wird zur Verwaltung von IPsec und IKE benötigt.

Solaris 10 7/07: Ab diesem Release implementiert IPsec vollständig Tunnel im Tunnelmodus. Die Dienstprogramme, die Tunnel unterstützen, wurden modifiziert.

Solaris 10 1/06: Ab diesem Release ist IKE vollständig konform mit NAT-Traversal-Unterstützung gemäß der Normen RFC 3947 und RFC 3948. IKE-Operationen nutzen die PKCS #11-Bibliothek des Solaris Cryptographic Framework (SCF), was die Leistung verbessert.

Das Kryptographie-Framework stellt einen Softtoken-Schlüsselspeicher für Anwendungen bereit, die den Metaslot verwenden. Wenn IKE den Metaslot verwendet, können Sie die Schlüssel auf einer Festplatte, einem angehängten Board oder im Softtoken-Schlüsselspeicher speichern.

Einführung in IPsec

IPsec schützt IP-Pakete, indem es Pakete authentifiziert, Pakete verschlüsselt oder beides ausführt. IPsec wird innerhalb des IP-Moduls unterhalb der Anwendungsschicht ausgeführt. Aus diesem Grund kann eine Internet-Anwendung die Vorteile von IPsec nutzen, ohne dass sie zur Verwendung von IPsec konfiguriert werden muss. Wenn es richtig eingesetzt wird, ist IPsec ein wirksames Tool bei der Sicherung des Netzwerkverkehrs.

Der IPsec-Schutz umfasst fünf Hauptkomponenten:

Beim Einsatz von IPsec werden die Sicherheitsmechanismen auf IP-Datagramme angewendet, die zur IP-Zieladresse gesendet werden. Der Empfänger nutzt die Informationen in seiner SADB, um die Legitimität ankommender Pakete sicherzustellen und sie zu entschlüsseln. Anwendungen können IPsec aufrufen, um ebenfalls Sicherheitsmechanismen an IP-Datagrammen auf Socket-Ebene anzuwenden.

Beachten Sie, dass sich Sockets je nach Port unterschiedlich verhalten:

IPsec RFCs

Die Internet Engineering Task Force (IETF) hat eine Reihe von Requests for Comment (RFCs) veröffentlichen, in denen die Sicherheitsarchitektur für die IP-Schicht beschrieben wird. Das Copyright für diese RFCs liegt bei der Internet Society. Einen Link zu den RFCs finden Sie unter http://www.ietf.org/. Die folgende Liste der RFCs deckt die allgemeinen IP-Sicherheitsreferenzen ab:

IPsec-Terminologie

Die IPsec RFCs definieren zahlreiche Begriffe, mit denen Sie vertraut sein sollten, wenn Sie IPsec auf Ihren Systemen umsetzen möchten. In der folgenden Tabelle sind IPsec-Begriffe, ihre am häufigsten verwendeten Akronymen sowie Definitionen aufgeführt. Eine Liste der bei der Schlüsselaushandlung verwendeten Terminologie finden Sie in Tabelle 22–1.

Tabelle 19–1 IPsec-Begriffe, Akronymen und Definitionen

IPsec-Begriff 

Acronym 

Definition 

Sicherheitszuordnung 

SA 

Eine einmalige Verbindung zwischen zwei Knoten in einem Netzwerk. Die Verbindung wird durch ein Triplet definiert: ein Sicherheitsprotokoll, ein Sicherheits-Parameterindex und ein ID-Ziel. Das IP-Ziel kann eine IP-Adresse oder ein Socket sein. 

Sicherheitszuordnung- Datenbank 

SADB 

Eine Datenbank, in der alle aktiven Sicherheitszuordnungen enthalten sind. 

Security Parameter Index 

SPI 

Der Indexwert für eine Sicherheitszuordnung. Ein SPI ist ein 32-Bit-Wert, der zwischen SAs unterscheidet, die das gleiche IP-Ziel und Sicherheitsprotokoll aufweisen. 

Security Policy-Datenbank

SPD 

Eine Datenbank, die feststellt, ob abgehende und eingehende Pakete die angegebene Schutzebene aufweisen. 

Key Exchange 

 

Der Prozess zum Erzeugen von Schlüsseln für asymmetrische kryptografische Algorithmen. Die zwei wichtigsten Methoden sind die RSA-Protokolle und das Diffie-Hellman-Protokoll. 

Diffie-Hellman- Protokoll 

DH 

Ein Key Exchange-Protokoll zur Erzeugung und Authentifizierung von Schlüsseln. Wird häufig auch als authentifizierter Schlüsselaustausch bezeichnet.

RSA-Protokoll 

RSA 

Ein Key Exchange-Protokoll zur Erzeugung und Verteilung von Schlüsseln. Das Protokoll ist nach seinen drei Autoren Rivest, Shamir und Adleman benannt. 

Internet- Sicherheitszuordnung und Schlüsselmanagement- protokoll 

ISAKMP 

Eine allgemeine Grundstruktur zum Einrichten des Formats für SA-Attribute sowie zum Aushandeln, Bearbeiten und Löschen von SAs. ISAKMP ist der IETF-Standard für die Verarbeitung von IPsec-SAs. 

IPsec-Paketfluss

Abbildung 19–1 zeigt, wie ein IP-adressiertes Paket als Teil eines IP-Datagramms verarbeitet wird, wenn IPsec für ein abgehendes Paket aufgerufen wurde. Das Ablaufdiagramm zeigt, wo die Entitäten Authentication Header (AH) und Encapsulating Security Payload (ESP) am Paket angewendet werden können. Wie diese Entitäten angewendet werden und wie die Algorithmen ausgewählt werden, wird in den folgenden Abschnitten beschrieben.

Abbildung 19–2 zeigt den IPsec-Ablauf bei eingehenden Paketen.

Abbildung 19–1 Ablauf bei IPsec für abgehende Pakete

Das Ablaufdiagramm zeigt, dass das abgehende Paket zunächst durch ESP und dann durch AH geschützt wird. Dann durchläuft das Paket einen Tunnel oder eine physikalische Schnittstelle.

Abbildung 19–2 Ablauf bei IPsec für eingehende Pakete

Das Ablaufdiagramm zeigt, dass IPsec zunächst den AH-Header, und damit den ESP-Header der eingehenden Pakete verarbeitet. Ein nicht ausreichend geschütztes Paket wird verworfen.

IPsec und Sicherheitszuordnungen

Eine IPsec-Sicherheitszuordnung (SA) legt die Sicherheitseigenschaften fest, die von miteinander kommunizierenden Hosts erkannt werden. Eine einzelne SA schützt Daten in eine Richtung. Der Schutz gilt entweder für einen bestimmten Host oder eine Gruppenadresse (multicast). Da eine Kommunikation entweder Peer-to-Peer oder Client-Server abläuft, müssen zwei SAs vorhanden sein, um den Datenverkehr in beide Richtungen zu schützen.

Eine IPsec-SA ist durch drei Elemente eindeutig gekennzeichnet:

Der SPI, eine zufällige 32-Bit-Zahl, wird mit einem AH- oder ESP-Paket übertragen. In den Manpages ipsecah(7P) und ipsecesp(7P) finden Sie ausführliche Informationen zum Schutzumfang durch AH und ESP. Zur Authentifizierung eines Pakets wird eine Integrität-Prüfsumme eingesetzt. Schlägt die Authentifizierung fehl, wird das Paket verworfen.

Sicherheitszuordnungen werden in einer Sicherheitszuordnung-Datenbank (SADB) gespeichert. In berechtigten Anwendungen kann die Datenbank mithilfe einer Socket-basierten Verwaltungsengine, der PF_KEY-Schnittstelle, verwaltet werden. Beispielsweise können die IKE-Anwendung und der Befehl ipseckeys die Socketschnittstelle PF_KEY verwenden.

Schlüsselmanagement in IPsec

Sicherheitszuordnungen (SAs) benötigen Schlüsselmaterial zur Authentifizierung und Verschlüsselung. Die Verwaltung dieses Schlüsselmaterials wird als Schlüsselmanagement bezeichnet. Das Schlüsselmanagement wird automatisch vom Internet Key Exchange (IKE)-Protokoll abgewickelt. Sie können die Schlüssel jedoch auch manuell mit dem Befehl ipseckey verwalten.

SAs für IPv4- und IPv6-Pakete können beide Methoden zum Schlüsselmanagement verwenden. Solange kein zwingender Grund für ein manuelles Schlüsselmanagement vorliegt, sollten Sie das automatische Schlüsselmanagement einsetzen. Ein Grund für ein manuelles Schlüsselmanagement wäre die Zusammenarbeit mit Systemen, die nicht unter Solaris OS ausgeführt werden.

In der aktuellen Version stellt SMF IPsec die folgenden Schlüsselmanagement-Services bereit:

In älteren Versionen als Solaris 10 4/09 dienen die Befehle in.iked und ipseckey zur Verwaltung von Schlüsselmaterial.

IPsec-Schutzmechanismen

IPsec umfasst zwei Sicherheitsprotokolle zum Schutz von Daten:

Ein AH schützt Daten mit einem Authentifizierungsalgorithmus. Eine ESP schützt Daten mit einem Verschlüsselungsalgorithmus. Optional kann eine ESP Daten mit einem Authentifizierungsalgorithmus schützen. Jede Implementierung eines Algorithmus wird als ein Mechanismus bezeichnet.

Authentication Header

Der Authentication Header bietet Datenauthentifizierung, starke Integrität und Replay-Schutz für IP-Datagrammen. AH schützt den größten Teil des IP-Datagramms. Wie die folgende Abbildung zeigt, wird der AH zwischen IP-Header und Transport-Header eingefügt.

Das Diagramm zeigt den AH-Header zwischen IP-Header und TCP-Header.

Der Transport-Header kann TCP, UDP, SCTP oder ICMP sein. Wenn ein Tunnel verwendet wird, kann der Transport-Header ein anderer IP-Header sein.

Encapsulating Security Payload

Das Encapsulating Security Payload (ESP)-Modul bietet Vertraulichkeit für Inhalte, die durch ESP eingekapselt sind. ESP stellt auch Services bereit, die vom AH angeboten werden. ESP stellt seinen Schutz jedoch nur dem Teil des Datagramms zur Verfügung, den ESP einkapselt. ESP bietet optionale Authentifizierungsservices, um die Integrität des geschützten Pakets sicherzustellen. Da ESP eine verschlüsselungskonforme Technologie verwendet, könnte ein System zur ESP-Bereitstellung den Gesetzen zu Exportbeschränkungen unterliegen.

ESP kapselt seine Daten ein, so dass ESP nur die Daten schützt, die seinem Anfang im Datagramm folgen, wie in der folgenden Abbildung gezeigt.

Das Diagramm zeigt den ESP-Header zwischen IP-Header und TCP-Header. Der TCP-Header ist durch den ESP-Header verschlüsselt.

In einem TCP-Paket kapselt ESP nur den TCP-Header und dessen Daten ein. Handelt es sich bei dem Paket um ein IP-in-IP-Datagramm, schützt ESP das innere IP-Datagramm. Die für einen Socket geltende Richtlinie ermöglicht eine Selbst-Einkapselung, so dass ESP gegebenenfalls auch IP-Optionen einkapseln kann.

Bei aktivierter Selbst-Einkapselung wird eine Kopie des IP-Headers erstellt, um ein IP-in-IP-Datagramm zu konstruieren. Ist die Selbst-Einkapselung nicht auf ein TCP-Socket gesetzt, wird das Datagramm in dem folgenden Format gesendet:


[ IP(a -> b) options + TCP + data ]

Ist die Selbst-Einkapselung auf ein TCP-Socket gesetzt, wird das Datagramm in dem folgenden Format gesendet:


[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ]

Weitere Informationen finden Sie unter Transport- und Tunnelmodi in IPsec.

Sicherheitsbetrachtungen beim Verwenden von AH und ESP

In der folgenden Tabelle werden AH und ESP hinsichtlich des gebotenen Schutzes miteinander verglichen.

Tabelle 19–2 Von AH und ESP in IPsec gebotener Schutz

Protokoll 

Einbezogenes Paket 

Schutz 

Gegenüber Angriffen 

AH 

Schützt das Paket vom IP-Header bis zum Transport-Header 

Bietet starke Integrität, Datenauthentifizierung: 

  • Stellt sicher, dass der Empfänger genau das empfängt, was der Absender gesendet hat.

  • Ist anfällig gegenüber Replay-Angriffen, wenn für einen AH kein Replay-Schutz aktiviert ist.<remark role="writer">

Wiedergabe, Ausschneiden und Einfügen 

ESP 

Schutz für das Paket ab dem Anfang der ESP im Datagramm. 

Mit der Verschlüsselungsoption wird das IP-Datagramm verschlüsselt. Stellt Vertraulichkeit sicher. 

Mithören 

Bietet mit der Authentifizierungsoption den gleichen Schutz wie der AH. 

Wiedergabe, Ausschneiden und Einfügen 

Bietet mit beiden Optionen starke Integrität, Datenauthentifizierung und Vertraulichkeit. 

Wiedergabe, Ausschneiden und Einfügen, Mithören 

Authentifizierungs- und Verschlüsselungsalgorithmen in IPsec

Die IPsec-Sicherheitsprotokolle verwenden zwei Arten von Algorithmen: Authentifizierung und Verschlüsselung. Das AH-Modul verwendet Authentifizierungsalgorithmen. Das ESP-Modul kann sowohl Verschlüsselungs- als auch Authentifizierungsalgorithmen verwenden. Eine Liste der auf Ihrem System verwendeten Algorithmen und deren Eigenschaften können Sie durch Eingabe des Befehls ipsecalgs anzeigen. Weitere Informationen finden Sie in der Manpage ipsecalgs(1M) Mit den in der Manpage getipsecalgbyname(3NSL) beschriebenen Funktionen können Sie auch die Eigenschaften der Algorithmen abrufen.

IPsec auf einem Solaris-System verwendet die kryptografische Grundstruktur in Solaris, um auf die Algorithmen zuzugreifen. Die Grundstruktur bietet neben anderen Services auch ein zentrales Repository für Algorithmen. Mithilfe der Grundstruktur kann IPsec von den leistungsstarken kryptografischen Hardwarebeschleunigern profitieren. Darüber hinaus stellt die Grundstruktur Resource Control-Funktionen zur Verfügung. Beispielsweise können Sie mit der Grundstruktur die Zeit beschränken, die die CPU für kryptografischen Vorgänge im Kernel aufwendet.

Weitere Informationen finden Sie hier:

Authentifizierungsalgorithmen in IPsec

Authentifizierungsalgorithmen erzeugen eine Integritätsprüfsumme (digest), die auf den Daten und einem Schlüssel basiert. Das AH-Modul verwendet Authentifizierungsalgorithmen. Das ESP-Modul kann ebenfalls Authentifizierungsalgorithmen verwenden.

Verschlüsselungsalgorithmen in IPsec

Verschlüsselungsalgorithmen verschlüsseln Daten mithilfe eines Schlüssels. Das ESP-Modul in IPsec verwendet Verschlüsselungsalgorithmen. Der Algorithmus arbeitet mit Daten in Einheiten von jeweils einer Blockgröße.

Verschiedene Versionen des Betriebssystems Solaris 10 enthalten verschiedenene Standard-Verschlüsselungsalgorithmen.

Achtung – Achtung –

Ab Solaris 10 7/07 brauchen Sie das Solaris Encryption Kit auf Ihrem System nicht zusätzlich zu installieren. Das Kit stuft den Patch-Level zur Verschlüsselung auf Ihrem System herab. Das Kit ist mit der Verschlüsselung auf Ihrem System nicht kompatibel.

IPsec-Schutzrichtlinien

IPsec-Schutzrichtlinien können für alle Sicherheitsmechanismen verwendet werden. IPsec-Richtlinien können auf folgenden Ebenen angewendet werden:

IPsec wendet die systemweit geltende Richtlinie an abgehenden und eingehenden Datagrammen an. Abgehende Datagramme werden entweder geschützt oder ungeschützt gesendet. Bei aktiviertem Schutz sind die Algorithmen entweder spezifisch oder nicht spezifisch. Aufgrund zusätzlicher Daten, die dem System bekannt sind, können Sie einige zusätzliche Regeln für abgehende Datagramme anwenden. Eingehende Datagramme werden entweder akzeptiert oder verworfen. Die Entscheidung, ob ein eingehendes Datagramm verworfen oder akzeptiert wird, basiert auf verschiedenen Kriterien, die manchmal überlappen oder widersprüchlich sind. Widersprüche werden gelöst, in dem festgelegt wird, welche Regel zuerst ausgewertet wird. Datenverkehr wird automatisch akzeptiert, es sei denn, ein Richtlinieneintrag gibt an, dass Datenverkehr alle weiteren Richtlinien umgehen soll.

Eine Richtlinie, die ein Datagramm normalerweise schützt, kann umgangen werden. Sie können eine Ausnahme entweder in der systemweit geltenden Richtlinie angeben, oder Sie fordern an, das eine für ein Socket geltende Richtlinie umgegangen wird. Bei Datenverkehr innerhalb eines Systems werden Richtlinien erzwungen, aber tatsächliche Sicherheitsmechanismen nicht angewendet. Stattdessen wird die Richtlinie für abgehende Datenverkehr bei einem systeminternen Paket in ein eingehendes Paket übersetzt, für das die Mechanismen angewendet wurden.

Mit der Datei ipsecinit.conf und dem Befehl ipsecconf können Sie IPsec-Richtlinien konfigurieren. Einzelheiten und Beispiele finden Sie in der Manpage ipsecconf(1M).

Transport- und Tunnelmodi in IPsec

Die IPsec-Standards definieren zwei unterschiedlichen Modi für den IPsec-Betrieb: den Transportmodus und den Tunnelmodus. Die Modi wirken sich nicht auf die Verschlüsselung von Paketen aus. Die Pakete werden in beiden Modi durch AH, ESP oder durch beides geschützt. Die Modi unterscheiden sich in der Richtlinienauslegung, wenn es sich bei dem inneren Paket um ein ID-Paket handelt:

Im Transportmodus können der äußere Header, der nächste Header und alle Ports, die der nächste Header unterstützt, zum Festlegen der IPsec-Richtlinie verwendet werden. Somit kann IPsec aufgrund der Granularität eines einzelnen Port unterschiedliche Transportmodus-Richtlinien für zwei IP-Adressen erzwingen. Ist beispielsweise der nächste Header ein TCP-Header, der Ports unterstützt, kann die IPsec-Richtlinie für einen TCP-Port der äußeren IP-Adresse eingerichtet werden. Entsprechend gilt: ist der nächste Header ein IP-Header, können der äußere Header und der innere IP-Header zum Festlegen der IPsec-Richtlinie verwendet werden.

Der Tunnelmodus arbeitet nur für IP-in-IP-Datagramme. Tunneling im Tunnelmodus eignet sich dann, wenn Mitarbeiter von zu Hause aus eine Verbindung mit einem Zentralcomputer herstellen. Im Tunnelmodus wird die IPsec-Richtlinie für die Inhalte des inneren IP-Datagramms durchgesetzt. Bei mehreren verschiedenen inneren IP-Adressen können unterschiedliche IPsec-Richtlinien durchgesetzt werden. Das heißt, die innere IP-Adresse, der nächste Header, und Ports, die der nächste Header unterstützt, können eine Richtlinie durchsetzen. Im Gegensatz zum Transportmodus kann der äußere IP-Header im Tunnelmodus die Richtlinie für das innere IP-Datagramm nicht vorschreiben.

Aus diesem Grund kann die IPsec-Richtlinie im Tunnelmodus für Teilnetze eines LAN hinter einem Router und für Ports dieser Teilnetze angegeben werden. Eine IPsec-Richtlinie kann auch für bestimmte IP-Adressen (Hosts) in diesem Teilnetzen angegeben werden. Den Ports dieser Hosts kann auch jeweils eine bestimmte IPsec-Richtlinie zugewiesen sein. Wird jedoch ein dynamisches Routing-Protokoll über einen Tunnel ausgeführt, verwenden Sie keine Teilnetz- oder Adressauswahl, da sich die Ansicht der Netzwerktopologie auf dem Peer-Netzwerk ändern könnte. Änderungen würden die statische IPsec-Richtlinie ungültig machen. Beispiele für Tunneling-Verfahren, die eine Konfiguration statischer Routen beinhalten, finden Sie unter Schützen eines VPN mit IPsec.

In Solaris OS kann der Tunnelmodus nur für eine IP-Tunneling-Netzwerkschnittstelle erzwungen werden. Mit dem ipsecconf-Befehl wird ein Tunnel-Schlüsselwort bereitgestellt, um eine IP-Tunneling-Netzwerkschnittstelle auszuwählen. Ist das Schlüsselwort tunnel in einer Regel vorhanden, gelten alle in dieser Regel angegebenen Selektoren für das innere Paket.

Im Transportmodus kann das Datagramm durch ESP, AH oder durch beides geschützt werden.

Die folgende Abbildung zeigt eine IP-Adresse mit einem ungeschützten TCP-Paket.

Abbildung 19–3 Ungeschütztes IP-Paket mit TCP-Informationen

Das Diagramm zeigt den IP-Header, gefolgt vom TCP-Header. Der TCP-Header ist nicht geschützt.

Im Transportmodus schützt ESP die Daten wie in der folgenden Abbildung gezeigt. Der schattierte Bereich kennzeichnet den verschlüsselten Teil des Pakets.

Abbildung 19–4 Geschütztes IP-Paket mit TCP-Informationen

Das Diagramm zeigt den ESP-Header zwischen IP-Header und TCP-Header. Der TCP-Header ist durch den ESP-Header verschlüsselt.

Im Transportmodus schützt AH die Daten wie in der folgenden Abbildung gezeigt.

Abbildung 19–5 Von einem Authentication Header geschütztes Paket

Das Diagramm zeigt den AH-Header zwischen IP-Header und TCP-Header.

Tatsächlich schützt AH die Daten, bevor die Daten im Datagramm erscheinen. Entsprechend wirkt sich der Schutz durch den AH auch im Transportmodus auf einen Teil des IP-Headers aus.

Im Tunnelmodus befindet sich das gesamte Datagramm innerhalb des Schutzes eines IPsec-Headers. Das Datagramm in Abbildung 19–3 wird im Tunnelmodus durch einen äußeren IPsec-Header (in diesem Fall ESP) geschützt. Dies wird in der folgenden Abbildung gezeigt.

Abbildung 19–6 Im Tunnelmodus geschütztes IPsec-Paket

Das Diagramm zeigt den ESP-Header hinter dem IP-Header und vor einem IP-Header und einem TCP-Header. Die letzten beiden Header sind durch eine Verschlüsselung geschützt.

Der Befehl ipsecconf umfasst Schlüsselwörter zum Einrichten von Tunneln im Tunnel- oder Transportmodus.

Virtuelle private Netzwerke und IPsec

Ein konfigurierter Tunnel ist eine Point-to-Point-Schnittstelle. Ein Tunnel ermöglicht, dass ein IP-Paket in einem anderen IP-Paket eingekapselt wird. Ein korrekt konfigurierter Tunnel erfordert sowohl eine Tunnelquelle als auch ein Tunnelziel. Weitere Informationen finden Sie in der Manpage tun(7M) und unter Konfiguration von Tunneln zur Unterstützung von IPv6.

Ein Tunnel erstellt eine scheinbare Physikalische Schnittstelle für IP. Die Integrität einer physikalischen Verknüpfung hängt von den zu Grunde liegenden Sicherheitsprotokollen ab. Wenn Sie die Sicherheitszuordnungen (SAs) sicher einrichten, können Sie dem Tunnel vertrauen. Pakete, die den Tunnel verlassen, müssen von dem Peer stammen, der am Tunnelziel angegeben wurde. Wenn diese Vertrauensstellung existiert, können Sie eine für eine Schnittstelle geltende IP-Weiterleitung verwenden, um ein Virtuelles privates Netzwerk (VPN) zu erstellen.

Ein VPN kann mithilfe von IPsec erstellt werden. IPsec sichert die Verbindung. So kann eine Organisation, die zwei Büros mit separaten Netzwerken über ein VPN verbindet, IPsec zur Sicherung des Datenverkehrs zwischen den zwei Büros verwenden.

Die folgende Abbildung zeigt, wie zwei Büros das Internet verwenden, um deren VPN einzurichten, das IPsec in den Netzwerksystemen einsetzt.

Abbildung 19–7 Virtuelles privates Netzwerk

Das Diagramm zeigt die Büros 1 und 2, die die Schnittstelle hme0 zur Kommunikation miteinander verwenden. Jedes Büro verwendet hme1 für die interne Kommunikation.

Ein ausführliches Beispiel zur Einrichtung dieses Systems finden Sie unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4.

Ein ähnliches Beispiel mit IPv6-Adressen finden Sie unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv6.

IPsec und NAT Traversal

IKE kann IPsec SAs über eine NAT-Box aushandeln. Mit dieser Fähigkeit sind Systeme in der Lage, von einem standortfernen Netzwerk aus auch dann eine sichere Verbindung herzustellen, wenn sich die Systeme hinter einem NAT-Gerät befinden. Beispiele können Mitarbeiter, die von zu Hause aus arbeiten, oder Personen, die sich von einer Konferenz-Site aus anmelden, ihren Datenverkehr mit IPsec schützen.

NAT bedeutet Network Address Translation (Netzwerk-Adresseübersetzung). Eine NAT-Box dient zum Übersetzen einer privaten internen Adresse in eine einmalige Internetadresse. NATs befinden sich häufig an öffentlichen Zugangspunkten zum Internet, z. B. in Hotels. Weitere Informationen finden Sie unter Verwenden der NAT-Funktion in Oracle Solaris IP Filter.

Die Fähigkeit, IKE verwenden zu können, wenn sich eine NAT-Box zwischen kommunizierenden Systemen befindet, wird NAT-Traversal oder NAT-T genannt. In Release Solaris 10 gelten für NAT-T die folgenden Einschränkungen:

Die folgenden RFCs beschreiben die NAT-Funktionalität und die Einschränkungen von NAT-T. Diese RFCs können Sie von http://www.rfc-editor.org herunterladen.

Informationen zum Verwenden von IPsec über ein NAT finden Sie unter Konfiguration von IKE für mobile Systeme (Übersicht der Schritte).

IPsec und SCTP

Das Solaris-Betriebssystem unterstützt das SCTP-Protokoll (Streams Control Transmission Protocol). Die Verwendung des SCTP-Protokolls und der SCTP-Portnummer zur Angabe einer IPsec-Richtlinie wird unterstützt, ist aber nicht sehr robust. Die IPsec-Erweiterungen für SCTP gemäß der Angabe in der RFC 3554 wurden noch nicht implementiert. Diese Einschränkungen können zu Komplikationen beim Erstellen einer IPsec-Richtlinie für SCTP führen.

SCTP kann im Rahmen einer einzelnen SCTP-Assoziation mehrere Quell- und Zieladressen verwenden. Wenn die IPsec-Richtlinie an einer Quell- oder an einer Zieladresse angewendet wird, könnte die Kommunikation fehlschlagen, wenn SCTP die Quell- oder Zieladresse dieser Assoziation wechselt. Die IPsec-Richtlinie erkennt nur die ursprüngliche Adresse. Informationen zum SCTP finden Sie in den RFCs und unter SCTP-Protokoll.

IPsec und Solaris Zones

Für gemeinsame IP-Zonen wird IPsec von der globalen Zone aus konfiguriert. Die Konfigurationsdatei einer IPsec-Richtlinie, ipsecinit.conf, existiert nur in der globalen Zone. Die Datei kann Einträge enthalten, die für nicht-globale Zonen gelten und Einträge, die für die globale Zone gelten.

Für exklusive IP-Zonen wird IPsec von der nicht-globalen Zone aus konfiguriert.

Informationen zur Verwendung von IPsec mit Zonen finden Sie unter Schützen von Datenverkehr mit IPsec. Informationen zu Zonen finden Sie in Kapitel 16, Einführung in Solaris Zones in Systemverwaltungshandbuch: Oracle Solaris Container – Ressourcenverwaltung und Solaris Zones.

IPsec und Logische Domains

IPsec arbeitet mit logischen Domänen. Die logische Domäne muss eine Version des Betriebssystems Solaris ausführen, die IPsec enthält, so zum Beispiel Solaris 10.

Um logische Domänen zu erstellen, müssen Sie Oracle VM Server für SPARC verwenden, der früher mit dem Begriff Logical Domains bezeichnet wurde. Informationen zur Konfiguration von logischen Domänen finden Sie in Logical Domains 1.2 Administration Guide oder Oracle VM Server for SPARC 2.0 Administration Guide.

IPsec-Dienstprogramme und Dateien

Aus Tabelle 19–3 geht hervor, welche Dateien, Befehle und Servicebezeichnungen zur Konfiguration und Verwaltung von IPsec verwendet werden. Der Vollständigkeit halber enthält die Tabelle die Dateien und Befehle des Schlüsselmanagements.

Ab Solaris 10 4/09 erfolgt das IPsec-Management über SMF. Weitere Informationen zu Servicebezeichnungen finden Sie in Kapitel 18, Managing Services (Overview) in System Administration Guide: Basic Administration.

Tabelle 19–3 Liste der ausgewählten IPsec-Dienstprogramme und -Dateien

IPsec-Dienstprogramm, -Datei oder -Service 

Beschreibung 

Manpage 

svc:/network/ipsec/ipsecalgs

Der SMF-Service, der in der aktuellen Version die IPsec-Algorithmen verwaltet. 

smf(5), ipsecalgs(1M)

svc:/network/ipsec/manual-key

Der SMF-Service, der in der aktuellen Version die manuellen Sicherheitszuordnungen (SAs) verwaltet. 

smf(5), ipseckey(1M)

svc:/network/ipsec/policy

Der SMF-Service, der in der aktuellen Version die IPsec-Richtlinie verwaltet.

smf(5), ipsecconf(1M)

svc:/network/ipsec/ike

Der SMF-Service, der in der aktuellen Version für das automatische Management von IPsec-SAs sorgt. 

smf(5), in.iked(1M)

/etc/inet/ipsecinit.conf-Datei

IPsec-Richtliniendatei. In älteren Versionen als Solaris 10 4/09 wird IPsec beim Booten aktiviert, falls diese Datei vorhanden ist.

In der aktuellen Version verwendet der SMF policy-Service diese Datei zur Konfiguration der IPsec-Richtlinie beim Booten des Systems.

ipsecconf(1M)

ipsecconf-Befehl

IPsec-Richtlinienbefehl. Nützlich zum Anzeigen und Ändern der aktuellen IPsec-Richtlinie sowie zum Testen. In früheren Versionen als Solaris 10 4/09 wird in den Boot-Skripten mit dem Befehl ipsecconf die Datei /etc/inet/ipsecinit.conf gelesen, und anschließend wird IPsec aktiviert.

In der aktuellen Version wird ipsecconf vom SMF policy-Service zur Konfiguration der IPsec-Richtlinie beim Booten des Systems verwendet.

ipsecconf(1M)

PF_KEY-Socket-Schnittstelle

Schnittstelle der Sicherheitszuordnung-Datenbank (SADB). Wickelt das manuelle und das automatische Schlüsselmanagement ab.

pf_key(7P)

ipseckey-Befehl

Der IPsec-Schlüsselbefehl für SAs. ipseckey ist ein Befehlszeilen-Frontend für die PF_KEY-Schnittstelle. ipseckey kann SAs erzeugen, abbrechen oder ändern.

ipseckey(1M)

/etc/inet/secret/ipseckeys-Datei

Schlüssel für IPsec SAs. In älteren Versionen als Solaris 10 4/09 wird, wenn die Datei ipsecinit.conf vorhanden ist, beim Booten des Systems automatisch die Datei ipseckeys gelesen.

In der aktuellen Version wird ipseckeys vom SMF manual-key-Service zur manuellen Konfiguration von SAs beim Booten des Systems verwendet.

 

ipsecalgs-Befehl

Befehl für IPsec-Algorithmen. Nützlich zum Anzeigen und Ändern der Liste von IPsec-Algorithmen und deren Eigenschaften.

Wird in der aktuellen Version vom SMF ipsecalgs-Service beim Booten des Systems zur Synchronisierung bekannter IPsec-Algorithmen mit dem Systemkern verwendet.

ipsecalgs(1M)

/etc/inet/ipsecalgs-Datei

Enthält die konfigurierten IPsec-Protokolle und Definitionen der Algorithmen. Diese Datei wird vom ipsecalgs-Befehl verwaltet und darf nicht manuell bearbeitet werden.

 

/etc/inet/ike/config-Datei

IKE-Konfigurations- und Richtliniendatei. Diese Datei ist standardmäßig nicht vorhanden. In älteren Versionen als Solaris 10 4/09 stellt der IKE-Daemon (in.iked) das automatische Schlüsselmanagement bereit, wenn diese Datei vorhanden ist. Das Management basiert auf Regeln und globalen Parametern in der Datei /etc/inet/ike/config. Lesen Sie dazu IKE-Dienstprogramme und Dateien.

In der aktuellen Version startet der svc:/network/ipsec/ike -Service den IKE-Daemon (in.iked) für das automatische Schlüsselmanagement, falls diese Datei vorhanden ist.

ike.config(4)

Änderungen an IPsec für Solaris 10

Eine vollständige Liste der neuen Funktionen in Solaris sowie eine Beschreibung der Solaris-Versionen finden Sie in Neuerungen in Oracle Solaris 9 10/10. Mit Solaris 9 wurden die folgenden Funktionen in IPsec eingeführt: