
User-Agentを基盤とした悪意的アクセス判断の限界と対応戦略
こんにちは。D.Lです。
過去にGithubとCI/CDを扱った記事以後、二度目に記事を残すことになりました。
私はMSP業務以外にも個人的にサーバーを運営しております。
単純に個人的な関心事でしたが、時間が経つにつれて業務スキル向上に個人サーバー運営が大きく役立つということを感じております。
業務で接した新しい技術やセキュリティイシューを個人サーバーでテストしてみることができ、個人サーバー運営中に発見したインサイトをMSP業務に適用してみることができました。
今回は個人サーバーのテストを進行しながら経験したことを通じて、User-AgentのスプーフィングとMSP業務で直面する問題、そしてこれに対する対応戦略を書いてみたいと思います。
1. DDoSテストで直面したUser-Agentスプーフィング
先日個人サーバーのシステム限界点とボトルネック区間を調査するためDDoSテストを進行しながら、アクセスログでUser-Agentがランダムに変わることを発見いたしました。



「TESTING_PURPOSES_ONLY」とメッセージを表示しておりますが、User-AgentはDDoS攻撃と疑わせないよう一般的なクローラーやブラウザの姿をしておりました。
以前からUser-Agentスプーフィングが可能であることは知っておりましたが、DDoSツールがこのように積極的に応用している以上、これについてもう少し調査してみることにいたしました。
2. User-Agentスプーフィングの日常化
DDoS攻撃ツールや脆弱性スキャンツールの使用事例を見ますと、User-Agentのスプーフィングは既に攻撃の基本要素になっているものと見られます。
1. Layer7 DDoS攻撃事例で上位10個のUser-Agentのうち3個はボットで、7個は一般ユーザーのふりをして偽装
https://datadome.co/learning-center/case-study-from-ddos-panic-to-peace-of-mind-in-less-than-an-hour/
2. HTTP Flood攻撃ツールの場合、人気のあるブラウザのUser-Agentをランダムに出力https://trunc.org/learning/http-flood-attack-ddos-analyzed
3. ウェブスクレイピングでUser-Agentを動的に変換し多様なユーザーリクエストを模倣https://packetstream.io/user-agent-rotation-in-web-scraping/
3. MSP業務で直面する問題
1. ログ分析の複雑性増加
ログを分析しながら実際に直面する問題は内容の複雑性だと思います。
例えばブラウザスニッフィングを避けるために曖昧なUser-Agentを残す事例を挙げることができます。
どのブラウザを使用しているか確認するブラウザスニッフィングという技法があります。
代表的にChrome以外のブラウザでGoogleにアクセスすると「Chromeをインストールしてください」
という文章を表示するなどマーケティングや、
特定のブラウザのみ使用してアクセスできるよう遮断を目的として使用されます。
しかしこれを避けるために曖昧なUser-Agentを残す事例がときどき見られます。
以下のようなログを残す事例ですが、
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
一つの文字列にMozilla、WebKit、Chrome、Safariが全て入っておりますが、
実際に使用したブラウザはChromeブラウザでした。
このように正確なブラウザ把握を困難にしてくる場合もあり、
ログを分析する立場では困惑する状況です。
2. 迅速な判断の圧迫
ZmEuやurllib等の明示的なツールも今では一般的なブラウザ「Mozilla/5.0」等に
スプーフィングしてリクエストする事例が多く増えました。
これにより正常なユーザーの間に深く隠れて入ったため、
どのような行動をしているか綿密に調べる必要があることに伴い、迅速な判断が困難になりました。
毎日多様なお客様のサーバーを確認し、迅速に原因把握をして解決策を立てて
お客様にご連絡しなければならない私は、迅速に判断できる「対応戦略」を立てる必要がありました。
4. 対応戦略
1. 行動ベース分析
行動パターンを確認し、正常な行動なのかそうでないかを判断します。
a. 時間帯別接続パターン
・ 早朝時間帯大量接続
・正常なユーザーは早朝時間帯に1000回以上のリクエストを行わないであろうという仮定の下で
疑い順位を上げて対応します。
b. ページ探索経路
・ サイトごとに異なると思いますが、ショッピングサイトなら以下のように例示できます。
・正常ユーザー: メイン → カテゴリ → 商品 → ショッピングカート
・ボット: 無作為、Sitemapを基盤とした行動
c. セッション持続時間と活動量
・ 正常ユーザー: ページローディング後に読む時間、スクロール、クリックの間隔の存在
・ ボット: 一定間隔でリクエストするか非常に速い速度でリクエスト
d. 同一IPから多重セッション存在有無確認
・ 一つのIPから多様なUser-Agentで接続した履歴があれば疑い順位を上げて対応します。
・ ただし一つのルーターを通じて複数のデバイスを使用する場合が多いので注意が必要です。
2. User-Agent以外の他の指標による分析
単純にUser-Agentのみを見るのではなく、IP評判、GETパターン、HTTPヘッダー整合性等を
総合的に確認します。
a. IP評判
・ abuseIPDBのようなIP評判サイトを通じて主にどのような攻撃が行われたか把握します。
https://www.abuseipdb.com/
b. GETパターン
・ 正常パターン: “/”, “/products”, “/product/1234”, “/cart”
・ スキャンパターン: “/admin”, “/wp-admin”, “/.env”, “/config.php”
・ 組合せ分析: スキャンパターン + スプーフィングされたUser-Agent = 悪意的なリクエスト
c. hostname確認
・ hostnameを相互検証して公式クローラーなのか確認します。
// hostname確認
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
// 逆方向確認
host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1
d. その他多様な手段と指標を活用して悪意的なリクエストを検出します。
3. セキュリティソリューション導入
IDS、IPS、WAF等があり、攻撃が頻繁で機密情報を持つサーバーなら導入を検討してみることができます。
人間が見落とす可能性がある部分まで見つけ出して迅速に対応するため、
MSPの最高の補助手段だと思っております。
弊社ネットアシストでも該当サービスを提供中でございますので、
お気軽にお問合せいただけたらと存じます。
結論: User-Agentはパズルの一片に過ぎない。
アクセスログを分析する際、User-Agentは有用な指標ですが、これだけでは精巧な攻撃を検出して防御することは困難です。
User-Agentはパズルの一片に過ぎず、全体的な絵を見るためにはもっと精巧で多層的なアプローチ方式が必要だと思います。
これがMSPがお客様に真の価値を提供できる道だと思います。





