Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

Überwachung des VPN-Datenverkehrs

Die VPN-Überwachung ermöglicht es Ihnen, die Erreichbarkeit von Peer-Geräten zu bestimmen, indem Sie ICMP-Anfragen (Internet Control Message Protocol) an die Peers senden.

Grundlegendes zu VPN-Alarmen und -Prüfungen

Konfigurieren Sie den folgenden Befehl, um die Protokollierung von Sicherheitsereignis während der ersten Einrichtung des Geräts zu aktivieren. Diese Funktion wird auf SRX300-, SRX320-, SRX340-, SRX345-, SRX550HM- und SRX1500-Geräten und virtuellen vSRX-Firewall-Instanzen unterstützt.

set security log cache

Die Administratoren (Audit, Kryptografie, IDS und Sicherheit) können die Konfiguration der Protokollierung von Sicherheitsereignisen nicht ändern, wenn der obige Befehl konfiguriert ist und jede Administratorrolle so konfiguriert ist, dass sie einen eigenen Satz von Berechtigungen hat, abgesehen von allen anderen Administrativen Rollen.

Alarme werden durch einen VPN-Fehler ausgelöst. Ein VPN-Alarm wird generiert, wenn das System eines der folgenden überwachten Ereignisse überwacht:

  • Authentication failures— Sie können das Gerät so konfigurieren, dass ein Systemalarm generiert wird, wenn der Paketauthentifizierungsfehler eine bestimmte Anzahl erreicht.

  • Encryption and decryption failures— Sie können das Gerät so konfigurieren, dass es einen Systemalarm erzeugt, wenn Ver- oder Entschlüsselungsfehler eine angegebene Anzahl überschreiten.

  • IKE Phase 1 and IKE Phase 2 failures— Internet Key Exchange (IKE) Phase-1-Verhandlungen werden verwendet, um IKE-Sicherheitszuordnungen (SAs) einzurichten. Diese SAs schützen die IKE-Phase-2-Verhandlungen. Sie können das Gerät so konfigurieren, dass ein Systemalarm generiert wird, wenn IKE Phase 1- oder IKE-Phase-2-Fehler eine angegebene Anzahl überschreiten.

  • Self-test failures— Bei Selbsttests handelt es sich um Tests, bei denen ein Gerät beim Einschalten oder Neustart ausgeführt wird, um zu überprüfen, ob die Sicherheitssoftware auf Ihrem Gerät korrekt implementiert ist.

    Selbsttests stellen die Richtigkeit kryptografischer Algorithmen sicher. Das Junos-FIPS-Bild führt automatisch beim Einschalten Selbsttests durch und kontinuierlich für die Generierung von Schlüsselpaaren. In inländischen oder FIPS-Images können Selbsttests so konfiguriert werden, dass sie nach einem definierten Zeitplan, auf Anforderung oder unmittelbar nach der Schlüsselgenerierung durchgeführt werden.

    Sie können das Gerät so konfigurieren, dass ein Systemalarm generiert wird, wenn ein Selbsttest auftritt.

  • IDP flow policy attacks— Eine Intrusion Detection and Prevention (IDP)-Richtlinie ermöglicht es Ihnen, verschiedene Angriffserkennungs- und Abwehrtechniken auf den Netzwerkverkehr durchzusetzen. Sie können das Gerät so konfigurieren, dass bei Verstößen gegen idP-Datenflussrichtlinien ein Systemalarm generiert wird.

  • Replay attacks— Ein Replay-Angriff ist ein Netzwerkangriff, bei dem eine gültige Datenübertragung böswillig oder in betrügerischer Weise wiederholt oder verzögert wird. Sie können das Gerät so konfigurieren, dass bei einem Wiedergabeangriff ein Systemalarm generiert wird.

