Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec-Grundlagen

IPsec – Übersicht

IPsec ist eine Suite verwandter Protokolle zur kryptografischen Sicherung der Kommunikation auf der IP-Paketschicht. IPsec bietet auch Methoden für die manuelle und automatische Aushandlung von Sicherheitsassoziationen (SAs) und Schlüsselverteilung, deren Attribute alle in einem Interpretationsbereich (DOI) gesammelt werden. Der IPsec-DOI ist ein Dokument, das Definitionen für alle Sicherheitsparameter enthält, die für die erfolgreiche Aushandlung eines VPN-Tunnels erforderlich sind – im Wesentlichen alle Attribute, die für SA- und IKE-Verhandlungen erforderlich sind. Weitere Informationen finden Sie unter RFC 2407 und RFC 2408.

Um IPsec-Sicherheitsdienste zu verwenden, erstellen Sie Sicherheitszuordnungen zwischen Hosts. Eine SA ist eine Simplex-Verbindung, die es zwei Hosts ermöglicht, mittels IPsec sicher miteinander zu kommunizieren. Es gibt zwei Arten von Sicherheitszuordnungen: manuell und dynamisch.

IPsec unterstützt zwei Sicherheitsmodi (Transportmodus und Tunnelmodus).

Sicherheitsverbände

Eine Security Association (SA) ist eine unidirektionale Vereinbarung zwischen den VPN-Teilnehmern über die Methoden und Parameter, die bei der Sicherung eines Kommunikationskanals verwendet werden sollen. Für eine vollständige bidirektionale Kommunikation sind mindestens zwei Sicherheitszuordnungen erforderlich, eine für jede Richtung. Über die Sicherheitszuordnung kann ein IPsec-Tunnel die folgenden Sicherheitsfunktionen bereitstellen:

  • Datenschutz (durch Verschlüsselung)

  • Inhaltsintegrität (durch Datenauthentifizierung)

  • Absenderauthentifizierung und – bei Verwendung von Zertifikaten – Nichtabstreitbarkeit (durch Datenursprungsauthentifizierung)

Welche Sicherheitsfunktionen Sie verwenden, hängt von Ihren Bedürfnissen ab. Wenn Sie nur die IP-Paketquelle und die Inhaltsintegrität authentifizieren müssen, können Sie das Paket authentifizieren, ohne Verschlüsselung anzuwenden. Wenn es Ihnen jedoch nur um die Wahrung der Privatsphäre geht, können Sie das Paket verschlüsseln, ohne Authentifizierungsmechanismen anzuwenden. Optional können Sie das Paket sowohl verschlüsseln als auch authentifizieren. Die meisten Netzwerksicherheitsdesigner entscheiden sich dafür, ihren VPN-Datenverkehr zu verschlüsseln, zu authentifizieren und abzuspielen und abzusichern.

Ein IPsec-Tunnel besteht aus einem Paar unidirektionaler Sicherheitszuordnungen (eine Sicherheitszuordnung für jede Richtung des Tunnels), die den Sicherheitsparameterindex (SPI), die Ziel-IP-Adresse und das Sicherheitsprotokoll (verwendeter Authentication Header [AH] oder Encapsulating Security Payload [ESP]) angeben. Eine Sicherheitszuordnung fasst die folgenden Komponenten zum Sichern der Kommunikation zusammen:

  • Sicherheitsalgorithmen und -schlüssel.

  • Protokollmodus, entweder Transport oder Tunnel. Junos OS-Geräte verwenden immer den Tunnelmodus. (Siehe Paketverarbeitung im Tunnelmodus.)

  • Schlüsselverwaltungsmethode, entweder manueller Schlüssel oder AutoKey IKE.

  • SA-Lebensdauer.

Für eingehenden Datenverkehr sucht Junos OS die Sicherheitszuordnung mithilfe des folgenden Tripletts:

  • Ziel-IP-Adresse.

  • Sicherheitsprotokoll, entweder AH oder ESP.

  • SPI-Wert (Security Parameter Index).

Für ausgehenden VPN-Datenverkehr ruft die Richtlinie die SA auf, die dem VPN-Tunnel zugeordnet ist.

IPsec-Schlüsselverwaltung

Die Verteilung und Verwaltung von Schlüsseln ist entscheidend für die erfolgreiche Nutzung von VPNs. Junos OS unterstützt die IPsec-Technologie zum Erstellen von VPN-Tunneln mit drei Arten von Schlüsselerstellungsmechanismen:

  • Manueller Schlüssel

  • AutoKey-IKE mit einem vorinstallierten Schlüssel oder einem Zertifikat

