Как защитить и оптимизировать RDP: Gateway, MFA, NLA и диагностика

RDP удобен для администрирования и терминальной работы, но его безопасность зависит от пути доступа, учётных записей и настроек хоста. Открытие TCP 3389 в Интернет с длинным паролем не заменяет защищённый шлюз и многофакторную проверку. Ниже — порядок настройки для Windows и Windows Server, проверки сети и журналов, а также поиска причин медленной работы.

1. Проверьте редакцию Windows и назначение сервера

Уточните, нужна ли удалённая административная сессия или многопользовательский сервис RDS. Windows Home может быть клиентом, но не штатным хостом Remote Desktop. Для RDS проверьте роли и лицензирование; обычная административная возможность Windows Server не заменяет терминальное развёртывание. Разрешённые редакции и порядок включения описаны в документации Microsoft Remote Desktop.

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-Service TermService
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue

Отсутствие listener может означать, что RDP выключен, служба остановлена или порт изменён. Само прослушивание порта не доказывает его доступность снаружи. Сохраните исходные политики и доступ к консоли перед изменением сети или аутентификации.

2. Постройте защищённый путь доступа

Предпочтительный путь для внешнего пользователя: управляемое устройство → VPN с MFA или RD Gateway → разрешённый внутренний хост. На внешнем экране не должно быть прямого DNAT 3389 к рабочей станции. Gateway использует HTTPS и политики допуска; правила CAP определяют, кто может подключиться, а RAP — к каким ресурсам.

Сертификат шлюза должен соответствовать имени и быть доверенным клиенту. Не учите сотрудников игнорировать предупреждения сертификата. Архитектура описана в документации RD Gateway. Отдельно ограничьте доступ шлюза к внутренним RDP-хостам и права администраторов шлюза: наличие одной защищённой точки входа не оправдывает свободный доступ ко всей сети.

3. Включите NLA и проверьте MFA на фактическом входе

NLA требует аутентификацию до создания полноценной удалённой сессии. Это полезный уровень защиты, но не второй фактор. MFA должна реально участвовать в выбранном пути входа, включая обходные маршруты и резервные профили VPN.

Состояние NLA можно прочитать через CIM, если соответствующий провайдер доступен на вашей ОС:

$cim = @{
    Namespace = 'root/cimv2/terminalservices'
    ClassName = 'Win32_TSGeneralSetting'
    Filter = "TerminalName='RDP-tcp'"
}
Get-CimInstance @cim |
    Select-Object TerminalName, UserAuthenticationRequired, SecurityLayer

Для локального хоста откройте sysdm.cpl → «Удалённый доступ» и включите требование проверки подлинности на уровне сети для разрешённых RDP-подключений. В домене задайте Enabled для политики Require user authentication for remote connections by using Network Level Authentication в Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security. Затем проверьте результирующую политику и вход. Для RD Gateway возможна интеграция с NPS extension и Microsoft Entra MFA, но она требует выполнения условий и настройки политик из официального руководства. Проверьте положительный вход, отказ без второго фактора и недоступность прямого маршрута.

4. Ограничьте сеть хоста и проверьте все разрешающие правила

Сначала выясните, какие правила реально применены. Названия стандартных правил могут отличаться по сборке; запрос ниже показывает распространённые имена и их фильтры.

$rules = Get-NetFirewallRule -PolicyStore ActiveStore |
    Where-Object Name -Like 'RemoteDesktop*'
$rules | Select-Object Name, Enabled, Direction, Action, Profile,
    PolicyStoreSourceType
$rules | Get-NetFirewallAddressFilter |
    Select-Object InstanceID, LocalAddress, RemoteAddress
$rules | Get-NetFirewallPortFilter |
    Select-Object InstanceID, Protocol, LocalPort

Добавление нового узкого allow-правила не ограничивает старое широкое allow. Проверьте также другие правила порта и правила GPO. Для выбранного локального правила сохраните исходные параметры и задайте только согласованную подсеть VPN или адреса Gateway. Пример ниже не применяйте, если выбранное правило поступает из GPO или у вас нет резервной консоли.

$name = 'RemoteDesktop-UserMode-In-TCP'
Get-NetFirewallRule -Name $name | Get-NetFirewallAddressFilter |
    Export-Clixml 'C:\AdminReports\rdp-address-before.xml'
Set-NetFirewallRule -Name $name -RemoteAddress '10.50.0.0/24'

