Защита RDP: NLA, блокировка перебора паролей, смена порта и доступ через VPN

Если сервер с открытым в интернет RDP проработал хотя бы сутки, загляните в журнал безопасности: почти наверняка там сотни или тысячи неудачных попыток входа под именами Administrator, admin, user, buh и т. п. Это работают автоматические сканеры, которые перебирают пароли на всех найденных адресах с открытым портом удалённого рабочего стола. Ниже по порядку разберу, что реально защищает RDP, а что только создаёт видимость защиты.

Коротко: лучшая защита — не публиковать RDP в интернет напрямую, а пускать пользователей через VPN или шлюз удалённых рабочих столов (RD Gateway). Дополнительно обязательно включить NLA, настроить политику блокировки учётных записей, разрешить RDP только нужным группам, следить за событиями 4625 и по возможности добавить второй фактор. Смена порта 3389 на другой снижает шум в журналах, но от целенаправленного подбора не спасает.

Главное правило: RDP не должен смотреть в интернет

Почти все проблемы с перебором начинаются с проброса порта 3389 (или «нестандартного» порта) с роутера на сервер. Как только порт доступен из интернета, любой желающий может пробовать пароли столько, сколько позволит ваша политика блокировки, а каждая уязвимость в протоколе становится вашей проблемой.

Варианты, при которых сервер не виден снаружи:

  • VPN — сотрудник сначала подключается к сети офиса (WireGuard, IPsec IKEv2, OpenVPN на роутере или отдельном сервере), а уже потом запускает mstsc на внутренний адрес. Снаружи открыт только порт VPN, а без ключа или сертификата к нему не подключиться.
  • RD Gateway — роль Windows Server, которая принимает RDP, упакованный в HTTPS, на TCP 443 (и UDP 3391 для транспорта UDP) и пропускает его дальше только после проверки по политикам. Сам сервер сеансов при этом наружу не опубликован.
  • Белый список адресов — если у всех пользователей статические IP, можно разрешить входящий RDP в брандмауэре только с них. Это не замена VPN, но уже резко сокращает поверхность атаки.

Ограничить правило брандмауэра Windows по адресам можно так (имена встроенных правил не зависят от языка системы):

Set-NetFirewallRule -Name "RemoteDesktop-UserMode-In-TCP" -RemoteAddress 203.0.113.10,198.51.100.0/24
Set-NetFirewallRule -Name "RemoteDesktop-UserMode-In-UDP" -RemoteAddress 203.0.113.10,198.51.100.0/24

Адреса в примере — документационные, подставьте свои.

NLA: проверка подлинности до создания сеанса

Network Level Authentication (проверка подлинности на уровне сети) заставляет клиента предъявить учётные данные ещё до того, как сервер создаст сеанс и покажет экран входа. Без NLA каждая попытка подключения поднимает на сервере полноценный экран входа, что тратит ресурсы и даёт атакующему больше простора.

Где включается:

  • в свойствах системы на вкладке «Удаленный доступ» — флажок про разрешение подключений только с проверкой подлинности на уровне сети;
  • групповой политикой: Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity → Require user authentication for remote connections by using Network Level Authentication = Enabled.

Проверить текущее состояние можно через PowerShell (значение 1 — NLA требуется):

