Windowsクライアントのリモートデスクトップ接続状態を追跡、監視するための超お手軽なヒント集：山市良のうぃんどうず日記（200）

新型コロナウイルス感染症の感染拡大が続く中、企業にはテレワークのさらなる推進が求められています。出社せずに自宅などから会社の業務用PC環境にアクセスする方法として、Windows標準の「リモートデスクトップ接続」を利用しているところもあるでしょう。しかし、この方法を安易に導入することは、企業ネットワークをサイバー攻撃の標的にさらしてしまうことになります。

» 2021年02月10日 05時00分公開

[山市良，テクニカルライター]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

山市良のうぃんどうず日記

Azure ADアプリケーションプロキシを使用した社内リソースへの安全なRDP接続（お勧め）

　アプリケーションプロトコルとして「リモートデスクトッププロトコル（RDP）」を使用する「リモートデスクトップ接続」には、Windows Serverの「リモートデスクトップサービス（RDS）」を使用したセッションベースまたは仮想マシンベースのリモートデスクトップ接続（前者はWindows Serverへのマルチセッション接続、Windows Enterprise仮想マシンプールへの接続、いわゆるVDI）と、WindowsクライアントのProエディション以上が備える1対1のリモートデスクトップ接続のサーバ機能があります。

　クライアントとしては、Windowsの全エディションに加え、さまざまなプラットフォームに対応したリモートデスクトップ接続アプリやHTML5対応ブラウザベースの「リモートデスクトップWebクライアント」を利用できます。

　企業で社外から社内リソースへのリモートデスクトップ接続を可能にするには、企業内にRDSを展開し、ネットワークの境界に「RDゲートウェイ」を設置して、TCPポート「443」の「HTTPS」でカプセル化（RDP over HTTPS）した上でリモートデスクトップ接続を保護することが推奨されます。RDゲートウェイでは信頼された証明書でのサーバ認証による接続許可／拒否が可能な他、集中的に接続状況を管理でき、強制的な切断や機能制限（クリップボードやリダイレクトの不許可など）を実施できます（画面1）。

画面1　RDゲートウェイを含むRDSを企業内に展開すると、RDPをHTTPSでカプセル化して保護しながら、接続状況を集中的に監視できる

　さらに、クラウドサービスである「Azure Active Directory（Azure AD）アプリケーションプロキシ」を使用すると、企業ネットワークへの直接的な接続を完全にブロックしながら、2段階認証と条件付きアクセスを追加し、社内リソースへの安全なRDP接続を発行することができます。これに似たソリューションはWindows Serverの「Webアプリケーションプロキシ」でも構築可能ですが、現在はAzure ADアプリケーションプロキシによる発行が推奨されています。

Azure ADアプリケーションプロキシを使用したリモートデスクトップの発行（Microsoft Docs）

　しかしながら、この方法はRDSシステムの設計と構築に加え、「RDSクライアントアクセスライセンス（RDS CAL）」や「Virtual Desktop Access（VDA）」ライセンスを購入する必要があるため、素早く導入できるというものではなく、コストもかかります。

　だからといって、RDSやその他のソリューションのためにコストをかけることなく、単純に社内のWindows PCに対するRDPのTCPポート「3389」への社外からの接続を許可してしまうこと、例えばポートフォワーディングなどを利用して企業内の複数のWindows PCに接続できる状態にしてしまうことは、大きなセキュリティ上のリスクを伴います。

　これは、ユーザー名とパスワードの組み合わせだけの認証で、認証失敗をロックアウトする機能も持ちません。それがインターネット全体に公開されてしまうのです。あなたの自宅の玄関をピッキングして開けようとしている不審者が四六時中、次々にやってくることを想像してみてください。もし、そのような方法でリモートデスクトップ接続を許可したいのなら、最低でも接続元のIPアドレスでフィルタリングすべきです。ポート番号を「3389」以外に変更したとしても、リスクが低減されることはありません。

　このことを踏まえて、RDSを展開していない環境で、リモートデスクトップ接続を監視する方法を幾つか紹介します。不用意に開放してしまったRDPのポートに対して、攻撃が試行されていないかどうか、不審なアクセスが行われていないかどうかを調査する際に参考になるはずです。

追跡／監視のヒント1：イベントログ

　ログオンの成功／失敗は、Windowsの「セキュリティ」ログのセキュリティ監査イベントを調査することで、追跡することができます。「Windows 10」と「Windows Server 2016」の場合は、ログオンイベントの「ワークステーション名」や「ソースネットワークアドレス」で接続元の情報を取得できるでしょう（画面2）。

画面2　セキュリティ監査ログのログオンイベントで接続元のIPアドレス情報を取得できる

　「Windows 8.1」と「Windows Server 2012 R2」以前の場合は、「ソースネットワークアドレス」が記録されないという不具合があるようです。その場合でも、「アプリケーションとサービス」の「Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational」ログのイベントID「131」で接続元のIPアドレスの情報（画面3）、イベントID「102」で接続の終了を、イベントID「103」で切断理由を、それぞれ確認できます。

