Next-Gen WAF を最大限に活用する10のヒント

Fastly の Technical Account Management チームの役割のひとつに、お客様が Fastly の Next-Gen WAF (Powered by Signal Sciences) を最も効果的に活用できるよう支援することがあります。私たちは日々、さまざまな業界のお客様からの質問に直接対応し、ガイダンスを提供することで、皆様が円滑にサービスをお使いいただけるようサポートしています。

本記事では、そうした業務を通じて提供しているアドバイスをご紹介します。私たちが推奨する以下のプラクティスを参考に、Fastly の Next-Gen WAF (NGWAF) を最大限にご活用ください。

1. クライアント IP の偽装防止

まずは、本当のクライアント IP を取得できる必要があります (これは基本的なステップですが、見落とされがちなポイントです)。そうでないと、攻撃者はブロックを避けるために必要なヘッダーを変更するだけで、WAF をバイパスできるようになります。

Next-Gen WAF のエージェントは X-Forwarded-For ヘッダーを利用して、クライアント IP アドレス (例 : client-ip-header="Fastly-Client-IP") を特定します。このヘッダーは、異なる IP をヘッダーで渡すだけで簡単に偽装が可能です。

Fastly のお客様向けドキュメントでは、この問題に対応しています。具体的には、別のヘッダーを渡し、そのヘッダーを利用して本当のクライアント IP を判断できるようエージェントを設定するというソリューションを提案しています。また、X-Forwarded-For IP アドレスをデフォルトの左から右ではなく、右から左に読み取るようエージェントを設定することも推奨しています。この場合、local-networks="private" を設定する必要があります。

オンプレミス (モジュール/エージェント) のデプロイでは、NGWAF エージェントがヘッダーを受信する前に、本当の IP アドレスが確実に検証されるようにしなければなりません。例えば、NGINX では ngx_http_realip_module によって、クライアントの IP アドレスを検証します。

NGWAF の前面に Fastly CDN を配置しているお客様は、(こちらで説明している通り) カスタム VCL を利用して IP アドレスを渡すことができるメリットを得られます。これにより、本当のクライアント IP を Fastly-Client-IP ヘッダーに渡せるようになります。

代替ヘッダーはコントロールパネルで設定できます。Cloud WAF 以外のデプロイ方法をご利用の場合は、こちらに手順が説明されています。

Cloud WAF をデプロイする場合は、Cloud WAF インスタンスで Instance location の Advanced を選択して、使用すべき適切なヘッダーを指定することで設定できます。

本当のクライアント IP アドレスとして使用するヘッダーを特定したので、IP とシグナルを利用しながら、しきい値を活用できます。

2. 攻撃のしきい値の調整

IP がしきい値に近づいている (まだ超えていない) かどうかは、Observed Sources -> Suspicious IPs から確認が可能です。

しきい値の設定は、誤検知の発生時に正当なトラフィックがブロックされないようにする、Fastly NGWAF の重要な機能です。IP が攻撃シグナルの現在のしきい値に達していない場合は、NGWAF が潜在的な攻撃を見落としている可能性があります。

すべての攻撃シグナルに、1分あたり50件のリクエストがデフォルトのしきい値として設定されています。しかし、上記のスクリーンショットを確認すると、しきい値の75%を超えた IP が2つあることがわかります。これは約37件の SQLi リクエストが許可されたことを示しています。あまり沢山の攻撃を許可したくないので、多くの場合、このしきい値を下げるのは適切な判断です。本番環境に影響を与える問題がないことを確認するために、しきい値の変更前にテストや検証を行う必要があります。

例えば、上記の SQLi 攻撃の場合、SQLi の攻撃しきい値を1分あたり25件まで下げるのが望ましいです。

通常はこの値を少しずつ下げるか、場合によっては SQLi のような攻撃リクエストを完全にブロックすることになります。このアクションは、そのシグナルをブロックするリクエストルールを作成することで可能になります。

3. 悪意のある IP からの攻撃をブロック

このリクエストルールによって、悪意のある IP シグナルを使用して、しきい値によるブロックが作動する前に攻撃リクエストを即座に阻止することができます。

NGWAF は複数のソースから IP 情報を取得します。ソースには、SANS Internet Storm Center から定期的にインポートされる SANS Malicious IP リストがあります。IP は、ポートスキャンや、ボットソースまたはランサムウェアソースとして認識されるなど、さまざまな理由でこのリストに追加されます。このリストの IP には、Malicious IP というシグナルでタグ付けされます。また、NGWAF は Tor Project から TOR 出口ノードのリストを定期的にインポートします。これらの IP は、Tor Traffic というシグナルでタグ付けされます。さらに NGWAF プラットフォーム内に IP レピュテーション機能を構築し、同プラットフォームを利用するすべてのお客様に対する攻撃動作を観測して、Fastly の内部脅威レピュテーションリストに追加しています。これらの IP は、SigSci IP というシグナルでタグ付けされます。

これらの3種類のシグナルは、リクエスト送信者が悪意を持って行動していることを保証するとは限りません。そのため、こうしたシグナルを NGWAF で定義済みの攻撃システムシグナルと併用することをお勧めします。そうすることで、以下のルールが、既知の脅威レピュテーションソースからアプリケーションを攻撃しようとする攻撃者を即座にブロックすることが可能になります。

4. OFAC のリストに含まれる国からのリクエストをブロック

米国財務省外国資産管理室 (OFAC) による規制対象国のリストに記載されている国からのリクエストをブロックするルールを構築できます。下記のスクリーンショットには、同リストの国コードを識別するために使用されるサイトリストが表示されています。

