EOLノードをアップグレードする場合のWallarmノードの新機能¶

このページでは、旧バージョン（3.6以下）のノードを5.0にアップグレードした際に利用可能になる変更点を一覧で紹介します。記載の変更は、通常（クライアント）ノードとマルチテナントノードの両方に適用されます。

Wallarmノード3.6およびそれ以前は非推奨です

Wallarmノード3.6およびそれ以前は非推奨のため、アップグレードを推奨します。

バージョン5.xのWallarmノードでは、ノード構成とトラフィックのフィルタリングが大幅に簡素化されています。5.xの一部の設定は旧バージョンのノードと互換性がありません。モジュールのアップグレード前に、変更点のリストと一般的な推奨事項を必ず確認してください。

All-in-oneインストーラーとDEB/RPMパッケージの非推奨化¶

さまざまな環境でNGINXの動的モジュールとしてWallarmノードをインストール・アップグレードする際は、導入プロセスの効率化と標準化のために設計されたAll-in-oneインストーラーを使用します。このインストーラーは、OSとNGINXのバージョンを自動検出し、必要な依存関係をすべてインストールします。

インストーラーは以下を自動で実行し、作業を簡素化します:

OSとNGINXのバージョン確認
検出したOSとNGINXのバージョンに対応するWallarmリポジトリの追加
それらのリポジトリからのWallarmパッケージのインストール
インストールされたWallarmモジュールのNGINXへの接続
提供されたトークンを用いたWallarm Cloudへのフィルタリングノードの接続

All-in-oneインストーラーでのノードアップグレードの詳細 →

ノードインストール用のDEB/RPMパッケージは現在「非推奨」です。

collectdの廃止¶

これまで全フィルタリングノードにインストールされていたcollectdサービスおよび関連プラグインは削除されました。メトリクスはWallarmの組み込みメカニズムで収集・送信され、外部ツールへの依存が低減されます。

PrometheusおよびJSON形式で同等のメトリクスを提供する、collectdの代替である/wallarm-statusエンドポイントを使用してください。

この変更の結果、設定ルールにも以下の変更があります:

/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.confのcollectd設定ファイルは使用されなくなりました。
以前にcollectdのネットワークプラグインでメトリクスを転送していた場合、例えば:
```
LoadPlugin network

<Plugin "network">
    Server "<Server IPv4/v6 address or FQDN>" "<Server port>"
</Plugin>
```
これからはPrometheusで/wallarm-statusをスクレイプする方式に切り替えてください。

API Sessions¶

API経済に特化したユニークなセキュリティ機能 — API Sessionsを導入しました。これにより、API全体での攻撃、異常、ユーザー行動の可視性が得られ、ユーザーがAPIやアプリケーションとどのようにやり取りしているかの透明性が向上します。

攻撃者は、正規ユーザーの行動に紛れて脆弱なエンドポイントを悪用することがよくあります。セッション全体のコンテキストがなければ、パターンや脅威の特定は、複数のツールやシステムをまたいだ時間のかかる作業になります。多くの組織はAPIレベルでの適切な可視性を持っていません。

API Sessionsにより、セキュリティチームはユーザーセッションごとに関連アクティビティをまとめて確認でき、攻撃シーケンス、ユーザーの異常、通常の行動をこれまでにない可視性で把握できます。これまで数時間から数日かかっていた調査は、Wallarm Consoleから数分で実行できるようになります。

主な特長:

攻撃、異常、ユーザー行動の可視化: セッション内のすべてのリクエストを表示・分析し、攻撃ベクターや不審なパターンを追跡します。
レガシーおよびモダンなセッションの両方をサポート: アプリケーションがCookieベースのセッションやJWT/OAuthに依存していても、Wallarm API Sessionsは完全な互換性と可視性を確保します。
個々の攻撃とそれに紐づくセッション間をシームレスに行き来できます。

API Sessionsにより、セキュリティチームは次のことを容易に行えます:

脅威行為者の全活動を調査し、潜在的な攻撃経路や侵害されたリソースを把握します。
シャドーAPIやゾンビAPIへのアクセス方法を特定し、未文書や古いAPIによるリスクを軽減します。
セキュリティ調査時に同僚と主要な洞察を共有し、コラボレーションを促進します。

詳細を読む

API Sessionsのレスポンスパラメータ¶

NGINX Node 5.3.0以上およびNative Node 0.12.0以上

WallarmのAPI Sessionsは、ユーザーの一連のアクティビティを可視化します。今回の拡張により、各セッションでリクエストだけでなくレスポンス情報も利用可能になりました:

任意のレスポンスヘッダーやパラメータを、対応するリクエスト内に表示するよう設定でき、ユーザーアクティビティの明確で完全な全体像を得られます。
レスポンスパラメータをセッションのグルーピングキーとして使用できます（例参照）。これにより、リクエストのセッショングルーピング精度が向上します。

レート制限¶

適切なレート制限がないことはAPIセキュリティにおける重大な課題でした。攻撃者は大量リクエストを発生させてサービス拒否（DoS）やシステム過負荷を引き起こし、正規ユーザーに悪影響を与えます。

Wallarmのレート制限機能により、セキュリティチームはサービス負荷を効果的に管理し、誤検知を防ぎ、正規ユーザーに対してサービスの可用性と安全性を確保できます。この機能では、従来のIPベースのレート制限に加え、JSONフィールド、base64エンコードデータ、Cookie、XMLフィールドなど、リクエストやセッションのパラメータに基づく多様な接続制限を提供します。