Die Syslog-Meldungen sind in den folgenden Fällen enthalten:

  • Fehlgeschlagene symmetrische Schlüsselgenerierung

  • Fehlgeschlagene asymmetrische Schlüsselgenerierung

  • Fehlgeschlagene manuelle Schlüsselverteilung

  • Fehlgeschlagene automatisierte Schlüsselverteilung

  • Fehlgeschlagene Schlüsselvernichtung

  • Fehlgeschlagene Handhabung und Speicherung von Schlüsseln

  • Fehlgeschlagene Verschlüsselung oder Entschlüsselung von Daten

  • Fehlgeschlagene Signatur

  • Fehlgeschlagene Schlüsselvereinbarung

  • Fehlgeschlagenes kryptografisches Hashing

  • IKE-Fehler

  • Fehlgeschlagene Authentifizierung der empfangenen Pakete

  • Entschlüsselungsfehler aufgrund ungültiger Padding-Inhalte

  • Mismatch in der Länge, die im alternativen Betrefffeld des Zertifikats angegeben ist, das von einem Remote-VPN-Peer-Gerät empfangen wird.

Alarme werden basierend auf Syslog-Meldungen ausgelöst. Jeder Fehler wird protokolliert, aber ein Alarm wird erst generiert, wenn ein Schwellenwert erreicht wird.

Führen Sie den Befehl aus, um die show security alarms Alarminformationen anzuzeigen. Die Anzahl der Verstöße und der Alarm bleiben nicht während des Systemneustarts bestehen. Nach einem Neustart wird die Anzahl der Verstöße auf null zurückgesetzt, und der Alarm wird aus der Alarmwarteschlange entfernt.

Nachdem entsprechende Maßnahmen ergriffen wurden, können Sie den Alarm löschen. Der Alarm bleibt in der Warteschlange, bis Sie ihn löschen (oder bis Sie das Gerät neu starten). Führen Sie den Befehl aus, um den clear security alarms Alarm zu löschen.

Siehe auch

Verstehen der VPN-Überwachung

Die VPN-Überwachung verwendet ICMP Echo Requests (oder Pings), um zu bestimmen, ob ein VPN-Tunnel aktiv ist. Wenn die VPN-Überwachung aktiviert ist, sendet das Sicherheitsgerät Pings über den VPN-Tunnel an das Peer-Gateway oder an ein bestimmtes Ziel am anderen Ende des Tunnels. Pings werden standardmäßig im Abstand von 10 Sekunden für bis zu 10 aufeinanderfolgende Male gesendet. Wenn nach 10 aufeinanderfolgenden Pings keine Antwort erhalten wird, gilt das VPN als deaktiviert und die IPsec Security Association (SA) wird freigegeben.

Die VPN-Überwachung wird für ein bestimmtes VPN aktiviert, indem die vpn-monitor Option auf Hierarchieebene [edit security ipsec vpn vpn-name] konfiguriert wird. Die IP-Adresse des Peer-Gateways ist das Standardziel. Sie können jedoch eine andere Ziel-IP-Adresse (z. B. einen Server) am anderen Ende des Tunnels angeben. Das lokale Tunnelendpunkt ist die Standardquellschnittstelle, Sie können jedoch einen anderen Schnittstellennamen angeben.

Die VPN-Überwachung eines extern verbundenen Geräts (z. B. eines PCs) wird auf SRX5400-, SRX5600- und SRX5800-Geräten nicht unterstützt. Das Ziel für die VPN-Überwachung muss eine lokale Schnittstelle des SRX5400-, SRX5600- oder SRX5800-Geräts sein.

Die VPN-Überwachungsoption optimized sendet Pings nur, wenn ausgehender Datenverkehr und kein eingehender Datenverkehr durch den VPN-Tunnel erfolgt. Wenn eingehender Datenverkehr über den VPN-Tunnel erfolgt, betrachtet das Sicherheitsgerät den Tunnel als aktiv und sendet keine Pings an den Peer. Durch die Konfiguration der optimized Option können Ressourcen auf dem Sicherheitsgerät eingespart werden, da Pings nur gesendet werden, wenn die Peer-Lebendigkeit ermittelt werden muss. Das Senden von Pings kann auch kostspielige Backup-Links aktivieren, die sonst nicht verwendet würden.

