内部ホスト名がクラウドに漏洩するとき

 (rachelbythebay.com)
1 ポイント 投稿者 GN⁺ 2026-02-06 | 1件のコメント | WhatsAppで共有
  • 家庭用NAS機器のWebインターフェースが、内部専用ホスト名を外部サービスへ送信する事例が発見された
  • NASのWeb UIに含まれるsentry.ioのエラー報告スクリプトが、スタックトレースとともに内部ホスト名を外部へ送信
  • sentry.io側がそのホスト名に対してTLS接続を逆向きに試行するものの、実際のリクエストは送らないという奇妙な挙動が観測された
  • ワイルドカードDNSをあらかじめ設定していたおかげで漏洩の事実を検知でき、機微なホスト名を使っている場合は深刻な情報露出リスクがある
  • この仕組みを悪用すると、任意のホストに対するDNSスキャンを誘発できる潜在的なセキュリティ問題がある

NASの設置と内部ホスト名の構成

  • NAS機器を購入してドライブを装着し、ホームネットワークに接続して、HTTPSモードで運用
  • 公開インターネット上で意味のないドメインの配下サブゾーン（例: *.nothing-special.whatever.example.com）に対するワイルドカードTLS証明書を導入
  • /etc/hosts ファイルに 172.16.12.34 nas.nothing-special.whatever.example.com のようなローカル専用エントリを追加し、ブラウザからアクセス

外部からの予期しないアクセスを発見

  • NASを設置して数日後、同じホスト名に対して外部("outside world")からのリクエストが届き始めた
  • そのホスト名はノートPCの /etc/hosts ファイルにしか存在しない完全に内部専用の名前
  • 事前に *.nothing-special.whatever.example.com 全体について、自分が管理するマシンへ向けるワイルドカードDNSエントリを設定していたため、漏洩を検知できた
  • NASを読み込むたびに、GCPホストがその内部ホスト名をSNIとして提示し、接続を試みていた

漏洩の原因: sentry.ioのエラー報告

  • NASのWebインターフェースにはphone home機能が含まれており、その一環としてsentry.ioへスタックトレースを送信
  • ブラウザがsentry.ioへコールバックする際、内部ストレージ機器で使っているホスト名も一緒に送信していた
  • sentry.io側がそのホスト名に対してTLS接続を逆向きに生成するが、実際のHTTPリクエストはまったく送らないことを確認

セキュリティ上の示唆と対応

  • ホスト名に機微な情報（例: mycorp-and-othercorp-planned-merger-storage のような名前）を含めている場合、深刻な情報漏洩の危険がある
  • このsentryの報告メカニズムを利用して、任意の外部ホストに対するDNSスキャンを誘発することが可能（具体的方法は読者に委ねる）
  • 対応策として Little Snitch を起動し、そのドメイン全体をすべてのアプリに対してブロックした

関連記事

