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 zugehöriger Protokolle zur kryptographischen Sicherung der Kommunikation auf IP-Paketebene. IPsec bietet außerdem Methoden für die manuelle und automatische Aushandlung von Sicherheitszuordnungen (SAs) sowie die Schlüsselverteilung, alle Attribute, für die sie in einem DoI-Interpretationsdomänen erfasst werden. 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-Aushandlung IKE erforderlich sind. Weitere Informationen finden Sie in RFC 2407 und RFC 2408.

Für die Verwendung von IPsec-Sicherheitsdiensten erstellen Sie SAs zwischen Hosts. Eine Sicherheitszuordnung ist eine Simplexverbindung, die zwei Hosts die sichere Kommunikation miteinander mit hilfe von IPsec ermöglicht. Es gibt zwei Typen von SAs: manuell und dynamisch.

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

Sicherheitszuordnungen

Eine Sicherheitszuordnung (Security Association, SA) ist eine unidirektionale Vereinbarung zwischen den VPN-Teilnehmern bezüglich der Methoden und Parameter zur Sicherung eines Kommunikationskanals. Die vollständige bidirektionale Kommunikation erfordert mindestens zwei SAs (einen für jede Richtung). Durch die SICHERHEITSzuordnung kann ein IPsec-Tunnel die folgenden Sicherheitsfunktionen bereitstellen:

  • Datenschutz (durch Verschlüsselung)

  • Inhaltsintegrität (durch Datenauthentifizierung)

  • Senderauthentifizierung und – bei Verwendung von Zertifikaten – Unauthentifizierung (durch Daten ursprungsauthentifizierung)

Welche Sicherheitsfunktionen Sie nutzen, hängt von Ihren Anforderungen ab. Wenn Sie nur die IP-Paketquelle und Die Integrität der Inhalte authentifizieren müssen, können Sie das Paket ohne Verschlüsselung authentifizieren. Wenn Sie jedoch nur den Datenschutz schützen möchten, können Sie das Paket verschlüsseln, ohne Authentifizierungsmechanismen anwenden zu müssen. Optional können Sie das Paket sowohl verschlüsseln als auch authentifizieren. Die meisten Netzwerksicherheitsentwickler wählen für die Verschlüsselung, Authentifizierung und Wiedergabe ihres VPN-Datenverkehrs.

