【実務・中級編】ポート3389番(RDP)：リモートデスクトッププロトコルのブルートフォース攻撃とランサムウェア侵入経路としてのリスク – サイバーセキュリティとプライバシー保護実践ガイド

RDPの「3389」をインターネットに晒すという愚行――ゼロトラスト時代の境界防御とランサムウェア対策

深夜2時、電話が鳴る。画面の向こうで真っ赤に染まったサーバー群。ランサムウェアの身代金要求メッセージ。エンジニア人生で最も見たくない光景の一つだ。そのインシデントの火種が、往々にして「インターネットに直結されたTCP/3389（RDP）」にあることを、君たちは知っているだろうか？

今日は、教科書的な「RDPは危険です」という警告を超えて、なぜそれが攻撃者の入り口になり、現場のエンジニアとしてどう防壁を構築すべきか、その「泥臭い現実」を語ろうと思う。

—

1. なぜRDPは「ランサムウェアの正面玄関」なのか

攻撃者は、世界中に散らばる脆弱なポートをスキャンしている。TCP/3389 は、彼らにとっての「開けっ放しの金庫」だ。

RDPの通信フローは、まず TCP 3ウェイ・ハンドシェイクから始まる。その後、RDP Security Layer と TLS によるネゴシエーションが行われる。ここで、NLA (Network Level Authentication) が無効な場合、攻撃者は「認証画面」まで辿り着くことができてしまう。

この「認証画面」こそが脆弱性だ。IDとパスワードの組み合わせを何万回と試す「ブルートフォース攻撃」や、流出した認証情報を使った「パスワードスプレー」を仕掛けられれば、防壁の薄いサーバーはあっけなく陥落する。一度ログインを許せば、そこは攻撃者の遊び場。権限昇格、横展開（ラテラルムーブメント）、そしてデータの暗号化まで、わずか数時間しかかからない。

—

2. 物理的な境界から論理的な境界へ：NLAの強制

まずは、OSレベルで最も基本的な防御策を講じる。それが NLA だ。
NLA は、ユーザーがRDPセッションを確立する「前」に、認証を要求する仕組みだ。これにより、攻撃者は認証完了前にセッションリソースを消費させられるリスクから解放され、より強固な防御が可能になる。

Windows Serverであれば、以下の設定が必須だ。

# NLAを有効にするためのレジストリ操作
# UserAuthenticationを1に設定することでNLAを強制する
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

※手動で行う場合は、「システムのプロパティ」→「リモート」タブから「ネットワークレベル認証でリモートデスクトップを実行しているコンピューターからのみ接続を許可する」にチェックを入れる。これだけで、スキャナーの多くは認証に至る前に接続を断念する。

—

3. 「インターネット直結」を卒業する：ゼロトラストの鉄則

しかし、NLA だけでは「パスワード強度」という人間の弱点に依存することになる。真の防御策は、RDPポートをインターネットから物理的に遮断することだ。

現場で推奨されるのは、VPNの利用、あるいは RD Gateway を経由したアクセスだが、現代の最適解は「ゼロトラスト・アクセス・プロキシ」だ。

Pythonによる接続確認（診断用スクリプト）

もし君たちが「今、自分の環境が公開されているか？」を確認したいなら、外部からポートの状態を叩くシンプルなスクリプトを書いてみるといい。

import socket

def check_rdp_port(ip, port=3389):
    """
    指定したIPのポートが開いているかを確認する簡易チェッカー
    """
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(3)
    result = sock.connect_ex((ip, port))
    if result == 0:
        print(f"[!] 警告: ポート {port} は開いています。直ちに閉鎖を検討してください。")
    else:
        print(f"[+] 安全: ポート {port} は閉じているか、フィルタリングされています。")
    sock.close()

# 実際の運用では自分のグローバルIPに向けて実行する
check_rdp_port("203.0.113.1")

—

4. 多要素認証（MFA）をRDPに組み込む

VPNを導入できない小規模環境や、どうしてもリモート接続が必要な場合は、DUO や Microsoft Entra ID Application Proxy を活用して、RDP接続に MFA を強制する設計が必須だ。

特に Microsoft Entra ID と連携した Conditional Access を活用すれば、以下のようなポリシーが構築できる。

1. 場所の制限: 許可されたIPレンジからのみ接続を許可。
2. デバイスの健全性: セキュリティパッチが当たったIntune管理デバイスからのみ接続を許可。
3. MFAの強制: 接続時にスマホアプリでの承認を要求。

これらを組み合わせることで、万が一パスワードが漏洩しても、攻撃者が最終的なデスクトップ画面を拝むことは不可能になる。

—

5. 最後に：現場のエンジニアへ

僕がトラブルシューティングの現場で痛感するのは、「設定一つで防げた悲劇」の多さだ。3389 を開けることは、鍵のかかっていない玄関を大通りに面して設置するのと同じ。

鉄則1: インターネットから 3389 への直接到達を禁止する。
鉄則2: VPNまたはゼロトラストプロキシを必ず挟む。
鉄則3: NLA を有効にし、強固なパスワードと MFA を組み合わせる。

ネットワークセキュリティは、完璧な壁を作ることではなく、攻撃者のコストを跳ね上げさせ、彼らに「ここを狙うのは割に合わない」と思わせるゲームだ。君たちの守るインフラが、ランサムウェアの餌食にならないことを心から祈っている。

何かあれば、ログを見ろ。パケットは嘘をつかない。それが、凄腕への第一歩だ。