Путь отчёта создайте заранее и ограничьте доступ. Аналогично исследуйте UDP и другие правила. Возврат выполняется восстановлением записанных адресов только затронутого правила, а не выключением firewall целиком.

Найдите также правила с произвольными именами. Этот поиск выбирает активные входящие Allow для TCP/UDP/Any, у которых LocalPort включает 3389, диапазон с ним или Any. Он читает правила, но не меняет их:

function Test-PortIncluded($ports, [int]$target) {
    foreach ($port in @($ports)) {
        if ($port -eq 'Any') { return $true }
        if ($port -match '^\d+$' -and [int]$port -eq $target) { return $true }
        if ($port -match '^(\d+)-(\d+)$') {
            if ($target -ge [int]$Matches[1] -and
                $target -le [int]$Matches[2]) { return $true }
        }
    }
    return $false
}
Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound -Action Allow |
    Where-Object Enabled -EQ 'True' | ForEach-Object {
        $rule = $_
        $port = $rule | Get-NetFirewallPortFilter
        if ($port.Protocol -in @('TCP','UDP','Any','6','17','256') -and
            (Test-PortIncluded $port.LocalPort 3389)) {
            $address = $rule | Get-NetFirewallAddressFilter
            [pscustomobject]@{
                Name = $rule.Name; Profile = $rule.Profile
                Source = $rule.PolicyStoreSourceType
                Protocol = $port.Protocol; Port = $port.LocalPort -join ','
                RemoteAddress = $address.RemoteAddress -join ','
            }
        }
    } | Format-Table -Wrap

Если RDP работает на другом порту, замените target. Широкие правила могут иметь ограничения по программе, service или интерфейсу: исследуйте соответствующие фильтры, прежде чем считать любой найденный Any безусловным доступом. Сетевой экран перед хостом проверяется отдельно. Для выбранного локального TCP-правила возврат адресов из сохранённой копии выполняется так:

$old = Import-Clixml 'C:\AdminReports\rdp-address-before.xml'

Примените сохранённые адреса к тому же локальному правилу:

$restore = @{
    Name = 'RemoteDesktop-UserMode-In-TCP'
    RemoteAddress = $old.RemoteAddress
}
Set-NetFirewallRule @restore

Копия должна соответствовать именно этому правилу. Если оно пришло из GPO или изменилось после вашей операции, согласуйте возврат в исходной политике.

5. Выдайте минимальные права

Разрешите вход только согласованной группе и проверьте Allow log on through Remote Desktop Services вместе с соответствующим deny. Членство в Remote Desktop Users не отменяет запрет результирующей политики. У обычного сотрудника нет необходимости получать local administrator ради RDP.

Отдельно задайте правила для clipboard, дисков, принтеров, USB и перенаправления устройств. Это каналы переноса данных, а не только удобство интерфейса. Для административного хоста отключайте ненужные перенаправления; для рабочих процессов оставляйте согласованный минимум. Учитывайте влияние GPO, RD Collection и клиента: пользовательский переключатель не всегда является окончательной политикой.

6. Проверьте доступ с разных точек

Из разрешённой сети выполните TCP-проверку и интерактивный вход. Из внешней согласованной точки проверьте отсутствие прямого доступа к 3389. Результат из локальной сети не описывает правила внешнего firewall.

Test-NetConnection rdp01.example.internal -Port 3389
quser /server:rdp01

TCP-тест не проверяет UDP, MFA, сертификат и права пользователя. Приёмка требует реального входа с правильным именем хоста и проверки отказа для неразрешённой учётной записи. Публичное имя шлюза и внутреннее имя рабочего хоста должны соответствовать схеме, а не случайному IP, сохранённому у пользователя.

7. Исследуйте входы и завершения сессий

Используйте Security, TerminalServices-LocalSessionManager и RemoteConnectionManager. Событие 4624 нужно читать с LogonType=10, а не считать каждый успешный вход событием RDP. Событие 1149 отражает этап аутентификации и само по себе не доказывает полноценную рабочую сессию. Различайте disconnect, logoff и повторное подключение к существующей сессии.

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'
    StartTime = (Get-Date).AddHours(-2)
} -MaxEvents 200 | Select-Object TimeCreated, Id, RecordId, Message

