Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Internet Key Exchange (IKE) für IPsec-VPN

Internet Key Exchange Version 2 (IKEv2) ist ein IPsec-basiertes Tunneling-Protokoll, das einen sicheren VPN-Kommunikationskanal zwischen Peer-VPN-Geräten bereitstellt und die Aushandlung und Authentifizierung für IPsec-Sicherheitszuordnungen (Security Associations, SAs) auf geschützte Weise definiert.

IKE- und IPsec-Paketverarbeitung

IKE bietet Tunnelmanagement für IPsec und authentifiziert Endentitäten. IKE führt einen Diffie-Hellman-Schlüsselaustausch (DH) durch, um einen IPsec-Tunnel zwischen Netzwerkgeräten zu erzeugen. Die von IKE generierten IPsec-Tunnel werden verwendet, um den Benutzerdatenverkehr zwischen den Netzwerkgeräten auf der IP-Ebene zu verschlüsseln, zu entschlüsseln und zu authentifizieren.

IKE-Paketverarbeitung

Wenn ein Klartextpaket auf einem Gerät von Juniper Networks eintrifft, für das Tunneling erforderlich ist, und für diesen Tunnel keine aktive Phase-2-Sicherheitszuordnung vorhanden ist, beginnt Junos OS mit den IKE-Verhandlungen und verwirft das Paket. Die Quell- und Zieladressen im IP-Paket-Header sind die des lokalen bzw. des Remote-IKE-Gateways. In der IP-Paketnutzlast gibt es ein UDP-Segment, das ein ISAKMP (IKE)-Paket kapselt. Das Format für IKE-Pakete ist für Phase 1 und Phase 2 identisch. Siehe Abbildung 1.

In der Zwischenzeit hat der Quellhost das verworfene Paket erneut gesendet. In der Regel sind die IKE-Verhandlungen abgeschlossen, wenn das zweite Paket eintrifft, und Junos OS schützt das Paket und alle nachfolgenden Pakete in der Sitzung mit IPsec, bevor es weitergeleitet wird.

Abbildung 1: IKE-Paket für die Phasen 1 und 2 IKE-Paket für die Phasen 1 und 2

Das Feld "Nächste Nutzlast" enthält eine Zahl, die einen der folgenden Nutzlasttypen angibt:

  • 0002 – Die SA-Aushandlungsnutzlast enthält eine Definition für eine SA der Phase 1 oder Phase 2.

  • 0004 – Bei der Angebotsnutzlast kann es sich um einen Vorschlag der Phase 1 oder Phase 2 handeln.

  • 0008—Die Transformationsnutzlast wird in eine Vorschlagsnutzlast gekapselt, die wiederum in eine SA-Nutzlast gekapselt wird.

  • 0010 – Die Payload "Key Exchange" (KE) enthält Informationen, die für die Durchführung eines Schlüsselaustauschs erforderlich sind, z. B. einen öffentlichen DH-Wert.

  • 0020 – Identifikationsnutzlast (IDx).

    • In Phase 1 gibt IDii die Initiator-ID und IDir die Responder-ID an.

    • In Phase 2 gibt IDui den Benutzerinitiator und IDur den Benutzer-Responder an.

    Bei den IDs handelt es sich um IKE-ID-Typen wie FQDN, U-FQDN, IP-Adresse und ASN.1_DN.

  • 0040 – Payload "Zertifikat (CERT)".

  • 0080 – Nutzlast für Zertifikatsanforderungen (CERT_REQ).

  • 0100 – Die Hash-Nutzlast (HASH) enthält die Digest-Ausgabe einer bestimmten Hash-Funktion.

  • 0200 – Die Signatur-Nutzlast (SIG) enthält eine digitale Signatur.

  • 0400 – Die Nutzlast "Nonce (Nx)" enthält einige pseudozufällige Informationen, die für den Austausch erforderlich sind.

  • 0800 – Nutzlast benachrichtigen.

  • 1000 – ISAKMP Payload löschen.

  • 2000 – Die Nutzlast der Anbieter-ID (VID) kann an beliebiger Stelle in die Verhandlungen der Phase 1 einbezogen werden. Junos OS verwendet es, um die Unterstützung für NAT-T zu kennzeichnen.

Jede ISAKMP-Nutzlast beginnt mit demselben generischen Header, wie in gezeigt.Abbildung 2

Abbildung 2: Generischer ISAKMP-Nutzlast-Header Generischer ISAKMP-Nutzlast-Header

Es können mehrere ISAKMP-Nutzlasten miteinander verkettet sein, wobei jeder nachfolgende Nutzlasttyp durch den Wert im Feld Nächster Header angegeben wird. Der Wert von gibt die letzte ISAKMP-Nutzlast an.0000 Siehe für ein Beispiel.Abbildung 3

Abbildung 3: ISAKMP-Header mit generischen ISAKMP-Nutzlasten ISAKMP-Header mit generischen ISAKMP-Nutzlasten

IPsec-Paketverarbeitung

Nachdem die IKE-Verhandlungen abgeschlossen sind und die beiden IKE-Gateways Sicherheitszuordnungen (SAs) der Phasen 1 und 2 eingerichtet haben, werden alle nachfolgenden Pakete über den Tunnel weitergeleitet. Wenn die Phase-2-Sicherheitszuordnung das Encapsulating Security Protocol (ESP) im Tunnelmodus angibt, sieht das Paket wie in gezeigt aus.Abbildung 4 Das Gerät fügt dem ursprünglichen Paket, das der initiierende Host sendet, zwei zusätzliche Header hinzu.

Wie in gezeigt, enthält das Paket, das der initiierende Host erstellt, die Nutzlast, den TCP-Header und den inneren IP-Header (IP1).Abbildung 4

Abbildung 4: IPsec-Paket – ESP im Tunnelmodus IPsec-Paket – ESP im Tunnelmodus

Der Router-IP-Header (IP2), den Junos OS hinzufügt, enthält die IP-Adresse des Remote-Gateways als Ziel-IP-Adresse und die IP-Adresse des lokalen Routers als Quell-IP-Adresse. Junos OS fügt außerdem einen ESP-Header zwischen dem äußeren und dem inneren IP-Header hinzu. Der ESP-Header enthält Informationen, die es dem Remote-Peer ermöglichen, das Paket ordnungsgemäß zu verarbeiten, wenn er es empfängt. Dies wird in gezeigt.Abbildung 5

Abbildung 5: Äußerer IP-Header (IP2) und ESP-Header Äußerer IP-Header (IP2) und ESP-Header

Das Feld "Nächste Kopfzeile" gibt den Datentyp im Nutzlastfeld an. Im Tunnelmodus ist dieser Wert 4, was darauf hinweist, dass ein IP-Paket in der Nutzlast enthalten ist. Siehe .Abbildung 6

Abbildung 6: Innerer IP-Header (IP1) und TCP-Header Innerer IP-Header (IP1) und TCP-Header

Einführung in IKE in Junos OS

IKE bietet Möglichkeiten zum sicheren Austausch von Schlüsseln für die Verschlüsselung und Authentifizierung über ein ungesichertes Medium wie das Internet. IKE ermöglicht zwei Sicherheits-Gateways für Folgendes: Richten Sie dynamisch einen sicheren Tunnel ein, über den Sicherheits-Gateways Tunnel- und Schlüsselinformationen austauschen können. Richten Sie Tunnel oder SAs auf Benutzerebene ein, einschließlich Tunnelattributverhandlungen und Schlüsselverwaltung. Diese Tunnel können auch auf demselben sicheren Kanal aktualisiert und beendet werden. IKE verwendet Diffie-Hellman-Methoden und ist in IPsec optional (die gemeinsam genutzten Schlüssel können manuell an den Endpunkten eingegeben werden).

IKEv2 bietet Unterstützung für:

  • Routenbasierte VPNs.

  • Site-to-Site-VPNs.

  • Erkennung toter Peers.

  • Chassis-Cluster.

  • Authentifizierung mit vorinstalliertem Schlüssel.

  • Zertifikatsbasierte Authentifizierung.

  • Untergeordnete Sicherheitszuordnungen. Eine untergeordnete IKEv2-Sicherheitszuordnung wird in IKEv1 als Phase-2-Sicherheitszuordnung bezeichnet. In IKEv2 kann eine untergeordnete Sicherheitszuordnung nicht ohne die zugrunde liegende IKE-Sicherheitszuordnung vorhanden sein.

  • AutoVPN.

  • Dynamisches Endpunkt-VPN.

  • EAP wird für den Remotezugriff mit IKEv2 unterstützt.

  • Traffic-Selektoren.

IKEv2 unterstützt die folgenden Funktionen nicht:

  • Richtlinienbasiertes VPN.

  • VPN-Überwachung.

  • IP Payload Compression Protocol (IPComp).

Konfigurieren von IKEv2 in Junos OS

