フィルトレーションモード¶

フィルトレーションモードは、受信リクエストを処理する際のフィルタリングノードの動作を定義します。本ドキュメントでは、利用可能なフィルトレーションモードおよびその設定方法について説明します。

利用可能なフィルトレーションモード¶

Wallarmフィルタリングノードは、受信リクエストを以下のモード（穏やかなものから厳格なものへ順に）で処理できます：

無効 (off)
モニタリング (monitoring)
セーフブロッキング (safe_blocking)
ブロッキング (block)

Wallarm node behavior	`off`	`monitoring`	`safe_blocking`	`block`
Analyzes incoming requests for input validation, virtual patch, and regex-based malicious payloads	-	+	+	+
Uploads malicious requests to the Wallarm Cloud so that they are displayed in the event list	-	+	+	+
Blocks malicious requests	-	-	Only those originated from graylisted IPs	+
Blocks requests originated from denylisted IPs^{see exception} (IPs added manually and automatically by multi-attack protection and behavioral protection: API abuse prevention, manual BOLA, brute force and forced browsing)	-	+	+	+
Blocks requests originated from graylisted IPs (IPs added manually and automatically by the same protection measures as for denylist)	-	-	Only those containing malicious payloads	-
Allows requests originated from allowlisted IPs	-	+	+	+

Exception for denylist

If wallarm_acl_access_phase off, the Wallarm node does not block requests from denylisted IPs in the monitoring mode.

設定方法¶

フィルトレーションモードは、以下の方法で設定できます。

ノード側でwallarm_modeディレクティブを設定する
Wallarm Consoleにおける一般的なフィルトレーションルールを定義する
Wallarm Consoleにおけるエンドポイント対象のフィルトレーションルールを定義する

フィルトレーションモード設定方法の優先順位は、wallarm_mode_allow_overrideディレクティブによって決定されます。デフォルトでは、Wallarm Consoleで指定された設定は、その値の厳格度に関係なく、wallarm_modeディレクティブによる設定よりも優先されます。

`wallarm_mode`ディレクティブの設定¶

ノード側でwallarm_modeディレクティブを使用してフィルトレーションモードを設定できます。異なるデプロイメントにおけるwallarm_modeディレクティブの設定上の特徴を以下に説明します。

なお、本設定はin-lineデプロイメントにのみ適用されます。out-of-band (OOB)ソリューションではmonitoringモードのみが有効です。

All-in-oneインストーラーDocker NGINXベースイメージDocker EnvoyベースイメージNGINX IngressコントローラーサイドカーEdgeコネクターNative Node

Linux上にall-in-one installerを使用してインストールされたNGINXベースのノードでは、フィルタリングノードの設定ファイルにwallarm_modeディレクティブを設定できます。異なるコンテキストに対してフィルトレーションモードを定義できます。これらのコンテキストは、以下のリストのように、最もグローバルなものから最もローカルなものへと順に並びます：

http: HTTPサーバーに送信されるリクエストにディレクティブが適用されます。
server: 仮想サーバーに送信されるリクエストにディレクティブが適用されます。
location: 該当のパスを含むリクエストにのみディレクティブが適用されます。

もしhttp、server、locationブロックで異なるwallarm_modeディレクティブの値が定義されている場合、最もローカルな設定が最も高い優先順位を持ちます。

以下の設定例を参照してください。

Dockerコンテナを使用してNGINXベースのWallarmノードをデプロイする場合、WALLARM_MODE環境変数を渡してください：

docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_MODE='monitoring' -p 80:80 wallarm/node:5.3.0

Dockerコンテナを使用してEnvoyベースのWallarmノードをデプロイする場合、WALLARM_MODE環境変数を渡してください：

docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e ENVOY_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_MODE='monitoring' -p 80:80 wallarm/envoy:4.8.0-1

または、設定ファイルに対応するパラメータを含めて、当該ファイルをマウントしてコンテナを実行してください。

NGINX Ingressコントローラーの場合、wallarm-modeアノテーションを使用してください：

kubectl annotate ingress <YOUR_INGRESS_NAME> -n <YOUR_INGRESS_NAMESPACE> nginx.ingress.kubernetes.io/wallarm-mode=monitoring

