Tailscale を「調整サーバーや 1 台の端末が破られても」耐える形にする（Tailnet Lock と Tailscale SSH の絞り込み）

Tailnet Lock を有効にすると、新しい端末は自分が信頼した署名用ノードの署名がない限り tailnet に参加できない。Tailscale SSH は転送や root 接続を広く許さず、接続元と接続先を一対一で絞る。

通常の tailnet では、どの端末を仲間として受け入れるかを Tailscale の調整サーバー（コントロールプレーン）が決める。調整サーバー側が侵害されたり、管理者アカウントが乗っ取られたりすると、攻撃者の端末を紛れ込ませられる。
2026-10-25 公開の調査「Tailworm」（Erica Windisch 氏、Tailscale 1.104.2 などで検証）は、Tailscale SSH の設定次第で、侵害済みの端末から別サーバーの root 権限を奪えると報告した。SSH のポート転送を許していることと、接続権限のある端末を事前に侵害していることが条件。研究室での実証で、実攻撃は未確認、CVE や修正版は報告時点で未発表。
同調査で、不正端末の登録まで成功したのは Tailnet Lock が無効な環境だけ だった。一対一の接続許可ルールも侵入の拡大を防いだ。

署名用ノードを 2 台以上決める（普段手元にある信頼できる端末。Tailscale v1.46.1 以上）。
管理画面の Device management で Enable Tailnet Lock を選び、署名用ノードを追加すると tailscale lock init コマンドが生成される。署名用ノードの 1 台でそれを実行する。
実行時に表示される 10 個の「無効化用シークレット」を、パスワードマネージャーなど安全な場所に保管する。表示はこのときだけで、失うと Tailnet Lock を解除できない（サポートに 1 個預けるオプションもある）。
各ノードで tailscale lock status を実行し、信頼済み署名鍵の一覧が全ノードで同じで、自分が選んだ署名用ノードの鍵と一致するか確かめる（初回の状態は調整サーバーから配られるので、ここで改ざんがないかを確認する）。
以後、新しい端末は署名用ノードから tailscale lock sign で署名するまで他の端末とつながらない。

開発元が SSH の権限管理の不備を認め、1.104.4 で Unix ソケット転送を「認証したユーザーの権限」で処理するよう修正した。Tailscale SSH を使う端末はまず 1.104.4 以上へ更新する。
すぐ更新できない端末のつなぎ対策は、tailscaled の環境変数 TS_SSH_DISABLE_FORWARDING=1 を設定してサービスを再起動し、SSH の転送を止めること。
接続前に追加認証を求める check モードは機密性の高いサーバーに勧められているが、研究者は「認証後の転送処理で起きる権限昇格は防げない」と説明している。check モードだけで安心しない。
侵害された端末の鍵入り状態ファイルが複製されていた場合、再インストールしても盗まれた鍵は失効しない。管理画面でその端末を削除し、その端末から届いた先の認証情報も交換する。
出典: @MalwareBibleJP · 2026-10-29 、Tailscale ブログ tailscale.com