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).
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:
svc:/network/ipsec/policy:default
svc:/network/ipsec/ipsecalgs:default
Standardmäßig sind die Schlüsselmanagement-Services beim Booten des Systems deaktiviert:
svc:/network/ipsec/manual-key:default
svc:/network/ipsec/ike:default
Gehen Sie wie folgt vor, um die IPsec-Richtlinien in SMF zu aktivieren:
Fügen Sie der Datei ipsecinit.conf IPsec-Richtlinieneinträge hinzu.
Konfigurieren Sie die Internet Key Exchange (IKE), oder konfigurieren Sie die Schlüssel manuell.
Aktualisieren Sie den Service für die IPsec-Richtlinie.
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.
IPsec implementiert Tunnel im Tunnelmodus für virtuelle private Netzwerke (VPNs). Im Tunnelmodus unterstützt IPsec mehrere Clients hinter einem einzelnen NAT. Im Tunnelmodus kann IPsec mit Implementationen von IP-in-IP-Tunneln von anderen Anbietern zusammenarbeiten. IPsec unterstützt weiterhin Tunnel im Transportmodus, ist also mit früheren Solaris-Releases kompatibel.
Die Syntax zum Erzeugen eines Tunnels wurde vereinfacht. Zur Verwaltung der IPsec-Richtlinie wurde der Befehl ipsecconf erweitert. Der Befehl ifconfig zur Verwaltung der IPsec-Richtlinie wird nicht unterstützt.
Ab diesem Release ist die Datei /etc/ipnodes nicht mehr vorhanden. Verwenden Sie die Datei /etc/hosts zur Konfiguration der IPv6-Netzwerkschnittstellen.
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.
Informationen zur Verwendung des Softtoken-Schlüsselspeichers finden Sie in der Manpage cryptoadm(1M).
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.
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:
Sicherheitsprotokolle – Die Schutzmechanismen für IP-Datagramme. Der Authentication Header (AH) signiert IP-Pakete und stellt so Integrität sicher. Der Inhalt des Datagramms wird nicht verschlüsselt, aber der Empfänger kann sicher sein, dass der Paketinhalt nicht geändert wurde. Darüber hinaus wird dem Empfänger versichert, dass die Pakete vom Absender gesendet wurden. Die Encapsulating Security Payload (ESP) verschlüsselt IP-Daten und verbirgt so den Inhalt während der Paketübertragung. ESP kann darüber hinaus die Datenintegrität über eine Authentifizierungs-Algorithmusoption sicherstellen.
Sicherheitszuordnung-Datenbank (SADB) – Die Datenbank, die ein Sicherheitsprotokoll mit einer IP-Zieladresse und eine Indexnummer verbindet. Die Indexnummer wird als Security Parameter Index (SPI) bezeichnet. Diese drei Elemente (das Sicherheitsprotokoll, die Zieladresse und die SPI) kennzeichnen ein legitimes IPsec-Paket eindeutig. Die Datenbank stellt sicher, dass ein geschütztes Paket, das am Ziel eintrifft, auch vom Empfänger erkannt wird. Der Empfänger verwendet die Informationen aus der Datenbank, um den Datenverkehr zu entschlüsseln, um sicherzustellen, dass die Pakete nicht geändert wurden, um die sie wieder zusammenzusetzen und an das endgültige Ziel weiterzuleiten.
Schlüsselmanagement – Das Erzeugen und Verteilen der Schlüssel für die kryptografischen Algorithmen und für die SPI.
Sicherheitsmechanismen – Die Authentifizierungs- und Verschlüsselungsalgorithmen, mit denen die Daten in den IP-Datagrammen geschützt werden.
Security Policy-Datenbank (SPD) – Die Datenbank, in der die Schutzebene angegeben ist, die für ein bestimmtes Datenpaket gilt. Die SPD filtert IP-Datenverkehr und stellt auf diese Weise fest, wie die Pakete verarbeitet werden müssen. Ein Paket kann vergeworfen werden. Ein Paket kann unverschlüsselt weitergeleitet werden. Ein Paket kann mit IPsec geschützt werden. Bei abgehenden Paketen stellen SPD und SADB fest, welche Schutzebene angewendet werden soll. Bei eingehenden Paketen hilft die SPD festzustellen, ob die Schutzebene des Pakets akzeptabel ist. Wurde das Paket durch IPsec geschützt, wird die SPD abgefragt, nachdem das Paket entschlüsselt und geprüft wurde.
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:
Für einen einzelnen Socket geltende SAs setzen ihren entsprechenden Port-Eingang in der SPD außer Kraft.
Darüber hinaus gilt, ist ein Socket an einen Port angeschlossen und wird die IPsec-Richtlinie wird erst später an diesem Port angewendet, so wird der Datenverkehr, der diesen Socket verwendet, nicht durch IPsec geschützt.
Natürlich wird ein Socket, der auf einem Port geöffnet wird, nachdem die IPsec-Richtlinie an diesem Port angewendet wurde, durch IPsec geschützt.
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:
RFC 2411, „IP Security Document Roadmap,“ November 1998
RFC 2401, „Security Architecture for the Internet Protocol,“ November 1998
RFC 2402, „IP Authentication Header,“ November 1998
RFC 2406, „IP Encapsulating Security Payload (ESP),“ November 1998
RFC 2408, „Internet Security Association and Key Management Protocol (ISAKMP),“ November 1998
RFC 2407, „The Internet IP Security Domain of Interpretation for ISAKMP,“ November 1998
RFC 2409, „The Internet Key Exchange (IKE),“ November 1998
RFC 3554, „On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,“ Juli 2003 [in der Solaris 10-Release nicht implementiert]
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. |
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. |
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.
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:
Das Sicherheitsprotokoll (AH oder ESP)
Die IP-Zieladresse
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.
Eine ausführliche Beschreibung der IPsec-SADB finden Sie unter Sicherheitszuordnung-Datenbank für IPsec.
Weitere Informationen zur Verwaltung der SADB finden Sie in der Manpage pf_key(7P).
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:
svc:/network/ipsec/ike:default -Service – Der SMF-Service für das automatische Schlüsselmanagement. Der ike-Service führt zur Bereitstellung des automatischen Schlüsselmanagements den in.iked-Daemon aus. Eine Beschreibung des IKE-Protokolls finden Sie in Kapitel 22Internet Key Exchange (Übersicht). Weitere Informationen zum in.iked-Daemon finden Sie in der Manpage in.iked(1M). Informationen zum ike-Service finden Sie unter IKE Service Management Facility.
svc:/network/ipsec/manual-key:default-Service – Der SMF-Service für das manuelle Schlüsselmanagement. Der manual-key-Service führt den ipseckey-Befehl mit verschiedenen Optionen zum manuellen Schlüsselmanagement aus. Eine Beschreibung des ipseckey -Befehls finden Sie unter Dienstprogramme zur Schlüsselerzeugung in IPsec. Eine ausführliche Beschreibung der ipseckey-Befehlsoptionen finden Sie in der Manpage ipseckey(1M).
In älteren Versionen als Solaris 10 4/09 dienen die Befehle in.iked und ipseckey zur Verwaltung von Schlüsselmaterial.
Der in.iked-Daemon bietet automatisches Schlüsselmanagement. Eine Beschreibung des IKE-Protokolls finden Sie in Kapitel 22Internet Key Exchange (Übersicht). Weitere Informationen zum in.iked-Daemon finden Sie in der Manpage in.iked(1M).
Der ipseckey-Befehl bietet manuelles Schlüsselmanagement. Eine Beschreibung dieses Befehls finden Sie unter Dienstprogramme zur Schlüsselerzeugung in IPsec. Eine ausführliche Beschreibung der ipseckey-Befehlsoptionen finden Sie in der Manpage ipseckey(1M).
IPsec umfasst zwei Sicherheitsprotokolle zum Schutz von Daten:
Authentication Header (AH)
Encapsulating Security Payload (ESP)
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.
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.
Der Transport-Header kann TCP, UDP, SCTP oder ICMP sein. Wenn ein Tunnel verwendet wird, kann der Transport-Header ein anderer IP-Header sein.
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.
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.
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
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 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 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.
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.
Ab Release Solaris 10 7/07 wird der Inhalt des Solaris Encryption Kit vom Solaris-Installationsdatenträger installiert. Bei dieser Version sind die SHA2-Authentifizierungsalgorithmen sha256, sha384 und sha512 hinzugefügt. Die SHA2-Implementierungen entsprechen der Spezifikation RFC 4868. Bei dieser Version werden größere Diffie-Hellman-Gruppen hinzugefügt: 2048-Bit (Gruppe 14), 3072-Bit (Gruppe 15) und 4096-Bit (Gruppe 16). Bei Sun-Systemen mit CoolThreads-Technologie wird nur die 2048-Bit-Gruppe beschleunigt.
Vor Release Solaris 10 7/07 enthielt der Solaris-Installationsdatenträger grundlegende Algorithmen und Sie konnten stärkere Algorithmen aus dem Solaris Encryption Kit installieren.
Standardmäßig sind die Algorithmen DES-CBC, 3DES-CBC, AES-CBC und Blowfish-CBC installiert. Die von den AES-CBC- und Blowfish-CBC-Algorithmen unterstützte Schlüsselgröße beträgt 128 Bit.
AES-CBC- und Blowfish-CBC-Algorithmen, die Schlüsselgrößen von mehr als 128 Bit unterstützen, stehen IPsec zur Verfügung, wenn Sie das Solaris Encryption Kit installieren. Jedoch stehen nicht alle Verschlüsselungsalgorithmen auch außerhalb der Vereinigten Staaten von Amerika zur Verfügung. Das Kit ist als eine separate CD erhältlich, die nicht im Solaris 10-Installationspaket enthalten ist. Die Installation des Kit ist im Solaris 10 Encryption Kit Installation Guide beschrieben. Weitere Informationen finden Sie auf der Sun Downloads-Website. Zum Herunterladen des Kits klicken Sie auf die Registerkarte „Downloads A-Z“ und dann auf den Buchstaben S. Das Solaris 10 Encryption Kit befindet sich unter den 20 ersten Einträgen.
IPsec-Schutzrichtlinien können für alle Sicherheitsmechanismen verwendet werden. IPsec-Richtlinien können auf folgenden Ebenen angewendet werden:
Auf systemweite Ebene
Auf für einen Socket geltenden Ebene
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).
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 bestimmt der äußere Header die IPsec-Richtlinie, die das innere IP-Paket schützt.
Im Tunnelmodus bestimmt das innere IP-Paket die IPsec-Richtlinie, die dessen Inhalte schützt.
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.
Im Transportmodus schützt ESP die Daten wie in der folgenden Abbildung gezeigt. Der schattierte Bereich kennzeichnet den verschlüsselten Teil des Pakets.
Im Transportmodus schützt AH die Daten wie in der folgenden Abbildung gezeigt.
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.
Der Befehl ipsecconf umfasst Schlüsselwörter zum Einrichten von Tunneln im Tunnel- oder Transportmodus.
Einzelheiten zur für einen Socket geltenden Richtlinie finden Sie in der Manpage ipsec(7P).
Ein Beispiel einer für einen Socket geltenden Richtlinie finden Sie unter How to Use IPsec to Protect a Web Server From Nonweb Traffic.
Weitere Informationen zu Tunneln finden Sie in der Manpage ipsecconf(1M).
Ein Beispiel für eine Tunnelkonfiguration finden Sie unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4.
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.
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.
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:
NAT-T arbeitet nur mit IPv4-Netzwerken.
NAT-T kann die Vorteile der IPsec ESP-Beschleunigung durch das Sun Crypto Accelerator 4000-Board nicht nutzen. Dennoch funktioniert die IKE-Beschleunigung mit dem Sun Crypto Accelerator 4000-Board.
Das AH-Protokoll beruht auf einem unveränderlichen IP-Header. Aus diesem Grund funktioniert AH nicht mit NAT-T. Mit NAT-T wird das ESP-Protokoll verwendet.
Die NAT-Box benötigt keine speziellen Verarbeitungsregeln. Eine NAT-Box mit speziellen IPsec-Verarbeitungsregeln zu Problemen mit der Implementierung von NAT-T führen.
NAT-T arbeitet nur dann, wenn der IKE-Initiator das System hinter der NAT-Box ist. Ein IKE-Antwortgeber kann sich nicht hinter einer NAT-Box befinden, es sei denn, die Box wurde zum Weiterleiten von IKE-Paketen zum entsprechenden individuellen System hinter der Box programmiert.
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.
RFC 3022, „Traditional IP Network Address Translator (Traditional NAT),“ Januar 2001
RFC 3715, „IPsec-Network Address Translation (NAT) Compatibility Requirements,“ März 2004
RFC 3947, „Negotiation of NAT-Traversal in the IKE,“ Januar 2005
RFC 3948, „UDP Encapsulation of IPsec Packets,“ Januar 2005
Informationen zum Verwenden von IPsec über ein NAT finden Sie unter Konfiguration von IKE für mobile Systeme (Übersicht der Schritte).
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.
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 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.
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.
Anweisungen zur Umsetzung von IPsec in Ihrem Netzwerk finden Sie unter Schützen des Datenverkehrs mit IPsec (Übersicht der Schritte).
Details zu den Dienstprogrammen und Dateien von IPsec finden Sie in Kapitel 21IP Security Architecture (Referenz).
IPsec-Dienstprogramm, -Datei oder -Service |
Beschreibung |
Manpage |
---|---|---|
svc:/network/ipsec/ipsecalgs |
Der SMF-Service, der in der aktuellen Version die IPsec-Algorithmen verwaltet. | |
svc:/network/ipsec/manual-key |
Der SMF-Service, der in der aktuellen Version die manuellen Sicherheitszuordnungen (SAs) verwaltet. | |
svc:/network/ipsec/policy |
Der SMF-Service, der in der aktuellen Version die IPsec-Richtlinie verwaltet. | |
svc:/network/ipsec/ike |
Der SMF-Service, der in der aktuellen Version für das automatische Management von IPsec-SAs sorgt. | |
/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-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. | |
PF_KEY-Socket-Schnittstelle |
Schnittstelle der Sicherheitszuordnung-Datenbank (SADB). Wickelt das manuelle und das automatische Schlüsselmanagement ab. | |
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. | |
/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. | |
/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. |
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:
Wenn ein Sun Crypto Accelerator 4000-Board angehängt ist, speichert das Board IPsec SAs für Pakete, die die Ethernet-Schnittstelle des Boards verwenden, automatisch im Cache-Speicher zwischen. Darüber hinaus beschleunigt das Board die Verarbeitung der IPsec SAs.
IPsec profitiert von den Vorteilen des automatischen Schlüsselmanagements mit IKE über IPv6-Netzwerke. Weitere Informationen finden Sie in Kapitel 22Internet Key Exchange (Übersicht).
Informationen zu den neuen IKE-Funktionen finden Sie unter Änderungen an IKE für das Release Solaris 10.
Der Parser für den ipseckey-Befehl enthält eine besser strukturierte Hilfe. Der Befehl ipseckey monitor versieht jedes Ereignis mit einer Zeitmarke. Einzelheiten entnehmen Sie der Manpage ipseckey(1M).
IPsec-Algorithmen stammen jetzt aus einem zentralen Speicher, dem Solaris Cryptographic Framework. Eigenschaften der verfügbaren Algorithmen sind in der Manpage ipsecalgs(1M) beschrieben. Die Algorithmen sind für die Architektur optimiert, auf der sie ausgeführt werden. Eine Beschreibung des Framework finden Sie in Kapitel 13, Oracle Solaris Cryptographic Framework (Overview) in System Administration Guide: Security Services.
IPsec arbeitet in der globalen Zone. Die IPsec-Richtlinie wird in der globalen Zone für eine nicht-globale Zone verwaltet. Das Schlüsselmaterial wird manuell in der globalen Zone für eine nicht-globale Zone erzeugt und verwaltet. IKE kann nicht zum Erzeugen von Schlüsseln für eine nicht-globale Zonen verwendet werden. Weitere Informationen zu Zonen finden Sie in Kapitel 16, Einführung in Solaris Zones in Systemverwaltungshandbuch: Oracle Solaris Container – Ressourcenverwaltung und Solaris Zones.
Die IPsec-Richtlinie kann mit dem Streams Control Transmission-Protokoll (SCTP) und der SCTP-Portnummer zusammenarbeiten. Dies wurde jedoch noch nicht vollständig realisiert. Die IPsec-Erweiterungen für SCTP, die in der RFC 3554 beschrieben sind, wurden an noch nicht umgesetzt. Diese Einschränkungen können zu Komplikationen beim Erstellen einer IPsec-Richtlinie für SCTP führen. Details finden Sie in den RFCs. Lesen Sie auch IPsec und SCTP und SCTP-Protokoll.
IPsec und IKE können Datenverkehr schützen, dessen Ursprung hinter einer NAT-Box liegt. Details und Einschränkungen finden Sie unter IPsec und NAT Traversal. Anweisungen finden Sie unter Konfiguration von IKE für mobile Systeme (Übersicht der Schritte).