フィルトレーションモードをmonitoringに設定して、NGINXベースのIngressコントローラーでのトラフィック分析がどのように有効になるかの例を参照してください。

Wallarm Sidecarソリューションの場合、デフォルトのvalues.yamlのWallarm固有部分でmodeパラメータを設定してください：

config:
wallarm:
    ...
    mode: monitoring
    modeAllowOverride: "on"

サイドカー用のフィルトレーションモードの指定方法については、こちらを参照してください。

Security Edge connectorsの場合、コネクターのデプロイ時にFiltration modeセレクターでwallarm_modeの値を指定してください。

Native Node all-in-one installerおよびDockerイメージの場合、route_config.wallarm_modeパラメータを使用してください。
Native Node Helmチャートの場合、config.connector.modeパラメータを使用してください。

Wallarm Consoleにおける一般的なフィルトレーションルール¶

USまたはEU CloudのSettings→Generalで、すべての受信リクエストに対する一般的なフィルトレーションモードを定義できます。

一般的なフィルトレーションモードの設定は、RulesセクションにおけるSet filtration modedefaultルールとして表されます。なお、このセクションのエンドポイント対象のフィルトレーションルールは、より高い優先順位を持ちます。

Wallarm Consoleにおけるエンドポイント対象のフィルトレーションルール¶

特定のブランチ、エンドポイント、およびその他の条件に基づいてフィルトレーションモードを設定できます。Wallarmはこの目的のためにSet filtration modeルールを提供しています。これらのルールは、Wallarm Consoleで設定された一般的なフィルトレーションルールよりも高い優先順位を持ちます。

新たなフィルトレーションモードルールを作成するには：

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.
Fine-tuning attack detection→Override filtration modeを選択します。
If request isにおいて、ルールを適用する対象範囲を記述します。特定のブランチ、ヒット、エンドポイントに対してルールを作成した場合、それらが対象範囲を定義します。必要に応じて、条件を追加できます。
目的のモードを選択します。
変更を保存し、ルールのコンパイル完了を待ちます。

フィルトレーションモードルールを作成するには、Wallarm APIを直接呼び出すこともできますのでご注意ください。

設定方法の優先順位¶

Edgeノードにおけるwallarm_mode_allow_overrideディレクティブのサポート

Wallarm Edgeのinlineおよびconnectorノードでは、wallarm_mode_allow_overrideディレクティブをカスタマイズできない点にご留意ください。

wallarm_mode_allow_overrideディレクティブは、フィルタリングノードの設定ファイルに記載されたwallarm_modeディレクティブの値ではなく、Wallarm Consoleで定義されたルールを適用する機能を管理します。

wallarm_mode_allow_overrideディレクティブには、以下の値が有効です：

off: Wallarm Consoleで指定されたルールは無視され、設定ファイルに記載されたwallarm_modeディレクティブによるルールが適用されます。
strict: 設定ファイルに記載されたwallarm_modeディレクティブの値よりも厳しいフィルトレーションモードを定義するWallarm Cloudで指定されたルールのみが適用されます。

利用可能なフィルトレーションモードは、最も穏やかなものから最も厳格なものまで、上記に記載されています。
on (デフォルト): Wallarm Consoleで指定されたルールが適用され、設定ファイルに記載されたwallarm_modeディレクティブの値は無視されます。

wallarm_mode_allow_overrideディレクティブの値を定義できるコンテキストは、最もグローバルなものから最もローカルなものまで、以下のリストに示されています：

http: httpブロック内のディレクティブは、HTTPサーバーに送信されるリクエストに適用されます。
server: serverブロック内のディレクティブは、仮想サーバーに送信されるリクエストに適用されます。
location: locationブロック内のディレクティブは、該当のパスを含むリクエストにのみ適用されます。

もしhttp、server、locationブロックで異なるwallarm_mode_allow_overrideディレクティブの値が定義されている場合、最もローカルな設定が最も高い優先順位を持ちます。

wallarm_mode_allow_overrideディレクティブの使用例：

http {

    wallarm_mode monitoring;

    server {
        server_name SERVER_A;
        wallarm_mode_allow_override off;
    }

    server {
        server_name SERVER_B;
        wallarm_mode_allow_override on;

        location /main/login {
            wallarm_mode_allow_override strict;
        }
    }
}

