「つながるだけでは不十分。RustDeskの公開ID接続を見直してみた【Linux運用・セキュリティ編】」

つながるようになった。その次に考えたこと

以前の記事では、古いPCにLinux Mintを導入し、Tailscaleを使って複数の拠点や機器をつなぐ取り組みをご紹介しました。

古いiMacやVAIO、Raspberry Pi、Odroidなどを組み合わせ、外出先からも事務所の機器を管理できる環境が整いました。

今回は、その環境を運用する中で気になった、遠隔操作のセキュリティについてのお話です。

Linux Mintで稼働している古いiMacには、遠隔操作ソフトのRustDeskを導入しています。

Tailscale経由で安全に接続できる環境は、すでに構築済みでした。

しかし、ここで一つ疑問が生まれました。

「Tailscaleで接続できるのに、RustDeskの公開ID経由の接続も残しておく必要があるのだろうか？」

便利な接続方法でも、使わない経路はできるだけ減らしたい。

そこで、RustDeskの接続経路を見直してみることにしました。

RustDeskとTailscaleを組み合わせる

RustDeskは、離れた場所にあるパソコンの画面を操作できる便利なソフトウェアです。

一般的にはRustDesk IDを使って接続先を指定できます。ネットワーク環境によっては、中継サーバーを経由して接続することもあります。

一方、Tailscaleは、認証された端末同士をプライベートなネットワークで接続できる仕組みです。

今回のiMacも、すでにTailscaleに参加していました。

そこで、RustDeskのDirect IP接続を利用し、TailscaleのIPアドレスを指定して遠隔操作できるようにしました。

iMac側ではRustDesk 1.4.9を使用しています。

Direct IP接続用のTCPポートは21118を使用しました。

UFWで接続元を制限する

Linux Mint側では、ファイアウォールとしてUFWを使用しています。

今回、SSHとRustDeskのDirect IP接続について、Tailscaleのネットワークインターフェースからの着信のみを許可しました。

これにより、通常のネットワーク側からDirect IP接続用ポートへアクセスすることを制限できます。

ところが、ここで一つ問題がありました。

UFWで外部からの着信を制限しても、従来のRustDesk IDで接続できてしまったのです。

これは、外部からの着信と、RustDesk自身が外部サーバーへ開始する通信が別のものだからです。

UFWの標準設定では外向き通信が許可されていたため、公開ID・リレー経由の接続を防ぐには不十分でした。

RustDeskの設定ファイルを書き換えてみたものの……

次に、RustDeskの公開IDサーバー設定をローカルアドレスへ変更する方法を試しました。

しかし、RustDeskを再起動すると、変更した設定が元の公開サーバーに戻ってしまいました。

root側と一般ユーザー側の設定ファイルを確認しても、同じ現象が発生していました。

原因を完全に特定できたわけではありませんが、少なくとも今回の環境では、この設定変更だけに頼る方法は適切ではないと判断しました。

そこで、Linuxのサービス管理機能であるsystemdを利用することにしました。

systemdでRustDeskの通信を制限する

systemdには、サービスごとに通信先や接続元のIPアドレスを制限する機能があります。

今回使用したのは、IPAddressAllow と IPAddressDeny という設定です。

まずRustDeskのプロセスを確認し、通信を担当する rustdesk --server が rustdesk.service の管理下にあることを確認しました。

そのうえで、RustDeskサービス専用の追加設定ファイルを作成しました。

設定の考え方は、次のようなものです。

[Service]
IPAddressDeny=any
IPAddressAllow=localhost
IPAddressAllow=100.x.x.x/32
IPAddressAllow=100.y.y.y/32

※上記は設定の考え方を示した説明用の例です。そのままコピーして使用することはできません。実際にはiMac自身と接続元PCのTailscale IPアドレスを指定します。また、設定変更前には必ずバックアップを取得し、SSHや現地コンソールなど、別の復旧手段を確保してください。

※IPアドレスは説明用です。実際には接続を許可する各PCのTailscale IPアドレスを登録します。

IPAddressDeny=any で原則として通信を制限し、IPAddressAllow で必要な通信相手だけを許可します。

今回は、iMac自身と、遠隔操作に利用する複数のPCを個別に登録しました。

設定変更時に気を付けたこと