Sie können das Intervall, in dem Pings gesendet werden, und die Anzahl der aufeinanderfolgenden Pings konfigurieren, die ohne Antwort gesendet werden, bevor das VPN als ausfällt. Diese werden mit den interval optionen bzw threshold . auf hierarchieebene [edit security ipsec vpn-monitor-options] konfiguriert.

Die VPN-Überwachung kann in einigen VPN-Umgebungen zu Tunnel-Flapping führen, wenn Ping-Pakete vom Peer basierend auf der Quell- oder Ziel-IP-Adresse des Pakets nicht akzeptiert werden.

Grundlegendes zur IPsec-Datenpfadverifizierung

Überblick

Standardmäßig basiert der Status der Secure Tunnel (st0)-Schnittstellen, die in routenbasierten VPNs im Punkt-zu-Punkt-Modus konfiguriert sind, auf dem Zustand des VPN-Tunnels. Kurz nach der Einrichtung der IPsec SA werden routen, die der st0-Schnittstelle in der Junos OS-Weiterleitungstabelle zugeordnet sind. In bestimmten Netzwerktopologien, z. B. wenn sich eine Transit-Firewall zwischen den VPN-Tunnel-Endgeräten befindet, kann der IPsec-Datenverkehr, der aktive Routen für einen etablierten VPN-Tunnel auf der st0-Schnittstelle verwendet, von der Transit-Firewall blockiert werden. Dies kann zu Datenverkehrsverlusten führen.

Wenn Sie die IPsec-Datapath-Verifizierung aktivieren, wird die st0-Schnittstelle erst aktiviert, wenn der Datapath verifiziert ist. Die Überprüfung wird mit der set security ipsec vpn vpn-name vpn-monitor verify-path Anweisung für routenbasierte, Standort-zu-Standort- und dynamische Endpunkt-VPN-Tunnel konfiguriert.

Wenn sich vor dem Peer-Tunnel-Endgerät ein NAT-Gerät befindet, wird die IP-Adresse des Peer-Tunnel-Endgeräts in die IP-Adresse des NAT-Geräts übersetzt. Damit die ICMP-Anfrage des VPN-Monitors den Peer-Tunnel-Endpunkt erreicht, müssen Sie explizit die ursprüngliche, nicht übersetzte IP-Adresse des Peer-Tunnel-Endgeräts hinter dem NAT-Gerät angeben. Dies wird mit der set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip Konfiguration konfiguriert.

Ab Junos OS Version 15.1X49-D120 können Sie die Größe des Pakets konfigurieren, das zum Überprüfen eines IPsec-Datenpfads verwendet wird, bevor die st0 Schnittstelle eingerichtet wird. Verwenden Sie die set security ipsec vpn vpn-name vpn-monitor verify-path packet-size Konfiguration. Die konfigurierbare Paketgröße reicht von 64 bis 1.350 Bytes; der Standard ist 64 Bytes.

Mögliche Einschränkungen der Aussagekraft der erhobenen Daten

Die Quellschnittstelle und die Ziel-IP-Adressen, die für den VPN-Monitorbetrieb konfiguriert werden können, haben keine Auswirkungen auf die IPsec-Datenpfadüberprüfung. Die Quelle für die ICMP-Anforderungen in der IPsec-Datenpfadüberprüfung ist der lokale Tunnelendpunkt.

Wenn Sie die IPsec-Datenpfadverifizierung aktivieren, wird die VPN-Überwachung automatisch aktiviert und nach der Einrichtung der st0-Schnittstelle verwendet. Wir empfehlen, die option "optimierten VPN-Monitor" mit dem Befehl zu konfigurieren, wenn Sie die set security ipsec vpn vpn-name vpn-monitor optimized IPsec-Datenpfadverifizierung aktivieren.

