Utilisation élevée de descripteur et de tampon de paquet sur puce due au refus policy ayant pour résultat la latence et les baisses de trafic

• Latence / lenteur observée, dans certains cas la perte de paquets pour le trafic traversant le Firewall .
• Habituellement, l’utilisation dataplane DP () CPU reste dans la plage prévue et aucun écart énorme par rapport à l’habituel ou « état de travail ».
• Pic dans flow_policy_deny compteurs mondiaux.
• La session supérieure dans le spectacle en cours d’exécution de ressources moniteur ingress-backlogs a grp id 2 ou 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 montre« Bad Key », et sa consommation prend une majorité % de sur puce.

> show session id 2022536315

Session      2022536315

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

• Spike dans le descripteur de paquets sur puce et l’utilisation tampon de paquet, Exemple (à partir d’une sortie de débogage en direct):

> 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
• Zone Protection
• DOS Protection

> 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

• Si un paquet entrant ne correspond pas à une session existante, il est soumis à slowpath.
• Si le paquet correspond à un refus policy dans slowpath (avec enregistrement de session activé), le paquet est supprimé et une entrée de journal de trafic est créée, mais une session n’est pas installée.
• Le paquet suivant avec les mêmes 6 tuples passerait par le même chemin que le paquet précédent.
• slowpath, comme son nom l’indique, peut prendre un plus grand nombre de cycles de traitement, parce que c’est dans cette étape que toutes les tâches associées à l’établissement d’une session sont effectuées.
• Le temps pris pour compléter le slowpath dépend de la Firewall configuration et du modèle de trafic.
• Par exemple, s’il y a un grand nombre de stratégies de sécurité ou de nat, le temps nécessaire pour terminer slowpath serait plus élevé.
• Tous les paquets avec les mêmes 6 tuples sont soumis ou ATOMIC le traitement de paquets en série dans l’ordre entrant(un à la fois).
• Comme ces paquets doivent être traités en série, ils ne peuvent pas être envoyés à différents cœurs ou threads pour un traitement parallèle.
• Comme les paquets sont en attente d’être traitées par DP CPU le , en fonction du taux entrant de paquets et le temps nécessaire pour compléter slowpath pour chaque paquet, il peut y avoir accumulation de paquets.
• S’il ya un taux important / quantité de ces mêmes 6 tuples trafic frapper le , se faire refuser Firewall sur slowpath, les descripteurs sur puce et éventuellement les tampons de paquets peuvent se remplir.
• À ce stade, vous commenceriez à voir des problèmes de circulation.

• Une fois que vous avez déterminé que le policy refus est significativement élevé ou est plus élevé que d’habitude, la prochaine étape est d’identifier la source de ce trafic.
• Si « Log at session-end » est activé sur le refus du trafic, le trafic policy « in infraction » peut être trouvé en filtrant les journaux de trafic pour policy -refuser.

• Avant de passer aux techniques d’atténuation, nous devrions nous assurer que le trafic qui est censé être autorisé est effectivement autorisé par les politiques de sécurité.
• Si le trafic doit être autorisé, créez la sécurité policy requise. Une fois le trafic autorisé, une session sera installée et la circulation ne sera pas soumise à un lent chemin.
• Si le modèle de trafic dans le réseau n’est pas connu, une sécurité policy peut être créée pour permettre un trafic à fort volume comme le syslog à partir de zones internes/de confiance (appliquer des profils de sécurité au besoin).

• Si les adresses IP exactes des hôtes responsables du problème sont connues, la création d’un DoS policy avec l’action « Deny » vous aidera.
• Les règles DoS policy sont spécifiques (source/zone de destination, ADRESSES, port de service), et elles peuvent remplacer la sécurité similaire par policy le refus d’action.
• Étant donné que les stratégies DoS sont évaluées avant policy la recherchez la sécurité et n’ont pas un grand nombre d’entrées, les paquets sont bloqués plus tôt, ce qui permet d’économiser des firewall ressources.

• Création d’un DoS classé policy avec l’action « Protéger »
• A classés DoS policy peut être appliqué avec l’action « Protéger » et l’adresse appariée à« source-ip seulement »ou« src-dest-ip-both« .

