Hohe On-Chip-Deskriptor- und Paketpufferauslastung aufgrund policy von Verweigerung, was zu Datenverkehrslatenz und -stürzen führt

• Latenz/Langsamkeit beobachtet, in einigen Fällen Paketverlust für Datenverkehr durch die Firewall .
• In der Regel bleibt die DataPlane ( DP ) Nutzung innerhalb des CPU erwarteten Bereichs und keine große Abweichung vom üblichen oder "Arbeitszustand".
• Spike in flow_policy_deny globalen Zählern.
• Die oberste Sitzung in Show Running Resource-Monitor Ingress-Backlogs hat grp id 2 oder grp id 16

> show running resource-monitor ingress-backlogs 
<snip>
-- SLOT: s1, DP: dp0 --
USAGE - ATOMIC: 88% TOTAL: 89%

TOP SESSIONS:
SESS-ID         PCT     GRP-ID  COUNT
2022536315      88%     16      3640

<snip>

• Show-Session-ID zeigt"Bad Key", und sein Verbrauch nimmt eine Mehrheit % des On-Chip.

> show session id 2022536315

Session      2022536315

            Bad Key: c2s: 'c2s'
            Bad Key: s2c: 's2c'
        index(local):                        : 9270395

• Spike in On-Chip-Paketdeskriptor und Paketpuffer-Nutzung, Beispiel (aus einer Live-Debug-Ausgabe):

> show running resource-monitor second last 5

DP s1dp0:

Resource monitoring sampling data (per second):

CPU load sampling by group:
flow_lookup                    :     3%
flow_fastpath                  :     3%
flow_slowpath                  :     3%
flow_forwarding                :     3%
flow_mgmt                      :     0%
flow_ctrl                      :     3%
nac_result                     :     3%
flow_np                        :     3%
dfa_result                     :     3%
module_internal                :     3%
aho_result                     :     3%
zip_result                     :     3%
pktlog_forwarding              :     9%
lwm                            :     0%
flow_host                      :     3%

CPU load (%) during last 5 seconds:
core   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
       *   0   3   2   2   3   3   3   4   4   2   3   2   3   3   2
       *   0   3   2   2   3   3   3   3   4   2   3   2   3   3   2
       *   0   3   3   2   4   4   3   3   3   2   2   2   3   3   3
       *   0   3   2   2   3   4   3   3   3   2   3   2   3   4   2
       *   0   3   3   2   3   3   3   3   3   2   2   2   3   4   2
core  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31
       2   2   2   2   2   3   3   3   3   3   3   3   3   3   3   3
       2   2   2   2   2   3   3   3   3   3   3   3   3   3   3   3
       2   3   2   2   2   3   3   3   2   4   3   3   2   3   3   2
       2   3   2   2   2   3   2   3   2   3   3   3   2   3   3   3
       2   2   2   2   2   2   2   3   3   3   3   3   3   3   3   3
core  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47
       3   2   2   2   2   2   3   2   2   2   2   2   3   2   4   9
       3   2   2   2   2   2   2   2   2   2   2   2   3   2   4   9
       3   2   2   3   2   2   2   2   2   2   2   2   3   2   4   9
       3   2   2   2   3   2   2   2   2   2   2   2   3   2   4   9
       3   2   3   2   2   2   3   2   2   2   2   2   3   2   4   9

Resource utilization (%) during last 5 seconds:
session:
  0   0   0   0   0 
packet buffer:
 14  13  13  13  12 
packet descriptor:
  0   0   0   0   0 
packet descriptor (on-chip):
100 100 100 100 100
<snip>

• PAN-OS
• Schutzzone
• DOS der Schutz

> show running resource-monitor ingress-backlogs 
<snip>
-- SLOT: s1, DP: dp0 --
USAGE - ATOMIC: 88% TOTAL: 89%

TOP SESSIONS:
SESS-ID         PCT     GRP-ID  COUNT
2022536315      88%     16      3640

<snip>

> show session id 2022536315

Session      2022536315

            Bad Key: c2s: 'c2s'
            Bad Key: s2c: 's2c'
        index(local):                        : 9270395