Ein VPN-Peer ist entweder als IKEv1 oder IKEv2 konfiguriert. Wenn ein Peer als IKEv2 konfiguriert ist, kann er nicht auf IKEv1 zurückgreifen, wenn sein Remotepeer die IKEv1-Aushandlung initiiert. Standardmäßig sind Sicherheitsgeräte von Juniper Networks IKEv1-Peers.

Verwenden Sie die configuration-Anweisung auf der Hierarchieebene [], um IKEv2 zu konfigurieren.version v2-onlyedit security ike gateway gw-name

Die IKE-Version wird in der Ausgabe des Befehls und des CLI-Befehls angezeigt.show security ike security-associationsshow security ipsec security-associations

Geräte von Juniper Networks unterstützen bis zu vier Vorschläge für Phase-2-Aushandlungen, sodass Sie festlegen können, wie restriktiv ein Bereich von Tunnelparametern ist, den Sie akzeptieren. Junos OS bietet vordefinierte standardmäßige, kompatible und grundlegende Phase-2-Vorschlagssätze. Sie können auch benutzerdefinierte Phase-2-Vorschläge definieren.

Grundlegendes zur Nutzlast der IKEv2-Konfiguration

Bei der Konfigurationsnutzlast handelt es sich um eine IKEv2-Option (Internet Key Exchange Version 2), die angeboten wird, um Bereitstellungsinformationen von einem Responder an einen Initiator weiterzugeben. Die IKEv2-Konfigurationsnutzlast wird nur mit routenbasierten VPNs unterstützt.

RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), definiert 15 verschiedene Konfigurationsattribute, die vom Responder an den Initiator zurückgegeben werden können. beschreibt die IKEv2-Konfigurationsattribute, die von Firewalls der SRX-Serie unterstützt werden.Tabelle 1

Tabelle 1: IKEv2-Konfigurationsattribute

Attributtyp

Wert

Beschreibung

Länge

INTERNAL_IP4_ADDRESS

1

Gibt eine Adresse im internen Netzwerk an. Es können mehrere interne Adressen angefordert werden. Der Responder kann bis zu der Anzahl der angeforderten Adressen senden.

0 oder 4 Oktette

INTERNAL_IP4_NETMASK

2

Gibt den Netzmaskenwert des internen Netzwerks an. In den Anforderungs- und Antwortnachrichten ist nur ein Netzmaskenwert zulässig (z. B. 255.255.255.0), und er darf nur mit einem INTERNAL_IP4_ADDRESS Attribut verwendet werden.

0 oder 4 Oktette

INTERNAL_IP4_DNS

3

Gibt die Adresse eines DNS-Servers innerhalb des Netzwerks an. Es können mehrere DNS-Server angefordert werden. Der Responder kann mit null oder mehr DNS-Serverattributen antworten.

0 oder 4 Oktette

INTERNAL_IP4_NBNS

4

Gibt die Adresse eines NetBIOS-Namenservers (NBNS), z. B. eines WINS-Servers, innerhalb des Netzwerks an. Es können mehrere NBNS-Server angefordert werden. Der Responder kann mit null oder mehr NBNS-Serverattributen antworten.

0 oder 4 Oktette

INTERNAL_IP6_ADDRESS

8

Gibt eine Adresse im internen Netzwerk an. Es können mehrere interne Adressen angefordert werden. Der Responder kann bis zu der Anzahl der angeforderten Adressen senden.

0 oder 17 Oktette

INTERNAL_IP6_DNS

10

Gibt die Adresse eines DNS-Servers innerhalb des Netzwerks an. Es können mehrere DNS-Server angefordert werden. Der Responder kann mit null oder mehr DNS-Serverattributen antworten.

0 oder 16 Oktette

Damit der IKE-Responder dem Initiator Bereitstellungsinformationen zur Verfügung stellen kann, muss er die Informationen aus einer angegebenen Quelle abrufen, z. B. einem RADIUS-Server. Bereitstellungsinformationen können auch von einem DHCP-Server über einen RADIUS-Server zurückgegeben werden. Auf dem RADIUS-Server sollten die Benutzerinformationen kein Authentifizierungskennwort enthalten. Das RADIUS-Serverprofil wird mithilfe der Konfiguration auf der Hierarchieebene [] an das IKE-Gateway gebunden.aaa access-profile profile-nameedit security ike gateway gateway-name

Beginnend mit Junos OS Version 20.3R1 haben wir auf SRX5000 Linie mit SPC3 und der virtuellen vSRX-Firewall, auf denen iked-Prozesse ausgeführt werden, die IKEv2-Konfigurationsnutzlast wie folgt verbessert:

  • Unterstützung für den lokalen IPv4- und IPv6-Adresspool. Sie können einem Peer auch eine feste IP-Adresse zuweisen.

    Während der IKE-Einrichtung fordert der Initiator eine IPv4-Adresse, IPv6-Adresse, DNS-Adresse oder WINS-Adresse vom Responder an. Nachdem der Responder den Initiator erfolgreich authentifiziert hat, weist er eine IP-Adresse entweder aus einem lokalen Adresspool oder über einen RADIUS-Server zu. Je nach Konfiguration wird diese IP-Adresse entweder jedes Mal dynamisch zugewiesen, wenn ein Peer eine Verbindung herstellt, oder als feste IP-Adresse zugewiesen. Wenn der RADIUS-Server mit einem gerahmten Pool antwortet, weist Junos OS eine IP-Adresse oder Informationen basierend auf der Konfiguration aus dem entsprechenden lokalen Pool zu. Wenn Sie sowohl den lokalen Adresspool als auch den RADIUS-Server konfigurieren, hat die vom RADIUS-Server zugewiesene IP-Adresse Vorrang vor dem lokalen Pool. Wenn Sie den lokalen IP-Adresspool konfigurieren und der RADIUS-Server keine IP-Adresse zurückgegeben hat, weist der lokale Pool der Anforderung die IP-Adresse zu.

  • Zusätzliche Option, eingeführt für .noneauthentication-order Weitere Informationen finden Sie unter Authentifizierungsreihenfolge (Zugriffsprofil).authentication-order (Access Profile)

  • Start- und Stoppmeldungen der RADIUS-Kontorechnung informieren über den Status des Tunnels oder Peers zum RADIUS-Server. Diese Nachrichten können für Nachverfolgungszwecke oder Benachrichtigungen an Subsysteme wie einen DHCP-Server verwendet werden.

    Stellen Sie sicher, dass der RADIUS-Server Start- oder Stoppmeldungen für das Accounting unterstützt. Stellen Sie außerdem sicher, dass sowohl die Firewalls der SRX-Serie als auch der RADIUS-Server über geeignete Einstellungen verfügen, um diese Meldungen zu verfolgen.

  • Die Einführung der IPv6-Unterstützung ermöglicht Dual-Stack-Tunnel unter Verwendung von Konfigurationsnutzlasten. Während des Anmeldevorgangs fordert IKE sowohl IPv4- als auch IPv6-Adressen an. AAA erlaubt die Anmeldung nur, wenn alle angeforderten Adressen erfolgreich zugewiesen wurden. IKE beendet die Aushandlung, wenn die angeforderte IP-Adresse nicht zugewiesen wird.

In einem routenbasierten VPN werden Secure Tunnel (st0)-Schnittstellen entweder im Punkt-zu-Mehrpunkt- oder im Punkt-zu-Punkt-Modus betrieben. Die Adresszuweisung über die IKEv2-Konfigurationsnutzlast wird jetzt für den Punkt-zu-Mehrpunkt- oder Punkt-zu-Punkt-Modus unterstützt. Bei Punkt-zu-Mehrpunkt-Schnittstellen müssen die Schnittstellen nummeriert sein, und die Adressen in der Konfigurationsnutzlast INTERNAL_IP4_ADDRESS der Attributtyp müssen innerhalb des Teilnetzbereichs der zugeordneten Punkt-zu-Mehrpunkt-Schnittstelle liegen.

Ab Junos OS Version 20.1R1 können Sie ein allgemeines Kennwort für IKEv2-Konfigurationsnutzlastanforderungen für eine IKE-Gateway-Konfiguration konfigurieren. Das allgemeine Kennwort im Bereich von 1 bis 128 Zeichen ermöglicht es dem Administrator, ein allgemeines Kennwort zu definieren. Dieses Kennwort wird zwischen der Firewall der SRX-Serie und dem RADIUS-Server verwendet, wenn die Firewall der SRX-Serie eine IP-Adresse im Namen eines Remote-IPsec-Peers mithilfe der IKEv2-Konfigurationsnutzlast anfordert. Der RADIUS-Server gleicht die Anmeldeinformationen ab, bevor er IP-Informationen an die Firewall der SRX-Serie für die Konfigurationsnutzlastanforderung übermittelt. Sie können das allgemeine Kennwort mithilfe der Konfigurationsanweisung auf der Hierarchieebene [] konfigurieren.config-payload-password configured-passwordedit security ike gateway gateway-name aaa access-profile access-profile-name

