test

Systemverwaltungshandbuch: IP Services

Teil IV IP-Sicherheit

In diesem Abschnitt werden Aspekte der Netzwerksicherheit beschrieben. Die Sicherheitsarchitektur für IP (IP Security Architecture, IPsec) schützt das Netzwerk auf der Paketebene. Der Internet-Schlüsselaustausch (Internet Key Exchange, IKE) verwaltet die Schlüssel für IPsec. Oracle Solaris IP Filter stellt eine Firewall bereit.

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:

Kapitel 20 Konfiguration von IPsec (Aufgaben)

In diesem Kapitel sind die Verfahren zur Realisierung von IPsec in Ihrem Netzwerk beschrieben. Die Verfahren sind in den folgenden Tabellen beschrieben:

Eine Einführung in IPsec finden Sie in Kapitel 19IP Security Architecture (Übersicht). Referenzinformationen zu IPsec finden Sie in Kapitel 21IP Security Architecture (Referenz).

Schützen des Datenverkehrs mit IPsec (Übersicht der Schritte)

Die folgende Tabelle enthält Links zu den Verfahren, mit denen IPsec zwischen einem oder mehreren Systemen eingerichtet wird. Die Manpages ipsecconf(1M), ipseckey(1M) und ifconfig(1M) enthalten weitere nützliche Verfahren in den jeweiligen Beispiel-Abschnitten.

Aufgabe 

Beschreibung 

Siehe 

Sichern des Datenverkehrs zwischen zwei Systemen. 

Schützen Sie Pakete auf dem Weg von einem System zum anderen. 

So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec

Sichern eines Webbrowsers mithilfe einer IPsec-Richtlinie. 

Erzwingen Sie, dass nicht-Webverkehr IPsec verwendet. Webclients werden durch die jeweiligen Ports identifiziert, die IPsec-Prüfungen umgehen. 

How to Use IPsec to Protect a Web Server From Nonweb Traffic

Anzeigen der IPsec-Richtlinien. 

Zeigen Sie die derzeit durchgesetzten IPsec-Richtlinien in der Durchsetzungsreihenfolge an. 

So zeigen Sie die IPsec-Richtlinien an

Erzeugen von Zufallszahlen. 

Erzeugen Sie Zufallszahlen für das Schlüsselmaterial von manuell erstellten Sicherheitszuordnungen. 

So erzeugen Sie Zufallszahlen auf einem Solaris-System

How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services

Erstellen oder manuelles Ersetzen von Sicherheitszuordnungen. 

Stellen Sie die Raw-Daten für Sicherheitszuordnungen bereit: 

  • Name des IPsec-Algorithmus und Schlüsselmaterial

  • Schlüssel für den Security Parameter Index

  • IP-Quell- und Zieladressen

So erstellen Sie manuell IPsec-Sicherheitszuordnungen

Prüfen, ob IPsec die Pakete schützt. 

Suchen Sie in der Ausgabe des Befehls snoop nach bestimmten Headern, die anzeigen, wie IP-Datagramme geschützt werden.

So prüfen Sie, ob Pakete mit IPsec geschützt sind

(Optional) Erstellen einer Network Security-Rolle. 

Erstellen Sie eine Rolle, mit der ein sicheres Netzwerk eingerichtet werden kann, die aber über weniger Rechte als ein Superuser verfügt. 

How to Configure a Role for Network Security

Verwalten von IPsec und Schlüsselmaterial als Gruppe von SMF-Services. 

Beschreibt, wann und wie die Befehle zum Aktivieren, Deaktivieren, Aktualisieren und erneuten Starten von Services verwendet werden. Beschreibt außerdem die Befehle, die die Eigenschaftswerte von Services ändern. 

Verwalten von IKE- und IPsec-Services

Einrichten eines sicheren virtuellen privaten Netzwerks (VPN). 

Richten Sie IPsec zwischen zwei Systemen ein, die durch das Internet voneinander getrennt sind. 

Schützen eines VPN mit IPsec (Übersicht der Schritte)

Schützen von Datenverkehr mit IPsec

Dieser Abschnitt enthält Verfahren, mit denen Sie den Datenverkehr zwischen zwei Systemen und einen Webserver sichern können. Informationen zum Schützen eines VPN finden Sie unter Schützen eines VPN mit IPsec (Übersicht der Schritte) . Zusätzliche Verfahren bieten Schlüsselmaterial und Sicherheitszuordnungen und stellen sicher, dass IPsec gemäß der Konfiguration arbeitet.

Die folgenden Informationen gelten für alle Aufgaben bei der Konfiguration von IPsec:

ProcedureSo sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec

Dieses Verfahren nimmt das folgende Setup an:

Bevor Sie beginnen

Sie müssen sich in der globalen Zone befinden, um die IPsec-Richtlinie für das System oder für eine gemeinsame IP-Zone zu konfigurieren. Für eine exklusive IP-Zone konfigurieren Sie die IPsec-Richtlinie in der nicht-globalen Zone.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine Remoteanmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere remote Anmeldung. Ein Beispiel finden Sie unter Beispiel 20–1.

  2. Prüfen Sie auf jedem System Host-Einträge.

    In der aktuellen Version fügen Sie die Hosteinträge der Datei /etc/inet/hosts hinzu.

    Bei einem System, das ein älteres Release als Solaris 10 7/07 ausführt, fügen Sie die IPv4- und IPv6-Einträge zur Datei /etc/inet/ipnodes hinzu. Die Einträge für ein System müssen untereinander in der Datei stehen. TCP/IP-KonfigurationsdateienKapitel 11IPv6 im Detail (Referenz).

    Wenn Sie die Systeme nur mit IPv4-Adressen verbinden, nehmen Sie die Änderungen an der /etc/inet/hosts-Datei vor. In diesem Beispiel führen die zu verbindenden Systeme ein früheres Solaris-Release aus und verwenden IPv6-Adressen.

    1. Geben Sie auf dem System enigma Folgendes in die Datei hosts bzw. ipnodes ein:


      # Secure communication with partym
192.168.13.213 partym
2001::eeee:3333:3333 partym

    2. Geben Sie auf dem System partym Folgendes in die Datei hosts bzw. ipnodes ein:


      # Secure communication with enigma
192.168.116.16 enigma
2001::aaaa:6666:6666 enigma

    Es ist unsicher, die Namensdienste für symbolische Namen zu verwenden.

  3. Erstellen Sie auf jedem System die IPsec-Richtliniendatei.

    Der Dateiname lautet /etc/inet/ipsecinit.conf. Ein Beispiel finden Sie in der Datei /etc/inet/ipsecinit.sample.

  4. Fügen Sie einen IPsec-Richtlinieneintrag in die Datei ipsecinit.conf ein.

    1. Fügen Sie die folgende Richtlinie auf dem System enigma hinzu:


      {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. Fügen Sie eine identische Richtlinie auf dem System partym hinzu:


      {laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

      Informationen zur Syntax der IPsec-Richtlinieneinträge finden Sie in der Manpage ipsecconf(1M).

  5. Fügen Sie auf jedem System ein IPsec SA-Paar zwischen den zwei Systemen ein.

    Sie können Internet Key Exchange (IKE) konfigurieren, um die SAs automatisch zu erstellen. Die SAs können auch manuell hinzugefügt werden.

    Hinweis –

    Sie sollten IKE verwenden, es sei denn, Sie haben einen triftigen Grund, Ihre Schlüssel manuell zu erzeugen und zu verwalten. Das IKE-Schlüsselmanagement ist sicherer als das manuelle Schlüsselmanagement.

  6. Aktivieren Sie die IPsec-Richtlinie.

    • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, starten Sie das System neu.


      # init 6

      Fahren Sie anschließend mit den Erläuterungen unter So prüfen Sie, ob Pakete mit IPsec geschützt sind fort.

    • Aktualisieren Sie ab Solaris 10 4/09 den IPsec-Service, und aktivieren Sie den Schlüsselmanagement-Service.

      Führen Sie Schritt 7 bis Schritt 10 durch.

  7. Überprüfen Sie die Syntax der IPsec-Richtliniendatei.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

    Beheben Sie alle Fehler, überprüfen Sie die Syntax der Datei, und fahren Sie fort.

  8. Aktualisieren Sie die IPsec-Richtlinie.


    # svcadm refresh svc:/network/ipsec/policy:default

    Die IPsec-Richtlinie wird standardmäßig aktiviert, daher sollten Sie sie aktualisieren. Falls Sie die IPsec-Richtlinie deaktiviert haben, aktivieren Sie sie.


    # svcadm enable svc:/network/ipsec/policy:default

  9. Aktivieren Sie die Schlüssel für IPsec.

    • Wenn Sie IKE in Schritt 5 konfiguriert haben, führen Sie eine der folgenden Aktionen durch:

      • Wenn der ike-Service nicht aktiviert ist, aktivieren Sie ihn.


        # svcadm enable svc:/network/ipsec/ike:default

      • Wenn der ike-Service aktiviert ist, starten Sie ihn neu.


        # svcadm restart svc:/network/ipsec/ike:default

    • Wenn Sie in Schritt 5 Schlüssel manuell konfiguriert haben, führen Sie eine der folgenden Aktionen durch:

      • Wenn der manual-key-Service nicht aktiviert ist, aktivieren Sie ihn.


        # svcadm enable svc:/network/ipsec/manual-key:default

      • Wenn der manual-key-Service aktiviert ist, aktualisieren Sie ihn.


        # svcadm refresh svc:/network/ipsec/manual-key:default

  10. Prüfen Sie, ob die Pakete geschützt werden.

    Informationen hierzu finden Sie unter So prüfen Sie, ob Pakete mit IPsec geschützt sind.

Beispiel 20–1 Hinzufügen der IPsec-Richtlinie für eine ssh-Verbindung

In diesem Beispiel konfiguriert der Administrator als Superuser die IPsec-Richtlinie und die Schlüssel auf zwei Systemen mithilfe des Befehls ssh, um das zweite System zu erreichen. Weitere Informationen finden Sie in der Manpage ssh(1).

Bei der nächsten Kommunikation der beiden Systeme, einschließlich einer ssh-Verbindung, wird die Kommunikation durch IPsec geschützt.

Beispiel 20–2 Schutz des Datenverkehrs mit IPsec ohne erneutes Booten

Das folgende Beispiel ist nützlich, wenn Sie mit einer älteren Version als Solaris 10 4/09 arbeiten. Zumindest, wenn in Ihrer Version IPsec nicht als Service verwaltet wird. Im Beispiel wird beschrieben, wie Sie IPsec in einer Testumgebung implementieren. In einer Produktionsumgebung ist erneutes Booten des Systems sicherer als das Ausführen des Befehls ipsecconf. Informationen zu den Sicherheitsbetrachtungen finden Sie am Ende dieses Beispiels.

Anstatt in Schritt 6 neu zu booten, wählen Sie eine der folgenden Optionen:

Sicherheitsbetrachtungen – Lesen Sie die Warnung, wenn Sie den Befehl ipsecconf ausführen. Ein bereits gesperrtes Socket, das heißt, ein Socket das bereits verwendet wird, stellt eine ungesicherte Hintertür zum System dar. For more extensive discussion, see Sicherheitsbetrachtungen für ipsecinit.conf und ipsecconf.

ProcedureHow to Use IPsec to Protect a Web Server From Nonweb Traffic

Ein sicherer Webserver gestattet es Webclients, Daten untereinander über den Webservice auszutauschen. Auf einem sicheren Webserver muss Datenverkehr, bei dem es sich nicht um Webverkehr handelt, Sicherheitsprüfungen durchlaufen. Das folgende Verfahren beinhaltet Umgehungen für Webverkehr. Darüber hinaus kann dieser Webserver nicht sichere DNS-Client-Anforderungen stellen. Der gesamte verbleibende Verkehr erfordert ESP mit AES- und SHA-1-Algorithmen.

Bevor Sie beginnen

Zur Konfiguration der IPsec-Richtlinie müssen Sie sich in der globalen Zone befinden. Für eine exklusive IP-Zone konfigurieren Sie die IPsec-Richtlinie in der nicht-globalen Zone. Sie haben den Abschnitt So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec abgeschlossen, d. h. folgende Bedingungen sind wirksam:

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere remote Anmeldung.

  2. Stellen Sie fest, welche Services Prüfungen der Sicherheitsrichtlinien umgehen müssen.

    Bei einem Webserver umfassen diese Services TCP-Ports 80 (HTTP) und 443 (Secure HTTP). Wenn der Webserver DNS-Namenssuchen bereitstellt, muss der Server auch Port 53 für TCP und UDP umfassen.

  3. Erstellen Sie die IPsec-Richtlinie für den Webserver, und aktivieren Sie sie.

    Schritt 12 ist in allen Solaris-Versionen optional.

  4. Fügen Sie der IPsec-Richtlinendatei die Webserver-Richtlinie hinzu.

    Fügen Sie der Datei /etc/inet/ipsecinit.conf folgende Zeilen hinzu:


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Bei dieser Konfiguration ist nur bei sicherem Verkehr ein Zugriff auf das System möglich. Dabei gelten die in Schritt 4 beschriebenen Ausnahmen für die Umgehung.

  5. Überprüfen Sie die Syntax der IPsec-Richtliniendatei.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Aktualisieren Sie die IPsec-Richtlinie.


    # svcadm refresh svc:/network/ipsec/policy:default

  7. Aktualisieren Sie die Schlüssel für IPsec.

    Ihre Einrichtung ist abgeschlossen. Sie können Schritt 12 optional durchführen.

  8. Erstellen Sie eine Datei im Verzeichnis /etc/inet für die Webserver-Richtlinie.

    Hinweis –

    Durch die folgenden Schritte wird ein Webserver konfiguriert, auf der eine ältere Version als Solaris 10 4/09 ausgeführt wird.

    Benennen Sie die Datei mit einem aussagekräftigen Namen, z. B. IPsecWebInitFile. Geben Sie die folgenden Zeilen in diese Datei ein:


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Diese Konfiguration gestattet nur sicherem Verkehr den Zugriff auf das System. Dabei gelten die in Schritt 4 beschriebenen Ausnahmen für die Umgehung.

  9. Kopieren Sie den Inhalt der von Ihnen in Schritt 8 erstellten Datei in die /etc/inet/ipsecinit.conf-Datei.

  10. Schützen Sie die Datei IPsecWebInitFile, indem Sie Nur-Lese-Berechtigungen zuweisen.


    # chmod 400 IPsecWebInitFile

  11. Sichern Sie den Webserver, ohne ihn erneut zu booten.

    Wählen Sie eine der folgenden Optionen:

    • Wenn Sie IKE zum Schlüsselmanagement verwenden, stoppen Sie den in.iked-Daemon und starten ihn neu.


      # pkill in.iked
# /usr/lib/inet/in.iked

    • Wenn Sie die Schlüssel manuell verwalten, verwenden Sie die Befehle ipseckey und ipsecconf.

      Verwenden Sie IPsecWebInitFile als Argument für den Befehl ipsecconf. Wenn Sie die Datei ipsecinit.conf als Argument verwenden, erzeugt der Befehl ipsecconf Fehlermeldungen, wenn die Richtlinien in der Datei bereits auf dem System implementiert sind.


      # ipseckey -c -f /etc/inet/secret/ipseckeys 
# ipsecconf -a /etc/inet/IPsecWebInitFile
    Achtung – Achtung –

    Lesen Sie die Warnmeldung, wenn Sie den Befehl ipsecconf ausführen. Ein bereits gesperrtes Socket, das heißt, ein Socket das bereits verwendet wird, stellt eine ungesicherte Hintertür zum System dar. Ausführlichere Informationen finden Sie unter Sicherheitsbetrachtungen für ipsecinit.conf und ipsecconf. Die gleiche Warnmeldung gilt für den Neustart des in.iked-Daemon.

    Sie können auch erneut booten. Durch erneutes Booten wird sichergestellt, dass die IPsec-Richtlinie für alle TCP-Verbindungen übernommen wird. Bei erneutem Booten verwenden die TCP-Verbindungen die Richtlinie in der IPsec-Richtliniendatei.

  12. (Optional) Konfigurieren Sie ein Remote-System so, dass es für NonWeb-Verkehr mit dem Webserver kommuniziert.

    Geben Sie die folgende Richtlinie die Datei ipsecinit.conf auf einem Remote-System ein:


    # Communicate with web server about nonweb stuff
#
{laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Ein remotes System kann nur dann sicher mit dem Webserver NonWeb-Verkehr austauschen, wenn die IPsec-Richtlinien der Systeme übereinstimmen.

ProcedureSo zeigen Sie die IPsec-Richtlinien an

Geben Sie den Befehl ipsecconf ohne weitere Argumente ein, um die auf dem System konfigurierten Richtlinien anzuzeigen.

Bevor Sie beginnen

Sie müssen den Befehl ipsecconf in der globalen Zone ausführen. Führen Sie für eine exklusive IP-Zone den Befehl ipsecconf in der nicht-globalen Zone aus.

  1. Nehmen Sie eine Rolle an, die das Network IPsec Management-Profil beinhaltet, oder melden Sie sich als Superuser an.

    Wenn Sie eine ältere Version als Solaris 10 4/09 ausführen, ist das Profil für die Netzwerk-IPsec-Verwaltung nicht verfügbar. Verwenden Sie das Profil für Netzwerksicherheit.

    Informationen zum Erstellen einer Rolle, die das Network Security-Profil beinhaltet und zum Zuweisen dieser Rolle zu einem Benutzer finden Sie unter How to Configure a Role for Network Security.

  2. Anzeigen der IPsec-Richtlinien.

    1. Zeigen Sie die Einträge in der globalen IPsec-Richtlinie in der Reihenfolge an, in der sie wurden.


      $ ipsecconf

      Mit diesem Befehl wird jedem Eintrag ein Index gefolgt von einer Zahl zugeordnet.

    2. Zeigen Sie die Einträge der IPsec-Richtlinie in der Reihenfolge an, in der eine Übereinstimmung auftritt.


      $ ipsecconf -l

    3. Zeigen Sie die Einträge der IPsec-Richtlinie, einschließlich der für einen Tunnel geltenden Einträge, in der Reihenfolge an, in der eine Übereinstimmung auftritt.


      $ ipsecconf -L

ProcedureSo erzeugen Sie Zufallszahlen auf einem Solaris-System

Wenn Sie die Schlüssel manuell eingeben, muss das Schlüsselmaterial zufällig erzeugt worden sein. Bei einem Solaris-System muss das Schlüsselmaterial im hexadezimalen Format vorliegen. Andere Betriebssysteme erfordern Schlüsselmaterial im ASCII-Format. Informationen zum Erzeugen von Schlüsselmaterial für ein Solaris-System, das mit einem Betriebssystem kommuniziert, für das ASCII-Daten erforderlich sind, finden Sie in Beispiel 23–1.

Falls Ihr Standort über einen Generator für Zufallszahlen verfügt, verwenden Sie diesen. Andernfalls können Sie den Befehl od mit dem Solaris-Gerät /dev/random als Eingabe verwenden. Weitere Informationen finden Sie in der Manpage od(1).

In der Solaris 10 4/09-Version können Sie auch den Befehl pktool verwenden. Die Syntax dieses Befehls ist einfacher als die Syntax des Befehls od. Weitere Informationen finden Sie unter How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services

  1. Erzeugen Sie hexadezimale Zufallszahlen.


    % od -x|-X -A n file | head -n
    -x

    Zeigt das oktale Abbild im hexadezimalen Format an. Das hexadezimale Format eignet sich für das Schlüsselmaterial. Der hexadezimale Wert wird in 4-Zeichen-Chunks gedruckt.

    -X

    Zeigt das oktale Abbild im hexadezimalen Format an. Der hexadezimale Wert wird in 8-Zeichen-Chunks gedruckt.

    -A n

    Löscht die Eingabe-Offsetbasis vom Bildschirm.

    Datei

    Dient als Quelle für die Zufallszahlen.

    head -n

    Beschränkt die Anzeige auf die ersten n Zeilen der Ausgabe.

  2. Verbinden Sie die Ausgabe, um einen Schlüssel in der angegebenen Länge zu erzeugen.

    Löschen Sie die Leerzeichen zwischen den Zahlen auf einer Zeile, um einen Schlüssel mit 32 Zeichen zu erzeugen. Ein 32-Zeichen-Schlüssel hat eine Länge von 128 Bit. Für den Security Parameter Index (SPI) sollten Sie einen 8-Zeichen-Schlüssel verwenden. Der Schlüssel sollte das Präfix 0x verwenden.

Beispiel 20–3 Erzeugen des Schlüsselmaterials für IPsec

Im folgenden Beispiel werden zwei Zeilen mit Schlüsseln in Gruppen von jeweils acht hexadezimalen Zeichen angezeigt.


% od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b

Durch Verbinden der vier Zeichengruppen in der ersten Zeile können Sie einen 32-Zeichen-Schlüssel erstellen. Eine 8-Zeichen-Zahl, die mit dem Präfix 0x beginnt, ergibt einen geeigneten SPI-Wert, z. B. 0xf3447465.

Im folgenden Beispiel werden zwei Zeilen mit Schlüsseln in Gruppen von jeweils vier hexadezimalen Zeichen angezeigt.


% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

Durch Verbinden der acht Zeichengruppen in der ersten Zeile können Sie einen 32-Zeichen-Schlüssel erstellen.

ProcedureSo erstellen Sie manuell IPsec-Sicherheitszuordnungen

Im folgenden Verfahren wird das Schlüsselmaterial für das Verfahren So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec erstellt. Sie generieren Schlüssel für die beiden Systeme partym und enigma. Sie generieren die Schlüssel auf einem System und verwenden dann die Schlüssel des ersten Systems auf beiden Systemen.

Bevor Sie beginnen

Sie müssen sich in der globalen Zone befinden, um das Schlüsselmaterial für eine Zone mit gemeinsamer IP manuell verwalten zu können.

  1. Erzeugen Sie das Schlüsselmaterial für die SAs.

    Sie benötigen drei hexadezimale Zufallszahlen für den abgehenden Verkehr und drei hexadezimale Zufallszahlen für den eingehenden Verkehr.

    Somit muss ein System die folgenden Zahlen erzeugen:

    • Zwei hexadezimale Zufallszahlen als Wert für das Schlüsselwort spi. Eine Zahl für den abgehenden Verkehr, eine Zahl für den eingehenden Verkehr. Jede Zahl kann bis zu acht Zeichen umfassen.

    • Zwei hexadezimale Zufallszahlen für den SHA1-Algorithmus für die Authentifizierung. Bei einem 160-Bit-Schlüssel muss jede Zahl 40 Zeichen umfassen. Eine Zahl für dst enigma, eine Zahl für dst partym.

    • Zwei hexadezimale Zufallszahlen für den AES-Algorithmus für die ESP-Verschlüsselung. Bei einem 256-Bit-Schlüssel muss jede Zahl 64 Zeichen umfassen. Eine Zahl für dst enigma, eine Zahl für dst partym.

    Wenn Sie über einen Generator für Zufallszahlen an Ihren Standort verfügen, verwenden Sie diesen. Alternativ verwenden Sie den Befehl od. Anleitungen dazu finden Sie unter So erzeugen Sie Zufallszahlen auf einem Solaris-System.

  2. Nehmen Sie über die Systemkonsole eines der Systeme die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere remote Anmeldung.

  3. Erstellen Sie die SAs

  4. Aktivieren Sie den ipseckey-Befehlsmodus.


    # ipseckey

>

    Die Eingabeaufforderung > kennzeichnet, dass sich das System im ipseckey-Befehlsmodus befindet.

  5. Wenn Sie vorhandere SAs ersetzen, leeren Sie die aktuellen SAs.


    > flush
>

    Um zu verhindern, dass ein potentieller Angreifer die Zeit hat, Ihre SAs zu entschlüsseln, müssen Sie das Schlüsselmaterial ersetzen.

    Hinweis –

    Sie müssen den Schlüsselaustausch jedoch bei kommunizierenden Systemen koordinieren. Wenn Sie die SAs auf einem System ersetzen, müssen sie auch auf dem remoten System ersetzt werden.

  6. Zum Erstellen von SAs geben Sie den folgenden Befehl ein.


    > add protocol spi random-hex-string \
src addr dst addr2 \
protocol-prefix_alg protocol-algorithm  \
protocol-prefixkey random-hex-string-of-algorithm-specified-length

    Sie verwenden diese Syntax auch zum Ersetzen der gerade geleerten SAs.

    Protokoll

    Geben Sie entweder esp oder ah an.

    zufällige-hexadezimale-Zeichenfolge

    Gibt eine Zufallszahl mit bis zu acht Zeichen in hexadezimalem Format an. Stellen Sie den Zeichen das Präfix 0x voran. Wenn Sie mehr Zahlen eingeben, als der Security Parameter Index (SPI) akzeptiert, so ignoriert das System die überflüssigen Zahlen. Wenn Sie weniger Zahlen eingeben als der Security Parameter Index (SPI) akzeptiert, so füllt das System Ihren Eintrag auf.

    adr

    Gibt die IP-Adresse eines Systems an.

    adr2

    Gibt die IP-Adresse des Peer-Systems von adr an.

    Protokollpräfix

    Gibt entweder encr oder auth an. Das Präfix encr wird mit dem esp-Protokoll verwendet. Das Präfix auth wird mit dem ah-Protokoll und zur Authentifizierung des esp-Protokolls verwendet.

    Protokollalgorithmus

    Gibt einen Algorithmus für ESP oder AH an. Jeder Algorithmus erfordert einen Schlüssel mit einer bestimmten Länge.

    Die Authentifizierungsalgorithmen umfassen MD5 und SHA1. Ab Version Solaris 10 4/09 werden SHA256 und SHA512 unterstützt. Verschlüsselungsalgorithmen beinhalten DES, 3DES, AES und Blowfish.

    zufällige-hexadezimale-Zeichenfolge-in-der-vom-Algorithmus-vorbestimmten-Länge

    Gibt eine zufällige hexadezimale Zahl der Länge an, die für den Algorithmus erforderlich ist. Beispielsweise erfordert der MD5-Algorithmus einen 32-Zeichen-String für den 128-Bit-Schlüssel. Der 3DES-Algorithmus erfordert einen 48-Zeichen-String für den 192-Bit-Schlüssel.

    1. Schützen Sie z. B. abgehende Pakete auf dem System enigma.

      Verwenden Sie die in Schritt 1 erzeugten Zufallszahlen.

      Unter Solaris 10 1/06:


      > add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg aes \
auth_alg sha1 \
encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
authkey 6fab07fec4f2895445500ed992ab48835b9286ff
>
      Hinweis –

      Das Peer-System muss das gleiche Schlüsselmaterial und den gleichen SPI verwenden.

    2. Bleiben Sie auf dem enigma-System im ipseckey-Befehlsmodus, und schützen Sie die eingehenden Pakete.

      Geben Sie die folgenden Befehle ein, um die Pakete zu schützen:


      > add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg aes \
auth_alg sha1 \
encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
authkey c80984bc4733cc0b7c228b9b74b988d2b7467745
>
      Hinweis –

      Die Schlüssel und der SPI können für jede SA unterschiedlich sein. Sie sollten für jede SA andere Schlüssel und einen anderen SPI zuweisen.

  7. Um den ipseckey-Befehlsmodus zu beenden, drücken Sie Strg-D oder geben quit ein.

  8. Fügen Sie der /etc/inet/secret/ipseckeys-Datei das Schlüsselmaterial hinzu.

    In älteren Versionen als Solaris 10 4/09 wird durch diesen Schritt sichergestellt, dass IPsec das Schlüsselmaterial beim Neustart zur Verfügung steht.

    Die Zeilen in der /etc/inet/secret/ipseckeys sind identisch mit der Befehlszeilensprache ipseckey.

    1. Beispielsweise ähnelt die Datei /etc/inet/secret/ipseckeys auf dem enigma-System dem Folgenden:


      # ipseckeys - This file takes the file format documented in 
#   ipseckey(1m).
#   Note that naming services might not be available when this file
#   loads, just like ipsecinit.conf.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

    2. Schützen Sie die Datei, indem Sie Nur-Lese-Berechtigungen zuweisen.


      # chmod 400 /etc/inet/secret/ipseckeys

  9. Wiederholen Sie den Vorgang auf dem System partym.

    Verwenden Sie das gleiche Schlüsselmaterial wie für enigma.

    Das Schlüsselmaterial muss auf den beiden Systemen identisch sein. Wie in dem folgenden Beispiel gezeigt, unterscheiden sich lediglich die Kommentare in der ipseckeys-Datei. Dies ist der Fall, weil dstenigma auf dem enigma-System für eingehenden Verkehr und auf dem partym-System für ausgehenden Verkehr gilt.


    # partym ipseckeys file
#
# for inbound packets
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for outbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

  10. Aktivieren Sie den Service manual-key.


    # svcadm enable svc:/network/ipsec/manual-key

    Informationen zum Ersetzen von Schlüsseln in der aktuellen Version finden Sie in Beispiel 20–4.

Beispiel 20–4 Ersetzen von IPsec-SAs

In diesem Beispiel konfiguriert der Administrator ein System, auf dem die aktuelle VersionSolaris 10 ausgeführt wird. Der Administrator generiert neue Schlüssel, ändert die Schlüsselinformationen in der Datei ipseckeys und startet den Service dann neu.

ProcedureSo prüfen Sie, ob Pakete mit IPsec geschützt sind

Um zu Überprüfen, ob die Pakete geschützt sind, testen Sie die Verbindung mit dem Befehl snoop. In der Ausgabe des Befehls snoop können die folgenden Präfixe erscheinen:

Bevor Sie beginnen

Zum Erstellen einer Ausgabe des Befehls snoop müssen Sie als Superuser angemeldet sein oder eine entsprechende Rolle angenommen haben. Sie müssen Zugriff auf beide Systeme haben, um die Verbindung zu testen.

  1. Melden Sie sich auf einem System, z. B. partym, als Superuser an.


    % su -
Password: Type root password
#

  2. Bereiten Sie vom partym-System aus das Snoopen der Pakete von einem remoten System vor.

    Snoopen Sie in einem Terminal-Fenster auf partym die Pakete vom enigma-System.


    # snoop -v enigma
Using device /dev/hme (promiscuous mode)

  3. Senden Sie ein Paket vom remoten System.

    Melden Sie sich in einem anderen Terminal-Fenster remote beim enigma-System an. Geben Sie Ihr Passwort ein. Melden der Sie sich dann als Superuser an und senden Sie ein Paket vom enigma-System an das partym-System. Das Paket soll von dem Befehl snoop -venigma erfasst werden.


    % ssh enigma
Password: Type your password
% su -
Password: Type root password
# ping partym

  4. Zeigen Sie die Ausgabe des Befehls snoop an.

    Auf dem partym-die System sollten Sie eine Ausgabe sehen, die AH- und ESP-Informationen nach den einleitenden IP-Header-Informationen enthält. AH- und ESP-Informationen, die dem Folgenden ähneln, sind geschützte Pakete:


    IP:   Time to live = 64 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 4e0e
IP:   Source address = 192.168.116.16, enigma
IP:   Destination address = 192.168.13.213, partym
IP:   No options
IP:
AH:  ----- Authentication Header -----
AH:
AH:  Next header = 50 (ESP)
AH:  AH length = 4 (24 bytes)
AH:  <Reserved field = 0x0>
AH:  SPI = 0xb3a8d714
AH:  Replay = 52
AH:  ICV = c653901433ef5a7d77c76eaa
AH:
ESP:  ----- Encapsulating Security Payload -----
ESP:
ESP:  SPI = 0xd4f40a61
ESP:  Replay = 52
ESP:     ....ENCRYPTED DATA....

ETHER:  ----- Ether Header -----
...

ProcedureHow to Configure a Role for Network Security

Wenn Sie die rollenbasierte Zugriffskontrolle (RBAC) zur Verwaltung Ihrer Systeme einsetzen, können Sie mit dem folgenden Verfahren eine Rolle für die Netzwerkverwaltung oder Netzwerksicherheit erstellen.

  1. Suchen Sie das Network-Rechteprofil in der lokalen prof_attr-Datenbank.

    In der aktuellen Version sieht die Ausgabe ungefähr folgendermaßen aus:


    % cd /etc/security
% grep Network prof_attr
Network IPsec Management:::Manage IPsec and IKE...
Network Link Security:::Manage network link security...
Network Management:::Manage the host and network configuration...
Network Security:::Manage network and host security...
Network Wifi Management:::Manage wifi network configuration...
Network Wifi Security:::Manage wifi network security...

    Wenn Sie mit einer älteren Version von Solaris 10 4/09 arbeiten, sieht die Ausgabe ungefähr folgendermaßen aus:


    % cd /etc/security
% grep Network prof_attr
Network Management:::Manage the host and network configuration  
Network Security:::Manage network and host security  
System Administrator::: Network Management 

    Das Network Management-Profil ist ein ergänzendes Profil im System Administrator-Profil. Wenn Sie das System Administrator-Rechteprofil in eine Rolle aufgenommen haben, kann diese Rolle die Befehle im Network Management-Profil ausführen.

  2. Stellen Sie fest, welche Befehle im Network Management-Rechteprofil zulässig sind.


    % grep "Network Management" /etc/security/exec_attr
Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config
…
Network Management:suser:cmd:::/usr/sbin/snoop:uid=0

    Die Richtlinienbefehle solaris werden mit einer Berechtigung (privs=sys_net_config) ausgeführt. Die Richtlinienbefehle suser werden als Superuser (uid=0) ausgeführt.

  3. Legen Sie den Umfang der Netzwerksicherheitsrollen an Ihrem Standort fest.

    Verwenden Sie die Definitionen der Rechteprofile in Schritt 1, um eine Entscheidung zu treffen.

    • Zum Erstellen einer Rolle, die sich um die gesamte Netzwerksicherheit kümmert, verwenden Sie das Rechteprofil für Netzwerksicherheit.

    • In der aktuellen Version verwenden Sie zum Erstellen einer Rolle zur ausschließlichen Verwaltung von IPsec und IKE das Rechteprofil für die Netzwerk-IPsec-Verwaltung.

  4. Erstellen Sie eine Netzwerksicherheitsrolle, die das Rechteprofil für die Netzwerkverwaltung enthält.

    Mit einer Rolle mit dem Rechteprofil für Netzwerksicherheit bzw. Netzwerk-IPsec-Verwaltung können zusätzlich zum Profil für die Netzwerkverwaltung unter anderem die Befehle ifconfig, snoop, ipsecconf und ipseckey mit entsprechenden Berechtigungen ausgeführt werden.

    Zum Erstellen einer Rolle weisen Sie die Rolle einem Benutzer zu und registrieren die Änderungen beim Namen-Service. Lesen Sie dazu Configuring RBAC (Task Map) in System Administration Guide: Security Services .

Beispiel 20–5 Aufteilen von Netzwerk-Sicherheitsverantwortlichkeiten zwischen Rollen

In diesem Beispiel teilt der Administrator Netzwerk-Sicherheitsverantwortlichkeiten zwischen zwei Rollen auf. Eine Rolle verwaltet die Wifi- und Linksicherheit, während die andere Rolle IPsec und IKE verwaltet. Jede Rolle ist drei Personen zugewiesen, d. h. einer Person pro Schicht.

Die Rollen werden vom Administrator wie folgt erstellt:

ProcedureVerwalten von IKE- und IPsec-Services

In den folgenden Schritten werden die wahrscheinlichsten Verwendungsmöglichkeiten der SMF-Services für IPsec, IKE und der manuellen Schlüsselverwaltung beschrieben. Die policy- und ipsecalgs-Services werden standardmäßig aktiviert. Außerdem werden die ike- und manual-key-Services standardmäßig deaktiviert.

  1. Führen Sie eine der folgenden Aktionen zum Verwalten der IPsec-Richtlinie aus:

    • Aktualisieren Sie nach dem Hinzufügen neuer Richtlinien zur Datei ipsecinit.conf den policy-Service.


      # svcadm refresh svc:/network/ipsec/policy

    • Zeigen Sie nach dem Ändern des Wertes einer Serviceeigenschaft den Eigenschaftswert an, und führen Sie eine Aktualisierung und einen Neustart des policy-Services durch.


      # svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf
# svcprop -p config/config_file policy
/etc/inet/MyIpsecinit.conf
# svcadm refresh svc:/network/ipsec/policy
# svcadm restart svc:/network/ipsec/policy

  2. Führen Sie eine der folgenden Aktionen zum automatischen Verwalten von Schlüsseln durch:

    • Aktivieren Sie nach dem Hinzufügen von Einträgen zur Datei /etc/inet/ike/config den ike-Service.


      # svcadm enable svc:/network/ipsec/ike

    • Aktualisieren Sie nach dem Ändern von Einträgen in der Datei /etc/inet/ike/config den ike-Service.


      # svcadm refresh svc:/network/ipsec/ike

    • Zeigen Sie nach dem Ändern des Wertes einer Serviceeigenschaft den Eigenschaftswert an, und führen Sie eine Aktualisierung und einen Neustart des Services durch.


      # svccfg -s ike setprop config/admin_privilege=modkeys
# svcprop -p config/admin_privilege ike
modkeys
# svcadm refresh svc:/network/ipsec/ike
# svcadm restart svc:/network/ipsec/ike

    • Deaktivieren Sie den ike-Service, um ihn anzuhalten.


      # svcadm disable svc:/network/ipsec/ike

  3. Führen Sie eine der folgenden Aktionen zum manuellen Verwalten von Schlüsseln durch:

    • Aktivieren Sie nach dem Hinzufügen von Einträgen zur Datei /etc/inet/secret/ipseckeys den manual-key-Service.


      # svcadm enable svc:/network/ipsec/manual-key

    • Aktualisieren Sie den Service nach dem Ändern der Datei ipseckeys.


      # svcadm refresh manual-key

    • Zeigen Sie nach dem Ändern des Wertes einer Serviceeigenschaft den Eigenschaftswert an, und führen Sie eine Aktualisierung und einen Neustart des Services durch.


      # svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile
# svcprop -p config/config_file manual-key
/etc/inet/secret/MyIpseckeyfile
# svcadm refresh svc:/network/ipsec/manual-key
# svcadm restart svc:/network/ipsec/manual-key

    • Zum Verhindern der manuellen Schlüsselverwaltung deaktivieren Sie den manual-key-Service.


      # svcadm disable svc:/network/ipsec/manual-key

  4. Wenn Sie die IPsec-Protokolle und die Algorithmustabelle ändern, aktualisieren Sie den ipsecalgs-Service.


    # svcadm refresh svc:/network/ipsec/ipsecalgs
Allgemeine Fehler

Verwenden Sie den Befehl svcs Service, um den Status eines Service zu ermitteln. Wenn sich der Service im maintenance-Modus befindet, folgen Sie den Debugging-Vorschlägen in der Ausgabe des Befehls svcs -x Service.

Schützen eines VPN mit IPsec

IPsec-Tunnel können ein VPN schützen. Im Release Solaris 10 7/07 kann sich ein Tunnel im Tunnelmodus oder Transportmodus befinden. Tunnelmodus kann mit den IPsec-Implementierungen anderer Anbieter zusammenarbeiten. Der Transportmodus kann mit früheren Versionen von Solaris OS zusammenarbeiten. Eine Beschreibung der Tunnelmodi finden Sie unter Transport- und Tunnelmodi in IPsec.

Tunnel im Tunnelmodus bieten eine genauere Kontrolle des Verkehrs. Im Tunnelmodus können Sie für eine interne IP-Adresse den gewünschten Schutz bis hin zu einem einzelnen Port zuweisen.

Beispiele für den Schutz eines VPN mit IPsec mithilfe von Tunneln im Tunnelmodus

Abbildung 20–1 IPsec-Tunnel-Diagramm

Das Diagramm zeigt ein VPN, das zwei LANs miteinander verbindet. Jedes LAN verfügt über vier Teilnetze.

In den folgenden Beispielen wird davon ausgegangen, dass der Tunnel für alle Teilnetze der LANs konfiguriert ist:


## Tunnel configuration ##
# Tunnel name is ip.tun0
# Intranet point for the source is 10.1.2.1
# Intranet point for the destination is 10.2.3.1
# Tunnel source is 192.168.1.10
# Tunnel destination is 192.168.2.10
Beispiel 20–6 Erstellen eines Tunnels, den alle Teilnetze verwenden können

In diesem Beispiel kann der gesamte Verkehr von den lokalen LANs des LAN Central in Abbildung 20–1 über Router 1 zu Router 2 getunnelt werden, dann wird der Verkehr allen lokalen LANs des LAN Overseas zugestellt. Dieser Verkehr wird mit AES verschlüsselt.


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
Beispiel 20–7 Erstellen eines Tunnels, der nur zwei Teilnetze miteinander verbindet

In diesem Beispiel wird nur der Verkehr zwischen Teilnetz 10.1.2.0/24 des LAN Central und Teilnetz 10.2.3.0/24 des LAN Overseas getunnelt und verschlüsselt. Da keine weiteren weiterer IPsec-Richtlinien für Central vorhanden sind, wird Verkehr an Router 1 abgeworfen, wenn das LAN Central versucht, Verkehr für andere LANs über diesen Tunnel zu routen.


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs aes encr_auth_algs md5 sha1 shared}
Beispiel 20–8 Erstellen eines Tunnels für E-Mail-Verkehr nur zwischen zwei Teilnetzen

In diesem Beispiel wird ein Tunnel ausschließlich für E-Mail-Verkehr erstellt. Der Verkehr wird von 10.1.2.0/24 des LAN Central an der E-Mail-Server im Teilnetz 10.2.3.0/24 des LAN Overseas zugestellt. Die E-Mails werden mit Blowfish verschlüsselt. Die Richtlinien gelten für den remoten und den lokalen E-Mail-Port. Die Richtlinie rport schützt E-Mail, die Central an den remoten E-Mail-Port von Overseas sendet. Die Richtlinie lport schützt E-Mail, die Central von Overseas am lokalen Port 25 empfängt.


## IPsec policy for email from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

## IPsec policy for email from Overseas to Central ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
Beispiel 20–9 Erstellen eines Tunnels für den FTP-Verkehr aller Teilnetze

In diesem Beispiel schützt die IPsec-Richtlinie die FTP-Ports in Abbildung 20–1 mit AES für alle Teilnetze des LAN Central zu allen Teilnetzen des LAN Overseas. Diese Konfiguration arbeitet im aktiven FTP-Modus.


## IPsec policy for outbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Schützen eines VPN mit IPsec (Übersicht der Schritte)

Die folgende Tabelle enthält Links zu den Verfahren, mit denen IPsec zum Schutz des Datenverkehrs über das Internet konfiguriert wird. Diese Verfahren richten ein sicheres virtuelles privates Netzwerk (VPN) zwischen zwei Systemen ein, die durch das Internet voneinander getrennt sind. Eine häufige Anwendung dieser Technologie ist das Schützen von Datenverkehr zwischen Heimarbeitern und dem Unternehmensbüro.

Aufgabe 

Beschreibung 

Siehe 

Schützen von Tunnelverkehr im Tunnelmodus über IPv4. 

Schützt Datenverkehr im Tunnelmodus zwischen zwei Solaris 10-Systemen; zwei Oracle Solaris-Systemen; oder zwischen einem Solaris 10-System und einem Oracle Solaris Express-System. Auf dem Solaris 10-System muss mindestens die Solaris 10 7/07-Version laufen. 

Schützt außerdem Datenverkehr im Tunnelmodus zwischen einem Solaris 10-System oder einem Oracle Solaris Express-System und einem System, das auf einer anderen Plattform ausgeführt wird. Auf dem Solaris 10-System muss mindestens die Solaris 10 7/07-Version laufen. 

So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4

Schützen vom Tunnelverkehr im Tunnelmodus über IPv6. 

Schützt Datenverkehr im Tunnelmodus zwischen zwei Oracle Solaris-Systemen, die das IPv6-Protokoll verwenden. 

So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv6

Schützen vom Tunnelverkehr im Transportmodus über IPv4. 

Schützt Datenverkehr im Transportmodus zwischen zwei Solaris 10-Systemen; zwei Solaris-Systemen oder zwischen einem Solaris 10-System und einem Oracle Solaris-System. Auf dem Solaris 10-System muss mindestens die Solaris 10 7/07-Version laufen. 

Schützt außerdem Datenverkehr im Transportmodus zwischen einem System, auf dem eine frühere Version von Solaris OS und Solaris 10 oder ein Oracle Solaris Express-System. läuft. Auf dem Solaris 10-System muss mindestens die Solaris 10 7/07-Version laufen. 

So schützen Sie ein VPN mit einem IPsec-Tunnel im Transportmodus über IPv4

Schützen Sie Datenverkehr durch das Verwenden einer älteren, eingestellten Syntax. Diese Methode eignet sich insbesondere dann, wenn Sie mit einem System kommunizieren, das eine frühere Version von Solaris OS ausführt. Diese Methode vereinfacht das Vergleichen der Konfigurationsdateien auf den zwei Systemen. 

Beispiel 20–11

Beispiel 20–16

Schützen vom Tunnelverkehr im Transportmodus über IPv6. 

Schützt Datenverkehr im Tunnelmodus zwischen zwei Oracle Solaris-Systemen, die das IPv6-Protokoll verwenden. 

So schützen Sie ein VPN mit einem IPsec-Tunnel im Transportmodus über IPv6

Verhindern von IP-Spoofing. 

Erstellt einen SMF-Service, um das System daran zu hindern, ohne Entschlüsselung Pakete über ein VPN der Pakete weiterzuleiten. 

So verhindern Sie IP-Spoofing

Beschreibung der Netzwerktopologie für IPsec-Aufgaben zum Schützen eines VPN

Bei den in diesem Abschnitt aufgeführten Verfahren wird das im Folgenden beschriebene Setup vorausgesetzt. Eine Darstellung des Netzwerks finden Sie in Abbildung 20–2.

Abbildung 20–2 Beispiel-VPN zwischen Büros, die durch das Internet voneinander getrennt sind

Das Diagramm zeigt Details eines VPN zwischen den Büros Europe und California.

Wie die oben stehende Abbildung zeigt, verwenden die Verfahren für das IPv4-Netzwerk die folgenden Konfigurationsparameter.

Parameter 

Europe 

California 

Systemname 

 

enigma
 

partym

System-Intranet-Schnittstelle 

 

hme1
 

hme1

Die System-Intranet-Adresse und die -point-Adresse in Schritt 7 


10.16.16.6
 

10.1.3.3

System-Internet-Schnittstelle 

 

hme0
 

hme0

Die System-Internet-Adresse und die tsrc-Adresse in Schritt 7 


192.168.116.16
 

192.168.13.213

Name des Internet-Routers 

 

router-E
 

router-C

Adresse des Internet-Routers 

 

192.168.116.4
 

192.168.13.5

Tunnelname 

 

ip.tun0
 

ip.tun0

In den Verfahren werden die folgenden IPv6-Adressen verwendet. Die Tunnelnamen sind dieselben.

Parameter 

Europe 

California 

System-Intranet-Adresse 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

System-Internet-Adresse 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Adresse des Internet-Routers 

 

2001::aaaa:0:4
 

2001::eeee:0:1

ProcedureSo schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4

Im Tunnelmodus bestimmt das innere IP-Paket die IPsec-Richtlinie, die dessen Inhalte schützt.

Dieses Verfahren ergänzt das unter So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec beschriebene Verfahren. Dieses Setup wird unter Beschreibung der Netzwerktopologie für IPsec-Aufgaben zum Schützen eines VPN beschrieben.

Hinweis –

Führen Sie die Schritte dieses Verfahrens auf beiden Systemen aus.

Sie verbinden nicht nur zwei Systeme, sondern zwei Intranets, die mit diesen zwei Systemen verbunden sind. Die Systeme in diesem Verfahren arbeiten als Gateways.

Bevor Sie beginnen

Sie müssen sich in der globalen Zone befinden, um die IPsec-Richtlinie für das System oder für eine gemeinsame IP-Zone zu konfigurieren. Für eine exklusive IP-Zone konfigurieren Sie die IPsec-Richtlinie in der nicht-globalen Zone.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere Remoteanmeldung.

  2. Kontrollieren Sie den Paketfluss vor der Konfiguration von IPsec.

    1. Stellen Sie sicher, dass IP-Weiterleitung und dynamisches IP-Routing deaktiviert sind.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      Wenn IP-Weiterleitung und dynamisches IP-Routing aktiviert sind, können diese Funktionen wie folgt deaktiviert werden:


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

      Durch Deaktivieren der IP-Weiterleitung wird verhindert, dass Pakete über dieses System von einem Netzwerk zu einem anderen weitergeleitet werden. Eine Beschreibung des Befehls routeadm finden Sie in der Manpage routeadm(1M).

    2. Aktivieren Sie das IP Strict Destination Multihoming.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      Durch Aktivieren von IP Strict Destination Multihoming wird sichergestellt, dass Pakete für eine der Zieladressen auf dem System bei der richtigen Zieladresse eintreffen.

      Wenn das Strict Destination Multihoming aktiviert ist, müssen Pakete, die an einer bestimmten Schnittstelle eintreffen, an eine der lokalen IP-Adressen dieser Schnittstelle adressiert sein. Alle anderen Pakete, auch solche, die an andere lokale Adressen des Systems adressiert sind, werden abgeworfen.

      Achtung – Achtung –

      Der Multihoming-Wert wird beim Booten des Systems auf den Standardwert zurückgesetzt. Informationen zum dauerhaften Ändern des Wertes finden Sie unter So verhindern Sie IP-Spoofing.

    3. Deaktivieren Sie die meisten Netzwerkservices – wenn möglich, alle Netzwerkservices.

      Hinweis –

      Wenn Ihr System mit dem SMF-Profil „limited“ installiert wurde, können Sie diesen Schritt überspringen. Netzwerkservices, mit Ausnahme der Solaris Secure Shell, sind deaktiviert.

      Durch Deaktivieren der Netzwerkservices wird verhindert, das IP-Pakete Schaden an einem System anrichten können. Beispielsweise könnten ein SNMP-Daemon, eine telnet-Verbindung oder eine rlogin-Verbindung ausgenutzt werden.

      Wählen Sie eine der folgenden Optionen:

      • Wenn Sie das Solaris 10 11/06-Release oder eine aktuellere Version ausführen, rufen Sie das SMF-Profil „limited“ auf.


        # netservices limited

      • Alternativ können Sie die Netzwerkservices einzeln deaktivieren.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

    4. Stellen Sie sicher, dass die meisten Netzwerk-Services deaktiviert sind.

      Stellen Sie sicher, dass die Loopback-Mounts und der ssh-Service ausgeführt werden.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Fügen Sie zwischen den beiden Systemen zwei SAs hinzu.

    Wählen Sie eine der folgenden Optionen:

  4. Fügen Sie eine IPsec-Richtlinie hinzu.

    Geben Sie die IPsec-Richtlinie für das VPN in die Datei /etc/inet/ipsecinit.conf ein. Informationen zur Verstärkung der Richtlinie finden Sie in Beispiel 20–12. Zusätzliche Beispiele finden Sie unter Beispiele für den Schutz eines VPN mit IPsec mithilfe von Tunneln im Tunnelmodus.

    Bei dieser Richtlinie ist der IPsec-Schutz zwischen Systemen im lokalen LAN und mit der internen IP-Adresse des Gateway nicht erforderlich, daher wird eine bypass-Anweisung hinzugefügt.

    1. Auf dem enigma-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. Auf dem partym-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Optional) Überprüfen Sie die Syntax der IPsec-Richtliniendatei.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Um den Tunnel zu konfigurieren und ihn mit IPsec zu schützen, folgen Sie den Schritten für die jeweilige Solaris-Version:

  7. Konfigurieren Sie den Tunnel, ip.tun0, in der Datei /etc/hostname.ip.tun0.

    Für die Datei gilt folgende Syntax:


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Um den Inhalt der Tunnelkonfigurationsdatei in den Systemkern einzulesen, starten Sie die Netzwerk-Services neu.


    # svcadm restart svc:/network/initial:default

  10. Aktivieren Sie die IP-Weiterleitung für die hme1-Schnittstelle.

    1. Fügen Sie auf dem System enigma den Routereintrag in die /etc/hostname.hme1-Datei ein.


      192.168.116.16 router

    2. Fügen Sie auf dem System partym den Routereintrag in die /etc/hostname.hme1-Datei ein:


      192.168.13.213 router

    IP-Weiterleitung bedeutet, dass alle Pakete, unabhängig vom Absender weitergeleitet werden. Darüber hinaus bedeutet IP-Weiterleitung, dass Pakete, die diese Schnittstelle verlassen, möglicherweise von einem anderen Absender stammen. Um ein Paket erfolgreich weiterzuleiten, müssen sowohl die empfangende als auch die übertragende Schnittstelle die IP-Weiterleitung aktiviert haben.

    Da die Schnittstelle hme1 innerhalb des Intranets liegt, muss die IP-Weiterleitung für hme1 aktiviert sein. Da ip.tun0 die zwei Systeme über das Internet miteinander verbindet, muss die IP-Weiterleitung für ip.tun0 aktiviert sein.

    Jedoch wurde die IP-Weiterleitung für die Schnittstelle hme0 deaktiviert, um zu verhindern, dass ein Angreifer von außen Pakete in das geschützte Intranet einleitet. außen bezieht sich in diesem Fall auf das Internet.

  11. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.

    1. Fügen Sie auf dem System enigma die private-Flag in die /etc/hostname.hme0-Datei ein.


      10.16.16.6 private

    2. Fügen Sie auf dem System partym die private-Flag in die /etc/hostname.hme0-Datei ein.


      10.1.3.3 private

    Auch wenn die IP-Weiterleitung für die Schnittstelle hme0 deaktiviert wurde, kann eine Routing-Protokoll-Implementierung die Schnittstelle noch immer bekannt geben. Beispielsweise könnte das in.routed-Protokoll bekannt geben, dass hme0 in der Lage ist, Pakete an ihre Peers im Intranet weiterzuleiten. Durch Einstellen des Schnittstellen-Flags private werden diese Advertisement-Nachrichten verhindert.

  12. Fügen Sie manuell eine Standardroute über die hme0-Schnittstelle hinzu.

    Die Standardroute muss ein Router mit direktem Zugriff auf das Internet sein.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add default 192.168.116.4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add default 192.168.13.5

      Auch wenn die Schnittstelle hme0 nicht zum Intranet gehört, muss hme0 über das Internet auf ihr Peer-System zugreifen können. Um ihren Peer zu finden, benötigt die Schnittstelle hme0 Informationen zum Internet-Routing. Das VPN-System erscheint dem restlichen Internet gegenüber als Host und nicht als Router. Aus diesem Grund können Sie einen Standard-Router verwenden, um das Router-Erkennungsprotokoll zum Finden eines Peer-Systems auszuführen. Weitere Informationen entnehmen Sie bitte den Manpages route(1M) and in.routed(1M).

  13. Zum Schluss wechseln Sie zu Schritt 22, um ein Routingprotokoll auszuführen.

  14. Konfigurieren Sie den Tunnel ip.tun0.

    Hinweis –

    Durch die folgenden Schritte wird ein Tunnel auf einem System konfiguriert, auf dem eine ältere Version als Solaris 10 4/09 ausgeführt wird.

    Verwenden Sie ifconfig-Befehle, um eine Point-to-Point-Schnittstelle zu erzeugen:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. Auf dem System enigma geben Sie die folgenden Befehle ein:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. Auf dem System partym geben Sie die folgenden Befehle ein:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # ipsecconf

  16. Aktivieren Sie den Router für den Tunnel.


    # ifconfig ip.tun0 router up

  17. Aktivieren Sie die IP-Weiterleitung für die Schnittstelle hme1.


    # ifconfig hme1 router

    IP-Weiterleitung bedeutet, dass alle Pakete, unabhängig vom Absender weitergeleitet werden. Darüber hinaus bedeutet IP-Weiterleitung, dass Pakete, die diese Schnittstelle verlassen, möglicherweise von einem anderen Absender stammen. Um ein Paket erfolgreich weiterzuleiten, müssen sowohl die empfangende als auch die übertragende Schnittstelle die IP-Weiterleitung aktiviert haben.

    Da die Schnittstelle hme1 innerhalb des Intranets liegt, muss die IP-Weiterleitung für hme1 aktiviert sein. Da ip.tun0 die zwei Systeme über das Internet miteinander verbindet, muss die IP-Weiterleitung für ip.tun0 aktiviert sein.

    Jedoch wurde die IP-Weiterleitung für die Schnittstelle hme0 deaktiviert, um zu verhindern, dass ein Angreifer von außen Pakete in das geschützte Intranet einleitet. außen bezieht sich in diesem Fall auf das Internet.

  18. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.


    # ifconfig hme0 private

    Auch wenn die IP-Weiterleitung für die Schnittstelle hme0 deaktiviert wurde, kann eine Routing-Protokoll-Implementierung die Schnittstelle noch immer bekannt geben. Beispielsweise könnte das in.routed-Protokoll bekannt geben, dass hme0 in der Lage ist, Pakete an ihre Peers im Intranet weiterzuleiten. Durch Einstellen des Schnittstellen-Flags private werden diese Advertisement-Nachrichten verhindert.

  19. Fügen Sie manuell eine Standardroute über hme0 hinzu.

    Die Standardroute muss ein Router mit direktem Zugriff auf das Internet sein.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add default 192.168.116.4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add default 192.168.13.5

      Auch wenn die Schnittstelle hme0 nicht zum Intranet gehört, muss hme0 über das Internet auf ihr Peer-System zugreifen können. Um ihren Peer zu finden, benötigt die Schnittstelle hme0 Informationen zum Internet-Routing. Das VPN-System erscheint dem restlichen Internet gegenüber als Host und nicht als Router. Aus diesem Grund können Sie einen Standard-Router verwenden, um das Router-Erkennungsprotokoll zum Finden eines Peer-Systems auszuführen. Weitere Informationen entnehmen Sie bitte den Manpages route(1M) and in.routed(1M).

  20. Stellen Sie sicher, dass das VPN nach einem erneuten Booten gestartet wird. Dazu fügen Sie einen Eintrag in die /etc/hostname.ip.tun0-Datei ein.


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  21. Konfigurieren Sie die Schnittstellendateien so, dass die korrekten Parameter an den Routing-Daemon übergeben werden.

    1. Ändern Sie auf dem System enigma die /etc/hostname. Schnittstelle-Dateien.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. Ändern Sie auf dem System partym die /etc/hostname. Schnittstelle-Dateien.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Führen Sie ein Routingprotokoll aus.


    # routeadm -e ipv4-routing
# routeadm -u

    Eventuell müssen Sie das Routing-Protokoll konfigurieren, bevor Sie es ausführen können. Weitere Informationen finden Sie unter Routing-Protokolle in Oracle Solaris. Anweisungen finden Sie unter So konfigurieren Sie einen IPv4-Router.

Beispiel 20–10 Erstellen temporärer Tunnels beim Testen

In diesem Beispiel testet der Administrator die Tunnelerstellung auf einem Solaris 10 4/09-System. Später verwendet der Administrator das unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4 Verfahren zur dauerhaften Einrichtung der Tunnel. Während des Testens führt der Administrator eine Reihe von Schritten auf den Systemen system1 und system 2 aus.

Beispiel 20–11 Erstellen eines Tunnels für eine frühere Version eines Solaris-Systems mithilfe der Befehlszeile

In Solaris 10 7/07 wurde die Syntax des ifconfig-Befehls vereinfacht. In diesem Beispiel testet der Administrator die Tunnelerstellung auf einem System, auf dem eine ältere Version als Solaris 10 7/07 ausgeführt wird. Mithilfe der ursprünglichen Syntax des ifconfig-Befehls kann der Administrator identische Befehle auf den beiden kommunizierenden Systemen verwenden. Später wandelt der Administrator die Tunnel nach der unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4 erläuterten Verfahrensweise in dauerhafte Tunnel um.

Während des Testens führt der Administrator folgende Schritte auf den Systemen system1 und system 2 aus.

Beispiel 20–12 Erfordern einer IPsec-Richtlinie auf allen Systemen in einem LAN

In diesem Beispiel wandelt der Administrator die bypass-Richtlinie, die in Schritt 4 konfiguriert wurde, in einen Kommentar um und verstärkt somit den Schutz. Bei dieser Richtlinienkonfiguration muss jedes System im LAN IPsec aktivieren, um mit dem Router kommunizieren zu können.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}
Beispiel 20–13 Verwenden von IPsec, um Telnet-Verkehr anders als SMTP-Verkehr zu schützen

