ノード導入後のWallarmヘルスチェック¶
本書は、新しいフィルタリングノードを導入した後にWallarmが正しく動作していることを確認するためのチェックリストです。既存のノードの健全性確認にも本手順を使用できます。
ヘルスチェック結果
記載の期待結果と実際の結果に差異がある場合、ノードの機能に問題がある兆候である可能性があります。そのような不一致には特に注意を払い、必要に応じてWallarmサポートチームにお問い合わせください。
ノードがCloudに登録されている¶
確認方法:
-
Wallarm Console → Configuration → Nodesを開きます。
-
アクティブなノードのみが表示されるようにフィルターを適用します。
-
一覧から対象ノードを見つけ、クリックして詳細を表示します。
ノードが攻撃を記録している¶
確認方法:
-
Send the request with test Path Traversal attack to a protected resource address:
If traffic is configured to be proxied to
example.com
, include the-H "Host: example.com"
header in the request. -
Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.
-
Optionally, [test][link-wallarm-health-check] other aspects of the node functioning.
ノードがすべてのトラフィックを記録している¶
完全な可視性を確保するため、WallarmのAPI Sessionsは悪意のあるリクエストと正当なリクエストのすべてを段階的なユーザーセッションの形式で表示します。
確認方法:
-
ノードで保護されているリソースにリクエストを送信します:
またはbashスクリプトで複数のリクエストを送信します:
この例では10件のリクエストを送信します。
-
Events → API Sessionsを開きます。
-
送信したリクエストと先ほど送信した攻撃が同一のセッション内にまとまっていることを確認します。
ノードの統計サービスが動作している¶
/wallarm-status
URLにアクセスすると、フィルタリングノードの動作統計を取得できます。
統計サービス
統計サービスの詳細と設定方法はこちらをご覧ください。
確認方法:
-
ノードがインストールされているマシン上で次のコマンドを実行します:
-
出力を確認します。次のように表示されるはずです:
{ "requests": 11, "streams": 0, "messages": 0, "attacks": 1, "blocked": 0, "blocked_by_acl": 0, "blocked_by_antibot": 0, "acl_allow_list": 0, "abnormal": 11, "tnt_errors": 0, "api_errors": 0, "requests_lost": 0, "overlimits_time": 0, "segfaults": 0, "memfaults": 0, "softmemfaults": 0, "proton_errors": 0, "time_detect": 0, "db_id": 199, "lom_id": 1726, "custom_ruleset_id": 1726, "custom_ruleset_ver": 56, "db_apply_time": 1750365841, "lom_apply_time": 1750365842, "custom_ruleset_apply_time": 1750365842, "proton_instances": { "total": 2, "success": 2, "fallback": 0, "failed": 0 }, "stalled_workers_count": 0, "stalled_workers": [], "ts_files": [ { "id": 1726, "size": 11887, "mod_time": 1750365842, "fname": "/opt/wallarm/etc/wallarm/custom_ruleset" } ], "db_files": [ { "id": 199, "size": 355930, "mod_time": 1750365841, "fname": "/opt/wallarm/etc/wallarm/proton.db" } ], "startid": 2594491974706159096, "compatibility": 4, "config_revision": 0, "rate_limit": { "shm_zone_size": 67108864, "buckets_count": 2, "entries": 0, "delayed": 0, "exceeded": 0, "expired": 0, "removed": 0, "no_free_nodes": 0 }, "timestamp": 1750371146.209885, "split": { "clients": [ { "client_id": null, "requests": 11, "streams": 0, "messages": 0, "attacks": 1, "blocked": 0, "blocked_by_acl": 0, "blocked_by_antibot": 0, "overlimits_time": 0, "time_detect": 0, "applications": [ { "app_id": -1, "requests": 11, "streams": 0, "messages": 0, "attacks": 1, "blocked": 0, "blocked_by_acl": 0, "blocked_by_antibot": 0, "overlimits_time": 0, "time_detect": 0 } ] } ] } }
これは、フィルタリングノードの統計サービスが起動しており正常に動作していることを意味します。
ノードのログが収集されている¶
確認方法:
-
ノードがインストールされているマシンで
/opt/wallarm/var/log/wallarm
に移動します。 -
wcli-out.log
の内容を確認します。ブルートフォース検出、Cloudへの攻撃エクスポート、Cloudとのノード同期状況など、ほとんどのWallarmサービスのログが記録されています。
その他のログおよびログ設定の詳細はこちらをご覧ください。
ノードが脆弱性を記録している¶
Wallarmはお使いのアプリケーションAPIの脆弱性を検出します。
確認方法:
-
ご利用のリソースに次のリクエストを送信します:
curl <RECOURSE_URL> -H 'jwt: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJjbGllbmRfaWQiOiIxIn0.' -H 'HOST: <TEST_HOST_NAME>'
なお、そのホストに対してすでに脆弱なJWTの脆弱性が検出されている場合(ステータスが何であっても、クローズ済みでも同様です)、新たな脆弱性が登録されることを確認するには、異なる
TEST_HOST_NAME
を指定する必要があります。 -
Wallarm Console → Events → Vulnerabilitiesを開き、weak JWTの脆弱性が一覧に表示されたかを確認します。
IPリストが機能している¶
Wallarmでは、リクエスト送信元のIPアドレスをAllowlist、Denylist、Graylistに分類することでアプリケーションAPIへのアクセスを制御できます。IPリストの基本ロジックはこちらをご覧ください。
確認方法:
-
Wallarm Console → Events → Attacksを開き、ノードが攻撃を記録しているの確認で作成した攻撃を見つけます。
-
攻撃の送信元IPをコピーします。
-
Security Controls → IP Lists → Allowlistに移動し、コピーした送信元IPをこのリストに追加します。
-
新しいIPリストの状態がフィルタリングノードに反映されるまで待ちます(約2分)。
-
同じIPから同じ攻撃を再送します。Attacksには何も表示されないはずです。
-
AllowlistからそのIPを削除します。
-
そのIPをDenylistに追加します。
-
ノードがすべてのトラフィックを記録しているの手順と同様に正当なリクエストを送信します。これらのリクエストは正当であってもAttacksにブロックとして表示されるはずです。
ルールが機能している¶
Wallarmでは、ルールを使用して、システムが悪意のあるリクエストを検出する方法や検出時の動作を変更できます。ルールはWallarm ConsoleからCloud上で作成し、カスタムルールセットとして構成され、Cloudからフィルタリングノードに配信されて適用されます。
確認方法:
-
次のいずれかの方法で現在のカスタムルールセットのIDと日時を確認します:
-
Security Controls → Rulesに移動します。
-
Add rule → Fine-tuning attack detection → Ignore certain attacksを使用し、リクエストの
uri
部分でPath traversalを無視するように選択してルールを作成します。 -
手順1で確認した値が更新されたことを確認します(2~4分かかる場合があります)。
-
ノードが攻撃を記録しているの確認で実行した攻撃を再実行します。今回はこの攻撃は無視され、Attacksに表示されないはずです。
-
そのルールを削除します。