フィルタリングモード¶

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

利用可能なフィルタリングモード¶

Wallarmフィルタリングノードは、次のモードで受信リクエストを処理できます（弱い→強いの順）:

off
monitoring
safe_blocking - ブロックが安全と判断される場合のみブロックします（graylist）。
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_modeディレクティブの値の強さに関係なく、Wallarm Consoleで指定した設定の方が高い優先度を持ちます。

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

ノード側ではwallarm_modeディレクティブを使用してノードのフィルタリングモードを設定できます。デプロイメントごとの設定の特徴は以下のとおりです。

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

All-in-oneインストーラーDockerのNGINXベースイメージNGINX Ingress controllerSidecarEdge ConnectorsNative Node

LinuxにAll-in-oneインストーラーでインストールしたNGINXベースのノードでは、フィルタリングノードの設定ファイルでwallarm_modeディレクティブを設定できます。複数のコンテキストに対してフィルタリングモードを定義できます。これらのコンテキストは、よりグローバルなものからローカルなものへ、次の順序で適用されます:

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

同じ設定ファイル内でhttp、server、locationブロックに異なるwallarm_mode値を設定した場合は、最もローカルな設定が最優先されます。

下記の設定例をご覧ください。

NGINXベースのWallarmノードをDockerコンテナでデプロイする場合は、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:6.4.1

または、設定ファイルに該当パラメータを含め、このファイルをマウントしてコンテナを実行します。

NGINX Ingress controllerの場合は、wallarm-modeアノテーションを使用します:

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

フィルタリングモードをmonitoringに設定してNGINXベースのIngress controllerのトラフィック解析を有効化する例をご覧ください。

Wallarm Sidecarソリューションでは、デフォルトのvalues.yamlのWallarm固有セクションでmodeパラメータを設定します:

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

Sidecarのフィルタリングモード指定の詳細はこちらをご覧ください。

Security Edge connectorsでは、コネクタのデプロイ時にFiltration modeセレクタでwallarm_modeの値を指定します。

Native NodeのAll-in-oneインストーラーおよびDockerイメージでは、route_config.wallarm_modeパラメータを使用します。
Native NodeのHelmチャートでは、config.connector.route_config.wallarm_modeパラメータを使用します。

全体のフィルタリングモード¶

全ての受信リクエストに対する全体のフィルタリングモードは、Mitigation controls（Advanced API Securityサブスクリプション）またはRules（Cloud Native WAAPサブスクリプション）を使用して定義できます。

Mitigation controlsRules

全ての受信リクエストの全体フィルタリングモードは、“all traffic” Real-time blocking modemitigation controlで定義します:

設定	フィルタリングモード
Inherited	フィルタリングモードは、all-traffic Real-time blocking modeおよびWallarmノードの設定から継承されます。
Excluding	`off`
Monitoring	`monitoring`
Safe blocking	`safe_blocking`
Blocking	`block`

既定はInheritedです。グローバルモードはいつでも変更できます。

全ての受信リクエストに対する全体のフィルタリングモードは、USまたはEU CloudのSettings → Generalで定義できます。

全体のフィルタリングモード設定は、RulesセクションのSet filtration modedefaultルールとして表されます。このセクションでエンドポイントを対象とするフィルタリングルールの方が高い優先度を持つ点にご注意ください。

条件付きフィルタリングモード¶

特定のブランチやエンドポイント、その他の条件に基づくフィルタリングモードは、Mitigation controls（Advanced API Securityサブスクリプション）またはRules（Cloud Native WAAPサブスクリプション）で設定できます。

Mitigation controlsRules

特定のブランチやエンドポイント、その他の条件に基づいてフィルタリングモードを設定できます。WallarmはReal-time blocking modemitigation controlを提供します。

その前に:Mitigation Controlsの記事（こちら）で、任意のmitigation controlに対してScopeとMitigation modeをどのように設定するかをご確認ください。

新しいフィルタリングモードのmitigation controlを作成するには:

Wallarm Console → Mitigation Controlsに進みます。
Add control → Real-time blocking modeを使用します。
Scopeに適用する対象を記述します。

Mitigation modeセクションで、指定したスコープに対するフィルタリングモードを選択します:

設定	フィルタリングモード
Inherited	フィルタリングモードは、all-traffic Real-time blocking modeおよびWallarmノードの設定から継承されます。
Excluding	`off`
Monitoring	`monitoring`
Safe blocking	`safe_blocking`
Blocking	`block`