Wenn während der IPsec-Datenpfadüberprüfung ein Chassis-Cluster-Failover auftritt, startet der neue aktive Knoten die Überprüfung erneut. Die st0-Schnittstelle wird erst aktiviert, wenn die Überprüfung erfolgreich ist.

Für IPsec-SA-Rekeys wird keine IPsec-Datenpfadüberprüfung durchgeführt, da sich der St0-Schnittstellenstatus für Neuschlüssel nicht ändert.

Die IPsec-Datenpfadverifizierung wird auf st0-Schnittstellen, die im Point-to-Multipoint-Modus konfiguriert sind und mit AutoVPN, Auto Discovery VPN und mehreren Datenverkehrs-Selektoren verwendet werden, nicht unterstützt. VPN-Überwachung und IPsec-Datenpfadverifizierung unterstützen keine IPv6-Adressen, sodass die IPsec-Datapath-Überprüfung nicht mit IPv6-Tunneln verwendet werden kann.

Globale SPI- und VPN-Überwachungsfunktionen verstehen

Sie können den effizienten Betrieb Ihres VPN mit den folgenden globalen VPN-Funktionen überwachen und aufrechterhalten:

  • SPI: Peers in einer Security Association (SA) können sich nicht synchronisieren lassen, wenn einer der Peers ausfällt. Wenn beispielsweise einer der Peers neu gestartet wird, sendet er möglicherweise einen falschen Sicherheitsparameterindex (SPI). Sie können dem Gerät ermöglichen, ein solches Ereignis zu erkennen und die Peers neu zu synchronisieren, indem Sie die fehlerhafte SPI-Antwortfunktion konfigurieren.

  • VPN-Überwachung: Sie können die globale VPN-Überwachungsfunktion verwenden, um in regelmäßigen Abständen Anfragen des Internet Control Message Protocol (ICMP) an den Peer zu senden, um festzustellen, ob der Peer erreichbar ist.

Verständnis von VPN-Überwachung und DPD

VPN-Überwachung und Dead Peer Detection (DPD) sind Funktionen, die auf den Firewalls der SRX-Serie zur Verfügung stehen, um die Verfügbarkeit von VPN-Peer-Geräten zu überprüfen. In diesem Abschnitt werden der Betrieb und die Konfiguration dieser Funktionen verglichen.

Die Firewall der SRX-Serie reagiert auf DPD-Nachrichten, die von VPN-Peers gesendet werden, selbst wenn DPD auf dem Gerät nicht konfiguriert ist. Sie können die Firewall der SRX-Serie so konfigurieren, dass SIE DPD-Nachrichten an VPN-Peers initiiert. Sie können auch die DPD- und VPN-Überwachung so konfigurieren, dass sie gleichzeitig auf derselben Firewall der SRX-Serie arbeiten, obwohl die Anzahl der Peers, die mit beiden Methoden überwacht werden können, reduziert ist.

Die VPN-Überwachung ist ein Junos OS-Mechanismus, der nur Phase-2-Sicherheitszuordnungen (SAs) überwacht. Die VPN-Überwachung wird auf VPN-Basis mit der vpn-monitor Anweisung auf der Hierarchieebene [edit security ipsec vpn vpn-name] aktiviert. Ziel-IP und Quellschnittstelle müssen angegeben werden. Die optimized Option ermöglicht es dem Gerät, Datenverkehrsmuster als Beweis für Peer-Livelines zu verwenden; ICMP-Anfragen werden unterdrückt.

VPN-Überwachungsoptionen werden mit der vpn-monitor-options Anweisung auf Hierarchieebene [edit security ipsec] konfiguriert. Diese Optionen gelten für alle VPNs, für die die VPN-Überwachung aktiviert ist. Zu den Optionen, die Sie konfigurieren können, gehören das Intervall, in dem ICMP-Anforderungen an den Peer gesendet werden (Der Standard ist 10 Sekunden) und die Anzahl der aufeinanderfolgenden ICMP-Anforderungen, die gesendet werden, ohne eine Antwort zu erhalten, bevor der Peer als nicht erreichbar gilt (Standard sind 10 aufeinander folgende Anforderungen).