(Get-CimInstance -Namespace rootcimv2TerminalServices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-Tcp'").UserAuthenticationRequired

NLA — это базовая гигиена, а не защита от подбора: пароль всё так же можно перебирать, просто дешевле для сервера. Имейте в виду, что некоторые сторонние решения двухфакторной авторизации, которые встраиваются в экран входа Windows, требуют особой настройки NLA — читайте документацию к своему продукту.

Политика блокировки учётных записей

Это то, что реально останавливает перебор: после N неудачных попыток учётная запись блокируется на заданное время. Настройки находятся в разделе Computer ConfigurationWindows SettingsSecurity SettingsAccount PoliciesAccount Lockout Policy (локально — secpol.msc, в домене — политика домена через gpmc.msc):

  • Account lockout threshold — число неудачных попыток до блокировки (0 — никогда не блокировать);
  • Account lockout duration — на сколько минут блокировать;
  • Reset account lockout counter after — через сколько минут сбрасывать счётчик неудачных попыток;
  • Allow Administrator account lockout — распространяется ли блокировка на встроенную учётную запись администратора.

Базовые рекомендации безопасности Microsoft — 10 попыток, 10 минут блокировки, сброс счётчика через 10 минут. На новых установках Windows 11 22H2 такие значения уже выставлены по умолчанию, а для систем, обновлённых с более старых версий, и для Windows Server их нужно задать самому. Важно и последнее значение: встроенный Administrator долго был исключён из блокировки, и именно его имя перебирают чаще всего. С обновлений октября 2022 года политика Allow Administrator account lockout позволяет блокировать и его; при этом вход с локальной консоли во время блокировки остаётся доступным, так что «запереть» себя совсем не получится.

Обратная сторона: зная имя пользователя, атакующий может специально блокировать его снова и снова. Поэтому блокировка хорошо работает вместе с закрытым снаружи RDP, а не вместо него. Сам я дополнительно переименовываю встроенного администратора или отключаю его, если есть другая административная учётная запись, и не использую очевидные логины вроде admin.

Ещё одна полезная мера — ограничить круг тех, кто вообще может входить по RDP. Это право Allow log on through Remote Desktop Services в разделе User Rights Assignment и членство в группе «Пользователи удаленного рабочего стола». Бухгалтеру нужен вход на терминальный сервер, но не на контроллер домена.

Журнал безопасности: события 4625

Каждая неудачная попытка входа записывается в журнал Security как событие 4625 «An account failed to log on». В нём есть всё нужное для анализа: имя учётной записи, тип входа, IP-адрес источника и код причины. Убедиться, что аудит входа включён, можно командой auditpol /get /category:* — в подкатегории входа в систему должен быть аудит отказов.

Есть нюанс с типом входа. Тип 10 (RemoteInteractive) — это вход через службы удалённых рабочих столов. Но при включённом NLA проверка пароля происходит до создания сеанса, и неудачные попытки по RDP обычно попадают в журнал с типом 3 (Network). Поэтому фильтровать только по типу 10 нельзя — пропустите большую часть перебора.

Скрипт, который показывает, с каких адресов за последние сутки было больше всего неудачных входов:

$since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$since} |
  ForEach-Object {
    $xml = [xml]$_.ToXml()
    $d = @{}
    $xml.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Time      = $_.TimeCreated
      User      = $d['TargetUserName']
      IP        = $d['IpAddress']
      LogonType = $d['LogonType']
    }
  } |
  Group-Object IP | Sort-Object Count -Descending |
  Select-Object Count, Name -First 20

Если среди источников внешние адреса, а у вас «всё закрыто», значит, где-то есть проброс порта, о котором забыли. Расшифровка основных кодов в полях Status и Sub Status:

Код Значение Что это обычно означает
0xC000006A Неверный пароль при существующем имени Подбирают пароль к реальной учётной записи — внимание
0xC0000064 Такой учётной записи нет Перебор имён по словарю
0xC000006D Неверное имя пользователя или данные проверки подлинности Общий код неудачи, смотрите Sub Status
0xC0000234 Учётная запись заблокирована Сработала политика блокировки
0xC0000072 Учётная запись отключена Пробуют отключённую запись, например старого сотрудника

Полное описание полей события есть в документации Microsoft по событию 4625.

RD Gateway вместо прямого RDP

Если пользователей много и раздавать каждому VPN неудобно, удобный вариант — роль Remote Desktop Gateway. Клиент mstsc умеет подключаться через шлюз штатно: в параметрах подключения указывается адрес шлюза, а дальше трафик RDP идёт внутри HTTPS. Что это даёт:

  • снаружи открыт только 443-й порт с нормальным TLS-сертификатом, а не RDP;
  • политики авторизации подключений (RD CAP) задают, какие группы пользователей вообще могут ходить через шлюз;
  • политики авторизации ресурсов (RD RAP) задают, к каким внутренним серверам им можно подключаться;
  • к шлюзу проще прикрутить второй фактор, чем к каждому серверу по отдельности.