Sie können Ihren Schlüsselerstellungsmechanismus – auch Authentifizierungsmethode genannt – während der Angebotskonfiguration von Phase 1 und Phase 2 auswählen. Weitere Informationen finden Sie unter Internet Key Exchange.Internet Key Exchange

Dieses Thema umfasst die folgenden Abschnitte:

Manueller Schlüssel

Mit manuellen Schlüsseln konfigurieren Administratoren an beiden Enden eines Tunnels alle Sicherheitsparameter. Dies ist eine praktikable Technik für kleine, statische Netzwerke, in denen die Verteilung, Wartung und Nachverfolgung von Schlüsseln nicht schwierig ist. Die sichere Verteilung von Handtastenkonfigurationen über große Entfernungen birgt jedoch Sicherheitsprobleme. Abgesehen davon, dass Sie die Schlüssel von Angesicht zu Angesicht weitergeben, können Sie nicht ganz sicher sein, dass die Schlüssel während des Transports nicht kompromittiert wurden. Wenn Sie den Schlüssel ändern möchten, werden Sie mit den gleichen Sicherheitsproblemen konfrontiert wie bei der ursprünglichen Verteilung.

AutoKey IKE

Wenn Sie zahlreiche Tunnel erstellen und verwalten müssen, benötigen Sie eine Methode, bei der Sie nicht jedes Element manuell konfigurieren müssen. IPsec unterstützt die automatisierte Generierung und Aushandlung von Schlüsseln und Sicherheitszuordnungen mithilfe des IKE-Protokolls (Internet Key Exchange). Junos OS bezeichnet automatisierte Tunnelaushandlung als AutoKey IKE und unterstützt AutoKey IKE mit vorinstallierten Schlüsseln und AutoKey IKE mit Zertifikaten.

  • AutoKey-IKE mit vorinstallierten Schlüsseln: Bei Verwendung von AutoKey-IKE mit vorinstallierten Schlüsseln zur Authentifizierung der Teilnehmer in einer IKE-Sitzung muss jede Seite den vorinstallierten Schlüssel im Voraus konfigurieren und sicher austauschen. In dieser Hinsicht ist die Frage der sicheren Schlüsselverteilung die gleiche wie bei manuellen Schlüsseln. Nach der Verteilung kann ein Autokey jedoch im Gegensatz zu einem manuellen Schlüssel seine Schlüssel mithilfe des IKE-Protokolls automatisch in vordefinierten Intervallen ändern. Durch häufiges Ändern von Schlüsseln wird die Sicherheit erheblich verbessert, und der automatische Wechsel reduziert den Aufwand für die Schlüsselverwaltung erheblich. Das Ändern von Schlüsseln erhöht jedoch den Datenverkehrsaufwand. Daher kann ein zu häufiges Ändern der Schlüssel die Effizienz der Datenübertragung verringern.

    Ein vorinstallierter Schlüssel ist ein Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung, den beide Teilnehmer haben müssen, bevor sie die Kommunikation initiieren.

  • AutoKey-IKE mit Zertifikaten: Bei der Verwendung von Zertifikaten zur Authentifizierung der Teilnehmer während einer AutoKey-IKE-Aushandlung generiert jede Seite ein öffentlich-privates Schlüsselpaar und ruft ein Zertifikat ab. Solange die ausstellende Zertifizierungsstelle (Certificate Authority, CA) von beiden Seiten als vertrauenswürdig eingestuft wird, können die Teilnehmer den öffentlichen Schlüssel des Peers abrufen und die Signatur des Peers überprüfen. Es ist nicht erforderlich, den Überblick über die Schlüssel und SAs zu behalten. IKE macht das automatisch.

Diffie-Hellman-Austausch

Ein Diffie-Hellman-Austausch (DH) ermöglicht es den Teilnehmern, einen gemeinsamen geheimen Wert zu erzeugen. Die Stärke der Technik besteht darin, dass sie es den Teilnehmern ermöglicht, den geheimen Wert über ein ungesichertes Medium zu erstellen, ohne den geheimen Wert durch den Draht zu leiten. Die Größe des Primmoduls, der in der Berechnung jeder Gruppe verwendet wird, unterscheidet sich, wie in der folgenden Tabelle dargestellt. Diffie-Hellman-Austauschvorgänge (DH) können entweder in Software oder in Hardware ausgeführt werden. Im Folgenden werden verschiedene Diffie-Hellman-Gruppen (DH) aufgelistet und angegeben, ob der für diese Gruppe ausgeführte Vorgang in der Hardware oder in der Software ausgeführt wird.Tabelle 1

