ハクソク

世界を動かす技術を、日本語で。

テレネットが消えた日

104日前原文(labs.greynoise.io)

概要

  • 2026年1月14日、 世界的なTelnetトラフィックの急減 が観測された事象
  • CVE-2026-24061 （Telnetの認証バイパス脆弱性）公開直前の出来事
  • 北米Tier 1トランジットプロバイダー によるポート23フィルタ導入の可能性
  • 脆弱性公開とトラフィック減少の 因果関係の推察
  • Telnet利用環境の 今後の実務的影響 と対応策

Telnetトラフィック消失の前兆と背景

  • 2025年12月1日から2026年1月14日まで、 GreyNoise は1日平均約91万4,000件の非スプーフ可能なTelnetセッションを観測
  • 2026年1月14日21:00 UTC、 1時間で65%減少 し、2時間後には83%減少、以降も低水準で推移
  • この急激な減少は ルーティングインフラの構成変更 を示唆、単なるスキャン行動の変化ではない
  • 18のASN（例：Vultr, Cox, Charter, BTなど）が 完全にTelnetトラフィックを喪失
  • ジンバブエ、ウクライナ、カナダ、ポーランド、エジプトの 5カ国からのTelnetトラフィックが消滅
  • AWSやContaboなど クラウドプロバイダーは影響を受けず、逆に増加傾向

フィルタリングの実態と影響範囲

  • 北米Tier 1トランジットプロバイダーによるポート23フィルタ導入 の可能性
  • 米国時間16:00（UTC21:00）という メンテナンスウィンドウ に一致
  • 米国大手ISP（Cox, Charter, Comcast等）は大打撃、クラウドはIXPのプライベートピアリングで回避
  • Verizon/UUNET（AS701）は 79%減少、Tier 1バックボーンとしてフィルタ実施または直上流の可能性
  • トランジット依存度の高い国（米国経由の国）は甚大な影響、欧州ピアリング強い国（フランス、ドイツ等）は無傷
  • 中国のバックボーン（China Telecom, China Unicom）は 均等に約59%減少、米国側フィルタの示唆

CVE-2026-24061と時系列

  • CVE-2026-24061 はGNU Inetutils telnetdの認証バイパス脆弱性（CVSS 9.8）
  • 攻撃者が -f root をユーザー名として送信すると認証不要でrootシェル取得
  • 脆弱コードは2015年に導入、 11年間未発見
  • 主な時系列
    • 1月14日21:00 UTC：Telnetトラフィック急減
    • 1月20日：脆弱性アドバイザリ公開
    • 1月21日：NVD登録・初の悪用観測
    • 1月22日：GreyNoiseによる初動レポート
    • 1月26日：CISA KEVカタログ追加

フィルタ導入とCVE公開の関係仮説

  • 脆弱性公開前に インフラレベルでの対応（ポート23フィルタ）が行われた 可能性
    • 事前通知を受けた事業者が 先行して対策 した推察
  • フィルタの特徴
    • ポート23/TCPのみ対象
    • トランジット依存経路のみ影響、ダイレクトピアリング経路は無傷
    • 数週間経過後も 持続的にフィルタ継続
  • 偶然の可能性も否定できないが、 時系列・影響範囲・技術的合理性 から「関連性あり」と推察

Telnetトラフィックの現状と傾向

  • 1月14日以降は 周期的なスパイクと落ち込み（のこぎり型パターン） が観測
  • 週平均セッション数
    • 12月第1週：108万6,744件（119%）
    • 1月第2週：98万5,699件（108%）
    • 1月第3週：36万3,184件（40%）
    • 2月第1週：32万2,606件（35%）
  • 事前水準の約1/3で推移し、やや減少傾向

実務的インプリケーションと推奨対応

  • GNU Inetutils telnetd を利用中の場合、 2.7-2以降へアップデート またはサービス無効化を推奨
  • CISA KEVの 連邦機関向け対応期限は2026年2月16日
  • 公開後数時間で 悪用試行を観測、2月上旬に1日2,600セッションまで増加後減少
  • ネットワーク運用者は 境界でポート23フィルタ を検討、業界全体の流れ
  • Tier 1バックボーンがTelnetを運ばない判断 をした可能性、今後の標準化も視野

まとめ

  • Telnetトラフィック激減と重大脆弱性公開 がほぼ同時期に発生
  • インフラ事業者による先行的な防御策 の可能性が高い
  • Telnetは 歴史的役割を終えつつあるプロトコル、今後の利用縮小が加速
  • 詳細情報や実際に対応した関係者からの情報提供を research@greynoise.io で募集中

Hackerたちの意見