この設定例では、Wallarm Consoleからのフィルトレーションモードルールの適用が以下のようになります：

仮想サーバーSERVER_Aに送信されるリクエストについては、Wallarm Consoleで定義されたフィルトレーションモードルールは無視されます。SERVER_Aに対応するserverブロックにwallarm_modeディレクティブが指定されていないため、httpブロックで指定されたmonitoringフィルトレーションモードが適用されます。
仮想サーバーSERVER_Bに送信されるリクエストについては、/main/loginパスを含むリクエストを除き、Wallarm Consoleで定義されたフィルトレーションモードルールが適用されます。
仮想サーバーSERVER_Bに送信され、/main/loginパスを含むリクエストについては、設定ファイルで指定されたmonitoringモードよりも厳しいフィルトレーションモードを定義する場合に限り、Wallarm Consoleで定義されたフィルトレーションモードルールが適用されます。

設定例¶

ここでは、これまでに述べたすべての方法を使用したフィルトレーションモード設定の例を考えます。

ノード設定ファイル¶

http {

    wallarm_mode block;

    server { 
        server_name SERVER_A;
        wallarm_mode monitoring;
        wallarm_mode_allow_override off;

        location /main/login {
            wallarm_mode block;
            wallarm_mode_allow_override strict;
        }

        location /main/signup {
            wallarm_mode_allow_override strict;
        }

        location /main/apply {
            wallarm_mode block;
            wallarm_mode_allow_override on;
        }

        location /main/feedback {
            wallarm_mode safe_blocking;
            wallarm_mode_allow_override off;
        }
    }
}

Wallarm Consoleのルール¶

Wallarm Consoleにおける一般的なフィルトレーションルール：モニタリング。
エンドポイント対象のフィルトレーションルール:
- リクエストが以下の条件を満たす場合：
  - メソッド：POST
  - パスの第1部分：main
  - パスの第2部分：apply、
  その場合、Defaultフィルトレーションモードを適用します。
- リクエストが以下の条件を満たす場合：
  - パスの第1部分：main、
  その場合、Blockingフィルトレーションモードを適用します。
- リクエストが以下の条件を満たす場合：
  - パスの第1部分：main
  - パスの第2部分：login、
  その場合、Monitoringフィルトレーションモードを適用します。

リクエスト例¶

設定されたサーバーSERVER_Aに送信されたリクエストと、それに対してWallarmフィルタリングノードが適用する動作の例は以下の通りです：

SERVER_Aサーバーに対するwallarm_mode monitoring;設定により、/newsパスの悪意のあるリクエストは処理されますがブロックされません。
SERVER_Aサーバーに対するwallarm_mode monitoring;設定により、/mainパスの悪意のあるリクエストは処理されますがブロックされません。サーバーSERVER_Aのwallarm_mode_allow_override off;設定のため、Wallarm Consoleで定義されたBlockingルールは適用されません。
/main/loginパスのリクエストに対するwallarm_mode block;設定により、/main/loginパスの悪意のあるリクエストはブロックされます。フィルタリングノード設定ファイルのwallarm_mode_allow_override strict;設定により、Wallarm Consoleで定義されたMonitoringルールは適用されません。
/main/signupパスのリクエストは、wallarm_mode_allow_override strict;設定および/mainパスに対してWallarm Consoleで定義されたBlockingルールによりブロックされます。
/main/applyパスかつGETメソッドの悪意のあるリクエストは、/main/applyパスのリクエストに対するwallarm_mode_allow_override on;設定および/mainパスに対してWallarm Consoleで定義されたBlockingルールによりブロックされます。
/main/applyパスかつPOSTメソッドの悪意のあるリクエストは、/main/applyパスのリクエストに対するwallarm_mode_allow_override on;設定、Wallarm Consoleで定義されたDefaultルール、およびフィルタリングノード設定ファイル内の/main/applyパスに対するwallarm_mode block;設定によりブロックされます。
/main/feedbackパスの悪意のあるリクエストは、フィルタリングノード設定ファイルにおけるwallarm_mode safe_blocking;設定により、graylisted IPからのものである場合にのみブロックされます。フィルタリングノード設定ファイルのwallarm_mode_allow_override off;設定により、Wallarm Consoleで定義されたMonitoringルールは適用されません。