• Une fois le seuil configuré atteint, le DoS policy créerait une table ip-block DoS, qui commencerait à laisser tomber les paquets sans être soumis à slowpath.
• Dans les appareils qui ont un processeur de déchargement, la table de bloc serait installé dans le hardware déchargement pour réduire davantage la charge sur le DP CPU .
• Pour plus de lecture, consultez : Monitor Block List et DoS Protection Profiles and Policy Rules

• Les seuils de l’objet DoS classifié changeraient en fonction du modèle de trafic client et du réseau, les valeurs par défaut peuvent ne pas être applicables à tous les environnements.
• Pour slowpath refuser les attaques que "source-ip seulement" ou "src-dest-ip-both" fonctionnerait, en utilisant « destination-ip seulement » n’aide pas.
• Pour les zones orientées vers Internet, puisque la source ips pourrait être potentiellement énorme, firewall le n’a pas la capacité de stocker des compteurs pour toutes IP les adresses possibles sur Internet.
• Référence : Profils DoS classifiés vs agrégés

• Packet Buffer Protection ( PBP ) est une fonctionnalité disponible à partir de PAN-OS 8.0.
• PBP est préférable, car il est automatique et est déclenché en fonction de l’utilisation réelle des ressources, par rapport à DoS policy qui est déclenché sur les connexions préconfigurées par deuxième seuil
• PBP protège à la firewall fois contre l’épuisement de la mémoire tampon slowpath et fastpath (session existante).
• Firewall surveille automatiquement les agresseurs tampons.
• Après avoir atteint le seuil d’activation configuré (par défaut 50%), firewall le commence à laisser tomber le trafic infaillant ( RED ).
• Si l’utilisation du tampon est supérieure à 80% (ce seuil est codé en interne et non configurable) pour une durée de temps de blocage, une entrée de table de bloc dos est créée.
• Référence: Protection tampon paquet

Compteurs liés à DoS via SNMP (partie PAN-COMMON-MIB de):
 

Reportez-vous à l’examen détaillé CLI du « afficher l’exécution des arriérés d’entrées de moniteurs de ressources » pour plus de détails sur la commande.

Pourquoi voyons-nous « Mauvaise clé » lors de l’exécution de l’id session <id> </id> d’exposition de la session obtenue à partir d’entrées-arriérés?
Étant donné qu’à ce stade la SESS-ID session n’est pas encore installée, la valeur sous est une valeur tag interne et non l’id de session réel.
Dans ce cas specifc de slowpath refuser, si vous regardez attentivement la valeur sous SESS-ID , la valeur est beaucoup plus élevé que la plage d’index de session. (Ce qui en soi est un indice. qu’il n’est pas une session id)
Par conséquent, lorsque vous utilisez l’id de session <idx> d’exposition puisque la valeur n’est pas un id de session réel, vous voyez 'Bad Key'.

Pourquoi avons-nous besoin ATOMIC ou le traitement des paquets en série (on-at-a-time)?</idx>

• Chaque étape de traitement des paquets a des exigences différentes en ce qui concerne la question de savoir s’il doit être soumis au traitement des paquets en série (un à la fois dans l’ordre entrant) ou au traitement parallèle des paquets pour un tuple/session donné de 6.
• L’objectif du traitement des paquets en série est d’éviter que plusieurs cœurs/threads effectuent la même opération ou accèdent/écrivent sur les mêmes données.
• Par exemple, si nous recevons une rafale de nouveau trafic qui devrait appartenir à la même session, nous ne voulons pas que plusieurs noyaux/threads effectuent l’installation de session, donc nous ne traitons pas les paquets parallélise mais les soumettons au traitement en série.

• Comme expliqué précédemment, puisque les mêmes 6 tuples nient le trafic est soumis au traitement en série, il est possible que la plupart des noyaux sont juste en attente pour le travail / paquets à traiter.
• Par CPU conséquent, l’utilisation serait faible, mais le tampon de paquets et les ressources de descripteur sur puce pourraient se remplir.

• Chaque groupe viz. flow_fastpath, flow_slowpath etc., se voit attribuer un id de groupe (grp id)
• grp id 2 et 16 sont tous deux pour slowpath / flow_slowpath
• Sur les hardware modèles plus anciens (Ex: PA-3000 , PA-5000 etc) et en cas de série PA-7000 anciens NPC modèles, vous verraient grp id 2
• Sur les nouveaux hardware modèles (Ex: PA-5200 , ) et en cas de série de nouveaux PA-3200 PA-7000 NPC modèles, vous verraient grp id 16