例えば、ユーザーごとのAPI接続数を制限し、1ユーザーが1分間に何千ものリクエストを行うことを防げます。これはサーバーへの大きな負荷となり、サービス障害につながり得ます。レート制限を実装することで、サーバーの過負荷を防ぎ、全ユーザーに公平なAPIアクセスを保証します。

レート制限はWallarm Console UI → Rules → Advanced rate limitingで、スコープ、レート、バースト、遅延、レスポンスコードをユースケースに合わせて指定するだけで簡単に設定できます。

レート制限の設定ガイド →

推奨はレート制限ルールの使用ですが、新しいNGINXディレクティブでも設定できます:

Credential stuffing detection ¶

Wallarmはクレデンシャルスタッフィング試行のリアルタイム検出と通知を提供します。クレデンシャルスタッフィングとは、盗まれた/弱いユーザー名・メールアドレスとパスワードの組み合わせをWebサイトのログインフォームに自動投入し、不正にアカウントへアクセスする手口です。本機能により、漏えいした認証情報を持つアカウントを特定し、アカウント所有者への通知や一時的なアクセス停止などの対処が可能です。

Credential Stuffing Detectionの設定方法

クレデンシャルスタッフィング検出をサポートする選択済みアーティファクト

All-in-oneインストーラー、NGINX Ingress Controller、NGINXベースのDockerイメージ、クラウドイメージ（AMI、GCP Image）など、限定的なアーティファクトで新しいクレデンシャルスタッフィング検出機能がサポートされます。

GraphQL API protection ¶

WallarmはデフォルトでGraphQL内の一般的な攻撃（SQLi、RCE、など）を検出します。しかし、プロトコルの特性により、過度な情報露出やDoSに関連するGraphQL特有の攻撃が可能です。

これらの攻撃への保護を導入しました。保護は、組織のGraphQLポリシー（GraphQLリクエストに対する制限のセット）を設定することで行います。設定された制限を超えるリクエストは、アクティブなフィルタリングモードに従ってフィルタリングノードが処理し、ポリシー違反として記録のみ、または記録してブロックします。

本機能の利用を開始するには、Wallarm Consoleで少なくとも1つのDetect GraphQL attacksルールを作成する必要があります。

GraphQL API Protectionの設定方法

Mitigation Controls¶

すべてのWallarm攻撃緩和設定を一元管理する管理センター — Mitigation Controlsを導入しました。Mitigation Controlsにより、次のことが可能です:

すべてのWallarm緩和設定を1か所で表示・管理できます。
統一的に管理できます（すべてのコントロールは類似の設定UIとオプションを備えます）。
各コントロールの現在のモードを容易に把握できます: 有効か、監視のみか、ブロックもするか。
各コントロールで捕捉された攻撃をすばやく俯瞰できます。

ファイルアップロード制限ポリシー¶

Wallarmはアップロードファイルサイズを直接制限するためのツールを提供します。これは、OWASP API Top 10 2023に含まれる最も重大なAPIセキュリティリスクの1つであるunrestricted resource consumptionを防ぐための一連の対策の一部です。

サブスクリプションプランにより、アップロード制限はミティゲーションコントロールまたはルールで適用されます。リクエスト全体または選択したポイントに対してファイルサイズの制限を設定できます。

列挙攻撃保護¶

NGINX Node 6.1.0以上およびNative Node 0.14.1以上

列挙攻撃に対する新たな保護レベルとして、以下の列挙ミティゲーションコントロールを提供します:

従来のトリガーと比較して、ミティゲーションコントロールは次を可能にします:

列挙試行の監視対象パラメータを選択できます。
カウント対象とするリクエストを高度に絞り込めます。
API Sessionsと深く統合されます: 検出された攻撃は対応するセッション内に表示され、何が起きてなぜそのセッションの活動が攻撃としてマークされ、ブロックされたのか、完全なコンテキストを提供します。

DoS保護¶

NGINX Node 6.1.0以上およびNative Node 0.14.1以上

unrestricted resource consumptionは、OWASP API Top 10 2023に含まれる重大なAPIセキュリティリスクです。これは（過負荷によるサービスの遅延・停止という）脅威自体であるだけでなく、列挙攻撃などさまざまな攻撃の土台にもなります。同時刻に許容しすぎるリクエストは、これらのリスクの主因の1つです。

Wallarmは、APIへの過剰なトラフィックを防ぐための新しいミティゲーションコントロールDoS protectionを提供します。

既定のコントロール¶

有効化するとWallarmプラットフォームの検出能力を大幅に強化する既定のミティゲーションコントロールを提供します。これらは一般的な攻撃パターンに対し堅牢な保護を提供するよう事前設定されています。現在の既定コントロールは以下のとおりです:

GraphQL protection
ユーザーID、オブジェクトID、ファイル名に対するBOLA（Broken Object Level Authorization）列挙保護
パスワード、OTP、認証コードに対するBrute force protection
Forced browsing protection（404プロービング）
Enumeration attack protection（以下を含む）:
- ユーザー/メールアドレス列挙
- SSRF（Server-Side Request Forgery）列挙
- ユーザーエージェントのローテーション

unrestricted resource consumptionからの保護¶

NGINX Node 6.3.0以上、Native Nodeは現時点では非対応です。

WallarmのAPI Abuse Preventionは、unrestricted resource consumption（自動化クライアントが適切な制限なく過剰にAPIやアプリケーションのリソースを消費する濫用行為）を防止する機能を提供します。これには、非悪意の大量リクエスト送信、計算資源・メモリ・帯域の枯渇、正規ユーザー向けサービス品質の低下などが含まれます。

この種の自動化された脅威を検出するため、API Abuse Preventionは次の3つの新しい検出器を提供します:

