コンテンツにスキップ

攻撃検知の手順

WallarmプラットフォームはAPIトラフィックを継続的に分析し、不正リクエストをリアルタイムで緩和します。本記事では、Wallarmが攻撃から保護するリソースの種類、トラフィック中の攻撃検知方法、および検知された脅威の追跡と管理方法を説明します。

Attackとは何か、その構成要素は何か?

Attackとは、以下の特性でグループ化された1つのHitまたは複数のHitsです:

  • 同一の攻撃タイプ、悪意のあるペイロードを含むパラメータ、そしてHitが送信されたアドレスが同じであること。Hitは同一または異なるIPアドレスから到来してもよく、同一攻撃タイプの範囲で悪意のあるペイロードの値が異なる場合があります。新しいHitは最後のHitから1時間以内に到着したもののみ同一Attackにまとめられます。1時間を超える場合は別のAttackとして記録されます。

    このHitのグルーピング方法は基本で、すべてのHitに適用されます。

  • source IPによるHitのグルーピングが有効な場合は、送信元IPアドレスが同じであること。その他のHitのパラメータ値は異なっていて構いません。

    このグルーピング方法は、Brute force、Forced browsing、BOLA(IDOR)、Resource overlimit、Data bomb、Virtual patchの攻撃タイプを除くすべてのHitに適用されます。

    Hitがこの方法でグループ化されている場合、そのAttackに対してはMark as false positiveボタンを使用できません。

上記のHitのグルーピング方法は相互に排他的ではありません。両方の条件を満たすHitは、1つのAttackにまとめられます。

Hitとは、シリアライズされた不正リクエスト（元の不正リクエストと、Wallarmノードが付与するメタデータ）です。1つのリクエスト内に異なるタイプの複数の悪意のあるペイロードが検出された場合、Wallarmは、それぞれが1種類のペイロードのみを含む複数のHitとして記録します。

悪意のあるペイロードとは、元のリクエストのうち次の要素を含む部分です:

  • リクエストで検出された攻撃シグネチャ。同一の攻撃タイプを特徴付ける複数の攻撃シグネチャが1つのリクエストで検出された場合は、最初に検出されたシグネチャのみがペイロードに記録されます。

  • 攻撃シグネチャのコンテキスト。コンテキストとは、検出された攻撃シグネチャの前後にある文字の集合です。ペイロードの長さには制限があるため、攻撃シグネチャがペイロード全体の長さを占める場合はコンテキストが省略されることがあります。

    攻撃シグネチャは行動ベースの攻撃の検知には使用しないため、行動ベースの攻撃の一部として送信されたリクエストのペイロードは空になります。

Wallarmで攻撃を分析する方法→

保護対象リソースの種類

Wallarmノードは、保護対象リソースに送信されるHTTPおよびWebSocketトラフィックを分析します:

保護対象のAPIは以下の技術を基盤として設計できます（WAAPのサブスクリプションプランにより制限があります）:

  • GraphQL

  • gRPC

  • WebSocket

  • REST API

  • SOAP

  • XML-RPC

  • WebDAV

  • JSON-RPC

攻撃の処理プロセス

攻撃を検知・処理するために、Wallarmは次のプロセスを使用します:

  1. IP listsを確認し、そもそもリクエストを処理するかどうかを判断します。Denylistはリクエストをブロックし、allowlistは許可します。いずれも以降の解析は行いません。

  2. リクエスト形式を判定し、各リクエスト要素を解析して基本の検出器を適用します。

  3. リクエストの宛先エンドポイントを特定し、カスタムルール/Mitigation controlsおよび特定モジュールの設定を適用するとともに、フィルタリングモードを把握します。

  4. 基本の検出器、カスタムルール、特定モジュールの設定に基づいて、そのリクエストが攻撃の一部かどうかを判定します。

  5. 判定結果とフィルタリングモードに従ってリクエストを処理します。

攻撃処理プロセスの図

ルール、Mitigation controls、設定、およびフィルタリングモードは、親エンドポイントまたはアプリケーションから継承される場合があります。より具体的なものが優先されます。

攻撃検知のためのツール