お気づきの通り、このリストには具体的な地域が示されていません。ソース IP の位置情報を判断するには、国コード以外の情報も必要になるからです。

対応策として、Fastly CDN をプロビジョニングして ASN 情報をヘッダーで渡す方法が挙げられます。ASN ヘッダーを使用して、同様のリストとリクエストルールを作成することで、アプリケーションへのアクセスを許可しない ASN のリストを構築します。

5. 既知の悪質なユーザーエージェントからのリクエストをブロック

これは実行しやすいシンプルな対策方法です。アプリケーションにアクセスするために、有効なユーザーエージェントが使われていることを確認します。アクセスを許可しないユーザーエージェントのリストを作成し、即座にブロックできます。以下は、アプリケーションへのアクセスが許可されるべきではないユーザーエージェントのリストです。

注意点 : このリストでは大文字小文字が区別されるので、あらゆる可能性が考慮されるようワイルドカードの活用を検討してください。

このリストをリクエストルールに使用して、即座にブロックを実行できます。

6. 無効なホストヘッダーを含むリクエストをブロック

このルールは、アプリケーションに IP アドレスで直接アクセスを試みるリクエストや、ホストヘッダーが空のリクエストをブロックします。NGWAF では、アプリケーションへのアクセスに使用されるべき有効なドメインのリストを作成できるだけでなく、以下のようにリスト化することも可能です。

このルールを使用して、ホストヘッダーがアプリケーションのドメインと一致した際に、Domain Request というシグナルを追加して識別します。

次に、Domain Request シグナルに一致しないものをすべてブロックする別のリクエストルールを作成します。さらに、そのようなリクエストを Invalid Request としてタグ付けするシグナルを追加します。

7. ドメインアクセスのレート制限 (アプリケーション DDoS 対策)

注意点 : この機能の利用にはプレミアライセンスが必要です。

DDoS 攻撃から保護するために、アプリケーションレイヤーで高度なレート制限を行いたいというご要望をよく伺います。ドメインリクエストの識別を目的とする先述のルールセットを使用してレート制限ルールを作成し、トラフィックを制限できるようになりました。

この例では、1分間に100件のドメインリクエストがあった場合、ドメインへのアクセスをブロックして、レスポンスコード429を返します。

8. 列挙の試行をレート制限

注意点 : この機能の利用にはプレミアライセンスが必要です。

多くの攻撃者は、さまざまな技術を利用してアプリケーションや API の列挙を試みます。例えば、攻撃者がファイルやディレクトリにブルートフォース攻撃でアクセスを試みるか、クレデンシャルスタッフィング攻撃を行おうとした場合、4XX や 5XX エラーが多数発生する可能性があります。

列挙の試行がエスカレートするのを防ぐためにレート制限ルールを利用して、アプリケーションや API を保護することができます。このルールは広範なユースケースに対応しますが、必要に応じて変更も可能です。

このスクリーンショットでは、4XX または 5XX レスポンスを発生させるすべてのリクエストを探しています。それらのリクエストを見つけた場合、列挙の試行であるとみなします。カウントシグナル (この場合は Suspected Attacker) は、そうした試行を追跡します。(先ほど設定した) アクションシグナルの Domain Request は、アクセスをブロックしようとするドメインを特定します (詳細は上記のセクションを参照)。これにより、列挙の試行のしきい値に達した後、後続のリクエストがブロックされます。

9. 新機能やリリースの通知

新機能やリリースの通知を有効にしてください。New Feature Announcements は、エージェントリリースのプロダクト強化に関する情報のみを提供します。これには通常、そのエージェントリリースバージョンに適用されたバグ修正や機能強化に関する情報が含まれます。

Corp Manage > Corp Integration で以下のイベントを選択し、通知を設定します。

新機能の通知はこちらに掲載されます : Announcements - Signal Sciences Help Center

Release Created イベントはエージェントのリリースに関する情報のみを提供し、こちらに掲載されます : Agent - Signal Sciences Help Center

10. API または Syslog によるログ取得

ログデータの取得は、特にセキュリティプロダクトの可観測性の確保において重要です。これには Next-Gen WAF からログデータを取り出して、SIEM にエクスポートすることも含まれます。ログデータの取得にはさまざまな方法がありますが、選択肢は状況により異なります。こちらのブログ記事では、詳しい情報をご紹介しています。

サンプル/編集済みログデータの取得が望ましい場合は、API を使用して NGWAF のダッシュボードからデータを抽出するのが最適なソリューションです。API を活用してデータを抽出するのに使用可能な Python スクリプトの例はこちらです。Splunk を使用している場合は、API を利用する Splunk アプリを活用することもできます。

サンプリングされていない/未編集のデータの方が都合が良い場合は、Syslog を活用してエージェントログを取得し、Syslog サーバーに転送する方法もあります。この場合、エージェントでデバッグログを有効にする必要があります。以下の設定を agent.conf に追加してください。

debug-log-web-inputs = 1
debug-log-web-outputs = 1
log-out = “/var/log/sigsci.log”

このデバッグログオプションを有効にするオプションは、Cloud WAF を利用するお客様は現在ご利用になれません。

Next-Gen WAF でアプリケーションを保護

今回ご紹介したヒントによって、お客様が Fastly の Next-Gen WAF を最大限に活用し、デプロイ場所を問わずにアプリケーションをこれまで以上にしっかりと保護できるようお役に立てれば幸いです。より詳しいガイダンスが必要な場合は、担当の Fastly テクニカルアカウントマネージャーにお気軽にお問い合わせください。

Fastly の Next-Gen WAF の詳細については、製品ページをご覧ください。