Sowohl für die Firewall der SRX-Serie als auch für den RADIUS-Server muss dasselbe Kennwort konfiguriert sein, und der RADIUS-Server sollte so konfiguriert sein, dass er das Password Authentication Protocol (PAP) als Authentifizierungsprotokoll verwendet. Ohne sie wird der Tunnelaufbau nicht erfolgreich sein.

Abbildung 7 zeigt einen typischen Workflow für eine IKEv2-Konfigurationsnutzlast.

Abbildung 7: Typischer IKEv2-Konfigurations-Payload-WorkflowTypischer IKEv2-Konfigurations-Payload-Workflow

Die IKEv2-Konfigurationsnutzlastfunktion wird sowohl für Point-to-Multipoint Secure Tunnel (st0)-Schnittstellen als auch für Point-to-Point-Schnittstellen unterstützt. Punkt-zu-Mehrpunkt-Schnittstellen müssen nummeriert sein, und die in der Konfigurationsnutzlast angegebenen Adressen müssen innerhalb des Teilnetzbereichs der zugeordneten Punkt-zu-Mehrpunkt-Schnittstelle liegen.

Ab Junos OS Version 20.1R1 unterstützen wir die IKEv2-Konfigurationsnutzlastfunktion mit Punkt-zu-Punkt-Schnittstellen auf SRX5000 Linie und vSRX Virtual Firewall mit iked.

Grundlegendes zur Bereitstellung von Pico-Zellen

Die IKEv2-Konfigurationsnutzlast kann verwendet werden, um Bereitstellungsinformationen von einem IKE-Responder, z. B. einer Firewall der SRX-Serie, an mehrere Initiatoren, z. B. LTE-Pico-Zellen-Basisstationen in einem Mobilfunknetz, weiterzugeben. Die Pico-Zellen werden ab Werk mit einer Standardkonfiguration ausgeliefert, die eine Verbindung mit der Firewall der SRX-Serie ermöglicht, aber die Pico-Zellen-Bereitstellungsinformationen werden auf einem oder mehreren Provisioning-Servern in einem geschützten Netzwerk gespeichert. Die Pico-Zellen erhalten vollständige Bereitstellungsinformationen, nachdem sie sichere Verbindungen mit den Bereitstellungsservern hergestellt haben.

Der Arbeitsablauf, der erforderlich ist, um eine Pico-Zelle zu booten, bereitzustellen und in Betrieb zu nehmen, umfasst vier verschiedene Phasen:

  1. Erwerb der ersten Adressen: Die Pico-Zelle wird ab Werk mit den folgenden Informationen ausgeliefert:

    • Konfiguration für den Secure Gateway-Tunnel zur Firewall der SRX-Serie

    • Digitales Zertifikat, ausgestellt vom Hersteller

    • Vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) der Provisioning-Server, die sich im geschützten Netzwerk befinden

    Die Pico-Zelle wird hochgefahren und erhält von einem DHCP-Server eine Adresse, die für die IKE-Aushandlung verwendet werden soll. Unter Verwendung dieser Adresse wird dann ein Tunnel zum sicheren Gateway auf der Firewall der SRX-Serie aufgebaut. Eine Adresse für OAM-Datenverkehr (Operation, Administration and Management) wird ebenfalls vom DHCP-Server für die Verwendung im geschützten Netzwerk zugewiesen.

  2. Bereitstellung von Pico-Zellen – Unter Verwendung der ihr zugewiesenen OAM-Datenverkehrsadresse fordert die Pico-Zelle ihre Bereitstellungsinformationen – in der Regel Betreiberzertifikat, Lizenz, Software und Konfigurationsinformationen – von Servern innerhalb des geschützten Netzwerks an.

  3. Neustart: Die Pico-Zelle wird neu gestartet und verwendet die erfassten Bereitstellungsinformationen, um sie für das Netzwerk und das Betriebsmodell des Service Providers spezifisch zu machen.

  4. Servicebereitstellung – Wenn die Pico-Zelle in Betrieb genommen wird, verwendet sie ein einzelnes Zertifikat, das Werte für den definierten Namen (DN) und alternative Antragstellernamen mit einem FQDN enthält, um zwei Tunnel zum sicheren Gateway auf der Firewall der SRX-Serie aufzubauen: eine für den OAM-Datenverkehr und die andere für den Datenverkehr des Third-Generation Partnership Project (3GPP).

IKE-Vorschlag

Die IKE-Konfiguration definiert die Algorithmen und Schlüssel, die zum Herstellen der sicheren IKE-Verbindung mit dem Peersicherheitsgateway verwendet werden. Sie können einen oder mehrere IKE-Vorschläge konfigurieren. Jeder Vorschlag ist eine Liste von IKE-Attributen zum Schutz der IKE-Verbindung zwischen dem IKE-Host und seinem Peer.

Um einen IKE-Vorschlag zu konfigurieren, fügen Sie die Anweisung ein, und geben Sie einen Namen auf der Hierarchieebene [] an:proposaledit security ike

IKE-Richtlinie

Eine IKE-Richtlinie definiert eine Kombination von Sicherheitsparametern (IKE-Vorschlägen), die während der IKE-Aushandlung verwendet werden sollen. Er definiert eine Peer-Adresse und die Vorschläge, die für diese Verbindung erforderlich sind. Je nachdem, welche Authentifizierungsmethode verwendet wird, definiert es den vorinstallierten Schlüssel für den jeweiligen Peer oder das lokale Zertifikat. Während der IKE-Aushandlung sucht IKE nach einer IKE-Richtlinie, die auf beiden Peers identisch ist. Der Peer, der die Aushandlung initiiert, sendet alle seine Richtlinien an den Remotepeer, und der Remotepeer versucht, eine Übereinstimmung zu finden. Eine Übereinstimmung wird vorgenommen, wenn beide Richtlinien der beiden Peers einen Vorschlag haben, der die gleichen konfigurierten Attribute enthält. Wenn die Gültigkeitsdauer nicht identisch ist, wird die kürzere Gültigkeitsdauer zwischen den beiden Richtlinien (vom Host und vom Peer) verwendet. Der konfigurierte vorinstallierte Schlüssel muss auch mit seinem Peer übereinstimmen.

Zuerst konfigurieren Sie einen oder mehrere IKE-Vorschläge. dann verknüpfen Sie diese Vorschläge mit einer IKE-Richtlinie.

Um eine IKE-Richtlinie zu konfigurieren, schließen Sie die Anweisung ein, und geben Sie einen Richtliniennamen auf der Hierarchieebene [] an:policyedit security ike

Erneute Schlüsselerstellung und erneute Authentifizierung

Überblick

Bei IKEv2 sind die erneute Schlüsselerstellung und die erneute Authentifizierung getrennte Prozesse. Durch die erneute Schlüsselerstellung werden neue Schlüssel für die IKE-Sicherheitszuordnung (Security Association, SA) erstellt und Nachrichten-ID-Leistungsindikatoren zurückgesetzt, die Peers werden jedoch nicht erneut authentifiziert. Bei der erneuten Authentifizierung wird überprüft, ob VPN-Peers ihren Zugriff auf Authentifizierungsanmeldeinformationen behalten. Bei der erneuten Authentifizierung werden neue Schlüssel für die IKE-Sicherheitszuordnung und die untergeordneten Sicherheitszuordnungen erstellt. Neuschlüssel einer ausstehenden IKE-SA oder untergeordneten SA werden nicht mehr benötigt. Nachdem die neue IKE und die untergeordneten Sicherheitszuordnungen erstellt wurden, werden die alte IKE und die untergeordneten Sicherheitszuordnungen gelöscht.

Die erneute IKEv2-Authentifizierung ist standardmäßig deaktiviert. Sie aktivieren die erneute Authentifizierung, indem Sie einen Wert für die Häufigkeit der erneuten Authentifizierung zwischen 1 und 100 konfigurieren. Die Häufigkeit der erneuten Authentifizierung ist die Anzahl der erneuten IKE-Schlüssel, die vor der erneuten Authentifizierung erfolgen. Wenn z. B. die konfigurierte Häufigkeit der erneuten Authentifizierung 1 ist, erfolgt die erneute Authentifizierung jedes Mal, wenn ein IKE-Neuschlüssel erfolgt. Wenn die konfigurierte Häufigkeit der erneuten Authentifizierung 2 ist, erfolgt die erneute Authentifizierung bei jedem zweiten erneuten IKE-Schlüssel. Wenn die konfigurierte Häufigkeit der erneuten Authentifizierung 3 beträgt, erfolgt die erneute Authentifizierung bei jedem dritten erneuten IKE-Schlüssel usw.

Sie konfigurieren die Häufigkeit der erneuten Authentifizierung mit der Anweisung auf der Hierarchieebene [].reauth-frequencyedit security ike policy policy-name Die erneute Authentifizierung wird deaktiviert, indem die Häufigkeit der erneuten Authentifizierung auf 0 (Standardeinstellung) festgelegt wird. Die Häufigkeit der erneuten Authentifizierung wird nicht von Peers ausgehandelt, und jeder Peer kann seinen eigenen Wert für die Häufigkeit der erneuten Authentifizierung haben.