In diesem Beispiel schützt die erste Regel den telnet-Datenverkehr an·Port 23 mit Blowfish und SHA-1. Die zweite Regel schützt den SMTP-Datenverkehr an Port 25 mit AES und MD5.


{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}
Beispiel 20–14 Verwenden eines IPsec-Tunnels im Tunnelmode, um den Teilnetz-Verkehr anders als den restlichen Netzwerkverkehr zu schützen

Die folgende Tunnelkonfiguration schützt den gesamten Verkehr aus dem Teilnetz 10.1.3.0/24 über den Tunnel:


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Die folgende Tunnelkonfiguration schützt Verkehr aus dem Teilnetz 10.1.3.0/24 an andere Teilnetze über den Tunnel. Teilnetze, die mit 10.2.x.x beginnen, befinden sich hinter dem Tunnel.


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

ProcedureSo schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv6

Zum Einrichten eines VPN in einem IPv6-Netzwerk führen Sie die gleichen Schritte wie für ein IPv4-Netzwerk aus. Lediglich die Syntax der Befehle ist etwas anders. Eine vollständige Beschreibung der Gründe für bestimmte Befehle finden Sie unter den entsprechenden Schritten der Beschreibung unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4.

Hinweis –

Führen Sie die Schritte dieses Verfahrens auf beiden Systemen aus.

In diesem Verfahren werden die folgenden Konfigurationsparameter verwendet.

Parameter 

Europe 

California 

Systemname 

 

enigma
 

partym

System-Intranet-Schnittstelle 

 

hme1
 

hme1

System-Internet-Schnittstelle 

 

hme0
 

hme0

System-Intranet-Adresse 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

System-Internet-Adresse 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Name des Internet-Routers 

 

router-E
 

router-C

Adresse des Internet-Routers 

 

2001::aaaa:0:4
 

2001::eeee:0:1

Tunnelname 

 

ip6.tun0
 

ip6.tun0

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere Remoteanmeldung.

  2. Kontrollieren Sie den Paketfluss vor der Konfiguration von IPsec.

    Informationen zu den Auswirkungen dieser Befehle finden Sie unter Schritt 2 in So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4.

    1. Stellen Sie sicher, dass IP-Weiterleitung und dynamisches IP-Routing deaktiviert sind.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      Wenn IP-Weiterleitung und dynamisches IP-Routing aktiviert sind, können diese Funktionen wie folgt deaktiviert werden:


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. Aktivieren Sie das IP Strict Destination Multihoming.


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Achtung – Achtung –

      ip_strict_dst_multihoming wird beim Booten des Systems auf den Standardwert zurückgesetzt. Informationen zum dauerhaften Ändern des Wertes finden Sie unter So verhindern Sie IP-Spoofing.

    3. Deaktivieren Sie die meisten Netzwerkservices – wenn möglich, alle Netzwerkservices.

      Hinweis –

      Wenn Ihr System mit dem SMF-Profil „limited“ installiert wurde, können Sie diesen Schritt überspringen. Netzwerkservices, mit Ausnahme der Solaris Secure Shell, sind deaktiviert.

      Durch Deaktivieren der Netzwerkservices wird verhindert, das IP-Pakete Schaden an einem System anrichten können. Beispielsweise könnten ein SNMP-Daemon, eine telnet-Verbindung oder eine rlogin-Verbindung ausgenutzt werden.

      Wählen Sie eine der folgenden Optionen:

      • Wenn Sie das Solaris 10 11/06-Release oder eine aktuellere Version ausführen, rufen Sie das SMF-Profil „limited“ auf.


        # netservices limited

      • Alternativ können Sie die Netzwerkservices einzeln deaktivieren.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. Stellen Sie sicher, dass die meisten Netzwerk-Services deaktiviert sind.

      Stellen Sie sicher, dass die Loopback-Mounts und der ssh-Service ausgeführt werden.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
...
online         Aug_09   svc:/network/ssh:default

  3. Fügen Sie zwischen den beiden Systemen zwei SAs hinzu.

    Wählen Sie eine der folgenden Optionen:

  4. Fügen Sie eine IPsec-Richtlinie für das VPN hinzu.

    Geben Sie die IPsec-Richtlinie für das VPN in die Datei /etc/inet/ipsecinit.conf ein.

    1. Auf dem enigma-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. Auf dem partym-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Optional) Überprüfen Sie die Syntax der IPsec-Richtliniendatei.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Um den Tunnel zu konfigurieren und ihn mit IPsec zu schützen, folgen Sie den Schritten für die jeweilige Solaris-Version:

  7. Konfigurieren Sie den Tunnel ip6.tun0 in der /etc/hostname.ip6.tun0-Datei.

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname6.ip6.tun0-Datei ein:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname.ip6.tun0-Datei ein.


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Um den Inhalt der Tunnelkonfigurationsdatei in den Systemkern einzulesen, starten Sie die Netzwerk-Services neu.


    # svcadm restart svc:/network/initial:default

  10. Aktivieren Sie die IP-Weiterleitung für die Schnittstelle hme1.

    1. Fügen Sie auf dem System enigma den Routereintrag in die /etc/hostname6.hme1-Datei ein.


      2001::aaaa:6666:6666 inet6 router

    2. Fügen Sie auf dem System partym den Routereintrag in die /etc/hostname6.hme1-Datei ein.


      2001::eeee:3333:3333 inet6 router

  11. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.

    1. Fügen Sie auf dem System enigma die private-Flag in die /etc/hostname6.hme0-Datei ein.


      6000:6666::aaaa:1116 inet6 private

    2. Fügen Sie auf dem System partym die private-Flag in die /etc/hostname6.hme0-Datei ein.


      6000:3333::eeee:1113 inet6 private

  12. Fügen Sie manuell eine Standardroute über hme0 hinzu.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add -inet6 default 2001::aaaa:0:4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add -inet6 default 2001::eeee:0:1

  13. Zum Schluss wechseln Sie zu Schritt 22, um ein Routingprotokoll auszuführen.

  14. Konfigurieren Sie den sicheren Tunnel ip6.tun0.

    Hinweis –

    Durch die folgenden Schritte wird ein Tunnel auf einem System konfiguriert, auf dem eine ältere Version als Solaris 10 4/09 ausgeführt wird.

    1. Auf dem System enigma geben Sie die folgenden Befehle ein:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. Auf dem System partym geben Sie die folgenden Befehle ein:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # ipsecconf

  16. Aktivieren Sie den Router für den Tunnel.


    # ifconfig ip6.tun0 router up

  17. Aktivieren Sie auf jedem System die IP-Weiterleitung für die Schnittstelle hme1. 


    # ifconfig hme1 router

  18. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.


    # ifconfig hme0 private

  19. Fügen Sie manuell eine Standardroute über hme0 hinzu.

    Die Standardroute muss ein Router mit direktem Zugriff auf das Internet sein.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add -inet6 default 2001::aaaa:0:4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add -inet6 default 2001::eeee:0:1

  20. Stellen Sie sicher, dass das VPN nach einem erneuten Booten gestartet wird. Dazu fügen Sie einen Eintrag in die /etc/hostname6.ip6.tun0-Datei ein.

    Dieser Eintrag repliziert die Parameter, die in Schritt 14 an den Befehl ifconfig übergeben wurden.

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname6.ip6.tun0-Datei ein:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666  tdst 2001::eeee:3333:3333 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname6.ip6.tun0-Datei ein:


      6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. Konfigurieren Sie die Schnittstellendateien auf jedem System so, dass die korrekten Parameter an den Routing-Daemon übergeben werden.

    1. Ändern Sie auf dem System enigma die /etc/hostname6. Schnittstelle-Dateien.


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. Ändern Sie auf dem System partym die /etc/hostname6. Schnittstelle-Dateien.


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## partym
2001::eeee:3333:3333 inet6 router

  22. Führen Sie ein Routingprotokoll aus.


    # routeadm -e ipv6-routing
# routeadm -u

    Eventuell müssen Sie das Routing-Protokoll konfigurieren, bevor Sie es ausführen können. Weitere Informationen finden Sie unter Routing-Protokolle in Oracle Solaris. Anweisungen finden Sie unter Konfiguration eines IPv6-Routers.

ProcedureSo schützen Sie ein VPN mit einem IPsec-Tunnel im Transportmodus über IPv4

Im Transportmodus bestimmt der äußere Header die IPsec-Richtlinie, die das innere IP-Paket schützt.

Dieses Verfahren ergänzt das unter So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec beschriebene Verfahren. Sie verbinden nicht nur zwei Systeme, sondern zwei Intranets, die mit diesen zwei Systemen verbunden sind. Die Systeme in diesem Verfahren arbeiten als Gateways.

Dieses Verfahren verwendet das unter Beschreibung der Netzwerktopologie für IPsec-Aufgaben zum Schützen eines VPN beschriebene Setup. Eine vollständige Beschreibung der Gründe für bestimmte Befehle finden Sie unter den entsprechenden Schritten der Beschreibung unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4.

Hinweis –

Führen Sie die Schritte dieses Verfahrens auf beiden Systemen aus.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere Remoteanmeldung.

  2. Kontrollieren Sie den Paketfluss vor der Konfiguration von IPsec.

    1. Stellen Sie sicher, dass IP-Weiterleitung und dynamisches IP-Routing deaktiviert sind.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      Wenn IP-Weiterleitung und dynamisches IP-Routing aktiviert sind, können diese Funktionen wie folgt deaktiviert werden:


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

    2. Aktivieren Sie das IP Strict Destination Multihoming.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1
      Achtung – Achtung –

      ip_strict_dst_multihoming wird beim Booten des Systems auf den Standardwert zurückgesetzt. Informationen zum dauerhaften Ändern des Wertes finden Sie unter So verhindern Sie IP-Spoofing.

    3. Deaktivieren Sie die meisten Netzwerkservices – wenn möglich, alle Netzwerkservices.

      Hinweis –

      Wenn Ihr System mit dem SMF-Profil „limited“ installiert wurde, können Sie diesen Schritt überspringen. Netzwerkservices, mit Ausnahme der Solaris Secure Shell, sind deaktiviert.

      Durch Deaktivieren der Netzwerkservices wird verhindert, das IP-Pakete Schaden an einem System anrichten können. Beispielsweise könnten ein SNMP-Daemon, eine telnet-Verbindung oder eine rlogin-Verbindung ausgenutzt werden.

      Wählen Sie eine der folgenden Optionen:

      • Wenn Sie das Solaris 10 11/06-Release oder eine aktuellere Version ausführen, rufen Sie das SMF-Profil „limited“ auf.


        # netservices limited

      • Alternativ können Sie die Netzwerkservices einzeln deaktivieren.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. Stellen Sie sicher, dass die meisten Netzwerk-Services deaktiviert sind.

      Stellen Sie sicher, dass die Loopback-Mounts und der ssh-Service ausgeführt werden.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Fügen Sie zwischen den beiden Systemen zwei SAs hinzu.

    Wählen Sie eine der folgenden Optionen:

  4. Fügen Sie eine IPsec-Richtlinie hinzu.

    Geben Sie die IPsec-Richtlinie für das VPN in die Datei /etc/inet/ipsecinit.conf ein. Informationen zur Verstärkung der Richtlinie finden Sie in Beispiel 20–15.

    1. Auf dem System enigma geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. Auf dem partym-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Optional) Überprüfen Sie die Syntax der IPsec-Richtliniendatei.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Um den Tunnel zu konfigurieren und ihn mit IPsec zu schützen, folgen Sie den Schritten für die jeweilige Solaris-Version:

  7. Konfigurieren Sie den Tunnel ip.tun0 in der /etc/hostname.ip.tun0-Datei.

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Um den Inhalt der hostname.ip.tun0-Datei in den Systemkern zu lesen, starten Sie die Netzwerk-Services neu.


    # svcadm restart svc:/network/initial:default

  10. Aktivieren Sie die IP-Weiterleitung für die hme1-Schnittstelle.

    1. Fügen Sie auf dem System enigma den Routereintrag in /etc/hostname ein.hme1-Datei.


      192.168.116.16 router

    2. Fügen Sie auf dem System partym den Routereintrag in /etc/hostname ein.hme1-Datei.


      192.168.13.213 router

  11. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.

    1. Fügen Sie auf dem System enigma das private-Flag in /etc/hostname ein.hme0-Datei.


      10.16.16.6 private

    2. Fügen Sie auf dem System partym das private-Flag in /etc/hostname ein.hme0-Datei.


      10.1.3.3 private

  12. Fügen Sie manuell eine Standardroute über hme0 hinzu.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add default 192.168.116.4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add default 192.168.13.5

  13. Zum Schluss wechseln Sie zu Schritt 22, um ein Routingprotokoll auszuführen.

  14. Konfigurieren Sie den Tunnel ip.tun0.

    Hinweis –

    Durch die folgenden Schritte wird ein Tunnel auf einem System konfiguriert, auf dem eine ältere Version als Solaris 10 4/09 ausgeführt wird.

    Verwenden Sie ifconfig-Befehle, um eine Point-to-Point-Schnittstelle zu erzeugen:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. Auf dem System enigma geben Sie die folgenden Befehle ein:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. Auf dem System partym geben Sie die folgenden Befehle ein:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # ipsecconf

  16. Aktivieren Sie den Router für den Tunnel.


    # ifconfig ip.tun0 router up

  17. Aktivieren Sie die IP-Weiterleitung für die Schnittstelle hme1.


    # ifconfig hme1 router

  18. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.


    # ifconfig hme0 private

  19. Fügen Sie manuell eine Standardroute über hme0 hinzu.

    Die Standardroute muss ein Router mit direktem Zugriff auf das Internet sein.


    # route add default router-on-hme0-subnet

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add default 192.168.116.4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add default 192.168.13.5

  20. Stellen Sie sicher, dass das VPN nach einem erneuten Booten gestartet wird. Dazu fügen Sie einen Eintrag in die /etc/hostname.ip.tun0-Datei ein.


    system1-point system2-point tsrc system1-taddr \