Response time anomaly: APIレスポンス遅延の異常パターンを特定し、自動化された濫用やバックエンドの悪用の兆候を検知します。
Excessive request consumption: 異常に大きいリクエストペイロードを送信するクライアントを特定し、バックエンド処理資源の濫用・誤用を示唆します。
Excessive response consumption: セッション全体でのレスポンスデータ総量に基づき、疑わしいセッションをフラグします。個々のリクエストに着目する検出器とは異なり、セッション全体でレスポンスサイズを集計して、スロードリップ型や分散型スクレイピング攻撃を特定します。

API Specification Enforcement¶

このアップデートでは、API Specification Enforcement機能を導入しました。これは受信トラフィックをフィルタリングし、API仕様に準拠したリクエストのみを許可します。クライアントとアプリケーションの間に配置されたWallarmノードが、仕様のエンドポイント記述と実際のAPIリクエストを比較します。未定義のエンドポイントや未許可パラメータを含むリクエストなどの不一致は、設定に応じてブロックまたは監視されます。

これは潜在的な攻撃試行を阻止してセキュリティを強化するだけでなく、過負荷や不適切な利用を回避することでAPIのパフォーマンスを最適化します。

また、一部のデプロイメントオプション向けに技術的な制御を可能にする新しいパラメータも追加しました:

All-in-oneインストーラー向け: wallarm_enable_apifw NGINXディレクティブ
NGINX Ingress Controller向け: controller.wallarm.apifirewallの値グループ
NGINXベースのDockerイメージ向け: 環境変数WALLARM_APIFW_ENABLE

API Specification Enforcementの設定方法

新しい攻撃タイプの検出¶

Wallarmは新しい攻撃タイプを検出します:

Broken Object Level Authorization（BOLA、Insecure Direct Object ReferencesまたはIDORとも呼ばれます）は、最も一般的なAPIの脆弱性の1つになりました。アプリケーションにIDOR / BOLAの脆弱性がある場合、攻撃者に機密情報やデータを露出する可能性が高くなります。攻撃者は、自身のリソースIDをAPI呼び出し内で他ユーザーのリソースIDに置き換えるだけで済みます。適切な認可確認がないと、攻撃者はそのリソースにアクセスできます。したがって、オブジェクトIDを受け取り何らかの操作を行うすべてのAPIエンドポイントは攻撃対象になり得ます。

この脆弱性の悪用を防ぐため、WallarmノードにはエンドポイントをBOLA攻撃から保護できる新しいトリガーが追加されています。トリガーは特定エンドポイントへのリクエスト数を監視し、しきい値を超えた際にBOLA攻撃イベントを作成します。
Mass Assignment

Mass Assignment攻撃では、攻撃者はHTTPリクエストパラメータをプログラムコードの変数やオブジェクトにバインドしようとします。APIが脆弱でバインドを許容している場合、公開を意図しないオブジェクトの機密プロパティを変更され、特権昇格やセキュリティ機構の回避などにつながる可能性があります。
SSRF

SSRF攻撃が成功すると、攻撃対象のWebサーバーになりすましてリクエストを発行でき、使用中のネットワークポートの露呈、内部ネットワークのスキャン、認可の回避につながる可能性があります。

API DiscoveryとAPI Sessionsのセンシティブなビジネスフロー¶

NGINX Node 5.3.0以上およびNative Node 0.10.1以上

センシティブなビジネスフロー機能により、WallarmのAPI Discoveryは、認証、アカウント管理、課金など特定のビジネスフローや機能にとって重要なエンドポイントを自動的に特定できます。

これにより、センシティブなビジネスフローに関連するエンドポイントの、脆弱性や侵害に対する定期監視・監査、および開発・保守・セキュリティ対応の優先順位付けが可能になります。

特定されたセンシティブなビジネスフローはWallarmのAPI Sessionsにも反映されます。API Discoveryでセンシティブなビジネスフローに重要とタグ付けされたエンドポイントに影響するセッションのリクエストがある場合、そのセッションにも自動的にそのビジネスフロータグが付与されます。

セッションにセンシティブなビジネスフロータグが付与されると、特定のビジネスフローでフィルタリングできるようになり、分析対象として最も重要なセッションを絞り込みやすくなります。

フル機能のGraphQLパーサー¶

NGINX Node 5.3.0以上およびNative Node 0.12.0以上

フル機能のGraphQLパーサーは、GraphQLリクエスト内の入力検証攻撃（例: SQLインジェクション）の検出を大幅に向上させ、精度向上と誤検知の最小化を実現します。

主な利点:

入力検証攻撃（例: SQLインジェクション）の検出精度向上
詳細なパラメータの可視化: GraphQLリクエストパラメータの値を抽出してAPI Sessionsに表示し、セッションのコンテキストパラメータとして活用できます。
精緻な攻撃検索: 引数、ディレクティブ、変数など、特定のGraphQLリクエスト要素における攻撃を正確に特定します。
高度なルール適用: GraphQLリクエストの特定部分に粒度の細かい保護ルールを適用できます。これにより、GraphQLリクエストの定義済み部分における特定攻撃タイプの除外など、きめ細かい調整が可能です。

JSON Web Tokenの強度チェック¶

JSON Web Token（JWT）は、APIなどのリソース間でデータを安全に交換するための一般的な認証標準です。JWTの侵害は、認証機構を破られることでアプリケーションやAPIに完全アクセスされるため、攻撃者の主要な標的となります。JWTが弱いほど、侵害される可能性は高まります。

現在、Wallarmは次のJWTの弱点を検出します:

