「RDPでリモート作業しているけど、本当に大丈夫なのか不安だ」
「ポート3389をインターネットに開けているが、攻撃の踏み台になっていないか心配」
こうした不安を持つ情シス担当者は少なくありません。リモートデスクトッププロトコル(RDP)は中小企業のリモートワーク普及とともに急速に広まりましたが、同時に攻撃者が最も好んで狙うポートの一つになっています。インターネットに直接3389番ポートを公開している環境は、世界中から自動スキャンとブルートフォース攻撃を受け続けている状態です。
この記事では、RDPがどのように攻撃されるのか、そして情シス1人体制でも実施できる現実的な防御手順を現場目線で解説します。予算ゼロでもリスクを大幅に下げられる設定変更を中心に紹介しますので、今日から動ける内容になっています。
RDP(リモートデスクトップ)とは?なぜ攻撃者に狙われるのか
RDP(Remote Desktop Protocol)はMicrosoftが開発したリモートアクセス技術で、ネットワーク越しにWindowsのデスクトップ画面を操作できるプロトコルです。中小企業では「社内PCに外からアクセスして作業する」「サーバーの管理画面を操作する」といった用途で広く使われています。
ところが、このRDPは攻撃者にとって非常に魅力的なターゲットです。理由は単純で、認証さえ突破すれば対象のWindowsマシンをそのまま乗っ取れるからです。正規のリモートデスクトップ接続に成功した攻撃者は、ファイル操作・ソフトウェアインストール・ネットワーク探索など、ログインユーザーと同じ権限で何でもできてしまいます。
セキュリティ調査会社の複数レポートで、ランサムウェア感染の初期侵入経路としてRDPが長年にわたりトップ3に入り続けています。インターネットに直接RDPポート(デフォルト3389/TCP)を公開していると、Shodanなどのスキャナーに即座に検出され、世界中から自動攻撃が飛んでくることになります。
攻撃の仕組み(敵を知る)
RDPを狙った攻撃は大きく3つのパターンに分かれます。防御手順を正しく理解するために、まず攻撃者の動き方を押さえておきましょう。
1. ブルートフォース攻撃・パスワードスプレー攻撃
最も一般的な手口です。Shodan(インターネット接続機器の検索エンジン)などで3389ポートを公開しているIPアドレスを自動収集した後、大量のパスワードを試し続けます。
・ブルートフォース攻撃: 特定のアカウントに対して無数のパスワードを次々に試す
・パスワードスプレー攻撃: 「Password1」「Welcome2024」など使いまわされやすいパスワードを、多数のアカウントに少しずつ試す(アカウントロックを回避するために低速で行う)
・クレデンシャルスタッフィング: 過去のデータ侵害で流出したID・パスワードの組み合わせをそのまま試す
「うちのパスワードは複雑だから大丈夫」と思っていても、過去に別サービスで流出した認証情報が使われるケースがあります。RDPをインターネットに直接公開している状態は、それだけで根本的にリスクが高いと認識してください。
2. RDPを悪用したランサムウェア感染ルート
RDPへの不正アクセスに成功した攻撃者がどう動くか、典型的な流れを示します。
# 攻撃者の典型的な侵害ルート(概念図) # Step1: インターネットスキャン → 3389ポート公開IPリスト収集 # Step2: ブルートフォース or 流出クレデンシャルでRDP認証突破 # Step3: ログイン成功 → 管理者権限があれば即座に横展開 # Step4: ウイルス対策ソフトを無効化 / バックアップを破壊 # Step5: ランサムウェアを展開 → 全社ファイル暗号化
ランサムウェア攻撃グループはRDPへのアクセス権限を「ダークウェブ上で売買」しているケースもあります。最初に侵入した攻撃者が権限を売り渡し、別の犯罪グループがランサムウェアを展開するという分業体制が確立されています。侵入から暗号化まで数分で完了することもあります。
3. 既知の脆弱性(CVE)の悪用
RDP実装自体にも過去、重大な脆弱性が複数発見されています。Windowsのセキュリティパッチが当たっていない古い環境では、認証なしでリモートコード実行が可能なレベルの脆弱性が放置されているリスクがあります。「まだ動いているから問題ない」と古いOSを使い続けている場合は特に注意が必要です。
具体的な防御手順
実際に設定できる防御手段を紹介します。難易度の低いものから順番に取り組んでください。
1. RDPをインターネットに直接公開しない(最優先)
これが最も効果的な対策です。RDPはVPNの内側に閉じ込め、VPN経由でのみアクセスできる構成にします。インターネット側からのポート3389へのアクセスをファイアウォール・ルーターで完全に遮断することで、RDP自体が外部から見えない状態にできます。
・推奨構成: インターネット → VPN認証 → 社内ネットワーク → RDP接続
・コスト感: WireGuardやOpenVPNを使った自前VPNは無料で構築可能(Linuxベースのネットワーク設定については姉妹サイトLinuxMaster.JPも参考にしてください)
・クラウド活用: Microsoft Entra ID(旧Azure AD)のアプリケーションプロキシを使えば、VPN不要でより安全なRDPアクセスを実現できる
2. NLA(ネットワークレベル認証)を有効にする
NLA(Network Level Authentication)は、RDPのログイン画面を表示する「前」に認証を完了させる仕組みです。未認証の段階でセッションが確立されないため、ログイン画面そのものの脆弱性を突く攻撃を防げます。
# NLAの有効化をレジストリで確認・設定する(PowerShell) # 現在の設定確認(1 = NLA有効、0 = NLA無効) reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication # NLAを有効化(変更後は再起動不要、即時反映) reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 1 /f # GUIから設定する場合: # [コントロールパネル] → [システム] → [リモートの設定] # → [ネットワーク レベル認証でリモート デスクトップを実行しているコンピューターからのみ接続を許可する] # のラジオボタンを選択
3. Windowsファイアウォールで接続元IPを制限する
RDPへの接続を許可するIPアドレスを特定のIP(自宅・拠点・VPNゲートウェイ)に限定します。「どこからでも接続できる」状態を終わらせるだけで、自動攻撃の大半を遮断できます。
# Windows Defenderファイアウォール(PowerShell管理者権限で実行) # 既存のRDP全許可ルールを削除 Remove-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)" -ErrorAction SilentlyContinue # 特定IPからのみ3389を許可(例: 203.0.113.10 が拠点やVPNゲートウェイのIP) New-NetFirewallRule -DisplayName "RDP-Allow-Specific-IP" ` -Direction Inbound ` -Protocol TCP ` -LocalPort 3389 ` -RemoteAddress 203.0.113.10 ` -Action Allow # 複数IPを許可する場合はカンマ区切りで指定 # -RemoteAddress 203.0.113.10,198.51.100.20 # 設定確認 Get-NetFirewallRule -DisplayName "RDP-Allow-Specific-IP" | Get-NetFirewallAddressFilter
4. アカウントロックポリシーを設定する
一定回数のログイン失敗でアカウントをロックするポリシーを設定します。ブルートフォース攻撃で何万回もパスワードを試すことができなくなります。
# グループポリシーエディタ(gpedit.msc)での設定場所: # コンピュータの構成 → Windowsの設定 → セキュリティの設定 # → アカウントポリシー → アカウントロックアウトのポリシー # 推奨値: # アカウントのロックアウトのしきい値: 5回 # ロックアウト カウンターのリセット: 30分後 # アカウントのロックアウト期間: 30分 # 現在のポリシーをコマンドで確認 net accounts
5. Administratorアカウントを無効化し、専用アカウントを使う
攻撃者が最初に試すのは「Administrator」や「admin」「user」といったデフォルトのアカウント名です。ビルトインのAdministratorアカウントを無効化し、推測されにくい名前のアカウントだけでRDPを許可することで、攻撃の難度を大幅に上げられます。
# ビルトインAdministratorアカウントを無効化(PowerShell管理者権限) Disable-LocalUser -Name "Administrator" # 新しい管理者アカウントを作成(名前は推測されにくいものに) $securePass = Read-Host -AsSecureString "新しいパスワードを入力" New-LocalUser -Name "sysop2024" -Password $securePass -FullName "System Operator" Add-LocalGroupMember -Group "Administrators" -Member "sysop2024" # RDP接続を許可するグループに追加 Add-LocalGroupMember -Group "Remote Desktop Users" -Member "sysop2024"
6. RDPポート番号を変更する(補助的な対策)
デフォルトの3389から別のポートに変更することで、自動スキャンによる検出を一時的に減らせます。ただし「隠すセキュリティ」は根本的な対策ではないため、必ず上記の対策と組み合わせた補助手段として位置づけてください。
# レジストリでRDPポートを変更(例: 53389に変更) reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 53389 /f # ファイアウォールで新しいポートを許可 New-NetFirewallRule -DisplayName "RDP-Custom-Port" -Direction Inbound -Protocol TCP -LocalPort 53389 -Action Allow # 変更後はWindowsを再起動して反映 # 接続時はクライアント側で「ホスト名:53389」と入力して接続
中小企業でも今日からできること
「VPN構築は難しい」「すぐには変更できない」という場合も、以下の項目だけは今日中に確認してください。
・まずShodan.ioで自社IPを検索: アカウント不要の基本検索で、3389ポートが公開されているか確認できる
・パスワードを強化する: RDPで使うアカウントのパスワードを16文字以上のランダムな文字列に今すぐ変更する
・MFAを有効化する: Microsoft Entra ID(旧Azure AD)を使っている場合、Microsoft Authenticatorと連携したMFA適用が可能
・Windowsイベントログを確認する: イベントID 4625(ログイン失敗)が大量に記録されていないかイベントビューアーで確認する
・使っていないPCのRDPを無効化する: リモートデスクトップを使っていないPCではRDPを完全に閉じる
# 使用していないPCでRDPを完全に無効化する(PowerShell管理者権限) Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 1 Disable-NetFirewallRule -DisplayGroup "Remote Desktop" # RDPの有効・無効の現在状態を確認 Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections # 0 = RDP有効、1 = RDP無効 # ログイン失敗の直近ログを確認(PowerShell) Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 | Select-Object TimeCreated, Message | Format-List
よくある誤解と注意点
【注意】「VPNを使っているから大丈夫」は半分正解
VPN経由でRDPを使う構成は基本的に正しい方向性ですが、VPN自体の認証が突破されれば内側のRDPも危険になります。VPN自体にもMFAを適用し、VPNと組み合わせてもRDP側のアカウントロックポリシーとNLAは必ず設定してください。多層防御が重要です。
【注意】「ポートを変えれば安全」は誤解
ポート番号の変更は「見えにくくする」効果しかなく、Nmapなどのスキャナーを使えば開いているポートはすぐに特定されます。IP制限・VPN閉じ込め・NLAの組み合わせが根本的な対策です。ポート変更はあくまで補助的な手段です。
【注意】クラウドVMのRDP開放は特に危険
AWS・Azure・GCPなどのクラウドVMでRDPを「0.0.0.0/0(全インターネット)」に開放している設定は、オンプレミス以上に危険です。グローバルIPが固定されているためスキャン対象になりやすく、攻撃の頻度も高くなります。セキュリティグループ・ファイアウォールルールで、RDPを特定IPまたはVPN経由のみに制限してください。
【注意】ログを監視しないと攻撃に気づけない
攻撃に気づくためにはWindowsイベントログの監視が不可欠です。イベントID 4625(ログイン失敗)・4648(別資格情報での明示的ログオン)・4778/4779(RDPセッションの接続・切断)を定期的に確認する習慣をつけましょう。SIEMがない環境でも、イベントビューアーからの手動確認や、PowerShellスクリプトによる定期チェックは実施できます。
本記事のまとめ
| 対策 | 効果 | 難易度 |
|---|---|---|
| VPN経由のみRDP許可 | インターネット直接露出を完全遮断 | 中(VPN構築が必要) |
| 接続元IPをファイアウォールで制限 | 不特定多数からの攻撃を遮断 | 低(設定変更のみ) |
| NLA(ネットワークレベル認証)有効化 | 未認証段階の脆弱性悪用を防止 | 低(設定変更のみ) |
| アカウントロックポリシー設定 | ブルートフォース攻撃を実質無効化 | 低(グループポリシー変更) |
| Administratorアカウント無効化 | デフォルトアカウント狙い攻撃を防止 | 低(アカウント操作のみ) |
| MFA(多要素認証)の適用 | パスワード漏洩時も乗っ取りを防止 | 中(認証基盤が必要) |
| ポート番号変更 | 自動スキャンの検出を一時的に低減(補助) | 低(レジストリ変更) |
| 不要なRDPの完全無効化 | 攻撃面そのものを削減 | 低(コマンド1行) |
RDPは便利なツールですが、設定を誤るとランサムウェア感染の玄関口になります。「インターネットに直接3389を公開しない」という一点を徹底するだけで、リスクを劇的に下げられます。情シス1人体制でも、今日紹介した設定変更の多くは数時間以内に実施できます。まずは自社のRDP公開状況をShodanで確認するところから始めましょう。
「中小企業のセキュリティ」の記事を読む
このテーマに関連する解説記事を一覧でまとめています。あわせてご覧ください。