Tabelle 1: Diffie-Hellman-Gruppen (DH) und ihre Austauschoperationen

Diffie-Hellman (DH) Gruppe

Größe des Prime-Moduls

DH Gruppe 1

768-Bit

DH Gruppe 2

102-Bit

DH Gruppe 5

1536-Bit

DH Gruppe 14

2048-Bit

DH Gruppe 15

3072-Bit

DH Gruppe 16

4096-Bit

DH Gruppe 19

Elliptische 256-Bit-Kurve

DH Gruppe 20

Elliptische 384-Bit-Kurve

DH Gruppe 21

Elliptische 521-Bit-Kurve

DH Gruppe 24

2048-Bit mit 256-Bit-Untergruppe Primzahl

Ab Junos OS Version 19.1R1 unterstützen Firewalls der SRX-Serie die DH-Gruppen 15, 16 und 21.

Ab Junos OS Version 20.3R1 unterstützen virtuelle vSRX-Firewall-Instanzen mit installiertem junos-ike-Paket die DH-Gruppen 15, 16 und 21.

Wir raten von der Verwendung der DH-Gruppen 1, 2 und 5 ab.

Da das Modul für jede DH-Gruppe eine andere Größe hat, müssen sich die Teilnehmer darauf einigen, dieselbe Gruppe zu verwenden.

IPsec-Sicherheitsprotokolle

IPsec verwendet zwei Protokolle, um die Kommunikation auf IP-Ebene zu sichern:

  • Authentication Header (AH) – Ein Sicherheitsprotokoll zur Authentifizierung der Quelle eines IP-Pakets und zur Überprüfung der Integrität seines Inhalts

  • Encapsulating Security Payload (ESP) – Ein Sicherheitsprotokoll zur Verschlüsselung des gesamten IP-Pakets (und zur Authentifizierung seines Inhalts)

Sie können Ihre Sicherheitsprotokolle – auch genannt – während der Angebotskonfiguration von Phase 2 auswählen.authentication and encryption algorithms Weitere Informationen finden Sie unter Internet Key Exchange.Internet Key Exchange

Für jeden VPN-Tunnel werden sowohl AH- als auch ESP-Tunnelsitzungen auf Services Processing Units (SPUs) und der Steuerungsebene installiert. Tunnelsitzungen werden nach Abschluss der Aushandlung mit dem ausgehandelten Protokoll aktualisiert. Bei SRX5400-, SRX5600- und SRX5800-Geräten werden Tunnelsitzungen auf Anker-SPUs mit dem ausgehandelten Protokoll aktualisiert, während Nicht-Anker-SPUs ESP- und AH-Tunnelsitzungen beibehalten. ESP- und AH-Tunnelsitzungen werden in den Ausgängen für die Befehle und Betriebsmodus angezeigt.show security flow sessionshow security flow cp-session

Dieses Thema umfasst die folgenden Abschnitte:

IPsec-Authentifizierungsalgorithmen (AH-Protokoll)

Das AH-Protokoll (Authentication Header) bietet eine Möglichkeit, die Authentizität und Integrität des Inhalts und des Ursprungs eines Pakets zu überprüfen. Sie können das Paket anhand der Prüfsumme authentifizieren, die über einen Hash Message Authentication Code (HMAC) unter Verwendung eines geheimen Schlüssels und entweder MD5- oder SHA-Hash-Funktionen berechnet wird.

  • Message Digest 5 (MD5): Ein Algorithmus, der einen 128-Bit-Hash (auch digitale Signatur oder Message Digest genannt) aus einer Nachricht beliebiger Länge und einem 16-Byte-Schlüssel erzeugt. Der resultierende Hash wird wie ein Fingerabdruck der Eingabe verwendet, um die Authentizität und Integrität von Inhalten und Quellen zu überprüfen.

  • Secure Hash Algorithm (SHA): Ein Algorithmus, der einen 160-Bit-Hash aus einer Nachricht beliebiger Länge und einem 20-Byte-Schlüssel erzeugt. Es wird allgemein als sicherer als MD5 angesehen, da es größere Hashes erzeugt. Da die Rechenverarbeitung im ASIC erfolgt, sind die Leistungseinbußen vernachlässigbar.