tdst system2-taddr encr_algs aes encr_auth_algs sha1 router up

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname.ip.tun0-Datei ein:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \
tdst 192.168.116.16 router up

  21. Konfigurieren Sie die Schnittstellendateien so, dass die korrekten Parameter an den Routing-Daemon übergeben werden.

    1. Ändern Sie auf dem System enigma die /etc/hostname. Schnittstelle-Dateien.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. Ändern Sie auf dem System partym die /etc/hostname. Schnittstelle-Dateien.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Führen Sie ein Routingprotokoll aus.


    # routeadm -e ipv4-routing
# routeadm -u
Beispiel 20–15 Erfordern einer IPsec-Richtlinie auf allen Systemen im Transportmodus

IPsec-RichtlinieLAN-BeispielIn diesem Beispiel wandelt der Administrator die bypass-Richtlinie, die in Schritt 4 konfiguriert wurde, in einen Kommentar um und verstärkt somit den Schutz. Bei dieser Richtlinienkonfiguration muss jedes System im LAN IPsec aktivieren, um mit dem Router kommunizieren zu können.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}
Beispiel 20–16 Verwenden einer eingestellten Syntax zur Konfiguration eines IPsec-Tunnels im Transportmodus

In diesem Beispiel stellt der Administrator eine Verbindung zwischen einem Solaris 10 7/07-System und einem System her, das das Solaris 10-Release ausführt. Aus diesem Grund verwendet der Administrator die Solaris 10-Syntax in der Konfigurationsdatei und nimmt die IPsec-Algorithmen in den Befehl ifconfig auf.

Der Administrator verwendet das Verfahren So schützen Sie ein VPN mit einem IPsec-Tunnel im Transportmodus über IPv4 mit den folgenden Syntaxänderungen.

ProcedureSo schützen Sie ein VPN mit einem IPsec-Tunnel im Transportmodus über IPv6

Zum Einrichten eines VPN in einem IPv6-Netzwerk führen Sie die gleichen Schritte wie für ein IPv4-Netzwerk aus. Lediglich die Syntax der Befehle ist etwas anders. Eine vollständige Beschreibung der Gründe für bestimmte Befehle finden Sie unter den entsprechenden Schritten der Beschreibung unter So schützen Sie ein VPN mit einem IPsec-Tunnel im Tunnelmodus über IPv4.

Hinweis –

Führen Sie die Schritte dieses Verfahrens auf beiden Systemen aus.

In diesem Verfahren werden die folgenden Konfigurationsparameter verwendet.

Parameter 

Europe 

California 

Systemname 

 

enigma
 

partym

System-Intranet-Schnittstelle 

 

hme1
 

hme1

System-Internet-Schnittstelle 

 

hme0
 

hme0

System-Intranet-Adresse 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

System-Internet-Adresse 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Name des Internet-Routers 

 

router-E
 

router-C

Adresse des Internet-Routers 

 

2001::aaaa:0:4
 

2001::eeee:0:1

Tunnelname 

 

ip6.tun0
 

ip6.tun0

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere Remoteanmeldung.

  2. Kontrollieren Sie den Paketfluss vor der Konfiguration von IPsec.

    1. Stellen Sie sicher, dass IP-Weiterleitung und dynamisches IP-Routing deaktiviert sind.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      Wenn IP-Weiterleitung und dynamisches IP-Routing aktiviert sind, können diese Funktionen wie folgt deaktiviert werden:


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. Aktivieren Sie das IP Strict Destination Multihoming.


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Achtung – Achtung –

      ip_strict_dst_multihoming wird beim Booten des Systems auf den Standardwert zurückgesetzt. Informationen zum dauerhaften Ändern des Wertes finden Sie unter So verhindern Sie IP-Spoofing.

    3. Stellen Sie sicher, dass die meisten Netzwerk-Services deaktiviert sind.

      Stellen Sie sicher, dass die Loopback-Mounts und der ssh-Service ausgeführt werden.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Fügen Sie zwischen den beiden Systemen zwei SAs hinzu.

    Wählen Sie eine der folgenden Optionen:

  4. Fügen Sie eine IPsec-Richtlinie hinzu.

    Geben Sie die IPsec-Richtlinie für das VPN in die Datei /etc/inet/ipsecinit.conf ein.

    1. Auf dem enigma-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

    2. Auf dem partym-System geben Sie den folgenden Eintrag in die ipsecinit.conf-Datei ein:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

  5. (Optional) Überprüfen Sie die Syntax der IPsec-Richtliniendatei.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Um den Tunnel zu konfigurieren und ihn mit IPsec zu schützen, folgen Sie den Schritten für die jeweilige Solaris-Version:

  7. Konfigurieren Sie den Tunnel ip6.tun0 in der /etc/hostname.ip6.tun0-Datei.

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname6.ip6.tun0-Datei ein:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname.ip6.tun0-Datei ein.


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Um den Inhalt der hostname.ip6.tun0-Datei in den Systemkern zu lesen, starten Sie die Netzwerk-Services neu.


    # svcadm restart svc:/network/initial:default

  10. Aktivieren Sie die IP-Weiterleitung für die Schnittstelle hme1.

    1. Fügen Sie auf dem System enigma den Routereintrag in die /etc/hostname6.hme1-Datei ein.


      2001::aaaa:6666:6666 inet6 router

    2. Fügen Sie auf dem System partym den Routereintrag in die /etc/hostname6.hme1-Datei ein.


      2001::eeee:3333:3333 inet6 router

  11. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.

    1. Fügen Sie auf dem System enigma die private-Flag in die /etc/hostname6.hme0-Datei ein.


      6000:6666::aaaa:1116 inet6 private

    2. Fügen Sie auf dem System partym die private-Flag in die /etc/hostname6.hme0-Datei ein.


      6000:3333::eeee:1113 inet6 private

  12. Fügen Sie manuell eine Standardroute über hme0 hinzu.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add -inet6 default 2001::aaaa:0:4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add -inet6 default 2001::eeee:0:1

  13. Zum Schluss wechseln Sie zu Schritt 22, um ein Routingprotokoll auszuführen.

  14. Konfigurieren Sie den sicheren Tunnel ip6.tun0.

    Hinweis –

    Durch die folgenden Schritte wird ein Tunnel auf einem System konfiguriert, auf dem eine ältere Version als Solaris 10 4/09 ausgeführt wird.

    1. Auf dem System enigma geben Sie die folgenden Befehle ein:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. Auf dem System partym geben Sie die folgenden Befehle ein:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6  6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. Schützen Sie den Tunnel mit der von Ihnen erstellten IPsec-Richtlinie.


    # ipsecconf

  16. Aktivieren Sie den Router für den Tunnel.


    # ifconfig ip6.tun0 router up

  17. Aktivieren Sie die IP-Weiterleitung für die Schnittstelle hme1. 


    # ifconfig hme1 router

  18. Stellen Sie sicher, dass die Routing-Protokolle die Standardroute nicht innerhalb des Intranets bekannt geben.


    # ifconfig hme0 private

  19. Fügen Sie auf jedem System manuell eine Standardroute über hme0 hinzu.

    Die Standardroute muss ein Router mit direktem Zugriff auf das Internet sein.

    1. Auf dem System enigma können Sie die folgende Route hinzufügen:


      # route add -inet6 default 2001::aaaa:0:4

    2. Auf dem System partym fügen Sie die folgende Route hinzu:


      # route add -inet6 default 2001::eeee:0:1

  20. Stellen Sie auf jedem System sicher, dass das VPN nach einem erneuten Booten gestartet wird. Dazu fügen Sie einen Eintrag in die /etc/hostname6.ip6.tun0-Datei ein.

    Dieser Eintrag repliziert die Parameter, die in Schritt 14 an den Befehl Schritt 14 übergeben wurden.

    1. Fügen Sie auf dem System enigma den folgenden Eintrag in die hostname6.ip6.tun0-Datei ein:


      6000:6666::aaaa:1116  6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333  router up

    2. Fügen Sie auf dem System partym den folgenden Eintrag in die hostname6.ip6.tun0-Datei ein:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. Konfigurieren Sie die Schnittstellendateien so, dass die korrekten Parameter an den Routing-Daemon übergeben werden.

    1. Ändern Sie auf dem System enigma die /etc/hostname6. Schnittstelle-Dateien.


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. Ändern Sie auf dem System partym die /etc/hostname6. Schnittstelle-Dateien.


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## 
partym2001::eeee:3333:3333 inet6 router

  22. Führen Sie ein Routingprotokoll aus.


    # routeadm -e ipv6-routing
# routeadm -u
Beispiel 20–17 Verwenden einer eingestellten Syntax zur Konfiguration von IPsec im Transportmodus über IPv6

In diesem Beispiel stellt der Administrator eine Verbindung zwischen einem Solaris 10 7/07-System und einem System her, das das Solaris 10-Release ausführt. Aus diesem Grund verwendet der Administrator die Solaris 10-Syntax in der Konfigurationsdatei und nimmt die IPsec-Algorithmen in den Befehl ifconfig auf.

Der Administrator verwendet das Verfahren So schützen Sie ein VPN mit einem IPsec-Tunnel im Transportmodus über IPv6 mit den folgenden Syntaxänderungen.

ProcedureSo verhindern Sie IP-Spoofing

Um IP-Spoofing auszuschließen, muss das System daran gehindert werden, Pakete ohne Entschlüsselung an eine andere Schnittstelle weiterzuleiten. Eine Methode ist das Festlegen der strengen IP-Ziel-Multihoming-Parameter mithilfe des Befehls ndd. Wird dieser Parameter in einem SMF-Manifest festgelegt, wird er beim erneuten Booten des Systems eingestellt.

Hinweis –

Führen Sie die Schritte dieses Verfahrens auf beiden Systemen aus.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Erstellen Sie das standortspezifische SMF-Manifest zur Verhinderung von IP-Spoofing.

    Verwenden Sie das Beispielskript /var/svc/manifest/site/spoof_check.xml.

    <?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='Custom:ip_spoof_checking'>

<!--    This is a custom smf(5) manifest for this system. Place this
        file in /var/svc/manifest/site, the directory for local
        system customizations. The exec method uses an unstable
        interface to provide a degree of protection against IP
        spoofing attacks when this system is acting as a router.

        IP spoof protection can also be achieved by using ipfilter(5).
        If ipfilter is configured, this service can be disabled.

        Note: Unstable interfaces might be removed in later
        releases.  See attributes(5).
-->

<service
        name='site/ip_spoofcheck'
        type='service'
        version='1'>

        <create_default_instance enabled='false' />
        <single_instance />

        <!--    Don't enable spoof protection until the
                network is up.
        -->
        <dependency
                name='basic_network'
                grouping='require_all'
                restart_on='none'
                type='service'>
        <service_fmri value='svc:/milestone/network' />
        </dependency>

        <exec_method
                type='method'
                name='start'
                exec='/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1'
<!--    
     For an IPv6 network, use the IPv6 version of this command, as in:
                exec='/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1
-->
                timeout_seconds='60'
        />

        <exec_method
                type='method'
                name='stop'
                exec=':true'
                timeout_seconds='3'
        />

        <property_group name='startd' type='framework'>
                <propval
                        name='duration'
                        type='astring'
                        value='transient'
                />
        </property_group>

        <stability value='Unstable' />

</service>
</service_bundle>

  3. Importieren Sie dieses Manifest in das SMF-Repository.


    # svccfg import /var/svc/manifest/site/spoof_check.xml

  4. Aktivieren Sie den ip_spoofcheck-Service.

    Verwenden Sie den Namen, der im Manifest /site/ip_spoofcheck definiert wird.


    # svcadm enable /site/ip_spoofcheck

  5. Stellen Sie sicher, dass der ip_spoofcheck-Service online ist.


    # svcs /site/ip_spoofcheck

Kapitel 21 IP Security Architecture (Referenz)

Dieses Kapitel enthält die folgenden Referenzinformationen:

Anweisungen zur Implementierung von IPsec in Ihrem Netzwerk finden Sie in Kapitel 20Konfiguration von IPsec (Aufgaben). Eine Übersicht zu IPsec finden Sie in Kapitel 19IP Security Architecture (Übersicht).

IPsec Service Management Facility

Die Service Management Facility (SMF) stellt IPsec die folgenden Services zur Verfügung:

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

ipsecconf-Befehl

Mit dem ipsecconf-Befehl wird die IPsec-Richtlinie für einen Host konfiguriert. Wenn Sie diesen Befehl zur Konfiguration der Richtlinie ausführen, erstellt das System IPsec-Richtlinieneinträge im Kernel. Das System verwendet diese Einträge, um die Richtlinie an allen eingehenden und abgehenden IP-Datagrammen zu prüfen. Weitergeleitete Datagramme sind jedoch von den Richtlinienprüfungen, ausgenommen, die mit diesem Befehl hinzugefügt werden. Mit dem Befehl ipsecconf wird auch die Security Policy Database (SPD) konfiguriert.

Zum Aufrufen des ipsecconf-Befehls müssen Sie sich als Superuser anmelden oder eine entsprechende Rolle annehmen. Der Befehl akzeptiert Einträge, die den Datenverkehr in beide Richtungen schützen, und Einträge, die den Datenverkehr nur in eine Richtung schützen.

Richtlinieneinträge im Format lokale Adresse und remote Adresse können den Datenverkehr mit nur einem Richtlinieneintrag in beiden Richtungen schützen. Beispielsweise schützen Einträge nach dem Muster ladr host1 und radr host2 Datenverkehr in beiden Richtungen, wenn keine Richtung für den benannten Host angegeben ist. Aus diesem Grund benötigen Sie für jeden Host nur einen Richtlinieneintrag.

Richtlinieneinträge im Format Quelladresse zu Zieladresse schützen Datenverkehr nur in eine Richtung. Beispielsweise schützt ein Richtlinieneintrag nach dem Muster qadr host1 zadr host2 entweder eingehenden Datenverkehr oder abgehenden Datenverkehr, aber keinen bidirektionalen Datenverkehr. Daher müssen Sie, um Datenverkehr in beide Richtungen zu schützen, den Befehl ipsecconf in einem weiteren Eintrag übergeben, z. B. qadr host2 zadr host1.

Um sicherzustellen, dass die IPsec-Richtlinie beim Booten des Computers aktiviert wird, können Sie eine IPsec-Richtliniendatei, /etc/inet/ipsecinit.conf, erstellen. Die Datei wird beim Starten der Netzwerkservices eingelesen. Anweisungen zum Erstellen einer IPsec-Richtliniendatei finden Sie unter Schützen des Datenverkehrs mit IPsec (Übersicht der Schritte).

Ab Solaris 10 4/09 kann mit der -c-Option beim ipsecconf-Befehl die Syntax der als Argument bereitgestellten IPsec-Richtliniendaten überprüft werden.

Richtlinieneinträge, die über den ipsecconf-Befehl hinzugefügt werden, bleiben nicht über einen erneuten Bootvorgang im System erhalten. Damit die IPsec-Richtlinie beim Booten des Systems aktiv ist, müssen die entsprechenden Einträge in die Datei /etc/inet/ipsecinit.conf eingefügt werden. Aktualisieren bzw. aktivieren Sie in der aktuellen Version den policy-Service. In einer älteren Version als Solaris 10 4/09 müssen Sie das System erneut booten oder den Befehl ipsecconf verwenden. Beispiele finden Sie unter Schützen des Datenverkehrs mit IPsec (Übersicht der Schritte).

ipsecinit.conf-Datei

Um die IPsec-Sicherheitsrichtlinien beim Starten des Solaris OS (Solaris OS) aufzurufen, erstellen Sie eine Konfigurationsdatei, um IPsec mit Ihren speziellen IPsec-Richtlinieneinträgen zu initialisieren. Der Standardname für diese Datei lautet /etc/inet/ipsecinit.conf. Ausführliche Informationen zu Richtlinieneinträgen und deren Format finden Sie in der Manpage ipsecconf(1M). Nachdem die Richtlinien konfiguriert sind, können Sie den Befehl ipsecconf aufrufen, um die bestehende Konfiguration anzuzeigen oder zu ändern. Ab Solaris 10 4/09 wird die vorhandene Konfiguration durch eine Aktualisierung des policy-Service geändert.

Beispiel einer ipsecinit.conf-Datei

Die Solaris-Software enthält ein Beispiel einer IPsec-Richtliniendatei, ipsecinit.sample. Sie können diese Datei als Vorlage verwenden, um Ihre eigene ipsecinit.conf-Datei zu erstellen. Die Datei ipsecinit.sample enthält die folgenden Beispiele:


#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#	 {lport 23 dir in} drop {}
#	 {lport 23 dir out} drop {}
# will disallow any remote system from telnetting in.
#
# If you are using IPv6, it may be useful to bypass neighbor discovery
# to allow in.iked to work properly with on-link neighbors. To do that,
# add the following lines:
#
#        {ulp ipv6-icmp type 133-137 dir both } pass { }
#
# This will allow neighbor discovery to work normally.

Sicherheitsbetrachtungen für ipsecinit.conf und ipsecconf

Seien Sie vorsichtig, wenn Sie eine Kopie der ipsecinit.conf-Datei über ein Netzwerk übertragen. Ein potentieller Angreifer kann eine über das Netzwerk eingehängte Datei lesen, wenn die Datei eingelesen wird. Angenommen, die Datei /etc/inet/ipsecinit.conf wird geöffnet oder von einem NFS eingehängten Dateisystem kopiert, kann ein potentieller Angreifer die in der Datei enthaltene Richtlinie ändern.

Stellen Sie sicher, dass Sie IPsec-Richtlinien einrichten, bevor Sie eine Kommunikation initiieren, da bestehende Verbindungen durch Hinzufügen von neuen Richtlinieneinträgen beeinflusst werden können. Entsprechend sollten Sie keine Richtlinien während der Kommunikation ändern.

Eine IPsec-Richtlinie kann insbesondere nicht für SCTP-, TCP- oder UDP-Sockets geändert werden, für die ein connect()- oder accept()-Funktionsaufruf ausgegeben wurde. Ein Socket, dessen Richtlinie nicht geändert werden kann, wird als gesperrtes Socket bezeichnet. Neue Richtlinieneinträge schützen keine Sockets, die bereits gesperrt sind. Weitere Informationen finden Sie in den Manpages connect(3SOCKET) und accept(3SOCKET).

Schützen Sie Ihr Benennungssystem. Wenn die folgenden beiden Bedingungen erfüllt sind, sind Ihre Hostnamen nicht mehr vertrauenswürdig:

Sicherheitsschwächen beruhen häufig auf dem Fehlverhalten von Tools, nicht von tatsächlichen Tools. Aus diesem Grund sollten Sie bei der Verwendung des ipsecconf-Befehls vorsichtig sein. Verwenden Sie eine Konsole oder ein anderes festverdrahtetes TTY für den sichersten Betriebsmodus.

ipsecalgs-Befehl

Das Solaris Cryptographic Framework bietet Authentifizierungs- und Verschlüsselungsalgorithmen für IPsec. Mit dem ipsecalgs -Befehl werden die Algorithmen aufgeführt, die von den einzelnen IPsec-Protokollen unterstützt werden. Die ipsecalgs-Konfiguration wird in der Datei /etc/inet/ipsecalgs gespeichert. Diese Datei muss in der Regel nicht geändert werden. Wenn Sie sie doch ändern müssen, verwenden Sie den ipsecalgs-Befehl. Diese Datei darf nicht direkt bearbeitet werden. In der aktuellen Version werden die unterstützten Algorithmen beim Booten des Systems mittels des svc:/network/ipsec/ipsecalgs:default-Service mit dem Systemkern synchronisiert.

Die gültigen IPsec-Protokolle und -Algorithmen werden von der ISAKMP-Domain of Interpretation (DOI) beschrieben, die in RFC 2407 behandelt wird. Im allgemeinen Sinn definiert eine DOI Datenformate, Netzverkehr-Austauscharten sowie Konventionen für das Benennen sicherheitsrelevanter Informationen. Bespiele für sicherheitsrelevante Informationen sind Sicherheitsrichtlinien, kryptografische Algorithmen und Kryptographiemodi.

Insbesondere definiert die ISAKMP DOI die Benennungs- und Nummerierungskonventionen für gültige IPsec-Algorithmen und deren Protokolle, PROTO_IPSEC_AH und PROTO_IPSEC_ESP. Jedem Algorithmus ist exakt ein Protokoll zugeordnet. Diese ISAKMP DOI-Definitionen sind in der /etc/inet/ipsecalgs-Datei enthalten. Der Algorithmus und die Protokollnummern werden von der Internet Assigned Numbers Authority (IANA) definiert. Mit dem Befehl ipsecalgs kann die Algorithmenliste für IPsec erweitert werden.

Weitere Informationen zu Algorithmen finden Sie in der Manpage ipsecalgs(1M) Weitere Informationen zum Solaris Cryptographic Framework finden Sie in Kapitel 13, Oracle Solaris Cryptographic Framework (Overview) in System Administration Guide: Security Services.

Sicherheitszuordnung-Datenbank für IPsec

Informationen zum Schlüsselmaterial für die IPsec-Sicherheitsservices werden in einer Sicherheitszuordnung-Datenbank (SADB) verwaltet. Sicherheitszuordnungen (SAs) schützen eingehende und abgehende Pakete. Die SADBs werden von einem Benutzerprozess, eventuell von mehreren kooperierenden Prozessen verwaltet, die Nachrichten über einen besonderen Socket senden. Diese Methode der SADBs-Verwaltung entspricht der in Manpage route(7P) beschriebenen Methode. Nur Superuser oder Benutzer, die eine entsprechende Rolle angenommen haben, können auf die Datenbank zugreifen.

Der in.iked-Daemon und der ipseckey-Befehl können die SADBs über die PF_KEY-Socket-Schnittstelle verwalten. Weitere Informationen zur Verarbeitung von Anforderungen und Nachrichten durch die SADBs finden Sie in der Manpage pf_key(7P).

Dienstprogramme zur Schlüsselerzeugung in IPsec

Das IKE-Protokoll bietet ein automatisches Schlüsselmanagement für IPv4- und IPv6-Adressen. Informationen zum Einrichten von IKE finden Sie in Kapitel 23Konfiguration von IKE (Aufgaben). Das manuelle Schlüssel-Dienstprogramm ist der Befehl ipseckey, der in der Manpage ipseckey(1M) ausführlich beschrieben wird.

Mit dem ipseckey-Befehl können Sie die Datenbank mit den Sicherheitszuordnungen (SADB) manuell auffüllen. In der Regel werden Sicherheitszuordnungen manuell erstellt, wenn IKE nicht zur Verfügung steht. Bei eindeutigen SPI-Werten können die manuelle SA-Erstellung und IKE jedoch auch parallel eingesetzt werden.

Mit dem ipseckey-Befehl können alle im System bekannten SAs aufgerufen werden – unabhängig davon, ob die Schlüssel manuell oder mit IKE hinzugefügt wurden. Ab Solaris 10 4/09 kann mit der -c-Option des ipseckey-Befehls die Syntax der als Argument bereitgestellten Schlüsseldatei überprüft werden.

IPsec-SAs, die mit dem ipseckey-Befehl hinzugefügt wurden, gehen bei einem erneuten Booten des Systems verloren. Wenn Sie in der aktuellen Version manuell hinzugefügte SAs beim Booten des Systems aktivieren möchten, fügen Sie Einträge in die Datei /etc/inet/secret/ipseckeys ein, und aktivieren Sie anschließend den svc:/network/ipsec/manual-key:default-Service. Die Verfahrensweise ist unter So erstellen Sie manuell IPsec-Sicherheitszuordnungen erläutert.

Obwohl der Befehl ipseckey nur über wenige allgemeine Optionen verfügt, unterstützt er eine umfangreiche Befehlssprache. Sie können festlegen, dass Anforderungen mittels einer programmatischen Schnittstelle zugestellt werden, die speziell für die manuelle Schlüsselerstellung gilt. Weitere Informationen finden Sie in der Manpage pf_key(7P).

Sicherheitsbetrachtungen für ipseckey

Mit dem ipseckey-Befehl können Sie als Superuser oder in einer Rolle mit dem Rechteprofil für Netzwerksicherheit bzw. Netzwerk-IPsec-Management vertrauliche kryptografische Informationen eingeben. Wenn ein potenzieller Gegner Zugriff auf diese Informationen erhält, könnte er die Sicherheit des IPsec-Datenverkehrs beeinflussen.

Berücksichtigen Sie bei der Verwaltung des Schlüsselmaterials und dem Verwenden des Befehls ipseckey sollten Sie die folgenden Punkte:

Sicherheitsschwächen beruhen häufig auf dem Fehlverhalten von Tools, nicht von tatsächlichen Tools. Aus diesem Grund sollten Sie bei der Verwendung des ipseckey-Befehls vorsichtig sein. Verwenden Sie eine Konsole oder ein anderes festverdrahtetes TTY für den sichersten Betriebsmodus.

IPsec-Erweiterungen für andere Dienstprogramme

Der Befehl ifconfig verfügt über Optionen zur Verwaltung der IPsec-Richtlinie für eine Tunnelschnittstelle. Der Befehl snoop kann AH- und ESP-Header analysieren.

ifconfig-Befehl und IPsec

In den Releases Solaris 10, Solaris 10 7/05, Solaris 10 1/06 und Solaris 10 11/06: Zur Unterstützung von IPsec stehen die folgenden Sicherheitsoptionen über den Befehl ifconfig zur Verfügung. Diese Sicherheitsoptionen werden vom Befehl ipsecconf im Solaris 10 7/07-Release verarbeitet.

Sie müssen alle IPsec-Sicherheitsoptionen für einen Tunnel in einem Aufruf angeben. Angenommen, Sie verwenden zum Schützen des Verkehrs nur ESP, können Sie den Tunnel ip.tun0 einmal mit beiden Sicherheitsoptionen wie in dem folgenden Beispiel konfigurieren:


# ifconfig ip.tun0 encr_algs aes encr_auth_algs md5

Entsprechend wird ein ipsecinit.conf-Eintrag den Tunnel einmal mit beiden Sicherheitsoptionen konfigurieren. Betrachten Sie dazu das folgende Beispiel:


# WAN traffic uses ESP with AES and MD5.
   {} ipsec {encr_algs aes encr_auth_algs md5}

auth_algs-Sicherheitsoption

Diese Option aktiviert einen IPsec AH-Header mit einem bestimmten Authentifizierungsalgorithmus für einen Tunnel. Die Option auth_algs hat das folgende Format:


auth_algs authentication-algorithm

Als Algorithmus können Sie entweder eine Zahl oder einen Algorithmusnamen einschließlich dem Parameter any verwenden, so dass kein bestimmter Algorithmus bevorzugt wird. Zum Deaktivieren der Tunnelsicherheit geben Sie die folgende Option an:


auth_algs none

Zum Anzeigen einer Liste der verfügbaren Authentifizierungsalgorithmen geben Sie den Befehl ipsecalgs ein.

Hinweis –

Die Option auth_algs arbeitet nicht mit NAT-Traversal. Weitere Informationen finden Sie unter IPsec und NAT Traversal.

encr_auth_algs-Sicherheitsoption

Diese Option aktiviert einen IPsec ESP-Header mit einem bestimmten Authentifizierungsalgorithmus für einen Tunnel. Die Option encr_auth_algs hat das folgende Format:


encr_auth_algs authentication-algorithm

Als Algorithmus können Sie entweder eine Zahl oder einen Algorithmusnamen einschließlich dem Parameter any verwenden, so dass kein bestimmter Algorithmus bevorzugt wird. Wenn Sie einen ESP-Verschlüsselungsalgorithmus, aber keinen Authentifizierungsalgorithmus angeben, nimmt der Werte für den ESP-Authentifizierungsalgorithmus standardmäßig den Parameter any an.

Zum Anzeigen einer Liste der verfügbaren Authentifizierungsalgorithmen geben Sie den Befehl ipsecalgs ein.

encr_algs-Sicherheitsoption

Diese Option aktiviert einen IPsec ESP-Header mit einem bestimmten Verschlüsselungsalgorithmus für einen Tunnel. Die Option encr_algs hat das folgende Format:


encr_algs encryption-algorithm

Als Algorithmus können Sie entweder eine Zahl oder den Algorithmusnamen angeben. Zum Deaktivieren der Tunnelsicherheit geben Sie die folgende Option an:


encr_algs none

Wenn Sie einen ESP-Authentifizierungsalgorithmus, aber keinen Verschlüsselungsalgorithmus angeben, nimmt der Wert der ESP-Verschlüsselung standardmäßig den Parameter null an.

Zum Anzeigen einer Liste der verfügbaren Verschlüsselungsalgorithmen geben Sie den Befehl ipsecalgs ein.

snoop-Befehl und IPsec

Der Befehl snoop kann AH- und ESP-Header analysieren. Da ESP seine Daten verschlüsselt, sieht der Befehl snoop keine verschlüsselten Header, die durch ESP geschützt wurden. AH verschlüsselt keine Daten. Aus diesem Grund kann Datenverkehr, der durch AH geschützt wird, mit dem Befehl snoop geprüft werden. Die Befehlsoption -V zeigt, wann AH für ein Paket verwendet wird. Weitere Informationen finden Sie in der Manpage snoop(1M).

Ein Beispiel einer ausführlichen Ausgabe des Befehls snoop bei einem geschützten Paket finden Sie unter So prüfen Sie, ob Pakete mit IPsec geschützt sind.

Kapitel 22 Internet Key Exchange (Übersicht)

Internet Key Exchange (IKE) automatisiert das Schlüsselmanagement für IPsec. Dieses Kapitel enthält die folgenden Informationen zum IKE:

Anweisungen zur Implementierung von IKE finden Sie in Kapitel 23Konfiguration von IKE (Aufgaben). Referenzinformationen finden Sie in Kapitel 24Internet Key Exchange (Referenz). Referenzinformationen zu IPsec finden Sie in Kapitel 19IP Security Architecture (Übersicht).

Neuerungen bei IKE

Solaris 10 4/09: Ab dieser Version wird IKE in der Service Management Facility (SMF) als Service verwaltet. Standardmäßig ist der Service svc:/network/ipsec/ike:default deaktiviert. Ebenfalls in dieser Version wird das Rechteprofil für das Netzwerk-IPsec-Management (zur Verwaltung von IPsec und IKE) bereitgestellt.

Solaris 10 7/07: Ab diesem Release kann IKE den AES-Algorithmus benutzen und in der globalen Zone für die Verwendung in nicht-globalen Zonen konfiguriert werden.

Schlüsselmanagement mit IKE

Die Verwaltung des Schlüsselmaterials für IPsec-Sicherheitszuordnungen (SAs) wird als Schlüsselmanagement bezeichnet. Für das automatische Schlüsselmanagement ist ein sicherer Kommunikationskanal erforderlich, damit Schlüsseln ordnungsgemäß erstellt, authentifiziert und ausgetauscht werden können. Das Solaris OS verwendet Internet Key Exchange (IKE) zum automatischen Schlüsselmanagement. IKE lässt sich mit einfachen Mitteln skalieren, um einen sicheren Kanal für hohen Datenverkehr bereitzustellen. IPsec SAs für IPv4- und IPv6-Pakete können von den Vorteilen von IKE profitieren.

Wird IKE auf einem System mit einem Sun Crypto Accelerator 1000-, einem Sun Crypto Accelerator 4000-oder einem Sun Crypto Accelerator 6000-Board betrieben, können die öffentlichen Schlüsselvorgänge an den Beschleuniger abgegeben werden. Die Betriebssystemressourcen werden dann nicht für PublicKey-Vorgänge genutzt. Wird IKE auf einem System mit einem Sun Crypto Accelerator 4000 oder einem Sun Crypto Accelerator 6000-Board verwendet, können die Zertifikate, Public Keys und Private Keys auf dem Board gespeichert werden. Die Schlüsselspeicherung findet außerhalb des Systems statt, um für eine zusätzliche Sicherheitsschicht zu sorgen.

IKE-Schlüsselaushandlung

Der IKE-Daemon in.iked sorgt für eine sichere Aushandlung und Authentifizierung des Schlüsselmaterials für SAs. Der Daemon verwendet Zufalls-Seeds für Schlüssel aus internen Funktionen, die von Solaris OS bereitgestellt werden. IKE bietet umfassende Sicherheit bei Weiterleitungen (PFS, Perfect Forward Secrecy). Bei PFS können die Schlüssel, mit denen die Datenübertragung geschützt wird, nicht zum Ableiten von weiteren Schlüsseln verwendet werden. Außerdem können Seeds, die zum Erstellen von Datenübertragungsschlüsseln verwendet werden, nicht wieder verwendet werden. Weitere Informationen finden Sie in der Manpage in.iked(1M).

Wenn der IKE-Daemon einen öffentlichen Chiffrierschlüssel eines Remote-Systems erfasst, kann das lokale System diesen Schlüssel verwenden. Das System verschlüsselt Nachrichten mithilfe des öffentlichen Schlüssels des Remote-Systems. Die Nachrichten können nur von diesem Remote-System gelesen werden. Der IKE-Daemon arbeitet in zwei Stufen. Diese Stufen werden als exchanges (Austauschvorgänge) bezeichnet.

IKE-Schlüssel – Terminologie

In der folgenden Tabelle sind Begriffe aufgeführt, die bei der Schlüsselaushandlung verwendet werden. Darüber hinaus sind Akronyme, Erklärungen und Verwendungsmöglichkeiten für jeden Begriff angegeben.

Tabelle 22–1 Begriffe, Akronyme und Verwendungsmöglichkeiten bei der Schlüsselaushandlung

Begriff 

Acronym 

Definition und Verwendung 

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. 

Perfect Forward Secrecy

PFS 

Gilt nur für authentifizierten Schlüsselaustausch. PFS stellt sicher, dass sich langfristig sicheres Schlüsselmaterial nicht negativ auf die Geheimhaltung von Schlüsseln auswirkt, die bei früheren Kommunikationen ausgetauscht wurden.  

Bei PFS kann der Schlüssel, der zum Schützen der Datenübertragung verwendet wird, nicht zum Ableiten weiterer Schlüssel verwendet werden. Außerdem wird die Quelle des Schlüssels, der zum Schützen von Datenübertragungen verwendet wird, niemals zum Ableiten weiterer Schlüssel verwendet. 

Oakley-Methode 

 

Eine Methode zum sicheren Erstellen der Schlüssel für Stufe 2. Das Protokoll ist analog zur Diffie-Hellman-Methode beim Key Exchange. Wie Diffie-Hellman führt der Schlüsselaustausch der Oakley-Methode Schlüsselerzeugung und Schlüsselauthentifizierung aus. Die Oakley-Methode dient zur Aushandlung von PFS. 

IKE Phase 1 Exchange

Der Phase 1 Exchange wird als Hauptmodus bezeichnet. Im Phase 1 Exchange verwendet IKE Verschlüsselungsmethoden mit öffentlichem Schlüssel, um sich selbst gegenüber IKE-Peer- Entitäten zu authentifizieren. Das Ergebnis ist eine Internet Security Association and Key Management Protocol (ISAKMP)-Sicherheitszuordnung (SA). Eine ISAKMP SA ist ein sicherer Kanal für IKE zur Aushandlung des Schlüsselmaterials für IP-Datagramme. Im Gegensatz zu IPsec SAs sind ISAKMP SAs bidirektional, daher wird nur eine Sicherheitszuordnung benötigt.

