本文へ
ハクソク

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

300以上のTor出口ノードを削除した方法

元記事: 原文(kaba.cx)

概要

2026年10月2日、Torネットワークの約10%にあたる333の出口ノードが感染し、SSH接続の傍受とデータ窃取を試みた攻撃が発生。 攻撃者はEbury 1.8.3(OpenSSHバックドア)を用い、主に暗号化されていないメールとSSHトラフィックを標的に。 Torプロジェクトは迅速な対応で感染ノードを遮断し、被害の拡大を防止。 感染ノードの特定にはexitmapやsshのフィンガープリント検証が活用された。 攻撃の背後や侵入経路は未解明だが、金銭目的の犯罪グループが関与している可能性が高い。

Torネットワークへの大規模攻撃

  • 2026年10月2日午前9:35、 333の感染した出口ノード が協調して SSH接続の傍受 と 未暗号化データの収集 を開始
  • Tor全体の 約3,000出口リレー のうち 10%が攻撃者の制御下 に
  • 攻撃者は 2か月前(8月) からサーバーに侵入し、 Ebury 1.8.3(Linux用OpenSSHバックドア) を密かに展開
  • 攻撃の主目的は
    • 未暗号化メールトラフィックの収集
    • SSH接続のMITM(中間者攻撃)
  • 特定ポートをブロックし、出口ノードで未暗号化メールのみを処理

SSH中間者攻撃(MITM)の手口

  • 感染出口ノード経由のSSH接続は 12台の傍受サーバー へリダイレクト
  • 通常の暗号化ウェブトラフィックは問題なく転送
  • SSH接続時にホストキー警告が表示されるが、無視してログインすると
    • パスワード窃取
    • コマンド監視(MITM)
    • Eburyによるサーバー感染
  • 実際に被害に遭遇したTorオペレーターの詳細なレポートも存在

Torプロジェクトの対応と影響

  • 攻撃発覚後、 Torネットワークヘルスチーム が即時対応
  • 10月4日:感染ノードの運用者に通達、 BadExit フラグで出口としての利用を停止
  • 攻撃者がノードを再稼働させても、中継リレーとしてしか機能せず
  • 10月5日:全感染サーバーが停止
  • 333ノードの遮断により、Tor出口ノードの数が大きく減少
  • Tor公式メトリクスで10月4日以降の明確な減少が確認可能

技術的調査方法

  • exitmap を使い、全出口ノードへのSSH接続を自動化スクリプトで検証
    • 正しいSSHフィンガープリントの有無を判定
    • 傍受サーバー経由のリダイレクトで感染ノードを特定
  • sshesame (ハニーポット)を使い、攻撃者の行動を観察
    • paramiko(Python SSHライブラリ)やPerlによるEburyインストール手法の確認
    • 権限チェック後、base64エンコードコマンドを実行

未解決の疑問と考察

  • どのようにして多数のサーバーへ侵入できたのかは不明
    • ホスティング会社自体の侵害説もあるが未確定
  • 攻撃者の正体も不明だが、Eburyの利用と未暗号化データ収集から 金銭目的の犯罪グループ の可能性
  • 2009~2023年に Ebury感染サーバーは40万台 以上との報告もあり、今後も注意が必要
  • 金曜に攻撃開始し、週末の対応遅れを狙った可能性

セキュリティ教訓と推奨対策

  • パスワード認証を無効化し、SSH鍵認証へ移行
  • ハードウェアキーの導入推奨
  • リレーやブリッジは 高度に標的化される本番機 として運用すべき
  • Torコミュニティへの貢献としてリレー運用も検討推奨

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

ここに作者がいます :) 要約すると、10月2日に333の出口ノード(Torの約10%)がポート22を12のインターセプションサーバーにリダイレクトし、パラミコを使ったMITM攻撃でパスワードを盗んだり、ターゲットにEburyを仕込もうとしたってことです。

└

そのホストを検出して検証するために時間をかけてくれてありがとう。 もし可能なら、そこから(たぶんcurlを使って)ifconfig.meのようなサイトにアウトバウンド接続を作って、どのプロバイダーにいるかをログに記録して、HNに報告を投稿することはできますか? [1] - https://ifconfig.me/

└

なんでTOR経由でsshでホストにアクセスしたいのかがわからない。

└

ありがとう、君のおかげで世界が救われたよ。

これを書いてくれてありがとう。 > でも、警告を無視してログインを進めると、攻撃者は3つのことをします: > 1. あなたのパスワードを盗む。 ただし、これはキー認証には影響しないはずです。また、あなたの投稿にリンクされているMarc-Etienne M.Léveilléのメールからの情報ですが: > もう一つの可能性は、ホスティングプロバイダーが侵害されていることです。過去にEburyによって管理サーバーが侵害されたいくつかのプロバイダーを特定しました。その結果、顧客のVPSやコンテナなどもEburyを実行することになりました。顧客のVPSインスタンスがプロバイダー側で侵害される傾向は、近年増加しています。プライバシー関連のものはVPSでホスティングするのをやめて、専用ハードウェアに切り替えました。多くの人は、プロバイダーがリアルタイムでRAMやディスクスペースを静かにダンプしたり操作したりするのがどれほど簡単か理解していません。