インターネットのトランジットインフラのかなり大きな部分の上流で、誰かがテレネットトラフィックはもう運ぶ価値がないと判断したみたい。多分、それは正しい判断だね。これってMUDのトラフィックに影響あるのかな？いくつかのMUDは非標準のテレネットポートで動いてるけど、まだポート23での接続を許可してるところも多いよね。これはエンドツーエンドのテレネットトラフィックをブロックするの？それとも、バックボーンリレー自体のテレネットサービスへのアクセスを試みるのだけをブロックするの？

└

記事からははっきりしなかったけど、攻撃のためにフィルタリングしてると思った。テレネットは完全にプレーンテキストだから、簡単にできるよね？

└

ほとんどのMUDはテレネットを使ってないよ。MUDは、幅広いクライアントがアクセスできるプレーンテキストTCPプロトコルを使ってる。テレネットプロトコルはしっかり定義されてて、完全なプレーンテキストではない。インバンドシグナリングメソッドや交渉があるからね。テレネットはIANAのよく知られた特権ポートとして23/tcpで動くことが定義されてるけど、MUDはそんなことしてない。通常、テレネットクライアントを使ってMUDに接続できるけど、ほとんどのプレイヤーはその体験が嫌いで、専用のプログラム可能なクライアントを好むことが多いよ。MUDが高い4桁のポートを使ってるのは、標準化されたプロトコルや「よく知られたポート」の存在がない、特権のないユーザー運営のサーバーとしての始まりから来てるんだ。特にアクセスしづらいMUDにしたいなら、今ポート23で運営するのもアリだね！

└

住宅回線がSMTPポートをシャットオフするのと似たようなポートベースのブロックをしてるみたいだね。とはいえ、今の時代、公共ネットワークのサーバーはSSHを使うべきだと思うけど。

11年前に誰かがテレネットデーモンにバックドアを仕込んだんだって。誰がやったの？コミットはどこ？

└

バックドアじゃなくて、ただの非常に深刻なセキュリティバグだよ。でも、陰謀論やパラノイアにすぐ飛びつくのはおめでとう。

└

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...

└

テレネットはクリアテキストで、ずっとそうだったよ。バックドアはやりすぎな気がする。

└

バックドア それって意図的ってこと？なんでそう思うの？

なんで今の時代にまだ人々がインターネットでtelnetを使ってるんだろう？これって攻撃トラフィック全部なの？（まあ、古いトーカーの一人が使ってるのは知ってるけど、すごく非標準なポートだからポート23をブロックしても意味ないし。）

└

私の理解では、greynoiseはスキャナートラフィックを監視してるから、これらは全部スキャンか攻撃だね。

└

ASCIIでスター・ウォーズを見るために。telnet towel.blinkenlights.nl https://www.youtube.com/watch?v=Mhcf6tc2jeQ （これについて昔聞いたことがあるんだけど、調べたら1999年にSlashdotで見た気がする。今でも存在してる/動いてることを確認したよ。）

└

ハムたちは時々パケットラジオで使ってるよ。アマチュアバンドでは暗号化が禁止されてるからね。私の意見では、署名付きデータを送る良いtelnetの代替が必要だと思う。ほとんどの人は、FCCのルールの下で署名は許可されてると解釈してるけど、暗号化はダメなんだよね。

└

一つ？まだ全てのトーカーが使ってるし、MUDやMOOsなどはトーカーの数をはるかに上回ってるよ。

└

Aardwolf、俺の仕事用ノートパソコンでうまく動いてる。誰かに見られても気にしないし。

└

nethack.alt.org、まだtelnetサーバーを維持してるんだ！

└

telnetはレガシー、IoT、組み込み、低レベルの産業ハードウェアで使われてる。自動化がtelnet用に書かれてて、sshに切り替えるのが簡単じゃないデバイスでは意図的に有効にされてることもある。商業的に使われるsshのほとんどを調べると、セキュリティが無効化されてたり無視されてたりする。誰もホストキーを確認しないし、ホストがサイクルする自動化では、ホストキーが常に変わるから確認を無効にせざるを得ない。ホストキーの確認がなければ、他のことに意味がなくなる。仮にホストキーが確認されたとしても、一般的なsshの使い方は、長期間使える静的キーを使うか（ほとんどの人がパスワードを設定してない）、パスワードを使うかだ。2FAを使ってる人はほとんどいないし、一時的なキー（OIDC）や証明書を使ってる人もほとんどいない（多くの人がそれを間違える）。だから、実際の使い方から見ると、SSHは最も安全性の低い通信手段の一つだよ。OAuthでログインするHTTPSのウェブソケット上でtelnetを使った方がずっと安全だね。

└

このバグがこんなに長生きした理由の一つは、特権アクセスにはあまり使われなくなったからだと思う。でも、mooをしたり、ASCIIムービーを見せたりするためには使えるよね、下の人たちが返信してる間に。

