サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

AWS WAFのNoUserAgent_HEADERとは？検知条件・Count設定・誤検知対策を解説

greeden
AWS WAF Image

NoUserAgent_HEADERは、HTTPリクエストにUser-Agentヘッダーがない場合に一致するAWS WAFのマネージドルールです。
AWSのCore rule set（AWSManagedRulesCommonRuleSet）に含まれ、既定のルールアクションはBlockです。

ただし、User-Agentがないことだけで攻撃と断定することはできません。
正当なAPIクライアント、Webhook、監視処理なども、実装によっては同じ条件に一致するためです。

導入時はNoUserAgent_HEADERだけをいきなり本番でブロックさせず、Countで一致状況を確認し、正当な通信への影響を調べてから扱いを決めます。
AWS WAFの役割やWeb ACLの基本から確認したい場合は、先に全体像を押さえると設定の位置づけがわかりやすくなります。

NoUserAgent_HEADERが確認する条件

User-Agentは、ブラウザやプログラムなどのクライアントが、自らの種類やバージョンをサーバーへ伝えるために使うHTTPリクエストヘッダーです。
申告値なので、クライアントの身元や安全性を保証する情報ではありません。

NoUserAgent_HEADERの基本的な挙動
項目 内容
ルールグループ AWSManagedRulesCommonRuleSet（Core rule set）
確認する条件 HTTPリクエストにUser-Agentヘッダーがない
既定のアクション Block
検証時の調整 個別ルールのアクションをCountへ変更できる

このルールが確認するのはヘッダーの有無です。
User-Agentの文字列が信頼できるクライアントを示しているか、リクエストの内容が安全かまでは判定しません。

リクエストがブロックされる流れ

  1. User-AgentヘッダーのないリクエストがWeb ACLへ届きます。
  2. 評価順がNoUserAgent_HEADERまで進むと、ルールの条件に一致します。
  3. ルールアクションが既定のBlockのままなら、そのリクエストは遮断されます。

AWS WAFのBlockによる既定の応答はHTTP 403ですが、403という結果だけではNoUserAgent_HEADERが原因だと断定できません。
別のWAFルールやアプリケーションも403を返し得るため、AWS WAFのログやサンプルリクエストで一致したルール名を確認します。

User-Agentがない通信を一律に攻撃とみなせない理由

ヘッダーがないことは調査のきっかけになりますが、通信の目的を示す証拠にはなりません。
攻撃用のスクリプトがUser-Agentを省く場合がある一方で、任意の文字列を付けることもできます。

正当な自動通信でも、利用するライブラリや外部サービスの仕様によってヘッダーが送られない場合があります。
特にAPI連携、Webhook、ヘルスチェック、機器からの通信では、ブラウザと同じ前提を置かず、実際のリクエストを確認する必要があります。

判定では、対象パス、送信元、認証の成否、発生頻度、想定している処理との一致を組み合わせます。
User-Agentの有無だけで許可または拒否を決めると、正当な通信の停止と不審な通信の見逃しの両方が起こり得ます。

安全に導入する手順

1. 個別ルールをCountにする

まず、NoUserAgent_HEADERのルールアクションをCountへ上書きします。
Countは一致を記録しますが、その一致だけではリクエストを許可も拒否もせず、Web ACLの後続評価を続けます。

AWS Managed Rulesの種類とCountによる検証方法も、ルールグループ全体の導入を考える際の参考になります。

2. 一致した通信をログで分類する

ログでは、一致したルール名に加えて、どのパスへ、いつ、どの送信元からリクエストが届いたかを確認します。
運用中のAPI、外部連携、監視処理と照合し、正当な通信と調査が必要な通信を分けます。

3. クライアント側で修正できるか確認する

自社が管理するクライアントなら、用途がわかるUser-Agentを明示的に付ける方法が最も影響範囲を絞りやすい対応です。
値に認証情報や個人情報を含めず、クライアント名と管理上必要なバージョンなどにとどめます。

4. 例外の範囲を設計する

クライアントを変更できない場合は、NoUserAgent_HEADERをCountにしたうえで、後続のカスタムルールと条件を組み合わせて扱いを分ける方法を検討します。
特定パスだけを許可したい場合も、広いAllowルールで他の検査まで飛ばさないようにします。

マネージドルールグループのscope-down statementは、NoUserAgent_HEADERだけでなく、そのルールグループが評価するリクエスト範囲を狭めます。
パスを除外する目的で使う場合は、Core rule set内のほかのルールもそのパスを評価しなくなる影響を確認しなければなりません。

対策ごとの影響範囲
方法 向いている状況 確認点
クライアントにUser-Agentを追加 管理できるAPIクライアントや監視処理 値に秘密情報を含めない
NoUserAgent_HEADERをCountへ変更 導入前の観測、誤検知の調査 このルールによる遮断は行われない
後続のカスタムルールで条件分岐 パスなどに応じて扱いを変えたい場合 ルールの評価順と条件をテストする
マネージドルールグループをscope-down グループ全体の評価対象を絞りたい場合 ほかのCore rule setルールへの影響も調べる

curlで有無を比較する方法

curlは通常、curl自身を示すUser-Agentを送信します。
そのため、単にcurlを実行しただけでは「ヘッダーなし」の再現になりません。

管理下の検証用エンドポイントに対して、ヘッダーを除いた場合と明示した場合を比較します。

# User-Agentヘッダーを送らない
curl -I -H "User-Agent:" https://example.com/health

# 管理用のUser-Agentを明示する
curl -I -A "InternalHealthCheck/1.0" https://example.com/health

HTTPステータスだけでなく、同じ時刻帯のAWS WAFログを確認し、どのルールに一致したかを照合します。
第三者のサイトではなく、自社が管理するテスト環境または許可された環境で実施します。

403発生時の確認項目

運用で避けたい判断

NoUserAgent_HEADER運用の要点

この記事に関連する株式会社greedenの取り組み

NoUserAgent_HEADERは、入れるだけでなく通信実態に合わせて検証と調整を続ける運用が必要です。
株式会社greedenは、AWSを含むクラウド環境を見据えたWebシステム開発から、リリース後の保守・運用改善まで支援しています。

モバイルバージョンを終了