Безопасный удалённый доступ: RD Gateway, NLA и жизнь без проброса 3389

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

Стоит открыть RDP наружу — и начинается перебор. Это не гипотетический риск, а измеримая реальность.

Типичная картина на сервере, который мы принимаем на поддержку с проброшенным портом: несколько тысяч событий неудачного входа в сутки, десятки исходных адресов, попытки идут круглосуточно.

Посмотреть у себя:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625;
  StartTime=(Get-Date).AddDays(-1)} |
  Group-Object { $_.Properties[19].Value } |
  Sort-Object Count -Descending | Select-Object Count, Name -First 20

Свойство под индексом 19 — исходный адрес. Если запрос возвращает список из десятков адресов с сотнями попыток — вас перебирают прямо сейчас.

Чем это заканчивается, помимо очевидного подбора пароля:

• Блокировки учётных записей. При настроенной политике блокировки перебор блокирует реальных пользователей. Сотрудники не могут войти, а причина неочевидна.
• Нагрузка на контроллер домена. Каждая попытка — обращение к DC.
• Эксплуатация уязвимостей протокола. История RDP знает несколько критичных дыр, позволявших выполнить код без аутентификации.
• Шифровальщики. Публичный RDP остаётся одним из основных векторов проникновения программ-вымогателей в компании малого и среднего размера.

Смена порта на нестандартный проблему не решает. Она снижает фоновый шум от массовых сканеров, но не защищает от целенаправленного поиска: полное сканирование портов адреса занимает минуты.

Network Level Authentication переносит проверку учётных данных на этап до установления сеанса.

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

С NLA клиент обязан предъявить учётные данные до того, как что-либо начнётся. Перебор становится дороже, а поверхность атаки — заметно меньше.

Включается одним параметром:

$p = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
Set-ItemProperty $p -Name UserAuthentication -Value 1 -Type DWord
Set-ItemProperty $p -Name SecurityLayer -Value 2 -Type DWord   # SSL/TLS