Weitere Informationen zu MD5-Hashalgorithmen finden Sie unter RFC 1321 und RFC 2403. Weitere Informationen zu SHA-Hashalgorithmen finden Sie unter RFC 2404. Weitere Informationen zu HMAC finden Sie unter RFC 2104.

IPsec-Verschlüsselungsalgorithmen (ESP-Protokoll)

Das ESP-Protokoll (Encapsulating Security Payload) bietet ein Mittel zur Gewährleistung des Datenschutzes (Verschlüsselung), der Quellauthentifizierung und der Inhaltsintegrität (Authentifizierung). ESP im Tunnelmodus kapselt das gesamte IP-Paket (Header und Nutzlast) und hängt dann einen neuen IP-Header an das jetzt verschlüsselte Paket an. Dieser neue IP-Header enthält die Zieladresse, die zum Weiterleiten der geschützten Daten durch das Netzwerk benötigt wird. (Siehe Paketverarbeitung im Tunnelmodus.)Understanding IKE and IPsec Packet Processing

Mit ESP können Sie sowohl verschlüsseln als auch authentifizieren, nur verschlüsseln oder nur authentifizieren. Für die Verschlüsselung können Sie einen der folgenden Verschlüsselungsalgorithmen auswählen:

  • Data Encryption Standard (DES): Ein kryptografischer Blockalgorithmus mit einem 56-Bit-Schlüssel.

  • Triple DES (3DES): Eine leistungsfähigere Version von DES, bei der der ursprüngliche DES-Algorithmus in drei Runden mit einem 168-Bit-Schlüssel angewendet wird. DES bietet erhebliche Leistungseinsparungen, wird aber für viele klassifizierte oder sensible Materialtransfers als inakzeptabel angesehen.

  • Advanced Encryption Standard (AES) – Ein Verschlüsselungsstandard, der eine größere Interoperabilität mit anderen Geräten bietet. Junos OS unterstützt AES mit 128-Bit-, 192-Bit- und 256-Bit-Schlüsseln.

Für die Authentifizierung können Sie entweder MD5- oder SHA-Algorithmen verwenden.

Obwohl es möglich ist, NULL für die Verschlüsselung auszuwählen, hat sich gezeigt, dass IPsec unter solchen Umständen anfällig für Angriffe sein kann. Daher empfehlen wir Ihnen, einen Verschlüsselungsalgorithmus für maximale Sicherheit zu wählen.

IPsec-Tunnelaushandlung

Die folgenden zwei verschiedenen Modi, die bestimmen, wie der Datenverkehr im VPN ausgetauscht wird.

  • Tunnelmodus: Schützen Sie den Datenverkehr, indem Sie das ursprüngliche IP-Paket in ein anderes Paket im VPN-Tunnel kapseln. In diesem Modus werden vorinstallierte Schlüssel mit IKE verwendet, um Peers zu authentifizieren, oder digitale Zertifikate mit IKE, um Peers zu authentifizieren. Dies wird am häufigsten verwendet, wenn Hosts in separaten privaten Netzwerken über ein öffentliches Netzwerk kommunizieren möchten. Dieser Modus kann sowohl von VPN-Clients als auch von VPN-Gateways verwendet werden und schützt Kommunikation, die von Nicht-IPsec-Systemen kommt oder an diese geht.

  • Transportmodus: Schützen Sie den Datenverkehr, indem Sie das Paket direkt zwischen den beiden Hosts senden, die den IPsec-Tunnel eingerichtet haben. Das heißt, wenn der Kommunikationsendpunkt und der kryptografische Endpunkt identisch sind. Der Datenteil des IP-Pakets ist verschlüsselt, der IP-Header jedoch nicht. VPN-Gateways, die Verschlüsselungs- und Entschlüsselungsdienste für geschützte Hosts bereitstellen, können den Transportmodus nicht für die geschützte VPN-Kommunikation verwenden. Die IP-Adressen der Quelle oder des Ziels können geändert werden, wenn das Paket abgefangen wird. Aufgrund seiner Konstruktion kann der Transportmodus nur verwendet werden, wenn der Kommunikationsendpunkt und der kryptografische Endpunkt identisch sind.

Unterstützte IPsec- und IKE-Standards