• Wenn ein eingehendes Paket nicht mit einer vorhandenen Sitzung übereinstimmt, unterliegt es slowpath.
• Wenn das Paket mit einem Deny policy in Slowpath übereinstimmt (wenn die Sitzungsprotokollierung aktiviert ist), wird das Paket verworfen und ein Datenverkehrsprotokolleintrag erstellt, aber eine Sitzung wird nicht installiert.
• Das nächste Paket mit den gleichen 6 Tupeln würde denselben Pfad wie das vorherige Paket durchlaufen.
• Slowpathkann, wie der Name schon sagt, eine größere Anzahl von Verarbeitungszyklen in Anspruch nehmen, da in diesem Schritt alle Aufgaben im Zusammenhang mit dem Einrichten einer Sitzung ausgeführt werden.
• Die Zeit, die zum Abschließen des Slowpaths erforderlich ist, hängt von der Firewall Konfiguration und dem Datenverkehrsmuster ab.
• Wenn z. B. eine große Anzahl von Sicherheits- oder Nat-Richtlinien vorhanden ist, wäre die Zeit, die für den Abschluss des Slowpaths aufgedauert wird, höher.
• Alle Pakete mit den gleichen 6 Tupeln werden ATOMIC der seriellen Paketverarbeitung in der eingehenden Reihenfolge (einmaliger) unterzogen.
• Da diese Pakete seriell verarbeitet werden müssen, können sie nicht zur parallelen Verarbeitung an verschiedene Kerne oder Threads gesendet werden.
• Da die Pakete darauf warten, von der verarbeitet zu DP CPU werden, kann es je nach der Eingangsrate der Pakete und der Zeit, die zum Abschließen des Slowpaths für jedes Paket verwendet wird, zu einer Anhäufung von Paketen kommen.
• Wenn es eine signifikante Rate/Menge von solchen 6 Tupeln Verkehr trifft die Firewall , wird auf Slowpath verweigert, die On-Chip-Deskriptoren und schließlich die Paketpuffer können gefüllt werden.
• An diesem Punkt würden Sie beginnen, Verkehrsprobleme zu sehen.

• Nachdem Sie festgestellt haben, dass die policy Verweigerung deutlich höher oder höher als üblich ist, besteht der nächste Schritt darin, die Quelle dieses Datenverkehrs zu identifizieren.
• Wenn "Log at session-end" für die Verweigerung des Datenverkehrs aktiviert policy ist, kann der "beleidigende" Datenverkehr gefunden werden, indem die Datenverkehrsprotokolle nach policy -deny gefiltert werden.

• Bevor wir in Minderungstechniken einsteigen, sollten wir sicherstellen, dass der Datenverkehr, der zugelassen werden soll, tatsächlich durch Sicherheitsrichtlinien zugelassen wird.
• Wenn der Datenverkehr zugelassen werden muss, erstellen Sie die erforderliche Sicherheit policy . Sobald der Datenverkehr zugelassen ist, wird eine Sitzung installiert, und der Datenverkehr unterliegt nicht dem langsamen Pfad.
• Wenn das Datenverkehrsmuster im Netzwerk nicht bekannt ist, kann eine Sicherheit policy erstellt werden, um Datenverkehr mit hohem Volumen wie syslog aus internen/vertrauenswürdigen Zonen zuzulassen (nach Bedarf Sicherheitsprofile anwenden).

• Wenn genaue IPs der Hosts, die das Problem verursachen, bekannt sind, hilft das Erstellen eines DoS policy mit der Aktion "Verweigern".
• DoS-Regeln policy sind spezifisch (Quell-/Zielzone, IP-Nachrichten, Dienstport) und können ähnliche Sicherheit policy durch Aktionsverweigerung ersetzen.
• Da DoS-Richtlinien vor der Sicherheitssuche ausgewertet werden policy und keine große Anzahl von Einträgen enthalten, werden Pakete früher blockiert, wodurch Ressourcen gespart firewall werden.

• Erstellen eines DoS, das mit der Aktion "Schützen" klassifiziert ist policy
• A klassifiziert DoS kann mit der policy Aktion "Protect" und der Adresse angewendet werden, die auf "source-ip only" oder "src-dest-ip-both" abgestimmt ist.

• Sobald der konfigurierte Schwellenwert erreicht ist, würde das DoS policy eine DoS ip-Block-Tabelle erstellen, die mit dem Ablegen von Paketen beginnt, ohne einem Slowpath enthont zu werden.
• Bei Geräten mit einem Abladeprozessor würde die Blocktabelle in der Offload installiert, hardware um die Last auf dem weiter zu DP CPU reduzieren.
• Weitere Informationen finden Sie unter : Monitor-Blockliste und DoS-Schutzprofile und Policy -regeln