暗号化されていないJWT
秘密鍵が漏えいした状態で署名されたJWT

JSON Web Tokenに対する攻撃の検査¶

JSON Web Token（JWT）は最も一般的な認証方式の1つです。そのため、JWTは攻撃（例えばSQLiやRCE）の格好の手段にもなります。JWT内のデータはエンコードされ、リクエスト内のどこにでも存在し得るため、発見が非常に困難です。

Wallarmノードはリクエスト内のどこにあるJWTでも検出してデコードし、適切なフィルタリングモードに従って、この認証方式を悪用する攻撃をブロックします。

サポートされるインストールオプション¶

Community Ingress NGINX Controller 1.11.5に基づくWallarm Ingress controller。

最新のWallarm Ingress controllerへの移行手順 →
非推奨となったCentOS 8.xの代替として、AlmaLinux、Rocky Linux、Oracle Linux 8.xをサポートしました。

代替OS向けのWallarmノードパッケージはCentOS 8.xリポジトリに格納されます。
Debian 11 Bullseyeをサポートしました
Ubuntu 22.04 LTS（jammy）をサポートしました
CentOS 6.x（CloudLinux 6.x）のサポートを終了しました
Debian 9.xのサポートを終了しました
Ubuntu 16.04 LTS（xenial）のサポートを終了しました

サポートされるインストールオプションの全一覧 →

フィルタリングノードインストールのシステム要件¶

Wallarmノードインスタンスは、攻撃検出ルールやAPI仕様の更新をダウンロードし、許可/拒否/グレーリストに登録された国、地域、データセンターの正確なIPを取得するため、以下のIPアドレスへのアクセスが必要になりました。
US CloudEU Cloud
node-data0.us1.wallarm.com - 34.96.64.17 node-data1.us1.wallarm.com - 34.110.183.149 us1.api.wallarm.com - 35.235.66.155 34.102.90.100 34.94.156.115 35.235.115.105
node-data1.eu1.wallarm.com - 34.160.38.183 node-data0.eu1.wallarm.com - 34.144.227.90 api.wallarm.com - 34.90.110.226
フィルタリングノードがクラウドにデータをアップロードする宛先は、us1.api.wallarm.com:444およびapi.wallarm.com:444から、us1.api.wallarm.com:443（US Cloud）とapi.wallarm.com:443（EU Cloud）に変更されました。

ノードをデプロイしたサーバーが外部リソースへの接続を個別に許可している場合、アップグレード後にフィルタリングノードとクラウド間の同期が停止します。新しいポートのAPIエンドポイントへのアクセスを許可する必要があります。

APIトークンによるWallarm Cloudへのノード登録の統一¶

新しいWallarmノードのリリースでは、メール・パスワードによるクラウドへのノード登録は廃止されました。新しいAPIトークンベースのノード登録方式への移行が必須です。

新リリースでは、サポートされる任意のプラットフォームでAPIトークンによるWallarm Cloudへのノード登録が可能になり、以下のとおりより安全かつ迅速にWallarm Cloudへ接続できます:

ノードのインストールだけが可能なDeployロールの専用ユーザーアカウントは不要です。
ユーザーデータはWallarm Cloudに安全に保存されます。
ユーザーアカウントで二要素認証を有効化していても、ノード登録を妨げません。
別サーバーにデプロイした初期トラフィック処理モジュールとリクエストポストアナリティクスモジュールを、1つのノードトークンでクラウド登録できます。

登録方式の変更に伴い、ノードタイプにも更新があります:

サーバーで実行する登録スクリプト名はregister-nodeです。以前、cloud nodeはトークンによる登録をサポートしていましたが、スクリプト名はaddcloudnodeでした。

cloud nodeは新しいデプロイ手順への移行は不要です。
addnodeスクリプトに渡す「メール・パスワード」での登録に対応していたregular nodeは非推奨です。

現在のノード登録手順は次のとおりです:

Wallarm Console → Settings → API tokensに進みます。
Node deployment/Deploymentの使用タイプでトークンを生成します。
必要なノードのデプロイアーティファクトを、該当パラメータにAPIトークンを渡して実行します。

通常ノードのサポート

regular nodeタイプは非推奨であり、将来のリリースで削除されます。

AWSでWallarmをデプロイするTerraformモジュール¶

Terraformを用いたInfrastructure as Code（IaC）環境から、AWSへWallarmを容易にデプロイできるようになりました。

Wallarm Terraformモジュールは、セキュリティとフェイルオーバーの業界ベストプラクティスに準拠したスケーラブルなソリューションで、プロキシとしてWallarmをデプロイするために設計されています。

WallarmのAWS向けTerraformモジュールのドキュメント

拒否リストソースからのブロックリクエスト統計の収集¶

WallarmのNGINXベースのフィルタリングノードは、ソースが拒否リストにあるためにブロックされたリクエストの統計を収集できるようになり、攻撃の強度評価能力が強化されました。これにはブロックされたリクエストの統計とそのサンプルへのアクセスが含まれ、見落としを最小化できます。Wallarm Console UIのAttacksセクションで確認できます。

自動IPブロッキング（例: ブルートフォーストリガーを設定）を使用している場合、初回にトリガーを発動させたリクエストと、その後にブロックされたリクエストのサンプルの両方を分析できます。ソースの手動拒否リスト登録によりブロックされたリクエストについても、新機能によりブロックソースのアクション可視性が向上します。

Attacksセクションに新しい検索タグとフィルターを導入し、新データへ容易にアクセスできます:

blocked_source検索で、IPアドレス、サブネット、国、VPNなどの手動拒否リスト登録によりブロックされたリクエストを特定できます。
multiple_payloads検索で、Number of malicious payloadsトリガーによりブロックされたリクエストを特定できます。このトリガーは、複数のペイロードを含む悪意のあるリクエストを発するソースを拒否リストに追加する設計です。これはマルチアタック加害者の一般的特徴です。
さらに、api_abuse、brute、dirbust、bola検索タグは、それぞれの攻撃タイプに対応するWallarmトリガーによりソースが自動で拒否リストに追加されたリクエストも包含します。

この変更に伴い、デフォルトでon（有効）に設定され、必要に応じてoff（無効）にできる新しい設定パラメータも導入しました:

wallarm_acl_export_enable NGINXディレクティブ
NGINX Ingress controllerチャート用の値controller.config.wallarm-acl-export-enable
Sidecar Controller向けHelmチャートの値config.wallarm.aclExportEnableと、Podアノテーションsidecar.wallarm.io/wallarm-acl-export-enable

`cloud-init.py`スクリプト同梱のWallarm AWSイメージ¶

Infrastructure as Code（IaC）アプローチに従う場合、cloud-initスクリプトを使用してAWSへWallarmノードをデプロイする必要があるかもしれません。WallarmはAWSクラウドイメージに、すぐに使えるcloud-init.pyスクリプトを同梱しています。

Wallarmのcloud-initスクリプト仕様

マルチテナントノード構成の簡素化¶

マルチテナントノードでは、テナントとアプリケーションをそれぞれ専用のディレクティブで定義します:

テナントの一意識別子を設定するためにwallarm_partner_client_uuid NGINXディレクティブを追加しました。
wallarm_application NGINXディレクティブの挙動を変更しました。現在はアプリケーションIDの設定にのみ使用します。

マルチテナントノードのアップグレード手順

フィルタリングモード¶

新しいsafe blockingフィルタリングモード。

このモードは、グレーリストIPアドレスからの悪意あるリクエストのみをブロックすることで、誤検知の大幅な削減を可能にします。
リクエストソースの分析は、safe_blockingおよびblockモードでのみ実行されます。
- offまたはmonitoringモードで動作するWallarmノードが、拒否リストのIPからのリクエストを検出しても、このリクエストはブロックしません。
- monitoringモードで動作するWallarmノードは、許可リストIPアドレスからのすべての攻撃をWallarm Cloudにアップロードします。

Wallarmノードのモードの詳細 →

リクエストソース制御¶

以下のリクエストソース制御パラメータは非推奨です:

IPアドレス拒否リストの設定に使用されるすべてのacl NGINXディレクティブと環境変数。IPの手動拒否リスト登録は不要になりました。

拒否リスト設定の移行詳細 →

リクエストソース制御には以下の新機能があります:

IPアドレスの許可リスト・拒否リスト・グレーリストを完全に管理するためのWallarm Consoleセクション
新しいフィルタリングモードsafe_blockingとIPアドレスのグレーリストのサポート

safe blockingモードは、グレーリストIPアドレスからの悪意あるリクエストのみをブロックすることで、誤検知の大幅な削減を可能にします。

自動グレーリスト化には、新たに提供されたNumber of malicious payloadsトリガーを使用できます。
企業リソースの脆弱性スキャンや追加のセキュリティテストに使用するWallarmのスキャナーIPの自動許可リスト登録。これらのアドレスの手動許可は不要です。
サブネット、TorネットワークIP、VPN IP、特定の国・地域・データセンターに登録されたIPグループを許可・拒否・グレーリスト化可能
特定のアプリケーションに対して、リクエストソースを許可・拒否・グレーリスト化可能
リクエストの発信元分析を無効化するための新しいNGINXディレクティブdisable_acl

disable_acl NGINXディレクティブの詳細 →

許可リスト・拒否リスト・グレーリストへのIP追加の詳細 →

APIインベントリ検出のための新モジュール¶

新しいWallarmノードには、アプリケーションAPIを自動識別するモジュールAPI Discoveryが同梱されています。モジュールはデフォルトで無効です。

API Discoveryモジュールの詳細 →

libdetectionライブラリによる攻撃分析の強化¶

Wallarmによる攻撃分析は、追加の攻撃検証レイヤーを導入して強化されました。すべてのフォームファクターのWallarmノードには、デフォルトでlibdetectionライブラリが有効になっています。このライブラリは、すべてのSQLi攻撃に対して、完全な文法ベースの二次検証を実行し、SQLインジェクションにおける誤検知を削減します。

メモリ消費量の増加

libdetectionライブラリを有効にすると、NGINXおよびWallarmプロセスのメモリ消費量が約10%増加する可能性があります。

Wallarmの攻撃検出方法の詳細 →

`overlimit_res`攻撃検出の微調整を可能にするルール¶

overlimit_res攻撃検出を微調整する新しいルールを導入しました。

NGINX設定ファイルによるoverlimit_res攻撃検出の微調整は非推奨の方法となります:

このルールでは、以前のwallarm_process_time_limit NGINXディレクティブと同様に、単一のリクエスト処理時間の上限を設定できます。
このルールでは、wallarm_process_time_limit_block NGINXディレクティブの代わりに、ノードのフィルタリングモードに従ってoverlimit_res攻撃をブロックまたは許可できます。

上記のディレクティブおよびパラメータは非推奨となり、将来のリリースで削除されます。それまでに、ディレクティブからルールへのoverlimit_res攻撃検出の設定移行を推奨します。該当するノードのデプロイオプションごとの手順を参照してください。