# проверить
(Get-WmiObject -Namespace root\CIMV2\TerminalServices `
  -Class Win32_TSGeneralSetting).UserAuthenticationRequired

Единица означает, что NLA включена.

Оговорка про совместимость: очень старые клиенты RDP и некоторые тонкие клиенты NLA не поддерживают. Это единственная причина, по которой её иногда выключают, — и почти всегда правильнее обновить клиента, чем ослаблять сервер.

Мы встречали ситуацию, где NLA была выключена ради двух тонких клиентов 2011 года выпуска, стоявших на складе. Замена этих двух устройств стоила дешевле, чем последствия того инцидента, который случился через полгода.

Шлюз удалённых рабочих столов принимает подключения снаружи по HTTPS на порт 443 и транслирует RDP-трафик внутрь сети.

Что это даёт по сравнению с пробросом порта:

Наружу смотрит один сервер, а не каждый терминальный хост.

Трафик идёт по HTTPS, проходит через корпоративные прокси и не блокируется сетями, где RDP закрыт.

Аутентификация происходит на шлюзе до того, как трафик попадёт к целевому серверу.

Есть политики, определяющие, кто и куда может подключаться.

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

Установка:

Install-WindowsFeature RDS-Gateway -IncludeManagementTools
Add-RDServer -Server gw.corp.local -Role RDS-GATEWAY `
  -ConnectionBroker rdcb.corp.local -GatewayExternalFqdn rds.example.ru

Дальше — сертификат на внешнее имя и две политики.

CAP (Connection Authorization Policy) отвечает на вопрос «кого пускаем через шлюз»: группы пользователей, методы аутентификации, разрешено ли перенаправление устройств.

RAP (Resource Authorization Policy) отвечает на вопрос «куда конкретно можно этому человеку»: список целевых компьютеров или групп.

New-Item -Path "RDS:\GatewayServer\CAP" -Name "CAP-Office" `
  -UserGroups "RDS-Users@CORP" -AuthMethod 1

New-Item -Path "RDS:\GatewayServer\RAP" -Name "RAP-Office" `
  -UserGroups "RDS-Users@CORP" -ComputerGroupType 1 `
  -ComputerGroup "RDS-Hosts@CORP"

Разделение на две политики выглядит избыточным, пока не появляется задача вроде «подрядчику можно подключаться, но только к одному конкретному серверу». Тогда RAP решает её ровно и без костылей.

Пароль — единственный фактор, и он утекает. Фишинг, повторное использование, записка под клавиатурой.

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

Варианты реализации для RDS, от простого к сложному:

Сертификаты на устройствах. CAP может требовать не только пароль, но и клиентский сертификат. Фактически это привязка к устройству: с чужого компьютера войти не получится, даже зная пароль. Реализуется своим центром сертификации, работает без внешних сервисов.

Внешний RADIUS с OTP. Шлюз перенаправляет аутентификацию на RADIUS-сервер, который дополнительно запрашивает одноразовый код. Так подключаются большинство коммерческих решений двухфакторной аутентификации.

VPN перед RDP. Формально не двухфакторная аутентификация для RDS, но практически решает ту же задачу: чтобы дойти до шлюза, надо сначала попасть в сеть.

Для офиса до 50 человек мы чаще всего предлагаем третий вариант или первый. Второй хорош, но требует либо покупки решения, либо возни с настройкой и поддержкой инфраструктуры OTP.

Важное замечание: двухфакторная аутентификация не отменяет всего остального. Она не поможет, если у пользователей права локальных администраторов на терминальном сервере, а обновления не ставились год.

Даже за шлюзом стоит контролировать попытки подбора.

Политика блокировки учётных записей. Штука обоюдоострая: слишком агрессивная настройка превращает перебор в отказ в обслуживании для реальных пользователей. Разумный компромисс — блокировка на 15 минут после 10 неудачных попыток за 15 минут.

Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
  -LockoutThreshold 10 -LockoutDuration 00:15:00 `
  -LockoutObservationWindow 00:15:00

Ограничение по географии и адресам. Если сотрудники работают только из России, блокировка остальных диапазонов на периметре убирает большую часть фонового шума. Реализуется на фаерволе, а не на Windows.

Мониторинг событий 4625. Всплеск неудачных входов должен порождать тревогу. Порог подбирается по фактическому фону: если обычно 5 событий в час, тревога на 50.

Журнал шлюза. Успешные подключения через RD Gateway пишутся в отдельный журнал с указанием пользователя, исходного адреса и целевого хоста.

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-Gateway/Operational' `
  -MaxEvents 100 |
  Where-Object Id -in 200,300,302 |
  Select-Object TimeCreated, Id, Message -First 20

Этот журнал полезен и вне контекста безопасности: он отвечает на вопрос «кто и когда подключался», который регулярно возникает при разборе инцидентов совсем другого рода.

И ещё одна мера, которую недооценивают: ограничение времени работы. Если бухгалтерия работает с 8 до 20, подключения в три часа ночи можно просто запретить политикой. Это не защита от целенаправленной атаки, но она отсекает целый класс автоматических попыток и делает аномалию заметной.

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

Обратились не с безопасностью. Обратились с тем, что «утром половина людей не может войти, пишет про блокировку учётной записи, к обеду проходит».

Внутренний айтишник считал, что дело в контроллере домена или в сети, и уже дважды перезагружал DC.

Первый же запрос по событиям 4625 дал картину. За предыдущие сутки — 41 800 неудачных попыток входа. Адресов-источников 340, лидирующие давали по несколько тысяч попыток каждый.

Перебирались короткие и очевидные имена: admin, administrator, user, test, buh, 1c. И — что важно — реальные имена сотрудников в формате «первая буква плюс фамилия».

Откуда злоумышленники знали имена: формат учётных записей совпадал с форматом корпоративной почты, а адреса были опубликованы на сайте компании в разделе контактов. Дальше подбор шёл прицельно.

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

Ни один пароль, судя по журналам, подобран не был. Повезло: пароли в компании были нормальные.

Что сделали за один рабочий день:

• подняли RD Gateway на существующем сервере, выпустили сертификат на внешнее имя;
• закрыли проброс 3389 на маршрутизаторе полностью;
• настроили CAP и RAP с ограничением по группе пользователей;
• включили NLA, которая была выключена «для совместимости» неизвестно с чем;
• отсекли на периметре весь трафик к шлюзу извне России;
• смягчили политику блокировки до десяти попыток за 15 минут;
• поставили мониторинг на всплеск событий 4625.

Блокировки прекратились в тот же день. Количество событий 4625 за следующие сутки — 11, все от одного сотрудника, который путался в раскладке.

Показательнее всего здесь срок. Три года. И всё это время воспринималась не как проблема безопасности, а как «глючит сеть» — потому что проявлялась она именно так.

То, что мы проверяем при аудите терминальной инфраструктуры клиента.

• Порт 3389 не проброшен в интернет ни для одного сервера.
• Внешний доступ идёт только через RD Gateway или VPN.
• NLA включена на всех узлах сеансов.
• Уровень безопасности — SSL/TLS, не RDP Security Layer.
• Сертификат шлюза действителен, выдан публичным центром, автопродление проверено.
• Политики CAP и RAP ограничивают доступ конкретными группами, а не «всем пользователям домена».
• Настроен второй фактор либо доступ только из доверенной сети.
• Политика блокировки учётных записей задана и не создаёт отказа в обслуживании.
• На периметре отсечены географические диапазоны, из которых сотрудники не работают.
• Мониторинг событий 4625 с порогом по фактическому фону.
• У обычных пользователей нет прав локального администратора на хостах.
• Обновления безопасности на узлах сеансов и шлюзе ставятся регулярно.

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

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

Достаточно ли сменить порт RDP с 3389 на нестандартный?

Нет. Это снижает фоновый шум от массовых сканеров, но не защищает: полное сканирование портов одного адреса занимает минуты. Правильное решение — вообще не выставлять RDP наружу, а использовать RD Gateway или VPN.

Что даёт NLA?

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

Чем отличаются политики CAP и RAP на шлюзе?

CAP определяет, кого вообще пускать через шлюз — группы пользователей и методы аутентификации. RAP определяет, к каким именно внутренним компьютерам этому человеку разрешено подключаться. Разделение удобно, когда подрядчику нужен доступ строго к одному серверу.

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

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