• Schwellenwerte für das klassifizierte DoS-Objekt würden sich basierend auf dem Kundenverkehrsmuster und dem Netzwerk ändern, die Standardwerte sind möglicherweise nicht für alle Umgebungen anwendbar.
• Bei Slowpath-Deny-Angriffen würde nur "source-ip only" oder "src-dest-ip-both" funktionieren, die Verwendung von "destination-ip only" hilft nicht.
• Für Internet-Zonen, da Quell-IP-Anbieter potenziell riesig sein könnten, hat die firewall nicht die Kapazität, Zähler für jede mögliche Adresse im Internet zu IP speichern.
• Refer: Klassifizierte vs Aggregate DoS-Profile

• Packet Buffer Protection ( ) ist eine Funktion, die PBP ab PAN-OS 8.0 verfügbar ist.
• PBP wird bevorzugt, da es automatisch ist und basierend auf der tatsächlichen Ressourcenauslastung ausgelöst wird, im Vergleich zu DoS, policy das bei vorkonfigurierten Verbindungen pro Sekunde ausgelöst wird
• PBP schützt sowohl den firewall Slowpath- als auch den Fastpath-Puffer (vorhandene Sitzung).
• Firewall überwacht Pufferabusers automatisch.
• Nach Erreichen des konfigurierten Aktivierungsschwellenwerts (Standard 50%) beginnt der firewall Start, den beleidigenden Datenverkehr fallen zu lassen ( RED ).
• Wenn die Pufferauslastung über 80 % liegt (dieser Schwellenwert ist intern hartcodiert und nicht konfigurierbar), wird für eine Sperrdauer ein Dos-Blocktabelleneintrag erstellt.
• Siehe: Paketpufferschutz

DoS-bezogene Zähler über SNMP (Teil von PAN-COMMON-MIB ):
 

Weitere Informationen zum Befehl finden Sie unter Detaillierte Informationen zum Befehl " Show running CLI resource-monitor ingress-backlogs".

Warum sehen wir 'Bad Key' beim Ausführen der Show-Session-ID <id> </id> der Sitzung, die aus Ingress-Backlogs erhalten wurde?
Da die Sitzung zu diesem Zeitpunkt noch SESS-ID nicht installiert ist, ist der Wert unter ein interner tag Wert und nicht die tatsächliche Sitzungs-ID.
In diesem speziellen Fall von Slowpath-Verweigerung SESS-ID ist der Wert viel höher als der Sitzungsindexbereich, wenn Sie sich den Wert unter sorgfältig ansehen. (Was für sich genommen ein Hinweis ist. dass es nota Session ID ist)
Wenn Sie also die Show-Sitzungs-ID verwenden, <idx> da der Wert keine tatsächliche Sitzungs-ID ist, sehen Sie 'Bad Key'.

Warum benötigen wir ATOMIC eine serielle Paketverarbeitung (on-at-a-time)?</idx>

• Jede Paketverarbeitungsphase hat unterschiedliche Anforderungen, ob sie einer seriellen Paketverarbeitung (einmal in der eingehenden Reihenfolge) oder der parallelen Paketverarbeitung für ein bestimmtes 6 Tupel/Sitzung unterzogen werden soll.
• Das Ziel der seriellen Paketverarbeitung besteht darin, zu vermeiden, dass mehrere Kerne/Threads denselben Vorgang ausführen oder auf dieselben Daten zugreifen/schreiben.
• Wenn wir z. B. einen neuen Datenverkehr erhalten, der zur gleichen Sitzung gehören sollte, möchten wir nicht, dass mehrere Kerne/Threads die Sitzungsinstallation durchführen, daher verarbeiten wir die Pakete nicht parallel, sondern unterwerfen sie der seriellen Verarbeitung.

• Wie bereits erläutert, da die gleichen 6 Tupeln den Datenverkehr einer seriellen Verarbeitung unterziehen, ist es möglich, dass die meisten Kerne nur auf die Verarbeitung von Arbeit/Paketen warten.
• Daher wäre die CPU Nutzung gering, aber der Paketpuffer und die On-Chip-Deskriptorressourcen könnten sich füllen.

• Jeder Gruppe viz. flow_fastpath, flow_slowpath usw. wird eine Gruppen-ID (grp-ID) zugewiesen.
• grp id 2 und 16 stehen beide für slowpath/ flow_slowpath
• Bei älteren hardware Modellen (Z.B.: PA-3000 PA-5000 etc.) und bei PA-7000 serienalten älteren NPC Modellen würden Sie grp id 2 sehen
• Bei neueren hardware Modellen (Z.B.: PA-5200 ) und bei PA-3200 PA-7000 NPC Serien-Neuerer Modellen sehen Sie grp id 16