Ein IPsec-Tunnel besteht aus zwei unidirektionalen Sicherheitszuordnungen ( einer SICHERHEITSzuordnung für jede Richtung des Tunnels), die den Security Parameter Index (SPI), die Ziel-IP-Adresse und das Sicherheitsprotokoll enthalten (Authentication Header [AH] oder Encapsulating Security Payload [ESP]. Eine Sicherheitszuordnung enthält die folgenden Komponenten für die Sicherung der Kommunikation:

  • Sicherheitsalgorithmen und -schlüssel.

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

  • Schlüsselverwaltungsmethode (entweder manueller Schlüssel oder AutoKey-IKE.

  • SA-Lebensdauer.

Für eingehenden Datenverkehr Junos OS anwendung folgender Triplet die Sicherheitszuordnung nach:

  • Ziel-IP-Adresse

  • Sicherheitsprotokoll, entweder AH oder ESP.

  • Wert des Security Parameter Index (SPI).

Bei ausgehenden VPN-Datenverkehr ruft die Richtlinie die dem VPN-Tunnel zugeordneten SICHERHEITSzuordnungen ab.

IPsec-Schlüsselverwaltung

Die Verteilung und Verwaltung der Schlüssel sind wichtig für die erfolgreiche Verwendung von VPNs. Junos OS unterstützt die IPsec-Technologie für das Erstellen von VPN-Tunneln mit drei Arten von Schlüsselerstellungsmechanismen:

  • Manueller Schlüssel

  • AutoKey-IKE mit einem preshared Key oder einem Zertifikat

Sie können ihren Haupterstellungsmechanismus, auch als Authentifizierungsmethode bezeichnet, während der Konfiguration von Phase 1- und Phase 2-Angebot wä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 ist. Die sichere Verteilung manueller Schlüsselkonfigurationen über große Entfernungen wirft jedoch Sicherheitsprobleme auf. Abgesehen davon, dass Sie die Schlüssel von Angesicht zu Angesicht bestehen, können Sie nicht ganz sicher sein, ob die Schlüssel während der Übertragung nicht gefährdet wurden. Außerdem stehen Sie bei jeder Änderung des Schlüssels vor den gleichen Sicherheitsproblemen wie bei der ersten Verteilung.

AutoKey-IKE

Wenn Sie mehrere 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 automatische Erstellung und Aushandlung von Schlüssel- und Sicherheitszuordnungen mithilfe des Internet Key Exchange (IKE)-Protokolls. Junos OS bezeichnet automatisierte Tunnelaushandlung wie AutoKey IKE und unterstützt AutoKey IKE mit preshared Keys und AutoKey IKE mit Zertifikaten.

  • AutoKey IKE mit preshared Keys: Mit AutoKey IKE mit preshared Keys zur Authentifizierung der Teilnehmer in einer IKE-Sitzung muss jede Seite den Preshared-Schlüssel im Voraus konfigurieren und sicher austauschen. In diesem Zusammenhang ist das Problem der sicheren Schlüsselverteilung dasselbe wie bei manuellen Schlüsseln. Sobald er jedoch verteilt ist, kann ein Autokey im Gegensatz zu einem manuellen Schlüssel automatisch seine Schlüssel in vordefinierten Intervals mithilfe des IKE ändern. Durch die häufigen Änderungen an Schlüsseln wird die Sicherheit erheblich verbessert. Dadurch werden die Verantwortlichkeiten im Schlüsselmanagement erheblich reduziert. Die Änderung des Schlüssels erhöht jedoch den Datenverkehrsaufwand. deshalb kann ein allzu ofter Schlüsselwechsel die Datenübertragungseffizienz reduzieren.

    Ein preshared Key ist ein Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung, den beide Teilnehmer vor dem Beginn der Kommunikation haben müssen.

  • AutoKey IKE mit Zertifikaten: Durch die Verwendung von Zertifikaten zur Authentifizierung der Teilnehmer während einer AutoKey IKE-Aushandlung generiert jede Seite ein Paar öffentlich-privater Schlüssel und übernimmt ein Zertifikat. Solange die ausstellende Zertifizierungsstelle (CA) von beiden Seiten vertrauenswürdig ist, können die Teilnehmer den öffentlichen Schlüssel des Peer abrufen und die Signatur des Peers überprüfen. Es ist nicht notwendig, die Schlüssel und Sicherheitsbehörden im Überblick zu behalten. IKE automatisch vor.

Diffie-Hellman Exchange

Mit dem Diffie-Hellman (DH)-Austausch können die Teilnehmer einen gemeinsamen geheimen Wert erzeugen. Die Stärke der Technik ist, dass die Teilnehmer damit den geheimen Wert über ein ungesichertes Medium schaffen können, ohne den geheimen Wert durch den Draht zu geben. Die Größe des in der Berechnung der einzelnen Gruppen verwendeten Prime Modulus unterscheidet sich von der in der nachstehenden Tabelle dargestellten. Diffie Hellman (DH) Exchange-Vorgänge können sowohl in Software als auch in Hardware ausgeführt werden. Wenn diese Exchange-Vorgänge in Hardware ausgeführt werden, verwenden wir den QAT-Kryptographie (QuickAssist Technology). Im Folgenden Tabelle 1 werden verschiedene Diffie Hellman (DH)-Gruppen aufgeführt und angibt, ob der für diese Gruppe durchgeführte Betrieb in der Hardware oder in der Software erfolgt.

Tabelle 1: Diffie Hellman (DH)-Gruppen und ausgeführte Exchange-Vorgänge

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

256-Bit-Elchetic Curve

DH-Gruppe 20

384-Bit-Eltic Curve

DH-Gruppe 21

521-Bit-Elchetic Curve

DH-Gruppe 24

2048-Bit mit 256-Bit-Hauptauftrags-Untergruppe

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

Beginnend im Junos OS Veröffentlichungs-20.3R1, vSRX mit installierten Junos-ike-Paketen Unterstützung für DH-Gruppen 15, 16 und 21.

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

Da der Modulus für jede DH-Gruppe eine andere Größe hat, müssen die Teilnehmer der Verwendung derselben Gruppe zustimmen.

IPsec-Sicherheitsprotokolle

IPsec verwendet zwei Protokolle zum Sichern der Kommunikation auf IP-Ebene:

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

  • Kapselung der Security Payload (ESP): Ein Sicherheitsprotokoll für die Verschlüsselung des gesamten IP-Pakets (und die Authentifizierung des Inhalts)

Sie können während der Konfiguration ihrer Angebotsphase 2 Ihre Sicherheitsprotokolle, die auch als Authentifizierungs- und Verschlüsselungsalgorithmenbezeichnet werden, wählen. Siehe Internet Key Exchange.

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

Dieses Thema umfasst die folgenden Abschnitte:

IPsec-Authentifizierungsalgorithmen (AH-Protokoll)

Mit dem AH-Protokoll (Authentication Header) können Sie die Authentizität und Integrität des Inhalts und Ursprungs eines Pakets überprüfen. Sie können das Paket anhand der Prüfsumme authentifizieren, die über einen Hash Message Authentication Code (H); mit einem geheimen Schlüssel berechnet wird, und entweder MD5- oder SHA-Hash-Funktionen.

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

  • Secure Hash Algorithm (SHA): Ein Algorithmus, der einen 160-Bit-Hash aus einer Nachricht mit beliebiger Länge und einem 20-Byte-Schlüssel erzeugt. Sie wird generell als sicherer denn MD5 betrachtet, da sie mehr Hasching erzeugt. Da die Rechnerverarbeitung im ASIC durchgeführt wird, sind die Leistungskosten vernachlässigbar.

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

IPSec-Verschlüsselungsalgorithmen (ESP-Protokoll)

Das Encapsulating Security Payload (ESP)-Protokoll bietet ein Mittel, um Datenschutz (Verschlüsselung) sowie Quellauthentifizierung und Inhaltsintegrität (Authentifizierung) sicherzustellen. ESP im Tunnelmodus verkapselt das gesamte IP-Paket (Header und Payload) und fügt dann einen neuen IP-Header zum nun verschlüsselten Paket hinzu. Dieser neue IP-Header enthält die Zieladresse, die zum Routen der geschützten Daten über das Netzwerk erforderlich ist. (Siehe Paketverarbeitung im Tunnelmodus.)

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

  • Data Encryption Standard (DES) – Ein Kryptographieblockierungsalgorithmus mit einem 56-Bit-Schlüssel.

  • Triple DES (3DES) – Eine leistungsstärkere Version von DES, in der der ursprüngliche DES-Algorithmus in drei Kreisen mit einem 168-Bit-Schlüssel angewendet wird. DES führt zu erheblichen Leistungseinsparungen, gilt jedoch für viele klassifizierte oder vertrauliche Materialübertragungen als inakzeptabel.

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

Zur Authentifizierung können entweder MD5- oder SHA-Algorithmen verwendet werden.

Obwohl die Option NULL für die Verschlüsselung möglich ist, hat sich gezeigt, dass IPsec unter diesen Umständen angriffsanfällig sein könnte. Daher empfehlen wir Ihnen, einen Verschlüsselungsalgorithmus für maximale Sicherheit zu wählen.

IPsec-Tunnel-Aushandlung

Die folgenden beiden unterschiedlichen 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 einkapseln. In diesem Modus werden preshared Keys mit IKE zur Authentifizierung von Peers oder digitalen Zertifikaten IKE Authentifizierung von Peers verwendet. Dies wird am häufigsten verwendet, wenn Hosts innerhalb separater privater Netzwerke über ein öffentliches Netzwerk kommunizieren möchten. Dieser Modus kann sowohl für VPN-Clients als auch für VPN-Gateways verwendet werden und schützt die Kommunikation, die von oder zu Nicht-IPsec-Systemen kommt.

  • 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 alle Kommunikationsendpunkte und die Verschlüsselungsendpunkte gleich sind. Der Datenabschnitt des IP-Pakets wird 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 Bauweise kann der Transportmodus nur dann verwendet werden, wenn das Kommunikationsendpunkt und das kryptographische Endgerät identisch sind.

Unterstützte IPsec- und IKE-Standards

Bei Routern mit einem oder mehr MS-MPCs, MS-MICs oder DPCs unterstützt die Version von Junos OS in Kanada und den USA im Wesentlichen die folgenden RFCs, in denen Standards für IP-Sicherheit (IPsec) und Internet Key Exchange (IKE) festgelegt werden.

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

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

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

  • RFC 2403, The Use of HWP-MD5-96 in ESP and AH (Die Verwendung von HWP-MD5-96 in ESP und AH)

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

  • RFC 2405, DER ESP DES-CBC-Cipher-Algorithmus mit Explicit IV

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

  • RFC 2407, The Internet IP Security Domain of Interpretation für 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 Cipher-Algorithmen

  • RFC 2460, Internet Protocol, Version 6 (IPv6)

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

  • RFC 3193, Securing L2TP using IPsec (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-Einkapselung 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 Internet Protocol

  • RFC 4302, IP-Authentifizierungs-Header

  • RFC 4303, IP-Einkapselung von Security Payload (ESP)

  • RFC 4305, Implementierungsanforderungen für Kryptographische Algorithmen für die Kapselung von Security Payload (ESP) und Authentication Header (AH)

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

  • RFC 4307, Kryptographiealgorithmen für die Verwendung in der Internet Key Exchange Version 2 (IKEv2)

  • RFC 4308, Kryptographische Suites für IPsec

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

  • RFC 4754, IKE- und IKEv2-Authentifizierung mithilfe des Eltic Curve Digital Signature Algorithm (ECDSA)

  • RFC 4835, Implementierungsanforderungen für Kryptographische Algorithmen für die Einkapselung von Security Payload (ESP) und Authentication Header (AH)

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

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

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

  • RFC 3526, Modularer 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, Eltic Curve Groups modulo a Prime (ECP-Gruppen) für IKE und IKEv2

In den folgenden RFCs und Internet-Entwürfen werden keine Standards festgelegt, sondern Informationen zu IPsec, IKE und zugehörigen Technologien zur Verfügung gestellt. Der IETF klassifiziert sie als "Informational".

  • RFC 2104, H VERSIERTE: Schlüssel zum Hashing bei der Nachrichtenauthentifizierung

  • RFC 2412, The OAKLEY Key Determination Protocol

  • RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

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

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