└

Telnetを使って接続するDikuMUDを運営してるんだけど、もっと安全なオプションを使えるようにアップデートしないといけないな。

インターンの時、なぜかデスクにVoIP電話が支給されたんだ。ある日、退屈になってtelnetで接続できることに気づいた。特に面白いことはなかったけど、楽しい瞬間だったよ！

└

俺もやったわ、笑

└

ずーっと前、インターンの時にperlのcgiスクリプトを作ってて、よくtelnetでテストしてた。hayesコマンドをいじるのに慣れてたから、HTTPコマンドを手動で打つのは自然な延長みたいに感じたんだ。

Cが責められないのはいいね！…ただの古い論理不足（これがCのコードベースの欠点の大部分だと思うけど、同意するよ）。

└

DNSじゃないよ！

このCVEの範囲とそれに対する反応は本当にすごい。ある人がtelnet時代をこんなに決定的に終わらせる責任を一手に負ってるなんて、考えただけでクレイジーだよ。歴史に残る話だね。

└

ある人が一手に責任を負ってる まぁ、PRを出したのは一人で、承認したのも一人 - 2015年の話だし。セキュリティ研究者のせいじゃないよ。

すごいバグだな。最初の10年はインターネットでtelnetしか使ってなかった気がする。あの頃は本当にワイルドだった。イーサネットのトラフィックをログに取ってパスワードが見えたりしてたし。終わりの方では少しだけシングルユーザーのマシンも増えてきたけど、大半は昔ながらの多ユーザーのマシンで、「root」は厳しく制限されてると思われてた（もちろん、実際には知ってる人にはそうでもなかったけど）。とにかく、これを見るのは驚きだね：> telnet -l 'root -f' server.test か > USER='-f root' telnet -a server.test 11年も生き残ったんだ。

└

ソフトウェアの仕事をすればするほど、何かが動いていることに驚かされるよ。まだまだ簡単に手に入る問題がたくさんあると思う。

└

telnetでrootを送ったことはないけど、親の家の近くの図書館で学校のAIXアカウントを使ってlynxでウェブをブラウジングするのに、休暇の時間を使いすぎたな。デスクトップがロックダウンされてる中で、カードカタログプログラムに加えてtelnetクライアントがあったからね。あの頃はもっと無邪気な時代だった。自分のトラフィックが記録されてるなんて思わなかったし。AIXアカウントにtelnetアクセスがあれば、どこでも便利なコマンドラインからメール（pine）やウェブ（lynx）、IRCができたんだ。

GNUのtelnetdのRCEは、telnetのサンセットとは関係ないよ。SSHでも同じことが起こる可能性があるけど（実際には、OpenBSDの人たちは本質的に用心深いからあまりないけど）。AppleがOS Xからtelnetクライアントを削除したのは愚かな判断だね。UNIXを名乗るならtelnetクライアントがないなんてありえないよ。grepやedを削除するようなもんだ。

└

それがOpen GroupのmacOS UNIX認証の謎の例外だったんだね！

└

telnetにはUNIXの要件はないよ。Ubuntuはデフォルトで含まれてないし（16.04からかな？）。ほとんどのディストロもそうだよ。

└

認証が必要でない限り、nc hostname 23はいつでも使えるよ。

でも、Telnetクライアントは死んでないよね？昔、SMTPサーバー（ポート25）と話すためにTelnetクライアントを使って、友達にいたずらメールを送って遊んでたことがある。ポートブロッキングが広がる中で、いつかすべてのサービスとプロトコルがポート443で待機するようになると思ってた。セキュリティの名のもとに他のポートが排除されていく中で、ポートベースのフィルタリングが無意味になるポートが一つ残ることになるんじゃないかな。

└

これらはtelnetクライアントプログラムの使用や、自分のホストでtelnetdを動かす能力には影響しないよ（でも、ちゃんとパッチ当てておいてね！）。起こっているのは、インターネットのグローバルルーティング（またはその大部分）が、たぶんパッチが当たってない恐竜システムを自動攻撃から守るために、telnetのデフォルトポートをブロックし始めたってこと。だから、SMTPサーバーにアクセスしてスプーフィングしたメールを送るのは、たぶんもう無理だね。自分のローカル環境からじゃないとできないかも。

└

netcat、socat、openssl s_clientは、一般的な手動接続テストに使えるよ。他にもいろんなツールがあるけど、上のやつらは基本的にtelnetの代わりに使える優れた選択肢だね。

telnetdが死んだって感じで、telnet自体は死んでないよ。ちなみに、クイックなtelnetクライアントが欲しいなら、古いPythonがインストールされてたら、python -m telnetlib IPを使えるよ。