Telnetが消えた日

 (labs.greynoise.io)
4 ポイント 投稿者 GN⁺ 2026-02-12 | 1件のコメント | WhatsAppで共有
  • 2026年1月14日21時（UTC）に全世界のTelnetトラフィックが急激に崩壊し、観測網で59%の持続的減少が確認された
  • 18のASNが完全に沈黙し、**5か国（ジンバブエ・ウクライナ・カナダ・ポーランド・エジプト）**のトラフィックが完全消滅
  • 主要クラウド事業者（AWS・Contaboなど）はむしろ増加した一方、北米地域のISPは大規模に減少
  • 6日後、**GNU Inetutils telnetdの認証バイパス脆弱性（CVE-2026-24061）**が公開され、root権限取得が可能な致命的欠陥であることが確認された
  • 業界ではバックボーンレベルのポート23フィルタリングが事前通知に基づく措置だった可能性に注目し、Telnetの終焉を象徴する出来事と評価

世界のTelnetトラフィック崩壊

  • 2026年1月14日21時（UTC）にGreyNoise Global Observation GridがTelnetトラフィックの急激な崩壊を検知
    • 1時間前の約74,000セッションから次の時間には22,000セッションへ65%急減
    • 2時間後には83%減の11,000セッション水準まで低下し、そのまま維持
  • 2025年12月〜2026年1月初めまでの平均日次セッション91万件に対し、その後は37万件水準へ59%減少
  • 変化は漸進的な減少ではなく、**単一時点での急激な断絶（ステップ関数型の変化）**であり、ルーティングインフラ設定の変更可能性を示唆

沈黙したネットワークと国

  • 18のASNが1月15日以降Telnetトラフィック「0」に転換
    • Vultr（AS20473）38万件 → 0、Cox Communications（AS22773）15万件 → 0
    • Charter/Spectrum（AS20115）、BT/British Telecom（AS2856）などを含む
  • **5か国（ジンバブエ、ウクライナ、カナダ、ポーランド、エジプト）**のトラフィックが完全消滅
  • 一方でAWSは78%増、Contaboは90%増、DigitalOceanは+3%維持
    • クラウド事業者はプライベートピアリング網を通じてバックボーンフィルタリングの影響を回避

ポート23フィルタリングの可能性

  • パターン上、北米のTier 1トランジット事業者がポート23フィルタリングを適用した状況がうかがえる
    • 時点が米国東部時間16時で、米国内のメンテナンス時間帯と一致
    • **Cox、Charter、Comcast（-74%）**など米国ISPが大きな打撃
    • **Verizon/UUNET（AS701）**は79%減少し、主要バックボーン事業者としてフィルタリング主体または上位経路である可能性
  • **欧州の直接ピアリング国（フランス +18%、ドイツ -1%）**は影響が軽微
  • **中国の通信事業者（China Telecom、China Unicom）**はいずれも59%減少
    • 均一な減少率は、米国側の太平洋横断リンクでのフィルタリング可能性を示唆

CVE-2026-24061脆弱性の公開

  • GNU Inetutils telnetdの認証バイパス脆弱性、CVSS 9.8評価
    • USER環境変数処理中の引数注入により、-f rootを渡すと認証なしでrootシェル取得が可能
    • 2015年のコミットで導入され、約11年間未発見の状態
  • 主な日程
    • 1月14日: Telnetトラフィック崩壊開始
    • 1月20日: CVE公開
    • 1月21日: NVD登録および初の悪用観測
    • 1月26日: CISA KEVリスト追加
  • トラフィック崩壊がCVE公開6日前に発生しており、単なる偶然以上の関連可能性が提起されている

事前通知とインフラ対応仮説

  • 脆弱性の報告者はKyu Neushwaistein / Carlos Cortes Alvarezで、1月19日に報告したとされる
  • パッチ準備・CISA対応が公開翌日には行われた点から、事前調整の可能性がある
  • GreyNoiseは次のシナリオを提示
    • 主要インフラ運用者が事前通知を受け、ポート23フィルタリングを先行適用
    • 1月14日にフィルタリング稼働 → 1月20日に公開 → 1月26日にCISA登録
  • 明確な証拠はなく、単なる時期的一致の可能性にも言及

