【ITニュース解説】12,241 LXD Fingerprints, 15 for Incus, and the Same Question About Who Can Create a Container

「コンテナ」や「仮想マシン」といった技術は、今日のITシステムを支える重要な基盤だ。これらを動かすための「司令塔」のような役割を果たすのが、「コントロールプレーン」と呼ばれるソフトウェアで、LXDやIncusといったツールがその代表例となる。これらのツールは、コンピュータの物理的なハードウェア（システムエンジニアの世界では「ベアメタル」と呼ばれることもある）に非常に近い場所で動作し、コンテナなどの「インスタンス」を作成したり管理したりする強力な権限を持っている。つまり、これらのツールを使ってインスタンスを作成できるユーザーは、単にアプリケーションを使っている人ではなく、そのコンピュータのインフラそのものを直接操作できる「テナント」のような存在であり、コンピュータの心臓部であるカーネルが許可するあらゆる操作が可能になる、ということだ。

最近の調査によると、LXDやIncusといったコンテナ管理ツールのいくつかが、インターネット上に露出している実態が明らかになった。インターネット上の機器を探索する「ZoomEye」というツールを使って2026年10月28日に収集されたデータでは、「LXD」と識別されるサービスが12,241件検出され、そのうち11,685件は、LXDの管理インターフェースがデフォルトで利用するHTTPSポート8443で応答していた。一方、LXDから派生した新しいプロジェクトである「Incus」については、「app="Incus"」という識別子で検出されたのはわずか15件だったが、「title="Incus"」というウェブページのタイトルで検出されたものは359件に上り、そのうち257件はポート8443で応答していた。この数字の大きな違いは、それぞれのツールの「フィンガープリント」、つまりインターネット上のシステムを識別するための「指紋」のような情報が、どれだけ普及しているか、また新しいプロジェクトへの対応が追いついているかによって生じる。LXDは広く使われているため、専用のアプリ識別情報で多く検出される。しかしIncusのように新しく独立したプロジェクトの場合、まだ専用の識別情報が浸透しておらず、ウェブページのタイトルなど、より一般的な情報で検出されることが多い。これは、新しい技術を計測する際には、特定の「アプリシグネチャ」だけでなく、さまざまな角度からの情報を組み合わせて判断する必要があるという、計測全般における重要な教訓を示している。ただし、これらの数字は、その管理インターフェースが「認証」を必要としているかどうかまでは示していないことに注意が必要だ。

これらの管理インターフェースがインターネットに露出している状況は、深刻なセキュリティリスクを意味する。これらのツールは、API（Application Programming Interface）という仕組みを通じて操作される。APIは、ソフトウェア同士が通信するための「窓口」のようなもので、例えば「コンテナを作成する」という操作はHTTPのPOSTリクエストとして、「デバイスをコンテナに接続する」という操作はPUTリクエストとして実行される。さらに、稼働中のコンテナ内でコマンドを実行する機能も提供されており、これらはシステム管理者（オペレーター）がトラブルシューティングを行う際などに利用する正当な機能だ。しかし、これらの操作一つ一つは、呼び出し元が不適切な権限を持っていた場合、大きな問題を引き起こす可能性がある「特権」である。もし、認証されていない、つまり本人確認がされていない誰かが、これらのAPIにアクセスできてしまうと、単に「コンテナが勝手に作成される」といった事態にとどまらない。攻撃者は、コンテナをホストするコンピュータ上で直接コードを実行できるようになってしまう可能性があるのだ。コンテナが実行されるホストマシンは、通常、その内部で動くコンテナよりも高い権限を持っているため、ホストが乗っ取られると、その上に存在するすべてのコンテナ、そしてホストがアクセスできるすべてのデータやシステムが危険に晒される。コンテナのセキュリティにおける「コンテナエスケープ」という脆弱性カテゴリがあるが、これはコンテナの境界線が薄いことを悪用するものだ。しかし、今回のように管理インターフェースが外部に露出している場合、攻撃者はその境界線を「越える」必要すらなく、いきなりホストへのアクセス経路を手に入れてしまうことになりかねない。ポート8443で応答している11,685件のLXDインスタンスの多くは、この管理インターフェース自体をインターネットに晒している可能性があり、中には研究開発環境やテスト環境、あるいは誤ったファイアウォール設定が適用された本番環境も含まれているかもしれない。

このような危険を回避し、システムを安全に保つためには、いくつかの重要な確認事項がある。まず最も重要なのは、APIがリクエストを受け入れる前に「クライアント証明書」や「トラストトークン」といった認証メカニズムを要求するように設定されているか確認することだ。これらはLXDやIncusの機能として提供されているが、デフォルトで有効になっているわけではなく、システム管理者が明示的に設定する必要がある。次に、どのプロジェクトに誰がアクセスできるのか、そのアクセス権限を明確に把握し、列挙することだ。一人しか使わないホストと、複数のユーザーやテナントが共有するホストとでは、リスクの性質が大きく異なるため、ネットワーク図だけでなく、権限モデルに基づいてリスクを評価する必要がある。また、コントロールプレーンがどのネットワークインターフェースで接続を待ち受けているか、その「リスニングアドレス」を確認することも重要だ。VPN経由でしかアクセスできないプライベートなアドレスにバインドされている場合と、インターネットから直接アクセス可能なパブリックなアドレスにバインドされている場合とでは、セキュリティレベルが全く異なる。この二つは、「外部に露出しているか」という議論の際にしばしば混同されがちだが、明確に区別して考えるべきだ。最後に、そのコンテナホスト自体が、どこにアクセスできるのかを確認する。コンテナホストは、ネットワーク上の位置、ストレージへのアクセス権、そしてイメージレジストリからコンテナイメージをダウンロードするための認証情報など、多くの「特権」を持っている。コントロールプレーンが侵害された場合の影響範囲、つまり「爆発半径」は、コンテナが実行している内容ではなく、ホスト自身の権限によって決まるため、この点も念入りに確認する必要がある。

今回検出されたLXDの12,241件やIncusの15件といった数字は、ウェブフレームワークが持つ数十万という数に比べれば少なく見えるかもしれない。しかし、これらはインフラ管理ツールであり、デプロイされる数は少ないものの、それぞれが持つ権限は非常に大きい、というインフラツールの特性を考えれば、この規模は適切だと言える。この少ない数字を「大したことない」と軽視してはならない。むしろ、これらのシステムこそ、たった一つの設定ミスが「インターネットからアクセス可能」という状態から「ホスト上で不正なコードが実行される」という最悪の事態へと最短経路でつながる可能性を秘めていることを認識すべきなのだ。このような計測は、低コストで実施でき、かつその結果に基づいてすぐに行動を起こす価値がある。なぜなら、行動を起こさない選択は、誰も中身を確認していないネットワークルールを盲目的に信頼することに等しいからだ。