攻撃を検知するために、Wallarmは攻撃の処理プロセスに従って保護対象に送信されるすべてのリクエストを次のツールで分析します:

基本の検出器

Wallarmは、基本の検出器セット（Wallarmが開発したlibprotonライブラリ）を用いて、攻撃タイプごとのシグネチャをトークン列として判定します。例: SQLインジェクション攻撃タイプに対するunion select。リクエストに検出器のトークン列と一致するトークン列が含まれている場合、そのリクエストは対応するタイプの攻撃と見なされます。

Wallarmは、新しい攻撃タイプおよび既存の攻撃タイプに対して、この検出器（トークン列）のリストを定期的に更新します。

また、WallarmはSQLインジェクション攻撃を追加検証します（Wallarmが開発したlibdetectionライブラリ）。管理方法をご覧ください。

カスタムルール

カスタムルールは、基本の検出器で定義される挙動をきめ細かく調整するために使用します。ユーザーはWallarm Consoleでルールを作成し、そのルールセットがフィルタリングノードにアップロードされます。

Mitigation controls

Mitigation controlsは、追加のセキュリティ対策によってWallarmの攻撃防御を拡張し、Wallarmの挙動をさらに微調整できるようにします。

特定モジュールの設定

基本の検出器やカスタムルールとの照合に加えて、リクエストは次のような各種保護ツールが提供する設定にも照らしてチェックされます:

これらのいずれのツールも、特定の攻撃や脆弱性の検知、ならびにリクエストのブロックを引き起こす場合があります。

特定の攻撃タイプを無視する

Ignore certain attack typesルールは、特定のリクエスト要素において特定の攻撃タイプの検知を無効化できます。

デフォルトでは、Wallarmノードは任意のリクエスト要素でいずれかの攻撃タイプのシグネチャを検出すると、そのリクエストを攻撃としてマークします。ただし、攻撃シグネチャを含む一部のリクエストが実際には正当な場合もあります（例: データベース管理者フォーラムへの投稿を公開するリクエストの本文に、悪意のあるSQLコマンドの説明が含まれる場合）。

リクエストの標準的なペイロードをWallarmノードが悪意のあるものとしてマークすると、誤検知が発生します。誤検知を防ぐには、保護対象APIの特性に合わせて、特定タイプのカスタムルールを用い標準の攻撃検知ルールを調整する必要があります。そのためにWallarmはIgnore certain attack typesルールを提供しています。

ルールの作成と適用

  1. Proceed to Wallarm Console:

    • Rules → Add rule or your branch → Add rule.
    • Attacks / Incidents → attack/incident → hit → Rule.
    • API Discovery (if enabled) → your endpoint → Create rule.

  2. Fine-tuning attack detection → Ignore certain attacksを選択します。

  3. If request isで、このルールを適用する対象範囲を記述します。

  4. 特定の攻撃のみのシグネチャを無視するのか（対象を選択）、すべての攻撃のシグネチャを無視するのかを設定します。

  5. In this part of requestで、このルールを設定したいリクエストのポイントを指定します。

    利用可能なポイントはこちらに記載されています。お使いのユースケースに合致するものを選択してください。

  6. ルールのコンパイルが完了するまで待ちます。

ルール例

たとえば、ユーザーがデータベース管理者フォーラムへの投稿の公開を確認すると、クライアントはエンドポイントhttps://example.com/posts/にPOSTリクエストを送信します。このリクエストには次の特性があります:

  • 投稿内容はリクエスト本文のパラメータpostBodyに渡されます。投稿内容には、Wallarmによって悪意ありとマークされ得るSQLコマンドが含まれる場合があります。

  • リクエスト本文のタイプはapplication/jsonです。

以下はSQLインジェクションを含むcURLリクエストの例です:

curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}'

したがって、https://example.com/posts/へのリクエストについて、パラメータpostBody内のSQLインジェクションを無視する必要があります。

そのためには、次のスクリーンショットのとおりIgnore certain attack typesルールを設定します:

「Ignore certain attack types」ルールの例

Note that options you add to In this part of request should go in a particular order to reflect in which order Wallarm will apply parsers to read the required request element.

