This product is not supported for your selected
Datadog site. (
).
概要
AAP の Exploit Prevention を使うと、重要なアプリケーションと API をゼロ デイ脆弱性から守れます。チューニングや再設定は不要です。
AAP のコンテキスト認識機能により、アプリケーションのロジック、データ フロー、状態を深く把握できます。
Datadog tracer のテレメトリーを事前定義のヒューリスティクスと組み合わせることで、より高い精度でエクスプロイトを検知してブロックします。正当なトラフィックへの影響は最小限に抑えられます。
Exploit Prevention の仕組み
- アプリケーションに Datadog AAP トレーシング ライブラリを組み込むと、リクエスト、コード実行、データ フローなど、アプリケーション内のあらゆるインタラクションの詳細が収集されます。
- 攻撃ペイロードがアプリケーションに到達すると、AAP はそのペイロードが既知の脆弱性に紐づくコード パスを通過するかどうかを評価します。
- 潜在的なエクスプロイトが検出されると、AAP は次の処理を行います。
- AAP は被害が発生する前にリクエストをリアル タイムでブロックします。
- AAP は追加調査のためにセキュリティ シグナルを生成します。
- Exploit Prevention の検知結果にはスタック トレースが付随し、脆弱性が存在するコード上の位置を完全に可視化できます。修正に向けた道筋が明確になります。
例 1: Server-side request forgery (SSRF)
攻撃者がサーバーをだまして、内部システムや外部サーバーに対する不正なリクエストを送らせます。その結果、情報漏えいにつながったり、さらなる悪用の足掛かりになったりします。
AAP Exploit Prevention は、ユーザー パラメータによって一部または全体が制御されるリクエストの URL が、攻撃者によって改ざんされ、リクエスト本来の目的が変えられていないかを確認します。
例 2: Local file inclusion (LFI)
攻撃者が脆弱なパラメータを悪用し、サーバー上のローカル ファイルを取り込ませます。設定ファイルなどの機密データが露出したり、リモートでのコード実行につながったりする可能性があります。
AAP Exploit Prevention はすべてのファイル アクセス試行を検査し、パスがインジェクションされていないか、また制限されたファイルへのアクセスが発生していないかを判定します。
例 3: SQL injection (SQLi)
攻撃者がクエリに悪意ある SQL コードを埋め込み、データベースへの不正アクセス、データ改ざん、管理操作の実行などを狙います。
AAP Exploit Prevention はすべての SQL クエリをインターセプトし、ユーザー パラメータがインジェクションされていないか、またその結果として SQL クエリ本来の目的や構造が変化していないかを確認します。
前提条件
ライブラリの互換性
| エクスプロイト種別 | .NET | Python | Go | Java | Node.js | PHP | Ruby |
|---|
| サーバー サイド リクエスト フォージェリー (SSRF) | v3.3.0 | v2.15.0 | v1.70.1 | v1.42.0 | v5.20.0, v4.44.0 | Q1 ‘25 に利用可能 | Q1 ‘25 に利用可能 |
| Local File Inclusion (LFI) | v3.5.0 | v2.15.0 | orchestrion v1.0.0 | v1.42.0 | v5.24.0, v4.48.0 | Q1 ‘25 に利用可能 | Q1 ‘25 に利用可能 |
| SQL Injection (SQLi) | v3.4.0 | v2.16.0 | v1.70.1 | v1.42.0 | v5.25.0, v4.49.0 | Q1 ‘25 に利用可能 | Q4 ‘24 に利用可能 |
| コマンドインジェクション | v3.4.0 | v2.15.0 | Q4 ‘24 に利用可能 | v1.45.0 | v5.25.0, v4.49.0 | Q1 ‘25 に利用可能 | Q1 ‘25 に利用可能 |
Exploit Prevention を有効化する
In-App WAF (Security > App and API Protection > Protection > In-App WAF) に移動します。
サービスに Datadog 管理ポリシーを適用している場合は、次の手順に従ってください。
a. ポリシーを複製します。たとえば、Managed - Block attack tools ポリシーを使用できます。
b. ポリシー名と説明を追加します。c. 作成したポリシーをクリックし、Local File Inclusion ルール セットを選択します。Local File Inclusion exploit ルールのブロックを有効にします。d. 同様に、Server-side Request Forgery ルール セットを選択し、Server-side request forgery exploit ルールのブロックを有効にします。サービスにカスタム ポリシーを適用している場合は、ポリシー複製の手順 (2.a と 2.b) を省略できます。そのまま Exploit Prevention ルールを blocking モードで設定してください (2.c と 2.d)。
AAP でエクスプロイト試行を確認する
Exploit Prevention を有効にすると、AAP がエクスプロイトの試行を検知した時点で、そのリクエストをブロックします。Exploit Prevention の検知結果には常にスタック トレースが付随するため、コード内のどこに脆弱性があるのかを明確に把握でき、修正に向けた道筋を立てやすくなります。
さらに AAP は、ブロックされたすべてのトレースを関連付け、サービスを狙っている攻撃者 IP アドレスを切り分けたシグナルも生成します。攻撃元の IP を一括でブロックする、といった対応が可能です。
参考資料