ONU(Optical Network Unit)とは、光回線の終端に設置される装置で、多くの家庭ではルータ機能を内蔵した一体型がISPから提供されています。
ある日、インターネットが止まった
ある日、自宅のインターネットが突然使えなくなりました。 通信回復までは以下のような流れでした。
スマートフォンのWiFiアイコンは接続中を表示。しかし、どのサイトにもアクセスできない。ルータの管理画面(192.168.1.1)すらWiFi経由では開けない状況。有線LANケーブルでPCを直接接続してみると、管理画面には入れる。ステータスを確認すると、WAN側の受信バイト数が「0」——つまり、インターネット側からのデータが一切届いていない状態であった。管理画面から再起動を実行すると、約10分後に通信は回復した。
これだけなら「たまにある不具合」で済む話かもしれません。しかし、調査を進めていくうちに、このONUの中身に驚くべき事実が見えてきました。
ONUの先は「戦場」である
話を進める前に、そもそもONUが接続している「インターネット」がどういう場所なのかを知っておく必要があります。
ほとんどの家庭用ONUには、グローバルIPアドレスが割り当てられています。これは、世界中のどこからでも直接通信を試みることができるアドレスです。そして実際に、世界中から通信が来ています。
現在のインターネットでは、IPv4アドレスの全空間(約43億個)を数分から数十時間でスキャンすることが技術的に可能です。masscanやzmapといったツールを使えば、一台のサーバーから毎秒数百万パケットを送信し、インターネット上のすべてのIPアドレスに対して特定のポートが開いているかを調べられます。
これは理論上の話ではありません。実際に、こうしたスキャンは24時間365日、絶え間なく行われています。
Shodan、Censys、ZoomEyeといった検索エンジンは、インターネットに接続されたすべての機器を常時インデクシングしています。あなたの家のONUも、すでにこれらのデータベースに登録されている可能性が高いです。どのポートが開いているか、どんなサービスが動いているか、どのメーカーの機器かといった情報が、誰でも検索できる状態で公開されています。
さらに深刻なのは、ボットネットによる自動化された侵入試行です。Mirai系をはじめとするマルウェアに感染した機器は、新たな標的を求めて常にインターネットをスキャンしています。グローバルIPアドレスを持つ機器は、接続した瞬間から数分以内にスキャンを受け始めます。SSH(22番ポート)、Telnet(23番ポート)、HTTP(80番ポート)など、よく知られたポートには、デフォルトパスワードでのログイン試行が1日に数百回から数千回規模で行われています。
弊社が業務で管理しているサーバー群でも、1台あたり1日に数百件のブルートフォース攻撃を観測しています。攻撃元はアジア太平洋地域、ヨーロッパ、中東、南米と文字通り世界中に分布しており、その大半は感染した機器による自動的な攻撃です。紛争でインフラが停止しているはずの地域からも攻撃が届きます。ボットネットは人間の事情とは無関係に、自動的に動き続けるからです。
つまり、あなたの家のONUは、回線を契約してインターネットに接続した瞬間から、世界中の攻撃者やボットネットに対して「見える」状態に置かれています。ONUの先にあるのは、便利なウェブサービスの世界だけではありません。それは同時に、自動化された攻撃が常時飛び交う、ある意味での戦場でもあるのです。
そして、その戦場との境界に立っているのが、あなたの家のONUです。
このルータは2024年に提供が開始された新しい機種のはずだった
問題のONUは、ある大手ISPが2024年5月頃から提供を開始したA社製のONU一体型ルータです。GPON対応、WiFi 6、2.5GbEポート搭載と、スペック上は最新世代の機器です。
このONUの管理画面を辿ると、「情報表示」→「GNU General Public License (GPL)」というページがあり、使用しているオープンソースソフトウェアの名称、バージョン、ライセンス情報が一覧で公開されています。GPLなどのライセンス義務に基づく開示で、誰でも確認できる情報です。
そこに並んでいたバージョン番号を見て、目を疑いました。
10年前のソフトウェアが動いている
以下は、このONUに搭載されている主要なオープンソースソフトウェアとそのバージョンです。
| ソフトウェア | 搭載バージョン | 初回リリース年 | 現在の状況 |
|---|---|---|---|
| Linux Kernel | 4.4.115 | 2016年 | サポート終了済 (2022年2月 EOL) |
| U-Boot | 2014.04-rc1 | 2014年 | 約10年前のブートローダー |
| OpenSSL | 1.1.1d | 2019年 | サポート終了済 (2023年9月 EOL) |
| curl | 7.48 | 2016年 | 後続バージョンで深刻度「高」を含む多数の修正(例: CVE-2023-38545) |
| BusyBox | 1.26.2 | 2016年 | 後続でセキュリティ修正が継続(搭載版との差分が大きい) |
| Dnsmasq | 2.81 | 2018年頃 | 後続で複数の重要なセキュリティ修正が入っている |
2024年に提供が始まった機器の中身が、実質的に2014年〜2019年のソフトウェアで構成されています。
問題は「古いこと」そのものではありません。更新状況が外部から検証できず、責任の所在も見えない点にあります。
なお、ここで一つ技術的な補足をしておきます。OSSのバージョンが古い、あるいはコミュニティのサポートが終了しているからといって、直ちに危険であるとは限りません。機器ベンダーが独自にセキュリティパッチをバックポート(新しいバージョンの修正を古いバージョンに適用)している場合があるからです。ただし、それがどの範囲まで適用されているかは外部からは確認する手段がありません。確認できないものを「安全」と信頼してよいのか、という問題は残ります。
個別のCVEがこの構成で実際に悪用可能(exploitable)かどうかは構成依存であり、一概には言えません。しかし、修正が適用されていない期間が長くなるほど攻撃面(attack surface)が広がる、というのがセキュリティ実務の基本的な感覚です。
Linux Kernel 4.4 — サポート終了済みのカーネル
Linux 4.4は2016年1月にリリースされたLTS(長期サポート)カーネルで、2022年2月に公式サポートを終了しています。Linuxカーネルの現在の安定版は6.x系です。カーネルはOSの根幹であり、権限管理、メモリ管理、ネットワークスタックのすべてを司ります。カーネルの脆弱性はシステム全体に波及するため、そのサポート状況は機器のセキュリティを左右する最も重要な要素の一つです。
OpenSSL 1.1.1d — サポート終了済みの暗号ライブラリ
OpenSSL 1.1.1dは2019年9月にリリースされたバージョンです。OpenSSL 1.1.1シリーズ自体が2023年9月にサポートを終了しています。OpenSSLはTLS/SSL通信の基盤であり、ルータの管理画面へのHTTPS接続、ファームウェア更新のダウンロード、さらにはIoTサービスとのクラウド接続など、あらゆる暗号化通信に使われます。サポート終了済みのOpenSSLは、新たに発見された脆弱性に対してコミュニティからの修正が提供されません。
curl 7.48 — 2016年のHTTPクライアント
curlはHTTP通信を行うライブラリで、ファームウェアの自動更新などに使用されます。バージョン7.48は2016年のリリースであり、その後のバージョンで多数のセキュリティ脆弱性が報告・修正されています。たとえば2023年に報告されたCVE-2023-38545は、curlのSOCKS5プロキシ処理におけるヒープバッファオーバーフローで、深刻度「高」と評価されました。7.48にこの特定の脆弱性が影響するかは構成次第ですが、7年分の修正が未適用であること自体がリスクの蓄積を意味します。
これは珍しいことではない——Miraiの教訓
組み込み機器のソフトウェアが古いまま放置されることの危険性は、すでに現実の大規模インシデントとして証明されています。
2016年、「Mirai」と呼ばれるマルウェアが、ルータ、IPカメラ、DVRなどのIoT機器を大量に乗っ取り、巨大なボットネットを構築しました。このボットネットはDNSプロバイダであるDyn社に対して大規模なDDoS攻撃を仕掛け、Twitter、Netflix、Redditなど多数の著名サービスが一時的にアクセス不能になりました。
Miraiが悪用したのは、デフォルトパスワードの放置や、古いファームウェアの脆弱性でした。攻撃者にとって、パッチの当たっていない機器は格好の標的です。
また、2021年にはRealtek製SoCのSDKに存在する脆弱性(CVE-2021-35394)が公開され、このSDKを採用した複数メーカーのルータが影響を受けました。これもまさにBSPに起因する脆弱性が、メーカーを横断して広がった事例です。
Miraiが示したのは、「個々の機器の弱さ」ではありません。更新されない機器がインターネットに常時接続されている——その構造そのものがリスクになる、という事実です。
前述の通り、インターネット上では常時自動スキャンが行われており、脆弱な機器は発見され次第、ボットネットに組み込まれていきます。あなたの家のONUが攻撃者に乗っ取られた場合、そのONUは被害者であると同時に、他の機器を攻撃する加害者にもなります。
今回確認したONUのソフトウェア構成が、こうした攻撃に対して十分な耐性を持っているかどうかは、外部からは判断できません。判断できないということ自体が、問題の本質なのかもしれません。
なぜ新しい機器に古いソフトウェアが入るのか
これはこの製品固有の問題ではなく、組み込み機器業界の構造的な問題です。
BSP(Board Support Package)依存
家庭用ルータやONUの心臓部には、通信用のSoC(System on Chip)が搭載されています。SoCメーカーは、チップとともにBSP(Board Support Package)と呼ばれるソフトウェア開発キットを提供します。BSPにはLinuxカーネル、ブートローダー、各種ドライバが含まれており、機器メーカーはこのBSPをベースにして製品を開発します。
問題は、SoCメーカーが提供するBSPのLinuxカーネルバージョンが、チップ開発時点のものに固定されていることです。たとえば、2014年頃に設計が始まったSoCのBSPには、当時のLinux 4.4系が含まれています。機器メーカーがカーネルを独自に新しいバージョンに差し替えることは技術的に極めて困難です。SoC固有のドライバやハードウェアアブストラクション層が動かなくなるからです。
多層構造が生む「触らない」力学
組み込み機器の開発は、以下のような多層構造になっています。
SoCメーカー → BSPを提供(カーネル、ドライバ)
↓
機器メーカー → BSP上にアプリケーションを開発
↓
ISP → ブランドを付けてユーザーに配布
各レイヤーで「動いているものは触らない」というインセンティブが働きます。SoCメーカーは新チップの開発に注力し、旧チップのBSPを最新カーネルに更新する動機がありません。機器メーカーは、個別ライブラリだけを更新するとビルドシステム全体が壊れるリスクがあり、膨大なテスト工数が必要になるため手を出しにくい状況です。ISPは安定稼働を最優先し、積極的な更新を求めません。
結果として、2024年に出荷される機器に2014年のブートローダーが載ったまま、という状況が生まれます。
あなたの家のONUも例外ではない
これはA社製ONU固有の問題ではありません。市場に出回っている家庭用ルータ・ONUの多くが、同様の古いソフトウェアスタックで動作していると考えられます。有名メーカーの製品であっても例外ではありません。
ISPから提供されるONUは、ユーザーが自分でファームウェアを更新することができません。更新はISP経由の自動配信に依存しており、いつ更新されるか、何が修正されるかはユーザーには分かりません。極端に言えば、自宅のネットワークの最も重要な機器について、ユーザーは一切の制御権を持っていないのです。
ではどう身を守るか
ONU=信頼境界という前提を疑う
多くの家庭では、ISPから提供されたONUがネットワークの唯一の出入口であり、暗黙のうちに「この内側は安全」という前提で運用されています。しかし、その前提は見直すべきです。
企業ネットワークでは「ネットワーク境界を信頼しない」というゼロトラストの考え方が浸透しつつあります。同じ考え方を家庭にも適用すべき時が来ているのではないでしょうか。
実践的な防衛策
以下は、個人として取りうる対策です。
1. ONU配下に自前のルータ/ファイアウォールを設置する
ONU配下に自前のルータを設置します。セキュリティ更新が定期的に行われ、かつユーザー自身でファームウェアを管理できる機器を選ぶことが重要です。ONU側のWiFi機能はオフにし、すべての端末は自前のルータ経由で接続します。これにより、仮にONUが侵害されても、内部ネットワークへの直接的な影響を緩和できます。
なお、ONU配下にルータを追加するとNATが二重になり、オンラインゲーム、VoIP、ポート開放、IPv6通信などに支障が出る場合があります。可能であればONU側をブリッジモード(またはIPv6パススルー)に設定し、自前ルータ側で回線を終端するのが望ましい構成です。ONU側の設定変更が難しい場合は、「二重NATでも困らない範囲」から始めて段階的に構成を見直すという現実的な進め方もあります。
2. ONU内蔵のWiFiを使わない
今回の障害で、ONU内蔵のWiFiモジュールはONU本体の障害に巻き込まれて管理画面すらアクセスできなくなることが分かりました。別途アクセスポイントを用意することで、ONU障害時の管理アクセス手段を確保できるだけでなく、WiFi部分のセキュリティも自分で管理できるようになります。
3. 重要な通信は端末間で暗号と認証を完結させる
ネットワーク機器を信頼しない前提に立つなら、重要な通信は「端末から端末まで」暗号化と認証を閉じることが原則になります。VPN、SSH、HTTPSの適切な運用がこれにあたります。経路上のどの機器が侵害されていても、通信内容が保護される状態を目指します。たとえば、自宅NASは外部に直接公開せず、外出先からはWireGuard等のVPNで自宅ネットワークに入ってからアクセスする、といった構成が具体例になります。
4. 端末側のセキュリティを強化する
ネットワーク機器を信頼できない以上、最終的な防衛線は各端末自身です。OSとアプリケーションのアップデートを怠らないこと、エンドポイントセキュリティを導入すること、不要なサービスのポートを閉じること——こうした基本対策の重要性がますます増しています。
セルフチェックリスト
最後に、今日からできる確認項目を挙げておきます。
- ONU管理画面にGPL/OSS一覧があるか確認し、主要ソフトウェアのバージョンを記録する
- ONU内蔵WiFiをOFFにし、自前のアクセスポイントに切り替える(または切り替えを検討する)
- ONU配下に自前ルータを設置した場合、二重NATの影響を把握する
- 管理画面のパスワードをデフォルトから変更し、リモート管理(WAN側からのアクセス)をOFFにする
- 重要な通信がVPN/SSH/HTTPSで端末間暗号化されているか確認する
「侵害されないこと」を前提にしない
私たちはこれまで、ISPから提供された機器を無条件に信頼してきました。電話会社が提供する電話機を疑わなかったのと同じ感覚で、ONUを信頼してきました。
しかし、電話機と違い、ONUは汎用的なLinuxが動作する小型コンピュータであり、常時インターネットに接続され、IoTクラウドサービスとも通信しています。その中身は公開情報から確認できる範囲だけでも、サポートの終了したOSとライブラリで構成されています。そしてその機器は、世界中からの自動スキャンと侵入試行に24時間さらされ続けています。
これは特定のメーカーやISPの怠慢という話ではありません。半導体のサプライチェーンからソフトウェア開発、通信事業の構造に至るまで、業界全体が抱える構造的な課題です。
そして、この課題から導かれる設計思想の転換があります。
更新できないデバイスが存在することを前提に、防御を設計する。「侵害されないこと」を前提にするのではなく、「侵害されても被害が拡大しない」構造をつくること。各端末やプロセスが、ネットワーク機器の信頼性に依存せず、自分自身のランタイムの安定性を自分で守る——こうした考え方は「Runtime Stability(ランタイム安定性)」と呼ばれ、これからのIoT時代に求められる防御モデルの核になるものだと弊社は考えています。
あなたの家のONUの管理画面にも、おそらく同じようなオープンソース一覧のページがあります。一度確認してみてください。そこに並んでいるバージョン番号が、あなたのネットワークの信頼性を物語っているはずです。
*弊社は、ランタイムセキュリティの上位概念であるランタイムスタビリティの研究・開発に従事しています。「更新できないデバイスをどう守るか」という課題は、IoTセキュリティの根幹に関わるテーマです。本記事は特定の製品やメーカーを批判する意図はなく、業界全体の構造的課題について問題提起するものです。*