【ITニュース解説】Finding Affected NGINX Hosts at Scale: What 313 Million Fingerprinted Assets Do and Do Not Tell You

最近、Webサーバーとして広く利用されている「NGINX（エンジンエックス）」に、複数のセキュリティ上の弱点、つまり「脆弱性」が見つかった。このニュース記事は、そうした脆弱性が発見された際に、私たちがどのようにして影響を受けるシステムを特定し、対処すべきかについて深く掘り下げて解説している。特に重要なのは、今回見つかった5つの脆弱性すべてが、NGINXの「設定（コンフィグレーション）」に依存するという点だ。つまり、ただNGINXを動かしているだけでは脆弱ではない場合があり、特定の「設定ディレクティブ」という命令が有効になっているかどうかで、危険性が変わってくる。そのため、脆弱なシステムを特定する作業は、単にパッチを適用するよりも複雑になる。

まず、インターネット上にどれだけのNGINXサーバーが存在するのかという「露出（Exposure）」の数字について考えてみよう。記事では、インターネット上のデバイスを検索できる「ZoomEye」というツールを使って「NGINXを使っている」と判断された資産が3億1300万台以上あると報告されている。この数字は非常に大きく、一見するとこれだけの数のNGINXサーバーがすべて危険にさらされているように思えるかもしれない。しかし、これは単に「NGINXというソフトウェアが動いている」と特定されたサーバーの総数であり、「実際に脆弱性を抱えているサーバー」の数ではない。この区別は非常に重要で、初心者はこの大きな数字に惑わされないように注意が必要だ。

なぜなら、前述したように今回の脆弱性は、すべて特定の「設定ディレクティブ」が有効になっている場合にのみ影響を受けるからだ。例えば、HTTP/3という通信プロトコルに関する脆弱性は、そのプロトコルを受け入れる設定（リスナー）が有効になっている場合にのみ問題となる。もしサーバーがNGINXを使っていたとしても、これらの特定の条件を満たす設定がされていなければ、脆弱性の影響は受けない。また、CVE（Common Vulnerabilities and Exposures）識別子という、脆弱性につけられる共通の番号で検索しても、今回の脆弱性についてはまだ結果が出てこない。これは、脆弱性が発表されたばかりで、データベースに情報が反映されていないためだが、このような状況では、製品の「フィンガープリント」や「設定内容」を分析することが、脆弱なサーバーを見つける上で不可欠となる。

「フィンガープリント」とは、サーバーがどのようなソフトウェアを動かしているかを識別するための痕跡や特徴のことだ。NGINXのフィンガープリントは、そのサーバーがNGINXを動かしていることを教えてくれる。さらに、一部のNGINXフィンガープリントは、HTTPレスポンスヘッダーの「Server」フィールドに具体的なバージョン情報を含んでいることがある。このバージョン情報がわかれば、どのバージョンのNGINXが稼働しているかを確認でき、パッチが適用されているかどうかを判断する手がかりになる。しかし、セキュリティ対策として、このバージョン情報を隠しているサーバーも多い。その場合、フィンガープリントは「NGINXを使っている」ということしか教えてくれない。それでも、NGINXを使っているサーバーのリストを作成できるという点で、フィンガープリントは有用なツールだ。これは、脆弱性診断の範囲を絞り込むための「スコープツール」であり、そのサーバーが脆弱かどうかを決定する「評決」ではないという理解が大切だ。

NGINXのバージョンとパッチについても理解しておく必要がある。NGINXは通常、安定版とメインライン版という特定のブランチにのみセキュリティパッチを提供する。そのため、もしあなたが使っているNGINXのバージョンが古い（例えば1.28など）場合、公式のパッチパスからは外れてしまう。その場合でも、利用しているLinuxディストリビューションなどが、脆弱性の修正を古いバージョンにも適用する「バックポート」を行っていれば問題ないが、そうでなければ自分で対応する必要がある。今回の5つの脆弱性に対するパッチは、バージョン1.30.6と1.31.7で提供されている。各脆弱性によって影響を受けるバージョンの範囲は異なるため、公式のアドバイザリで詳細を確認することが重要だ。

では、実際にどうすれば脆弱なシステムを特定し、対処できるのだろうか。そのための実用的なワークフローは3つのステップから構成される。 まず第一に、NGINXのフィンガープリントが確認されたサーバーを洗い出し、それらを「候補」としてリストアップする。 次に、この候補リストと、組織内の「設定管理システム」を連携させ、それぞれのサーバーで「nginx -T」というコマンドを実行してNGINXの詳しい設定内容を確認する。そして、その設定内容の中から、今回の5つの脆弱性が発動する「トリガーとなる設定」が存在するかどうかを検索する。この2番目のステップが、最も価値があり、時間と労力をかけるべき部分だ。例えば、NGINXを動かしていても、特定の機能（ルート以外のSSI、共有セッションキャッシュ、QUICリスナーなど）を使っていなければ、ほとんどの脆弱性の影響は受けない。逆に、クライアント証明書を強制し、共有セッションキャッシュを使用しているリスナーを持つサーバーで、セッションキーが明示的に設定されていない場合は、特定の認証バイパス脆弱性にさらされている可能性があり、最優先で修正すべき対象となる。 最後に、2番目のステップで特定された、脆弱な設定を持つサーバーに対して、ソフトウェアのアップグレードを行うか、あるいは特定の回避策を適用して問題を修正する。

セキュリティに関する情報を報告する際には、「露出」と「確認された脆弱性」を混同しないように細心の注意が必要だ。3億1300万という数字をそのまま「脆弱なサーバーの数」として報道してしまうと、これは誤解を招く。正確な表現は、「非常に多くのインターネットに接続された資産がNGINXを動かしており、そのごく一部の、しかし特定されていないサブセットが、影響を受けるバージョンと脆弱性を引き起こす設定ディレクティブを組み合わせて使用している」ということになる。この区別を曖昧にしてしまうと、実際には脆弱ではないサーバーの危険性を過大に伝え、本当に緊急性の高い、ごく少数の脆弱なサーバーへの対応が遅れるという、二重の失敗を招くことになるからだ。

最終的に、個々のサーバーが脆弱であるかどうかを確認するための最も確実な方法は、そのサーバー上で「nginx -T」コマンドを実行することだ。このコマンドは、NGINXのすべての設定を表示する。その出力内容を詳しく確認することで、5つの脆弱性がそれぞれ依存する「前提条件となる設定」が存在するかどうかを判断できる。フィンガープリントは、この重要な「nginx -T」コマンドを、どのサーバーで実行すべきかを教えてくれる、最初の目印となるのだ。