Публичный RDP на виртуальном сервере (VPS/VDS) почти неизбежно попадает в поле зрения сканеров: 3389/TCP проверяется автоматически, а попытки подбора паролей начинаются в течение часов после выдачи IP. На Windows Server 2022 базовые средства защиты уже встроены, но «из коробки» они редко настроены так, чтобы действительно жестко ограничивать доступ. Ниже приведен практический сценарий для VDS: включение NLA, настройка политик блокировок, ограничение входящих подключений через Windows Defender Firewall и включение аудита входов для контроля попыток доступа.

Задача статьи одна – оставить RDP только тем, кому он действительно нужен (конкретные учетные записи, конкретные источники подключения), и получить прозрачную картину попыток входа в журналах Windows. Описанные действия применимы как к одиночному серверу в workgroup, так и к серверу в домене (с поправкой на применение GPO).

Целевая модель: что считается «жестким ограничением»

В реальных внедрениях «жесткость» достигается сочетанием нескольких уровней:

• NLA (Network Level Authentication) – аутентификация до создания полноценной RDP-сессии, что снижает поверхность атаки и нагрузку при переборе
• Контроль, кто имеет право входа по RDP – доступ только определенной группе/учетным записям, без «по умолчанию разрешено всем администраторам» в неуправляемых сценариях
• Политики блокировок – ограничение числа неверных вводов пароля и временная блокировка учетной записи
• Windows Defender Firewall – разрешение RDP только с доверенных IP/подсетей (allowlist), отключение лишних правил и профилей
• Аудит входов – включение нужных подкатегорий аудита и понимание, какие события фиксируют успешные и неуспешные RDP-входы

Дополнительно (за рамками основного сценария) часто используются VPN, RD Gateway, MFA, JIT-доступ. Однако даже без этих компонентов связка NLA + allowlist + блокировки + аудит уже радикально снижает риск компрометации публичного RDP на VDS.

Подготовка: как не потерять доступ к серверу

Главная операционная ошибка при ужесточении RDP – отрезать доступ самому себе. Перед изменениями обычно фиксируются три контрольных пункта:

• Аварийный доступ. Нужен альтернативный канал управления, не зависящий от RDP (веб-консоль/виртуальная KVM, VNC-консоль у провайдера, отдельная приватная сеть, VPN)
• Резервная административная учетная запись. Желательно две независимые учетные записи с сильными паролями, чтобы ошибка в правах одной не блокировала управление полностью
• Список разрешенных источников. Как минимум – статический IP офиса/шлюза, IP корпоративного VPN или выделенного bastion/jump-хоста. Динамический домашний IP усложняет жесткую фильтрацию и обычно требует VPN или временного открытия доступа

Если виртуальный сервер арендуется у провайдера, у которого доступна out-of-band консоль для восстановления после ошибочной настройки Firewall, это заметно снижает риск простоя. В качестве нейтрального примера площадки с арендой VPS/VDS можно упомянуть VPS.house.

Шаг 1. Включение NLA и усиление параметров безопасности RDP

Что дает NLA. Network Level Authentication заставляет клиента пройти проверку учетных данных до создания сеанса удаленного рабочего стола. Это сокращает количество ресурсов, расходуемых на «пустые» подключения, и отсекает часть примитивных атак, рассчитанных на старые сценарии предаутентификации.

Ограничения NLA:

• Требуется поддержка NLA на клиенте (актуальные версии mstsc, современные ОС). Старые клиенты могут не подключиться
• При ошибках в CredSSP/шифровании возможны проблемы совместимости, особенно в смешанных средах

Включение NLA через GUI

Для Windows Server 2022 стандартный путь выглядит так:

1. Открыть свойства системы (например, через «Server Manager» – «Local Server» – «Remote Desktop»)
2. Включить удаленный доступ
3. Отметить вариант «Разрешить подключения только с компьютеров, на которых включена проверка подлинности на уровне сети (рекомендуется)»

Принудительное требование NLA через локальные политики (gpedit.msc)

Чтобы зафиксировать настройку и избежать случайного отключения, используется политика:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → «Require user authentication for remote connections by using Network Level Authentication» → Enabled.

В этом же разделе часто фиксируются дополнительные параметры:

• «Set client connection encryption level» → High (уместно для административного доступа)
• «Require use of specific security layer for remote (RDP) connections» → SSL (TLS). Формулировка может выглядеть устаревшей, но на Server 2022 фактически используется современный TLS-стек, если он не ослаблен отдельно