画面3　「Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational」ログでもRDP接続要求を追跡することができる

　切断理由は10進数の番号で記録されますが、16進数での一覧を以下のドキュメントで確認することができます。例えば、ユーザーの明示的な操作による切断は「11」（0x0000000B）、ログオフは「12」（0x0000000C）で判断できます。

2.2.5.1.1 Set Error Info PDU Data（TS_SET_ERROR_INFO_PDU）［英語］（Microsoft Docs）

　なお、この一覧にない切断理由もあるようです。Windows 10 バージョン20H2で存在しないユーザー名や、誤ったパスワードで認証を失敗させたところ切断理由「4408」（0x00001138）が記録されました。

追跡／監視のヒント2：Sysmonログ

　Windows Sysinternalsの「System Monitor（Sysmon）」を使用すると、ネットワーク接続要求を含む、さまざまなイベントをイベントログに記録することができます。

Sysmon［英語］（Windows Sysinternals）

　例えば、構成ファイル「config.xml」を以下のように作成し、次の2つのコマンドラインでSysmonをシステムにインストールすると、TCP/UDPポート「3389」に対する着信要求とクリップボードの共有操作を追跡することができます（画面4）。

<Sysmon schemaversion="4.50">
  <EventFiltering>
    <ProcessCreate onmatch="include" />
    <ProcessTerminate onmatch="include" />
    <DriverLoad onmatch="include" />
    <ImageLoad onmatch="include" />
    <FileCreateTime onmatch="include" />
    <CreateRemoteThread onmatch="include" />
    <RawAccessRead onmatch="include" />
    <NetworkConnect onmatch="include">
      <DestinationPort>3389</DestinationPort>
    </NetworkConnect>
    <ClipboardChange onmatch="exclude" />
  </EventFiltering>
</Sysmon>

▲「config.xml」（「sysmon -s」を実行して最新のスキーマバージョンを確認し、適宜書き換えてください）

sysmon -i -n accepteula
sysmon –c config.xml

画面4　Sysmonを利用したRDP接続要求とクリップボード共有操作の監視ログ

　「ClipboardChange」フィルターは2021年1月にリリースされたSysmon v12.0からのリモートデスクトップ接続の新しいキャプチャー機能です（本稿執筆時点の最新バージョンはv13.01）。Sysmonのログは、「アプリケーションとサービス」の「Microsoft-Windows-Sysmon/Operational」ログに記録されます。

　ここで少し応用してみましょう。システムにSysmonをインストールしたら、次のPowerShellスクリプト「monitorsysmon.ps1」を実行してみてください。10秒間隔で「Microsoft-Windows-Sysmon/Operational」ログをチェックし、新しいログが記録されるとログの内容を出力するというスクリプトです（画面5）。

$lastRecordId = 0
while ($true) {
  $events = Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational -FilterXpath "*[System[TimeCreated[timediff(@SystemTime) <= 3600000]]]" | Sort -property RecordId
  if ($events.Count -ne 0) {
    if ($lastRecordId -eq 0) {
      foreach ($event in $events) {
        $lastRecordId = $event.RecordId
      }
    } else {
      foreach ($event in $events) {
        if ($event.RecordId -gt $lastRecordId) {
           Write-Host "-------------------------------"
           Write-Host $event.Message
           $lastRecordId = $event.RecordId
        }
      }
    }
  }
  Start-Sleep -seconds 10
}

▲「monitorsysmon.ps1」

画面5　Sysmonのログを10秒間隔でチェックして、新しいログを画面に出力する「monitorsysmon.ps1」

　Sysmonによる監視を終了するには、「sysmon -u」を実行してシステムからSysmonをアンインストールします。

追跡／監視のヒント3：QUERY SESSIONとPSTerminalServices

　Windows ServerのRDSの環境では「RemoteDesktop」モジュールのコマンドレット（「Get-RDUserSession」など）を利用できますが、RDSの役割がインストールされていないWindows ServerやWindowsクライアントではリモートデスクトップ接続に対応したコマンドレットは標準搭載されていません。

　現在のアクティブセッションについては、Windows標準の「QUERY SESSION」コマンドを利用できますが、取得できる情報が限られます。

　「PowerShell Gallery」やGitHubで公開されている「PSTerminalServices」モジュールは、QUERY SESSIONコマンドの高機能なPowerShell版のようなもので、例えば、「Get-TSSession」コマンドレットはソースIPアドレス、クライアントのOSビルド、接続時間などを含む詳細な情報を取得することができます（画面6）。

PSTerminalServices 1.0［英語］（PowerShell Gallery）
imseandavis / PSTerminalServices（GitHub）

画面6　PSTerminalServicesモジュールのコマンドレットを利用すると、QUERY SESSIONコマンドよりも詳細な接続情報を取得できる

筆者紹介

山市良（やまいちりょう）

岩手県花巻市在住。Microsoft MVP：Cloud and Datacenter Management（2019-2020）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決コマンド＆テクニック集』（日経BP社）。