フィルタリングモード¶
フィルタリングモードは、受信リクエストを処理する際のフィルタリングノードの動作を定義します。本ドキュメントでは、利用可能なフィルタリングモードとその設定方法を説明します。
利用可能なフィルタリングモード¶
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 IPssee 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_allow_override
ディレクティブで決まります。デフォルトでは、wallarm_mode
ディレクティブの値の強さに関係なく、Wallarm Consoleで指定した設定の方が高い優先度を持ちます。
wallarm_mode
ディレクティブの設定¶
ノード側ではwallarm_mode
ディレクティブを使用してノードのフィルタリングモードを設定できます。デプロイメントごとの設定の特徴は以下のとおりです。
なお、ここで説明する設定はin-lineデプロイにのみ適用されます。out-of-band (OOB)ソリューションではmonitoring
モードのみ有効にできます。
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
パラメータを設定します:
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サブスクリプション)を使用して定義できます。
全ての受信リクエストの全体フィルタリングモードは、“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です。グローバルモードはいつでも変更できます。
条件付きフィルタリングモード¶
特定のブランチやエンドポイント、その他の条件に基づくフィルタリングモードは、Mitigation controls(Advanced API Securityサブスクリプション)またはRules(Cloud Native WAAPサブスクリプション)で設定できます。
特定のブランチやエンドポイント、その他の条件に基づいてフィルタリングモードを設定できます。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フィルタリングモードを適用します。
- Method:
-
次の条件に一致する場合:
- First part of the path:
main
,
Blockingフィルタリングモードを適用します。
- First part of the path:
-
次の条件に一致する場合:
- First part of the path:
main
- Second part of the path:
login
,
Monitoringフィルタリングモードを適用します。
- First part of the path:
-
リクエスト例¶
設定済みサーバー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ルールは適用されません。
フィルタリングモードを段階的に適用するベストプラクティス¶
新しいWallarmノードをスムーズに導入するため、次のステップに従ってフィルタリングモードを切り替えることをおすすめします:
-
本番以外の環境に、動作モードを
monitoring
に設定したWallarmフィルタリングノードをデプロイします。 -
本番環境に、動作モードを
monitoring
に設定したWallarmフィルタリングノードをデプロイします。 -
全ての環境(テストと本番を含む)で7‑14日間、フィルタリングノード経由でトラフィックを流し、Wallarmのクラウドベースバックエンドがアプリケーションを学習する時間を確保します。
-
すべての本番以外の環境でWallarmの
block
モードを有効化し、自動テストまたは手動テストで保護対象アプリケーションが期待どおり動作することを確認します。 -
本番環境でWallarmの
block
モードを有効化し、利用可能な手段でアプリケーションが期待どおり動作することを確認します。