設定ファイルに上記のパラメータが明示的に指定されており、ルールがまだ作成されていない場合、ノードは設定ファイルの内容に従ってリクエストを処理します。

最適化され、よりセキュアになったNGINXベースのDockerイメージ¶

WallarmのNGINXベースのフィルタリングノード用Dockerイメージは、セキュリティと最適化のために刷新されました。主な更新点は次のとおりです:

DockerイメージはDebianからAlpine Linuxベースに変更され、より安全で軽量なアーティファクトになりました。以前同梱されていたauth-pamおよびsubs-filter NGINXモジュールはDockerイメージには含まれなくなりました。
NGINXの最新安定版1.28.0へ更新（以前は1.14.x）。1.14.xの多くの脆弱性はDebian（旧イメージはDebian 10.xベース）によりパッチ適用済みでしたが、1.28.0への更新で残存する脆弱性も解消し、セキュリティが向上します。

NGINXの更新とAlpine Linuxへの移行により、NGINX 1.28.0に実装されたAlpine固有のパッチによってHTTP/2 Rapid Reset脆弱性（CVE-2023-44487）が解消されます。
ARM64アーキテクチャのプロセッサーをサポートし、インストール時に自動検出します。
Dockerコンテナ内のすべての操作は、以前のrootユーザーではなく、非rootユーザーwallarmで実行されるようになりました。これはNGINXプロセスにも適用されます。
/wallarm-statusエンドポイントは、Dockerコンテナ外からアクセスする場合に、JSONではなくPrometheus形式でメトリクスをエクスポートするよう更新されました。この機能には、環境変数WALLARM_STATUS_ALLOWの適切な設定が必要です。
DockerイメージはAll-in-oneインストーラーでビルドされるようになり、内部ディレクトリ構造が変更されました:
- ログディレクトリ: /var/log/wallarm → /opt/wallarm/var/log/wallarm
- クラウド接続用の資格情報ファイル格納ディレクトリ: /etc/wallarm → /opt/wallarm/etc/wallarm
/usr/shareディレクトリのパス → /opt/wallarm/usr/share

これにより、サンプルブロックページの新しいパスは/opt/wallarm/usr/share/nginx/html/wallarm_blocked.htmlになります。

新機能は新フォーマットのNGINXベースDockerイメージでもサポートされます。

クラウドイメージの最適化¶

Amazon Machine Image（AMI）とGoogle Cloud Machine Imageを最適化しました。主な更新点は次のとおりです:

クラウドイメージは、セキュリティの向上のため、旧Debian 10.x（buster）から最新安定版Debian 12.x（bookworm）に変更しました。
NGINX 1.22.1へ更新（以前は1.14.x）。
ARM64アーキテクチャのプロセッサーをサポートし、インストール時に自動検出します。
クラウドイメージはAll-in-oneインストーラーでビルドされるようになり、内部ディレクトリ構造が変更されました:
- ノード登録スクリプト: /usr/share/wallarm-common/register-node → /opt/wallarm/usr/share/wallarm-common/cloud-init.py
- ログディレクトリ: /var/log/wallarm → /opt/wallarm/var/log/wallarm
- クラウド接続用の資格情報ファイル格納ディレクトリ: /etc/wallarm → /opt/wallarm/etc/wallarm
- /usr/shareディレクトリのパス → /opt/wallarm/usr/share
  
  これにより、サンプルブロックページの新しいパスは/opt/wallarm/usr/share/nginx/html/wallarm_blocked.htmlになります。
- グローバルなWallarmフィルタリングノード設定を含む/etc/nginx/conf.d/wallarm.confファイルは削除されました。

新機能は新フォーマットのクラウドイメージでもサポートされます。

新しいブロックページ¶

サンプルブロックページ/usr/share/nginx/html/wallarm_blocked.htmlを更新しました。新しいノードバージョンではレイアウトが刷新され、ロゴとサポートメールのカスタマイズに対応しました。

新しいレイアウトのブロックページは、デフォルトで以下のとおりです:

ブロックページ設定の詳細 →

基本的なノード設定の新パラメータ¶

WallarmのNGINXベースDockerコンテナに渡す新しい環境変数:
- WALLARM_APPLICATION: Wallarm Cloudで使用する保護対象アプリケーションの識別子を設定します。
- NGINX_PORT: Dockerコンテナ内でNGINXが使用するポートを設定します。
WallarmのNGINXベースDockerコンテナのデプロイ手順 →
Wallarm Cloudとフィルタリングノードの同期設定用に、node.yamlファイルへ新パラメータapi.local_hostとapi.local_portを追加しました。これらにより、Wallarm APIへのリクエスト送信に用いるネットワークインターフェイスのローカルIPアドレスとポートを指定できます。

Wallarm Cloudとフィルタリングノードの同期設定に関するnode.yamlパラメータの全一覧 →

NGINXベースのWallarm DockerコンテナでのIPv6接続の無効化¶

NGINXベースのWallarm Dockerイメージは、新しい環境変数DISABLE_IPV6をサポートします。この変数により、NGINXがIPv6接続を処理しないようにし、IPv4接続のみを処理させることができます。

パラメータ、ファイル、メトリクスの名称変更¶

次のNGINXディレクティブの名称を変更しました:
- wallarm_instance → wallarm_application
- wallarm_local_trainingset_path → wallarm_custom_ruleset_path
- wallarm_global_trainingset_path → wallarm_protondb_path
- wallarm_ts_request_memory_limit → wallarm_general_ruleset_memory_limit
旧名称のパラメータも引き続きサポートしますが、将来のリリースで非推奨になります。パラメータのロジックに変更はありません。
Ingressのアノテーションnginx.ingress.kubernetes.io/wallarm-instanceをnginx.ingress.kubernetes.io/wallarm-applicationに変更しました。

