ブルートフォース署名の誤検出を送信する方法
2688
Created On 06/27/22 16:44 PM - Last Modified 10/22/24 09:58 AM
Objective
この記事では、トリガーされたブルート フォース シグネチャの基本的なトラブルシューティングと調査を行う方法と、ブルート フォース シグネチャの誤検知の可能性を報告する際に何を収集するかについて説明します。
Environment
全てPAN-OSバージョン
Procedure
ブルート フォース シグネチャ、トリガー条件、マッチング ロジックの詳細については、以下のリンクを参照してください。
ブルート フォース シグネチャと関連するトリガー条件
ノート：
ブルート フォース シグネチャを扱う際に最も重要なことは、ブルート フォース シグネチャの性質と概念を理解することです。PAN-OS . 各ブルート フォース シグネチャには、関連する独自の子シグネチャがあり、関連するブルート フォース イベントで論理的および機能的なペアを形成しています。子署名はペアの頭脳であり、ネットワーク トラフィック内で独自に定義された一致するロジックを探しています。親のブルート フォース シグニチャはペア内の単なるカウンタであり、それが独自に設定された属性のしきい値 (定義された時間範囲および集約基準ごとの子シグニチャのヒット数) と一致する場合にのみトリガーする必要があります。
たとえば、以下の署名は 1 つのペアを形成しています。
31914 SSH2 Login Attempt The child signature, 31914 is alert on every connection on the ssh server. 40015 SSH User Authentication Brute-force Attempt If a session has the same source and destination but triggers our child signature, 31914, 20 times in 60 seconds, we call it a brute force attack. Brute force signature's attributes are delivered with predefined default values and can be changed to reflect desired conditions in your network.
ブルートフォース署名のトリガーを調査する方法は?
可能性のあるブルート フォース イベントを調査するには、通常、関連するシグネチャの脅威キャプチャのみが必要であり、イベントに関する確実性とトリガーの誤検知の性質に関して十分です。 関連する脅威キャプチャが目的のシグネチャに対して環境内にまだ表示されていない場合は、特定のシグネチャに対して有効にする方法の詳細を以下に示します。
特定のスパイウェア対策シグネチャの脅威パケット キャプチャを有効にする方法は?
脅威ログで見られる最も一般的なブルート フォース トリガーは、以下の 4 つのシナリオに要約できます。
シナリオ 1:
ブルート フォース シグネチャ (親シグネチャ) のみが脅威ログに表示され、関連する子シグネチャは脅威ログに表示されません。
さらなる調査のための措置:
ブルート フォース/親署名の一致するポリシーと脆弱性プロファイルを検索します (UTID 40015) を有効にし、対応する子署名のログと脅威のキャプチャを有効にします (UTID 31914) 子シグネチャ設定アクションの脅威例外を作成することにより、ALERTパケットキャプチャ部分を「無効」から「単一パケット」に設定します。
これを行う方法？
ログに「ルール名」列が追加されている場合は、脅威ログから、または拡大鏡をクリックして詳細なログ ビューから、一致するルールを見つけます。 そこから、関連する脆弱性プロファイルを見つけることができます。
これを行うと、次に子シグネチャの条件が一致したときに、子シグネチャの脅威ログにログ エントリと脅威キャプチャ情報が表示されます。 ログで親署名のトリガーにつながったトリガー条件がわかっている場合は、それを複製して子署名を確認できます。 要件ごとに問題が再現できない場合、トリガーの原因がわからない場合、または単純にクライアント マシンを制御していない場合は、次のブルート フォース イベントを待つ必要があります。
次は何？
脅威のキャプチャ (緑の矢印) をエクスポートし、ロジックが子シグネチャと一致するかどうかを確認します。
ロジックが一致する場合は、構成された属性が親/ブルート フォース署名に一致するかどうかを確認します。
後で報告および収集するために重要な脅威のキャプチャは、赤い四角形でマークされています。
親署名の属性値がデフォルト値から変更されましたUTID40015 であり、親シグネチャでトリガーされる前に、60 秒で子シグネチャで 10 回トリガーされるのと同じように、正しくトリガーされていることがわかります。
注: 親がトリガーされる前に、さまざまな数の子署名を表示することができます。これについては、次の記事で説明しています。
ブルート フォースの親子シグネチャの脅威ログ生成基準
正当なトラフィックがブルート フォース シグネチャに正しくヒットした場合の状況にどのように対処すればよいですか?
上記の例では、子署名と親署名の両方が正しくトリガーされ、構成に従って、ブルート フォースによる誤検知のケースではありません。 Firewall ネットワーク トラフィックと親シグニチャで構成された属性のみを確認します。 Firewall 可能性を考慮していないか、クライアントが脅威ログに表示されていることを認識していません (ソースIP) ブルート フォース シグネチャの場合は、ローカル/リモート スキャナーであり、誰かが計画されたスキャン アクティビティを実行した可能性があります。 Firewall 可能性を考慮に入れておらず、ネットワークトポロジも認識していません。NATネットワーク管理者が配置されているサブネットに対して実行され、その操作の性質上、すべてのトラフィックが表示されますFirewallシングルとしてIPしたがって、10の異なるSSH60 秒で 10 人の異なる管理者からの接続がトリガーされますUTID上記の例のように値が変更された 40015。
コンテキスト、セキュリティ要件、および希望に応じて、環境とネットワークに適用可能なこの種の正当で予想される状況に対処するためのさまざまなアプローチがあります。 異なるアクションの脅威例外、特定の脅威例外など、さまざまな形式で脅威例外を作成することを検討できます。IP 、脅威ログへの記録の有無にかかわらず脅威の例外、親シグネチャのしきい値の微調整など。 観測および調査されたブルート フォース イベントに合わせて、希望する優先調整を行うために、さまざまな構成変更を行うことができます。
重要な注意事項: この種の状況では、サポートがお客様に代わって最終決定を下すことはできません。
ブルート フォース シグネチャの真の誤検知を報告するにはどうすればよいですか?
子署名の一致するロジックが表示されない場合、または親署名のカウンターが正しくない場合は、次のデータ セットを収集して弊社に報告できます。
何を集める？
1. から「show system info」の出力を収集します。CLIあなたのfirewall、または WebGUI のダッシュボードから「一般情報」ペインをコピーします。
2. 順番に見られる子シグネチャの最初の 3 つの脅威キャプチャ (親シグネチャのカウンターは、これらを最初、2 番目、3 番目のヒットとしてカウントします) を収集し、ブルート フォース イベントの関連する調査時間枠で親シグネチャがトリガーされる前に 3 つの脅威キャプチャを収集します。 子シグネチャのすべての脅威キャプチャが必要というわけではありません。
明確にするために、上の写真を見てください後で報告および収集するために重要な脅威のキャプチャは、赤い四角形でマークされています。
3. 脅威ログ: 関連するブルート フォース脅威ログのみをエクスポートしてください。CSV必要なフィルターを配置してエクスポートを絞り込み、ケースにアップロードすることでフォーマットします。 ログには、最初にトリガーされた子署名からトリガーされた親署名までのエントリが含まれている必要があり、それらは収集された脅威キャプチャに対応している必要があります。
明確にするために、十分な脅威ログも同じ図に表示されます後で報告および収集するために重要な脅威のキャプチャは、赤い四角形でマークされています。
注: 脅威のキャプチャが必要であり、最初の調査に必要です。
必要なすべてのデータを 1 つのパスワードで保護して配置するZIPファイルに好みの名前を付け、選択した名前の前に 20220627- のようにプレフィックスを付けます。FP-SSHユーザー認証ブルートフォース Attempt.zip、アップロードのみZIPパスワードをファイルして共有します。 追加のデータ セットが必要な場合は、アップロードされたデータ セットが異なる同じチケットの下で、物事を明確な方法と明確な順序で維持するのに役立ちます。
シナリオ 2:
子シグネチャが脅威ログに表示され、アクションは両方ともリセットされ、関連する脅威キャプチャはありません。
さらなる調査のための措置:
子署名の一致するポリシーと脆弱性プロファイルを検索します (UTID 31914) を作成し、子署名の脅威の例外を作成して、子署名のログと脅威のキャプチャを有効にします。RESET-BOTHパケットキャプチャ部分を「無効」から「単一パケット」に設定します。
次のアクション？
シナリオ 1 で説明したのと同じ手順に従います。
注: 同じ送信元/送信先に気付く場合がありますIP、シナリオ 1 で見られるように、異なるアクションを持つ同じシグネチャの脅威ログの下に、同じルールと同じ一致するプロファイルが表示されます。 これはどのように可能ですか？ これらの状況につながる可能性のあるさまざまな状況があり、通常、それらは構成を反映していますFirewall. ここで、子署名に対するアクションの違いの根本的な原因は、プロファイルで行われた構成変更によるものです」TAC KB " シナリオ 2 のデータ収集が行われる前。 すべてのシグニチャに対して設定されたアクションは、「TAC KB " プロファイルは "デフォルト" から "リセット-両方" に変更され、変更されたプロファイルには例外が構成されていないため、上記の動作は構成された内容を正しく反映しています。
シナリオ 3:
脅威ログに子の署名が表示され、アクションが表示されるALERT関連する脅威のキャプチャはありません。
調査のためのアクション:
子署名の一致するポリシーと脆弱性プロファイルを検索します (UTID 31914)、子署名のロギングと脅威キャプチャを有効にします (UTID 31914) 子シグネチャ設定アクションの脅威例外を作成することにより、ALERTパケットキャプチャ部分を「無効」から「単一パケット」に設定します。
次のアクション？
シナリオ 1 で説明したのと同じ手順に従います。
シナリオ 4:
子署名が脅威ログに表示され、関連付けられた脅威キャプチャが既に存在します。
次のアクション？
シナリオ 1 で説明したのと同じ手順に従います。