Для автоматической обработки разбирайте XML-поля, а не локализованный Message. Размер Security и сроки хранения должны позволять расследовать событие до ротации. Пересылайте журналы в принятую систему контроля и ограничьте права их чтения. Не публикуйте адреса пользователей и содержимое сессий в открытых уведомлениях.

Для конкретного окна извлеките успешные удалённые входы из XML. Значения Subject и Target не смешиваются; здесь выводится TargetUserName и LogonType 10:

$events = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4624; StartTime = (Get-Date).AddHours(-2)
} -ErrorAction Stop
foreach ($event in $events) {
    [xml]$xml = $event.ToXml()
    $data = @{}
    foreach ($d in $xml.Event.EventData.Data) {
        $data[[string]$d.Name] = [string]$d.'#text'
    }
    if ($data.LogonType -eq '10') {
        [pscustomobject]@{
            TimeUtc = $event.TimeCreated.ToUniversalTime().ToString('o')
            RecordId = $event.RecordId
            User = "$($data.TargetDomainName)\$($data.TargetUserName)"
            LogonId = $data.TargetLogonId
            SourceAddress = $data.IpAddress
        }
    }
}

Если подходящих 4624 нет, Get-WinEvent может вернуть NoMatchingEventsFound; не подменяйте его ошибкой прав доступа. Пустой или proxy-адрес требует дополнительных журналов. Поля 4624 описаны в официальном справочнике Microsoft.

8. Разделите сеть, ресурсы и графику при медленной работе

Сначала сравните RTT, потери, маршрут VPN и стабильность канала; затем CPU, память и storage хоста в момент жалобы. Если тормозит только одно приложение, исследуйте его базу и серверные зависимости. Если зависает весь экран одновременно у всех пользователей, вероятнее общая проблема узла или пути доступа.

Проверьте, используется ли ожидаемый транспорт и разрешены ли необходимые UDP-потоки по принятой архитектуре. Не выключайте шифрование или NLA для ускорения. Для слабого канала можно уменьшить разрешение, число экранов и необязательные графические эффекты клиента, а затем измерить изменение. Перенаправленные принтеры и диски тоже могут влиять на вход и работу.

Проверьте счётчики TCP- и UDP-подключений RemoteFX/RDP, доступные на конкретном хосте. Названия наборов локализованы; сначала обнаружьте их, а не вставляйте английскую строку без проверки:

Get-Counter -ListSet * | Where-Object CounterSetName -Match 'RemoteFX|RDP' |
    Select-Object CounterSetName, PathsWithInstances

Если набор отсутствует, это не доказывает работу только TCP. Дополнительно соберите сетевую трассу утверждённым инструментом и состояние соединения клиента. Проверьте потерю UDP между VPN/Gateway и хостом по своей архитектуре, повторите одинаковую пользовательскую операцию и запишите RTT/потери/время ответа. Сравнивайте одно изменение за раз — например, отключение ненужного printer redirection — с тем же пользователем и приложением.

9. Обновляйте систему и управляйте тайм-аутами

Установите поддерживаемые обновления ОС, клиента и Gateway по процедуре тестирования. Устаревшие обходы для NT4, Windows XP и старых алгоритмов не переносите на текущие версии. Проблему после обновления подтверждайте конкретной сборкой, журналом и воспроизведением, а не бессрочным отключением обновлений.

Задайте ограничения неактивных и отключённых сессий с учётом приложения. Принудительный logoff может потерять несохранённые данные; тайм-аут требует согласования с владельцем процесса. Сохраняйте доступ через консоль и предусмотрите восстановление конкретной политики при ошибке. Изменять одновременно транспорт, firewall, MFA и GPO трудно диагностировать: внедряйте проверяемыми этапами.

10. Примите результат по проверяемым критериям

Зафиксируйте путь входа, поддерживаемые ОС, сертификаты, CAP/RAP или VPN-политики, разрешённые группы, NLA, MFA и сетевые ограничения. Проверьте успешный вход сотрудника, отказ лишнему пользователю, отказ при непрохождении MFA и недоступность прямого RDP из Интернета.

Дополнительно измерьте отклик типового приложения, восстановление после разрыва связи, тайм-ауты и поступление событий в центральные журналы. Сохраните исходные настройки и план возврата отдельных изменений. RDP защищён и пригоден к работе, когда подтверждены и безопасность пути, и права, и качество пользовательской сессии.

Связанные инструкции: настройка OpenVPN, аудит изменений AD.