MBSD-SOCでは様々な分析結果を元に、みなさまの役に立つ情報を配信していきたいと考えています。

今回はMBSD-SOCで観測したアラート(※)において、HTTP(S)のリクエスト時に使用されるHostヘッダに着目しアラートの傾向を分析してみました。
この考察から、セキュリティ対策として一定の効果があると想定される対応や、クラウドWAFを使用する際の注意点について解説していきます。
(※MBSD-SOCが攻撃または正規でないと判断したリクエスト。SOCで把握しているセキュリティ診断によるリクエストを除く。)

FQDNとIPアドレス直接指定によるリクエストの違い

Webサイトを利用する際、FQDNでアクセス先を指定することがほとんどかと思います。
例えば、ブラウザのURL欄にwww.example.comと入力してアクセスした場合、リクエストのHostヘッダは「Host: www.example.com」となります。

図1 Webサーバへの一般的なリクエスト例

一方で、例としてwww.example.comを名前解決したIPアドレスが198.51.100.1だとすると、このWebサイトにIPアドレスを直接指定してアクセスした場合、Hostヘッダが「Host: 198.51.100.1」のようになります。

また、IPアドレスを直接指定してHTTPSでアクセスした場合、証明書の検証に失敗してしまいますので、図2のようにブラウザに警告メッセージが表示されます。

図2 Microsoft Edgeの警告メッセージ例

よって、一般的なWebサイトであれば、サイト利用者による正規なリクエストはFQDNでのアクセスとなるはずです。
(もちろん、システムのモニタリングやAPI連携など、IPアドレスを指定した正規な通信もあるかと思います。)

アラートの傾向

図3は、ある期間にMBSD-SOCで観測したHTTP(S)リクエストによるアラートを、Hostヘッダの指定方法ごとに集計した結果です。

図3 Hostヘッダ指定方法の割合

アラートの約3割がIPアドレスを直接指定したリクエストであるという傾向が見受けられました。
FQDN・IPアドレス直接指定の他に、Hostヘッダに攻撃文字列をセットしたリクエストも一定数観測しています。

表1はMBSD-SOCで観測したアラートのうち、IPアドレス直接指定によるリクエストで検知したアラートを簡易的に分類し、集計した結果です。

表1 攻撃タイプごとの割合

最も割合の多い「特定の脆弱性を狙った攻撃」は、該当製品の使用有無に関わらず無差別的(バラマキ)に攻撃してきているケースを多く観測しています。「隠しファイルやパスへのアクセス試行」「IoTデバイスへの攻撃」にも同様の傾向があります。
(当然、事前に外部公開システムを検索できるサービスなどを使い、ターゲットを絞ってから攻撃してくるケースもあるものと想定されます。)

IPv4インターネットの世界には、ざっくり約43億個のグローバルIPアドレスがあります。
この43億という数はツールを使用することにより現実的なコスト(所要時間)でスキャンすることが可能と言われています。

IPアドレスをスイープ(総なめ)して無差別的に攻撃リクエストを投げてきたり、スキャンをかけてきたり、ボットネットの感染拡大を試行してくるという傾向は上記の集計結果からも読み取れるかと思います。

取り得る対応

以上のことから、全ての環境に当てはまるとは限りませんが、Webアプリケーションに対するIPアドレス直接指定によるリクエストを拒否することで、不審なリクエスト(攻撃を含む)を軽減する一定の効果があると考えられます。
その他にも、以下の観点でメリットがあると考えられます。

• IDS/IPSやWAFを運用している環境の場合、アラート確認の手間を削減できる。
• リクエストやレスポンス処理にかかるサーバリソースの無駄な消費を軽減できる。

WebサーバやWAF・ロードバランサなどのアプライアンスでIPアドレス直接指定によるリクエストを拒否(ブロック)する設定を検討するのはいかがでしょうか？

クラウドWAFの構成

ここまでの考察を以って、視点をクラウド型のWAF (CDN) に移します。

クラウドWAFでは、アクセスするWebサーバのFQDNをクラウドWAFのIPアドレスに名前解決させて、リクエストをクラウドWAFに向けるリバースプロキシ型の構成が多くなっています。

当社ブログのWAF解説の記事でも触れましたが、一般的に、クラウドWAFはHostヘッダにて指定されたFQDNでリクエスト転送先となるオリジンサーバを識別するため、クラウドWAFのIPアドレスを直接指定してリクエストをしても、オリジンサーバへのリクエストはできません。

図4 クラウドWAF構成例

つまり、このような構成のクラウドWAFを導入すると、副次的な効果として、IPアドレスを直接指定したリクエストをブロックすることができます。しかし、それでも注意が必要な点があります。

図5 クラウドフレアでのブロック例

クラウドWAF利用時の注意点と対策

1点目は、本記事前半で紹介したIPv4インターネットの世界における無差別的な攻撃が、WAFを経由せずにオリジンサーバに直接着弾してしまうケースです。そして2点目は、FQDNに紐づくオリジンサーバのグローバルIPが何らかの形で特定されてしまい、WAFを迂回してオリジンサーバが直接攻撃を受けてしまうという点です。

図6 クラウドWAFのバイパスイメージ

クラウドWAF (CDN) の裏に隠れたオリジンサーバのIPを探す手法として、DNSの履歴を確認できるサービスやサーバ証明書の情報を検索することなどが挙げられます。

具体的な手法については当記事では触れませんが、手法について言及する記事/研究が検索エンジンで簡単にヒットしますし、オープンソースのインテリジェンスやGitHubなどで公開されているツール類を使うことで、一定の知識を持つ人であれば費用をかけず容易にできてしまうものと想定されます。

この課題に対するシンプルな対策は、オリジンサーバへのリクエストをクラウドWAF (CDN) からのリクエストに限定することです。

クラウドWAFベンダはExternal IPのリストを公開していますので、オリジンサーバのシステム側のファイアウォールやアクセスリストなどでアクセス制御をすることを推奨します。

図7 オリジン直接アクセスの拒否例

なお、MBSD-SOCがマネージドセキュリティサービスを提供しているクラウドフレアWAFでは、こちら(https://www.cloudflare.com/ja-jp/ips/) でIPリストが公開されています。
クラウドサービスはサービス開発のペースが早いので、IPリストの更新状況を定期的に確認することをおすすめします。

まとめ

本記事後半の内容は、クラウドWAFやCDNの運用に慣れている方には当然の内容かもしれませんが、"クラウドWAFを入れた安心感" や "機器の管理担当者が違う" などにより、見落としやすいポイントとも思われます。

クラウドWAF (CDN) をご利用の方は、改めてオリジンサーバ側のネットワーク構成を再確認してみてはいかがでしょうか？