Unterstützte Funktionen

Die erneute IKEv2-Authentifizierung wird mit den folgenden Funktionen unterstützt:

  • IKEv2-Initiatoren oder -Responder

  • Dead Peer Detection (DPD)

  • Virtuelle Router und Secure Tunnel (st0)-Schnittstellen in virtuellen Routern

  • Network Address Translation Traversal (NAT-T)

  • Chassis-Cluster im Aktiv-Aktiv- und Aktiv-Passiv-Modus für SRX5400-, SRX5600- und SRX5800 Geräte

  • In-Service-Software-Upgrade (ISSU) auf SRX5400-, SRX5600- und SRX5800 Geräten

  • Upgrade oder Einsetzen einer neuen Services Processing Unit (SPU) unter Verwendung des In-Service-Hardware-Upgrade-Verfahrens (ISHU)

Einschränkungen

Beachten Sie die folgenden Einschränkungen bei Verwendung der erneuten IKEv2-Authentifizierung:

  • Mit NAT-T kann eine neue IKE-SA mit anderen Ports als der vorherigen IKE-SA erstellt werden. In diesem Szenario wird die alte IKE-SA möglicherweise nicht gelöscht.

  • In einem NAT-T-Szenario kann der Initiator hinter dem NAT-Gerät nach einer erneuten Authentifizierung zum Responder werden. Wenn die NAT-Sitzung abläuft, verwirft das NAT-Gerät möglicherweise neue IKE-Pakete, die möglicherweise an einem anderen Port eingehen. NAT-T-Keepalive oder DPD muss aktiviert sein, um die NAT-Sitzung am Leben zu erhalten. Für AutoVPN empfehlen wir, dass die auf den Spokes konfigurierte Häufigkeit der erneuten Authentifizierung kleiner ist als die auf dem Hub konfigurierte Häufigkeit der erneuten Authentifizierung.

  • Basierend auf der Häufigkeit der erneuten Authentifizierung kann eine neue IKE-SA entweder vom Initiator oder vom Responder der ursprünglichen IKE-SA initiiert werden. Da die EAP-Authentifizierung (Extensible Authentication Protocol)-Authentifizierungs- und Konfigurationsnutzlast erfordert, dass die IKE-SA von derselben Partei wie die ursprüngliche IKE-SA initiiert wird, wird eine erneute Authentifizierung mit EAP-Authentifizierungs- oder Konfigurationsnutzdaten nicht unterstützt.

IKE-Authentifizierung (zertifikatsbasierte Authentifizierung)

Mehrstufige Hierarchie für die Zertifikatsauthentifizierung

Die zertifikatbasierte Authentifizierung ist eine Authentifizierungsmethode, die von Firewalls der SRX-Serie während der IKE-Aushandlung unterstützt wird. In großen Netzwerken können mehrere Zertifizierungsstellen (CAs) Endentitätszertifikate (EE-Zertifikate) für ihre jeweiligen Endgeräte ausstellen. Es ist üblich, separate Zertifizierungsstellen für einzelne Standorte, Abteilungen oder Organisationen zu haben.

Wenn eine einstufige Hierarchie für die zertifikatbasierte Authentifizierung verwendet wird, müssen alle EE-Zertifikate im Netzwerk von derselben Zertifizierungsstelle signiert werden. Für die Überprüfung des Peerzertifikats muss auf allen Firewallgeräten dasselbe CA-Zertifikat registriert sein. Die Zertifikatsnutzlast, die während der IKE-Aushandlung gesendet wird, enthält nur EE-Zertifikate.

Alternativ kann die Zertifikatsnutzlast, die während der IKE-Aushandlung gesendet wird, eine Kette von EE- und CA-Zertifikaten enthalten. Eine Zertifikatskette ist die Liste der Zertifikate, die erforderlich sind, um das EE-Zertifikat eines Peers zu validieren. Die Zertifikatskette umfasst das EE-Zertifikat und alle CA-Zertifikate, die im lokalen Peer nicht vorhanden sind.

Der Netzwerkadministrator muss sicherstellen, dass alle Peers, die an einer IKE-Aushandlung teilnehmen, mindestens eine gemeinsame vertrauenswürdige Zertifizierungsstelle in ihren jeweiligen Zertifikatsketten haben. Die allgemein vertrauenswürdige Zertifizierungsstelle muss nicht die Stammzertifizierungsstelle sein. Die Anzahl der Zertifikate in der Kette, einschließlich der Zertifikate für EEs und der obersten Zertifizierungsstelle in der Kette, darf 10 nicht überschreiten.

Ab Junos OS Version 18.1R1 kann die Validierung eines konfigurierten IKE-Peers mit einem angegebenen CA-Server oder einer Gruppe von CA-Servern erfolgen. Bei Zertifikatketten muss die Stammzertifizierungsstelle mit der vertrauenswürdigen Zertifizierungsstellengruppe oder dem Zertifizierungsstellenserver übereinstimmen, die bzw. der in der IKE-Richtlinie konfiguriert ist

In der Beispiel-Zertifizierungsstellenhierarchie unter Abbildung 8ist die Stammzertifizierungsstelle die allgemeine vertrauenswürdige Zertifizierungsstelle für alle Geräte im Netzwerk. Die Stammzertifizierungsstelle stellt Zertifizierungsstellenzertifikate für die technischen und Vertriebszertifizierungsstellen aus, die als "Eng-CA" bzw. "Sales-CA" bezeichnet werden. Eng-CA stellt CA-Zertifikate für die Entwicklungs- und Qualitätssicherungsstellen aus, die als Dev-CA bzw. Qa-CA bezeichnet werden. Host-A erhält sein EE-Zertifikat von Dev-CA, während Host-B sein EE-Zertifikat von Sales-CA erhält.

Abbildung 8: Mehrstufige Hierarchie für zertifikatsbasierte AuthentifizierungMehrstufige Hierarchie für zertifikatsbasierte Authentifizierung

Jedes Endgerät muss mit den CA-Zertifikaten in seiner Hierarchie geladen werden. Host-A muss über Root-CA-, Eng-CA- und Dev-CA-Zertifikate verfügen. Sales-CA- und Qa-CA-Zertifikate sind nicht erforderlich. Host-B muss über Root-CA- und Sales-CA-Zertifikate verfügen. Zertifikate können manuell in ein Gerät geladen oder mit dem Simple Certificate Enrollment Process (SCEP) registriert werden.

Jedes Endgerät muss für jede CA in der Zertifikatskette mit einem CA-Profil konfiguriert werden. Die folgende Ausgabe zeigt die auf Host-A konfigurierten Zertifizierungsstellenprofile:

Die folgende Ausgabe zeigt die auf Host-B konfigurierten Zertifizierungsstellenprofile:

IKE-Schutz vor DDoS-Angriffen

SUMMARY In diesem Thema erfahren Sie, wie Juniper IPsec-VPN-IKE-Implementierungen vor DDoS-Angriffen (Enial-of-S-Service) schützt und die Implementierungen überwacht.

Denial of S Service (DoS) ist einer der häufigsten und zugleich schwerwiegendsten Angriffe in einem unsicheren IPsec-VPN-Netzwerk. Ein DoS-Angriff bietet eine schnelle und einfache Möglichkeit, sich das Netzwerk zu bemächtigen, da er nicht viel Halt in der Netzwerkinfrastruktur erfordert. Die Cyberangreiferwählen diese Methode, um die Kontrolle über das Netzwerk zu übernehmen.

Was passiert bei einem DoS-Angriff?

Der Angreifer versucht, das Netzwerk mit zu viel Datenverkehr zu überfluten und allmählich zum Absturz zu bringen, wodurch die Netzwerkressourcen erschöpft werden und die Kontrolle über die Geräteressourcen wie Arbeitsspeicher und CPU weiter übernommen wird. Wenn der Angreifer versucht, mehrere orchestrierte Systeme zu kontrollieren und gleichzeitig ein einzelnes Ziel anzugreifen, spricht man von Distributed-DoS-Angriffen (DDoS).

DDoS-Schwachstellen bei IKE-Implementierungen

Wenn der Remotepeer (Initiator) eine SA_INIT Nachricht sendet, antwortet der lokale Peer (Responder) und weist Speicher für die Nachrichtenstruktur zu. Wir bezeichnen die Sitzung als halboffene IKE-Sitzung, bis die Authentifizierung mit der IKE_AUTH Nachricht erfolgt.Nachdem die Peers eine IKE-Sicherheitszuordnung (SA) eingerichtet haben, wird die Sitzung als vollständig offene IKE-Sitzung bezeichnet.

