Dieses Verfahren nimmt das folgende Setup an:
Die beiden Systeme heißen enigma und partym.
Jedes System besitzt zwei Adressen, eine IPv4-Adresse und eine IPv6-Adresse.
Jedes System erfordert eine ESP-Verschlüsselung mit dem AES-Algorithmus, was einen 128 Bit-Schlüssel erfordert, und ESP-Authentifizierung mit SHA1-Nachrichtendigest, was einen 160 Bit-Schlüssel erfordert.
Jedes System verwendet gemeinsam genutzte Sicherheitszuordnungen.
Bei gemeinsam genutzten SAs ist nur ein SA-Paar zum Schutz von zwei Systemen erforderlich.
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.
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.
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.
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.
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 |
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.
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.
Fügen Sie einen IPsec-Richtlinieneintrag in die Datei ipsecinit.conf ein.
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} |
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).
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.
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.
Konfigurieren Sie IKE mithilfe eines der unter Konfiguration von IKE (Übersicht der Schritte) beschriebenen Konfigurationsverfahren. Informationen zur Syntax der IKE-Konfigurationsdatei finden Sie in der Manpage ike.config(4).
Wie SAs manuell hinzugefügt werden, können Sie unter So erstellen Sie manuell IPsec-Sicherheitszuordnungen nachlesen.
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.
Ü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.
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 |
Aktivieren Sie die Schlüssel für IPsec.
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.
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).
Zunächst konfiguriert der Administrator das erste System durch Ausführen von Schritt 2 bis Schritt 5 des vorangegangenen Verfahrens.
Dann verwendet der Administrator in einem anderen Terminal-Fenster den Befehl ssh zur Anmeldung am zweiten System.
local-system # ssh other-system other-system # |
Im Terminal-Fenster der ssh-Sitzung konfiguriert der Administrator die IPsec-Richtlinie und die Schlüssel des zweiten Systems durch Ausführen von Schritt 2 bis Schritt 6.
Dann beendet der Administrator die ssh-Sitzung.
other-system # exit local-system # |
Schließlich aktiviert der Administrator die IPsec-Richtlinie auf dem ersten System durch Ausführen von Schritt 6.
Bei der nächsten Kommunikation der beiden Systeme, einschließlich einer ssh-Verbindung, wird die Kommunikation durch IPsec geschützt.
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:
Wenn Sie IKE zum Erstellen des Schlüsselmaterials verwenden, müssen Sie den in.iked-Daemon zunächst stoppen und dann neu starten.
# pkill in.iked # /usr/lib/inet/in.iked |
Wenn Sie die Schlüssel manuell hinzugefügt haben, verwenden Sie den Befehl ipseckey, um die SAs zur Datenbank hinzuzufügen.
# ipseckey -c -f /etc/inet/secret/ipseckeys |
Dann aktivieren Sie die IPsec-Richtlinie mit dem Befehl ipsecconf.
# ipsecconf -a /etc/inet/ipsecinit.conf |
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.