DPD ist eine Implementierung von RFC 3706, einer datenverkehrsbasierten Methode zur Erkennung von Dead Internet Key Exchange (IKE) Peers. Er arbeitet auf IKE-Ebene und überwacht den Peer basierend auf IKE- und IPsec-Datenverkehrsaktivitäten.

DPD wird auf einem individuellen IKE-Gateway mit der dead-peer-detection Anweisung auf [edit security ike gateway gateway-name] Hierarchieebene konfiguriert. Sie können die DPD-Betriebsmodi konfigurieren. Der (optimierte) Standardmodus sendet DPD-Nachrichten an den Peer, wenn es innerhalb eines konfigurierten Intervalls keinen eingehenden IKE- oder IPsec-Datenverkehr gibt, nachdem das lokale Gerät ausgehende Pakete an den Peer gesendet hat. Andere konfigurierbare Optionen umfassen das Intervall, in dem DPD-Nachrichten an den Peer gesendet werden (Standard ist 10 Sekunden) und die Anzahl der aufeinanderfolgenden DPD-Nachrichten, die gesendet werden, ohne eine Antwort zu erhalten, bevor der Peer als nicht verfügbar gilt (Standard sind fünf aufeinander folgende Anforderungen).

Informationen zur Dead Peer Detection

Dead Peer Detection (DPD) ist eine Methode, mit der Netzwerkgeräte die aktuelle Existenz und Verfügbarkeit anderer Peer-Geräte überprüfen.

Sie können DPD als Alternative zur VPN-Überwachung verwenden. Die VPN-Überwachung gilt für ein individuelles IPsec-VPN, während DPD nur in einem individuellen IKE-Gateway-Kontext konfiguriert wird.

Ein Gerät führt eine DPD-Überprüfung durch, indem es verschlüsselte IKE Phase-1-Benachrichtigungs-Payloads (R-U-THERE-Nachrichten) an einen Peer sendet und auf DPD-Bestätigungen (R-U-THERE-ACK-Nachrichten) vom Peer wartet. Das Gerät sendet eine R-U-THERE-Nachricht nur, wenn es während eines angegebenen DPD-Intervalls keinen Datenverkehr vom Peer empfangen hat. Wenn das Gerät in diesem Intervall eine R-U-THERE-ACK-Nachricht vom Peer empfängt, betrachtet es den Peer am Leben. Wenn das Gerät Datenverkehr im Tunnel vom Peer empfängt, setzt es seinen R-U-THERE-Nachrichtenzähler für diesen Tunnel zurück und startet so ein neues Intervall. Wenn das Gerät während des Intervalls keine R-U-THERE-ACK-Nachricht empfängt, hält es den Peer für tot. Wenn das Gerät den Status eines Peer-Geräts ändert, dass es tot ist, entfernt das Gerät die Phase-1-Sicherheitszuordnung (SA) und alle Phase-2-SAs für diesen Peer.