└

多くの人は、プロバイダーがリアルタイムでRAMやディスクスペースを静かにダンプしたり操作したりするのがどれほど簡単か理解していません。これは使用されているVPSの技術スタックによります。確か、AmazonはIOMMUのようなハードウェア機能を使っていて、ホスト側からゲストのメモリにアクセスすることを防いでいます。

教訓はいつも同じ:追加のセキュリティは価値のある投資です。パスワード認証を無効にしてsshキーを使いましょう。私は今日、ハードウェアキーを買うつもりです。 :) 質問:これらのハードウェアキーはどこで手に入るの? どれが良い選択肢で、なぜ?

└

Yubikeyを使えば、パスワードの代わりにSSHキーを生成するだけで、このMITM攻撃を防げるよ。SSHのラウンドやポートを変更して、誰も認識できないような見えないプロトコルにするのも効果的。Yubikeyの利点は、ハードウェアにキーを保存できること。もしノートパソコンが何らかの形で侵害されたり盗まれたりしても、SSHキーを全部奪われることはないからね。

└

今日はハードウェアキーを買う必要はないよ。最近のOpenSSHサーバーがあれば、どんなFIDO2キーでもSSHに使えるから。ecdsa-skやed25519-skの公開鍵をサポートしているサーバーならね。信頼できるハードウェアキーのメーカーには、YubikeyやToken2などがあるよ。結局、FIDO2トークンとして使うだけだから、信頼できるものを選んでね。もし始めたばかりなら、ソフトウェアバックのキー(ssh-keygenを使って)を生成して、公開鍵をサーバーのauthorized_keysファイルにssh-copy-idでコピーするか、手動で追加することから始めるのがいいと思う。オンラインガイドもたくさんあるし、古いサーバーの実装がFIDO2クレデンシャルをサポートしていないリスクも少ないから、まずはこの方法を学んでから、公開鍵のコピーの仕組みを理解したらハードウェアキーに移行するといいよ。パスワードマネージャーも、キーを使ったログインのためにSSHエージェントとして機能することがあるかも。例えば、Bitwardenや他のいくつかは今そうしていると思うよ。

└

iPhoneを持っているなら、SSHクライアントアプリのTerminusがiPhoneのSecure Enclaveを使ってプライベートキーを保存できるよ。これで、電話の他のアプリ、Terminus自身さえもプライベートキーを読み取れなくなる。プライベートキーはハードウェアに保存されるんだ。FaceIDを使ってSSHのログイン操作を承認する感じ。最近、TerminusでプライベートSSHキーの生成と管理をする代わりにそれを使うように切り替えたよ。同様に、多くのMacやMacBookもSecure Enclaveを持っていて、プライベートキーをハードウェアに保存できるし、macOSに付属のSSHクライアントとも連携できる。でも、まだそれを使うことはしてないんだ。近いうちにやるつもりだけど。そうしたら、SSHのログイン操作を承認するのにTouchIDを使うことになる。Yubikeyもいいよね。私は主にSSH以外のことに使ってるけど。どんな解決策を選んでも、ハードウェアキーが壊れたときにアクセスを復元するためのバックアップや別の方法を用意しておくといいよ。例えば、Yubikeyを1つ買う代わりに3つ買って、それぞれ同じ場所にアクセスできるようにしておく。1つは持ち歩き、1つは家に、もう1つは別の場所に置いておく。数週間ごとにそれぞれを使い回して、全てがまだ機能しているか確認して、同じ場所にアクセスできるようにしておく。SSHの場合、ターゲットマシンに物理的にアクセスできるか、ホスティングプロバイダーからVNC管理ができるなど、ハードウェアキーを紛失したり壊したりした場合に戻れる手段があるから、SSH用にハードウェアキーを1つだけ使っていても大体大丈夫だよ。

これもまた、相互認証(sshユーザーキー認証やHTTPSクライアント証明書)の強さを示しています:クライアントがMITMサーバーからの偽のサーバーキーを受け入れても、実際のサーバーはクライアントのキー交換を受け入れません(SSHプロトコルでは、接続に結びついているため)。攻撃者がここで行った3つのことについて:1. パスワードを盗むことはできません。なぜなら、プライベートキーはクライアントから出ないからです;2. あなたが入力するコマンドを観察できますが、実際のサーバーに接続して、コマンドにどう反応するかを知ることはできません;3. 実際のサーバーに接続することはできません(認証に失敗するため)、だから実際のサーバーに対して何もできません。本当にパスワードが好きなら、sshdを設定してクライアントキーとパスワードの両方をその順番で要求する方法もあります。

└

パスワードが好きなら、SSHの相互認証を使って、ローカルのパスワードで暗号化されたプライベートキーを使うこともできるよ。それで「知っている何か」の要素の利点を得られるけど、サーバーにはパスワードをさらさない。キーの復号化や使用がどう行われるかも確認できるし(自分のコンピュータ上で行われるから)、コンピュータから出ていかないのが分かるんだ。

Hacker Newsで議論の続きを見る