Шаг 2. Ограничение прав входа по RDP на уровне пользователей и групп

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

Базовый принцип

• Доступ по RDP – только для выделенной группы (например, «RDP-Admins»), куда включаются конкретные администраторы
• Пользователи без административных задач не получают права «Allow log on through Remote Desktop Services»
• Сервисные учетные записи и учетные записи для задач планировщика получают явный запрет на вход по RDP (если это допустимо по сценарию)

Настройка через Local Security Policy (secpol.msc)

Для автономного Windows Server 2022 применяется локальная политика:

Local Policies → User Rights Assignment:

• Allow log on through Remote Desktop Services – оставить только нужные группы (например, Administrators и/или отдельную группу доступа)
• Deny log on through Remote Desktop Services – добавить учетные записи/группы, которым вход по RDP должен быть запрещен (например, service accounts, отдельные операторские роли и т. п.)

Важная практическая деталь: если из «Allow log on…» удаляется группа Administrators, необходимо заранее включить конкретные административные учетные записи в разрешенную группу, иначе администрирование будет возможно только через аварийную консоль.

Если сервер в домене

В доменных средах перечисленные настройки корректнее задавать через GPO на уровне OU/групп серверов. Это снижает риск расхождения конфигураций и позволяет централизованно ревизовать, кому разрешен доступ по RDP.

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

Политика блокировки (Account Lockout Policy) ограничивает число неверных попыток входа и временно блокирует учетную запись. Это один из немногих встроенных механизмов, реально повышающих цену перебора паролей на публичном RDP.

Рекомендуемая логика подбора значений

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

• Account lockout threshold: 5-10 неверных попыток
• Account lockout duration: 10-30 минут (или «до разблокировки администратором» в средах с жестким регламентом, но это повышает риск само-блокировки)
• Reset account lockout counter after: 10-30 минут (обычно близко к длительности блокировки)

Компромисс: слишком малый порог делает возможной «атака на доступность» – злоумышленник специально блокирует учетные записи, подбирая пароль. Слишком большой порог оставляет пространство для перебора. В VDS, где RDP открыт в интернет, чаще оправдан умеренный порог и ограниченная по времени блокировка.

Настройка на Windows Server 2022 (workgroup)

Открыть secpol.msc → Account Policies → Account Lockout Policy и задать три параметра:

• Account lockout threshold
• Account lockout duration
• Reset account lockout counter after

Если политика применяется через GPO, аналогичные параметры настраиваются в доменной политике безопасности.

Что важно понимать про блокировки и RDP

• При включенном NLA неверные учетные данные будут фиксироваться и учитываться в счетчике блокировок до открытия сеанса
• Для локальных учетных записей на автономном сервере блокировка действует на этом сервере; в домене правила задаются доменной политикой (а события могут фиксироваться на контроллерах домена)

Шаг 4. Windows Defender Firewall: разрешить RDP только с доверенных IP

Allowlist в Windows Defender Firewall – наиболее «жесткая» и понятная мера. Даже при наличии правильных паролей подключение по RDP не должно устанавливаться с неизвестных адресов. Для VDS с публичным IP это критично: сканеры могут атаковать бесконечно, но на уровне сети подключение просто не будет достигать службы.

Проверка профиля сети на сервере

На виртуальных серверах сетевой профиль часто определяется как Public. Это влияет на применяемые правила. Перед редактированием правил стоит убедиться, какие профили используются, чтобы не открыть RDP «не тем» профилем или, наоборот, не заблокировать доступ из ожидаемой зоны.

Ограничение стандартных правил RDP через GUI (wf.msc)

Последовательность действий:

1. Открыть Windows Defender Firewall with Advanced Security (wf.msc)
2. Перейти в Inbound Rules
3. Найти правила группы Remote Desktop. Обычно присутствуют варианты для TCP и UDP, а также для разных профилей
4. Открыть нужное правило (например, Remote Desktop – User Mode (TCP-In)), перейти на вкладку Scope
5. В блоке Remote IP address выбрать These IP addresses и указать разрешенные IP/подсети
6. Повторить для UDP-правила (если используется) либо отключить UDP-правило, если административный сценарий не требует UDP-транспорта

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

То же самое через PowerShell

Для автоматизации и воспроизводимости удобнее PowerShell. Список правил RDP:

Команда:
Get-NetFirewallRule -DisplayGroup «Remote Desktop» | Select-Object DisplayName, Enabled, Profile

Ограничение удаленных адресов для TCP (пример):

Команда:
Set-NetFirewallRule -DisplayName «Remote Desktop – User Mode (TCP-In)» -RemoteAddress «203.0.113.10»,«198.51.100.0/24»

Если на сервере несколько RDP-правил с разными профилями, аналогичное ограничение задается для каждого актуального правила (в зависимости от того, какие профили реально используются).

Как не допустить «лишних» разрешающих правил

Windows Firewall обрабатывает набор правил в совокупности; одна «широкая» разрешающая запись может перечеркнуть идею allowlist. На практике помогает простая проверка:

• Включены только те inbound-правила для 3389/TCP (и, при необходимости, 3389/UDP), где явно задан RemoteAddress и нужный профиль
• Остальные правила Remote Desktop отключены или приведены к тем же ограничениям

В VDS-сценариях также встречается провайдерский сетевой экран на уровне панели управления. Он полезен как дополнительный внешний слой, но даже при его наличии локальный Windows Defender Firewall остается актуальным: ошибки в «наружном» фильтре не должны автоматически открывать RDP всему интернету.

Перед применением жестких правил полезно убедиться, что доступна веб-консоль для аварийного входа в систему без RDP – такой механизм обычно доступен в панелях управления VDS; пример интерфейса можно посмотреть и попробовать на https://vps.house

Шаг 5. Аудит входов: какие политики включить и какие события смотреть

Ограничить доступ – половина задачи. Вторая половина – видеть попытки входа и быстро понимать, что именно происходит: кто входит, с каких адресов, какие учетные записи атакуют, есть ли блокировки. Windows Server 2022 предоставляет для этого несколько уровней журналирования.

Включение расширенного аудита (Advanced Audit Policy)

Грубый переключатель «Audit logon events» часто недостаточно управляем. Предпочтительнее включить нужные подкатегории через Advanced Audit Policy:

Local Security Policy → Advanced Audit Policy Configuration → Audit Policies:

• Logon/Logoff → Audit Logon – Success и Failure
• Logon/Logoff → Audit Logoff – Success (по ситуации)
• Logon/Logoff → Audit Special Logon – Success (полезно для фиксации входов с повышенными привилегиями)
• Account Logon → Audit Credential Validation – Success и Failure (для понимания проверок учетных данных)

Альтернативно – через командную строку (удобно для автоматизации):

Команды:
auditpol /set /subcategory:«Logon» /success:enable /failure:enable
auditpol /set /subcategory:«Special Logon» /success:enable /failure:enable
auditpol /set /subcategory:«Credential Validation» /success:enable /failure:enable

Проверка текущего состояния:

Команда:
auditpol /get /category:*

Ключевые события Security log для RDP

Основные события в «Windows Logs → Security»:

• 4624 – успешный вход (Logon Type 10 соответствует RemoteInteractive, то есть RDP)
• 4625 – неуспешный вход (для RDP также важен Logon Type 10)
• 4634 – завершение сеанса (logoff)
• 4672 – вход с особыми привилегиями (часто появляется при входе администраторов)

В 4625 наиболее информативны поля:

• Account Name – к какой учетной записи подбирают пароль
• Failure Reason, Status, SubStatus – причина отказа (неверный пароль, отключенная учетная запись, заблокированная учетная запись и т. п.)
• Source Network Address – источник попытки (не всегда заполняется одинаково; для RDP часто лучше дополнять данными из журналов служб терминалов)

Журналы Remote Desktop Services: что дают сверх Security log

Для RDP полезны журналы ветки «Applications and Services Logs → Microsoft → Windows»:

• TerminalServices-RemoteConnectionManager/Operational – события уровня подключения и аутентификации
• TerminalServices-LocalSessionManager/Operational – события создания/закрытия RDP-сеансов

Эти журналы часто отключены по умолчанию. Для включения:

1. Открыть Event Viewer (eventvwr.msc)
2. Перейти в нужный журнал (например, TerminalServices-RemoteConnectionManager/Operational)
3. Выбрать Enable Log

Практически значимые события:

• 1149 (RemoteConnectionManager/Operational) – успешная аутентификация пользователя для RDP; часто содержит имя учетной записи и IP клиента
• 21 (LocalSessionManager/Operational) – успешный вход в сеанс
• 23/24 – завершение или разрыв сеанса