Um die IKEv2 DDoS-Schwachstellen zu verstehen, sehen wir uns einige der Möglichkeiten an, wie ein Angreifer einen einfachen Angriffsvektor gegen die IKE-SAs erstellen kann:

  • Senden Sie große Mengen SA_INIT Nachrichten (ohne IKE_AUTH Nachrichten), für die der Angreifer halboffene IKE-Sicherheitszuordnungsstrukturen erstellen kann. Dies führt dazu, dass das Gerät die Ressourcen nutzt und der Arbeitsspeicher knapp wird.

  • Senden Sie eine große Menge an Junk-IKE_AUTH Paketen mit korrekten SPI_i und SPI_r auf dem Initiator bzw. dem Responder. Dies führt dazu, dass dem Gerät beim Versuch, die Pakete zu entschlüsseln, der Arbeitsspeicher ausgeht.

  • Senden Sie kontinuierlich SA_INIT Pakete. Dies führt dazu, dass dem Gerät beim Versuch, Schlüssel für verschlüsselte Pakete zu generieren, der Arbeitsspeicher ausgeht.

  • Senden Sie eine große Anzahl von Anforderungen zur erneuten Schlüsselerstellung pro Sekunde während vollständig geöffneter IKE-Sitzungen.

  • Senden Sie große Mengen von Nachrichten mit unterschiedlichen Nachrichten-IDs. Dies führt dazu, dass das Gerät alle eingehenden IKE-Nachrichten in die Warteschlange stellt und nicht genügend Speicher zur Verfügung steht.

So schützen Sie die IKE-Implementierungen

Wir bieten eine robuste Infrastruktur zur Abwehr und Überwachung von DDoS-Angriffen sowohl für das IKEv1- als auch für das IKEv2-Protokoll. Sie können sich vor Angriffen auf IKE-Implementierungen schützen, wenn Ihre Firewall den iked-Prozess ( Paket) für den IPsec-VPN-Dienst ausführt.junos-ike

HINWEIS:

Weitere Informationen zum DDoS-Schutz für IKEv2 finden Sie unter RFC 8019, Schutz von IKEv2-Implementierungen (Internet Key Exchange Protocol Version 2) vor verteilten Denial-of-Service-Angriffen. Der im RFC vorhandene Client-Puzzle-Mechanismus wird nicht unterstützt. Während der IKEv2-DDoS-Schutz auf RFC 8019 basiert, bieten wir einen ähnlichen Schutz für IKEv1, wenn Ihre Firewall den IPsec-VPN-Dienst mit dem iked-Prozess ausführt.

Schutz vor DDoS-Angriffen

Sie können mehrere Schutzmechanismen gegen DDoS-Angriffe während des Erstellungsprozesses der IKE-Sicherheitszuordnung aktivieren. Zu diesen Mechanismen gehören die Konfiguration der Ratenbegrenzung und eines Aufbewahrungszeitraums für die halboffenen IKE-Sicherheitszuordnungen sowie die weitere Verwaltung der eingehenden Wechselkurse für die Anforderungen zur erneuten Schlüsselerstellung. Wir stellen die folgenden Maßnahmen bereit, um den Schutz zu gewährleisten:

  • Für halboffene IKE-SAs:
    • Der Responder lässt für eine bestimmte Dauer keine Konfiguration der halb geöffneten IKE-SA zu. Sie können diesen Grenzwert so festlegen, dass der Responder erst konfiguriert wird, wenn er die Timeoutdauer erreicht hat. Weitere Informationen finden Sie unter der Option .session (Security IKE)timeout

    • Sie können den Grenzwert für die maximal zulässigen halb geöffneten IKE-Sicherheitszuordnungen auf dem Responder festlegen. Wenn die Gesamtzahl der halb geöffneten IKE-Sicherheitszuordnungen die maximale Anzahl erreicht, lehnt der Responder neue Verbindungen sowohl für IKEv1- als auch für IKEv2-Sicherheitszuordnungen ab. Weitere Informationen finden Sie unter der Option .session (Security IKE)max-count

    • Der Responder erzwingt Schwellenwerte für die Sitzungsanzahl für halb geöffnete IKE-Sicherheitszuordnungen. Wenn die Gesamtzahl der halb geöffneten IKE-Sicherheitseinrichtungen Schwellenwerte erreicht,

      • Im Falle von IKEv2-Sicherheitszuordnungen ruft der Responder den Cookie-Mechanismus für alle neuen Verbindungen auf.

      • Bei IKEv1-Sicherheitszuordnungen lehnt der Responder neue Verbindungen ab.

      Weitere Informationen finden Sie unter den Optionen und . session (Security IKE)thresholdssend-cookiereduce-timeout

    • Der Responder kann doppelte Sitzungen verwerfen. Weitere Informationen finden Sie unter der Option .session (Security IKE)discard-duplicate

    • Sie können Backoff-Timeouts für Authentifizierungsfehler und Initiierungsfehlerphasen festlegen. Weitere Informationen finden Sie unter den Optionen und . session (Security IKE)backoff-timeoutsinit-phase-failureauth-phase-failure

  • Für vollständig geöffnete IKE-Sicherheitszuordnungen:

    • Sie können die maximalen Raten eingehender Neuschlüsselanforderungen konfigurieren, um die Anforderungen in einem skalierten Szenario zu drosseln. Weitere Informationen finden Sie unter der Option .session (Security IKE)incoming-exchange-max-rates

  • Der Responder kann eine eingehende IKE-Sitzung von Peers basierend auf der Peer-IKE-ID blockieren. Weitere Informationen finden Sie unter .blocklists (Security IKE)RLI41450 Review this entire topic

  • Bei dynamischen Gateways können Sie mit der Option ein Limit für die Anzahl der Verbindungen auf IKE-Gateway-Konfigurationsebene festlegen.connections-limit Weitere Informationen finden Sie unter Gateway (Sicherheits-IKE)./documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-gateway-ike.html

Weitere Informationen zum Konfigurieren dieser Optionen finden Sie unterKonfigurieren des Schutzes vor IKE-DDoS-Angriffen.Konfigurieren des Schutzes vor IKE-DDoS-Angriffen

Wir unterstützen nicht:

  • DDoS-Schutz mit IPsec-VPN-Dienst basierend auf dem kmd-Verfahren.

  • Schutz vor Hash- und URL-Zertifikatskodierungsangriffen , da wir diese Kodierungstypen nicht unterstützen.

Möglichkeiten zur Überwachung von DDoS-Angriffen

Wir stellen die folgenden Mechanismen zur Überwachung der DDoS-Angriffe zur Verfügung:

Konfigurieren des Schutzes vor IKE-DDoS-Angriffen

SUMMARY In diesem Abschnitt erfahren Sie, wie Sie den Schutz vor DDoS-Angriffen auf das IKE-Protokoll konfigurieren.

Voraussetzungen

Bevor Sie den Schutz vor IKE-DDoS-Angriffen konfigurieren, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen:

  • Firewall der SRX-Serie, die ein Paket zum Ausführen des IPsec-VPN-Dienstes mithilfe des iked-Prozesses unterstützt .junos-ike

  • Die Firewall der SRX-Serie, die als lokaler Endpunkt (Responder) dient, ist für den Remote-IKE-Peer (den Initiator) erreichbar.

  • Eine IKE-Richtlinie, die eine IKE-Sperrliste zuordnen kann.

Die folgenden Aktionen sind an der Konfiguration des Schutzes vor IKE-DDoS-Angriffen beteiligt:

  • Verwalten Sie die eingehenden halboffenen IKE-SAs.

  • Verwalten Sie die eingehenden vollständig geöffneten IKE-Sicherheitszuordnungen.

  • Konfigurieren Sie mehrere Blockierungsmethoden, um die eingehenden IKE-Sitzungen von verschiedenen Peers zu blockieren und eine der Blockierungslisten einem IKE-Peer zuzuordnen.

Informationen zum Konfigurieren dieser Aktionen finden Sie in den folgenden Aufgaben.

Konfigurieren der IKE-Sitzung für halboffene IKE-Sicherheitszuordnungen

Überblick

Stellen Sie sicher, dass Sie alle oben genannten Voraussetzungen erfüllen.

In diesem Abschnitt erfahren Sie, wie Sie die Timeouts, die maximale Anzahl und die Schwellenwerte für die halb geöffneten IKE-SAs konfigurieren. Die Konfigurationsänderungen gelten für die neuen Sitzungen, während die vorhandenen Sitzungen weiterhin die Standardwerte verwenden, wenn sie nicht explizit zuvor konfiguriert wurden. Der Umfang dieser Konfigurationen auf der Hierarchieebene [] gilt auf globaler Ebene und nicht pro Peerebene.edit security ike session half-open

