拒否による高いオンチップ記述子とパケット バッファの使用量 policy により、トラフィックの遅延とドロップが発生する

• 遅延/低速が観察され、場合によっては を通過するトラフィックのパケット損失 Firewall が発生します。
• 通常、DataPlane ( DP ) の CPU 使用は期待される範囲内に残り、通常の状態や「動作条件」からの大きな逸脱はありません。
• flow_policy_denyグローバル カウンターのスパイク。
• リソース モニタイングレスバックログの実行を示すのトップ セッションには、grp ID 2 または 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 セッション ID は"Bad Key" を示し、その消費はオンチップの過半数を占めています。

> show session id 2022536315

Session      2022536315

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

• オンチップパケット記述子とパケットバッファの使用量の急増例( ライブデバッグ出力から):

> 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
• ゾーン保護
• DOS 保護

> 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

• 着信パケットが既存のセッションと一致しない場合は 、スローパスが適用されます。
• パケットが policy (セッションロギングが有効な状態で)slowpath で拒否に一致すると、パケットはドロップされ、トラフィックログエントリが作成されますが、セッションはインストールされません。
• 同じ 6 つのタプルを持つ次のパケットは、前のパケットと同じパスを通過します。
• slowpathは、名前が示すように、このステップではセッションの確立に関連するすべてのタスクが実行されるため、処理サイクルの数が多くなる可能性があります。
• スローパスの完了にかかる時間は Firewall 、設定とトラフィック パターンによって異なります。
• たとえば、セキュリティポリシーや NAT ポリシーが多数ある場合、スローパスの完了にかかる時間は長くなります。
• 同じ 6 個のタプルを持つすべてのパケットは ATOMIC 、着信順(1 回) でシリアル パケット処理を受けます。
• これらのパケットは逐次処理されなければならないため、並列処理のために異なるコアまたはスレッドに送信することはできません。
• パケットが によって処理されるのを待っている間、 DP CPU パケットの着信レートと各パケットのスローパスを完了するのにかかった時間によっては、パケットが蓄積される可能性があります。
• 同じ 6 個のタプル トラフィックが Firewall 、slowpath で拒否されると、オンチップの記述子と最終的にパケット バッファがいっぱいになる可能性があります。
• この時点で、トラフィックの問題が発生します。

• policy拒否が通常よりもかなり高いか、または高いと判断したら、次の手順は、このトラフィックの送信元を特定することです。
• トラフィックを拒否する場合に「セッション終了時のログ」が有効になっている場合 policy 、トラフィックログを-denyにフィルタリングすることで「問題のある」トラフィックを検出できます policy 。

• 軽減手法に移行する前に、許可されるはずのトラフィックがセキュリティ ポリシーによって許可されていることを確認する必要があります。
• トラフィックを許可する必要がある場合は、必要なセキュリティ policy を作成します。 トラフィックが許可されると、セッションがインストールされ、トラフィックがスローパスに適用されません。
• ネットワーク内のトラフィック パターンが不明な場合は、 policy 内部/信頼ゾーンからの syslog のような大量のトラフィックを許可するセキュリティを作成できます(必要に応じてセキュリティ プロファイルを適用します)。

• 問題の原因となっているホストの正確な IP がわかっている場合は、 policy アクション"Deny" を使用して DoS を作成すると、役立ちます。
• DoS policy ルールは特定の (送信元/宛先ゾーン、IP、サービス ポート) であり、同様のセキュリティを policy アクション拒否に置き換えることができます。
• DoS ポリシーはセキュリティルックアップの前に評価 policy され、多数のエントリを持たないため、パケットはブロックされるため、 firewall リソースを節約できます。

• policy 「保護」アクションで分類された DoS の作成
• A 分類済み DoS policy はアクション "Protect" で適用でき、アドレスは "ソース IP のみ" または "src-dest-ip-both" に一致します。