Das Verfahren zur Aushandlung des Schlüsselmaterials durch IKE beim Phase 1 Exchange kann konfiguriert werden. IKE liest die Konfigurationsinformationen in der Datei /etc/inet/ike/config ein. Die Konfigurationsinformationen umfassen Folgendes:

Die zwei Authentifizierungsmethoden sind PresharedKeys und PublicKey-Zertifikate. Die PublicKey-Zertifikate können selbst-signiert sein. Die Zertifikate können auch von einer Zertifizierungsstelle (Certificate authority, CA), einer PublicKey-Infrastruktur (PKI)-Organisation ausgegeben werden. Diese Organisationen sind z. B. beTrusted, Entrust, GeoTrust, RSA Security und Verisign.

IKE Phase 2 Exchange

Der Phase 2 Exchange wird als Schnellmodus bezeichnet. Beim Phase 2 Exchange erstellt und verwaltet IKE die IPsec SAs zwischen Systemen, die den IKE-Daemon ausführen. IKE verwendet den sicheren Kanal, der in Phase 1 erstellt wurde, für den Schutz der Übertragung des Schlüsselmaterials. Der IKE-Daemon erstellt die Schlüssel mithilfe des Geräts /dev/random aus einem Zufallszahlengenerator. Der Daemon aktualisiert die Schlüssel in einem konfigurierbaren Intervall. Das Schlüsselmaterial steht Algorithmen zur Verfügung, die in der Konfigurationsdatei für die IPsec-Richtlinie, ipsecinit.conf, angegeben sind.

IKE-Konfigurationsmöglichkeiten

Die Konfigurationsdatei /etc/inet/ike/config enthält Einträge für die IKE-Richtlinie. Damit zwei IKE-Daemons einander authentifizieren, müssen die Einträge gültig sein und das Schlüsselmaterial muss zur Verfügung stehen. Die Einträge in der Konfigurationsdatei bestimmen die Methode, in der das Schlüsselmaterial zur Authentifizierung des Phase 1 Exchange verwendet wird. Die Auswahlmöglichkeiten sind PresharedKeys oder PublicKey-Zertifikate.

Der Eintrag auth_method preshared legt fest, dass PresharedKeys verwendet werden. Andere Werte als preshared für auth_method kennzeichnen, dass PublicKey-Zertifikate verwendet werden. PublicKey-Zertifikate können selbst-signiert sein oder die Zertifikate können von einer PKI-Organisation installiert werden. Weitere Informationen finden Sie in der Manpage ike.config(4).

IKE mit PresharedKeys

PresharedKeys werden von einem Administrator auf einem System erstellt. Die Schlüssel werden dann außerbandig an die Administratoren der remoten Systeme weitergegeben. Achten Sie darauf, umfangreiche Zufallsschlüssel zu erzeugen und die Datei sowie die außerbandige Übertragung zu schützen. Die Schlüssel werden auf jedem System in der Datei /etc/inet/secret/ike.preshared abgelegt. Die Datei ike.preshared gilt für IKE , die Datei ipseckeys für IPsec. Eine Sicherheitsgefährdung der Schlüssel in der Datei ike.preshared gefährdet alle Schlüssel, die von den Schlüsseln in dieser Datei abgeleitet sind.

Ein Preshared-Schlüssel eines Systems muss identisch mit dem Schlüssel seines remoten Systems sein. Die Schlüssel sind an eine bestimmte IP-Adresse gebunden. Die Schlüssel sind am sichersten, wenn ein Administrator die kommunizierenden Systeme verwaltet. Weitere Informationen finden Sie in der Manpage ike.preshared(4).

IKE mit PublicKey-Zertifikaten

Mit PublicKey-Zertifikaten müssen kommunizierende Systeme kein geheimes außerbandiges Schlüsselmaterial mehr verwenden. PublicKeys verwenden das Diffie-Hellman-Protokoll (DH) zur Authentifizierung und Aushandlung von Schlüsseln. PublicKey-Zertifikate gibt es in zwei Ausführungen. Die Zertifikate können selbst-signiert sein, oder sie werden von einer Zertifizierungsstelle (Certificate authority, CA) zertifiziert.

Selbst-signierte PublicKey-Zertifikate werden von Ihnen, dem Administrator, erstellt. Mit dem Befehl ikecert certlocal -ks erstellen Sie den privaten Teil eines PublicKey-PrivateKey-Paars für das System. Dann erhalten Sie die selbst-signierte Zertifikatsausgabe im X.509-Format vom remoten System. Das Zertifikat des remoten Systems wird als öffentlicher Teil des Key-Paars in den Befehl ikecert certdb eingegeben. Die selbst-resignierten Zertifikate befinden sich in dem Verzeichnis /etc/inet/ike/publickeys der kommunizierenden Systeme. Wenn Sie die Option -T verwenden, befinden sich die Zertifikate auf einer angehängten Hardware.

Selbst-designierte Zertifikate stellen einen Kompromiss zwischen PresharedKeys und CAs dar. Im Gegensatz zu PresharedKeys kann ein selbst-signiertes Zertifikat auf einem mobilen Computer oder auf einem System verwendet werden, das neu nummeriert werden kann. Um ein Zertifikat für ein System ohne feststehende Nummer selbst zu signieren, verwenden Sie einen alternativen DNS-Namen (www.example.org) oder email (root@domain.org).

PublicKeys können von einer PK- oder einer CA-Organisation erstellt werden. Sie installieren die PublicKeys und deren begleitenden CAs im Verzeichnis /etc/inet/ike/publickeys. Wenn Sie die Option -T verwenden, befinden sich die Zertifikate auf einer angehängten Hardware. Anbieter veröffentlichen auch Listen der zurückgenommenen Zertifikate (Certificate Revocation-Lists, CRLs). Neben den Schlüsseln und CAs müssen Sie als Administrator auch die CRL im Verzeichnis /etc/inet/ike/crls installieren.

CAs haben den Vorteil, dass sie von einer außenstehenden Organisation und nicht vom Standort-Administrator zertifiziert werden. In gewisser Hinsicht sind CAs notariell beglaubigte Zertifikate. Wie auch selbst-signierte Zertifikate können CAs auf einem mobilen Computer oder auf einem System verwendet werden, dass neu nummeriert werden kann. Im Gegensatz zu selbst-signierten Zertifikaten können CAs leicht skaliert werden, um zahlreiche miteinander kommunizierende Systeme zu schützen.

IKE und Hardwarebeschleunigung

IKE-Algorithmen erfordern umfangreiche Berechnungen, insbesondere beim Phase 1 Exchange. Systeme, die zahlreiche Austauschvorgänge verarbeiten müssen, sollten ein Sun Crypto Accelerator 1000-Board zur Verarbeitung der PublicKey-Vorgänge verwenden. Die Sun Crypto Accelerator 6000- und Sun Crypto Accelerator 4000-Boards können auch für teuere Phase 1-Berechnungen verwendet werden.

Weitere Informationen, wie Sie IKE zum Ausführen der Berechnungen auf dem Beschleunigerboard konfigurieren, finden Sie unter So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board. Informationen zum Speichern von Schlüsseln finden Sie unterSo konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board und in der Manpage cryptoadm(1M).

IKE und Hardware-Speicherung

Public Key-Zertifikate, Private Keys und Public Keys können auf einem Sun Crypto Accelerator 6000- oder einem Sun Crypto Accelerator 4000-Board gespeichert werden. Bei der RSA-Verschlüsselung unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu einer Länge von 2048 Bit. Bei der DSA-Verschlüsselung unterstützt das Board Schlüssel bis zu einer Länge von 1024 Bit. Das Sun Crypto Accelerator 6000-Board unterstützt die SHA-512- und ECC-Algorithmen.

Informationen zur Konfiguration von IKE für den Zugriff auf das Board finden Sie unter So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board. Informationen zum Hinzufügen von Zertifikaten und PublicKeys zum Board finden Sie unter So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware.

IKE-Dienstprogramme und Dateien

In der folgenden Tabelle sind die Konfigurationsdateien für die IKE-Richtlinie, die Speicherorte für IKE-Schlüssel und die verschiedenen IKE-Befehle und -Services zusammengefasst. Weitere Informationen zu Services finden Sie in Kapitel 18, Managing Services (Overview) in System Administration Guide: Basic Administration.

Tabelle 22–2 IKE-Konfigurationsdateien, Speicherorte für Schlüssel, Befehle und Services

Datei, Speicherort, Befehl oder Service 

Beschreibung 

Weitere Informationen 

svc:/network/ipsec/ike

Der SMF-Service, der in der aktuellen Version die IKE-Verwaltung übernimmt.

smf(5)

/usr/lib/inet/in.iked-Daemon

Internet Key Exchange (IKE)-Daemon. Aktiviert die automatisierte Schlüsselverwaltung. In der aktuellen Version wird dieser Daemon durch den ike-Service aktiviert. In älteren Versionen wird der in.iked-Befehl verwendet.

in.iked(1M)

/usr/sbin/ikeadm-Befehl

IKE-Verwaltungsbefehl zum Anzeigen und Ändern der IKE-Richtlinie.

ikeadm(1M)

/usr/sbin/ikecert-Befehl

Befehl zur Verwaltung der Zertifikatdatenbank, mit dem lokale Datenbanken geändert werden können, die PublicKey-Zertifikate enthalten. Die Datenbanken können auch auf einem angehängtem Sun Crypto Accelerator 4000-Board gespeichert werden.

ikecert(1M)

/etc/inet/ike/config-Datei

Standardkonfigurationsdatei für die IKE-Richtlinie im Verzeichnis /etc/inet. Enthält die Regeln des Standorts für passende eingehende IKE-Anforderungen und zur Vorbereitung von abgehenden IKE-Anforderungen.

Falls diese Datei vorhanden ist, wird in der aktuellen Version der in.iked-Daemon gestartet, sobald der ike-Service aktiviert wird. Der Speicherort dieser Datei kann über den Befehl svccfg geändert werden.

ike.config(4)

ike.preshared-Datei

PresharedKeys-Datei im Verzeichnis /etc/inet/secret. Enthält sicheres Schlüsselmaterial für die Authentifizierung im Phase 1 Exchange. Wird bei der Konfiguration von IKE mit PresharedKeys verwendet.

ike.preshared(4)

ike.privatekeys-Verzeichnis

PrivateKeys-Verzeichnis im Verzeichnis /etc/inet/secret. Enthält die privaten Schlüssel, die Teil eines PublicKey-PrivateKey-Paares sind.

ikecert(1M)

publickeys-Verzeichnis

Verzeichnis im /etc/inet/ike-Verzeichnis, in dem PublicKeys und Zertifikatsdateien gespeichert sind. Enthält die öffentlichen Schlüssel, die Teil eines PublicKey-PrivateKey-Paares sind.

ikecert(1M)

crls-Verzeichnis

Verzeichnis im /etc/inet/ike-Verzeichnis, in dem Widerrufslisten (CRLs) für PublicKeys und Zertifikatsdateien gespeichert sind.

ikecert(1M)

Sun Crypto Accelerator 1000-Board 

Hardware, mit der PublicKey-Vorgänge beschleunigt werden, indem die Berechnung dieser Vorgänge für das Betriebssystem übernommen werden. 

ikecert(1M)

Sun Crypto Accelerator 4000-Board 

Hardware, mit der PublicKey-Vorgänge beschleunigt werden, indem die Berechnung dieser Vorgänge für das Betriebssystem übernommen werden. Außerdem können PublicKeys, PrivateKeys und PublicKey-Zertifikate auf dem Board gespeichert werden. 

ikecert(1M)

Änderungen an IKE für das Release Solaris 10

Nach dem Release Solaris 9 wurde IKE um die folgenden Leistungsmerkmale erweitert:

Kapitel 23 Konfiguration von IKE (Aufgaben)

In diesem Kapitel wird beschrieben, wie Sie den Internet Key Exchange (IKE) für Ihre Systeme konfigurieren. Nachdem IKE konfiguriert wurde, erzeugt es automatisch das für die Ausführung von IPsec in Ihrem Netzwerk erforderliche Schlüsselmaterial. Dieses Kapitel enthält die folgenden Informationen:

Eine Einführung in IKE finden Sie in Kapitel 22Internet Key Exchange (Übersicht). Referenzinformationen zu IKE finden Sie in Kapitel 24Internet Key Exchange (Referenz). Weitere Verfahren finden Sie im Beispielbereich der Manpages ikeadm(1M), ikecert(1M) und ike.config(4).

Konfiguration von IKE (Übersicht der Schritte)

Zur Authentifizierung von IKE können Sie PresharedKeys, selbst-designierte Zertifikate und Zertifikate von einer Zertifizierungsstelle (Certificate Authority, CA) verwenden. Eine Regel verbindet die jeweilige IKE-Authentifizierungsmethode mit den zu schützenden Endpunkten. Aus diesem Grund können Sie eine oder alle IKE-Authentifizierungsmethoden in einem System verwenden. Mit einem Zeiger auf die PKCS&;#11-Bibliothek können Zertifikate auch einen angehängten Hardwarebeschleuniger verwenden.

Nachdem Sie IKE konfiguriert haben, führen Sie die IPsec-Aufgabe aus, in der die IKE-Konfiguration verwendet wird. In der folgenden Tabelle wird auf die Übersichten verwiesen, die sich auf eine bestimmte IKE-Konfiguration beziehen.

Aufgabe 

Beschreibung 

Siehe 

Konfiguration von IKE mit PresharedKeys 

Schützen Sie die Kommunikation zwischen zwei Systemen, in dem die Systeme einen geheimen Schlüssel gemeinsam nutzen. 

Konfiguration von IKE mit PresharedKeys (Übersicht der Schritte)

Konfiguration von IKE mit PublicKey-Zertifikaten 

Schützen Sie die Kommunikation mit PublicKey-Zertifikaten. Die Zertifikate können selbst-signiert oder von einer PKI-Organisation ausgestellt worden sein. 

Konfiguration von IKE mit PublicKey-Zertifikaten (Übersicht der Schritte)

Durchlaufen einer NAT-Grenze 

Konfigurieren Sie IPsec und IKE zur Kommunikation mit einem mobilen System. 

Konfiguration von IKE für mobile Systeme (Übersicht der Schritte)

Konfiguration von IKE zum Erzeugen und Speichern von PublicKey-Zertifikaten auf angehängter Hardware 

Setzen Sie ein Sun Crypto Accelerator 1000-Board oder ein Sun Crypto Accelerator 4000-Board ein, um die Berechnung von IKE-Vorgängen zu beschleunigen. Auf dem Sun Crypto Accelerator 4000-Board können auch die PublicKey-Zertifikate gespeichert werden. 

Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte)

Optimieren der Phase 1-Parameter zur Schlüsselaushandlung 

Ändern Sie den Zeitpunkt der IKE-Schlüsselaushandlungen. 

Ändern der IKE-Übertragungsparameter (Übersicht der Schritte)

Konfiguration von IKE mit PresharedKeys (Übersicht der Schritte)

In der folgenden Tabelle wird auf Verfahren zur Konfiguration und Verwaltung von IKE mit PresharedKeys verwiesen.

Aufgabe 

Beschreibung 

Siehe 

Konfiguration von IKE mit PresharedKeys 

Erstellen Sie eine IKE-Richtliniendatei und einen gemeinsam zu nutzenden Schlüssel. 

So konfigurieren Sie IKE mit PresharedKeys

Aktualisieren der PresharedKeys auf einem laufenden IKE-System 

Fügen Sie neues Schlüsselmaterial für IKE auf den kommunizierenden Systemen hinzu. 

So werden IKE PresharedKeys aktualisiert

Hinzufügen von PresharedKeys zu einem laufenden IKE-System 

Fügen Sie einen neuen IKE-Richtlinieneintrag und neues Schlüsselmaterial zu einem System hinzu, das derzeit eine IKE-Richtlinie durchsetzt. 

So fügen Sie einen IKE PresharedKey für einen neuen Richtlinieneintrag in ipsecinit.conf ein

Prüfen, ob die PresharedKeys identisch sind 

Zeigen Sie die PresharedKeys auf beiden Systemen an, so dass Sie feststellen können, ob die Schlüssel identisch sind 

So prüfen Sie, ob die IKE PresharedKeys identisch sind

Konfiguration von IKE mit PresharedKeys

PresharedKeys ist die einfachste Authentifizierungsmethode für IKE. Wenn Sie beide Systeme so könfigurieren, dass sie IKE verwenden und Administrator beide Systeme sind, ist die Methode PresharedKeys eine gute Wahl. Im Gegensatz zu PublicKey-Zertifikaten sind PresharedKeys jedoch an bestimmte IP-Adressen gebunden. PresharedKeys können daher nicht mit mobilen Systemen oder Systemen verwendet werden, die neue Adressen erhalten. Darüber hinaus können Sie bei der Verwendung von PresharedKeys die Berechnung von IKE-Vorgängen nicht an angehängte Hardware abgeben.

ProcedureSo konfigurieren Sie IKE mit PresharedKeys

Die IKE-Implementierung bietet Algorithmen, deren Schlüssel unterschiedlich lang sind. Die von Ihnen gewählte Schlüssellänge wird von der Standortsicherheit vorgegeben. Im Allgemeinen bieten längere Schlüssel größere Sicherheit als kürzere Schlüssel.

In diesen Verfahren werden die Systeme enigma und partym verwendet. Ersetzen Sie enigma und partym durch die Namen Ihrer Systeme.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Kopieren Sie auf jedem System die Datei /etc/inet/ike/config.sample nach /etc/inet/ike/config.

  3. Geben Sie die Regeln und globalen Parameter auf jedem System in die Datei ike/config ein.

    Die Regeln und globalen Parameter in dieser Datei müssen zulassen, dass die IPsec-Richtlinie in der Datei ipsecinit.conf auf dem System erfolgreich ist. Die folgenden ike/config-Beispiele arbeiten mit den ipsecinit.conf-Beispielen unter So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec.

    1. Ändern Sie beispielsweise die Datei /etc/inet/ike/config auf dem System enigma:


      ### ike/config file on enigma, 192.168.116.16

## Global parameters
#
## Phase 1 transform defaults
p1_lifetime_secs 14400
p1_nonce_len 40
#
## Defaults that individual rules can override.
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2
#
## The rule to communicate with partym
#  Label must be unique
{ label "enigma-partym"
  local_addr 192.168.116.16
  remote_addr 192.168.13.213
  p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
  p2_pfs 5
}
      Hinweis –

      Alle Argumente für den Parameter auth_method müssen sich auf der gleichen Zeile befinden.

    2. Ändern Sie die Datei /etc/inet/ike/config auf dem System partym:


      ### ike/config file on partym, 192.168.13.213
## Global Parameters
#
p1_lifetime_secs 14400
p1_nonce_len 40
#
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2

## The rule to communicate with enigma
#  Label must be unique
{ label "partym-enigma"
  local_addr 192.168.13.213
  remote_addr 192.168.116.16
p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
p2_pfs 5
}

  4. Prüfen Sie auf den einzelnen Systemen die Dateisyntax.


    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

  5. Erzeugen Sie Zufallszahlen für das Schlüsselmaterial.

    Falls Ihr Standort über einen Generator für Zufallszahlen verfügt, verwenden Sie diesen. Auf einem Solaris-System können Sie den Befehl od verwenden. Beispielsweise druckt der folgende Befehl zwei Zeilen mit hexadezimalen Zahlen:


    % od -X -A n /dev/random | head -2
         f47cb0f4 32e14480 951095f8 2b735ba8
         0a9467d0 8f92c880 68b6a40e 0efe067d

    Eine Beschreibung des Befehls od finden Sie unter So erzeugen Sie Zufallszahlen auf einem Solaris-System und in der Manpage od(1).

    Hinweis –

    Andere Betriebssysteme erfordern Schlüsselmaterial im ASCII-Format. Wie Sie einen identischen Schlüssel im hexadezimalen und im ASCII-Format erzeugen, finden Sie unter Beispiel 23–1.

  6. Erzeugen Sie einen Schlüssel aus der Ausgabe in Schritt 5.


    f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

    Der Authentifizierungsalgorithmus in diesem Verfahren ist SHA–1 (wie in Schritt 3 gezeigt). Die Größe des Hash (d. h., die Größe der Ausgabe des Authentifizierungsalgorithmus) schreibt die empfohlene Mindestmenge für einen PresharedKey vor. Die Ausgabe des SHA–1-Algorithmus beträgt 160 Bit oder 40 Zeichen. Der Beispielschlüssel ist 56 Zeichen lang, wodurch IKE zusätzliches Schlüsselmaterial verwenden kann.

  7. Erstellen Sie auf jedem System eine /etc/inet/secret/ike.preshared-Datei.

    Geben Sie den PresharedKey in jede Datei ein.

    1. Auf dem System enigma enthält die ike.preshared-Datei dann Folgendes:


      # ike.preshared on enigma, 192.168.116.16