Auf Routern, die mit einem oder mehreren MS-MPCs, MS-MICs oder DPCs ausgestattet sind, unterstützt die kanadische und US-Version von Junos OS im Wesentlichen die folgenden RFCs, die Standards für IP-Sicherheit (IPsec) und Internet Key Exchange (IKE) definieren.

  • RFC 2085, HMAC-MD5 IP-Authentifizierung mit Replay-Schutz

  • RFC 2401, Sicherheitsarchitektur für das Internetprotokoll (veraltet durch RFC 4301)

  • RFC 2402, IP-Authentifizierungs-Header (veraltet durch RFC 4302)

  • RFC 2403, Die Verwendung von HMAC-MD5-96 in ESP und AH

  • RFC 2404, Die Verwendung von HMAC-SHA-1-96 in ESP und AH (veraltet durch RFC 4305)

  • RFC 2405, Der ESP DES-CBC-Verschlüsselungsalgorithmus mit explizitem IV

  • RFC 2406, IP Encapsulating Security Payload (ESP) ( veraltet durch RFC 4303 und RFC 4305)

  • RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (veraltet durch RFC 4306)

  • RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) ( veraltet durch RFC 4306)

  • RFC 2409, The Internet Key Exchange (IKE) ( veraltet durch RFC 4306)

  • RFC 2410, Der NULL-Verschlüsselungsalgorithmus und seine Verwendung mit IPsec

  • RFC 2451, Die ESP-CBC-Mode-Verschlüsselungsalgorithmen

  • RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)

  • RFC 3193, Sichern von L2TP mit IPsec

  • RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

  • RFC 3602, Der AES-CBC-Verschlüsselungsalgorithmus und seine Verwendung mit IPsec

  • RFC 3948, UDP-Kapselung von IPsec-ESP-Paketen

  • RFC 4106, Die Verwendung von Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

  • RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

  • RFC 4211, Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

  • RFC 4301, Sicherheitsarchitektur für das Internetprotokoll

  • RFC 4302, IP-Authentifizierungs-Header

  • RFC 4303, IP-gekapselte Sicherheitsnutzlast (ESP)

  • RFC 4305, Implementierungsanforderungen für kryptografische Algorithmen für die Kapselung von Sicherheitsnutzlast (ESP) und Authentifizierungsheader (AH)

  • RFC 4306, Internet Key Exchange (IKEv2)-Protokoll

  • RFC 4307, Kryptografische Algorithmen für die Verwendung im Internet Key Exchange Version 2 (IKEv2)

  • RFC 4308, Kryptografische Suites für IPsec

    In Junos OS wird nur Suite VPN-A unterstützt.

  • RFC 4754, IKE- und IKEv2-Authentifizierung mit dem Elliptic Curve Digital Signature Algorithm (ECDSA)

  • RFC 4835, Implementierungsanforderungen für kryptografische Algorithmen für die Kapselung von Sicherheitsnutzlast (ESP) und Authentifizierungsheader (AH)

  • RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) (veraltet durch RFC 7296)

  • RFC 7296, Internet Key Exchange Protocol, Version 2 (IKEv2)

  • RFC 8200, Internet Protocol, Version 6 (IPv6)-Spezifikation

Junos OS unterstützt teilweise die folgenden RFCs für IPsec und IKE:

  • RFC 3526, More Modular Exponential (MODP) Diffie-Hellman-Gruppen für Internet Key Exchange (IKE)

  • RFC 5114, Zusätzliche Diffie-Hellman-Gruppen zur Verwendung mit IETF-Standards

  • RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE und IKEv2

Die folgenden RFCs und Internet-Entwürfe definieren keine Standards, sondern enthalten Informationen zu IPsec, IKE und verwandten Technologien. Die IETF stuft sie als "informativ" ein.

  • RFC 2104, HMAC: Keyed-Hashing für die Nachrichtenauthentifizierung

  • RFC 2412, Das OAKLEY-Schlüsselbestimmungsprotokoll

  • RFC 3706, Eine datenverkehrsbasierte Methode zur Erkennung toter IKE-Peers (Internet Key Exchange)

  • Internet-Entwurf draft-eastlake-sha2-02.txt, US Secure Hash Algorithms (SHA und HMAC-SHA) ( läuft Juli 2006 ab)

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Release
Beschreibung
19.1R1
Ab Junos OS Version 19.1R1 unterstützen Firewalls der SRX-Serie die DH-Gruppen 15, 16 und 21.