В сценариях расследования инцидентов связка Security (4624/4625. + TerminalServices (1149, 21 и др.) позволяет точнее сопоставлять учетную запись, источник и факт открытия сеанса.

Размер журналов и сохранность данных

При публичном IP на VDS поток событий 4625 может быть высоким. Если журнал Security остается небольшим (десятки мегабайт), старые записи будут быстро перезаписаны, и диагностика станет затруднительной. Обычно настраиваются:

• увеличенный размер Security log (например, 256-512 МБ – значение зависит от интенсивности событий и политики хранения)
• понятный режим перезаписи (например, «Overwrite events as needed» при наличии внешней выгрузки в SIEM/WEF, либо ручной контроль при строгих требованиях к хранению)

Для изменения максимального размера журнала через командную строку:

Команда (пример для 256 МБ):
wevtutil sl Security /ms:268435456

Проверка после внедрения: минимальный тест-план

После изменения настроек важна проверка не только «входит/не входит», но и корректности журналирования:

1. Проверка NLA: подключение штатным клиентом RDP, подтверждение, что сервер не разрешает подключения без NLA (в случае попытки старым клиентом)
2. Проверка прав: вход учетной записью из разрешенной группы; попытка входа учетной записью вне группы должна завершаться отказом
3. Проверка Firewall: подключение с разрешенного IP проходит; попытка с неразрешенного источника не устанавливает соединение (проверяется, например, Test-NetConnection к 3389)
4. Проверка блокировок: несколько неверных паролей подряд должны приводить к ожидаемой блокировке (контроль по реакции системы и по событиям 4625 с соответствующими кодами отказа)
5. Проверка аудита: появление событий 4624/4625 в Security и 1149/21 в журналах TerminalServices

Типовые ошибки и ограничения, о которых часто забывают

1. Динамический IP у администратора

Allowlist в Firewall хорошо работает при фиксированных источниках. Если подключение осуществляется с динамического IP, жесткое ограничение превращается в постоянную операционную проблему. В подобных сценариях обычно выбирается один из подходов:

• доступ к RDP только через VPN с фиксированным выходным IP
• использование bastion/jump-хоста с известным адресом
• временное добавление IP в allowlist с последующим автоматическим удалением по регламенту (требует дисциплины и контроля)

2. Самоблокировка учетной записи политикой lockout

Слишком агрессивный порог блокировки в сочетании с ошибочным вводом пароля способен заблокировать единственного администратора. Это частая причина простоя. Минимизируется наличием резервной учетной записи и альтернативного канала доступа (консоль провайдера).

3. Неполный учет IPv6

Если на сервере активен IPv6 и правило Firewall ограничено только IPv4-адресами, фактически может оставаться «второй вход» через IPv6 (в зависимости от сетевой конфигурации VDS). В жестких моделях доступа IPv6 либо явно ограничивается allowlist-правилами, либо отключается при отсутствии потребности и согласовании с сетевой схемой.

4. Лишние разрешающие правила в Firewall

Иногда RDP оказывается разрешен несколькими правилами (например, для разных профилей или после установки стороннего ПО). В таком случае ограничение «одного» правила не дает результата. Требуется ревизия всех inbound-правил, которые затрагивают 3389/TCP и 3389/UDP.

5. Ожидание, что смена порта RDP «решает проблему»

Перенос RDP на нестандартный порт снижает шум от массовых сканеров, но не заменяет NLA, allowlist и аудит. При целевой атаке порт будет найден, если сервис доступен снаружи. В сценарии «жесткого ограничения» смена порта рассматривается только как дополнительная мера, а не как основная защита.

Итог: минимальный набор, который действительно работает на VDS

Для Windows Server 2022 на виртуальном сервере базовый практический минимум выглядит так:

• NLA включен и принудительно задан политикой
• Право входа по RDP выдано только нужным группам/учетным записям
• Политика блокировки ограничивает перебор паролей в разумных пределах
• Windows Defender Firewall разрешает RDP только с доверенных IP/подсетей, без «широких» исключений
• Аудит входов включен, а журналы настроены так, чтобы данные не терялись через несколько часов

Такой набор не отменяет требований к обновлениям, паролям и общей гигиене администрирования, но заметно сужает поверхность атаки RDP на публичном VPS/VDS и переводит попытки несанкционированного доступа в контролируемую и наблюдаемую плоскость.