変更を保存し、mitigation controlのコンパイルが完了するまでお待ちください。

特定のブランチやエンドポイント、その他の条件に基づいてフィルタリングモードを設定できます。これにはSet filtration moderuleを使用します。これらのルールは、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で、ルールを適用するスコープを記述します。特定のブランチ、ヒット、またはエンドポイントからルール作成を始めた場合は、それらがスコープを定義します。必要に応じて条件を追加できます。

指定したスコープに対するフィルタリングモードを選択します:

設定	フィルタリングモード
Default	フィルタリングモードは、グローバルのフィルタリングモード設定およびWallarmノードの設定から継承されます。
Disabled	`off`
Monitoring	`monitoring`
Safe blocking	`safe_blocking`
Blocking	`block`

変更を保存し、ルールのコンパイルが完了するまでお待ちください。

なお、フィルタリングモードのルールは、Wallarm APIを直接呼び出すことでも作成できます。

方法の優先順位¶

wallarm_mode_allow_overrideディレクティブのEdgeノードでのサポート

wallarm_mode_allow_overrideディレクティブは、Wallarm Edgeのinlineおよびconnectorノードではカスタマイズできません。

wallarm_mode_allow_overrideディレクティブは、フィルタリングノードの設定ファイルにあるwallarm_modeディレクティブの値ではなく、Wallarm Consoleで定義したモードのルール/mitigation controlsを適用できるかどうかを管理します。

wallarm_mode_allow_overrideディレクティブには次の値を設定できます:

off: Wallarm Consoleで指定したモードのルール/mitigation controlsは無視されます。設定ファイル内のwallarm_modeディレクティブで指定したルールが適用されます。
strict: 設定ファイル内のwallarm_modeディレクティブで定義したモードよりも厳しいフィルタリングモードを定義する、Wallarm Cloudで指定したモードのルール/mitigation controlsのみが適用されます。

利用可能なフィルタリングモードの弱い→強いの順序は上記に示しています。
on（デフォルト）: Wallarm Consoleで指定したモードのルール/mitigation controlsが適用されます。設定ファイル内の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で定義したフィルタリングモードのルール/mitigation controlsは無視されます。SERVER_Aに対応するserverブロックにwallarm_modeディレクティブが指定されていないため、httpブロックで指定されたmonitoringフィルタリングモードが適用されます。
仮想サーバーSERVER_Bに送信されるリクエストには、パスに/main/loginを含むリクエストを除き、Wallarm Consoleで定義したフィルタリングモードのルール/mitigation controlsが適用されます。
仮想サーバー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での設定¶

全体のフィルタリングモード: Monitoring。
条件付きフィルタリングモードの設定:
- 次の条件に一致する場合:
  - Method: POST
  - First part of the path: main
  - Second part of the path: apply,
  Defaultフィルタリングモードを適用します。
- 次の条件に一致する場合:
  - First part of the path: main,
  Blockingフィルタリングモードを適用します。
- 次の条件に一致する場合:
  - First part of the path: main
  - Second part of the path: login,
  Monitoringフィルタリングモードを適用します。

リクエスト例¶

設定済みサーバーSERVER_Aに送信されるリクエスト例と、それに対してWallarmフィルタリングノードが適用するアクションは次のとおりです:

/newsパスを持つ悪意のあるリクエストは、サーバーSERVER_Aに対するwallarm_mode monitoring;設定により処理されますが、ブロックはされません。
/mainパスを持つ悪意のあるリクエストは、サーバーSERVER_Aに対するwallarm_mode monitoring;設定により処理されますが、ブロックはされません。

Wallarm Consoleで定義されたBlockingルールは、サーバーSERVER_Aのwallarm_mode_allow_override off;設定により適用されません。
/main/loginパスを持つ悪意のあるリクエストは、/main/loginパスに対するwallarm_mode block;設定によりブロックされます。

Wallarm Consoleで定義されたMonitoringルールは、フィルタリングノード設定ファイルのwallarm_mode_allow_override strict;設定により適用されません。
/main/signupパスを持つ悪意のあるリクエストは、/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パスを持つ悪意のあるリクエストは、フィルタリングノード設定ファイルで/main/feedbackパスに対してwallarm_mode safe_blocking;が設定されているため、graylisted IPからのリクエストの場合にのみブロックされます。

フィルタリングノード設定ファイルのwallarm_mode_allow_override off;設定により、Wallarm Consoleで定義されたMonitoringルールは適用されません。