Überwachung und Fehlerbehebung von Sicherheitsrichtlinien
Die Überwachung bietet eine Echtzeitdarstellung aussagekräftiger Daten, die den Status der Zugriffsaktivitäten in einem Netzwerk darstellen. Diese Erkenntnisse ermöglichen es Ihnen, betriebliche Bedingungen einfach zu interpretieren und zu beeinflussen. Die Fehlerbehebung bietet kontextbezogene Anleitungen zur Lösung von Zugriffsproblemen in Netzwerken. Anschließend können Sie auf die Bedenken der Benutzer eingehen und zeitnah eine Lösung bereitstellen.
Sicherheits-Alarme verstehen
Alarme werden ausgelöst, wenn Pakete aufgrund eines Richtlinienverstoßes verworfen werden. Ein Richtlinienverstoß liegt vor, wenn ein Paket mit einer Ablehnungs- oder Verweigerungsrichtlinie übereinstimmt. Ein Alarm für Richtlinienverletzungen wird generiert, wenn das System eines der folgenden überwachten Ereignisse überwacht:
Anzahl der Richtlinienverletzungen durch einen Quellnetzwerkbezeichner innerhalb eines bestimmten Zeitraums
Anzahl der Richtlinienverletzungen eines Zielnetzwerk-Identifikators innerhalb eines bestimmten Zeitraums
Anzahl der Richtlinienverstöße gegen eine Anwendung innerhalb eines bestimmten Zeitraums
Richtlinienregel oder Gruppe von Regelverletzungen innerhalb eines bestimmten Zeitraums
Es gibt vier Arten von Alarmen, die diesen vier Ereignissen entsprechen. Die Alarme basieren auf Quell-IP, Ziel-IP, Anwendung und Richtlinie.
Wenn ein Paket auf eine Ablehnungs- oder Verweigerungsrichtlinie stößt, werden die Zähler für Richtlinienverletzungen für alle aktivierten Alarmtypen erhöht. Wenn ein Zähler den angegebenen Schwellenwert innerhalb eines bestimmten Zeitraums erreicht, wird ein Alarm generiert. Nach einem bestimmten Zeitraum wird der Zähler für Richtlinienverletzungen zurückgesetzt und wiederverwendet, um einen weiteren Zählzyklus zu starten.
Um die Alarminformationen anzuzeigen, führen Sie den show security alarms Befehl aus. Die Anzahl der Verstöße und der Alarm bleiben bei Systemneustarts nicht erhalten. Nach einem Neustart wird die Anzahl der Verstöße auf Null zurückgesetzt und der Alarm wird aus der Alarmwarteschlange gelöscht.
Nachdem Sie entsprechende Maßnahmen ergriffen haben, 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). Um den Alarm zu löschen, führen Sie den clear security alarms Befehl aus. Nachdem Sie den Alarm gelöscht haben, kann eine nachfolgende Reihe von Verstößen gegen die Datenverkehrsrichtlinie dazu führen, dass ein neuer Alarm ausgelöst wird.
Siehe auch
Beispiel: Generieren eines Sicherheitsalarms als Reaktion auf Richtlinienverletzungen
In diesem Beispiel wird gezeigt, wie das Gerät so konfiguriert wird, dass bei einem Richtlinienverstoß ein Systemalarm generiert wird. Standardmäßig wird kein Alarm ausgelöst, wenn ein Richtlinienverstoß auftritt.
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 Anwendungsgröße beträgt 10240 Einheiten.
Die Quell-IP-Verletzung überschreitet innerhalb von 20 Sekunden 1000.
Die Ziel-IP-Verletzung überschreitet innerhalb von 10 Sekunden 1000.
Der Richtlinienübereinstimmungsverstoß überschreitet 100 und hat eine Größe von 100 Einheiten.
Konfiguration
Vorgehensweise
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, fügen Sie sie [edit] in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem Konfigurationsmodus ein commit .
set security alarms potential-violation policy application size 10240 set security alarms potential-violation policy source-ip threshold 1000 duration 20 set security alarms potential-violation policy destination-ip threshold 1000 duration 10 set security alarms potential-violation policy policy-match threshold 100 size 100
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie Alarme für Richtlinienverletzungen:
Aktivieren Sie Sicherheitsalarme.
[edit] user@host# edit security alarms
Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn eine Anwendungsverletzung auftritt.
[edit security alarms potential-violation policy] user@host# set application size 10240
Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn eine Quell-IP-Verletzung auftritt.
[edit security alarms potential-violation policy] user@host# set source-ip threshold 1000 duration 20
Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn eine Ziel-IP-Verletzung auftritt.
[edit security alarms potential-violation policy] user@host# set destination-ip threshold 1000 duration 10
Geben Sie an, dass ein Alarm ausgelöst werden soll, wenn ein Richtlinienübereinstimmungsverstoß auftritt.
[edit security alarms potential-violation policy] user@host# set policy-match threshold 100 size 100
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration durch Eingabe des show security alarms Befehls. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
policy {
source-ip {
threshold 1000;
duration 20;
}
destination-ip {
threshold 1000;
duration 10;
}
application {
size 10240;
}
policy-match {
threshold 100;
size 100;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Um zu bestätigen, dass die Konfiguration ordnungsgemäß funktioniert, geben Sie im Betriebsmodus den show security alarms Befehl ein.
Übereinstimmende Sicherheits-Richtlinien
Mit dem show security match-policies Befehl können Sie Datenverkehrsprobleme anhand der Übereinstimmungskriterien beheben: Quellport, Zielport, Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll. Wenn Ihr Datenverkehr beispielsweise nicht durchgelassen wird, weil entweder keine geeignete Richtlinie konfiguriert ist oder die Übereinstimmungskriterien falsch sind, können Sie mit dem show security match-policies Befehl offline arbeiten und ermitteln, wo das Problem tatsächlich besteht. Es verwendet die Suchmaschine, um das Problem zu identifizieren, und ermöglicht es Ihnen so, die entsprechende Übereinstimmungsrichtlinie für den Datenverkehr zu verwenden.
Die result-count Option gibt an, wie viele Richtlinien angezeigt werden sollen. Die erste aktivierte Richtlinie in der Liste ist die Richtlinie, die auf den gesamten übereinstimmenden Datenverkehr angewendet wird. Andere Richtlinien darunter werden von der ersten "abgeschattet" und werden nie vom übereinstimmenden Datenverkehr getroffen.
Der show security match-policies Befehl gilt nur für Sicherheitsrichtlinien. IDP-Richtlinien werden nicht unterstützt.
Beispiel 1: Sicherheitsübereinstimmungsrichtlinien anzeigen
user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: z1, To zone: z2
Source addresses:
a2: 203.0.113.1/25
a3: 10.10.10.1/32
Destination addresses:
d2: 203.0.113.129/25
d3: 192.0.2.1/24
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [21-21]
Beispiel 2: Verwenden der Option result-count
Standardmäßig enthält die Ausgabeliste die Richtlinie, die auf Datenverkehr mit den angegebenen Merkmalen angewendet wird. Um mehr als eine Richtlinie aufzulisten, die den Kriterien entspricht, verwenden Sie die result-count Option. Die erste aufgeführte Richtlinie ist immer die Richtlinie, die auf den übereinstimmenden Datenverkehr angewendet wird. Wenn der result-count Wert zwischen 2 und 16 liegt, enthält die Ausgabe alle Richtlinien, die den Kriterien entsprechen, bis zum angegebenen result-count. Alle Richtlinien, die nach der ersten Richtlinie aufgeführt sind, werden von der ersten Richtlinie "abgeschattet" und nie auf übereinstimmenden Datenverkehr angewendet.
Verwenden Sie diese Option, um die Positionierung einer neuen Richtlinie zu testen oder eine Richtlinie zu beheben, die für bestimmten Datenverkehr nicht wie erwartet angewendet wird.
Im folgenden Beispiel stimmen die Datenverkehrskriterien mit zwei Richtlinien überein. Die erste aufgeführte Richtlinie enthält die Aktion, p1die auf den Datenverkehr angewendet wird. Die Richtlinie p15 wird von der ersten Richtlinie überschattet, und ihre Aktion wird daher nicht auf übereinstimmenden Datenverkehr angewendet.
user@host> show security match-policies from-zone zone-A to-zone zone-B source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1004 destination-port 80 protocol tcp result-count 5
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: zone-A, To zone: zone-B
Source addresses:
sa1: 10.10.0.0/16
Destination addresses:
da5: 192.0.2.0/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Policy: p15, action-type: deny, State: enabled, Index: 18
Sequence number: 15
From zone: zone-A, To zone: zone-B
Source addresses:
sa11: 10.10.10.1/32
Destination addresses:
da15: 192.0.2.5/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Siehe auch
Verfolgung der Trefferanzahl von Richtlinien
Verwenden Sie den show security policies hit-count Befehl, um die Nutzenrate von Sicherheitsrichtlinien entsprechend der Anzahl der Treffer anzuzeigen, die sie erhalten. Mit dieser Funktion können Sie bestimmen, welche Richtlinien auf dem Gerät verwendet werden und wie häufig sie verwendet werden. Abhängig von den ausgewählten Befehlsoptionen kann die Anzahl der Treffer ohne Reihenfolge oder in aufsteigender oder absteigender Reihenfolge aufgelistet und auf die Anzahl der Treffer beschränkt werden, die über oder unter eine bestimmte Anzahl oder innerhalb eines Bereichs liegen. Es werden Daten für alle Zonen angezeigt, die den Richtlinien oder benannten Zonen zugeordnet sind.
Überprüfen der Speicherauslastung
Sie können Speicherprobleme isolieren, indem Sie Speicherwerte vor und nach Richtlinienkonfigurationen vergleichen.
Bestimmte Methoden können helfen, die aktuelle Speicherauslastung auf dem Gerät zu überwachen und Parameter zu optimieren, um die Systemkonfiguration besser zu dimensionieren, insbesondere während der Richtlinienimplementierung.
So überprüfen Sie die Speichernutzung:
Verwenden Sie den Befehl, um die
show chassis routing-engineGesamtspeicherauslastung der Routing-Engine (RE) zu überprüfen. Die folgende Ausgabe dieses Befehls zeigt eine Speicherauslastung von 39 Prozent:user@host#
show chassis routing-engineRouting Engine status: Slot 0: Current state Master Election priority Master (default) DRAM 1024 MB Memory utilization 39 percent CPU utilization: User 0 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 97 percent Model RE-PPC-1200-A Start time 2011-07-09 19:19:49 PDT Uptime 37 days, 15 hours, 44 minutes, 13 seconds Last reboot reason 0x3:power cycle/failure watchdog Load averages: 1 minute 5 minute 15 minute 0.22 0.16 0.07Verwenden Sie den
show system processes extensiveBefehl, um Informationen zu den Prozessen abzurufen, die auf der Routing-Engine ausgeführt werden.Verwenden Sie die Option im
show system processes extensiveBefehl, um diefind nsddirekte Verwendung im Network Sicherheit Daemon (NSD) mit einem insgesamt verwendeten Speicher von 10 Megabyte und einer CPU-Auslastung von 0 Prozent anzuzeigen.user@host# show system processes extensive | find nsd 1182 root 1 96 0 10976K 5676K select 2:08 0.00% nsd 1191 root 4 4 0 8724K 3764K select 1:57 0.00% slbd 1169 root 1 96 0 8096K 3520K select 1:51 0.00% jsrpd 1200 root 1 4 0 0K 16K peer_s 1:10 0.00% peer proxy 1144 root 1 96 0 9616K 3528K select 1:08 0.00% lacpd 1138 root 1 96 0 6488K 2932K select 1:02 0.00% ppmd 1130 root 1 96 0 7204K 2208K select 1:02 0.00% craftd 1163 root 1 96 0 16928K 5188K select 0:58 0.00% cosd 1196 root 1 4 0 0K 16K peer_s 0:54 0.00% peer proxy 47 root 1 -16 0 0K 16K sdflus 0:54 0.00% softdepflush 1151 root 1 96 0 15516K 9580K select 0:53 0.00% appidd 900 root 1 96 0 5984K 2876K select 0:41 0.00% eventd
Überprüfen Sie die Größe der Konfigurationsdatei. Speichern Sie die Konfigurationsdatei unter einem eindeutigen Namen, bevor Sie die CLI beenden. Geben Sie dann den
ls -1 filenameBefehl aus der Shell-Eingabeaufforderung in der UNIX-Shell ein, um die Dateigröße zu überprüfen, wie in der folgenden Beispielausgabe gezeigt:user@host> start shell % ls -l config -rw-r--r-- 1 remote staff 12681 Feb 15 00:43 config
Siehe auch
Überwachen von Statistiken zu Sicherheitsrichtlinien
Zweck
Überwachen und zeichnen Sie Datenverkehr auf, den Junos OS auf der Grundlage zuvor konfigurierter Richtlinien zulässt oder verweigert.
Aktion
Um den Datenverkehr zu überwachen, aktivieren Sie die Optionen "Anzahl" und "Protokoll".
Anzahl—Konfigurierbar in einer individuellen Richtlinie. Wenn count aktiviert ist, werden Statistiken für Sitzungen erfasst, die für eine bestimmte Richtlinie in das Gerät gelangen, sowie für die Anzahl der Pakete und Bytes, die das Gerät für eine bestimmte Richtlinie in beide Richtungen durchlaufen. Für die Anzahl (nur für Pakete und Bytes) können Sie angeben, dass Alarme generiert werden, wenn der Datenverkehr bestimmte Schwellenwerte überschreitet. Siehe Anzahl (Sicherheits-Richtlinien).
Log—Die Protokollierungsfunktion kann mit Sicherheitsrichtlinien während der Phase der Sitzungsinitialisierung (session-init) oder des schließenden Sitzungs (session-close) aktiviert werden. Siehe Protokoll (Sicherheitsrichtlinien).
Um Protokolle von verweigerten Verbindungen anzuzeigen, aktivieren Sie log on session-init.
Um Sitzungen nach ihrem Abschluss/Beenden zu protokollieren, aktivieren Sie Log on session-close.
Das Sitzungsprotokoll ist in Echtzeit im Flow Code aktiviert, was sich auf die Benutzerleistung auswirkt. Wenn sowohl session-close als auch session-init aktiviert sind, wird die Leistung im Vergleich zur Aktivierung von session-init weiter beeinträchtigt.
Weitere Informationen zu den für Sitzungsprotokolle erfassten Informationen finden Sie unter Informationen in Sitzungsprotokolleinträgen für Services Gateways der SRX-Serie.
Überprüfen von Schattenrichtlinien
- Überprüfen aller Schattenrichtlinien
- Überprüfen einer Richtlinie Schatten auf eine oder mehrere Richtlinien
- Überprüfen, ob eine Richtlinie von einer oder mehreren Richtlinien überschattet wird
Überprüfen aller Schattenrichtlinien
Zweck
Überprüfen Sie alle Richtlinien, die eine oder mehrere Richtlinien schatten.
Aktion
Geben Sie im Betriebsmodus die folgenden Befehle ein:
Geben Sie für logische Systeme den
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-nameBefehl ein.Geben Sie für globale Richtlinien den
show security shadow-policies logical-system lsys-name globalBefehl ein.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b
Policies Shadowed policies
P1 P3
P1 P4
P2 P5
Bedeutung
Die Ausgabe zeigt die Liste aller Richtlinien an, die andere Richtlinien abschatten. In diesem Beispiel überschattet die P1-Richtlinie die P3- und P4-Richtlinien und die P2-Richtlinie die P5-Richtlinien.
Überprüfen einer Richtlinie Schatten auf eine oder mehrere Richtlinien
Zweck
Überprüfen Sie, ob eine bestimmte Richtlinie eine oder mehrere Richtlinien überschattet, die danach positioniert sind.
Aktion
Geben Sie im Betriebsmodus die folgenden Befehle ein:
Geben Sie für logische Systeme den
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-nameBefehl ein.Geben Sie für globale Richtlinien den
show security shadow-policies logical-system lsys-name global policy policy-nameBefehl ein.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P1
Policies Shadowed policies
P1 P3
P1 P4
Bedeutung
Die Ausgabe zeigt alle Richtlinien an, die von der angegebenen Richtlinie geschattet werden. In diesem Beispiel überschattet die P1-Richtlinie die P3- und P4-Richtlinien.
Überprüfen, ob eine Richtlinie von einer oder mehreren Richtlinien überschattet wird
Zweck
Überprüfen Sie, ob eine bestimmte Richtlinie von einer oder mehreren davor positionierten Richtlinien überschattet wird.
Aktion
Geben Sie im Betriebsmodus die folgenden Befehle ein:
Geben Sie für logische Systeme den
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-name reverseBefehl ein.Geben Sie für globale Richtlinien den
show security shadow-policies logical-system lsys-name global policy policy-name reverseBefehl ein.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
Policies Shadowed policies
P1 P4
Bedeutung
Die Ausgabe zeigt die angegebene Richtlinie an, die von einer oder mehreren Richtlinien geschattet wird. In diesem Beispiel wird die P4-Richtlinie von der P1-Richtlinie überschattet.
Fehlerbehebung bei Sicherheitsrichtlinien
- Synchronisieren von Richtlinien zwischen Routing-Engine und Packet Forwarding Engine
- Überprüfen eines fehlgeschlagenen Commits einer Sicherheit-Richtlinie
- Überprüfen eines Sicherheitsrichtlinien-Commits
- Suche nach Debug-Richtlinien
Synchronisieren von Richtlinien zwischen Routing-Engine und Packet Forwarding Engine
Problemstellung
Beschreibung
Sicherheitsrichtlinien werden in der Routing-Engine und der Paketweiterleitungs-Engine gespeichert. Sicherheitsrichtlinien werden von der Routing-Engine an die Packet Forwarding Engine übertragen, wenn Sie Konfigurationen bestätigen. Wenn die Sicherheitsrichtlinien auf der Routing-Engine nicht mit der Packet Forwarding Engine synchronisiert sind, schlägt der Commit einer Konfiguration fehl. Core-Dump-Dateien können generiert werden, wenn der Commit wiederholt versucht wird. Die Synchronisierung kann folgende Ursachen haben:
Eine Richtlinienmeldung von der Routing-Engine an die Packet Forwarding Engine geht während der Übertragung verloren.
Ein Fehler mit der Routing-Engine, z. B. eine UID für wiederverwendete Richtlinien.
Umgebung
Die Richtlinien in der Routing-Engine und der Packet Forwarding Engine müssen synchronisiert sein, damit die Konfiguration übernommen werden kann. Unter bestimmten Umständen können Richtlinien in der Routing-Engine und der Packet Forwarding Engine jedoch nicht synchron sein, was dazu führt, dass der Commit fehlschlägt.
Symptome
Wenn die Richtlinienkonfigurationen geändert werden und die Richtlinien nicht mehr synchronisiert sind, wird die folgende Fehlermeldung angezeigt: error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
Lösung
Verwenden Sie den show security policies checksum Befehl, um den Prüfsummenwert der Sicherheitsrichtlinie anzuzeigen, und verwenden Sie den request security policies resync Befehl, um die Konfiguration von Sicherheitsrichtlinien in der Routing-Engine und der Packet Forwarding Engine zu synchronisieren, wenn die Sicherheitsrichtlinien nicht synchron sind.
Überprüfen eines fehlgeschlagenen Commits einer Sicherheit-Richtlinie
Problemstellung
Beschreibung
Die meisten Fehler bei der Richtlinienkonfiguration treten während eines Commits oder zur Laufzeit auf.
Commit-Fehler werden direkt in der CLI gemeldet, wenn Sie den CLI-Befehl commit-check im Konfigurationsmodus ausführen. Diese Fehler sind Konfigurationsfehler, und Sie können die Konfiguration nicht bestätigen, ohne diese Fehler zu beheben.
Lösung
Gehen Sie wie folgt vor, um diese Fehler zu beheben:
Überprüfen Sie Ihre Konfigurationsdaten.
Öffnen Sie die Datei /var/log/nsd_chk_only. Diese Datei wird bei jeder Durchführung einer Commit-Prüfung überschrieben und enthält detaillierte Fehlerinformationen.
Überprüfen eines Sicherheitsrichtlinien-Commits
Problemstellung
Beschreibung
Wenn Sie beim Ausführen eines Richtlinienkonfigurations-Commits feststellen, dass das Systemverhalten falsch ist, führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:
Lösung
Operational show Commands: Führen Sie die operationalen Befehle für Sicherheitsrichtlinien aus, und überprüfen Sie, ob die in der Ausgabe angezeigten Informationen mit den Erwartungen übereinstimmen. Wenn nicht, muss die Konfiguration entsprechend geändert werden.
Trace-Optionen – Legen Sie den
traceoptionsBefehl in Ihrer Richtlinienkonfiguration fest. Die Flags unter dieser Hierarchie können gemäß Benutzeranalyse dershowBefehlsausgabe ausgewählt werden. Wenn Sie nicht bestimmen können, welches Flag verwendet werden soll, kann die flag-Optionallverwendet werden, um alle Trace-Protokolle zu erfassen.user@host#
set security policies traceoptions <flag all>
Sie können auch einen optionalen Dateinamen konfigurieren, um die Protokolle zu erfassen.
user@host# set security policies traceoptions <filename>
Wenn Sie in den Trace-Optionen einen Dateinamen angegeben haben, können Sie unter /var/log/<filename> nach der Protokolldatei suchen, um festzustellen, ob in der Datei Fehler gemeldet wurden. (Wenn Sie keinen Dateinamen angegeben haben, wird der Standarddateiname ereignisiert.) Die Fehlermeldungen geben den Fehlerort und die entsprechende Ursache an.
Nachdem Sie die Ablaufverfolgungsoptionen konfiguriert haben, müssen Sie die Konfigurationsänderung, die das falsche Systemverhalten verursacht hat, erneut bestätigen.
Suche nach Debug-Richtlinien
Problemstellung
Beschreibung
Wenn Sie über die richtige Konfiguration verfügen, aber ein Teil des Datenverkehrs fälschlicherweise verworfen oder zugelassen wurde, können Sie das lookup Flag in den Trace-Optionen für Sicherheitsrichtlinien aktivieren. Das lookup Flag protokolliert die nachschlagebezogenen Ablaufverfolgungen in der Ablaufverfolgungsdatei.
Lösung
user@host# set security policies traceoptions <flag lookup>
Hohe Verfügbarkeit (HA) Synchronisierung des Adressnamens, Cache auflösen
Der Netzwerksicherheitsprozess (NSD) wird neu gestartet, wenn das System neu gestartet wird, ein Failover mit hoher Verfügbarkeit auftritt oder wenn der Prozess abstürzt. Wenn während dieser Zeit eine große Anzahl von Domainnamenadressen in den Sicherheitsrichtlinien konfiguriert ist, versuchen SRX-Firewalls, Anfragen an den DNS-Server zu senden, um alle aufgelösten IP-Adressen zu erhalten. Wenn eine große Anzahl von DNS-Abfragen und -Antworten ausgetauscht wird, wird eine große Menge an Systemressourcen verbraucht. Daher können SRX-Firewalls keine Antwort vom DNS-Server erhalten, und die Adresse eines Hostnamens in einem Adressbucheintrag kann möglicherweise nicht korrekt aufgelöst werden. Dies kann zu einem Abbruch des Datenverkehrs führen, da keine Übereinstimmung mit der Sicherheitsrichtlinie oder Sitzung gefunden wird. Die neue Erweiterung der SRX-Firewalls behebt dieses Problem, indem die DNS-Abfrageergebnisse in einer lokalen DNS-Cache-Datei zwischengespeichert und die DNS-Cache-Datei regelmäßig vom primären Knoten der Hohe Verfügbarkeit zum Backup-Knoten der hohen Verfügbarkeit synchronisiert werden. In den DNS-Cache-Dateien werden IP-Adressen, Domänenname und TTL-Werte gespeichert. Nach dem Failover der Hohe Verfügbarkeit wird der vorherige Sicherungsknoten zum primären Knoten. Da alle DNS-Cacheergebnisse auf dem neuen primären Knoten verfügbar sind, wird die Verarbeitung der Sicherheitsrichtlinien fortgesetzt und der Pass-Through-Datenverkehr wird gemäß den Richtlinienregeln zugelassen.
Ab Junos OS Version 19.3R1 wird der DNS-Cachespeicher der Richtlinie mit einer lokalen DNS-Cachedatei auf dem Hohe Verfügbarkeit aktiven Knoten synchronisiert und auf den Sicherungsknoten Hohe Verfügbarkeit kopiert, um DNS-Abfragen oder -Antworten während des NSD-Neustarts zu unterdrücken.
Die folgenden Schritte werden ausgeführt, damit die Synchronisierung stattfinden kann:
Der DNS-Cachespeicher der Richtlinie wird alle 30 Sekunden mit einer lokalen DNS-Cachedatei der Richtlinie synchronisiert, die sich im Pfad /var/db/policy_dns_cache befindet, wenn sich der Inhalt des DNS-Cachespeichers der Richtlinie während dieses Zeitraums geändert hat.
Die lokale DNS-Cachedatei wird vom primären Hohe Verfügbarkeit Knoten mit Hohe Verfügbarkeit Sicherungsknoten synchronisiert, unmittelbar nachdem die lokale DNS-Cachedatei in Schritt 1 aktualisiert wurde.
Die Synchronisierung umfasst die folgenden Inhalte:
-
Domainname
-
IPv4-Adressliste und ihre TTL (Time to Live)
-
IPv6-Adressliste und ihre TTL
Wenn NSD neu gestartet wird, liest und analysiert es die lokale DNS-Cachedatei und importiert alle Cacheeinträge in den Speicher. Die Synchronisierung stellt sicher, dass DNS-Abfragen während eines NSD-Neustarts unterdrückt werden. NSD wird während Hohe Verfügbarkeit Failover auf dem neuen primären Knoten neu gestartet, da die aufgelösten IP-Adressen für Domänennamen beim Lesen von Richtlinienkonfigurationen bereits im DNS-Cachespeicher vorhanden sind. Daher wird neuer Pass-Through-Datenverkehr gemäß der Sicherheitsrichtlinie nach Hohe Verfügbarkeit Failover zugelassen, da alle aufgelösten IP-Adressen für Domänennamen innerhalb der Richtlinien auf der Routing-Engine und Packet Forwarding Engine des neuen primären Knotens vorhanden sind.
Plattformspezifisches Speichernutzungsverhalten
Verwenden Sie den Feature-Explorer , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
Verwenden Sie die folgende Tabelle, um das plattformspezifische Verhalten für Ihre Plattform zu überprüfen:
| Plattform |
Unterschied |
|---|---|
| SRX-Serie |
|