【ITニュース解説】111 and 2049: RPC and NFS Endpoints in an Internet-Facing Population

システムエンジニアを目指す皆さんにとって、ネットワークの安全性は非常に重要なテーマだ。特に、インターネット上に公開してはいけないサービスが誤って公開されてしまうと、深刻な情報漏洩やシステム侵害につながる可能性がある。この記事では、本来プライベートなネットワーク内で利用されることを想定していたにもかかわらず、インターネットにさらされてしまっている危険なサービスについて解説する。

まず理解すべきは、「プロトコル」という概念だ。これはコンピューター同士が通信する際の「お約束事」や「ルール」だと考えればよい。世の中には、インターネット全体で利用されることを前提としたプロトコルもあれば、特定の限られた、つまり「信頼できる」ネットワークの中でだけ利用されることを前提としたプロトコルも存在する。

「Portmapper（ポートマッパー）」や「NFS（Network File System）」は後者の代表例だ。NFSはネットワークを介してファイルを共有するためのプロトコルで、まるで自分のコンピューターのディスクのように遠隔地のファイルを扱える便利なものだ。PortmapperはそのNFSなどのサービスがどのポート番号（通信の窓口）を使っているかを教えてくれる役割を担う。これらのプロトコルは、本来、企業や組織の「データセンター」と呼ばれるサーバーが集中する場所や、社内ネットワークのような「プライベートネットワーク」内で使われることを想定して設計されてきた。そのため、利用するコンピューターのIPアドレスなどでアクセスを制限する「ホストベースのアクセス制御」を主なセキュリティ手段としており、インターネット上の不特定多数からの接続に耐えるような「認証」（IDとパスワードなどで本人確認を行う仕組み）の機能が十分でなかったり、デフォルトでは無効になっていたりすることが多い。つまり、これらのサービスは「このネットワーク内にあるコンピューターはすべて信頼できる」という前提で動いているため、インターネットのような信頼できない場所からアクセスされることは「あってはならない」事態なのだ。

しかし、残念ながら実際には多くのこのようなサービスがインターネットに公開されてしまっている。最近の調査によると、2026年9月25日に「ZoomEye SDK」というツールを使ってインターネット上のサービスをスキャンした結果、以下のような非常に多くの危険なサービスがインターネットからアクセス可能な状態で見つかった。

• ポート番号「6379」（Redis）：約490万件
• ポート番号「11211」（memcached）：約110万件
• ポート番号「2379」（etcd client API）：約150万件
• ポート番号「8500」（Consul HTTP API）：約170万件

これらの数字は、そのポート番号で何らかのサービスが「リッスン」（通信を待ち受けている）しており、インターネットから「到達可能」であることを示している。

では、これらの特定のポート番号のサービスがインターネットに公開されると何が問題なのだろうか。

「Redis（レディス）」と「memcached（ミームキャッシュド）」は、どちらも「キャッシュ」と呼ばれる一時的なデータを高速に保存・取得するためのサービスだ。ウェブサイトやアプリケーションの表示を速くするために広く利用されている。しかし、これらのサービスは歴史的に、デフォルト設定で「認証なし」で接続を受け入れてしまうことが多かった。もしインターネットから認証なしでアクセスできる状態になっていれば、第三者がキャッシュされているデータ（ユーザー情報、セッション情報など）を盗み見たり、場合によっては悪意のあるコードを実行させたりする経路として悪用される可能性もある。

「etcd（エトシーディー）」は、特に「Kubernetes（クバネティス）」のようなコンテナ管理システムにおいて、クラスタ全体の「状態」や「設定情報」を保存する非常に重要なサービスだ。このetcdのクライアントAPI（アプリケーションがetcdとやり取りするための窓口）がインターネットに公開されてしまうと、Kubernetesクラスタに保存されているパスワードやAPIキーなどの「機密情報」が漏洩する恐れがある。

「Consul（コンサル）」は、分散システムにおける「サービスカタログ」（どのサービスがどこで動いているかの一覧）や「キーバリューストア」（シンプルなデータ保存庫）を提供するサービスだ。これがインターネットに公開されると、システム内部の構成情報や、設定によっては重要なデータが第三者に筒抜けになってしまう可能性がある。

これらすべてのサービスに共通しているのは、「信頼されたネットワーク内での利用」という前提で設計されている点だ。インターネットという信頼できない環境に晒されると、その前提が崩れ、設計段階では想定していなかったセキュリティ上のリスクが露呈してしまうのだ。

ただし、これらの測定は「ポートベースのカウント」であり、必ずしもそのサービスが「Redis」や「memcached」といった特定の製品であると断定できるわけではない点には注意が必要だ。単にそのポート番号で何らかのサービスが動いている、という事実を示しているに過ぎない。中には、攻撃者を誘い込むための「ハニーポット」と呼ばれる偽のサービスが含まれている可能性もあるし、別の用途で同じポート番号を使っている場合もある。そのため、これらの数字が「数百万の組織がすでに侵害されている」ことを意味するわけではない。しかし、「信頼されたネットワーク」という前提が広く無視されている、または誤って設定されている現実を示していることは間違いない。

システムエンジニアを目指す皆さんにとって、このような状況を踏まえ、自分の管理するシステムや構築するシステムで何をすべきか、具体的な対策を理解しておくことは非常に重要だ。

まず最も重要なのは、自社のシステムでこれらのポート（6379, 11211, 2379, 8500など）が「信頼できないネットワーク」、つまりインターネットからアクセス可能になっていないかを「確認」することだ。もしアクセス可能な状態であれば、まず「そのアクセス経路自体を遮断する」ことを優先すべきだ。認証機能を追加するよりも、インターネットから全くアクセスできない状態にする方が根本的な解決策となる。

もし、やむを得ない事情でキャッシュサービスや連携サービスをインターネットからアクセス可能にしなければならない場合は、必ず「認証機能を有効にする」ことを確認する。そして、IDやパスワードなしで管理コマンドを実行できてしまうような「匿名での管理コマンド」が許可されていないかを厳しくチェックする必要がある。

さらに、etcdやConsulのようなクラスタの状態を保存する場所やキーバリューストアに、パスワードやAPIキーなどの「機密情報」が保存されていないかを確認するのも重要だ。これらの情報が保存されている場合、もしAPIが公開されてしまえば、単に情報が漏れるだけでなく、システム全体が乗っ取られるような深刻な被害につながる可能性があるからだ。

今回のニュースは、インターネットにサービスを公開する際には、そのサービスがどのような設計思想で作られているのか、どのようなセキュリティ前提を持っているのかを深く理解する必要があることを教えてくれている。安易な公開や設定ミスが、取り返しのつかない事態を招く可能性があることを常に意識し、適切なセキュリティ対策を講じることが、未来のシステムエンジニアには不可欠な能力となるだろう。