この設定は通信を強く制限するため、設定を間違えるとRustDeskで接続できなくなる可能性があります。

そのため、作業前には設定ファイルのバックアップを取得し、RustDeskとは別にSSHで接続できる状態を確保しました。

また、設定を変更する際には、次の順番で確認しています。

1. 現在の設定を保存する
2. 新しい設定を記述する
3. systemdの設定内容を検証する
4. RustDeskサービスを再起動する
5. 接続できることを実際に確認する

万一、接続できなくなった場合は、SSHまたは現地のコンソールから追加設定を無効化し、元の状態へ戻せるようにしています。

なお、systemdのIPアドレス制限は、Tailscaleの端末認証そのものを行うものではありません。

今回はUFWによるネットワークインターフェースの制限と組み合わせて運用しています。

万一、接続できなくなった場合

今回のような通信制限を設定すると、設定内容によってはRustDeskで接続できなくなる可能性があります。

そのため、SSHや現地コンソールなど、RustDesk以外の管理手段を確保しておくことが重要です。

今回の環境では、問題が発生した場合、次のコマンドで追加したsystemd設定を無効化し、元のサービス設定に戻せるようにしています。

sudo mv /etc/systemd/system/rustdesk.service.d/90-tailscale-only.conf \
  /etc/systemd/system/rustdesk.service.d/90-tailscale-only.conf.disabled

sudo systemctl daemon-reload
sudo systemctl restart rustdesk

※これは今回追加したsystemdの通信制限を解除する手順です。UFWなど、別の設定は変更しません。元の接続環境に完全に戻ることを保証するものではありません。

実際に接続テストをしてみた

設定変更後、別のLinux Mint端末から接続テストを行いました。

結果は次のとおりです。

接続方法	結果
Tailscale経由のDirect IP接続	成功
従来のRustDesk公開IDによる接続	失敗
SSH接続	正常
Tailscale	正常

当初の目的であった、Tailscale経由のDirect IP接続を維持しながら、従来の公開IDによる接続を制限するという結果が得られました。

ただし、これで外部からのあらゆる接続を完全に遮断できたと証明されたわけではありません。

今回の通信制限は、systemdが管理するRustDeskサービスのプロセスに適用されています。一方、RustDeskのGUIには別の管理グループで動作するプロセスもあります。

また、Tailnet外の独立した端末からの接続試験までは実施していません。

そのため、現段階では「今回の環境と接続テストにおいて、期待した結果を確認できた」という位置付けです。

今後も必要に応じて検証を続けていきます。

複数のPCからアクセスできるようにする

今回のiMacには、事務所や自宅など、複数のパソコンからアクセスする可能性があります。

そこで、Windows、Linux、macOSを使用する計6台の接続元PCについて、それぞれのTailscale IPアドレスをsystemdの許可設定に登録しました。

サービスを再起動し、設定が正しく反映されていることを確認しています。

現時点では、追加したすべてのPCの内3台からの実接続テストまでは完了しましたが、設定上は各端末全てからの通信を許可する構成になっています。

なお、TailscaleのIPアドレス帯全体を許可する方法もありますが、今回は管理する端末が少ないため、個別に登録する方式を採用しました。

古いPCを使い続けるために

今回の作業を通じて、改めて感じたことがあります。

それは、「つながること」と「安全につながること」は別だということです。

古いiMacにLinux Mintをインストールし、Tailscaleを使って遠隔操作できるようになったことで、機器の活用範囲は大きく広がりました。

しかし、便利だからといって、すべての接続方法を残しておく必要はありません。

今回も、UFWの設定だけでは想定していた制限が実現できず、RustDeskの設定ファイルの変更でも期待した結果が得られませんでした。

そこで、実際の通信やプロセスの動きを確認しながら、systemdによる制限を追加しました。

もちろん、これでセキュリティ対策がすべて完成したわけではありません。

今後もアップデートや運用環境の変化に合わせて、設定を見直していく必要があります。

古いPCを再利用するというのは、単に新しいOSをインストールすることではなく、必要な役割を持たせ、無理なく、安全に使い続けられる環境を整えることだと考えています。

ナミキアソシエイツでは、こうした身近なIT環境の改善を、実際の機器を使いながら少しずつ進めています。

これからも、その過程で得られた経験や工夫をTech Blogでご紹介していきます。