概要
前回の記事では、OCI WAFのメトリックをZabbixで可視化し、通信傾向に変化があればOCI LoggingのログをOCI Generative AIで分析して、調査が必要な兆候をメール通知する仕組みを紹介しました。
今回は続編としてログ分析で優先調査が必要と判断された場合に、根拠を確認できた送信元IPを対象として、WAFのリクエスト・アクセス・ルールを追加します。
これにより、管理者への通知に加えて、対象IPからのアクセスをWAFで拒否できます。
IPSのように「検知から防御へつなげる」ことを目指した構成ですが、本構成はメトリックとログを定期的に分析してアクセス制御へ反映する方式です。
前回から追加した機能
| 項目 | 前回 | 今回 |
|---|---|---|
| メトリック収集・保存 | OCI Monitoringから取得し、SQLiteへ保存 | 継続利用 |
| 可視化 | 全体・国別のアクセス数とブロック数をZabbixへ送信 | 継続利用 |
| 異常候補の抽出 | メトリックを評価し、必要な場合だけログを調査 | 継続利用 |
| ログ分析 | 生成AIと数値条件で攻撃兆候を評価 | 継続利用 |
| 対応 | 調査が必要な兆候をメール通知 | IP単位の根拠を再確認し、拒否ルールを追加 |
| 結果確認 | 分析結果を通知 | WAF更新の状態も通知に含める |
メトリック収集とZabbix送信は、前回の構成をそのまま利用します。今回追加した主な要素は、ログ分析後のIP選定、WAF更新、適用結果の確認です。
構成図
ロードバランサーに適用するOCI WAFのメトリックやログを取得して生成AIで解析します
攻撃兆候根拠を確認できた送信元IPを対象としてWAFのアクセス・ルールを追加して遮断します
| 項目 | 構成 |
|---|---|
| Web通信監視 | OCI WAF |
| 検知、ログ解析 | OCI Generative AI |
| WAFメトリック | OCI Monitoring |
| WAFログ | OCI Logging |
| 通知 | OCI Notifications |
| 監視分析およびWAF遮断ルール追加 | Virtual Machine |
構成
フロー
前回から追加した処理を黄色で示します
図では主経路を示しています。メトリックの最終判定がnormalの場合、Logging検索は行いません。また、最終ログ評価がwatchの場合は新規の自動遮断や、この経路のメール通知には進みません。
反映待ちの更新操作がある場合は、新しい攻撃判定とは別に、その操作結果を後続の実行で確認します。
生成AIでログ分析
ログ調査では、詳細確認用のサンプルに加え、Logging側の1分単位・送信元IP・パス・ステータス等の集計を利用します。最新200件のサンプルだけで、対象期間全体の件数を判断しないためです。
ログ評価は以下のようになります
| 最終ログ評価 | 新規の自動遮断 | この分析経路のメール通知 |
|---|---|---|
normal |
行わない | 行わない |
watch |
行わない | 行わない |
insufficient_data |
行わない | 行わない |
investigate |
IP単位の追加確認へ進む | 分析結果と遮断処理の結果を通知対象とする |
ここで重要なのは、「investigateを許可する条件に一致した」と「最終判定がinvestigateになった」は別であるという点です。
ローカル条件上はinvestigateを許可していても、AIの評価がwatchであれば、自動的にinvestigateへ引き上げることはしません。そのため、同じ件数の通信を発生させても、必ず遮断やメール通知に進むわけではありません。
IP単位の根拠・除外条件を再確認
対象WAFのログであることを確認したうえで、ログの送信元IPフィールドから候補を取り出し、IPごとに検知条件を再評価します。
例えば、複数パスへの継続アクセスでは、同じIPについて次を確認します。
| 条件 | 本構成の初期値 |
|---|---|
| 対象ステータス | 400・401・403・404 |
| 1分枠ごとの件数 | 50件以上 |
| 継続 | 3つの連続した1分枠 |
| 3分間の合計 | 150件以上 |
| 異なるパス | 20種類以上 |
ほかにも、設定したログインパスへの拒否集中や、既知の攻撃検知機能への一致などをIP単位で確認します。401や403だけで認証攻撃を確定するわけではありません。
全体のアクセス数が急増したという理由だけで、アクセス数上位のIPを遮断しないこともポイントです。分散した通信など、個々のIPに十分な根拠を結び付けられない場合は、遮断を見送り、分析結果を通知します。
[遮断対象の制限]
| 項目 | 本構成の設定・動作 |
|---|---|
| 対象WAF | ログのリソースIDと設定したWAF OCIDの一致を確認 |
| ログの鮮度 | 対象期間の終了から30分以内を条件とする |
| 対象IP | 公開IPとして扱える、ログに実在する送信元IP |
| 遮断範囲 | IPv4は単一IPの/32
|
| 1回の候補数 | 最大3IP |
| 自動管理ルール数 | 最大100件 |
既存設定を保持して拒否ルールを追加
今回は、IPごとのリクエスト・アクセス・ルールをWAFポリシーへ追加する方式にしました
| 項目 | 追加するルールの内容 |
|---|---|
| 名前 |
ai-block-で始まる自動管理用の名前 |
| 条件 | WAFが認識する送信元IPが対象IPと一致 |
| アクション | HTTPレスポンスを返す |
| 応答コード | 403 Forbidden |
| 配置 | 既存のリクエスト・アクセス・ルールより前 |
新しい拒否ルールを先頭へ追加することで、既存のAllowルールより先に評価する設計です。既存ルール同士の相対的な順序は変えませんが、追加IPについては従来の許可より拒否を優先する変更になります
定期分析では、同じ通信が複数回の評価対象になります。そこで、ポリシーOCIDとIPの組合せから、自動管理用のルール名を生成します。
同じ名前・条件・アクションのルールが存在し、参照先アクションが403を返すことを確認できた場合は、already_presentとして追加を省略します。
更新状態とルール定義を確認
次の順で更新します。
- 対象WAFから、現在適用されているWAFポリシーのOCIDを取得
- ポリシーの最新設定とETagを取得
- 現在のリクエスト・アクセス・ルールとデフォルトアクションを保持
- 新しい拒否ルールを加えたリクエスト・アクセス制御の更新データを作成
- 取得時のETagを条件に、OCI CLI経由で更新、取得後に他の更新が行われていた場合は設定上書きせず更新を失敗
| 状態 | 意味 |
|---|---|
applied |
ワークリクエスト成功とルール定義を確認 |
pending |
反映処理中。後続の実行で再確認 |
failed |
更新拒否、処理失敗、定義の検証失敗など |
uncertain |
応答喪失などで結果未確定。自動再送を止めて確認 |
no_change |
新しく追加するルールなし |
skipped |
根拠のあるIPがない、除外条件に該当するなど |
dry_run |
読み取りと変更案の検証のみ。WAFは更新しない |
分析結果と更新状態をメール通知
通知には、従来の分析結果に加えて、WAF更新の状態を含めます。
以下は、説明用に整えた通知文面の例です。
件名: [WAF][自動遮断設定:applied] waf1
WAFのログ評価で、優先調査が必要な兆候を検知しました。
※攻撃・侵入成功・情報漏洩が確定した通知ではありません。
判定: investigate
WAF名: waf1
WAF OCID: ocid1.webappfirewall.oc1.*****
WAFリージョン: *****
ログ検索期間: 2026-11-02 00:57:00 JST ~ 2026-11-02 01:13:00 JST
事象ID: 627b13614******
【状況(AIによる要約)】
サンプル200件のうち、IP **.**.**.** が194件を占め、全て 403 ステータスで
同一ルール(******)にマッチ。1分間のリクエスト数は最大63件で、
全体のリクエスト数は極端に低下。国別では日本がほぼ全件を占め、他国は極めて少数。
これらは単一IPによる大量アクセスの兆候であるが、WAFのブロックが原因である可能性が
高く、攻撃成功の証拠ではない。
【ローカル判定条件への一致】
継続した探索候補 / 件数=180 / 送信元IP=**.**.**.** / パス種類数=20
【参照根拠】
{"id": "G01", "metric": "sampled_entries", "value": 200}
{"id": "G06", "metric": "sample_top_listener_port",
"value": [{"value": "443", "count": 200}]}
{"id": "G07", "metric": "sample_top_response_provider",
"value": [{"value": "requestAccessControl/waf_e2e_test", "count": 194},
{"value": "**.**.**.**:**", "count": 6}]}
【管理者の確認事項】
1. IP **.**.**.** の詳細なリクエスト履歴を確認し、同一ルール(waf_e2e_test)への
マッチ理由を調査。
2. 日本からのアクセス集中の原因を特定するため、時間帯別・パス別のリクエスト分布を確認。
3. WAF設定でブロック対象となった条件(ヘッダー、パス、リクエスト数)を再確認。
【制約・未確認事項】
- サンプルは最新1ページのみで、全体のリクエスト分布は不明。
- ログ欠損・反映遅延により実際のリクエスト数が異なる可能性。
- 国別は上位10区分のみで、他国の変化は評価できない。
- ブロック理由やルール詳細はログに含まれていない。
- ログの反映遅延・取得上限・誤検知の可能性があります。
【WAF自動遮断設定の結果】
処理状態: applied
対象ポリシー: ocid1.webappfirewallpolicy.oc1.*****
説明: Work request SUCCEEDED; rule definitions verified. Traffic blocking is
not independently tested.
IP=**.**.**.** / ルール=ai-block-******f / 状態=applied
ワークリクエスト: ocid1.webappfirewallworkrequest.oc1.*****
- appliedはワークリクエスト成功とルール定義の確認を示します。対象IPからの実通信の拒否
は別途確認してください。
- dry_run/skippedでは追加遮断していません。pending/uncertainでは反映状態が未確定です。
- この版は期限解除を行いません。適用ルールは管理者が削除するまで残ります。
- ログに含まれるURLへのアクセスは行っていません。
推定AI料金 [メトリック分析]: USD 0.00027544
推定AI料金 [WAFログ分析]: USD 0.00056157
同一WAF・同一の判定条件/ルールの組合せは、設定した間隔で重複通知を抑制します。
まとめ
前回の可視化・検知・通知に、送信元IPの根拠確認とWAFアクセスルールの自動追加を組み合わせました。今後はLLMの選択や生成AIプロンプト改善による検知の精度向上を図りたいと思います