Die folgenden DPD-Modi werden von den Firewalls der SRX-Serie unterstützt:

  • Optimiert: R-U-THERE-Meldungen werden ausgelöst, wenn innerhalb eines konfigurierten Intervalls kein eingehender IKE- oder IPsec-Datenverkehr erfolgt, nachdem das Gerät ausgehende Pakete an den Peer gesendet hat. Dies ist der Standardmodus.

  • Probe-Idle-Tunnel: R-U-THERE-Meldungen werden ausgelöst, wenn innerhalb eines konfigurierten Intervalls kein eingehender oder ausgehender IKE- oder IPsec-Datenverkehr vorhanden ist. R-U-THERE-Nachrichten werden in regelmäßigen Abständen an den Peer gesendet, bis datenverkehrsbezogene Aktivitäten auftreten. Dieser Modus hilft bei der frühzeitigen Erkennung eines gestürzten Peers und macht den Tunnel für den Datenverkehr verfügbar.

    Wenn mehrere Datenverkehrs-Selektoren für ein VPN konfiguriert sind, können mehrere Tunnel für dieselbe IKE SA eingerichtet werden. In diesem Szenario löst der Probe-Leerlauf-Tunnelmodus R-U-THERE-Nachrichten aus, die gesendet werden, wenn ein mit der IKE SA verknüpfter Tunnel inaktiv wird, obwohl sich Datenverkehr für dieselbe IKE SA in einem anderen Tunnel befindet.

  • Immer senden: R-U-THERE-Nachrichten werden unabhängig von der Datenverkehrsaktivität zwischen den Peers in konfigurierten Intervallen gesendet.

    Wir empfehlen, anstelle des Modus den Probe-Leerlauf-Tunnel-Modus zu verwenden always-send .

DPD-Timer sind aktiv, sobald die Phase 1 SA eingerichtet wurde. Das DPD-Verhalten ist sowohl für das IKEv1- als auch für das IKEv2-Protokoll gleich.

Sie können die folgenden DPD-Parameter konfigurieren:

  • Der Intervallparameter gibt die Zeitdauer an (in Sekunden ausgedrückt), die das Gerät auf Datenverkehr von seinem Peer wartet, bevor es eine R-U-THERE-Nachricht sendet. Das Standardintervall beträgt 10 Sekunden. Ab Junos OS Version 15.1X49-D130 wird der zulässige Intervallparameterbereich, in dem R-U-THERE-Nachrichten an das Peer-Gerät gesendet werden, von 10 bis 60 Sekunden auf 2 Sekunden bis 60 Sekunden reduziert. Der mindeste Schwellenwertparameter sollte 3 sein, wenn der DPD-Intervallparameter weniger als 10 Sekunden festgelegt ist.

  • Der Schwellenwertparameter gibt die maximale Anzahl der Male an, mit der die R-U-THERE-Nachricht ohne Antwort des Peers gesendet werden kann, bevor der Peer für tot gilt. Die Standardanzahl der Übertragungen ist fünfmal, mit einem zulässigen Bereich von 1 bis 5 Wiederholungen.

Beachten Sie die folgenden Überlegungen vor der Konfiguration von DPD:

  • Wenn eine DPD-Konfiguration zu einem bestehenden Gateway mit aktiven Tunneln hinzugefügt wird, werden R-U-THERE-Nachrichten gestartet, ohne phase 1 oder Phase 2 SAs zu löschen.

  • Wenn eine DPD-Konfiguration von einem bestehenden Gateway mit aktiven Tunneln gelöscht wird, werden R-U-THERE-Nachrichten für die Tunnel angehalten. IKE- und IPsec-SAs sind nicht betroffen.

  • Durch Ändern einer DPD-Konfigurationsoption wie Modus, Intervall oder Schwellwerte wird der DPD-Vorgang aktualisiert, ohne die Phase-1- oder Phase-2-SAs zu löschen.

  • Wenn das IKE-Gateway mit DPD- und VPN-Überwachung konfiguriert ist, aber die Option zum sofortigen Einrichten von Tunneln nicht konfiguriert ist, initiiert DPD keine Phase-1-Aushandlung. Wenn DPD konfiguriert wird, muss auch die Option "Sofort tunneln einrichten" gleichzeitig konfiguriert werden, um die st0-Schnittstelle abreißen zu können, wenn keine Phase-1- und Phase-2-SAs verfügbar sind.

  • Wenn das IKE-Gateway mit mehreren Peer-IP-Adressen und DPD konfiguriert ist, Phase 1 SA jedoch nicht mit der ersten Peer-IP-Adresse eingerichtet werden kann, wird ein Phase-1-SA mit der nächsten Peer-IP-Adresse versucht. DPD ist erst aktiv, nachdem eine Phase-1-SA eingerichtet wurde.

  • Wenn das IKE-Gateway mit mehreren Peer-IP-Adressen und DPD konfiguriert ist, aber DPD mit der IP-Adresse des aktuellen Peers fehlschlägt, werden die Phase-1- und Phase-2-SAs gelöscht und ein Failover zur nächsten Peer-IP-Adresse wird ausgelöst.

  • Aufgrund gleichzeitiger Verhandlungen können mehr als eine Phase 1 oder Phase 2 SA mit demselben Peer vorhanden sein. In diesem Fall werden R-U-THERE-Nachrichten an alle Phase-1-SAs gesendet. Wenn keine DPD-Antworten für die konfigurierte Anzahl aufeinanderfolgender Male empfangen werden, löscht phase 1 SA und die zugehörige Phase 2 SA (nur für IKEv2).