1件のコメント

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

  • みんな誤解しているようだ。これは CTログ の問題ではなく、ワイルドカード証明書 に関する話だ。
    Sentryがクライアント側トレースを収集する際、リクエストを送ったホスト名を抽出し、それを再度ポーリングしようとして拒否された状況だ。

    • おそらくトレースUIで表示する favicon を取得しようとしたのかもしれない。
    • ただしこの構造だと、Sentryが任意のIPへリクエストを送れてしまう セキュリティ脆弱性 になりうる。特に、自動で悪意あるトラフィックを通報するIPへ繰り返しアクセスする可能性もある。
    • みんなが混乱している理由は、ブログ記事があまりに 混乱していて不明瞭に書かれている からだ。

  • ホスト名は本質的に 非公開情報ではない。
    DNSクエリやTLS証明書など、さまざまな経路で外部に露出する。
    非公開サービスを隠したいなら、ホスト名の代わりに URLパス に秘密を入れるほうがよい。
    たとえば fileservice.example.com/my-hidden-service-007-abc123/ のようにすれば、HTTPSでのみ送られるため露出はかなり減る。

    • もちろんこの場合でも、Sentryのような外部サービスにパスが送信される可能性があるので、不透明なURL を使い、秘密をURLに入れない習慣が必要だ。
    • 「HTTPだけを使えばこうした露出は減るのか？」という質問もあった。

  • 「clown GCP Host」が技術用語なのか気になった。調べてみると、筆者が cloudを皮肉って 使った表現だった。
    NASのWebインターフェースがSentryへログを送る際、内部ホスト名が含まれていたのが問題の核心だ。
    私ならこういう場合、信頼できるオープンソースOS に入れ替えるか、PiHole のようなDNSブロックでSentry呼び出しを止めると思う。

    • 「clown」はBig Techの cloudを揶揄する表現 で、昔のIRCでも「clown computing」という言い方があったそうだ。
      ある人はローカルDNSと TLSプロキシ を使って、外部へ出るトラフィックを完全に遮断していると説明していた。
    • 別の人は、「clown」は 大手クラウドプロバイダーとその利用者 を風刺する古い言葉だと付け加えた。
    • ある人は「clown」の代わりに「weenie」という単語を使うこともあると冗談を言っていた。
    • 「サーカスは去ったが 道化師たちは残った」という感じのユーモアもあった。

  • こうした事例があるので、私は uBlock Origin をWebセキュリティの最低基準だと見ている。
    ほとんどのWebページが大量のサードパーティ製スクリプトを読み込み、データを漏らしているのは深刻すぎる。
    根本的な解決ではないが、今すぐ私たちにできる最善策だ。

    • 私も AdGuard Home をルーターに入れているが、トラフィックの15〜20%が遮断される。追跡と広告がどれだけひどいか実感する。

  • こうした問題を防ぐには、前段に Nginxリバースプロキシ を置き、CSPヘッダー を注入するのがよい。
    こうすればNAS自身が外部へリクエストを送るのは防げないが、代わりにブラウザが送るのは遮断できる。
    たとえばSteamのアバター取得リクエスト（https://avatars.steamstatic.com/HASH_medium.jpg）もCSPポリシーでブロックできる。
    必要なら一部だけ許可すればよい。また Referrer-Policy: no-referrer を追加して、ホスト名が外部ログに残らないようにもできる。

    • ある人は「ATM machine」と言って重複表現を指摘し、
    • 別の人は「NPMはかなりシンプルだ」と冗談っぽく返していた。

  • 私は Synology NAS を買ったが、何度も後悔した。
    コミュニティ製ソフトウェア以外では、できることがほとんどない。
    Let's Encrypt でSSLを適用するのも複雑で、パスが非標準的なため設定場所を見つけにくい。
    古いrsyncバージョン、基本ユーティリティ不足など不満が多い。むしろ LinuxやBSDベースのNAS にしておけばよかった。

    • Synologyはファイルサーバーとしてだけ使うなら 非常に安定している ので満足している、という意見もあった。ただし閉鎖的な方針のせいで UniFi NAS へ移る予定だという人もいた。
    • 「サーバーを求めながら、NASがサーバーではないと不満を言うのは矛盾している」という反応もあった。
    • Synology NASに 最新のDebian を入れるガイドが Doozanフォーラム にあると共有した人もいた。
    • 「単なるファイル/iSCSIサーバーとして置いておくなら 非常に安定している ので、いじらないほうがいい」という助言もあった。
    • 一方で、RS217モデルを100ドルで買って最高の買い物だったという人もいた。Synology Office をGoogle Docsの代わりに使っており、UIの完成度に感心したそうだ。

  • 最近Sentryを設定してみたが、このシステムには 自動でアップタイム監視 を構成しようとする機能がある。
    ホストを認識すると定期的にpingを送り、数日間安定して応答すると「このホストにアップタイム監視を設定しますか？」という通知を出す。

    • ある人は「拡張のチャンス」と短くコメントしていた。

  • 私は個人的に Sentry関連ドメインを丸ごとブロック している。
    一般的な解決策ではないが、自分の環境ではそれが最善だ。

  • 逆引きサーバー は、内部ネットワークアドレス（ULA、RFC1918）まで解決しようとする試みがしばしば見られる。
    こうしたデータを他の情報と組み合わせれば、内部状態を推測できる。
    「Darknet収集中にUDPオーディオが捕捉されたこともある」とのことだ。

    • これに対して「そのUDPオーディオは何年ごろの SIPトラフィック だったのか？」という質問が出ていた。

  • 以前 Heroku で似た現象を調べたことがある。
    新しいアプリを作るとランダムなサブドメインが割り当てられるのだが、DNS問い合わせをしていなくても、すぐに 脆弱性スキャナーからのリクエスト が来る。
    Herokuに問い合わせたところ、新規アプリのURLが 証明書透明性（CT）ログ に公開されるためだという。

    • ある人は「これは新しいサービスごとに 『攻撃してください』の看板 を掲げるようなものだ」と言い、CTログには実際の証明書ではなく ハッシュだけを記録すべきだった と指摘していた。
      Certificate Transparencyの仕組み のリンクも共有されていた。
    • 別の人は「自分は ワイルドカードドメイン を使ってこの問題を避けている」と言って、スクリーンショット（画像リンク）を投稿していた。