バイナリデータ内の特定の攻撃シグネチャを無視する

デフォルトでは、Wallarmノードは既知のすべての攻撃シグネチャについて受信リクエストを分析します。この分析の過程で、攻撃シグネチャが通常のバイナリ記号ではないと判断され、バイナリデータ内に誤って悪意のあるペイロードが検出されてしまうことがあります。

Allow binary dataルールを使用すると、バイナリデータを含むリクエスト要素を明示的に指定できます。指定したリクエスト要素を分析する際、Wallarmノードはバイナリデータ内に絶対に含まれない攻撃シグネチャを無視します。

  • Allow binary dataルールは、バイナリデータ（例: 圧縮ファイルや暗号化ファイル）を含むリクエスト要素に対する攻撃検知の微調整を可能にします。

ルールの作成と適用

  1. Proceed to Wallarm Console:

    • Rules → Add rule or your branch → Add rule.
    • Attacks / Incidents → attack/incident → hit → Rule.
    • API Discovery (if enabled) → your endpoint → Create rule.

  2. Fine-tuning attack detection → Binary data processingを選択します。

  3. If request isで、このルールを適用する対象範囲を記述します。

  4. In this part of requestで、このルールを設定したいリクエストのポイントを指定します。

    利用可能なポイントはこちらに記載されています。お使いのユースケースに合致するものを選択してください。

  5. ルールのコンパイルが完了するまで待ちます。

ルール例

例えば、ユーザーがサイト上のフォームを使って画像を含むバイナリファイルをアップロードすると、クライアントはmultipart/form-dataタイプのPOSTリクエストをhttps://example.com/uploads/に送信します。バイナリファイルは本文パラメータfileContentsに渡されます。これを許可する必要があります。

そのためには、次のスクリーンショットのとおりAllow binary dataルールを設定します:

「Allow binary data」ルールの例

Note that options you add to In this part of request should go in a particular order to reflect in which order Wallarm will apply parsers to read the required request element.

攻撃の監視とブロック

入力検証型攻撃

Wallarmは、入力検証型攻撃を次のモードで処理できます:

  • Monitoring mode: 検知はしますがブロックしません。

  • Safe blocking mode: 攻撃を検知し、graylisted IPsからのもののみブロックします。graylisted IPsから送信された正当なリクエストはブロックされません。

  • Blocking mode: 検知し、ブロックします。

各フィルタリングモードの動作、および全体や特定のアプリケーション、ドメイン、エンドポイントに対するフィルタリングモードの設定方法の詳細はこちらをご覧ください。

行動ベースの攻撃

Wallarmが行動ベースの攻撃をどのように検知し、検知時にどのように振る舞うかは、フィルタリングモードではなく、これらの攻撃タイプの特定モジュールの設定によって定義されます。

誤検知

誤検知とは、正当なリクエストに攻撃シグネチャが検出された場合、または正当なエンティティが脆弱性と判定された場合に発生します。脆弱性スキャンにおける誤検知の詳細→

攻撃の有無を分析する際、Wallarmは誤検知率が極めて低くAPIを最適に保護する標準ルールセットを使用します。ただし、保護対象APIの特性によっては、標準ルールが正当なリクエストを誤って攻撃と認識する場合があります。例: データベース管理者フォーラムに、悪意のあるSQLクエリの説明を含む投稿を追加するリクエストで、SQLインジェクション攻撃が検知されることがあります。

このような場合は、以下の方法で標準ルールを保護対象APIの特性に合わせて調整します:

誤検知の特定と対処は、APIを保護するためのWallarmのチューニングの一部です。最初のWallarmノードはMonitoringmodeでデプロイし、検知された攻撃を分析することを推奨します。誤って攻撃と認識されているものがあれば、誤検知としてマークし、フィルタリングノードをBlocking modeに切り替えてください。

Wallarm UIのAttacks

Wallarmは、検知されたすべての攻撃とその詳細を表示する包括的なユーザーインターフェースを提供します。迅速な可視化のために攻撃ダッシュボードを利用したり、カスタム通知を設定したりできます。

詳しくは攻撃の分析の記事をご覧ください。

Attacksビュー