Siehe auch

Verstehen von Tunnelereignissen

Wenn es ein Netzwerkproblem im Zusammenhang mit einem VPN gibt, wird nach dem Auftreten des Tunnels nur der Tunnelstatus verfolgt. Viele Probleme können auftreten, bevor der Tunnel entsteht. Anstatt nur den Tunnelstatus, Tunnel-Down-Probleme oder Aushandlungsfehler zu verfolgen, werden nun erfolgreiche Ereignisse wie erfolgreiche IPsec SA-Verhandlungen, IPsec-Rekey und IKE SA-Rekeys verfolgt. Diese Ereignisse werden als Tunnelereignisse bezeichnet.

Für Phase 1 und Phase 2 werden die Aushandlungsereignisse für einen bestimmten Tunnel zusammen mit den Ereignissen verfolgt, die in externen Daemons wie AUTHD oder PKID auftreten. Wenn ein Tunnelereignis mehrmals auftritt, wird nur ein Eintrag mit der aktualisierten Uhrzeit und der Anzahl der Ereignisse beibehalten.

Insgesamt werden 16 Ereignisse verfolgt: acht Ereignisse für Phase 1 und acht Ereignisse für Phase 2. Einige Ereignisse können erneut auftreten und den Ereignisspeicher füllen, was dazu führt, dass wichtige Ereignisse entfernt werden. Um ein Überschreiben zu vermeiden, wird ein Ereignis nur gespeichert, wenn ein Tunnel ausfällt.

Folgende Veranstaltungen fallen in diese Kategorie:

  • Lebensdauer in KILObyte abgelaufen für IPsec SA

  • Harte Lebensdauer von IPsec SA abgelaufen

  • IPsec SA löscht vom Peer empfangene Nutzdaten, entsprechende IPsec-SAs freigegeben

  • Löschen ungenutzter redundanter Backup-IPsec-SA-Paare

  • IPsec-SAs als entsprechende IKE SA gelöscht

AutoVPN-Tunnel werden dynamisch erstellt und entfernt und folglich sind Tunnelereignisse, die diesen Tunneln entsprechen, kurzlebig. Manchmal können diese Tunnelereignisse keinem Tunnel zugeordnet werden, sodass stattdessen die Systemprotokollierung für die Fehlerbehebung verwendet wird.

Siehe auch

Beispiel: Festlegen einer akustischen Warnung als Benachrichtigung über einen Sicherheitsalarm

Dieses Beispiel zeigt, wie Sie ein Gerät so konfigurieren, dass ein Systemwarnungssignal erzeugt wird, wenn ein neues Sicherheitsereignis auftritt. Standardmäßig sind Alarme nicht hörbar. Diese Funktion wird auf SRX300-, SRX320-, SRX340-, SRX345-, SRX550HM- und SRX1500-Geräten und virtuellen vSRX-Firewall-Instanzen unterstützt.

Anforderungen

Vor der Konfiguration dieser Funktion ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Überblick