旧名称のアノテーションも引き続きサポートしますが、将来のリリースで非推奨になります。アノテーションのロジックに変更はありません。
カスタムルールセットビルドのファイル/etc/wallarm/lomを/etc/wallarm/custom_rulesetに変更しました。新しいノードバージョンのファイルシステムには新名称のファイルのみが存在します。

NGINXディレクティブwallarm_custom_ruleset_pathのデフォルト値もこれに合わせて変更され、新しいデフォルト値は/etc/wallarm/custom_rulesetです。
秘密鍵ファイル/etc/wallarm/license.keyを/etc/wallarm/private.keyに変更しました。新しい名称がデフォルトで使用されます。

統計サービスのパラメータ¶

Prometheusメトリクスwallarm_custom_ruleset_idにformat属性を追加しました。この属性はカスタムルールセットのフォーマットを表します。主値は引き続きカスタムルールセットのビルドバージョンです。更新後のwallarm_custom_ruleset_id値の例:
```
wallarm_custom_ruleset_id{format="51"} 386
```
Wallarm統計サービスは、新しいWallarmのレート制限モジュールのデータとともに新パラメータrate_limitを返します。新パラメータは、拒否されたリクエストや遅延されたリクエスト、ならびにモジュールの動作に関する問題を示します。
拒否リストIPからのリクエスト数は、統計サービス出力の新パラメータblocked_by_aclおよび既存のrequests、blockedにも表示されます。
サービスは新パラメータcustom_ruleset_verも返し、Wallarmノードが使用しているカスタムルールセットのフォーマットを示します。
次のノード統計パラメータの名称を変更しました:
- lom_apply_time → custom_ruleset_apply_time
- lom_id → custom_ruleset_id
新しいノードバージョンでは、一時的にhttp://127.0.0.8/wallarm-statusエンドポイントが非推奨および新パラメータの両方を返します。非推奨パラメータは将来のリリースでサービス出力から削除されます。

統計サービスの詳細 →

ノードのログ形式を設定するための新変数¶

次のノードのロギング変数を変更しました:

wallarm_request_timeをwallarm_request_cpu_timeに変更

この変数は、リクエスト処理にCPUが費やした時間（秒）を意味します。

旧名称の変数は非推奨であり、将来のリリースで削除されます。変数のロジックに変更はありません。
wallarm_request_mono_timeを追加

この変数は、リクエスト処理にCPUが費やした時間（秒）＋キュー待ちの時間を意味します。

拒否リストIPからのリクエストで攻撃探索を省略して性能を向上¶

新しいディレクティブwallarm_acl_access_phaseにより、拒否リストIPからのリクエスト分析時に攻撃探索ステージを省略して、Wallarmノードの性能を向上できます。多数の拒否リストIP（例: 国全体）からの高トラフィックによりCPU負荷が高い環境で有用です。

ノードインスタンスの簡単なグルーピング¶

Node deployment/Deployment使用タイプのAPIトークンと、groupラベルを含むWALLARM_LABELS変数を併用することで、ノードインスタンスを簡単にグルーピングできるようになりました。

例:

docker run -d -e WALLARM_API_TOKEN='<API TOKEN WITH DEPLOY ROLE>' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_LABELS='group=<GROUP>' -p 80:80 wallarm/node:6.4.1

…により、ノードインスタンスは<GROUP>インスタンスグループに配置されます（既存の場合はそこへ、存在しない場合は作成されます）。

対応済みの脆弱性¶

新リリースでは、Wallarmのデプロイアーティファクトに含まれていた重大・高リスクの複数の脆弱性に対応し、脆弱なコンポーネントを置き換えることでソフトウェアのセキュリティ体制を強化しました。

対応済みの脆弱性には、CVE-2020-36327、CVE-2023-37920などが含まれます。

HTTP/2ストリーム長制御ディレクティブ¶

HTTP/2ストリームの最大長を制御するディレクティブwallarm_http_v2_stream_max_lenを導入しました。長寿命のgRPC接続での過剰なメモリ消費を防止するのに役立ちます。

この変数をDockerコンテナで使用するには、NGINX設定ファイルに指定し、そのファイルをコンテナにマウントしてください。

Account Takeover、Scraping、Security Crawlers用の個別検索タグ¶

account_takeover、scraping、security_crawlers攻撃タイプ向けの個別の検索タグを導入し、従来の一般的なapi_abuseタグよりも特異性が向上しました。

コネクタおよびTCPトラフィックミラー向けNative Node¶

NGINXに依存しない新しいWallarmノードのデプロイオプション、Native Nodeを紹介します。このソリューションは、NGINXが不要な環境や、プラットフォーム非依存のアプローチが望まれる環境向けに開発されました。

現在、以下のデプロイに対応しています:

MuleSoft、Cloudflare、CloudFront、Broadcom Layer7 API Gateway、Fastlyコネクタ（リクエスト・レスポンスの両方を分析）
Kong API GatewayおよびIstio Ingressコネクタ
TCPトラフィックミラー分析

詳細を読む

ポストアナリティクスでTarantoolをwstoreに置換¶

Wallarmノードは、ローカルのポストアナリティクス処理に、Tarantoolの代わりにWallarm開発のサービスwstoreを使用します。結果として以下の変更があります:

All-in-oneインストーラー、AWS/GCPイメージ:
- ポストアナリティクスモジュールを他のNGINXサービスと分離してデプロイする場合のサーバーアドレスを定義するNGINXディレクティブwallarm_tarantool_upstreamは、wallarm_wstore_upstreamに名称変更されました。
  
  後方互換性は警告付きで維持されます:
```
2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19
```
  * ログファイルの名称変更: /opt/wallarm/var/log/wallarm/tarantool-out.log → /opt/wallarm/var/log/wallarm/wstore-out.log
  * 新しいwstore設定ファイル/opt/wallarm/wstore/wstore.yamlが、/etc/default/wallarm-tarantoolや/etc/sysconfig/wallarm-tarantoolなどの旧Tarantool設定ファイルを置き換えます。
  * /opt/wallarm/etc/wallarm/node.yaml内のtarantoolセクションはwstoreになりました。後方互換性は警告付きで維持されます。
Dockerイメージ:
- 上記の変更はコンテナ内にも適用されています。
- 以前は環境変数TARANTOOL_MEMORY_GBでTarantoolのメモリを割り当てていましたが、同じ原則で新しい変数を使用します: TARANTOOL_MEMORY_GB → SLAB_ALLOC_ARENA
- Alpine Linuxの慣例に合わせてコンテナのディレクトリ構造を調整しました。具体的には:
  - /etc/nginx/modules-availableおよび/etc/nginx/modules-enabledの内容を/etc/nginx/modulesに移動しました。
  - /etc/nginx/sites-availableおよび/etc/nginx/sites-enabledの内容を/etc/nginx/http.dに移動しました。
- /wallarm-statusサービスに許可されたIPアドレスを指定する既定のallow値は、127.0.0.8/8から127.0.0.0/8になりました。
Kubernetes Ingress Controller:
- Tarantoolは別Podではなくなり、wstoreはメインの<CHART_NAME>-wallarm-ingress-controller-xxx Pod内で動作します。
- Helmの値名を変更: controller.wallarm.tarantool → controller.wallarm.postanalytics
Kubernetes Sidecar Controller:
- Helmの値名を変更: postanalytics.tarantool.* → postanalytics.wstore.*
- Sidecarデプロイ用Helmチャートから以下のDockerイメージを削除しました:
  これらは現在、関連サービスを実行するwallarm/node-helpersイメージに置き換えられています。

以下の変更は、この後に記載するノードアップグレード手順に組み込まれています。

アップグレード手順¶

モジュールのアップグレードに関する推奨事項を確認します。
使用中のWallarmノードのデプロイオプションに応じた手順に従って、インストール済みモジュールをアップグレードします:
- All-in-oneインストーラーによるNGINX、NGINX Plus向けモジュールのアップグレード
  
  アップグレードプロセスの改善と簡素化のため、すべてのノードバージョンのアップグレードはWallarmのAll-in-oneインストーラーで実施します。個別のLinuxパッケージによる手動アップグレードはサポートしません。
- NGINXモジュール入りDockerコンテナのアップグレード
- Wallarmモジュール統合済みNGINX Ingress controllerのアップグレード
- クラウドノードイメージ
- マルチテナントノード
以前のWallarmノードバージョンの許可リスト・拒否リスト設定を、最新バージョンへ移行します。

Wallarm製品およびコンポーネントのその他の更新情報 →

EOLノードをアップグレードする場合のWallarmノードの新機能¶

All-in-oneインストーラーとDEB/RPMパッケージの非推奨化¶

collectdの廃止¶

API Sessions¶

API Sessionsのレスポンスパラメータ¶

レート制限¶

Credential stuffing detection ¶

GraphQL API protection ¶

Mitigation Controls¶

ファイルアップロード制限ポリシー¶

列挙攻撃保護¶

DoS保護¶

既定のコントロール¶

unrestricted resource consumptionからの保護¶

API Specification Enforcement¶

新しい攻撃タイプの検出¶

API DiscoveryとAPI Sessionsのセンシティブなビジネスフロー¶

フル機能のGraphQLパーサー¶

JSON Web Tokenの強度チェック¶

JSON Web Tokenに対する攻撃の検査¶

サポートされるインストールオプション¶

フィルタリングノードインストールのシステム要件¶

APIトークンによるWallarm Cloudへのノード登録の統一¶

AWSでWallarmをデプロイするTerraformモジュール¶

拒否リストソースからのブロックリクエスト統計の収集¶

cloud-init.pyスクリプト同梱のWallarm AWSイメージ¶

マルチテナントノード構成の簡素化¶

フィルタリングモード¶

リクエストソース制御¶

APIインベントリ検出のための新モジュール¶

libdetectionライブラリによる攻撃分析の強化¶

overlimit_res攻撃検出の微調整を可能にするルール¶

最適化され、よりセキュアになったNGINXベースのDockerイメージ¶

クラウドイメージの最適化¶

新しいブロックページ¶

基本的なノード設定の新パラメータ¶

NGINXベースのWallarm DockerコンテナでのIPv6接続の無効化¶

パラメータ、ファイル、メトリクスの名称変更¶

統計サービスのパラメータ¶

ノードのログ形式を設定するための新変数¶

拒否リストIPからのリクエストで攻撃探索を省略して性能を向上¶

ノードインスタンスの簡単なグルーピング¶

対応済みの脆弱性¶

HTTP/2ストリーム長制御ディレクティブ¶

Account Takeover、Scraping、Security Crawlers用の個別検索タグ¶

コネクタおよびTCPトラフィックミラー向けNative Node¶

ポストアナリティクスでTarantoolをwstoreに置換¶

アップグレード手順¶

`cloud-init.py`スクリプト同梱のWallarm AWSイメージ¶

`overlimit_res`攻撃検出の微調整を可能にするルール¶