Шлюз сам по себе тоже принимает пароли из интернета, поэтому политика блокировки и мониторинг журналов нужны и здесь.

Двухфакторная авторизация

Второй фактор — код из приложения, push-уведомление или аппаратный ключ — делает подобранный пароль бесполезным. Для RDP это особенно важно, потому что пароли пользователей терминальных серверов часто простые и годами не меняются. Реализаций много: модули для RD Gateway, агенты на самом сервере, которые добавляют запрос кода в экран входа, или второй фактор на уровне VPN. Если сервер арендованный, спросите у провайдера: например, в облаке можно подключить двухфакторную авторизацию на сервере без собственной инфраструктуры.

Почему смена порта — не защита

Смена 3389 на какой-нибудь 33899 — самый популярный «совет по безопасности». Порт задаётся в реестре, значение PortNumber в разделе HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp; после изменения нужно открыть новый порт в брандмауэре и перезапустить службу или сервер.

Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' -Name 'PortNumber'

Что это даёт честно: в журналах становится меньше мусора от самых примитивных ботов, которые стучатся только в 3389. Чего это не даёт: сканеры, проходящие весь диапазон портов, найдут RDP на любом порту и легко его опознают. После этого перебор продолжится как ни в чём не бывало. Поэтому менять порт можно как дополнение, но нельзя считать, что после этого RDP «спрятан».

Сводная таблица мер

Мера От чего защищает Ограничения
VPN вместо открытого RDP Перебор, эксплуатация уязвимостей RDP извне Нужно выдать и поддерживать доступы сотрудникам
RD Gateway Прямой доступ к серверам, нет контроля, кто и куда ходит Шлюз сам принимает пароли, нужен сертификат
NLA Нагрузка от анонимных подключений, часть атак на протокол Не мешает подбирать пароли
Блокировка учётных записей Быстрый перебор пароля одной учётной записи Можно намеренно блокировать пользователей
Двухфакторная авторизация Вход с подобранным или утёкшим паролем Нужно внедрить и объяснить пользователям
Смена порта Шум от простейших ботов От сканирования портов не защищает

Порядок действий

  1. Найти и закрыть все пробросы RDP на роутере, перевести пользователей на VPN или RD Gateway.
  2. Включить NLA на всех серверах и рабочих станциях с удалённым доступом.
  3. Задать политику блокировки (ориентир — 10/10/10) и включить Allow Administrator account lockout.
  4. Оставить право входа по RDP только нужным группам, переименовать или отключить встроенного администратора.
  5. Проверить аудит отказов входа и раз в неделю смотреть статистику событий 4625.
  6. Добавить второй фактор хотя бы для администраторов и удалённых сотрудников.

Общие принципы безопасной работы на сервере, которые полезно раздать пользователям, собраны в памятке о правилах безопасности на сервере.

Частые вопросы

Если включить блокировку, атакующий не заблокирует всех пользователей?

Может, если знает имена учётных записей и имеет доступ к RDP снаружи. Именно поэтому блокировка — не основная, а дополнительная мера. Когда RDP доступен только через VPN или шлюз, такой сценарий практически исключён, а блокировка защищает от подбора уже изнутри сети.

Почему в журнале неудачные входы с типом 3, если атакуют RDP?

При включённом NLA пароль проверяется до создания сеанса удалённого рабочего стола, и такая проверка обычно записывается как сетевой вход (тип 3). Чтобы отличить RDP от, например, обращений к общим папкам, сопоставляйте адрес источника и время с журналами службы удалённых рабочих столов.

Хватит ли сложного пароля без всего остального?

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

Нужно ли закрывать RDP, если сервер в облаке?

Да, правила те же. Облачный сервер с открытым 3389 сканируют так же активно, как офисный. Обычно провайдер даёт возможность ограничить доступ по IP, подключиться через VPN или включить второй фактор — этим стоит воспользоваться сразу после получения сервера.