Konfiguration

  • So legen Sie den Parameter für die Lebensdauer des Responders mit der folgenden Option fest:timeout seconds

    Während dieses Zeitraums lässt der Responder die Konfiguration halboffener IKE-Sicherheitszuordnungen erst zu, wenn die Timeoutdauer erreicht ist. Der Initiator kann unabhängig von der Konfiguration des Responders weiterhin eine Timeoutdauer von 60 Sekunden haben.

  • So legen Sie den Parameter für die maximale Anzahl des Responders mithilfe der folgenden Option fest:max-count value

    Mit dieser Option wird die maximale Anzahl halb geöffneter IKE-Sitzungen auf dem Responder festgelegt. Der Standardwert ist 300, wenn Sie diesen Wert nicht angeben. Die Konfiguration deaktiviert alle Schwellenwerte.max-count In solchen Fällen müssen Sie Schwellenwerte explizit konfigurieren, um sie durchzusetzen.

  • Geben Sie die verschiedenen Arten von Aktionen an, indem Sie die Option verwenden, wenn die Sitzungsanzahl des Responders das Limit erreicht.threshold

    • So legen Sie die Mindestanzahl halb geöffneter IKE-Sitzungen fest, um Cookie-Aktionen zu erzwingen, indem Sie die folgende Option verwenden:send-cookie count

      Dies gibt den Schwellenwert an, ab dem der Responder die Remotepeers auffordert, die Sitzungsinitiierung mit einem Cookie zu wiederholen, das in der ersten Antwort an den Peer zurückgesendet wird. Wenn die Begrenzung für die Anzahl der halb geöffneten IKE-Sitzungen 500 erreicht, verwendet der iked-Prozess einen Cookie-Mechanismus für die neuen IKE-Sitzungen.

    • So legen Sie die Mindestanzahl halb geöffneter IKE-Sitzungen fest, um eine Aktion mit reduzierter Zeitüberschreitung zu erzwingen, indem Sie die Option verwenden:reduced-timeout count timeout seconds

      Dies gibt den Grenzwert an, ab dem der iked-Prozess die Lebensdauer der neuen halboffenen IKE-Sicherheitszuordnungen reduziert. Sobald die Anzahl der halb geöffneten Responder-IKE-Sitzungen unter den Schwellenwert sinkt, verwenden die halb geöffneten Responder-IKE-Sitzungen wieder den Standardtimeoutwert.

  • So legen Sie die Option fest, um die doppelten halb geöffneten IKE-Sitzungen zu verwerfen, ohne eine Antwort an den Initiator zurückzusenden:discard-duplicate

    Bei einer doppelten Sitzungsinitiierungsanforderung (SA_INIT), die vom selben Peer mit einem anderen Initiatorcookie stammt, für das während der Aushandlung keine IKE-SA vorhanden ist, verwirft der Responder das Paket.

  • Sie können die Backoff-Timeouts mit der Option festlegen.backoff-timeouts

    Dies gibt dem Remotepeer etwas Zeit, sich im Falle eines Fehlschlags bei der Sitzungsinitiierung zurückzusetzen, wodurch sichergestellt wird, dass derselbe Peer während dieses Zeitraums keine neue Sitzung initiieren kann. Nach dem Backoff-Timeout kann der Peer eine neue Sitzung initiieren. Die Sitzungsinitiierung kann in zwei Phasen fehlschlagen: in der Initialisierungsphase und in der Authentifizierungsphase.

    • So legen Sie das Backoff-Timeout fest, wenn während der IKE_AUTH-Phase ein Fehler auftritt, indem Sie die Option verwenden:backoff-timeouts auth-phase-failure value

      Wenn Sie konfigurieren, werden alle Remotepeers, die auf der Sperrliste stehen, auch dann zurückgesetzt, wenn Sie das Backoff nicht als Aktion für die Zielblocklistenregel konfigurieren.auth-phase-failure Das Timeout für das Backoff ist dasjenige, das für konfiguriert ist.auth-phase-failure In diesem Beispiel startet das Gerät nach 150 Sekunden eine neue Sitzung. Um dieses Backoff-Timeout für eine bestimmte Regel zu überschreiben, können Sie explizit die Aktion für die Blockliste konfigurieren, in der das Timeout bei [.backoffruleedit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level

    • So legen Sie das Backoff-Timeout fest, wenn während der SA_INIT-Phase ein Fehler auftritt, indem Sie die Option verwenden:backoff-timeouts init-phase-failure value

      In diesem Beispiel startet das Gerät nach 160 Sekunden eine neue Sitzung.

    • So legen Sie den Parameter für die Lebensdauer des Responders mit der folgenden Option fest:timeout seconds

      Während dieses Zeitraums lässt der Responder die Konfiguration halboffener IKE-Sicherheitszuordnungen erst zu, wenn die Timeoutdauer erreicht ist. Der Initiator kann unabhängig von der Konfiguration des Responders weiterhin eine Timeoutdauer von 60 Sekunden haben.

Konfigurieren der IKE-Sitzung für vollständig geöffnete IKE-Sicherheitszuordnungen

Überblick

Stellen Sie sicher, dass Sie alle oben genannten Voraussetzungen erfüllen.

In diesem Abschnitt erfahren Sie, wie Sie verschiedene eingehende Anforderungsraten für die vollständig geöffneten IKE-Sicherheitszuordnungen konfigurieren, indem Sie die Option auf der Hierarchieebene [] verwenden.incoming-exchange-max-ratesedit security ike session full-open

Konfiguration

Konfigurieren Sie die Option zum Festlegen der maximalen Raten für verschiedene Austauschvorgänge, die vom Remote-Peer nach dem Einrichten einer IKE-SA initiiert werden.incoming-exchange-max-rates Sie können drei Arten von Wechselkursen konfigurieren: IKE-Neuschlüssel, IPsec-Neuschlüssel und Keepalive (auch als Dead Peer-Erkennung bezeichnet).

  • So legen Sie die maximale Rate für eingehende Peer-initiierte IKE-Neuschlüssel mithilfe der folgenden Option fest:incoming-exchange-max-rates ike-rekey value

    Die Option gilt für die erneute Schlüsselerstellung von IKEv2 pro Peer mit einem vorhandenen Peer, bei dem bereits eine IKE-SA vorhanden ist.

  • So legen Sie die maximale Rate für die eingehende Peer-initiierte IPsec-SA-Neuschlüsselung mithilfe der folgenden Option fest:incoming-exchange-max-rates ipsec-rekey value

    Der Grenzwert gilt für jeden Tunnel.

  • So legen Sie die maximale Keepalive-Rate für eingehende Peer-initiierte Personen mit der folgenden Option fest:incoming-exchange-max-rates keepalive value

    Das Limit gilt für jeden Peer.

Konfigurieren der Blocklisten für IKE-Sitzungen

Überblick

Stellen Sie sicher, dass Sie alle oben genannten Voraussetzungen erfüllen.

Um eine eingehende IKE-Sitzung von Peers basierend auf der Peer-IKE-ID zu blockieren, müssen Sie eine oder mehrere Blockierlisten konfigurieren. Jede Blockierliste enthält eine oder mehrere Regeln. Jede Regel hat ein Übereinstimmungskriterium und eine Aktion.

Berücksichtigen Sie bei der Konfiguration der Blocklisten die folgenden Kriterien:

  • Sperrlistenregeln gelten für die neuen IKE-Sicherheitszuordnungen, die ausgehandelt werden, und wirken sich nicht auf die vorhandenen IKE-Sicherheitszuordnungen aus. In der Phase der Peerauthentifizierung wendet das Gerät die Sperrlistenregeln an.

  • Die Reihenfolge der Anwendung der Regeln hängt von der Reihenfolge ab, in der diese Regeln aufgeführt sind.

  • Konfigurieren Sie die Übereinstimmungskriterien basierend auf der Rolle (Initiator oder Responder), einem ID-Typ (IPv4- oder IPv6-Adresse, Hostname, Distinguished Name, E-Mail-ID oder eine Schlüssel-ID) und einem ID-Muster, bei dem es sich um einen regulären Ausdruck handelt, der mit der IKE-ID übereinstimmt.

  • Sie können jede Regel mit einem ID-Typ konfigurieren. Auf diese Weise können Sie verschiedene IKE-IDs für verschiedene Regeln innerhalb derselben Blockierliste konfigurieren.

  • Konfigurieren Sie eine Aktion, um die Peerverbindung entweder zu verwerfen oder abzulehnen. Basierend auf der Übereinstimmung wendet das Gerät eine Aktion an. Optional können Sie den Backoff-Timer mit diesen Aktionen festlegen.

  • Verweisen Sie auf die Blockliste in der IKE-Richtlinie, die dem IKE-Gateway zugeordnet ist.

  • Jedes IKE-Gateway unterstützt nur einen Typ von Remote-IKE-ID-Typ . Wenn Sie eine Blockierliste an ein Gateway anhängen und sie mit Regeln konfigurieren, die unterschiedliche IKE-IDs enthalten, wendet das Gateway nur die Regeln an und stimmt mit ihnen überein, deren IKE-ID-Typ mit dem für das IKE-Gateway konfigurierten identisch ist.

  • Die Metriken für die Tunneleinrichtungsrate mit Blocklisten, die an die IKE-Gateways angehängt sind, basieren auf der Anzahl der in den Blocklisten konfigurierten Regeln.

In diesem Abschnitt erfahren Sie, wie Sie Blockierlisten konfigurieren und die Blockierliste einer IKE-Richtlinie zuordnen.

Konfiguration

  • So erstellen Sie eine Blockierliste mit mehreren Regeln:

    • Erstellen Sie eine Blockierliste.

    • Erstellen Sie eine oder mehrere Regeln.

    Sie können mehrere solcher Blocklisten und deren Regeln erstellen.

  • So konfigurieren Sie die Übereinstimmungskriterien und geben die Aktion an:

    • Konfigurieren Sie die Übereinstimmungskriterien für die in der Sperrliste .rule1blocklist1

      Um Blocklisten mit einer Gruppe von IKE-IDs oder partiellen IKE-IDs zu konfigurieren, verwenden Sie das mit einem Suffix oder Präfix.id-pattern value Sie können z. B. den Wert *.example.com verwenden, wenn Sie hr.example.com, finance.example.com admin.example.com abgleichen müssen. In der Regel sucht das Gerät nach dem Hostnamen, der dem Muster entspricht.rule1peer.*\.example\.net Hier sind peer.example.net, peer.1.example.net und peer.uplink.example.net einige mögliche Übereinstimmungen. In der Regel sucht das Gerät nach der E-Mail-Adresse, die dem Muster entspricht.rule2hr.example.com Auf ähnliche Weise können Sie ein anderes Übereinstimmungskriterium für die anderen Regeln konfigurieren, das auf anderen oder .id-typeid-pattern Diese Muster verwenden den regulären Standardausdruck.

    • Geben Sie die Aktion für eine Übereinstimmung an:

  • So verknüpfen Sie eine Blockierliste mit einem IKE-Peer:

    • Konfigurieren Sie die Sperrliste in der IKE-Richtlinie .blocklist1ike_policy1

Beispiel: Konfigurieren eines Geräts für die Überprüfung der Peerzertifikatskette

In diesem Beispiel wird gezeigt, wie ein Gerät für Zertifikatsketten konfiguriert wird, die zur Überprüfung von Peergeräten während der IKE-Aushandlung verwendet werden.

Anforderungen

Bevor Sie beginnen, besorgen Sie sich die Adresse der Zertifizierungsstelle (Certificate Authority, CA) und die Informationen, die diese benötigt (z. B. das Abfragekennwort), wenn Sie Anforderungen für lokale Zertifikate übermitteln.

Überblick

In diesem Beispiel wird gezeigt, wie Sie ein lokales Gerät für Zertifikatketten konfigurieren, Zertifizierungsstellen und lokale Zertifikate registrieren, die Gültigkeit registrierter Zertifikate überprüfen und den Sperrstatus des Peergeräts überprüfen.

Topologie

Dieses Beispiel zeigt die Konfigurations- und Betriebsbefehle auf Host-A, wie in Abbildung 9gezeigt. Auf Host-A wird automatisch ein dynamisches CA-Profil erstellt, damit Host-A die CRL von Sales-CA herunterladen und den Sperrstatus des Zertifikats von Host-B überprüfen kann.

Abbildung 9: Beispiel für eine ZertifikatsketteBeispiel für eine Zertifikatskette

In diesem Beispiel wird die IPsec-VPN-Konfiguration für die Aushandlung der Phasen 1 und 2 für Host-A gezeigt. Das Peer-Gerät (Host-B) muss ordnungsgemäß konfiguriert sein, damit die Optionen für Phase 1 und Phase 2 erfolgreich ausgehandelt und Sicherheitszuordnungen (Security Associations, SAs) eingerichtet werden können. Beispiele für die Konfiguration von Peer-Geräten für VPNs finden Sie unter Konfigurieren von Remote-IKE-IDs für Site-to-Site-VPNs .

Konfiguration

So konfigurieren Sie ein Gerät für Zertifikatsketten:

Konfigurieren von Zertifizierungsstellenprofilen

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein .[edit]commit

Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen hierzu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus imCLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

So konfigurieren Sie CA-Profile:

  1. Erstellen Sie das Zertifizierungsstellenprofil für die Stammzertifizierungsstelle.

  2. Erstellen Sie das CA-Profil für Eng-CA.

  3. Erstellen Sie das Zertifizierungsstellenprofil für Dev-CA.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den Befehl eingeben.show security pki Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf .commit

Registrieren von Zertifikaten

Schritt-für-Schritt-Anleitung

So registrieren Sie Zertifikate:

  1. Registrieren Sie die CA-Zertifikate.

    Geben Sie an den Eingabeaufforderungen ein , um das CA-Zertifikat zu laden.yes

  2. Stellen Sie sicher, dass die CA-Zertifikate auf dem Gerät registriert sind.

  3. Überprüfen Sie die Gültigkeit der registrierten Zertifizierungsstellenzertifikate.

  4. Generieren Sie ein Schlüsselpaar.

  5. Registrieren Sie das lokale Zertifikat.

  6. Stellen Sie sicher, dass das lokale Zertifikat auf dem Gerät registriert ist.

  7. Überprüfen Sie die Gültigkeit des registrierten lokalen Zertifikats.

  8. Überprüfen Sie den CRL-Download für konfigurierte Zertifizierungsstellenprofile.

Konfigurieren von IPsec-VPN-Optionen

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein .[edit]commit

Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen hierzu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus imCLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

So konfigurieren Sie IPsec-VPN-Optionen:

  1. Konfigurieren Sie die Optionen für Phase 1.

  2. Konfigurieren Sie die Optionen für Phase 2.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show security ikeshow security ipsec Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf .commit

Überprüfung

Wenn die Zertifikatüberprüfung während der IKE-Aushandlung zwischen Peergeräten erfolgreich ist, werden sowohl IKE- als auch IPsec-Sicherheitszuordnungen (Security Associations, SAs) eingerichtet.

Die IKE SA ist UP, wenn das Zertifikat gültig ist. Die IKE-Sicherheitszuordnung ist nicht verfügbar, und die IPSEC-Sicherheitszuordnung wird gebildet, wenn das Zertifikat gesperrt wird, und zwar nur, wenn die Sperrprüfung auf dem Peer-Gerät konfiguriert ist

Überprüfen des IKE-Phase-1-Status

Zweck

Überprüfen Sie den Status von IKE Phase 1.

Was

Geben Sie den Befehl aus dem Betriebsmodus ein.show security ike security-associations

Überprüfen des IPsec-Phase-2-Status

Zweck

Überprüfen Sie den IPsec-Phase 2-Status.

Was

Geben Sie den Befehl aus dem Betriebsmodus ein.show security ipsec security-associations

IKE- und IPsec-SA-Fehler für ein gesperrtes Zertifikat

Suchen nach gesperrten Zertifikaten

Problem

Wenn die Zertifikatüberprüfung während der IKE-Aushandlung zwischen Peergeräten fehlschlägt, stellen Sie sicher, dass das Zertifikat des Peers nicht gesperrt wurde. Ein dynamisches Zertifizierungsstellenprofil ermöglicht es dem lokalen Gerät, die Zertifikatsperrliste von der Zertifizierungsstelle des Peers herunterzuladen und den Sperrstatus des Peerzertifikats zu überprüfen. Um dynamische Zertifizierungsstellenprofile zu aktivieren, muss die Option für ein übergeordnetes Zertifizierungsstellenprofil konfiguriert werden.revocation-check crl

Lösung

So überprüfen Sie den Sperrstatus des Zertifikats eines Peers:

  1. Identifizieren Sie das dynamische Zertifizierungsstellenprofil, das die CRL für das Peer-Gerät anzeigt, indem Sie den Befehl aus dem Betriebsmodus eingeben.show security pki crl

    Das Zertifizierungsstellenprofil wird automatisch auf Host A erstellt, sodass Host A die Zertifikatsperrliste von der Zertifizierungsstelle von Host B (Sales-CA) herunterladen und den Sperrstatus des Peerzertifikats überprüfen kann.dynamic-001

  2. Zeigen Sie CRL-Informationen für das dynamische Zertifizierungsstellenprofil an, indem Sie den Befehl aus dem Betriebsmodus eingeben.show security pki crl ca-profile dynamic-001 detail

    Eingabe

    Das Zertifikat von Host-B (Seriennummer 10647084) wurde widerrufen.

IKEv2-Fragmentierung

Nachrichtenfragmentierung

Die IKEv2-Nachrichtenfragmentierung, wie in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, beschrieben, ermöglicht IKEv2 den Betrieb in Umgebungen, in denen IP-Fragmente blockiert werden können und Peers keine IPsec-Sicherheitszuordnung (Security Association, SA) einrichten können. Bei der IKEv2-Fragmentierung wird eine große IKEv2-Nachricht in eine Gruppe kleinerer Nachrichten aufgeteilt, sodass es keine Fragmentierung auf IP-Ebene gibt. Die Fragmentierung findet statt, bevor die ursprüngliche Nachricht verschlüsselt und authentifiziert wird, sodass jedes Fragment separat verschlüsselt und authentifiziert wird. Auf dem Empfänger werden die Fragmente gesammelt, verifiziert, entschlüsselt und mit der ursprünglichen Nachricht zusammengeführt.

Damit eine IKEv2-Fragmentierung auftritt, müssen beide VPN-Peers die Unterstützung der Fragmentierung angeben, indem sie die Nutzlast für die IKEV2_FRAGMENTATION_SUPPORTED Benachrichtigung in den IKE_SA_INIT Austausch einschließen. Wenn beide Peers die Unterstützung für die Fragmentierung angeben, muss der Initiator des Nachrichtenaustauschs bestimmen, ob die IKEv2-Fragmentierung verwendet wird.

Auf Firewalls der SRX-Serie sind maximal 32 Fragmente pro IKEv2-Nachricht zulässig. Wenn die Anzahl der zu sendenden oder zu empfangenden IKEv2-Nachrichtenfragmente 32 überschreitet, werden die Fragmente verworfen, und der Tunnel wird nicht eingerichtet. Die erneute Übertragung einzelner Nachrichtenfragmente wird nicht unterstützt

Konfiguration

Bei Firewalls der SRX-Serie ist die IKEv2-Fragmentierung standardmäßig für IPv4- und IPv6-Nachrichten aktiviert. Um die IKEv2-Fragmentierung zu deaktivieren, verwenden Sie die Anweisung auf der Hierarchieebene [].disableedit security ike gateway gateway-name fragmentation Sie können die Anweisung auch verwenden, um die Größe des Pakets zu konfigurieren, bei dem Nachrichten fragmentiert werden. Die Paketgröße liegt zwischen 500 und 1300 Byte.size Wenn diese Option nicht konfiguriert ist, beträgt die Standardpaketgröße 576 Byte für IPv4-Datenverkehr und 1280 Byte für IPv6-Datenverkehr.size Ein IKEv2-Paket, das größer als die konfigurierte Paketgröße ist, wird fragmentiert.

Nachdem die IKEv2-Fragmentierung deaktiviert oder aktiviert oder die Paketfragmentgröße geändert wurde, werden die VPN-Tunnel, die auf dem IKE-Gateway gehostet werden, heruntergefahren und die IKE- und IPsec-Sicherheitszuordnungen neu ausgehandelt.

Mögliche Einschränkungen der Aussagekraft der erhobenen Daten

Die folgenden Funktionen werden bei der IKEv2-Fragmentierung nicht unterstützt:

  • Pfad-MTU-Erkennung.

  • SNMP.

IKE-Richtlinie mit einer vertrauenswürdigen Zertifizierungsstelle

In diesem Beispiel wird gezeigt, wie ein vertrauenswürdiger CA-Server an eine IKE-Richtlinie des Peers gebunden wird.

Bevor Sie beginnen, müssen Sie über eine Liste aller vertrauenswürdigen Zertifizierungsstellen verfügen, die Sie der IKE-Richtlinie des Peers zuordnen möchten.

Sie können eine IKE-Richtlinie einem einzelnen vertrauenswürdigen Zertifizierungsstellenprofil oder einer vertrauenswürdigen Zertifizierungsstellengruppe zuordnen. Um eine sichere Verbindung herzustellen, verwendet das IKE-Gateway die IKE-Richtlinie, um sich bei der Überprüfung des Zertifikats auf die konfigurierte Gruppe von Zertifizierungsstellen (CA-Profile) zu beschränken. Ein Zertifikat, das von einer anderen Quelle als der vertrauenswürdigen Zertifizierungsstelle oder der vertrauenswürdigen Zertifizierungsstellengruppe ausgestellt wurde, wird nicht überprüft. Wenn eine Zertifikatüberprüfungsanforderung von einer IKE-Richtlinie ausgeht, wird das Zertifikat vom zugehörigen Zertifizierungsstellenprofil der IKE-Richtlinie validiert. Wenn eine IKE-Richtlinie keiner Zertifizierungsstelle zugeordnet ist, wird das Zertifikat standardmäßig von einem der konfigurierten Zertifizierungsstellenprofile überprüft.

In diesem Beispiel wird ein Zertifizierungsstellenprofil mit dem Namen a erstellt und dem Profil a zugeordnet.root-caroot-ca-identity

Sie können maximal 20 Zertifizierungsstellenprofile konfigurieren, die Sie einer vertrauenswürdigen Zertifizierungsstellengruppe hinzufügen möchten. Sie können Ihre Konfiguration nicht bestätigen, wenn Sie mehr als 20 Zertifizierungsstellenprofile in einer vertrauenswürdigen Zertifizierungsstellengruppe konfigurieren.

  1. Erstellen Sie ein Zertifizierungsstellenprofil, und ordnen Sie dem Profil eine Zertifizierungsstellen-ID zu.
  2. Definieren Sie einen IKE-Vorschlag und die Authentifizierungsmethode für IKE-Vorschläge.
  3. Definieren Sie die Diffie-Hellman-Gruppe, den Authentifizierungsalgorithmus, einen Verschlüsselungsalgorithmus für den IKE-Vorschlag.
  4. Konfigurieren Sie eine IKE-Richtlinie, und ordnen Sie die Richtlinie dem IKE-Vorschlag zu.
  5. Konfigurieren Sie einen lokalen Zertifikatbezeichner für die IKE-Richtlinie.
  6. Definieren Sie die Zertifizierungsstelle, die für die IKE-Richtlinie verwendet werden soll.

Führen Sie command aus, um die Zertifizierungsstellenprofile und die auf Ihrem Gerät konfigurierten vertrauenswürdigen Zertifizierungsstellengruppen anzuzeigen .show security pki

Der Befehl zeigt die Zertifizierungsstellenprofilgruppe unter dem Namen der IKE-Richtlinie und das Zertifikat an, das der IKE-Richtlinie zugeordnet ist.show security ikeike_policy

Konfigurieren von "Establish-Tunnel Responder-only" in IKE

In diesem Thema wird gezeigt, wie Sie in Internet Key Exchange (IKE) den Responder nur für die Einrichtung von Tunneln konfigurieren. Initiieren Sie die Tunnel vom Remote-Peer und leiten Sie den Datenverkehr durch alle Tunnel. Gibt an, wann IKE aktiviert ist.

Ab Junos OS Version 19.1R1 unterstützt die Option "Tunnel einrichten" in SRX5000 Zeile die Werte und unter der Hierarchieebene .responder-onlyresponder-only-no-rekey[edit security ipsec vpn vpn-name]

Die Optionen und werden auf der SRX5000-Linie mit einer SPC3-Karte nur unterstützt, wenn die installiert ist.responder-onlyresponder-only-no-rekeyjunos-ike-package Diese Optionen werden nur in einem Site-to-Site-VPN unterstützt. Diese Optionen werden von Auto VPN nicht unterstützt.

Die Option und stellt keinen VPN-Tunnel vom Gerät her, sodass der VPN-Tunnel vom Remotepeer initiiert wird.responder-onlyresponder-only-no-rekey Bei der Konfiguration schlüsselt ein eingerichteter Tunnel sowohl IKE als auch IPsec basierend auf den konfigurierten IKE- und IPsec-Lebensdauerwerten neu ein.responder-only Wenn Sie konfigurieren, wird ein eingerichteter Tunnel nicht vom Gerät neu verschlüsselt und verlässt sich darauf, dass der Remote-Peer die erneute Schlüsselerstellung initiiert.responder-only-no-rekey Wenn der Remotepeer die erneute Schlüsselerstellung nicht initiiert, erfolgt der Tunnelabbau nach Ablauf der festen Lebensdauer.

Bevor Sie beginnen:

So konfigurieren Sie "establish-tunnel responder-only" in IKE:

  1. Konfigurieren Sie "establish-tunnel Responder-only"
  2. Bestätigen Sie Ihre Konfiguration, indem Sie den Befehl eingeben.show security ipsec vpn IPSEC_VPN
  3. Konfigurieren Sie den Responder-Responder "establish-tunnel only-no-rekey"
  4. Bestätigen Sie Ihre Konfiguration, indem Sie den Befehl eingeben.show security ipsec vpn IPSEC_VPN

    Bei mehreren VPN-Objekten hat der Nur-Responder-Modus Vorrang. Wenn eines der VPNs in einem Gateway mit dem Nur-Responder-Modus konfiguriert ist, müssen alle VPNs im Gateway mit dem Nur-Responder-Modus konfiguriert werden.

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
23.4R1
Die Unterstützung für den IKE-Schutz vor DDoS-Angriffen wurde in Junos OS Version 23.4R1 eingeführt.
18.1R1
Ab Junos OS Version 18.1R1 kann die Validierung eines konfigurierten IKE-Peers mit einem angegebenen CA-Server oder einer Gruppe von CA-Servern erfolgen.