その後のTelnetトラフィックの様相

  • 1月14日以降、ノコギリ歯状パターンが継続
    • 例: 1月28日80万セッション → 1月30日19万セッション
    • 断続的フィルタリング、ルーティング変動、特定スキャナーキャンペーンの可能性
  • 週間平均
    • 1月19日の週: 36万セッション（基準比40%）
    • 2月2日の週: 32万セッション（35%）
  • 基準比約1/3水準で安定化し、なお減少傾向

セキュリティおよび運用上の示唆

  • GNU Inetutils telnetd利用者は直ちに2.7-2以上へ更新するか、サービス無効化が必要
    • CISAは2026年2月16日までに連邦機関のパッチ適用期限を設定
    • 公開直後、数時間以内に悪用試行が観測され、2月初めには日次2,600セッションまで増加後に減少
  • ネットワーク運用者はポート23フィルタリングの検討が必要
    • バックボーンレベルではすでにフィルタリングが進行中で、Telnetトラフィックはもはや価値のないプロトコルと見なされている
  • GreyNoiseは「誰かがインターネットのかなりの部分でTelnetを切断した」という事実を記録し、
    Telnet時代の終焉を象徴する出来事と評価

関連記事

1件のコメント

 
GN⁺ 2026-02-12
Hacker Newsの意見

  • telnetd より深刻なのは、Tier 1 トランジットプロバイダがポートフィルタリングを始めたことだと思う
    これはインターネットが分断されたということであり、自動ルーティング（BGP）でも迂回できない構造になってしまった

    • 昔、小さな ISP で働いていたときに Blaster ワームが大流行したが、ポート 139 のようなものを塞ぐのが最も速い対応だった
      当時はほとんどの ISP がポートを遮断し、その結果としてより安全になった
      もし本当に telnet が必要なら、別のポートへ移すかトンネリングすればいい
      いまだに標準の 23 番ポートで telnet を動かしている人がいるのか気になる
    • 検閲のリスクも問題だが、病院・銀行・原子力のようなシステムがハッキングされて人命が危険にさらされることも深刻な問題だ
      こうした判断を下す人たちは、権限と責任を同時に負っている
    • ポート 23 は、すでに何十年も前から大半のプロバイダがフィルタリングしていた
      だからあらゆるものが TLS 443 ポートへ集中している
      これを検閲だと騒ぐ話ではなく、本当の検閲は FOSTA/SESTA のような法律に見いだすべきだ
    • ポートを塞ぐのは結局 検閲と変わらないと思う
    • 私は Spectrum ISP 経由で GNU telnet クライアントを使い、シアトルとオランダのサーバーへ接続できた

  • 本当に驚くようなバグだ
    インターネット初期の 10 年間は、ほとんど telnet ばかり使っていた時代だった
    当時はイーサネットのトラフィックを見ればパスワードがそのまま見え、多くのシステムがマルチユーザー環境だった
    telnet -l 'root -f' server.test のようなコマンドが 11 年も生き残っていたとは信じがたい

    • ソフトウェアの仕事を長くするほど、世界がこんなふうに動いていること自体が不思議に思える
      まだ 取りやすい低い位置の果実みたいな脆弱性がたくさんある気がする
    • root でログインはしなかったが、学校の AIX アカウントで lynx を使って Web を見ていた時代があった
      当時はトラフィックが監視されているなんて考えもしなかったし、ただ自由な時代だった
      telnet でメール（pine）、Web（lynx）、IRC まで全部やっていた
    • いつ telnet を使わなくなったのかも覚えていない
      多くのサーバーが root の telnet ログインを開けていたのに、一度も侵害されなかった
      本当に あの時代が懐かしい
    • 昔、rlogin -l '-froot' のような脆弱性もあったのを思い出した
      当時はこういうのが普通だった
    • ログイン用途では使わなかったが、デバッグツールとしては今でも有用だった
      コンテナ間のトラフィックが通るか確認するときによく使っていた

  • Telnet クライアント自体はまだ死んでいない
    昔は SMTP サーバー（ポート 25）に telnet で接続して スプーフィングメールを送ったものだ
    ただしセキュリティ名目でポート遮断が増えているので、結局すべてのサービスが 443 ポートへ集まると思う

    • 今は netcat, socat, openssl s_client のようなツールの方がずっとよい代替だ
      telnet よりはるかに強力だ
    • 子どものころ、telnet で SMS を送ったことがある
      受信者には正式な通信事業者アカウントのように見えたし、その頃は無邪気だったが、今思うと危ないいたずらだった
    • telnet クライアントや telnetd 自体は今でも使える
      ただ、グローバルルーティングのレベルで標準ポートが遮断されたようだ
      保護されていない旧式システムを守るための措置に見える

  • いまだに、なぜ telnet をインターネット上で使うのか分からない
    ほとんど攻撃トラフィックではないかと思う

    • 一部は 歴史的システムの保存のために動かしている
    • 実際には ASCII スター・ウォーズを見るためだ
      telnet towel.blinkenlights.nl
      YouTube動画リンク
    • レガシー・IoT・産業用機器では今でも telnet が使われている
      SSH も実際にはずさんな運用をされることが多い
      ホストキー検証を無効にしたり、パスワードなしの鍵を使ったりするなど
      そのため現実的には telnet + HTTPS websocket + OAuth の組み合わせの方が安全なこともありうる
    • アマチュア無線（HAM）では 暗号化が禁止されているため telnet を使う
      その代わり署名付きデータ転送は許可されているので、そうした代替プロトコルが必要だ
    • いまだに MUD や MOO のようなテキストベースのゲームサーバーの大半は telnet を使っている

  • 今回の CVE は、組み込み機器ハッキングコミュニティにとっては朗報だ
    telnetd が開いている機器で root 権限を得られる可能性が高まった

    • 実際に Zyxel WiFi AP で試したが、busybox ベースの telnetd だったせいか脆弱ではなかった

  • 問題の CVE は このコミット に由来する
    user_name を uname に変えたのが核心だが、こうした名前変更がなぜ必要だったのか疑問だった

    • ChangeLog を見ると、user_name がグローバル変数と 名前衝突（shadowing） を起こしていたため変更したものだ
    • ただ、こうした修正よりも getenv() 呼び出しを点検する方が重要だと思う
      入力値のパースが難しく、しばしば脆弱性が生まれるからだ

  • 誰かがインターネット・トランジット基盤の上流で telnet トラフィックを捨てると決めたというのは興味深い
    おそらく正しい判断なのかもしれない
    MUD トラフィックに影響はあるのだろうか

    • ほとんどの MUD は Telnet プロトコルを直接使っていない
      単純な TCP ベースで、専用クライアントが好まれる
      ポート 23 は IANA によって Telnet 用に予約されているが、MUD は通常 4 桁の高いポートを使う
      むしろ今は 23 番ポートで動かすと、さらにアクセスしづらくなるだろう
    • 記事では明確ではなかったが、おそらく攻撃トラフィックだけをフィルタリングしているのだろう
      Telnet は平文なので、パターン分析で簡単に見分けられる
    • おそらく SMTP ポート遮断のようなポートベースのブロックである可能性が高い
      今どき公開ネットワーク上のサーバーなら SSH を使うべきだ

  • 今回の CVE とその対応は本当に 歴史的な出来事だ
    たった一人が事実上 telnet の時代を終わらせたというのは信じがたい

    • 実際には PR を出した人と承認した人の二人がいた
      セキュリティ研究者のせいではない

  • インターン時代、机の上にあった VoIP 電話機に telnet 接続できると気づいたときは本当に驚いた

    • 私もインターンのとき、Perl CGI スクリプトを telnet でテストしていた
      Hayes コマンドに慣れていたので、HTTP リクエストを直接タイプするのが自然だった
    • 私もそうだった、楽しい思い出だ

  • 最近、自分の telnet サーバーの統計を見たところ、平均で 2000 IP ほど接続してくる
    1 月中旬に 7500 まで急増してまた減り、2 月には 1000 程度まで落ちた