In diesem Beispiel haben Sie einen akustischen Signalton festgelegt, der als Reaktion auf einen Sicherheitsalarm generiert wird.

Konfiguration

Verfahren

Schritt-für-Schritt-Verfahren

So richten Sie einen akustischen Alarm ein:

  1. Aktivieren Sie Sicherheitsalarme.

  2. Geben Sie an, dass Sie über Sicherheitsalarme mit einem akustischen Signalton benachrichtigt werden möchten.

  3. Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.

Überprüfung

Geben Sie den Befehl ein, um zu überprüfen, ob die show security alarms detail Konfiguration ordnungsgemäß funktioniert.

Siehe auch

Beispiel: Generierung von Sicherheitsalarmen als Reaktion auf potenzielle Verstöße

Dieses Beispiel zeigt, wie Sie das Gerät so konfigurieren, dass bei einer potenziellen Verletzung ein Systemalarm generiert wird. Standardmäßig wird kein Alarm ausgelöst, wenn eine potenzielle Verletzung auftritt. Diese Funktion wird auf SRX300-, SRX320-, SRX340-, SRX345-, SRX550HM- und SRX1500-Geräten und virtuellen vSRX-Firewall-Instanzen unterstützt.

Anforderungen

Vor der Konfiguration dieser Funktion ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Überblick

In diesem Beispiel konfigurieren Sie einen Alarm, der ausgelöst wird, wenn:

  • Die Anzahl der Authentifizierungsfehler übersteigt 6.

  • Der kryptografische Selbsttest schlägt fehl.

  • Der nicht kryptografische Selbsttest schlägt fehl.

  • Der Selbsttest der Schlüsselgeneration schlägt fehl.

  • Die Anzahl der Verschlüsselungsausfälle übersteigt 10.

  • Die Anzahl der Entschlüsselungsfehler übersteigt 1.

  • Die Anzahl der IKE-Phase-1-Ausfälle übersteigt 10.

  • Die Anzahl der IKE-Phase-2-Fehler übersteigt 1.

  • Ein Replay-Angriff tritt auf.

Konfiguration

Verfahren

CLI-Schnellkonfiguration

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

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.

So konfigurieren Sie Alarme als Reaktion auf potenzielle Verstöße:

  1. Aktivieren Sie Sicherheitsalarme.

  2. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein Authentifizierungsfehler auftritt.

  3. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein kryptografischer Selbsttest auftritt.

  4. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein nicht kryptografischer Selbsttest auftritt.

  5. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein Schlüsselgenerierungs-Selbsttest fehlgeschlagen ist.

  6. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein Verschlüsselungsfehler auftritt.

  7. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein Entschlüsselungsfehler auftritt.

  8. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein IKE Phase 1-Fehler auftritt.

  9. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein IKE-Phase-2-Fehler auftritt.

  10. Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein Wiedergabeangriff auftritt.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show security alarms Befehl eingeben. Wenn in der Ausgabe die beabsichtigte Konfiguration nicht angezeigt wird, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

Geben Sie den Befehl ein, um zu bestätigen, dass die show security alarms Konfiguration ordnungsgemäß funktioniert.

Siehe auch

Verwandte Themen

Release-Verlaufstabelle
Release
Beschreibung
15.1X49-D130
Ab Junos OS Version 15.1X49-D130 wird der zulässige Intervallparameterbereich, in dem R-U-THERE-Nachrichten an das Peer-Gerät gesendet werden, von 10 bis 60 Sekunden auf 2 Sekunden bis 60 Sekunden reduziert. Der mindeste Schwellenwertparameter sollte 3 sein, wenn der DPD-Intervallparameter weniger als 10 Sekunden festgelegt ist.
15.1X49-D120
Ab Junos OS Version 15.1X49-D120 können Sie die Größe des Pakets konfigurieren, das zum Überprüfen eines IPsec-Datenpfads verwendet wird, bevor die st0 Schnittstelle eingerichtet wird.