• 設定されたしきい値に達すると policy 、DoS は DoS ip-block テーブルを作成し、スローパスを受けることなくパケットのドロップを開始します。
• オフロード プロセッサを搭載したデバイスでは、ブロック テーブルがオフロードにインストールされ、への hardware 負荷がさらに軽減されます DP CPU 。
• 詳細については、次を参照してください :モニタブロック リストとDoS 保護プロファイルと Policy ルール

• 分類された DoS オブジェクトのしきい値は、顧客のトラフィック パターンとネットワークに基づいて変更され、デフォルト値がすべての環境に適用されるわけではありません。
• スローパス拒否攻撃の場合は、"送信元 IP のみ" または "src-dest-ip-both" だけが機能しますが、"宛先-ip のみ" を使用しても役に立ちません。
• インターネットに接続するゾーンの場合、ソース ip は潜在的に巨大になる可能性があるため、 firewall インターネット上のすべての可能なアドレスのカウンタ IP を格納する能力はありません。
• 参照:分類済みと集計 DoS プロファイル

• パケット バッファ保護 ( PBP ) は、8.0 から始まる機能です PAN-OS 。
• PBP は自動で、1 policy 秒あたりの事前構成された接続でトリガーされる DoS と比較して、実際のリソース使用率に基づいてトリガーされるので、優先されます。
• PBP firewallスローパスとファストパス (既存のセッション) の両方のバッファーの枯渇から保護します。
• Firewall は、バッファの乱用者を自動的に監視します。
• 設定されたアクティブ化しきい値(デフォルトは 50%)に達すると、 firewall 問題のあるトラフィックのドロップが開始 RED されます( )。
• バッファー使用率が 80% を超える場合 (このしきい値は内部的にハードコーディングされ、構成可能ではありません)、ブロック保留時間の間、dos ブロック・テーブル項目が作成されます。
• 参照:パケット バッファ保護

DoS 関連カウンタ SNMP を経由します (の一部 PAN-COMMON-MIB ):
 

コマンドの詳細については CLI 、「リソース モニタイングレストバックログの実行を表示する」を参照してください。

入力バックログから取得したセッションのshow セッション <id> </id> IDを実行しているときに、なぜ「不正なキー」が表示されるのですか?
この段階ではセッションがまだインストールされていないので、 のSESS-ID値は tag 内部値であり、実際のセッション ID ではありません。
スローパス拒否のこの指定の場合、値を注意深く見ると、 SESS-ID 値はセッションインデックスの範囲よりはるかに大きくなります。 (それ自体が手がかりです。セッションIDではない)
したがって、値が実際のセッション ID ではないため、show <idx> セッション ID を使用すると'Bad Key' が表示されます。

なぜ ATOMIC シリアルパケット処理 (オンタイム)が必要なのですか?</idx>

• 各パケット処理ステージは、シリアル パケット処理 (着信順で一度に 1 つずつ) を受けるか、または特定の 6 タプル/セッションに対して並列パケット処理を行うかという点で、異なる要件を持ちます。
• シリアル パケット処理の目的は、複数のコア/スレッドが同じ操作を実行したり、同じデータに対してアクセス/書き込みを行ったりしないようにすることです。
• たとえば、同じセッションに属するはずの新しいトラフィックがバーストで発生した場合、複数のコア/スレッドがセッションのインストールを実行したくないので、パケットを並列に処理するのではなく、シリアル処理を行います。

• 前述のように、同じ 6 個のタプル拒否トラフィックがシリアル処理を受けるため、ほとんどのコアが作業/パケットの処理を待機している可能性があります。
• したがって CPU 、使用量は低くなりますが、パケット バッファとオンチップ記述子リソースがいっぱいになる可能性があります。

• 各グループviz. flow_fastpath、flow_slowpathなどは、グループID(grp id)が割り当てられます
• grp ID 2 と 16 はどちらもスローパス/flow_slowpathを表します
• 古い hardware モデル(例 PA-3000 :、 PA-5000 など)で、 PA-7000 シリーズの古い NPC モデルの場合は、grp id 2が表示されます
• 新しい hardware モデル(例: PA-5200 PA-3200 、)で、 PA-7000 シリーズの新しいモデルの場合 NPC は、grp ID 16が表示されます