#…
{ localidtype IP
	localid 192.168.116.16
	remoteidtype IP
	remoteid 192.168.13.213
	# enigma and partym's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}

    2. Auf dem System partym enthält die ike.preshared-Datei dann Folgendes:


      # ike.preshared on partym, 192.168.13.213
#…
{ localidtype IP
	localid 192.168.13.213
	remoteidtype IP
	remoteid 192.168.116.16
	# partym and enigma's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}
    Hinweis –

    Die PresharedKeys auf den Systemen müssen identisch sein.

Beispiel 23–1 Erzeugen von identischem Schlüsselmaterial für zwei Systeme mit unterschiedlichen Betriebssystemen

Solaris IPsec kann mit anderen Betriebssystemen zusammenarbeiten. Falls Ihr System mit einem System kommuniziert, das PresharedKeys im ASCII-Format benötigt, müssen Sie einen Schlüssel in zwei Formaten, hexadezimal und ASCII, erstellen.

Im folgenden Beispiel möchte der Solaris-Systemadministrator 56 Zeichen für das Schlüsselmaterial verwenden. Der Administrator verwendet den folgenden Befehl, um einen hexadezimalen Schlüssel aus einem ASCII-Passwortsatz zu erzeugen. Mit der Option -tx1 werden die Byte nacheinander auf allen Solaris-Systemen gedruckt.


# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

Durch Entfernen der Offsets und Verketten der hexadezimalen Ausgabe wird der hexadezimalen Schlüssel für das Solaris-System erstellt: 7061706965726d616368652077697468206361736865777320616e64 . Der Administrator fügt diesen Wert in die Datei ike.preshared auf dem Solaris-System ein.


# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

Auf dem System, das PresharedKeys im ASCII-Format erfordert, bildet der Passwortsatz den PresharedKey. Der Solaris-Systemadministrator sendet dem anderen Administrator telefonisch den Passwortsatz papiermache with cashews and.

ProcedureSo werden IKE PresharedKeys aktualisiert

Bei diesem Verfahren wird davon ausgegangen, dass Sie einen vorhandenen PresharedKey in regelmäßigen Intervallen ersetzen möchten.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Erzeugen Sie Zufallszahlen und konstruieren Sie einen Schlüssel in der erforderlichen Länge.

    Ausführliche Informationen finden Sie im Abschnitt So erzeugen Sie Zufallszahlen auf einem Solaris-System. Informationen zum Erzeugen von Schlüsselmaterial für ein Solaris-System, das mit einem Betriebssystem kommuniziert, das Schlüsselmaterial im ASCII-Format benötigt, finden Sie in Beispiel 23–1.

  3. Ersetzen Sie den aktuellen Schlüssel durch einen neuen Schlüssel.

    Bei den Hosts enigma und partym ersetzen Sie den Wert von key in der Datei /etc/inet/secret/ike.preshared durch eine Zahl der gleichen Länge.

  4. Lesen Sie den neuen Schlüssel in den Systemkern ein.

    • Wenn Sie mindestens mit Solaris 10 4/09 arbeiten, aktualisieren Sie den ike-Service.


      # svcadm refresh ike

    • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, muss der in.iked-Daemon beendet und neu gestartet werden.

      1. Überprüfen Sie die Privilegstufe des in.iked-Daemons.


        # /usr/sbin/ikeadm get priv
Current privilege level is 0x0, base privileges enabled

        Sie können das Schlüsselmaterial ändern, wenn dieser Befehl eine Privilegstufe von 0x1 oder 0x2 zurückgibt. Bei der Privilegstufe 0x0 ist das Ändern oder Anzeigen von Schlüsselmaterial nicht gestattet. Standardmäßig wird der in.iked-Daemon mit der Privilegstufe 0x0 ausgeführt.

      2. Lautet die Privilegstufe 0x0, brechen Sie den Daemon ab und starten ihn neu.

        Wenn der Daemon neu startet, liest er die neue Version der ike.preshared-Datei ein.


        # pkill in.iked
# /usr/lib/inet/in.iked

      3. Lautet die Privilegstufe 0x1 oder 0x2, lesen Sie die neue Version der ike.predshared-Datei ein.


        # ikeadm read preshared

ProcedureSo rufen Sie IKE PresharedKeys auf

Standardmäßig verhindert der Befehl ikeadm die Anzeige der tatsächlichen Schlüssel in einem Speicherauszug einer Phase-1-SA. Die Anzeige der Schlüssel ist bei der Fehlersuche hilfreich.

Um die tatsächlichen Schlüssel anzuzeigen, müssen Sie die Privilegstufe für diesen Daemon erhöhen. Eine Beschreibung der Privilegstufe finden Sie unter IKE-Verwaltungsbefehl.

Hinweis –

Wenn Sie dieses Verfahren in einer Version vor Solaris 10 4/09 durchführen möchten, schauen Sie sich die Hinweise unter Beispiel 23–2 an.

Bevor Sie beginnen

IKE ist konfiguriert, und der ike-Service wird ausgeführt.

  1. Rufen Sie die IKE PresharedKeys auf.


    # ikeadm
ikeadm> dump preshared

  2. Wenn ein Fehler auftritt, erhöhen Sie die Privilegstufe des in.iked-Daemons.

    1. Erhöhen Sie die Privilegstufe des in.iked-Daemons im SMF-Repository.


      # svcprop -p config/admin_privilege ike
base
# svccfg -s ike setprop config/admin_privilege=keymat

    2. Erhöhen Sie die Privilegstufe des ausgeführten in.iked-Daemons.


      # svcadm refresh ike ; svcadm restart ike

    3. (Optional) Überprüfen Sie, ob die Privilegstufe keymat lautet.


      # svcprop -p config/admin_privilege ike
keymat

    4. Zeigen Sie die Schlüssel an, indem Sie Schritt 1 erneut ausführen.

  3. Legen Sie für den IKE-Daemon wieder die Basis-Privilegstufe fest.

    1. Legen Sie nach der Betrachtung der Schlüssel wieder die ursprüngliche Privilegstufe fest.


      # svccfg -s ike setprop config/admin_privilege=base

    2. Aktualisieren Sie die Ansicht, und starten Sie IKE anschließend neu.


      # svcadm refresh ike ; svcadm restart ike
Beispiel 23–2 Überprüfen von IKE PresharedKeys in einer Version vor Solaris 10 4/09

Im folgenden Beispiel betrachtet der Administrator Schlüssel auf einem System mit einer älteren Solaris-Version. Der Administrator möchte sich vergewissern, dass die Schlüssel im System identisch mit den Schlüsseln im Kommunikationssystem sind. Nachdem der Administrator festgestellt hat, dass die Schlüssel der beiden Systeme identisch sind, stellt er die Privilegstufe 0 wieder her.

ProcedureSo fügen Sie einen IKE PresharedKey für einen neuen Richtlinieneintrag in ipsecinit.conf ein

Wenn Sie IPsec-Richtlinieneinträge hinzufügen, während IPsec und IKE ausgeführt werden, müssen Sie die neue Richtlinie und die neuen IKE-Regeln in den Systemkern einlesen. Wenn Sie mindestens mit Solaris 10 4/09 arbeiten, starten Sie den policy-Service neu und aktualisieren den ike-Service, nachdem Sie die neuen Schlüssel hinzugefügt haben.

Hinweis –

Wenn Sie dieses Verfahren in einer Version vor Solaris 10 4/09 durchführen möchten, schauen Sie sich die Hinweise unter Beispiel 23–3 an.

Bevor Sie beginnen

Bei diesem Verfahren wird das folgende Setup vorausgesetzt:

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Erstellen Sie auf diesem System Zufallszahlen und einen Schlüssel mit 64 bis 448 Bit.

    Ausführliche Informationen finden Sie im Abschnitt So erzeugen Sie Zufallszahlen auf einem Solaris-System. Informationen zum Erzeugen von Schlüsselmaterial für ein Solaris-System, das mit einem Betriebssystem kommuniziert, das Schlüsselmaterial im ASCII-Format benötigt, finden Sie in Beispiel 23–1.

  3. Senden Sie den Schlüssel an den Administrator des remoten Systems.

    Beide Administratoren müssen den gleichen PresharedKey zum gleichen Zeitpunkt hinzufügen. Ihr Schlüssel ist nur so sicher wie die Sicherheit Ihres Übertragungsmechanismus. Wir empfehlen einen außerbandigen Mechanismus, z. B. einen Einschreibebrief oder eine geschützte Faxübertragung. Sie können die beiden Systeme auch über eine ssh-Sitzung verwalten.

  4. Erstellen Sie eine Regel für IKE, um die Schlüssel für enigma und ada zu verwalten.

    1. Fügen Sie auf dem System enigma der Datei /etc/inet/ike/config die folgende Regel hinzu:


      ### ike/config file on enigma, 192.168.116.16
 
## The rule to communicate with ada

{label "enigma-to-ada"
 local_addr 192.168.116.16
 remote_addr 192.168.15.7
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
	}

    2. Fügen Sie auf dem System ada die folgende Regel hinzu:


      ### ike/config file on ada, 192.168.15.7
 
## The rule to communicate with enigma

{label "ada-to-enigma"
 local_addr 192.168.15.7
 remote_addr 192.168.116.16
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
}

  5. Stellen Sie sicher, dass die IKE PresharedKeys beim erneuten Booten zur Verfügung stehen.

    1. Fügen Sie auf dem System enigma der Datei /etc/inet/secret/ike.preshared die folgenden Informationen hinzu:


      # ike.preshared on enigma for the ada interface
# 
{ localidtype IP
  localid 192.168.116.16
  remoteidtype IP
  remoteid 192.168.15.7
  # enigma and ada's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

    2. Fügen Sie auf dem System ada der Datei ike.preshared die folgenden Informationen hinzu:


      # ike.preshared on ada for the enigma interface
# 
{ localidtype IP
  localid 192.168.15.7
  remoteidtype IP
  remoteid 192.168.116.16
  # ada and enigma's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

  6. Starten Sie auf den einzelnen Systemen den Service für die IPsec-Richtlinie neu, damit die neue Schnittstelle ebenfalls geschützt wird.


    # svcadm restart policy

  7. Aktualisieren Sie auf den einzelnen Systemen den ike-Service.


    # svcadm refresh ike

  8. Prüfen Sie, ob die Systeme miteinander kommunizieren können.

    Lesen Sie dazu So prüfen Sie, ob die IKE PresharedKeys identisch sind.

Beispiel 23–3 Hinzufügen eines IKE PresharedKeys für einen neuen IPsec-Richtlinieneintrag

Im folgenden Beispiel fügt der Administrator einen PresharedKey einem System hinzu, auf dem nicht die aktuellste Solaris-Version ausgeführt wird. Der Administrator befolgt das vorstehende Verfahren zur Änderung der Dateien ike/config und ike.preshared, zur Erstellung von Schlüsseln und zur Herstellung einer Verbindung zum Remote-System. Zum Einlesen der neuen IPsec-Richtlinie und der IKE-Regeln in den Systemkern verwendet der Administrator unterschiedliche Befehle.

ProcedureSo prüfen Sie, ob die IKE PresharedKeys identisch sind

Wenn die PresharedKeys auf den kommunizierenden Systemen nicht identisch sind, können die Systeme nicht authentifiziert werden.

Bevor Sie beginnen

IPsec wurde konfiguriert und ist zwischen den zu testenden Systemen aktiviert. Sie führen die aktuelle Version (Solaris 10) aus.

Hinweis –

Wenn Sie dieses Verfahren in einer Version vor Solaris 10 4/09 durchführen möchten, schauen Sie sich die Hinweise unter Beispiel 23–2 an.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere Remoteanmeldung.

  2. Prüfen Sie auf den einzelnen Systemen die Privilegstufe des in.iked-Daemons.


    # svcprop -p config/admin_privilege ike
base

    • Falls die Privilegstufe keymat lautet, fahren Sie mit Schritt 3 fort.

    • Falls die Privilegstufe base oder modkeys lautet, erhöhen Sie die Stufe.

      Aktualisieren Sie anschließend das System, und starten Sie den ike-Service neu.


      # svccfg -s ike setprop config/admin_privilege=keymat
# svcadm refresh ike ; svcadm restart ike
# svcprop -p config/admin_privilege ike
keymat

  3. Zeigen Sie die PresharedKey-Informationen auf beiden Systemen an.


    # ikeadm dump preshared
PSKEY: Preshared key (24 bytes): f47cb…/192
LOCIP: AF_INET: port 0, 192.168.116.16 (enigma).
REMIP: AF_INET: port 0, 192.168.13.213 (partym).

  4. Vergleichen Sie die beiden Speicherauszüge.

    Sind die PresharedKeys nicht identisch, ersetzen Sie in der Datei /etc/inet/secret/ike.preshared einen Schlüssel durch den anderen.

  5. Ändern Sie die Privilegstufe nach Abschluss der Prüfung wieder in den jeweiligen Standardwert der Systeme.


    # svccfg -s ike setprop config/admin_privilege=base
# svcadm restart ike

Konfiguration von IKE mit PublicKey-Zertifikaten (Übersicht der Schritte)

Die folgende Tabelle enthält Verweise auf Verfahren, in denen beschrieben wird, wie PublicKey-Zertifikaten für IKE erzeugt werden. Außerdem enthalten die Verfahren Informationen zum Beschleunigen und Speichern der Zertifikate auf angehängter Hardware.

Aufgabe 

Beschreibung 

Siehe 

Konfiguration von IKE mit selbst-signierten PublicKey-Zertifikaten 

Erstellen und fügen Sie jedem System zwei Zertifikate hinzu: 

  • Ein selbst-signiertes Zertifikat

  • Ein PublicKey-Zertifikat vom remoten System

So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten

Konfiguration von IKE mit einer PKI-Zertifikatsautorität 

Erstellen Sie eine Zertifikatsanforderung und fügen Sie jedem System drei Zertifikate hinzu: 

  • Das Zertifikat, das die Zertifikatsautorität (Certificate Authority, CA) aufgrund Ihrer Anforderung erstellt hat

  • Das PublicKey-Zertifikat von der CA

  • Die CRL von der CA

So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden

Konfiguration von PublicKey-Zertifikaten auf der lokalen Hardware 

Hierzu gehört entweder:  

  • Das Erzeugen selbst-signierter Zertifikate auf der lokalen Hardware und anschließend das Hinzufügen des PublicKey von einem remoten System zur Hardware.

  • Das Erzeugen einer Zertifikatsanforderung auf der lokalen Hardware und anschließend das Hinzufügen der PublicKey-Zertifikate von der CA zur Hardware.

So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware

Aktualisieren der Zertifikat-Widerrücknahmeliste (CRL) von einer PKI 

Zugriff auf die CRL an einem zentralen Verteilungspunkt. 

So verarbeiten Sie eine Zertifikat-Rücknahmeliste

Konfiguration von IKE mit PublicKey-Zertifikaten

Mit PublicKey-Zertifikaten müssen kommunizierende Systeme kein geheimes außerbandiges Schlüsselmaterial mehr verwenden. Im Gegensatz zu PresharedKeys kann ein PublicKey-Zertifikat auf einem mobilen Computer oder auf einem System verwendet werden, dass neu nummeriert werden kann.

PublicKey-Zertifikate können auch auf angehängter Hardware gespeichert werden. Informationen hierzu finden Sie unter Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte).

ProcedureSo konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten

Selbst-designierte Zertifikate erfordern weniger Aufwand als öffentliche Zertifikate von einer CA, lassen sich jedoch nicht einfach skalieren.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Fügen Sie ein selbst-signiertes Zertifikat in die Datenbank ike.privatekeys ein. 


    # ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]
    -ks

    Erstellt ein selbst-signiertes Zertifikat.

    -kc

    Erstellt eine Zertifikatanforderung. Informationen hierzu finden Sie unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

    -m Schlüsselgröße

    Die Größe des Schlüssels. Schlüsselgröße kann 512, 1024, 2048, 3072 oder 4096 annehmen.

    -t Schlüsseltyp

    Gibt den zu verwendenden Algorithmustyp an. Schlüsseltyp kann rsa-sha1, rsa-md5 oder dsa-sha1 annehmen.

    -D dname

    Der X.509-Distinguished Name (DN) für das Zertifikatssubjekt. dname hat in der Regel folgende Form: C=Land, O= Organisation, OU= Organisationseinheit, CN= allgemeiner Name. Gültige Tags sind C, O, OU und CN.

    -A altname

    Der Alternativname für das Zertifikat. altname hat im allgemeinen das Format Tag=Wert. Gültige Tags sind IP, DNS, email und DN.

    -S Gültigkeit-Anfang

    Ist das absolute oder relative Anfangsdatum der Zertifikatsgültigkeit.

    -F Gültigkeit-Ende

    Ist das absolute oder relative Enddatum der Zertifikatsgültigkeit.

    -T Token-ID

    Ermöglicht, dass ein PKCS&;#11-Hardwaretoken die Schlüssel erzeugt. Die Zertifikate werden dann auf der Hardware gespeichert.

    1. Der Befehl auf dem System partym sieht in etwa wie folgt aus:


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. Der Befehl auf dem System enigma sieht in etwa wie folgt aus:


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  3. Speichern Sie das Zertifikat und senden Sie es an das remote System.

    Sie können das Zertifikat in eine E-Mail einfügen.

    1. So können Sie das folgende partym-Zertifikat an den Administrator von enigma senden:


      To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. Der Administrator von enigma sendet Ihnen das folgende enigma-Zertifikat:


      To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  4. </remark>Fügen Sie auf jedem System das empfangene Zertifikat ein.

    1. Kopieren Sie den PublicKey aus der E-Mail des Administrators.

    2. Geben Sie den Befehl ikecert certdb -a ein, und drücken Sie die Eingabetaste.

      Wenn Sie die Eingabetaste drücken, werden keine Eingabeaufforderungen angezeigt.


      # ikecert certdb -a Press the Return key

    3. Fügen Sie den PublicKey ein, und drücken Sie die Eingabetaste. Drücken Sie dann Strg-D, um den Eintrag zu beenden.


      -----BEGIN X509 CERTIFICATE-----
MIIC…
…
----END X509 CERTIFICATE----- Press the Return key
<Control>-D

  5. Prüfen Sie gemeinsam mit dem anderen Administrator, dass das Zertifikat von diesem Administrator stammt.

    Beispielsweise können Sie mit dem anderen Administrator telefonieren und die Werte des PublicKey-Hash vergleichen. Das PublicKey-Hash für das gemeinsam genutzte Zertifikat muss auf beiden Systemen gleich sein.

    1. Listen Sie das gespeicherte Zertifikat auf Ihrem System auf.

      So befindet sich das öffentliche Zertifikat z. B. auf dem System partym in Slot 1 und das private Zertifikat in Slot 0.


      partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. Vergleichen Sie diesen Wert mit dem PublicKey-Hash auf dem System enigma.

      Sie können den PublicKey-Hash über das Telefon vorlesen.


      enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

  6. Richten Sie auf den Systemen eine Vertrauensstellung für die beide Zertifikate ein.

    Ändern Sie die Datei /etc/inet/ike/config so, dass die Zertifikate erkannt werden.

    Der Administrator des remoten Systems stellt die Werte für die Parameter cert_trust, remote_addr und remote_id zur Verfügung.

    1. Auf dem System partym enthält die ike/config-Datei Folgendes:


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## Parameters that may also show up in rules.

p1_xform 
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 5

{
 label "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    2. Geben Sie auf dem System enigma die enigma-Werte für lokale Parameter in die Datei ike/config ein.

      Für die remoten Parameter verwenden Sie partym-Werte. Achten Sie darauf, dass der Wert für das Schlüsselwort label einmalig ist. Der Wert muss sich von dem label-Wert des remoten Systems unterscheiden.


      …
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…
Beispiel 23–4 Prüfen Sie, ob das Zertifikat vom anderen Administrator gültig ist

In diesem Beispiel verwenden die Administratoren den „Subject Name“ um sicherzustellen, dass die Zertifikate identisch sind.

Der erste Administrator speichert die Ausgabe des Erzeugens und Auflistens des Zertifikats in einer Datei. Da die Ausgabe des ikecert-Befehls in den Standardfehler druckt, leitet der Administrator den Standardfehler an die Datei um.


sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

Der Administrator überprüft den Inhalt der Datei.


sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Dann sendet der Administrator die Datei in einer E-Mail an den zweiten Administrator.

Der zweite Administrator fügt die Datei in ein sicheres Verzeichnis ein und importiert dann das Zertifikat aus der Datei.


sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

Der Befehl ikecert importiert nur den Text zwischen den Zeilen -----BEGIN und -----END. Der Administrator überprüft, ob das lokale Zertifikat den gleichen öffentlichen Key-Hash wie in der Datei co2sys aufweist.


sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Um sicherzustellen, dass der erste Administrator diese E-Mail gesendet hat, telefoniert der zweite Administrator, um die Richtigkeit des „Subject Name“ des Zertifikats zu bestätigen.

Beispiel 23–5 Einrichten von Anfangs- und Enddatum für die Gültigkeit eines Zertifikats

In diesem Beispiel gibt der Administrator des Systems partym vor, wie lange ein Zertifikat gültig ist. Das Zertifikat ist um 2 1/2 Tage zurückdatiert und gilt für vier Jahre und sechs Monate ab dem Erstellungsdatum.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

Der Administrator des Systems enigma gibt die Daten an, innerhalb denen das Zertifikat gültig ist. Das Zertifikat wurde um zwei Tage zurückdatiert und gilt bis Mitternacht am 31. Dezember 2010.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

ProcedureSo konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden

Öffentliche Zertifikate einer Zertifikatsautorität (CA) machen eine Aushandlung mit einer außenstehenden Organisation erforderlich. Diese Zertifikate können leicht skaliert werden, so dass zahlreiche miteinander kommunizierende Systeme geschützt werden können.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Geben Sie den Befehl ikecert certlocal -kc ein, um ein Zertifikat anzufordern.

    Eine Beschreibung der Argumente dieses Befehls finden Sie in Schritt 2 unter So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten.


    # ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

    1. Der folgende Befehl erstellt eine Zertifikat-Anforderung auf dem System partym:


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

    2. Der folgende Befehl erstellt eine Zertifikat-Anforderung auf dem System enigma:


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

  3. Übermitteln Sie die Zertifikat-Anforderung an eine PKI-Organisation.

    Die PKI-Organisation teilt Ihnen mit, wie die Zertifikat-Anforderung übermittelt werden soll. Die meisten Organisationen verfügen über eine Website mit einem Übertragungsformular. Das Formular fordert einen Beweis, dass die Übertragung legitim ist. In der Regel fügen Sie Ihre Zertifikat-Anforderung in das Formular ein. Nachdem Ihre Anforderung von der Organisation überprüft wurde, stellt sie die folgenden zwei Zertifikatsobjekte sowie eine Liste zurückgenommenen Zertifikate aus:

    • Ihr PublicKey-Zertifikat – Dieses Zertifikat basiert auf der Anforderung, die Sie an die Organisation übermittelt haben. Die von Ihnen übermittelte Anforderung ist Teil dieses PublicKey-Zertifikats. Das Zertifikat identifiziert Sie eindeutig.

    • Eine Zertifikatsautorität – Die Signatur der Organisation. Die CA prüft, ob Ihr PublicKey-Zertifikat echt und unverfälscht ist.

    • Eine Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) – Die aktuelle Liste der Zertifikate, die von der Organisation zurückgenommen wurden. Die CRL wird nicht separat als ein Zertifikatsobjekt gesendet, wenn der Zugriff auf die CRL in das PublicKey-Zertifikat eingebettet ist.

      Ist ein URI für die CRL in das PublicKey-Zertifikat eingebettet, kann IKE die CRL automatisch für Sie abrufen. Entsprechend gilt, ist ein DN-Eintrag (Verzeichnisname auf einem LDAP-Server) in das PublicKey-Zertifikat eingebettet, kann IKE die CRL vom angegebenen LDAP-Server abrufen und zwischenspeichern.

      Ein Beispiel eines eingebetteten URI und eines eingebetteten DN-Eintrags in einem PublicKey-Zertifikat finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

  4. Fügen Sie Ihrem System alle Zertifikate hinzu.

    Mit der Option -a des Befehls ikecert certdb -a fügen Sie das eingefügte Objekt der entsprechenden Zertifikatdatenbank Ihres Systems hinzu. Weitere Informationen finden Sie unter IKE mit PublicKey-Zertifikaten.

    1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    2. Fügen Sie das PublicKey-Zertifikat hinzu, das Sie von der PKI -Organisation empfangen haben.


      # ikecert certdb -a
Press the Return key
Paste the certificate:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    3. Fügen Sie die CA von der PKI-Organisation hinzu.


      # ikecert certdb -a
Press the Return key
Paste the CA:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    4. Wenn die PKI-Organisation eine Liste der zurückgenommenen Zertifikate gesendet hat, fügen Sie die CRL zur certrldb-Datenbank hinzu:


      # ikecert certrldb -a
Press the Return key
Paste the CRL:
-----BEGIN CRL-----
…
-----END CRL----
Press the Return key
<Control>-D

  5. Geben Sie das Schlüsselwort cert_root ein, um die PKI-Organisation in der Datei /etc/inet/ike/config zu identifizieren.

    Verwenden Sie den von der PKI-Organisation angegebenen Namen.

    1. Die Datei ike/config auf dem System partym könnte wie folgt aussehen:


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform 
 { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "US-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}
      Hinweis –

      Alle Argumente für den Parameter auth_method müssen sich auf der gleichen Zeile befinden.

    2. Erstellen Sie eine ähnliche Datei auf dem System enigma.

      Beachten Sie bei der Datei enigma ike/config Folgendes:

      • Fügen Sie den gleichen cert_root-Wert hinzu.

      • Verwenden Sie enigma-Werte für lokale Parameter.

      • Verwenden Sie partym-Werte für remote Parameter.

      • Erstellen Sie einen einmaligen Wert für das Schlüsselwort label. Der Wert muss sich von dem label-Wert des remoten Systems unterscheiden.


      …
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

  6. Weisen Sie IKE an, wie die CRLs verarbeitet werden sollen.

    Wählen Sie die geeignete Option:

    • Keine CRL verfügbar

      Wenn die PKI-Organisation keine CRL zur Verfügung stellt, fügen Sie das Schlüsselwort ignore_crls zur ike/config -Datei hinzu.


      # Trusted root cert
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,…
ignore_crls
…

      Das Schlüsselwort ignore_crls weist IKE an, nicht nach CRLs zu suchen.

    • CRL verfügbar

      Wenn die PKI-Organisation einen zentralen Verteilungspunkt für CRLs bereitstellt, können Sie in der Datei ike/config auf diesen Speicherort verweisen.

      Beispiele finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

Beispiel 23–6 Verwenden von rsa_encrypt bei der Konfiguration von IKE

    Wenn Sie auth_method rsa_encrypt in der ike/config-Datei angeben, müssen Sie das Zertifikat des Peers zur publickeys-Datenbank hinzufügen.

  1. Senden Sie das Zertifikat an den Administrator des remoten Systems.

    Sie können das Zertifikat in eine E-Mail einfügen.

    Der Administrator von partym sendet Ihnen die folgende E-Mail:


    To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII…
----END X509 CERTIFICATE-----

    Der Administrator von enigma sendet die folgende E-Mail:


    To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII
…
-----END X509 CERTIFICATE-----

  2. Fügen Sie das per E-Mail gesendete Zertifikat auf beiden Systemen zur lokalen publickeys-Datenbank hinzu. 


    # ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

Die Authentifizierungsmethode für die RSA-Verschlüsselung verbirgt Identitäten in IKE vor möglichen Lauschangriffen. Da die rsa_encrypt-Methode die Identität des Peers verbirgt, kann IKE das Zertifikat des Peers nicht abrufen. Aus diesem Grund erfordert die rsa_encrypt-Methode, dass die IKE-Peers die PublicKeys des jeweils anderen Systems kennen.

Wenn Sie den auth_method rsa_encrypt in der /etc/inet/ike/config-Datei angeben, müssen Sie das Zertifikat des Peers zur publickeys-Datenbank hinzufügen. Die publickeys-Datenbank enthält dann drei Zertifikate für jedes kommunizierenden Systempaar:

Fehlerbehebung – Die IKE-Nutzlast, zu der auch die drei Zertifikate gehören, könnte zu groß werden, so dass eine Verschlüsselung durch rsa_encrypt nicht mehr möglich ist. Fehlermeldungen wie „Autorisierung fehlgeschlagen“ und „Fehlerhafte Nutzlast“ deuten darauf hin, dass die rsa_encrypt-Methode nicht die gesamte Nutzlast verschlüsseln konnte. Reduzieren Sie die Nutzlastgröße mit einer Methode wie z. B. rsa_sig, die nur zwei Zertifikate erfordert.

ProcedureSo erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware

Das Erzeugen von PublicKey-Zertifikaten und das Speichern dieser Zertifikate auf angehängter Hardware ähnelt dem Erzeugen von PublicKey-Zertifikaten und dem Speichern dieser Zertifikate auf Ihrem System. Auf der Hardware müssen die Befehle ikecert certlocal und ikecert certdb die Hardware identifizieren. Die Option -T mit der Token-ID identifiziert die Hardware gegenüber den Befehlen.

Bevor Sie beginnen

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Erzeugen Sie ein selbst-signiertes Zertifikat oder eine Zertifikat-Anforderung, und geben Sie die Token-ID an.

    Wählen Sie eine der folgenden Optionen:

    Hinweis –

    Für RSA unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu 2048 Bit. Für DSA unterstützt dieses Board Schlüssel bis zu 1024 Bit.

    • Bei einem selbst-signiertem Zertifikate verwenden Sie die folgende Syntax.


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

      Das Argument für die Option -T ist die Token-ID des angehängten Sun Crypto Accelerator 4000-Boards.

    • Bei einer Zertifikat-Anforderung verwenden Sie die folgende Syntax.


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

    Eine Beschreibung der Argumente für den Befehl ikecert finden Sie in der Manpage ikecert(1M).

  3. Geben Sie an der Eingabeaufforderung für eine PIN den Sun Crypto Accelerator 4000-Benutzer, einen Doppelpunkt und das Passwort des Benutzers ein.

    Hat das Sun Crypto Accelerator 4000-Board beispielsweise den Benutzer ikemgr, dessen Passwort rgm4tigt lautet, geben Sie Folgendes ein:


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
    Hinweis –

    Die PIN-Antwort wird auf dem Datenträger als Reintext gespeichert.

    Nachdem Sie das Passwort eingegeben haben, druckt das Zertifikat Folgendes:


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

  4. Senden Sie Ihr Zertifikat an die andere Partei.

    Wählen Sie eine der folgenden Optionen:

    • Senden Sie das selbst-signierte Zertifikat an das remote System.

      Sie können das Zertifikat in eine E-Mail einfügen.

    • Senden Sie die Zertifikat-Anforderung an eine Organisation, die PKI verarbeitet.

      Folgen Sie den Anweisungen der PKI-Organisation zur Übermittlung der Zertifikat-Anforderung. Ausführliche Anweisungen finden Sie in Schritt 3 unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

  5. Ändern Sie auf Ihrem System die Datei /etc/inet/ike/config, so dass die Zertifikate erkannt werden.

    Wählen Sie eine der folgenden Optionen.

    • Selbst-signiertes Zertifikat

      Verwenden Sie die vom Administrator des remoten Systems bereitgestellten Werte für die Parameter cert_trust, remote_id und remote_addr. Auf dem System enigma enthält die ike/config-Datei Folgendes:


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name


# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    • Zertifikat-Anforderung

      Geben Sie den von der PKI-Organisation bereitgestellten Namen als Wert für das Schlüsselwort cert_root ein. Die Datei ike/config könnte auf dem System enigma wie folgt aussehen:


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

  6. Speichern Sie die Zertifikate der anderen Partei auf der angehängten Hardware.

    Antworten Sie auf die PIN-Anforderung, wie Sie in Schritt 3 geantwortet haben.

    Hinweis –

    Sie müssen die PublicKey-Zertifikate auf der angehängten Hardware speichern, die Ihren PrivateKey erstellt hat.

    • Selbst-signiertes Zertifikat.

      Fügen Sie das selbst-signierte Zertifikat des remoten Systems hinzu. In diesem Beispiel wird das Zertifikat in der Datei DCA.ACCEL.STOR.CERT gespeichert.


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password

      Wenn das selbst-signierte Zertifikat rsa_encrypt als Wert für den Parameter auth_method verwendet, fügen Sie das Zertifikat des Peers zum Hardwarespeicher hinzu.

    • Zertifikate von einer PKI-Organisation.

      Fügen Sie die von der Organisation als Antwort auf Ihre Zertifikate-Anforderung erzeugten Zertifikate und die Zertifikatsautorität (CA) hinzu.


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT
Enter PIN for PKCS#11 token: Type user:password

      Informationen zum Hinzufügen der Zertifikat-Rücknahmeliste (CRL) von der PKI-Organisation finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

ProcedureSo verarbeiten Sie eine Zertifikat-Rücknahmeliste

Eine Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) enthält veraltete und sicherheitsgefährdete Zertifikate einer Zertifikatsautorität. Es gibt vier Möglichkeiten, CRLs zu verarbeiten.

Im folgenden Verfahren wird beschrieben, wie Sie IKE anweisen, CRLs von einem zentralen Verteilungspunkt aus zu verwenden.

  1. Zeigen Sie die von der CA empfangenen Zertifikate an.


    # ikecert certdb -lv certspec
    -l

    Listet die Zertifikate in der IKE-Zertifikatsdatenbank auf.

    -v

    Listet die Zertifikate im ausführlichen Modus auf. Verwenden Sie diese Option nur nach sorgfältigen Überlegungen.

    certspec

    Ein Muster, das Entsprechungen für ein Zertifikat in der IKE-Zertifikatsdatenbank findet.

    Das folgende Zertifikat wurde beispielsweise von Sun Microsystems herausgegeben. Bestimmte Einzelheiten wurden geändert.


    # ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A…A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

    Beachten Sie den Eintrag CRL Distribution Points. Der URI-Eintrag kennzeichnet, dass die CRL dieser Organisation im Web verfügbar ist. Der DN-Eintrag gibt an, dass die CRL auf einem LDAP-Server zur Verfügung steht. Nachdem IKE einmal auf die CRL zugegriffen hat, wird sie zur weiteren Verwendung zwischengespeichert.

    Um auf die CRL zuzugreifen, müssen Sie einen Verteilungspunkt erreichen.

  2. Wählen Sie eine der folgenden Methoden, um auf die CRL an einem zentralen Verteilungspunkt zuzugreifen.

    • Mithilfe des URI.

      Fügen Sie das Schlüsselwort use_http zur Datei /etc/inet/ike/config des Hosts hinzu. Die Datei ike/config ähnelt dann Folgendem:


      # Use CRL from organization's URI
use_http
…

    • Mithilfe eines Web-Proxy.

      Fügen Sie das Schlüsselwort proxy zur ike/config-Datei hinzu. Das Schlüsselwort proxy akzeptiert eine URL als Argument, wie in dem folgenden Beispiel:


      # Use own web proxy
proxy "http://proxy1:8080"

    • Mithilfe eines LDAP-Servers.

      Geben Sie den LDAP-Server als Argument für das Schlüsselwort ldap-list in die /etc/inet/ike/config-Datei des Hosts ein. Ihre Organisation stellt den Namen des LDAP-Servers zur Verfügung. Der Eintrag in der ike/config-Datei würde Folgendem ähneln:


      # Use CRL from organization's LDAP
ldap-list "ldap1.sun.com:389,ldap2.sun.com"
…

    IKE ruft die CRL ab und speichert die CRL zwischen, bis das Zertifikat abgelaufen ist.

Beispiel 23–7 Einfügen einer CRL in die lokale certrldb-Datenbank

Wenn die CRL einer PKI-Organisation nicht an einem zentralen Verteilungspunkt zur Verfügung steht, können Sie die CRL der zur lokalen certrldb-Datenbank manuell hinzufügen. Folgen Sie den Anweisungen der PKI-Organisation zum Extrahieren der CRL in eine Datei, dann fügen Sie die CRL mit dem Befehl ikecert certrldb -a zur Datenbank hinzu.


# ikecert certrldb -a < Sun.Cert.CRL

Konfiguration von IKE für mobile Systeme (Übersicht der Schritte)

Die folgende Tabelle enthält Verweise auf Verfahren, in denen beschrieben wird, wie IKE so konfiguriert wird, dass Systeme verarbeitet werden können, die sich remote bei einem zentralen Standort anmelden.

Aufgabe 

Beschreibung 

Siehe 

Kommunizieren mit einem zentralen Standort von einem Offsite-Standort 

Ermöglichen Sie es Offsite-Systemen, mit einem zentralen Standort zu kommunizieren. Bei Offsite-Systemen kann es sich um mobile Systeme handeln. 

So konfigurieren Sie IKE für Offsite-Systeme

Verwenden eines Root-Zertifikat und IKE auf einem zentralen System, das Datenverkehr von mobilen Systemen akzeptiert 

Konfigurieren Sie ein Gateway-Systems, so dass es IPsec-Verkehr von einem System akzeptiert, das nicht über eine feststehende IP-Adresse verfügt. 

Beispiel 23–8

Verwenden eines Root-Zertifikat und IKE auf einem System, das nicht über eine feststehende IP-Adresse verfügt 

Konfigurieren Sie ein mobiles System, um seinen Datenverkehr mit einem zentralen Standort, z. B. das Unternehmenshauptbüro zu schützen. 

Beispiel 23–9

Verwenden von selbst-signierten Zertifikaten und IKE auf einem zentralen System, das Datenverkehr von mobilen Systemen akzeptiert 

Konfigurieren Sie ein Gateway-System mit selbst-signierten Zertifikaten, so dass es von IPsec-Verkehr von einem mobilen System akzeptiert. 

Beispiel 23–10

Verwenden von selbst-signierten Zertifikaten und IKE auf einem System, das nicht über eine feststehende IP-Adresse verfügt 

Konfigurieren Sie ein mobilen System mit selbst-signierten Zertifikaten, so dass sein Verkehr mit einem zentralen Standort geschützt wird. 

Beispiel 23–11

Konfiguration von IKE für mobile Systeme

Wenn Heimbüros und mobile Laptops ordnungsgemäß konfiguriert wurden, können IPsec und IKE die Kommunikation mit den Computern am Unternehmenssitz schützen. Eine umfassende IPsec-Richtlinie, kombiniert mit einer PublicKey-Authentifizierungsmethode, bietet Offsite-Systemen die Möglichkeit, ihren Datenverkehr mit einem zentralen System zu schützen.

ProcedureSo konfigurieren Sie IKE für Offsite-Systeme

IPsec und IKE erfordern eine einmalige ID, um Quelle und Ziel eindeutig identifizieren zu können. Bei offsite oder mobilen Systemen, die nicht über eine einmalige IP-Adresse verfügen, müssen Sie einen anderen ID-Typ verwenden. Beispielsweise kann ein System eindeutig mit ID-Typen wie DNS, DN oder E-Mail identifiziert werden.

Offsite oder mobile Systeme, die über einmalige IP-Adressen verfügen, werden dennoch besser mit einem anderen ID-Typ konfiguriert. Wenn die Systeme z. B. versuchen, über eine NAT-Box eine Verbindung mit einem zentralen Standort herzustellen, werden deren einmalige Adressen nicht verwendet. Eine NAT-Box weist eine zufällige IP-Adresse zu, die das zentrale System nicht erkennen würde.

PresharedKeys können ebenfalls nicht als Authentifizierungsmechanismus für mobile Systeme eingesetzt werden, da sie feststehende IP-Adressen benötigen. Selbst-signierte Zertifikate oder Zertifikate von einer PKI ermöglichen mobilen Systemen jedoch die Kommunikation mit einem zentralen Standort.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Konfigurieren Sie das zentrale System, so dass es mobile Systeme erkennt.

    1. Richten Sie die /etc/hosts-Datei ein.

      Das zentrale System muss bestimmte Adressen für mobile Systeme nicht erkennen.


      # /etc/hosts on central
central 192.xxx.xxx.x

    2. Richten Sie die ipsecinit.conf-Datei ein.

      Das zentrale System benötigt eine Richtlinie, die einen breiten Bereich an IP-Adressen zulässt. Später stellen Zertifikate in der IKE-Richtlinie sicher, dass Systeme, die eine Verbindung herzustellen versuchen, hierzu berechtigt sind.


      # /etc/inet/ipsecinit.conf on central
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. Richten Sie die ike.config-Datei ein.

      DNS identifiziert das zentrale System. Zur Authentifizierung des Systems werden Zertifikate verwendet.


      ## /etc/inet/ike/ike.config on central
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# List self-signed certificates - trust server and enumerated others
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=root@central.domain.org"
#cert_trust    "email=user1@mobile.domain.org"
#

# Rule for mobile systems with certificate
{
  label "Mobile systems with certificate"
  local_id_type DNS

# Any mobile system who knows my DNS or IP can find me.

  local_id "central.domain.org"
  local_addr 192.xxx.xxx.x

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  3. Melden Sie sich bei jedem mobilen System an und konfigurieren Sie das System so, dass es das zentrale System findet.

    1. Richten Sie die /etc/hosts-Datei ein.

      Die /etc/hosts-Datei benötigt keine Adresse für das mobile System, kann aber eine bereitstellen. Die Datei muss eine öffentliche IP-Adresse für das zentrale System enthalten.


      # /etc/hosts on mobile
mobile 10.x.x.xx
central 192.xxx.xxx.x

    2. Richten Sie die ipsecinit.conf-Datei ein.

      Das mobile System muss das zentrale System über die öffentliche IP-Adresse finden können. Die Systeme müssen mit der gleichen IPsec-Richtlinie konfiguriert sein.


      # /etc/inet/ipsecinit.conf on mobile
# Find central
{raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. Richten Sie die ike.config-Datei ein.

      Als Bezeichner darf keine IP-Adresse verwendet werden. Für mobile Systeme sind die folgenden Bezeichner gültig:

      • DN=ldap-Verzeichnisname

      • DNS=Adresse-des-Domänennamenservers

      • email=E-Mail-Adresse

      Zur Authentifizierung des mobilen Systems werden Zertifikate verwendet.


      ## /etc/inet/ike/ike.config on mobile
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# Self-signed certificates - trust me and enumerated others
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=user1@domain.org"
#cert_trust    "email=root@central.domain.org"
#
# Rule for off-site systems with root certificate
{
	label "Off-site mobile with certificate"
	local_id_type DNS

# NAT-T can translate local_addr into any public IP address
# central knows me by my DNS

	local_id "mobile.domain.org"
	local_addr 0.0.0.0/0

# Find central and trust the root certificate
	remote_id "central.domain.org"
	remote_addr 192.xxx.xxx.x

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  4. Lesen Sie die IKE-Konfiguration in den Systemkern ein.

    • Wenn Sie mit mindestens Solaris 10 4/09 arbeiten, aktivieren Sie den ike-Service.


      # svcadm enable svc:/network/ipsec/ike

    • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, muss das System neu gestartet werden.


      # init 6

      Alternativ stoppen und starten Sie den in.iked-Daemon.

Beispiel 23–8 Konfiguration eines zentralen Computers zum Akzeptieren von IPsec-Verkehr von einem mobilen System

IKE kann Aushandlungen hinter einer NAT-Box initiieren. Das ideale Setup für IKE sieht jedoch keine zwischengeschaltete NAT-Box vor. Im folgenden Beispiel wurden die Root-Zertifikate von einer CA ausgegeben und auf dem mobilen und dem zentralen System eingepflegt. Ein zentrales System akzeptiert IPsec-Aushandlungen von einem System hinter einer NAT-Box. main1 ist ein Unternehmenssystem, das Verbindungen von Offsite-Systemen akzeptiert. Informationen zum Einrichten von Offsite-Systemen finden Sie in Beispiel 23–9.


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}
Beispiel 23–9 Konfiguration eines Systems hinter einer NAT-Box mit IPsec

Im folgenden Beispiel wurden die Root-Zertifikate von einer CA ausgegeben und auf dem mobilen sowie auf dem zentralen System eingepflegt. mobile1 stellt von zu Hause aus eine Verbindung mit dem Unternehmenshauptsitz her. Das Internet Service-Providers (ISP)-Netzwerk verwendet eine NAT-Box, damit der ISP mobile1 eine private Adresse zuordnen kann. Die NAT-Box übersetzt die private Adresse dann in eine öffentliche IP-Adresse, die gemeinsam mit anderen ISP-Netzwerkknoten genutzt wird. Das Hauptbüro des Unternehmens befindet sich nicht hinter einer NAT-Box. Informationen zur Einrichtung des Computers in der Unternehmenszentrale finden Sie unter Beispiel 23–8.


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
Beispiel 23–10 Akzeptieren selbst-signierter Zertifikate von einem mobilen System

Im folgenden Beispiel wurden selbst-signierte Zertifikate ausgegeben, die sich auf dem mobilen und auf dem zentralen System befinden. main1 ist ein Unternehmenssystem, das Verbindungen von Offsite-Systemen akzeptiert. Wie Sie die Offsite-Systeme einrichten, erfahren Sie in Beispiel 23–11.


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
Beispiel 23–11 Verwenden von selbst-signierten Zertifikaten zum Aufnehmen einer Verbindung mit einem zentralen System

Im folgenden Beispiel versucht mobile1, eine Verbindung von zu Hause aus mit dem Hauptbüro des Unternehmens herzustellen. Die Zertifikate wurden ausgegeben und befinden sich auf dem mobilen und auf dem zentralen System. Das ISP-Netzwerk verwendet eine NAT-Box, damit der ISP mobile1 eine private Adresse zuordnen kann. Die NAT-Box übersetzt die private Adresse dann in eine öffentliche IP-Adresse, die gemeinsam mit anderen ISP-Netzwerkknoten genutzt wird. Das Hauptbüro des Unternehmens befindet sich nicht hinter einer NAT-Box. Informationen zum Einrichten der Computer am Unternehmenshauptsitz finden Sie in Beispiel 23–10.


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte)

In der folgenden Tabelle wird auf Verfahren verwiesen, in denen beschrieben wird, wie IKE über angehängte Hardware informiert wird. IKE muss über angehängte Hardware informiert sein, bevor IKE die Hardware verwenden kann. Um die Hardware zu verwenden, folgen Sie den Hardware-Verfahren unter Konfiguration von IKE mit PublicKey-Zertifikaten.

Hinweis –

Sie müssen IKE nicht über On-Chip-Hardware informieren. Der UltraSPARC® T2-Prozessor beinhaltet beispielsweise kryptografische Beschleunigung. Sie müssen IKE nicht konfigurieren, damit die On-Chip-Accelerators gefunden werden.

Aufgabe 

Beschreibung 

Siehe 

Übertragen der IKE-Schlüsselvorgänge auf das Sun Crypto Accelerator 1000-Board 

Verbinden Sie IKE mit der PKCS&;#11-Bibliothek. 

So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board

Übertragen der IKE-Schlüsselvorgänge auf das Sun Crypto Accelerator 4000-Board und speichern der Schlüssel auf dem Board 

Verbinden Sie IKE mit der PKCS&;#11-Bibliothek und listen Sie die Namen der angehängten Hardware auf. 

So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board

Konfiguration von IKE zum Suchen angehängter Hardware

Public Key-Zertifikate können auch auf angehängter Hardware gespeichert werden. Das Sun Crypto Accelerator 1000-Board stellt nur Speicherkapazität zur Verfügung. Das Sun Crypto Accelerator 4000- und Sun Crypto Accelerator 6000-Board bietet Speicherkapazität und ermöglicht das Abgeben von Public Key-Vorgängen vom System auf das Board.

ProcedureSo konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board

Bevor Sie beginnen

Bei dem folgenden Verfahren wird davon ausgegangen, dass ein Sun Crypto Accelerator 1000-Board an das System angehängt ist. Außerdem muss die Software für das Board installiert und konfiguriert sein. Anweisungen finden Sie im Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Prüfen Sie, ob die PKCS&;#11-Bibliothek verlinkt ist.

    Geben Sie den folgenden Befehl ein, um festzustellen, ob eine PKCS&;#11-Bibliothek verlinkt ist:


    # ikeadm get stats
Phase 1 SA counts:
Current:   initiator:          0   responder:          0
Total:     initiator:          0   responder:          0
Attempted: initiator:          0   responder:          0
Failed:    initiator:          0   responder:          0
           initiator fails include 0 time-out(s)
PKCS#11 library linked in from /usr/lib/libpkcs11.so
#

  3. Solaris 10 1/06: Ab diesem Release können Sie Schlüssel im Softtoken-Schlüsselspeicher speichern.

    Informationen zum Schlüsselspeicher, der über das Solaris Cryptographic Framework bereitgestellt wird, finden Sie in der Manpage cryptoadm(1M) Ein Beispiel zur Verwendung des Schlüsselspeichers finden Sie in Example 23–12.

ProcedureSo konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board

Bevor Sie beginnen

Bei dem folgenden Verfahren wird davon ausgegangen, dass ein Sun Crypto Accelerator 4000-Board an das System angehängt ist. Außerdem muss die Software für das Board installiert und konfiguriert sein. Anweisungen finden Sie im Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.

Falls Sie ein Sun Crypto Accelerator 6000-Board verwenden, lesen Sie den Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide , um Anweisungen zu erhalten.

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Prüfen Sie, ob die PKCS&;#11-Bibliothek verlinkt ist.

    IKE verarbeitet die Schlüsselerzeugung und -speicherung auf dem Sun Crypto Accelerator 4000-Board mithilfe der Programmroutinen der Bibliothek. Geben Sie den folgenden Befehl ein, um festzustellen, ob eine PKCS&;#11-Bibliothek verlinkt ist:


    $ ikeadm get stats
…
PKCS#11 library linked in from /usr/lib/libpkcs11.so
$
    Hinweis –

    Für RSA unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu 2048 Bit. Für DSA unterstützt dieses Board Schlüssel bis zu 1024 Bit.

  3. Suchen Sie die Token-ID für das angehängte Sun Crypto Accelerator 4000-Board.


    $ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                     "

    Die Bibliothek gibt eine Token-ID mit 32 Zeichen zurück. Die Token-ID wird auch als Schlüsselspeichername bezeichnet. In diesem Beispiel können Sie das Token Sun Metaslot mit den ikecert-Befehlen zum Speichern und Beschleunigen der IKE-Schlüssel verwenden.

    Anweisungen zum Arbeiten mit dem Token finden Sie unter So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware.

    Die einführenden Leerzeichen werden von dem Befehl ikecert automatisch aufgefüllt.

Beispiel 23–12 Suchen und Verwenden von Metaslot-Token

Token können auf einem Datenträger, auf einem angehängten Board oder im Softtoken-Schlüsselspeicher des Solaris Encryption Framework gespeichert werden. Die Token-ID des Softtoken-Schlüsselspeichers könnte wie folgt aussehen:


$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

Informationen zum Erstellen eines Passwortsatzes für den Softtoken-Schlüsselspeicher finden Sie in der Manpage pktool(1).

Mit einem Befehl ähnlich dem Folgenden fügen Sie das Zertifikat zum Softtoken-Schlüsselspeicher hinzu. Sun.Metaslot.cert ist eine Datei mit dem CA-Zertifikat.


# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Ändern der IKE-Übertragungsparameter (Übersicht der Schritte)

In der folgenden Tabelle wird auf Verfahren zur Konfiguration der Übertragungsparameter verwiesen.

Aufgabe 

Beschreibung 

Siehe 

Schlüsselaushandlungen effizienter gestalten 

Ändern Sie die Parameter zur Schlüsselaushandlung. 

So ändern Sie die Dauer der Phase 1 IKE-Schlüsselaushandlung

Konfiguration der Schlüsselaushandlung, um Verzögerungen bei der Übertragung zu gestatten 

Verlängern Sie die Parameter zur Schlüsselaushandlung. 

Beispiel 23–13

Konfiguration der Schlüsselaushandlung, so dass sie schnell zum Erfolg führt oder schnell einen Fehler anzeigt 

Verkürzen Sie die Parameter zur Schlüsselaushandlung. 

Beispiel 23–14

Ändern der IKE-Übertragungsparameter

Wenn IKE Schlüssel aushandelt, wirkt sich die Übertragungsgeschwindigkeit auf den Erfolg der Aushandlung aus. Normalerweise müssen Sie die Standardwerte für die IKE-Übertragungsparameter nicht ändern. Eventuell müssen die Übertragungswerte jedoch geändert werden, um die Schlüsselaushandlung bei extrem frequentierten Leitungen zu optimieren oder um ein Problem zu reproduzieren.

Bei einer längeren Aushandlung kann IKE die Schlüssel aus über unzuverlässige Übertragungsleitungen aushandeln. Sie verlängern bestimmte Parameter, so dass schon die ersten Versuche erfolgreich sind. Wenn der erste Versuch nicht erfolgreich ist, können Sie nachfolgenden Versuchen mehr Zeit gewähren, damit sie erfolgreich abgeschlossen werden.

Bei einer kürzeren Dauer können Sie von den Vorteilen zuverlässiger Übertragungsleitungen profitieren. Sie können schneller einen Wiederholversuch bei fehlgeschlagenen Aushandlungen einleiten, um so die Aushandlung insgesamt zu beschleunigen. Bei der Suche nach der Ursache eines Problems können Sie auch die Aushandlung beschleunigen, um schnell einen Fehler zu erzeugen. Eine kürzere Aushandlung bedeutet auch, dass die Phase 1 SAs über deren gesamte Lebendauer genutzt werden können.

ProcedureSo ändern Sie die Dauer der Phase 1 IKE-Schlüsselaushandlung

  1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

    Hinweis –

    Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

  2. Ändern Sie die Standardwerte der globalen Übertragungsparameter auf jedem System.

    Ändern Sie die Phase 1 Parameter für die Aushandlungsdauer in der Datei /etc/inet/ike/config auf jedem System.


    ### ike/config file on system

## Global parameters
#
## Phase 1 transform defaults
#
#expire_timer      300
#retry_limit         5
#retry_timer_init    0.5 (integer or float)
#retry_timer_max    30   (integer or float)
    expire_timer

    Die Zeit in Sekunden, die eine noch nicht abgeschlossene IKE Phase I-Aushandlung weiter ausgeführt werden darf, bis der Aushandlungsversuch gelöscht wird. Standardmäßig werden die Versuche über 30 Sekunden ausgeführt.

    retry_limit

    Die Anzahl an wiederholten Übertragungen, bevor die IKE-Aushandlung abgebrochen wird. Standardmäßig versucht IKE fünf Übertragungen.

    retry_timer_init

    Das Erstintervall zwischen den Übertragungsversuchen. Dieses Intervall wird verdoppelt, bis der Wert von retry_timer_max erreicht ist. Das Erstintervall beträgt 0,5 Sekunden.

    retry_timer_max

    Das maximale Intervall zwischen den Übertragungsversuchen. Das Intervall für die Übertragungsversuche wächst bis zu diesem Wert an. Standardmäßig beträgt der Grenzwert 30 Sekunden.

  3. Lesen Sie die geänderte Konfiguration in den Systemkern ein.

    • Wenn Sie mindestens mit Solaris 10 4/09 arbeiten, aktualisieren Sie den ike-Service.


      # svcadm refresh svc:/network/ipsec/ike

    • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, starten Sie das System neu.


      # init 6

      Alternativ stoppen und starten Sie den in.iked-Daemon.

Beispiel 23–13 Verlängern der IKE Phase 1-Aushandlungszeiten

Im folgenden Beispiel ist ein System über eine stark frequentierte Übertragungsleitung mit seinem Peer verbunden. Die ursprünglichen Einstellungen in der Datei sind mit Kommentarzeichen versehen. Die neuen Einstellungen verlängern die Aushandlungszeit.


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180
Beispiel 23–14 Verkürzen der IKE Phase 1-Aushandlungszeiten

Im folgenden Beispiel ist ein System über eine Hochgeschwindigkeitsleitung mit wenig Verkehr mit seinem Peer verbunden. Die ursprünglichen Einstellungen in der Datei sind mit Kommentarzeichen versehen. Die neuen Einstellungen verkürzen die Aushandlungszeit.


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20

Kapitel 24 Internet Key Exchange (Referenz)

Dieses Kapitel enthält die folgenden Referenzinformationen zum IKE:

Informationen zur Implementierung von IKE finden Sie in Kapitel 23Konfiguration von IKE (Aufgaben). Eine Einführung in IKE finden Sie in Kapitel 22Internet Key Exchange (Übersicht).

IKE Service Management Facility

svc:/network/ipsec/ike:default -Service – Die Service Management Facility (SMF) stellt zur IKE-Verwaltung den ike-Service zur Verfügung. Dieser Service ist standardmäßig deaktiviert. Vor der Aktivierung dieses Service müssen Sie eine IKE-Konfigurationsdatei (/etc/inet/ike/config) erstellen.

Die folgenden Eigenschaften des ike-Service können konfiguriert werden:

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

IKE-Daemon

Der in.iked-Daemon automatisiert die Verwaltung der kryptografischen Schlüssel für IPsec auf einem Solaris-System. Der Daemon führt die Aushandlung mit einem remoten System aus, auf dem das gleiche Protokoll ausgeführt wird, um auf sichere Weise authentifiziertes Schlüsselmaterial für Sicherheitszuordnungen (SAs) bereitzustellen. Der Daemon muss auf allen Systemen ausgeführt werden, die sicher miteinander kommunizieren sollen.

Standardmäßig ist der svc:/network/ipsec/ike:default-Service nicht aktiviert. Nach der Konfiguration der /etc/inet/ike/config-Datei und der Aktivierung des ike-Service wird der in.iked-Daemon beim Booten des Systems ausgeführt.

Wenn der IKE-Daemon ausgeführt wird, authentifiziert sich das System gegenüber seiner IKE-Peer-Entität in der Phase 1 Exchange. Der Peer ist, ebenso wie die zu verwendenden Authentifizierungsmethoden, in der IKE-Richtliniendatei definiert. Als Nächstes richtet der Daemon dann die Schlüssel für den Phase 2 Exchange ein. Die IKE-Schlüssel werden in einem in der Richtliniendatei festgelegten Intervall automatisch aktualisiert. Der in.iked-Daemon empfängt eingehende IKE-Anforderungen aus dem Netzwerk und Anforderungen nach abgehendem Verkehr über den PF_KEY-Socket. Weitere Informationen finden Sie in der Manpage pf_key(7P).

Der IKE-Daemon unterstützt zwei Befehle. Der ikeadm-Befehl kann zur Anzeige und vorübergehenden Änderung der IKE-Richtlinie verwendet werden. Wenn Sie die IKE-Richtlinie dauerhaft ändern möchten, müssen Sie die Eigenschaften des ike-Service bearbeiten. Die Verfahrensweise wird unter So rufen Sie IKE PresharedKeys auf erläutert.

Mit dem Befehl ikecert können Sie die PublicKey-Datenbanken anzeigen und pflegen. Dieser Befehl dient zum Verwalten der lokalen Datenbanken ike.privatekeys und publickeys . Darüber hinaus werden mit diesem Befehl die PublicKey-Vorgänge durchgeführt und die PublicKeys auf der angehängten Hardware gespeichert.

IKE-Richtliniendatei

Die Konfigurationsdatei für die IKE-Richtlinie, /etc/inet/ike/config, verwaltet die Schlüssel für die Schnittstellen, die in der IPsec-Richtliniendatei, /etc/inet/ipsecinit.conf, geschützt sind. Die IKE-Richtliniendatei verwaltet die Schlüssel für IKE und für die IPsec SAs. Der IKE-Daemon selbst erfordert Schlüsselmaterial in Phase 1 Exchange.

Das Schlüsselmanagement mit IKE baut auf Regeln und globale Parameter. Eine IKE-Regel identifiziert die Systeme oder Netzwerke, die das Schlüsselmaterial sichert, und gibt die Authentifizierungsmethode an. Globale Parameter enthalten Objekte wie den Pfad zu einem angehängten Hardwarebeschleuniger. Beispiele für IKE-Richtliniendateien finden Sie unter Konfiguration von IKE mit PresharedKeys (Übersicht der Schritte). Beispiele und Beschreibungen der IKE-Richtlinieneinträge finden Sie in der Manpage ike.config(4).

Die von IKE unterstützten IPsec SAs schützen die IP-Datagramme gemäß den Richtlinien, die in der Konfigurationsdatei für die IPsec-Richtlinie, /etc/inet/ipsecinit.conf, aufgestellt wurden. Die IKE-Richtliniendatei legt fest, ob Perfect Forward Security (PFS) beim Erstellen der IPsec SAs verwendet werden soll.

Die Datei ike/config kann den Pfad zu einer Bibliothek enthalten, die gemäß dem Standard RSA Security Inc. PKCS&;#11 Cryptographic Token Interface (Cryptoki) implementiert wird. IKE verwendet diese PKCS&;#11-Bibliothek für den Zugriff auf Hardware zur Schlüsselbeschleunigung und -speicherung.

Die Sicherheitsaspekte für die ike/config-Datei entsprechend denen für die ipsecinit.conf-Datei. Ausführliche Informationen finden Sie im Abschnitt Sicherheitsbetrachtungen für ipsecinit.conf und ipsecconf.

IKE-Verwaltungsbefehl

Mit dem ikeadm-Befehl können Sie Folgendes auszuführen:

Beispiele und eine vollständige Beschreibung der Optionen dieses Befehls finden Sie in der Manpage ikeadm(1M)

Je nach Privilegstufe des ausgeführten IKE-Daemons können verschiedene Aspekte des Daemons angezeigt und geändert werden. Es werden drei Privilegstufen unterschieden.

base-Stufe

Sie können das Schlüsselmaterial weder anzeigen noch ändern. Base ist die Standard-Privilegstufe.

modkeys-Stufe

Sie können PresharedKeys entfernen, ändern und hinzufügen.

keymat-Stufe

Sie können das tatsächliche Schlüsselmaterial mit dem Befehl ikeadm anzeigen.

Wenn Sie die Privilegstufe nur vorübergehend ändern möchten, können Sie den ikeadm-Befehl verwenden. Wenn die Änderung dauerhaft erfolgen soll, ändern Sie die admin_privilege-Eigenschaft des ike-Service. Die Verfahrensweise wird unter Verwalten von IKE- und IPsec-Services.

Die Sicherheitsaspekte für den ikeadm-Befehl entsprechen denen für den ipseckey-Befehl. Ausführliche Informationen finden Sie unter Sicherheitsbetrachtungen für ipseckey.

IKE PresharedKeys-Dateien

Wenn Sie PresharedKeys manuell erstellen, werden die Schlüssel in Dateien im Verzeichnis /etc/inet/secret gespeichert. Die Datei ike.preshared enthält die PresharedKeys für die Internet Security Association and Key Management Protocol (ISAKMP) SAs. Die Datei ipseckeys enthält die PresharedKeys für die IPsec SAs. Die Dateien sind mit 0600 geschützt. Das Verzeichnis secret ist mit 0700 geschützt.

Hinweis –

PresharedKeys können die Vorteile der Hardware-Speicherung nicht nutzen. PresharedKeys werden vom System erzeugt und im System gespeichert.

IKE PublicKey-Datenbanken und -Befehle

Mit dem Befehl ikecert können Sie die PublicKey-Datenbanken des lokalen Systems bearbeiten. Sie verwenden diesen Befehl, wenn die Datei ike/config PublicKey-Zertifikate erfordert. Da IKE diese Datenbanken zur Authentifizierung der Phase 1 Exchange benötigt, müssen sie schon gefüllt sein, bevor der in.iked-Daemon aktiviert wird. Jede der drei Datenbanken verarbeitet drei Unterbefehle: certlocal, certdb und certrldb.

Mit dem Befehl ikecert wird auch die Schlüsselspeicherung verwaltet. Schlüssel können auf einem Datenträger, auf einem angehängten Sun Crypto Accelerator 6000- oder Sun Crypto Accelerator 4000-Board oder in einem Softtoken-Schlüsselspeicher gespeichert werden. Der Softtoken-Schlüsselspeicher ist verfügbar, wenn der Metaslot im Solaris Cryptographic Framework zur Kommunikation mit dem Hardware-Gerät verwendet wird. Der Befehl ikecert verwendet die PKCS&;#11-Bibliothek zum Lokalisieren des Schlüsselspeichers.

Weitere Informationen finden Sie in der Manpage ikecert(1M) Informationen zum Metaslot und dem Softtoken-Schlüsselspeicher finden Sie in der Manpage cryptoadm(1M).

ikecert tokens-Befehl

Das Argument Tokens führt die verfügbaren Token-IDs auf. Mit Token-IDs können die Befehle ikecert certlocal und ikecert certdb PublicKey-Zertifikate und Zertifikat-Anforderungen erstellen. Die Zertifikate und Zertifikat-Anforderungen werden vom Cryptographic Framework im Softtoken-Schlüsselspeicher oder auf dem angehängten Sun Crypto Accelerator 6000- oder Sun Crypto Accelerator 4000-Board gespeichert. Der Befehl ikecert verwendet die PKCS&;#11-Bibliothek zum Lokalisieren des Schlüsselspeichers.

ikecert certlocal-Befehl

Mit dem Unterbefehl certlocal wird die PrivateKey-Datenbanken verwaltet. Mit den Optionen dieses Unterbefehl können Sie PrivateKeys hinzufügen, anzeigen und entfernen. Mit diesem Unterbefehl wird auch entweder ein selbst-signiertes Zertifikat oder eine Zertifikat-Anforderung erstellt. Die Option -ks erstellt ein selbst-signiertes Zertifikat. Die Option -kc erstellt eine Zertifikat-Anforderung. Die Schlüssel werden auf dem System im Verzeichnis /etc/inet/secret/ike.privatekeys oder mit der Option -T auf der angehängten Hardware gespeichert.

Wenn Sie einen PrivateKey erstellen, müssen die Optionen für den Befehl ikecert certlocal entsprechende Einträge in der Datei ike/config aufweisen. Die Entsprechungen zwischen den ikecert-Optionen und den ike/config-Einträgen sind in der folgenden Tabelle aufgeführt.

Tabelle 24–1 Entsprechungen zwischen ikecert-Optionen undike/config-Einträgen

ikecert-Option

ike/config-Eintrag

Beschreibung 

-A Subjekt-Alternativname

cert_trust Subjekt-Alternativname

Ein Alias, der das Zertifikat eindeutig identifiziert. Mögliche Werte sind eine IP-Adresse, eine E-Mail-Adresse oder ein Domänenname. 

-D X.509-Distinguished-Name

X.509-Distinguished-Name

Der vollständige Name der Zertifikatsautorität, der das Land (C), den Namen der Organisation (ON), die Organisationseinheit (OU) und den allgemeinen Namen (CN) enthält. 

-t dsa-sha1

auth_method dss_sig

Eine Authentifizierungsmethode, die etwas langsamer als RSA ist.

-t rsa-md5 und

-t rsa-sha1

auth_method rsa_sig

Eine Authentifizierungsmethode, die etwas schneller als DSA ist.

Ein RSA-PublicKey muss groß genug sein, um die größte Nutzlast zu verschlüsseln. In der Regel ist eine Identität, zum Beispiel der X.509 Distinguished Name, die größte Nutzlast.

-t rsa-md5 und

-t rsa-sha1

auth_method rsa_encrypt

Die RSA-Verschlüsselung verbirgt Identitäten in IKE vor möglichen Mithörern, erfordert aber, dass IKE-Peers die PublicKeys des jeweils anderen Peers kennen. 

-T

pkcs11_path

Die PKCS #11-Bibliothek sorgt für Schlüsselbeschleunigung auf dem Sun Crypto Accelerator 1000-, Sun Crypto Accelerator 6000- und dem Sun Crypto Accelerator 4000- Board. Die Bibliothek stellt auch die Tokens zur Verfügung, die für die Schlüsselspeicherung auf den Sun Crypto Accelerator 6000- und Sun Crypto Accelerator 4000-Boards zuständig sind.

Wenn Sie mit dem Befehl ikecert certlocal -kc eine Zertifikat-Anforderung ausgeben, senden Sie die Ausgabe des Befehls an eine PKI-Organisation oder an eine Zertifikatsautorität (CA). Falls Ihr Unternehmen eine eigene PKI ausführt, senden Sie die Ausgabe des Befehls an Ihren PKI-Administrator. Die Zertifikate werden dann von der PKI-Organisation, der CA oder dem PKI-Administrator erstellt. Die von der PKI oder der CA zurückgegebenen Zertifikate dienen als Eingabe für den Unterbefehl certdb. Die von der PKI zurückgegebene Zertifikat-Rücknahmeliste (CRL) dient als Eingabe für den Unterbefehl certrldb.

ikecert certdb-Befehl

Mit dem Unterbefehl certdb wird die PublicKey-Datenbank verwaltet. Mit den Optionen dieses Unterbefehl zu können Sie Zertifikate und PublicKeys hinzufügen, anzeigen oder entfernen. Der Befehl akzeptiert Zertifikate, die mit dem Befehl ikecert certlocal -ks auf einem remoten System erzeugt wurden, als Eingabe. Verfahren hierzu finden Sie unter So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten. Darüber hinaus akzeptiert dieser Befehl ein Zertifikat als Eingabe, das Sie von einer PKI oder CA empfangen haben. Informationen hierzu finden Sie unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

Die Zertifikate und PublicKeys werden im Verzeichnis /etc/inet/ike/publickeys auf dem System gespeichert. Mit der Option -T werden die Zertifikate, PublicKeys und PrivateKeys auf der angehängten Hardware gespeichert.

ikecert certrldb-Befehl

Mit dem Unterbefehl certrldb wird die Datenbank der Zertifikat-Rücknahmeliste (CRL), /etc/inet/ike/crls, verwaltet. In der CRL-Datenbank werden die Rücknahmelisten für PublicKeys gepflegt. Hierbei handelt es sich um nicht mehr gültige Zertifikate. Wenn PKIs Ihnen eine CRL bereitstellt, können Sie sie mit dem Befehl ikecert certrldb in der CRL-Datenbank installieren. Verfahren hierzu finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

/etc/inet/ike/publickeys-Verzeichnis

Das /etc/inet/ike/publickeys-Verzeichnis enthält den öffentlichen Teil eines Paares aus Public und Private Key und dessen Zertifikat in Dateien oder Slots. Das Verzeichnis ist mit 0755 geschützt. Es wird mit dem Befehl ikecert certdb gefüllt. Mit dem Befehl -T werden die Schlüssel auf dem Sun Crypto Accelerator 6000- oder dem Sun Crypto Accelerator 4000-Board anstatt im publickeys-Verzeichnis gespeichert.

Die Slots enthalten den X.509 Distinguished Name eines von einem anderen System erzeugten Zertifikates in verschlüsselter Form. Wenn Sie selbst-signierte Zertifikate einsetzen, verwenden Sie das Zertifikat, das Sie vom Administrator des remoten Systems empfangen haben, als Eingabe für den Befehl. Wenn Sie Zertifikate von einer Zertifizierungsstelle verwenden, müssen Sie in dieser Datenbank zwei von der Zertifizierungsstelle signierte Zertifikate installieren. Sie installieren ein Zertifikat, dass auf der zur Zertifizierungsstelle gesendeten Zertifikatssignieranforderung basiert. Sie müssen auch das Zertifikat der Zertifizierungsstelle installieren.

/etc/inet/secret/ike.privatekeys-Verzeichnis

Das Verzeichnis /etc/inet/secret/ike.privatekeys enthält die PrivateKey-Dateien (Teil des PublicKey-PrivateKey-Paares), die das Schlüsselmaterial für die ISAKMP SAs darstellen. Das Verzeichnis ist mit 0700 geschützt. Das Verzeichnis ike.privatekeys wird mit dem Befehl ikecert certlocal gefüllt. PrivateKeys werden erst dann wirksam, wenn ihre PublicKey-Pendants, selbst-signierte Zertifikate oder CAs installiert sind. Die PublicKey-Pendants sind im Verzeichnis /etc/inet/ike/publickeys oder auf einem Sun Crypto Accelerator 6000- bzw. einem &sca 4;-Board gespeichert.

/etc/inet/ike/crls-Verzeichnis

Das Verzeichnis /etc/inet/ike/crls enthält die Dateien der Zertifikat-Rücknahmeliste (CRL). Jede Datei entspricht einer öffentlichen Zertifikatsdatei im Verzeichnis /etc/inet/ike/publickeys. PKI-Organisationen stellen die CRLs für ihre Zertifikate bereit. Mit dem Befehl ikecert certrldb können Sie die Datenbank füllen.

Kapitel 25 Oracle Solaris IP Filter (Übersicht)

Dieses Kapitel enthält eine Einführung in Oracle Solaris IP Filter. Aufgaben zu Oracle Solaris IP Filter finden Sie in Kapitel 26Oracle Solaris IP Filter (Aufgaben).

Dieses Kapitel enthält die folgenden Informationen:

Neuerungen bei Oracle Solaris IP Filter

In diesem Abschnitt werden die neuen Funktionen von Oracle Solaris IP Filter beschrieben.

Eine vollständige Liste der neuen Funktionen in sowie eine Beschreibung der Solaris-Releases finden Sie im Handbuch Neuerungen in Oracle Solaris 9 10/10

Paket Filter-Hooks

Version Solaris 10 7/07: Für die Paketfilterung in Oracle Solaris werden jetzt Paket Filter-Hooks eingesetzt. Diese Funktion bietet Systemadministratoren die folgenden Vorteile:

Weitere Informationen zu diesen Hooks finden Sie unter Paket Filter-Hooks. Aufgaben im Zusammenhang mit Paket Filter-Hooks finden Sie in Kapitel 26Oracle Solaris IP Filter (Aufgaben).

IPv6-Paketfilterung für Oracle Solaris IP Filter

Solaris 10 6/06: Für Administratoren, die einen Teil oder ihre gesamte Netzwerkinfrastruktur mit IPv6 konfigurieren, wurde Oracle Solaris IP Filter aufgewertet. IP Filter unterstützt jetzt auch die IPv6-Paketfilterung. Die IPv6-Paketfilterung kann basierend auf der Quell- oder Ziel-IPv6-Adresse, auf IPv6-Adresspools sowie auf IPv6-Extension-Header erfolgen.

Die Befehle ipf und ipfstat wurden um die Option -6 erweitert, so dass sie mit IPv6 verwendet werden können. Obwohl keine Änderungen an der Befehlszeilenschnittstelle für die Befehle ipmon und ippool vorgenommen wurden, unterstützen auch diese Befehle IPv6. Der Befehl ipmon wurde aufgewertet, so dass eine Protokollierung von IPv6-Paketen möglich ist, und der Befehl ippool unterstützt die Aufnahme von IPv6-Adressen in Pools.

Weitere Informationen zu IPv6 finden Sie unter ?IPv6 für Oracle Solaris IP Filter“. Aufgaben im Zusammenhang mit der IPv6-Paketfilterung finden Sie in Kapitel 26Oracle Solaris IP Filter (Aufgaben).

Einführung in Oracle Solaris IP Filter

Oracle Solaris IP Filter ersetzt die SunScreen-Firewall als Firewall-Software für Oracle Solaris. Im Gegensatz zur SunScreen-Firewall bietet Oracle Solaris IP Filter die statusbehaftete Paketfilterung und Network Address Translation (NAT). Darüber hinaus bietet Oracle Solaris IP Filter eine statusfreie Paketfilterung sowie die Möglichkeit, Adresspools zu erstellen und zu verwalten.

Die Paketfilterung bietet allgemeinen Schutz gegen netzwerkbasierte Angriffe. Oracle Solaris IP Filter kann nach IP-Adresse, Port, Protokoll, Netzwerkschnittstelle und Netzverkehrsrichtung filtern. Darüber hinaus kann Oracle Solaris IP Filter nach einer bestimmten IP-Quelladresse, einer IP-Zieladresse, nach einem Bereich von IP-Adressen oder nach Adresspools filtern.

Oracle Solaris IP Filter ist von der Open Source IP Filter-Software abgeleitet. Der Standardpfad zu Anzeige der Lizenzbedingungen, Attribution und den Hinweisen zum Copyright für Open Source IP Filter lautet /usr/lib/ipf/IPFILTER.LICENCE. Falls Oracle Solaris nicht unter dem Standardpfad installiert wurde, ändern Sie den angegebenen Pfad so, dass Sie auf die Datei im Installationsverzeichnis zugreifen können.

Informationsquellen für Open Source IP Filter

Die Homepage für die Open Source-Software IP Filter von Darren Reed befindet sich unter http://coombs.anu.edu.au/~avalon/ip-filter.html. Diese Site enthält Informationen zu Open Source IP Filter, einschließlich einem Link zu einem Lernprogramm mit der Bezeichnung „IP Filter Based Firewalls HOWTO“ (Brendan Conoboy and Erik Fichtner, 2002). Dieses Lernprogramm enthält schrittweise Anleitungen zum Erstellen von Firewalls in einer BSD UNIX-Umgebung. Obwohl es für eine BSD UNIX-Umgebung geschrieben wurde, gilt das Lernprogramm auch für die Konfiguration von Oracle Solaris IP Filter.

Paketverarbeitung mit Oracle Solaris IP Filter

Oracle Solaris IP Filter führt bei der Verarbeitung eines Pakets eine bestimmte Abfolge von Schritten aus. Das folgende Diagramm zeigt die Schritte bei der Paketverarbeitung und die Integration der Filterung in den TCP/IP-Protokollstapel.

Abbildung 25–1 Reihenfolge der Schritte bei der Paketverarbeitung

Zeigt die Reihenfolge der Schritte bei der Paketverarbeitung mit Oracle Solaris IP Filter an.

Die Reihenfolge bei der Paketverarbeitung umfasst:

Richtlinien zur Verwendung von OpenSolaris IP Filter

Verwenden der Oracle Solaris IP Filter-Konfigurationsdateien

Oracle Solaris IP Filter kann entweder Firewall-Services oder Network Address Translation (NAT) bereitstellen. Oracle Solaris IP Filter kann mithilfe von ladefähigen Konfigurationsdateien implementiert werden. Oracle Solaris IP Filter enthält ein Verzeichnis namens /etc/ipf. Im Verzeichnis /etc/ipf können Sie die Konfigurationsdateien ipf.conf, ipnat.conf und ippool.conf erstellen und speichern. Diese Dateien werden während des Bootens automatisch geladen, wenn sie sich im Verzeichnis /etc/ipf befinden. Sie können die Konfigurationsdateien auch in einem anderen Verzeichnis speichern und dann manuell laden. Beispiele für die Konfigurationsdateien finden Sie unter Erstellen und Bearbeiten von Konfigurationsdateien für Oracle Solaris IP Filter.

Arbeiten mit Oracle Solaris IP Filter-Regellisten

Bei der Verwaltung Ihrer Firewall verwenden Sie Oracle Solaris IP Filter, um Regellisten anzugeben, mit denen Ihr Netzwerkverkehr gefiltert wird. Sie können die folgenden Regellistentypen erstellen:

Darüber hinaus können Sie Adresspools erstellen, um auf IP-Adressgruppen zu verweisen. Diese Pools können Sie dann später in einer Regelliste verwenden. Die Adresspools helfen Ihnen dabei, die Regelverarbeitung zu beschleunigen. Mit Adresspools lassen sich auch große Adressengruppen einfacher verwalten.

Verwenden der Paketfilter-Funktionen in Oracle Solaris IP Filter

Eine Paketfilterung wird mithilfe der Paketfilter-Regellisten eingerichtet. Zum Arbeiten mit Paketfilter-Regellisten verwenden Sie den Befehl ipf. Informationen zum Befehl ipf finden Sie in der Manpage ipf(1M).

Sie erstellen die Paketfilterregeln entweder mithilfe des Befehls ipf in einer Befehlszeile oder in einer Paketfilterung-Konfigurationsdatei. Wenn Sie die Paketfilterregeln beim Booten laden möchten, erstellen Sie eine Konfigurationsdatei namens /etc/ipf/ipf.conf und legen die Regeln in dieser Datei an. Sollen die Paketfilterregeln nicht beim Booten geladen werden, speichern Sie die Datei ipf.conf in einen beliebigen Verzeichnis und aktivieren die Paketfilterung mithilfe des Befehls ipf manuell.

Mit Oracle Solaris IP Filter können Sie zwei Paketfilter-Regellisten verwalten: die aktive Regelliste und die inaktive Regelliste. In den meisten Fällen arbeiten Sie mit der aktiven Regelliste. Über den Befehl ipf -I können Sie die Befehlsaktion auch an der inaktiven Regelliste anwenden. Die inaktive Regelliste wird erst dann von Oracle Solaris IP Filter verwendet, wenn Sie sie auswählen. In der inaktiven Regelliste können Sie Regeln speichern, ohne dass sie sich auf die aktive Paketfilterung auswirken.

Oracle Solaris IP Filter arbeitet die Regeln in der Regelliste nacheinander vom dem Anfang der Liste bis zum Ende der Liste ab. Erst dann wird ein Paket durchgelassen oder blockiert. Oracle Solaris IP Filter setzt ein Flag, mit dem festgelegt wird, ob ein Paket durchgelassen wird oder nicht. Es durchläuft die gesamte Regelliste und legt fest, ob das Paket basierend auf der letzten übereinstimmenden Regel durchgelassen oder blockiert wird.

Für diesen Prozess gibt es zwei Ausnahmen. Die erste Ausnahme ist, wenn das Paket einer Regel entspricht, die das Schlüsselwort quick enthält. Wenn eine Regel das Schlüsselwort quick enthält, wird die Aktion für diese Regel ausgeführt und keine weiteren Regeln geprüft. Die zweite Ausnahme ist, wenn ein Paket einer Regel entspricht, die das Schlüsselwort group enthält. Wenn ein Paket einer Gruppe entspricht, werden nur die Regeln geprüft, die dieser Gruppe zugeordnet sind.

Konfiguration der Paketfilterregeln

Zum Erstellen der Paketfilterregeln verwenden Sie die folgende Syntax:

Aktion [in|out] Option Schlüsselwort, Schlüsselwort...

  1. Jede Regel beginnt mit einer Aktion. Oracle Solaris IP Filter wendet die Aktion an dem Paket an, wenn das Paket der Regel entspricht. Die folgende Liste enthält die Aktionen, die am häufigsten an einem Paket angewendet werden.

    block

    Verhindert, dass ein Paket den Filter passiert.

    pass

    Gestattet einem Paket, den Filter zu passieren.

    log

    Protokolliert das Paket, legt aber nicht fest, ob das Paket blockiert wird oder passieren darf. Zum Anzeigen des Protokolls verwenden Sie den Befehl ipmon.

    Zählung

    Nimmt das Paket in die Filterstatistiken auf. Zum Anzeigen der Statistiken verwenden Sie den Befehl ipfstat.

    skip Zahl

    Sorgt dafür, dass der Filter die nächsten Zahl Filterregeln überspringt.

    auth

    Fordert, dass die Paketauthentifizierung von einem Benutzerprogramm durchgeführt wird, dass die Paketinformationen überprüft. Das Programm legt fest, ob das Paket passieren darf oder blockiert wird.

    preauth

    Fordert, dass der Filter eine vorab authentifizierte Liste prüft, um festzustellen, was mit einem Paket erfolgen soll.

  2. Nach dieser Aktion muss das nächste Wort entweder in oder out lauten. Ihre Auswahl legt fest, ob die Paketfilterregel an einem eingehenden Paket oder einem abgehenden Paket angewendet wird.

  3. Als Nächstes können Sie in einer Optionsliste auswählen. Wenn Sie mehrere Optionen verwenden, müssen sie in der hier gezeigten Reihenfolge vorliegen.

    log

    Protokolliert das Paket, wenn die Regel die letzte übereinstimmende Regel ist. Zum Anzeigen des Protokolls verwenden Sie den Befehl ipmon.

    quick

    Führt die Regel aus, in der die Option quick enthalten ist, wenn eine Paketübereinstimmung aufgetreten ist. Anschließend werden keine weiteren Regeln geprüft.

    on Schnittstellenname

    Wendet die Regel nur dann an, wenn das Paket über die angegebene Schnittstelle ein- oder abgeht.

    dup-to Schnittstellenname

    Kopiert das Paket und sendet das Duplikat über Schnittstellenname an eine optional angegebene IP-Adresse.

    to Schnittstellenname

    Verschiebt das Paket über eine abgehende Warteschlange an Schnittstellenname.

  4. Nach Angabe der Optionen können Sie unter zahlreichen Schlüsselwörtern wählen, mit denen festgestellt wird, ob das Paket der Regel entspricht. Die folgenden Schlüsselwörter müssen in der hier aufgeführten Reihenfolge verwendet werden.

    Hinweis –

    Standardmäßig darf ein Paket, das keiner Regel in der Konfigurationsdatei entspricht, über den Filter passieren.

    tos

    Filtert das Paket basierend auf dem Servicetyp-Wert, der entweder als hexadezimale oder als dezimale ganze Zahl ausgedrückt ist.

    ttl

    Vergleicht die Pakete basierend auf dem Lebensdauerwert. Der in einem Paket gespeicherte Lebensdauerwert gibt an, wie lange sich ein Paket im Netzwerk aufhalten kann, bevor es gelöscht wird.

    proto

    Entspricht einem bestimmten Protokoll. Sie können einen der Protokollnamen in der Datei /etc/protocols oder eine Dezimalzahl verwenden, mit der das Protokoll angegeben wird. Mithilfe des Schlüsselworts tcp/udp kann z. B. geprüft werden, ob es sich um ein TCP- oder um ein UDP-Paket handelt.

    from/to/all/ any

    Vergleicht eine oder alle der folgenden Angaben: IP-Quelladresse, IP-Zieladresse und Portnummer. Mit dem Schlüsselwort all werden alle Pakete von allen Quellen und an alle Ziele akzeptiert.

    with

    Vergleicht bestimmte Attribute, die dem Paket zugeordnet sind. Fügen Sie entweder das Wort not oder das Wort no vor dem Schlüsselwort ein, damit ein Paket nur dann der Regel entspricht, wenn die Option nicht vorhanden ist.

    flags

    Wird bei TCP verwendet, um basierend auf gesetzten TCP-Flags zu filtern. Weitere Informationen zu den TCP-Flags finden Sie in der Manpage ipf(4).

    icmp-type

    Filtert nach dem ICMP-Typ. Dieses Schlüsselwort wird nur dann verwendet, wenn die Option proto auf icmp gesetzt ist und nicht verwendet wird, wenn die Option flags aktiviert ist.

    keep keep-Optionen

    Legt die Informationen fest, die bei einem Paket beibehalten werden. Zu den verfügbaren keep-Optionen zählen die Optionen state und frags. Die Option state behält Informationen zur Sitzung bei und kann bei TCP-, UDP- und ICMP-Paketen angewendet werden. Die Option frags behält Informationen zu Paketfragmenten bei und wendet diese Informationen an späteren Fragmenten an. Mit den keep-Optionen können entsprechende Pakete durchgelassen werden, ohne dass sie die Zugriffskontrolllisten durchlaufen müssen.

    head Zahl

    Erstellt eine neue Gruppe mit Filterregeln, die durch die Zahl Zahl gekennzeichnet ist.

    group Zahl

    Fügt die Regel zur Gruppennummer Zahl anstatt zur Standardgruppe hinzu. Wenn keine andere Gruppe angegeben wurde, werden alle Filterregeln werden in die Gruppe 0 eingefügt.

Das folgende Beispiel zeigt, wie die Syntax einer Paketfilterregel beim Erstellen einer Regel auszusehen hat. Zum Blockieren von eingehenden Verkehr von der IP-Adresse 192.168.0.0/16 nehmen Sie die folgende Regel in die Regelliste auf:


block in quick from 192.168.0.0/16 to any

Informationen zur vollständigen Grammatik und Syntax beim Schreiben von Paketfilterregeln finden Sie in der Manpage ipf(4) Aufgaben im Zusammenhang mit der Paketfilterung finden Sie unter Verwalten der Paketfilter-Regellisten für Oracle Solaris IP Filter. Eine Erklärung des im Beispiel verwendeten IP-Adressenschemas (192.168.0.0/16) finden Sie in Kapitel 2Planen Ihres TCP/IP-Netzwerks (Vorgehen).

Verwenden der NAT-Funktion in Oracle Solaris IP Filter

NAT stellt Zuordnungsregeln auf, die IP-Quell- und IP-Ziel-Adressen in andere Internet- oder Intranet-Adressen übersetzen. Diese Regeln ändern die Quell- und Zieladressen eingehender oder abgehender IP-Pakete und senden die Pakete weiter. Mit NAT können Sie Datenverkehr auch von einem Port an einen anderen Port umleiten. NAT behält die Integrität eines Datenpakets während Modifikationen oder Umleitungen des Pakets bei.

Zum Arbeiten mit NAT-Regellisten verwenden Sie den Befehl ipnat. Weitere Informationen zum Befehl ipnat finden Sie in der Manpage ipnat(1M).

Sie erstellen die NAT-Regeln entweder mithilfe des Befehls ipnat in einer Befehlszeile oder in einer NAT-Konfigurationsdatei. NAT-Konfigurationsregeln werden in der Datei ipnat.conf angelegt. Wenn die NAT-Regeln beim Booten geladen werden soll, erstellen Sie eine Datei namens /etc/ipf/ipnat.conf, in der Sie die NAT-Regeln anlegen. Sollen die NAT-Regeln nicht beim Booten geladen werden, speichern Sie die Datei ipnat.conf in einem beliebigen anderen Verzeichnis und aktivieren die Paketfilterung mithilfe des Befehls ipnat manuell.

Konfiguration der NAT-Regeln

Zum Erstellen der NAT-Regeln verwenden Sie die folgende Syntax:

Befehl Schnittstellenname Parameter

  1. Jede Regel beginnt mit einem der folgenden Befehle:

    map

    Ordnet eine IP-Adresse oder ein Netzwerk einer anderen IP-Adresse oder einem Netzwerk zu. Dabei wird ein ungeregelter Round-Robin-Prozess verwendet.

    rdr

    Leitet Pakete von einer IP-Adresse und einem Portpaar an eine andere IP-Adresse und ein anderes Portpaar um.

    bimap

    Richtet eine bidirektionale NAT zwischen einer externen IP-Adresse und einer internen IP-Adresse ein.

    map-block

    Richtet eine statische Übersetzung ein, die auf den IP-Adressen basiert. Dieser Befehl basiert auf einem Algorithmus, der die Übersetzung von Adressen in einen Zielbereich erzwingt.

  2. Nach diesem Befehl muss das nächste Wort der Schnittstellenname sein, z. B. hme0.

  3. Als Nächstes können Sie unter zahlreichen Parametern wählen, mit denen die NAT-Konfiguration festgelegt wird. Zu diesen Parametern zählen:

    ipmask

    Entwirft die Netzwerkmaske.

    dstipmask

    Weist die Adresse zu, in die ipmask übersetzt wird.

    mapport

    Weist die Protokolle tcp, udp oder tcp/udp zusammen mit einem Portnummernbereich zu.

Das folgende Beispiel zeigt, wie mithilfe der Syntax für eine NAT-Regel eine NAT-Regel erstellt wird. Um ein Paket neu zu schreiben, das über das Gerät de0 an die Zieladresse 192.168.1.0/24 gesendet wird, und um die Quelladresse extern als 10.1.0.0/16 anzuzeigen, nehmen Sie die folgende Regel in die NAT-Regelliste auf:


map de0 192.168.1.0/24 -> 10.1.0.0/16

Informationen zur vollständigen Grammatik und Syntax beim Schreiben von NAT-Regeln finden Sie in der Manpage ipnat(4).

Verwenden der Adresspool-Funktion in Oracle Solaris IP Filter

Adresspools stellen eine Referenz dar, die zum Benennen einer Gruppe von Adress/Netzmasken-Paaren verwendet wird. Adresspools bieten Prozesse, mit denen die Zeit zum Finden von Entsprechungen zwischen IP-Adressen und Regeln verringert wird. Mit Adresspools lassen sich auch große Adressengruppen einfacher verwalten.

Die Konfigurationsregeln für Adresspools befinden sich in der Datei ippool.conf. Wenn die Adresspool-Regeln beim Booten geladen werden sollen, erstellen Sie eine Datei namens /etc/ipf/ippool.conf, in der Sie die Adresspool-Regeln anlegen. Sollen die Adresspool-Regeln nicht beim Booten geladen werden, speichern Sie die Datei ippool.conf in einem beliebigen anderen Verzeichnis und aktivieren die Paketfilterung mithilfe des Befehls ippool manuell.

Konfiguration von Adresspools

Zum Erstellen eines Adresspools verwenden Sie die folgende Syntax:


table role = role-name type = storage-format number = reference-number
table

Definiert die Referenz für mehrere Adressen.

role

Legt die Rolle des Pools in Oracle Solaris IP Filter fest. Derzeit ist ipf die einzige Rolle, auf die Sie verweisen können.

type

Gibt das Speicherformat für den Pool an.

number

Gibt die Referenznummer an, die von der Filterregel verwendet wird.

Um beispielsweise die Adressgruppe 10.1.1.1 und 10.1.1.2 und das Netzwerk 192.16.1.0 als Poolnummer 13 zu verweisen, nehmen Sie die folgende Regel in die Adresspool-Konfigurationsdatei auf:

table role = ipf type = tree number = 13 
{ 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 };

Um dann in einer Filterregel auf die Poolnummer 13 zu verweisen, erstellen Sie eine Regel ähnlich der Folgenden:


pass in from pool/13 to any

Beachten Sie, dass die Pooldatei vor der Regeldatei geladen werden muss, in der ein Verweis auf den Pool enthalten ist. Andernfalls ist der Pool, wie in der folgenden Ausgabe gezeigt, nicht definiert:


# ipfstat -io
empty list for ipfilter(out)
block in from pool/13(!) to any

Auch wenn Sie den Pools später hinzufügen, wird die Regelliste im Kernel nicht aktualisiert. Sie müssen die Regeldatei, in der auf den Pool verwiesen wird, neu laden.

Informationen zur vollständigen Grammatik und Syntax beim Schreiben von Paketfilterregeln finden Sie in der Manpage ippool(4).

Paket Filter-Hooks

Ab Version Solaris 10 7/07 ersetzen die Paketfilter-Hooks das Modul pfil, um Oracle Solaris IP Filter zu aktivieren. In früheren Oracle Solaris-Versionen musste das Modul pfil in einem zusätzlichen Schritt beim Einrichten von Oracle Solaris IP Filter konfiguriert werden. Dieser zusätzliche Konfigurationsaufwand erhöhte das Risiko, das Oracle Solaris IP Filter fehlerhaft arbeitet. Durch Einfügen des pfil STREAMS-Moduls zwischen IP und dem Gerätetreiber wurde darüber hinaus eine Leistungsverschlechterung verursacht. Darüber hinaus konnte das pfil-Modul keine Pakete zwischen Zonen abfangen.

Mit der Verwendung der Paketfilter-Hooks wird das Verfahren zum Aktivieren von Oracle Solaris IP Filter rationalisiert. Aufgrund dieser Hooks verwendet Oracle Solaris IP Filter Prä-Routing- (Eingang) und Post-Routing-Filterabgriffe (Ausgang), um den ein- und abgehenden Paketfluss von Oracle Solaris-Systemen zu steuern.

Mit Paketfilter-Hooks ist das Modul pfil überflüssig geworden. Aus diesem Grund wurden auch die folgenden Komponenten entfernt, die zum Modul gehörten.

Aufgaben im Zusammenhang mit der Aktivierung von Oracle Solaris IP Filter finden Sie in Kapitel 26Oracle Solaris IP Filter (Aufgaben).

Oracle Solaris IP Filter und das pfil STREAMS-Modul

Hinweis –

Das Modul pfil wird nur in den folgenden Oracle Solaris 10-Versionen mit Oracle Solaris IP Filter verwendet:

Mit der Version Solaris 10 7/07 wurde das pfil-Modul durch die Paketfilter-Hooks ersetzt und wird nicht mehr mit Oracle Solaris IP Filter verwendet.

Das pfil STREAMS-Modul ist für die Arbeit mit Oracle Solaris IP Filter erforderlich. Oracle Solaris IP Filter bietet jedoch keinen automatischen Mechanismus, um das Modul auf jeder Schnittstelle bereitzustellen. Stattdessen wird das pfil STREAMS-Modul vom SMF-Service svc:/network/pfil verwaltet. Um die Filterung auf einer Netzwerkschnittstelle zu aktivieren, müssen Sie zunächst die Datei pfil.ap konfigurieren. Dann aktivieren Sie den svc:/network/pfil-Service, um der Netzwerkschnittstelle das pfil STREAMS-Modul bereitzustellen. Damit das STREAMS-Modul wirksam wird, muss das System entweder neu gebootet werden oder jede Netzwerkschnittstelle, für die eine Filterung angewendet werden soll, muss zunächst abgemeldet und dann erneut geplumbt (aktiviert) werden. Zum Aktivieren der IPv6-Paketfilterung müssen Sie die inet6-Version der Schnittstelle plumben anmelden.

Falls keine pfil-Module für Netzwerkschnittstellen gefunden wurden, werden die SMF-Services in den Wartungszustand versetzt. Die häufigste Ursache hierfür ist eine falsch bearbeitete Datei /etc/ipf/pfil.ap. Wenn der Service in den Wartungsmodus versetzt wird, wird dies in den Protokolldateien der Filterung aufgezeichnet.

Aufgaben im Zusammenhang mit der Aktivierung von Oracle Solaris IP Filter finden Sie unter Konfiguration von Oracle Solaris IP Filter.

IPv6 für Oracle Solaris IP Filter

Ab dem Solaris-Version 10 6/06 ist eine Unterstützung für IPv6 mit Oracle Solaris IP Filter verfügbar. Die IPv6-Paketfilterung kann basierend auf der Quell- oder Ziel-IPv6-Adresse, auf IPv6-Adresspools sowie auf IPv6-Extension-Header erfolgen.

IPv6 ähnelt IPv4 in vielerlei Hinsicht. Jedoch unterscheiden sich die Header- und Paketgrößen zwischen den zwei IP-Versionen; ein wichtiger Aspekt für IP Filter. IPv6-Pakete werden auch als Jumbogramme bezeichnet und enthalten ein Datagramm mit einer Länge von mehr als 65.535 Byte. Oracle Solaris IP Filter unterstützt keine IPv6-Jumbogramme. Informationen zu weiteren IPv6-Funktionen finden Sie unter Die wichtigsten Leistungsmerkmale von IPv6.

Hinweis –

Weitere Informationen zu Jumbogrammen finden Sie in dem Dokument „IPv6 Jumbograms“, RFC 2675 von der Internet Engineering Task Force (IETF). [http://www.ietf.org/rfc/rfc2675.txt]

Die IP Filter-Aufgaben bei IPv6 unterscheiden sich nur wenig von denen bei IPv4. Der wichtigste Unterschied ist das Verwenden der Option -6 bei bestimmten Befehlen. Beispielsweise enthalten die Befehle ipf und ipfstat die Option -6, wenn sie mit der IPv6-Paketfilterung verwendet werden. Sie verwenden die Option -6 mit dem Befehl ipf zum Laden und Leeren der IPv6-Paketfilterregeln. Zum Anzeigen der IPv6-Statistiken verwenden Sie die Option -6 mit dem Befehl ipfstat. Auch die Befehle ipmon und ippool unterstützen IPv6, obwohl es keine zugeordnete Funktion zur Unterstützung von IPv6 gibt. Der Befehl ipmon wurde erweitert, um die Protokollierung von IPv6-Paketen zu ermöglichen. Der Befehl ippool unterstützt IPv6-Adresspools. Sie können Pools erstellen, die entweder ausschließlich IPv4- oder IPv6-Adressen enthalten, oder einen Pool, der sowohl IPv4- als auch IPv6-Adressen enthält.

Mit der Datei ipf6.conf erstellen Sie Paketfilter-Regellisten für IPv6. Standardmäßig befindet sich die Konfigurationsdatei ipf6.conf in dem Verzeichnis /etc/ipf. Wie andere Konfigurationsdateien zur Paketfilterung wird die Datei ipf6.conf automatisch während des Bootens geladen, wenn sie sich im Verzeichnis /etc/ipf befindet. Sie können eine IPv6-Konfigurationsdatei auch in einem beliebigen anderen Verzeichnis speichern und dann manuell laden.

Hinweis –

Network Address Translation (NAT) unterstützt IPv6 nicht.

Nachdem Paketfilterregeln für IPv6 aufgestellt wurden, aktivieren Sie die IPv6-Paketfilterung, indem Sie die inet6-Version der Schnittstelle plumben (aktivieren).

Weitere Informationen zu IPv6 finden Sie in Kapitel 3Einführung in IPv6 (Überblick). Aufgaben im Zusammenhang mit der Aktivierung von Oracle Solaris IP Filter finden Sie in Kapitel 26Oracle Solaris IP Filter (Aufgaben).

Oracle Solaris IP Filter – Manpages

Die folgende Tabelle enthält eine Liste der Manpage-Dokumentation für Oracle Solaris IP Filter.

Manpage 

Beschreibung 

ipf(1M)

Verwenden des Befehls ipf, um die folgenden Aufgaben abzuschließen:

  • Arbeiten mit Paketfilter-Regellisten.

  • Aktivieren und Deaktivieren der Filterung.

  • Zurücksetzen von Statistiken und Neusynchronisieren der Kernel-internen Schnittstellenliste mit der aktuellen Schnittstellen-Statusliste.

ipf(4)

Enthält die Grammatik und Syntax zum Erstellen von Oracle Solaris IP Filter-Paketfilterregeln. 

ipfilter(5)

Enthält Lizenzinformationen zum Open Source IP Filter. 

ipfs(1M)

Verwenden des Befehls ipfs zum Speichern und Wiederherstellen der NAT-Informationen und Statustabelleninformationen nach Neustarts.

ipfstat(1M)

Verwenden des Befehls ipfstat zum Abrufen und Anzeigen von Statistiken zur Paketverarbeitung.

ipmon(1M)

Verwenden des Befehls ipmon zum Öffnen des Protokollierungsgeräts und zum Anzeigen der protokollierten Pakete für Paketfilterung und NAT.

ipnat(1M)

Verwenden des Befehls ipnat zum Abschließen der folgenden Aufgaben:

  • Arbeiten mit NAT-Regeln.

  • Abrufen und Anzeigen von NAT-Statistiken.

ipnat(4)

Enthält die Grammatik und Syntax zum Erstellen von NAT-Regeln. 

ippool(1M)

Verwenden des Befehls ippool zum Erstellen und Verwalten von Adresspools.

ippool(4)

Enthält die Grammatik und Syntax zum Erstellen von Oracle Solaris IP Filter-Adresspools. 

ndd(1M)

Anzeige der aktuellen Filterparameter des pfil STREAMS-Moduls und der aktuellen Werte der einstellbaren Parameter.

Kapitel 26 Oracle Solaris IP Filter (Aufgaben)

In diesem Kapitel finden Sie schrittweise Anweisungen zum Arbeiten mit Solaris IP Filter. Eine Einführung in Oracle Solaris IP Filter finden Sie in Kapitel 25Oracle Solaris IP Filter (Übersicht).

Dieses Kapitel enthält die folgenden Informationen:

Konfiguration von Oracle Solaris IP Filter

In der folgenden Tabelle sind die Verfahren zur Konfiguration von Oracle Solaris IP Filter aufgeführt.

Tabelle 26–1 Konfiguration von Oracle Solaris IP Filter (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Erstaktivierung von Oracle Solaris IP Filter. 

Oracle Solaris IP Filter ist standardmäßig nicht aktiviert. Sie müssen Solaris IP Filter entweder manuell aktivieren oder die Konfigurationsdateien im Verzeichnis /etc/ipf/ verwenden und das System neu booten. Ab Version Solaris 10 7/07 ersetzen die Paketfilter-Hooks das Modul pfil, um Oracle Solaris IP Filter zu aktivieren.

So aktivieren Sie Oracle Solaris IP Filter

Erneutes Aktivieren von Oracle Solaris IP Filter. 

Falls Oracle Solaris IP Filter deaktiviert oder abgeschaltet wurde, können Sie Oracle Solaris IP Filter neu aktivieren, indem Sie entweder das System neu booten oder den Befehl ipf eingeben.

So aktivieren Sie Oracle Solaris IP Filter erneut

Aktivieren der Loopback-Filterung 

Optional können Sie die Loopback-Filterung aktivieren, um beispielsweise Datenverkehr zwischen Zonen zu filtern. 

So aktivieren Sie die Loopback-Filterung

ProcedureSo aktivieren Sie Oracle Solaris IP Filter

Mit dem folgenden Verfahren aktivieren Sie Oracle Solaris IP Filter auf einem System, das mindestens Solaris 10 7/07 ausführt. Um Oracle Solaris IP Filter auch dann auszuführen, wenn ein Solaris Oracle Solaris 10-Version vor Solaris 10 7/07 ausgeführt wird, lesen Sie Arbeiten mit dem pfil-Modul.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Erstellen Sie eine Paketfilter-Regelliste.

    Die Paketfilter-Regelliste enthält Regeln, die von Oracle Solaris IP Filter verwendet werden. Wenn die Paketfilterregeln beim Booten geladen werden sollen, müssen Sie die Datei /etc/ipf/ipf.conf so bearbeiten, dass sie die IPv4-Paketfilterung implementiert. Für IPv6-Paketfilterregeln verwenden Sie die Datei /etc/ipf/ipf6.conf. Sollen die Paketfilterregeln nicht beim Booten geladen werden, speichern Sie die Regeln in einer Datei in einem beliebigen Verzeichnis und aktivieren die Paketfilterung dann manuell. Informationen zur Paketfilterung finden Sie unter Verwenden der Paketfilter-Funktionen in Oracle Solaris IP Filter. Informationen zum Arbeiten mit Konfigurationsdateien finden Sie unter Erstellen und Bearbeiten von Konfigurationsdateien für Oracle Solaris IP Filter.

  3. (Optional) Erstellen Sie eine Network Address Translation (NAT)-Konfigurationsdatei.

    Hinweis –

    Network Address Translation (NAT) unterstützt IPv6 nicht.

    Erstellen Sie eine Datei ipnat.conf, wenn Sie die Network Address Translation verwenden möchten. Wenn die NAT-Regeln beim Booten geladen werden soll, erstellen Sie eine Datei namens /etc/ipf/ipnat.conf, in der Sie die NAT-Regeln anlegen. Sollen die NAT-Regeln nicht beim Booten geladen werden, speichern Sie die Datei ipnat.conf in einem beliebigen anderen Verzeichnis und aktivieren die NAT-Regeln dann manuell.

    Weitere Informationen zu NAT finden Sie unter Verwenden der NAT-Funktion in Oracle Solaris IP Filter.

  4. (Optional) Erstellen Sie eine Adresspool-Konfigurationsdatei.

    Erstellen Sie eine Datei ipool.conf, wenn Sie eine Adressengruppe als einen Adresspool ansprechen möchten. Wenn die Adresspool-Konfigurationsdatei beim Booten geladen werden soll, erstellen Sie eine Datei namens /etc/ipf/ippool.conf, in der Sie den Adresspool anlegen. Soll die Adresspool-Konfiguration nicht beim Booten geladen werden, speichern Sie die Datei ippool.conf in einem beliebigen anderen Verzeichnis und aktivieren die Regeln dann manuell.

    Ein Adresspool kann entweder nur IPv4-Adressen oder nur IPv6-Adressen enthalten. Er kann auch sowohl IPv4- als auch IPv6-Adressen enthalten.

    Weitere Informationen zu Adresspools finden Sie unter Verwenden der Adresspool-Funktion in Oracle Solaris IP Filter.

  5. (Optional) Aktivieren Sie die Filterung von Loopback-Verkehr.

    Falls Sie beabsichtigen, Datenverkehr zwischen auf Ihrem System konfigurierten Zonen zu filtern, müssen Sie die Loopback-Filterung aktivieren. Lesen Sie dazu So aktivieren Sie die Loopback-Filterung. Denken in Sie daran, entsprechende Regellisten für die Zonen zu definieren.

  6. Aktivieren Sie Oracle Solaris IP Filter.


    # svcadm enable network/ipfilter

ProcedureSo aktivieren Sie Oracle Solaris IP Filter erneut

Sie können die Paketfilterung neu aktivieren, nachdem sie vorübergehend deaktiviert wurde.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Starten Sie Oracle Solaris IP Filter und aktivieren Sie die Filterung mithilfe einer der folgenden Methoden:

    • Starten Sie den Computer neu.


      # reboot
      Hinweis –

      Wenn IP Filter aktiviert ist, werden bei einem Neustart die folgenden Dateien geladen, sofern sie vorhanden sind: die Datei /etc/ipf/ipf.conf, die Datei /etc/ipf/ipf6.conf, wenn IPv6 verwendet wird , oder die Datei /etc/ipf/ipnat.conf.

    • Rufen Sie die folgenden Befehle auf, um Oracle Solaris IP Filter zu starten und die Filterung zu aktivieren:

      1. Aktivieren Sie Oracle Solaris IP Filter.


        # ipf -E

      2. Aktivieren Sie die Paketfilterung.


        # ipf -f filename

      3. (Optional) Aktivieren Sie NAT.


        # ipnat -f filename
        Hinweis –

        Network Address Translation (NAT) unterstützt IPv6 nicht.

ProcedureSo aktivieren Sie die Loopback-Filterung

Hinweis –

Sie können Loopback-Verkehr nur dann filtern, wenn Ihr System mindestens Version Solaris 10 7/07 ausführt. In älteren Oracle Solaris 10-Versionen wird die Loopback-Filterung nicht unterstützt.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Halten Sie Oracle Solaris IP Filter an, wenn es ausgeführt wird.


    # svcadm disable network/ipfilter

  3. Fügen Sie die folgende Zeile am Anfang der Datei /etc/ipf.conf bzw. der Datei /etc/ipf6.conf ein:


    set intercept_loopback true;

    Die Zeile muss vor allen IP-Filterregeln stehen, die in der Datei definiert sind. Sie können Befehle auch vor dieser Zeile einfügen. Betrachten Sie dazu das folgende Beispiel:


    # 
# Enable loopback filtering to filter between zones 
# 
set intercept_loopback true; 
# 
# Define policy 
# 
block in all 
block out all 
<other rules>
...

  4. Starten Sie Oracle Solaris IP Filter.


    # svcadm enable network/ipfilter

  5. Geben Sie den folgenden Befehl ein, um den Status der Loopback-Filterung zu überprüfen:


    # ipf —T ipf_loopback
ipf_loopback    min 0   max 0x1 current 1
#

    Wenn die Loopback-Filterung deaktiviert ist, erzeugt der Befehl die folgende Ausgabe:


    ipf_loopback    min 0   max 0x1 current 0

Deaktivieren und Stoppen von Oracle Solaris IP Filter

Eventuell muss die Paketfilterung und NAT unter den folgenden Umständen deaktiviert und gestoppt werden:

In der folgenden Tabelle sind die Verfahren zum Deaktivieren bzw. zum Stoppen der Oracle Solaris IP Filter-Funktionen aufgeführt.

Tabelle 26–2 Deaktivieren und stoppen von Oracle Solaris IP Filter (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Deaktivieren der Paketfilterung. 

Deaktivieren Sie die Paketfilterung mithilfe des Befehls ipf.

So deaktivieren Sie die Paketfilterung

Deaktivieren der NAT. 

Deaktivieren Sie die NAT mithilfe des Befehls ipnat.

So deaktivieren Sie NAT

Stoppen von Paketfilterung und NAT. 

Stoppen Sie die Paketfilterung und NAT mithilfe des Befehls ipf.

So stoppen Sie die Paketfilterung

ProcedureSo deaktivieren Sie die Paketfilterung

Mit dem folgenden Verfahren deaktivieren Sie die Oracle Solaris IP Filter-Paketfilterung, indem Sie die Paketfilterregeln aus der aktiven Regelliste entfernen. Mit diesem Verfahren wird Oracle Solaris IP Filter nicht gestoppt. Sie können Oracle Solaris IP Filter neu aktivieren, indem Sie Regeln wieder zur Regelliste hinzufügen.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Führen Sie eine Methoden aus, um die Oracle Solaris IP Filter-Regeln zu deaktivieren:

    • Entfernen Sie die aktive Regelliste aus dem Kernel.


      # ipf -Fa

      Dieser Befehl deaktiviert die Paketfilterregeln.

    • Entfernen Sie die Filterregeln für eingehende Pakete.


      # ipf -Fi

      Dieser Befehl deaktiviert die Paketfilterregeln für eingehende Pakete.

    • Entfernen Sie die Filterregeln für abgehende Pakete.


      # ipf -Fo

      Dieser Befehl deaktiviert die Paketfilterregeln für abgehende Pakete.

ProcedureSo deaktivieren Sie NAT

Mit dem folgenden Verfahren deaktivieren Sie die Oracle Solaris IP Filter-NAT-Regeln, indem Sie die NAT-Regeln aus der aktiven NAT-Regelliste entfernen. Mit diesem Verfahren wird Oracle Solaris IP Filter nicht deaktiviert. Sie können Oracle Solaris IP Filter neu aktivieren, indem Sie Regeln wieder zur Regelliste hinzufügen.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Entfernen Sie die NAT aus dem Kernel.


    # ipnat -FC

    Die Option -C löscht alle Einträge aus der aktuellen NAT-Regelliste. Mit der Option -F entfernen Sie alle aktiven Einträge aus der aktuellen NAT-Übersetzungstabelle, in der die derzeit aktiven NAT-Zuordnungen aufgeführt sind.

ProcedureSo stoppen Sie die Paketfilterung

Wenn Sie dieses Verfahren ausführen, werden sowohl Paketfilterung als auch NAT aus dem Kernel entfernt. Nachdem Sie dieses Verfahren ausgeführt haben, müssen Sie Solaris IP Filter neu starten, um die Paketfilterung und NAT zu reaktivieren. Weitere Informationen finden Sie unter So aktivieren Sie Oracle Solaris IP Filter erneut.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Stoppen Sie die Paketfilterung und gestatten Sie, dass alle Pakete in das Netzwerk passieren.


    # ipf –D
    Hinweis –

    Mit dem Befehl ipf -D entfernen Sie die Regeln aus der Regelliste. Wenn Sie die Filterung neu starten möchten, müssen Sie die Regeln wieder zur Regelliste hinzufügen.

Arbeiten mit dem pfil-Modul

In diesem Abschnitt wird beschrieben, wie Sie das pfil STREAMS-Modul zum Aktivieren oder Deaktivieren von Oracle Solaris IP Filter verwenden und pfil-Statistiken anzeigen. Diese Verfahren gelten nur für Systeme, die eines der folgenden Oracle Solaris-Versionen ausführen:

In der folgenden Tabelle sind die Verfahren aufgeführt, mit denen das pfil-Modul konfiguriert wird.

Tabelle 26–3 Arbeiten mit dem pfil-Modul (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Aktivieren von Oracle Solaris IP Filter 

Oracle Solaris IP Filter ist standardmäßig nicht aktiviert. Sie müssen Solaris IP Filter entweder manuell aktivieren oder die Konfigurationsdateien im Verzeichnis /etc/ipf/ verwenden und das System neu booten.

So aktivieren Sie Oracle Solaris IP Filter in älteren Solaris Oracle Solaris-Versionen

Aktivieren einer NIC zur Paketfilterung 

Konfigurieren Sie das pfil-Modul, um die Paketfilterung auf einer NIC zu aktivieren

So aktivieren Sie eine NIC für die Paketfilterung

Deaktivieren von Oracle Solaris IP Filter auf einer NIC 

Entfernen Sie eine NIC und gestatten Sie, dass alle Pakete eine NIC passieren. 

So deaktivieren Sie Oracle Solaris IP Filter auf einer NIC

Anzeigen der pfil-Statistiken.

Die Statistiken des pfil-Moduls helfen Ihnen bei der Fehlerbehebung von Oracle Solaris IP Filter mit dem Befehl ndd.

So zeigen Sie die pfil-Statistiken für Oracle Solaris IP Filter an

ProcedureSo aktivieren Sie Oracle Solaris IP Filter in älteren Solaris Oracle Solaris-Versionen

Oracle Solaris IP Filter wird mit Oracle Solaris installiert;. Die Paketfilterung wird jedoch standardmäßig nicht aktiviert. Verwenden Sie das folgende Verfahren, um Oracle Solaris IP Filter zu aktivieren.

Hinweis –

Falls auf Ihrem System mindestens Solaris 10 7/07 ausgeführt wird, befolgen Sie das VerfahrenSo aktivieren Sie Oracle Solaris IP Filter, bei dem Eingriffspunkte für Paketfilter eingesetzt werden.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Starten Sie einen Dateieditor und nehmen Sie Änderungen an der Datei /etc/ipf/pfil.ap vor.

    Diese Datei enthält die Namen der Netzwerkschnittstellenkarten (NICs) auf dem Host. Standardmäßig sind diese Namen auskommentiert. Löschen Sie das Kommentarzeichen für Geräte, die den zu filternden Netzwerkverkehr übertragen. Sollte der Name der NIC für Ihr System nicht aufgeführt sein, fügen Sie eine Zeile hinzu, in der diese NIC angegeben wird.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Aktivieren Sie Ihre Änderungen an der Datei /etc/ipf/pfil.ap, indem Sie die Serviceinstanz network/pfil neu starten.


    # svcadm restart network/pfil

  4. Erstellen Sie eine Paketfilter-Regelliste.

    Die Paketfilter-Regelliste enthält Regeln, die von Oracle Solaris IP Filter verwendet werden. Wenn die Paketfilterregeln beim Booten geladen werden sollen, müssen Sie die Datei /etc/ipf/ipf.conf so bearbeiten, dass sie die IPv4-Paketfilterung implementiert. Für IPv6-Paketfilterregeln verwenden Sie die Datei /etc/ipf/ipf6.conf. Sollen die Paketfilterregeln nicht beim Booten geladen werden, speichern Sie die Regeln in einer Datei in einem beliebigen Verzeichnis und aktivieren die Paketfilterung dann manuell. Informationen zur Paketfilterung finden Sie unter Verwenden der Paketfilter-Funktionen in Oracle Solaris IP Filter. Informationen zum Arbeiten mit Konfigurationsdateien finden Sie unter Erstellen und Bearbeiten von Konfigurationsdateien für Oracle Solaris IP Filter.

  5. (Optional) Erstellen Sie eine Network Address Translation (NAT)-Konfigurationsdatei.

    Hinweis –

    Network Address Translation (NAT) unterstützt IPv6 nicht.

    Erstellen Sie eine Datei ipnat.conf, wenn Sie die Network Address Translation verwenden möchten. Wenn die NAT-Regeln beim Booten geladen werden soll, erstellen Sie eine Datei namens /etc/ipf/ipnat.conf, in der Sie die NAT-Regeln anlegen. Sollen die NAT-Regeln nicht beim Booten geladen werden, speichern Sie die Datei ipnat.conf in einem beliebigen anderen Verzeichnis und aktivieren die NAT-Regeln dann manuell.

    Weitere Informationen zu NAT finden Sie unter Verwenden der NAT-Funktion in Oracle Solaris IP Filter.

  6. (Optional) Erstellen Sie eine Adresspool-Konfigurationsdatei.

    Erstellen Sie eine Datei ipool.conf, wenn Sie eine Adressengruppe als einen Adresspool ansprechen möchten. Wenn die Adresspool-Konfigurationsdatei beim Booten geladen werden soll, erstellen Sie eine Datei namens /etc/ipf/ippool.conf, in der Sie den Adresspool anlegen. Soll die Adresspool-Konfiguration nicht beim Booten geladen werden, speichern Sie die Datei ippool.conf in einem beliebigen anderen Verzeichnis und aktivieren die Regeln dann manuell.

    Ein Adresspool kann entweder nur IPv4-Adressen oder nur IPv6-Adressen enthalten. Er kann auch sowohl IPv4- als auch IPv6-Adressen enthalten.

    Weitere Informationen zu Adresspools finden Sie unter Verwenden der Adresspool-Funktion in Oracle Solaris IP Filter.

  7. Aktivieren Sie Oracle Solaris IP Filter mithilfe einer der folgenden Methoden:

    • Aktivieren Sie IP Filter und starten Sie den Computer neu.


      # svcadm enable network/ipfilter
# reboot
      Hinweis –

      Ein Neustart ist erforderlich, wenn Sie die Befehle ifconfig unplumb und ifconfig plumb nicht sicher auf den NICs verwenden können.

    • Aktivieren Sie die NICs mithilfe der Befehle ifconfig unplumb und ifconfig plumb. Dann aktivieren Sie IP Filter. Die inet6-Version der Schnittstelle muss geplumbt (aktiviert) werden, um eine IPv6-Paketfilterung zu implementieren.


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up
# ifconfig hme0 inte6 unplumb
# ifconfig hme0 inet6 plumb fec3:f849::1/96 up
# svcadm enable network/ipfilter

      Weitere Informationen zum Befehl ifconfig finden Sie in der Manpage ifconfig(1M).

ProcedureSo aktivieren Sie eine NIC für die Paketfilterung

Oracle Solaris IP Filter wird beim Booten aktiviert, wenn die Datei /etc/ipf/ipf.conf (bzw. die Datei /etc/ipf/ipf6.conf, wenn IPv6 verwendet wird) vorhanden ist. Müssen Sie die Paketfilterung auf einer NIC aktivieren, nachdem Oracle Solaris IP Filter gestartet wurde, verwenden Sie das folgende Verfahren.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Starten Sie einen Dateieditor und nehmen Sie Änderungen an der Datei /etc/ipf/pfil.ap vor.

    Diese Datei enthält die Namen der NICs auf dem Host. Standardmäßig sind diese Namen auskommentiert. Löschen Sie das Kommentarzeichen für Geräte, die den zu filternden Netzwerkverkehr übertragen. Sollte der Name der NIC für Ihr System nicht aufgeführt sein, fügen Sie eine Zeile hinzu, in der diese NIC angegeben wird.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Aktivieren Sie Ihre Änderungen an der Datei /etc/ipf/pfil.ap, indem Sie die Serviceinstanz network/pfil neu starten.


    # svcadm restart network/pfil

  4. Aktivieren Sie die NIC mithilfe einer der folgenden Methoden:

    • Starten Sie den Computer neu.


      # reboot
      Hinweis –

      Ein Neustart ist erforderlich, wenn Sie die Befehle ifconfig unplumb und ifconfig plumb nicht sicher auf den NICs verwenden können.

    • Aktivieren Sie die NICs, wenn Sie die Filterung mithilfe des Befehls ifconfig und den Optionen unplumb und plumb vornehmen möchten. Die inet6-Version der Schnittstelle muss geplumbt (aktiviert) werden, um eine IPv6-Paketfilterung zu implementieren.


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

      Weitere Informationen zum Befehl ifconfig finden Sie in der Manpage ifconfig(1M).

ProcedureSo deaktivieren Sie Oracle Solaris IP Filter auf einer NIC

Soll die Paketfilterung auf einer NIC gestoppt werden, verwenden Sie das folgende Verfahren.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Starten Sie einen Dateieditor und nehmen Sie Änderungen an der Datei /etc/ipf/pfil.ap vor.

    Diese Datei enthält die Namen der NICs auf dem Host. Die NICs, die zur Filterung des Netzwerkverkehrs verwendet wurden, sind nicht mit einem Kommentarzeichen versehen. Versehen Sie die Geräte, deren Netzwerkverkehr nicht mehr gefiltert werden soll, mit einem Kommentarzeichen.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
#hme    -1      0       pfil (Commented-out device no longer filters network traffic)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Deaktivieren Sie die NIC mithilfe einer der folgenden Methoden:

    • Starten Sie den Computer neu.


      # reboot
      Hinweis –

      Ein Neustart ist erforderlich, wenn Sie die Befehle ifconfig unplumb und ifconfig plumb nicht sicher auf den NICs verwenden können.

    • Deaktivieren Sie die NICs mithilfe des Befehls ifconfig und den Optionen unplumb und plumb. Für die inet6-Version jeder Schnittstelle muss das Plumbing aufgehoben (deaktiviert) werden, um die IPv6-Paketfilterung zu deaktivieren. Führen Sie die folgenden Schritte aus. Das Beispielgerät im System ist hme:

      1. Geben Sie die Hauptnummer des zu deaktivierenden Geräts an.


        # grep hme /etc/name_to_major
hme 7

      2. Zeigen Sie die aktuelle autopush-Konfiguration für hme0 an.


        # autopush -g -M 7 -m 0
   Major     Minor     Lastminor       Modules
       7      ALL          -           pfil

      3. Entfernen Sie die autopush-Konfiguration.


        # autopush -r -M 7 -m 0

      4. Öffnen Sie das Gerät und weisen Sie dem Gerät IP-Adressen zu.


        # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

        Weitere Informationen zum Befehl ifconfig finden Sie in der Manpage ifconfig(1M).

ProcedureSo zeigen Sie die pfil-Statistiken für Oracle Solaris IP Filter an

Zur Fehlerbehebung bei Oracle Solaris IP Filter können Sie die pfil-Statistiken anzeigen.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Anzeigen der pfil-Statistiken.


    # ndd -get /dev/pfil qif_status
Beispiel 26–1 Anzeigen der pfil-Statistiken für Oracle Solaris IP Filter

Im folgenden Beispiel wird gezeigt, wie Sie die pfil-Statistiken anzeigen.


# ndd -get /dev/pfil qif_status
ifname ill q OTHERQ num sap hl nr nw bad copy copyfail drop notip nodata
   notdata
QIF6 0 300011247b8 300011248b0 6 806 0 4 9 0 0 0 0 0 0 0
dmfe1 3000200a018 30002162a50 30002162b48 5 800 14 171 13681 0 0 0 0 0 0 0

Arbeiten mit Oracle Solaris IP Filter-Regellisten

In der folgenden Tabelle sind die Verfahren zum Arbeiten mit den Oracle Solaris IP Filter-Regellisten aufgeführt.

Tabelle 26–4 Arbeiten mit den Oracle Solaris IP Filter-Regellisten (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Verwalten, Anzeigen und Ändern von Regellisten zur Oracle Solaris IP Filter-Paketfilterung. 

 

Verwalten der Paketfilter-Regellisten für Oracle Solaris IP Filter

 

Zeigen Sie eine aktive Paketfilter-Regelliste an. 

So zeigen Sie die aktive Paketfilter-Regelliste an

 

Zeigen Sie eine inaktive Paketfilter-Regelliste an. 

So zeigen Sie die inaktive Paketfilter-Regelliste an

 

Aktivieren Sie eine andere aktive Regelliste. 

So aktivieren Sie eine andere oder aktualisierte Paketfilter-Regelliste

 

Entfernen Sie eine Regelliste. 

So entfernen Sie eine Paketfilter-Regelliste

 

Fügen Sie zusätzliche Regeln zu Regellisten hinzu. 

So fügen Sie der aktiven Paketfilter-Regelliste Regeln hinzu

So fügen Sie der inaktiven Paketfilter-Regelliste Regeln hinzu

 

Wechseln Sie zwischen aktiven und inaktiven Regellisten. 

So wechseln Sie zwischen der aktiven und der inaktiven Paketfilter-Regelliste

 

Löschen Sie eine inaktive Regelliste aus dem Kernel. 

So entfernen Sie eine inaktive Paketfilter-Regelliste aus dem Kernel

Verwalten, Anzeigen und Ändern von Oracle Solaris IP Filter-NAT-Regeln. 

 

Verwalten der NAT-Regeln für Oracle Solaris IP Filter

 

Zeigen Sie aktive NAT-Regeln an. 

So zeigen Sie die aktiven NAT-Regeln an

 

Entfernen Sie NAT-Regeln. 

So entfernen Sie NAT-Regeln

 

Fügen Sie zusätzliche Regeln zu NAT-Regeln hinzu. 

So hängen Sie Regeln an die NAT-Regelliste an

Verwalten, Anzeigen und Ändern von Oracle Solaris IP Filter-Adresspools. 

 

Verwalten der Adresspools für Oracle Solaris IP Filter

 

Zeigen Sie aktive Adresspools an. 

So zeigen Sie die aktiven Adresspools an

 

Entfernen Sie einen Adresspool. 

So entfernen Sie einen Adresspool

 

Fügen Sie zusätzliche Regeln zu einem Adresspool hinzu. 

So hängen Sie Regeln an einen Adresspool an

Verwalten der Paketfilter-Regellisten für Oracle Solaris IP Filter

Wenn Solaris IP Filter aktiviert ist, können sowohl aktive als auch inaktive Paketfilter-Regellisten im Kernel gespeichert sein. Die aktive Regelliste legt fest, welche Filterung an eingehenden und abgehenden Paketen durchgeführt wird. Auch in der inaktiven Regelliste sind Regeln gespeichert. Diese Regeln werden jedoch nicht verwendet, bis Sie die inaktive Regelliste zur aktiven Regelliste machen. Sie können sowohl die aktive als auch die inaktive Paketfilter-Regelliste verwalten, anzeigen und ändern.

ProcedureSo zeigen Sie die aktive Paketfilter-Regelliste an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Zeigen Sie die aktive Paketfilter-Regelliste an, die in den Kernel geladen wurde.


    # ipfstat -io
Beispiel 26–2 Anzeigen der aktiven Paketfilter-Regelliste

Iem folgenden Beispiel wird die Ausgabe der aktiven, in den Kernel geladenen Paketfilter-Regelliste gezeigt.


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe1 from 192.168.1.0/24 to any
pass in all
block in on dmfe1 from 192.168.1.10/32 to any

ProcedureSo zeigen Sie die inaktive Paketfilter-Regelliste an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Zeigen Sie die inaktive Paketfilter-Regelliste an.


    # ipfstat -I -io
Beispiel 26–3 Anzeigen der inaktiven Paketfilter-Regelliste

Im folgenden Beispiel wird die Ausgabe der inaktiven Paketfilter-Regelliste gezeigt.


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all

ProcedureSo aktivieren Sie eine andere oder aktualisierte Paketfilter-Regelliste

Verwenden Sie das folgende Verfahren, wenn Sie eine der folgenden Aufgaben durchführen möchten:

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Führen Sie einen der folgenden Schritte aus:

    • Erstellen Sie eine neue Regelliste in einer separaten Datei Ihrer Wahl, wenn Sie eine vollständig andere Regelliste aktivieren möchten.

    • Aktualisieren Sie die aktuelle Regelliste, indem Sie die Konfigurationsdatei bearbeiten, in der die Regelliste enthalten ist.

  3. Entfernen Sie die aktuelle Regelliste und laden Sie eine neue.


    # ipf -Fa -f filename

    Der Dateiname kann entweder der Name einer neuen Datei mit der neuen Regelliste oder der Name einer aktualisierten Datei sein, die die aktive Regelliste enthält.

    Die aktive Regelliste wird aus dem Kernel entfernt. Die Regeln in der Datei Dateiname werden zur aktiven Regelliste.

    Hinweis –

    Sie müssen diesen Befehl auch dann eingeben, wenn Sie die aktuelle Konfigurationsdatei neu laden. Andernfalls bleibt die alte Regelliste aktiviert, und die geänderte Regelliste in der aktualisierten Konfigurationsdatei wird nicht übernommen.

    Verwenden Sie keine Befehle wie ipf -D oder svcadm restart, um die aktualisierte Regelliste zu laden. Diese Befehle legen Ihr Netzwerk offen, da sie die Firewall vor dem Laden der neuen Regelliste deaktivieren.

Beispiel 26–4 Aktivieren einer anderen Paketfilter-Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie eine Paketfilter-Regelliste durch eine andere Liste in einer separaten Konfigurationsdatei (/etc/ipf/ipf.conf) ersetzen.


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe all
# ipf -Fa -f /etc/ipf/ipf.conf
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
Beispiel 26–5 Neuladen einer aktualisierten Paketfilter-Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie eine derzeit aktive und aktualisierte Paketfilter-Regelliste neu laden. Die in diesem Beispiel verwendete Datei heißt /etc/ipf/ipf.conf.


# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any

(Edit the /etc/ipf/ipf.conf configuration file.)

# ip -Fa -f /etc/ipf/ipf.conf
# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any
block in quick on elx10 from 192.168.0.0/12 to any

ProcedureSo entfernen Sie eine Paketfilter-Regelliste

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Entfernen Sie die Regelliste.


    # ipf -F [a|i|o]
    -a

    Entfernt alle Filterregeln aus der Regelliste.

    -i

    Entfernt alle Filterregeln für eingehende Pakete.

    -o

    Entfernt alle Filterregeln für abgehende Pakete.

Beispiel 26–6 Entfernen einer Paketfilter-Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie alle Filterregeln aus der aktiven Paketfilter-Regelliste entfernen.


# ipfstat -io
block out log on dmf0 all
block in log quick from 10.0.0.0/8 to any
# ipf -Fa
# ipfstat -io
empty list for ipfilter(out)
empty list for ipfilter(in)

ProcedureSo fügen Sie der aktiven Paketfilter-Regelliste Regeln hinzu

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Wählen Sie eine der folgenden Methoden, um der aktiven Regelliste Regeln hinzuzufügen:

    • Fügen Sie die Regeln über eine Befehlszeile mithilfe des Befehls ipf -f - zur Regelliste hinzu.


      # echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -

    • Führen Sie einen der folgenden Befehle aus:

      1. Erstellen Sie eine Regelliste in einer Datei Ihrer Wahl.

      2. Fügen Sie die von Ihnen erstellten Regeln zur aktiven Regelliste hinzu.


        # ipf -f filename

        Die Regeln in der Datei Dateiname werden am Ende der aktiven Regelliste eingefügt. Da Solaris IP Filter den „last matching rule“-Algorithmus verwendet, legen die hinzugefügten Regeln die Filterprioritäten fest, es sei denn, sie verwenden das Schlüsselwort quick. Wenn ein Paket einer Regel entspricht, die das Schlüsselwort quick enthält, wird die Aktion für diese Regel ausgeführt und alle weiteren Regeln werden ignoriert.

Beispiel 26–7 Anhängen von Regeln an die aktive Paketfilter-Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie eine Regel über die Befehlszeile an die aktive Paketfilter-Regelliste anhängen.


# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
# echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any

ProcedureSo fügen Sie der inaktiven Paketfilter-Regelliste Regeln hinzu

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Erstellen Sie eine Regelliste in einer Datei Ihrer Wahl.

  3. Fügen Sie die von Ihnen erstellten Regeln zur inaktiven Regelliste hinzu.


    # ipf -I -f filename

    Die Regeln in der Datei Dateiname werden am Ende der inaktiven Regelliste eingefügt. Da Solaris IP Filter den „last matching rule“-Algorithmus verwendet, legen die hinzugefügten Regeln die Filterprioritäten fest, es sei denn, sie verwenden das Schlüsselwort quick. Wenn ein Paket einer Regel entspricht, die das Schlüsselwort quick enthält, wird die Aktion für diese Regel ausgeführt und alle weiteren Regeln werden ignoriert.

Beispiel 26–8 Anhängen von Regeln an die interaktive Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie eine Regel aus einer Datei zur inaktiven Paketfilter-Regelliste hinzufügen.


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
# ipf -I -f /etc/ipf/ipf.conf
# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
block in log quick from 10.0.0.0/8 to any

ProcedureSo wechseln Sie zwischen der aktiven und der inaktiven Paketfilter-Regelliste

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Wechseln Sie von der aktiven zur inaktiven Paketfilter-Regelliste.


    # ipf -s

    Mit diesem Befehl können Sie zwischen der aktiven und der inaktiven Paketfilter-Regelliste im Kernel wechseln. Falls die inaktive Regelliste leer ist, findet keine Paketfilterung statt.

Beispiel 26–9 Wechseln zwischen der aktiven und der inaktiven Paketfilter-Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie mit dem Befehl ipf -s die inaktive Regelliste zur aktiven Regelliste machen und die aktive Regelliste zur inaktiven.

ProcedureSo entfernen Sie eine inaktive Paketfilter-Regelliste aus dem Kernel

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Geben Sie die inaktive Regelliste im Befehl „flush all“ an.


    # ipf -I -Fa

    Mit diesem Befehl entfernen Sie die inaktive Paketfilter-Regelliste aus dem Kernel.

    Hinweis –

    Wenn Sie anschließend den Befehl ipf -s ausführen, wird die leere inaktive Regelliste zur aktiven Regelliste. Eine leere aktive Regelliste bedeutet, dass keine Filterung durchgeführt wird.

Beispiel 26–10 Löschen einer inaktiven Paketfilter-Regelliste aus dem Kernel

Im folgenden Beispiel wird gezeigt, wie Sie die in aktive Paketfilter-Regelliste entfernen, so dass keine Regeln angewendet werden.


# ipfstat -I -io
empty list for inactive ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any
# ipf -I -Fa
# ipfstat -I -io
empty list for inactive ipfilter(out)
empty list for inactive ipfilter(in)

Verwalten der NAT-Regeln für Oracle Solaris IP Filter

Zum Verwalten, Anzeigen und Ändern der NAT-Regeln verwenden Sie die folgenden Verfahren.

ProcedureSo zeigen Sie die aktiven NAT-Regeln an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Zeigen Sie die aktiven NAT-Regeln an.


    # ipnat -l
Beispiel 26–11 Anzeigen der aktiven NAT-Regeln

Im folgenden Beispiel wird die Ausgabe der aktiven NAT-Regelliste gezeigt.


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

ProcedureSo entfernen Sie NAT-Regeln

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Entfernen Sie die aktuellen NAT-Regeln.


    # ipnat -C
Beispiel 26–12 Entfernen der NAT-Regeln

Im folgenden Beispiel wird gezeigt, wie Sie die Einträge aus der aktuellen NAT-Regelliste entfernen.


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:
# ipnat -C
1 entries flushed from NAT list
# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:

ProcedureSo hängen Sie Regeln an die NAT-Regelliste an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Wählen Sie eine der folgenden Methoden, um der aktiven Regelliste Regeln hinzuzufügen:

    • Fügen Sie die Regeln über eine Befehlszeile mithilfe des Befehls ipnat -f - zur NAT-Regelliste hinzu.


      # echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -

    • Führen Sie einen der folgenden Befehle aus:

      1. Erstellen Sie eine NAT-Regelliste in einer Datei Ihrer Wahl.

      2. Fügen Sie die von Ihnen erstellten Regeln zur aktiven NAT-Regelliste hinzu.


        # ipnat -f filename

        Die Regeln in der Datei Dateiname werden am Ende der NAT-Regelliste eingefügt.

Beispiel 26–13 Anhängen von Regeln an die NAT-Regelliste

Im folgenden Beispiel wird gezeigt, wie Sie eine Regel über die Befehlszeile an die aktive NAT-Regelliste anhängen.


# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:
# echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -
# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

Verwalten der Adresspools für Oracle Solaris IP Filter

Zum Verwalten, Anzeigen und Ändern der Adresspools verwenden Sie die folgenden Verfahren.

ProcedureSo zeigen Sie die aktiven Adresspools an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Zeigen Sie den aktiven Adresspool an.


    # ippool -l
Beispiel 26–14 Anzeigen des aktiven Adresspools

Im folgenden Beispiel wird gezeigt, wie Sie den Inhalt des aktiven Adresspools anzeigen.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

ProcedureSo entfernen Sie einen Adresspool

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Entfernen Sie die Einträge aus dem aktuellen Adresspool.


    # ippool -F
Beispiel 26–15 Entfernen eines Adresspools

Im folgenden Beispiel wird gezeigt, wie Sie einen Adresspool entfernen.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# ippool -F
1 object flushed
# ippool -l

ProcedureSo hängen Sie Regeln an einen Adresspool an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Wählen Sie eine der folgenden Methoden, um der aktiven Regelliste Regeln hinzuzufügen:

    • Fügen Sie die Regeln über eine Befehlszeile mithilfe des Befehls ippool -f - zur Regelliste hinzu.


      # echo "table role = ipf type = tree number = 13 
{10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24};" | ippool -f -

    • Führen Sie einen der folgenden Befehle aus:

      1. Erstellen Sie einen zusätzlichen Adresspool in einer Datei Ihrer Wahl.

      2. Fügen Sie die von Ihnen erstellten Regeln zum aktiven Adresspool hinzu.


        # ippool -f filename

        Die Regeln in der Datei Dateiname werden am Ende des aktiven Adresspools eingefügt.

Beispiel 26–16 Anhängen von Regeln an einen Adresspool

Im folgenden Beispiel wird gezeigt, wie Sie einen Adresspool über die Befehlszeile zur aktuellen Adresspool-Regelliste hinzufügen.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# echo "table role = ipf type = tree number = 100
 {10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24};" | ippool -f -
# ippool -l
table role = ipf type = tree number = 100
        { 10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24; };
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

Anzeigen von Statistiken und Informationen zu Oracle Solaris IP Filter

Tabelle 26–5 Anzeigen von Statistiken und Informationen zu Oracle Solaris IP Filter (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Anzeigen der Statustabellen. 

Zeigen Sie die Statustabellen an, um Informationen zur Paketfilterung mit dem Befehl ipfstat zu beziehen.

So zeigen Sie die Statustabellen für Oracle Solaris IP Filter an

Anzeigen der Statusstatistiken. 

Zeigen Sie die Statistiken zu dem Paket-Statusinformationen mit dem Befehl ipfstat - s an.

So zeigen Sie die Statusstatistiken für Oracle Solaris IP Filter an

Anzeigen der NAT-Statistiken. 

Zeigen Sie die NAT-Statistiken mit dem Befehl ipnat -s an.

So zeigen Sie die NAT-Statistiken für Oracle Solaris IP Filter an

Anzeigen der Adresspool-Statistiken. 

Zeigen Sie die Adresspool-Statistiken mit dem Befehl ippool -s an.

So zeigen Sie die Adresspool-Statistiken für Oracle Solaris IP Filter an

ProcedureSo zeigen Sie die Statustabellen für Oracle Solaris IP Filter an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Zeigen Sie die Statustabelle an.


    # ipfstat
    Hinweis –

    Mit der Option -t können Sie die Statustabelle im Top Utility-Format anzeigen.

Beispiel 26–17 Anzeigen der Statustabellen für Oracle Solaris IP Filter

Im folgenden Beispiel wird gezeigt, wie eine Statustabelle angezeigt wird.


# ipfstat
bad packets:            in 0    out 0
 input packets:         blocked 160 passed 11 nomatch 1 counted 0 short 0
output packets:         blocked 0 passed 13681 nomatch 6844 counted 0 short 0
 input packets logged:  blocked 0 passed 0
output packets logged:  blocked 0 passed 0
 packets logged:        input 0 output 0
 log failures:          input 0 output 0
fragment state(in):     kept 0  lost 0
fragment state(out):    kept 0  lost 0
packet state(in):       kept 0  lost 0
packet state(out):      kept 0  lost 0
ICMP replies:   0       TCP RSTs sent:  0
Invalid source(in):     0
Result cache hits(in):  152     (out):  6837
IN Pullups succeeded:   0       failed: 0
OUT Pullups succeeded:  0       failed: 0
Fastroute successes:    0       failures:       0
TCP cksum fails(in):    0       (out):  0
IPF Ticks:      14341469
Packet log flags set: (0)
        none

ProcedureSo zeigen Sie die Statusstatistiken für Oracle Solaris IP Filter an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Zeigen Sie die Statusstatistiken an.


    # ipfstat -s
Beispiel 26–18 Anzeigen der Statusstatistiken für Oracle Solaris IP Filter

Im folgenden Beispiel wird gezeigt, wie die Statusstatistiken angezeigt werden.


# ipfstat -s
IP states added:
        0 TCP
        0 UDP
        0 ICMP
        0 hits
        0 misses
        0 maximum
        0 no memory
        0 max bucket
        0 active
        0 expired
        0 closed
State logging enabled

State table bucket statistics:
        0 in use        
        0.00% bucket usage
        0 minimal length
        0 maximal length
        0.000 average length

ProcedureSo zeigen Sie die NAT-Statistiken für Oracle Solaris IP Filter an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Anzeigen der NAT-Statistiken.


    # ipnat -s
Beispiel 26–19 Anzeigen der NAT-Statistiken für Oracle Solaris IP Filter

Im folgenden Beispiel wird gezeigt, wie die NAT-Statistiken angezeigt werden.


# ipnat -s
mapped  in      0       out     0
added   0       expired 0
no memory       0       bad nat 0
inuse   0
rules   1
wilds   0

ProcedureSo zeigen Sie die Adresspool-Statistiken für Oracle Solaris IP Filter an

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Anzeigen der Adresspool-Statistiken.


    # ippool -s
Beispiel 26–20 Anzeigen der Adresspool-Statistiken für Oracle Solaris IP Filter

Im folgenden Beispiel wird gezeigt, wie die Adresspool-Statistiken angezeigt werden.


# ippool -s
Pools:  3
Hash Tables:    0
Nodes:  0

Arbeiten mit Protokolldateien für Oracle Solaris IP Filter

Tabelle 26–6 Arbeiten mit Protokolldateien für Oracle Solaris IP Filter (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Erstellen einer Protokolldatei. 

Erstellen Sie eine separate Oracle Solaris IP Filter-Protokolldatei. 

So richten Sie eine Protokolldatei für Oracle Solaris IP Filter ein

Anzeigen der Protokolldateien. 

Zeigen Sie die Status-, NAT- und der normalen Protokolldateien mithilfe des Befehls ipmon an.

So zeigen Sie Oracle Solaris IP Filter-Protokolldateien an

Leeren des Paketprotokollpuffers. 

Löschen Sie den Inhalt aus dem Paketprotokollpuffer mithilfe des Befehls ipmon - F.

So leeren Sie die Paketprotokolldatei

Speichern der protokollierten Pakete in einer Datei. 

Speichern Sie die protokollierten Pakete in einer Datei, so dass später darauf zugegriffen werden kann. 

So speichern Sie protokollierte Pakete in einer Datei

ProcedureSo richten Sie eine Protokolldatei für Oracle Solaris IP Filter ein

In der Standardeinstellung werden alle Informationen für Oracle Solaris IP Filter in der Datei syslogd protokolliert. Richten Sie eine Protokolldatei ein, um Oracle Solaris IP Filter-Verkehrsinformationen getrennt von anderen Daten aufzuzeichnen, die in der Standard-Protokolldatei aufgezeichnet werden. Führen Sie die folgenden Schritte aus.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Fügen Sie der Datei /etc/syslog.conf die beiden folgenden Zeilen hinzu:


    # Save IPFilter log output to its own file 
local0.debug             /var/log/log-name
    Hinweis –

    Achten Sie in der zweiten Zeile darauf, die Tabulatortaste und nicht die Leertaste zum Trennen von local0.debug und /var/log/Protokollname zu verwenden.

  3. Erstellen Sie die neue Protokolldatei.


    # touch /var/log/log-name

  4. Starten Sie den system-log-Service neu.


    # svcadm restart system-log
Beispiel 26–21 Erstellen eines Oracle Solaris IP Filter-Protokolls

Im folgenden Beispiel wird gezeigt, wie Sie die Datei ipmon.log anlegen, um IP-Filterinformationen zu archivieren.

Unter /etc/syslog.conf:


# Save IPFilter log output to its own file 
local0.debug             /var/log/ipmon.log

An der Befehlszeile:


# touch /var/log/ipmon.log
# svcadm restart system-log

ProcedureSo zeigen Sie Oracle Solaris IP Filter-Protokolldateien an

Bevor Sie beginnen

Zum Aufzeichnen der Oracle Solaris IP Filter-Daten sollten Sie eine separate Protokolldatei erstellen. Näheres dazu finden Sie unter So richten Sie eine Protokolldatei für Oracle Solaris IP Filter ein.

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Zeigen Sie die Status-, NAT- oder normalen Protokolldateien an. Zum Anzeigen einer Protokolldatei geben Sie den folgenden Befehl mit der entsprechenden Option an:


    # ipmon -o [S|N|I] filename
    S

    Zeigt die Status-Protokolldatei an.

    N

    Zeigt die NAT-Protokolldatei an.

    I

    Zeigt die normale IP-Protokolldatei an.

    Um alle Status-, NAT- und die normalen Protokolldateien anzuzeigen, geben Sie alle Optionen an:


    # ipmon -o SNI filename

    • Vorausgesetzt, Sie stoppen zunächst manuell den ipmon-Daemon, können Sie auch den folgenden Befehl zum Anzeigen der Status-, NAT- und Oracle Solaris IP Filter-Protokolldateien verwenden:


      # ipmon -a filename
      Hinweis –

      Rufen Sie den Befehl ipmon -a nicht auf, so lange der ipmon-Daemon noch ausgeführt wird. In der Regel wird der Daemon beim Booten des Systems automatisch gestartet. Mit dem Befehl ipmon -a öffnen Sie darüber hinaus eine weitere Kopie von ipmon. In diesem Fall lesen beide Kopien die gleichen Protokollinformationen, aber nur eine erhält eine bestimmte Protokolldatei.

    Weitere Informationen zum Anzeigen von Protokolldateien finden Sie in der Manpage ipmon(1M).

Beispiel 26–22 Anzeigen von Oracle Solaris IP Filter-Protokolldateien

Im folgenden Beispiel wird die Ausgabe von /var/ipmon.log gezeigt.


# ipmon -o SNI /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

oder


# pkill ipmon
# ipmon -aD /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

ProcedureSo leeren Sie die Paketprotokolldatei

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Leeren Sie den Paketprotokollpuffer.


    # ipmon -F
Beispiel 26–23 Leeren der Paketprotokolldatei

Im folgenden Beispiel wird die Ausgabe gezeigt, wenn eine Protokolldatei entfernt wird. Das System erstellt auch dann einen Bericht, wenn nichts in der Protokolldatei gespeichert ist; wie in diesem Beispiel.


# ipmon -F
0 bytes flushed from log buffer
0 bytes flushed from log buffer
0 bytes flushed from log buffer

ProcedureSo speichern Sie protokollierte Pakete in einer Datei

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Speichern Sie die protokollierten Pakete in einer Datei.


    # cat /dev/ipl > filename

    Setzen Sie die Protokollierung von Paketen in die Datei Dateiname fort, bis Sie den Vorgang durch Drücken von Strg-C unterbrechen, um zur Befehlszeile zu gelangen.

Beispiel 26–24 Speichern von protokollierten Paketen in einer Datei

Im folgenden Beispiel wird die Ausgabe gezeigt, wenn protokollierte Pakete in einer Datei gespeichert werden.


# cat /dev/ipl > /tmp/logfile
^C#

# ipmon -f /tmp/logfile
02/09/2004 15:30:28.708294 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 52 -S IN
02/09/2004 15:30:28.708708 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.792611 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 70 -AP IN
02/09/2004 15:30:28.872000 hme0 @0:1 p 129.146.157.149,33923 -> 
 129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872142 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 43 -AP IN
02/09/2004 15:30:28.872808 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872951 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 47 -AP IN
02/09/2004 15:30:28.926792 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN 
.
.
(output truncated)

Erstellen und Bearbeiten von Konfigurationsdateien für Oracle Solaris IP Filter

Zum Erstellen oder Ändern von Regellisten und Adresspools müssen Sie die Konfigurationsdateien direkt bearbeiten. Die Konfigurationsdateien werden nach den Standardregeln zur UNIX-Syntax erstellt:

ProcedureSo erstellen Sie eine Konfigurationsdatei für Oracle Solaris IP Filter

Im folgenden Verfahren wird beschrieben, wie Sie Folgendes einrichten:

  1. Nehmen Sie eine Rolle an, die das IP Filter Management-Rechteprofil umfasst, oder melden Sie sich als Superuser an.

    Sie können das IP Filter Management-Rechteprofil einer von Ihnen erstellten Rolle zuweisen. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Configuring RBAC (Task Map) in System Administration Guide: Security Services .

  2. Starten Sie einen Dateieditor Ihrer Wahl. Erstellen oder bearbeiten Sie die Konfigurationsdateien für die Funktion, die Sie konfigurieren möchten.

    • Zum Erstellen einer Konfigurationsdatei für Paketfilterregeln bearbeiten Sie die Datei ipf.conf.

      Oracle Solaris IP Filter verwendet die Paketfilterregeln in der Datei ipf.conf. Wenn Sie die Paketfilterregeln in der Datei /etc/ipf/ipf.conf angeben, wird diese Datei beim Booten des Systems geladen. Sollen die Filterregeln nicht beim Booten geladen werden, speichern Sie die Datei in einem beliebigen anderen Verzeichnis. Sie können die Regeln dann gemäß der Beschreibung unter So aktivieren Sie eine andere oder aktualisierte Paketfilter-Regelliste mit dem Befehl ipf aktivieren.

      Informationen zum Erstellen der Paketfilterregeln finden Sie unter Verwenden der Paketfilter-Funktionen in Oracle Solaris IP Filter.

      Hinweis –

      Ist die Datei ipf.conf leer, findet keine Filterung statt. Eine leere ipf.conf-Datei verhält sich wie eine Regelliste mit dem folgenden Inhalt:


      pass in all
pass out all

    • Zum Erstellen einer Konfigurationsdatei für NAT-Regeln bearbeiten Sie die Datei ipnat.conf.

      Oracle Solaris IP Filter verwendet die NAT-Regeln in der Datei ipnat.conf. Wenn Sie die NAT-Regeln in der Datei /etc/ipf/ipnat.conf angeben, wird diese Datei beim Booten des Systems geladen. Sollen die NAT-Regeln nicht während des Bootens geladen werden, Datei ipnat.conf in einem beliebigen anderen Verzeichnis. Sie können die NAT-Regeln dann mit dem Befehl ipnat aktivieren.

      Informationen zum Erstellen der NAT-Regeln finden Sie unter Verwenden der NAT-Funktion in Oracle Solaris IP Filter.

    • Zum Erstellen einer Konfigurationsdatei für Adresspools bearbeiten Sie die Datei ippool.conf.

      Oracle Solaris IP Filter verwendet den Adresspool in der Datei ippool.conf. Wenn Sie die Adresspool-Regeln in der Datei /etc/ipf/ippool.conf angeben, wird diese Datei beim Booten geladen. Soll der Adresspool nicht beim Booten geladen werden, speichern Sie die Dateiippool.conf in einem beliebigen anderen Verzeichnis. Sie können den Adresspool dann mit dem Befehl ippool aktivieren.

      Informationen zum Erstellen von Adresspools finden Sie unter Verwenden der Adresspool-Funktion in Oracle Solaris IP Filter.

Beispiel für Oracle Solaris IP Filter-Konfigurationsdateien

Die folgenden Beispiele verdeutlichen die Anwendung von Paketfilterregeln in Paketfilterkonfigurationen.

Beispiel 26–25 Oracle Solaris IP Filter-Hostkonfiguration

In diesem Beispiel wird eine Konfiguration auf einem Host-Computer mit der Netzwerkschnittstelle elxl gezeigt.


# pass and log everything by default
pass in log on elxl0 all
pass out log on elxl0 all

# block, but don't log, incoming packets from other reserved addresses
block in quick on elxl0 from 10.0.0.0/8 to any
block in quick on elxl0 from 172.16.0.0/12 to any

# block and log untrusted internal IPs. 0/32 is notation that replaces 
# address of the machine running Solaris IP Filter.
block in log quick from 192.168.1.15 to <thishost>
block in log quick from 192.168.1.43 to <thishost>

# block and log X11 (port 6000) and remote procedure call 
# and portmapper (port 111) attempts
block in log quick on elxl0 proto tcp from any to elxl0/32 port = 6000 keep state
block in log quick on elxl0 proto tcp/udp from any to elxl0/32 port = 111 keep state

Diese Regel beginnt mit zwei nicht eingeschränkten Regeln, die den gesamten über die Schnittstelle elxl eingehenden und ausgehenden Verkehr zulassen. Die zweite Regelliste blockiert die eingehenden Pakete von den privaten Adressbereichen 10.0.0.0 und 172.16.0.0 und verhindert deren Eintritt in die Firewall. Die nächste Regelliste blockiert bestimmte interne Adressen vom Host-Computer. Abschließend blockiert die letzte Regelliste Pakete, die an Port 6000 und Port 111 eingehen.

Beispiel 26–26 Oracle Solaris IP Filter-Serverkonfiguration

In diesem Beispiel wird die Konfiguration für einen Host-Computer gezeigt, der als Webserver arbeitet. Dieser Computer verfügt über die Netzwerkschnittstelle eri.


# web server with an eri interface
# block and log everything by default; then allow specific services
# group 100 - inbound rules
# group 200 - outbound rules
# (0/32) resolves to our IP address)
*** FTP proxy ***


# block short packets which are packets fragmented too short to be real.
block in log quick all with short


# block and log inbound and outbound by default, group by destination
block in log on eri0 from any to any head 100
block out log on eri0 from any to any head 200


# web rules that get hit most often
pass in quick on eri0 proto tcp from any \
to eri0/32 port = http flags S keep state group 100
pass in quick on eri0 proto tcp from any \
to eri0/32 port = https flags S keep state group 100


# inbound traffic - ssh, auth
pass in quick on eri0 proto tcp from any \
to eri0/32 port = 22 flags S keep state group 100
pass in log quick on eri0 proto tcp from any \
to eri0/32 port = 113 flags S keep state group 100
pass in log quick on eri0 proto tcp from any port = 113 \
to eri0/32 flags S keep state group 100


# outbound traffic - DNS, auth, NTP, ssh, WWW, smtp
pass out quick on eri0 proto tcp/udp from eri0/32 \
to any port = domain flags S keep state group 200
pass in quick on eri0 proto udp from any port = domain to eri0/32 group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = 113 flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 port = 113 \
to any flags S keep state group 200

pass out quick on eri0 proto udp from eri0/32 to any port = ntp group 200
pass in quick on eri0 proto udp from any port = ntp to eri0/32 port = ntp group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = ssh flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = http flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 \
to any port = https flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = smtp flags S keep state group 200


# pass icmp packets in and out
pass in quick on eri0 proto icmp from any to eri0/32  keep state group 100
pass out quick on eri0 proto icmp from eri0/32 to any keep state group 200


# block and ignore NETBIOS packets
block in quick on eri0 proto tcp from any \
to any port = 135 flags S keep state group 100

block in quick on eri0 proto tcp from any port = 137 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any to any port = 137 group 100
block in quick on eri0 proto udp from any port = 137 to any group 100

block in quick on eri0 proto tcp from any port = 138 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any port = 138 to any group 100

block in quick on eri0 proto tcp from any port = 139 to any flags S keep state
group 100
block in quick on eri0 proto udp from any port = 139 to any group 100
Beispiel 26–27 Oracle Solaris IP Filter-Routerkonfiguration

Das folgende Beispiel zeigt eine Konfiguration für einen Router, der über eine interne Schnittstelle ce0 und eine externe Schnittstelle ce1 verfügt.


# internal interface is ce0 at 192.168.1.1
# external interface is ce1 IP obtained via DHCP
# block all packets and allow specific services
*** NAT ***
*** POOLS ***


# Short packets which are fragmented too short to be real.
block in log quick all with short


# By default, block and log everything.
block in log on ce0 all
block in log on ce1 all
block out log on ce0 all
block out log on ce1 all


# Packets going in/out of network interfaces that aren't on the loopback
# interface should not exist.
block in log quick on ce0 from 127.0.0.0/8 to any
block in log quick on ce0 from any to 127.0.0.0/8
block in log quick on ce1 from 127.0.0.0/8 to any
block in log quick on ce1 from any to 127.0.0.0/8


# Deny reserved addresses.
block in quick on ce1 from 10.0.0.0/8 to any
block in quick on ce1 from 172.16.0.0/12 to any
block in log quick on ce1 from 192.168.1.0/24 to any
block in quick on ce1 from 192.168.0.0/16 to any


# Allow internal traffic
pass in quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24
pass out quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24


# Allow outgoing DNS requests from our servers on .1, .2, and .3
pass out quick on ce1 proto tcp/udp from ce1/32 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.2 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.3 to any port = domain keep state


# Allow NTP from any internal hosts to any external NTP server.
pass in quick on ce0 proto udp from 192.168.1.0/24 to any port = 123 keep state
pass out quick on ce1 proto udp from any to any port = 123 keep state


# Allow incoming mail
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = smtp keep state


# Allow outgoing connections: SSH, WWW, NNTP, mail, whois
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 22 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 22 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 443 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 443 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = nntp keep state
block in quick on ce1 proto tcp from any to any port = nntp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = nntp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = smtp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = whois keep state
pass out quick on ce1 proto tcp from any to any port = whois keep state


# Allow ssh from offsite
pass in quick on ce1 proto tcp from any to ce1/32 port = 22 keep state


# Allow ping out
pass in quick on ce0 proto icmp all keep state
pass out quick on ce1 proto icmp all keep state


# allow auth out
pass out quick on ce1 proto tcp from ce1/32 to any port = 113 keep state
pass out quick on ce1 proto tcp from ce1/32 port = 113 to any keep state


# return rst for incoming auth
block return-rst in quick on ce1 proto tcp from any to any port = 113 flags S/SA


# log and return reset for any TCP packets with S/SA
block return-rst in log on ce1 proto tcp from any to any flags S/SA


# return ICMP error packets for invalid UDP packets
block return-icmp(net-unr) in proto udp all