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 außerdem Methoden für die manuelle und automatische Aushandlung von Sicherheitszuordnungen (Security Associations, SAs) und Schlüsselverteilung, für die alle Attribute in einem Interpretationsbereich (DOI) erfasst werden. Das IPsec-DOI ist ein Dokument mit Definitionen für alle Sicherheitsparameter, 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-Sicherheitsservices zu verwenden, erstellen Sie SAs zwischen Hosts. Eine SA ist eine Simplex-Verbindung, die es zwei Hosts ermöglicht, über IPsec sicher miteinander zu kommunizieren. Es gibt zwei Arten von SAs: manuell und dynamisch.

IPsec unterstützt zwei Sicherheitsmodi (Transport- und Tunnelmodus).

Sicherheitszuordnungen

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

  • Datenschutz (durch Verschlüsselung)

  • Inhaltsintegrität (durch Datenauthentifizierung)

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

Welche Sicherheitsfunktionen Sie einsetzen, hängt von Ihren Anforderungen ab. Wenn Sie nur die IP-Paketquelle und die Inhaltsintegrität authentifizieren müssen, können Sie das Paket ohne Verschlüsselung authentifizieren. Wenn Es hingegen nur um die Wahrung der Privatsphäre geht, können Sie das Paket verschlüsseln, ohne Authentifizierungsmechanismen anzuwenden. Optional können Sie das Paket verschlüsseln und authentifizieren. Die meisten Netzwerksicherheits-Designer entscheiden sich dafür, ihren VPN-Datenverkehr zu verschlüsseln, zu authentifizieren und erneut zu schützen.

Ein IPsec-Tunnel besteht aus einem Paar unidirektionaler SAs – einer SA für jede Richtung des Tunnels –, die den Sicherheitsparameterindex (SPI), die Ziel-IP-Adresse und das Sicherheitsprotokoll (Authentication Header [AH] oder Encapsulating Security Payload [ESP] angeben. Eine SA gruppiert die folgenden Komponenten zur Sicherung der Kommunikation:

  • 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 SA mithilfe des folgenden Triplets:

  • Ziel-IP-Adresse.

  • Sicherheitsprotokoll, entweder AH oder ESP.

  • Security Parameter Index (SPI)-Wert.

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

IPsec-Schlüsselverwaltung

Die Verteilung und Verwaltung der Schlüssel sind entscheidend für die erfolgreiche Nutzung von VPNs. Junos OS unterstützt IPsec-Technologie für die Erstellung 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. Siehe 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 Verfolgung von Schlüsseln nicht schwierig sind. Die sichere Verteilung manueller Konfigurationen über große Entfernungen ist jedoch mit Sicherheitsproblemen verbunden. Abgesehen von der persönlichen Übergabe der Schlüssel können Sie nicht ganz sicher sein, dass die Schlüssel während der Übertragung nicht kompromittiert wurden. Außerdem müssen Sie, wenn Sie den Schlüssel ändern möchten, mit den gleichen Sicherheitsproblemen konfrontiert werden, wie bei der ersten Verteilung.

AutoKey-IKE

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

  • AutoKey-IKE mit vorab genutzten Schlüsseln: Mithilfe von AutoKey-IKE mit vorab genutzten Schlüsseln zur Authentifizierung der Teilnehmer in einer IKE-Sitzung muss jede Seite den vorab gemeinsam genutzten Schlüssel konfigurieren und sicher austauschen. In dieser Hinsicht ist die Frage der sicheren Schlüsselverteilung dasselbe wie bei manuellen Schlüsseln. Nach der Verteilung kann ein Autokey jedoch im Gegensatz zu einem manuellen Schlüssel seine Schlüssel automatisch in vorgegebenen Intervallen mithilfe des IKE-Protokolls ändern. Häufig wechselnde Schlüssel verbessern die Sicherheit erheblich, und automatisch werden die Verantwortlichkeiten für das Schlüsselmanagement erheblich reduziert. Durch das Ändern der Schlüssel erhöht sich jedoch der Datenverkehrsaufwand. daher kann ein allzu häufiger Wechsel der Schlüssel die Effizienz der Datenübertragung reduzieren.

    Ein vorinstallierter Schlüssel ist ein Schlüssel sowohl für die Ver- als auch für die Entschlüsselung, die beide Teilnehmer vor dem Starten der Kommunikation haben müssen.

  • 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 erwirbt ein Zertifikat. Solange die ausstellende Zertifizierungsstelle von beiden Seiten vertrauenswürdig ist, können die Teilnehmer den öffentlichen Schlüssel des Peers abrufen und die Signatur des Peers überprüfen. Es besteht keine Notwendigkeit, die Schlüssel und SAs im Auge zu behalten. IKE tut dies automatisch.

Diffie-Hellman Exchange

Ein Diffie-Hellman (DH)-Austausch ermöglicht es den Teilnehmern, einen gemeinsamen geheimen Wert zu erzielen. Die Stärke der Technik ist, dass es den Teilnehmern ermöglicht, den geheimen Wert über ein ungesichertes Medium zu schaffen, ohne den geheimen Wert durch die Leitung zu geben. Die Größe des Primmoduls, das in der Berechnung jeder Gruppe verwendet wird, unterscheidet sich, wie in der folgenden Tabelle dargestellt. Der Austausch von Diffie Hellman (DH) kann entweder in Software oder hardwarebetrieben werden. Wenn diese Exchange-Operationen in Hardware ausgeführt werden, verwenden wir QuickAssist Technology (QAT) Kryptografie. Im Folgenden Tabelle 1 werden verschiedene Diffie Hellman (DH)-Gruppen aufgeführt und angegeben, ob der für diese Gruppe durchgeführte Vorgang in der Hardware oder in der Software erfolgt.

Tabelle 1: Diffie Hellman (DH) Gruppen und deren Austauschoperationen durchgeführt

Diffie-Hellman (DH) Gruppe

Prime-Modulgröße

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 Kurve mit 256 Bit

DH-Gruppe 20

Elliptische 384-Bit-Kurve

DH-Gruppe 21

Elliptische 521-Bit-Kurve

DH-Gruppe 24

2048-Bit mit 256-Bit-Untergruppe für prime order

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

Ab Junos OS Version 20.3R1 unterstützen vSRX-Instanzen mit installierten Junos-ike-Paketen DH-Gruppen 15, 16 und 21.

Wir empfehlen die Verwendung der DH-Gruppen 1, 2 und 5 nicht.

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

IPsec-Sicherheitsprotokolle

IPsec verwendet zwei Protokolle zur Sicherung der Kommunikation auf IP-Ebene:

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

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

Sie können ihre Sicherheitsprotokolle – auch genannt authentication and encryption algorithms– während der Phase-2-Vorschlagskonfiguration auswählen. Siehe 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. Für SRX5400-, SRX5600- und SRX5800-Geräte werden Tunnelsitzungen an Anker-SPUs mit dem ausgehandelten Protokoll aktualisiert, während nicht-Anker-SPUs ESP- und AH-Tunnelsitzungen beibehalten. ESP- und AH-Tunnelsitzungen werden in den Ausgaben für die Befehle des Betriebsmodus und show security flow cp-session des show security flow session Betriebsmodus angezeigt.

Dieses Thema umfasst die folgenden Abschnitte:

IPsec-Authentifizierungsalgorithmen (AH-Protokoll)

Das AH-Protokoll (Authentication Header) bietet eine Möglichkeit, die Echtheit und Integrität des Inhalts und der Herkunft eines Pakets zu überprüfen. Sie können das Paket durch die Prüfsumme authentifizieren, die durch einen Hash Message Authentication Code (HMAC) berechnet wird, indem Sie einen geheimen Schlüssel und entweder MD5- oder SHA-Hashfunktionen verwenden.

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

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

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

IPsec-Verschlüsselungsalgorithmen (ESP-Protokoll)

Das Encapsulating Security Payload (ESP)-Protokoll bietet ein Mittel, um Datenschutz (Verschlüsselung), Quellauthentifizierung und Inhaltsintegrität (Authentifizierung) zu gewährleisten. ESP im Tunnelmodus verkapselt das gesamte IP-Paket (Header und Payload) und fügt dann einen neuen IP-Header an das jetzt verschlüsselte Paket an. Dieser neue IP-Header enthält die Zieladresse, die zum Routen der geschützten Daten durch das Netzwerk benötigt wird. (Siehe Paketverarbeitung im Tunnelmodus.)

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 leistungsstärkere Version von DES, in der der ursprüngliche DES-Algorithmus in drei Runden mit einer 168-Bit-Taste angewendet wird. DES ermöglicht erhebliche Leistungseinsparungen, wird aber für viele klassifizierte oder sensible Materialübertragungen als inakzeptabel angesehen.

  • Advanced Encryption Standard (AES): Ein Verschlüsselungsstandard, der eine bessere 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. Deshalb empfehlen wir, dass Sie einen Verschlüsselungsalgorithmus für maximale Sicherheit wählen.

IPsec-Tunnel-Aushandlung

Die folgenden zwei verschiedenen Modi 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 verkapseln. Dieser Modus verwendet preshared Schlüssel mit IKE, um Peers oder digitale Zertifikate mit IKE zu authentifizieren, 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 Die 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 das Kommunikationsendpunkt und das kryptografische Endgerät identisch sind. Der Datenanteil 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 für geschützte VPN-Kommunikation nicht 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 Prevention

  • RFC 2401, Security Architecture for the Internet Protocol (veraltet durch RFC 4301)

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

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

  • RFC 2404, The Use of HMAC-SHA-1-96 in ESP and AH (veraltet durch RFC 4305)

  • RFC 2405, Der ESP DES-CBC Cipher-Algorithmus mit Expliziter IV

  • RFC 2406, IP Kapselung 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, Internet Key Exchange (IKE) (veraltet durch RFC 4306)

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

  • RFC 2451, Die ESP CBC-Modus-Cipher-Algorithmen

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

  • RFC 3193, Sicherung von L2TP mit IPsec

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

  • RFC 3602, Der AES-CBC Cipher-Algorithmus und seine Verwendung mit IPsec

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

  • RFC 4106, The Use of 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 Internet Protocol

  • RFC 4302, IP-Authentifizierungs-Header

  • RFC 4303, IP-Kapselung Security Payload (ESP)

  • RFC 4305, Anforderungen an die Implementierung kryptografischer Algorithmen für die Kapselung von Security Payload (ESP) und Authentifizierungs-Header (AH)

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

  • RFC 4307, Kryptografische Algorithmen zur Verwendung im Internet Key Exchange Version 2 (IKEv2)

  • RFC 4308, Cryptographic Suites für IPsec

    Nur Suite VPN-A wird von Junos OS 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 Sicherheits-Nutzdaten (ESP) und Authentifizierungs-Header (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 Groups 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) für IKE und IKEv2

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

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

  • RFC 2412, Das OAKLEY Key Determination Protocol

  • RFC 3706, eine datenverkehrsbasierte Methode zur Erkennung von Toten Internet Key Exchange (IKE)-Peers

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

Release-Verlaufstabelle
Release
Beschreibung
19.1R1
Ab Junos OS Version 19.1R1 unterstützen Geräte der SRX-Serie DH-Gruppen 15, 16 und 21.