Удалёнка — не временный костыль, а новая норма. И каждый раз, когда бизнес требует «срочно открыть доступ Васе из дома», инженер по надёжности должен думать не только о том, чтобы всё заработало, но и о том, чтобы в три часа ночи не пришлось тушить пожар от брутфорса. RDP и VPN — классические точки входа, но их безопасная публикация — это не галочка в чек-листе, а многослойная архитектура. Если до сих пор держите 3389-й порт открытым, потому что «так исторически сложилось», — притормозите: пора разобраться, как сделать доступ прозрачным для сотрудников и бесполезным для атакующих.

Почему «просто открыть порт» — это уже не вариант

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

RDP стабильно в топе целей: порт 3389 сканируется автоматически ботнетами вроде Shodan и Censys. Уязвимости в NLA, шифровании и самом протоколе регулярно дают о себе знать — BlueKeep, NLA-bypass и свежие находки. А брутфорс-атаки на слабые пароли идут массово: если доводилось анализировать журналы безопасности Windows после публикации порта, то сотни событий 4625 в час — обычная картина.

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

Основные риски при публикации RDP и VPN

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

  • Атаки на учётные данные. Брутфорс на RDP/VPN, credential stuffing — когда злоумышленники используют утекшие пароли из других баз — и подбор слабых паролей администраторов. Без MFA одна успешная попытка означает компрометацию.
  • Уязвимости протоколов и сервисов. Дыры в реализациях RDP (тот же BlueKeep), уязвимости в VPN-серверах — старые версии IPSec, OpenVPN, Cisco AnyConnect. Практика показывает: ручные обновления часто забываются, и в сеть проникают через известные CVE.
  • Доступ из ненадёжных сетей. Сотрудник подключается из публичного Wi‑Fi без локального VPN — сессия может быть перехвачена. Личные устройства без контроля добавляют риска: на таком ноутбуке может сидеть шифровальщик, который дотянется до RDP-хоста.
  • Потеря контроля над сессией. Долгоживущие RDP-сессии без тайм-аутов, отсутствие мониторинга активных подключений — инцидент обнаруживают постфактум, когда данные уже утекли.

Понимание этих рисков помогает выстроить не просто «закрытый порт», а многослойную защиту с аудитом, алертингом и автоматическим реагированием.

Схемы безопасной публикации RDP

1. RDP через VPN

Классический и по‑прежнему надёжный вариант: VPN-сервер публикуется в интернете, сотрудник подключается, получает внутренний IP, и уже из VPN-подсети может ходить на RDP-хосты. Сам RDP наружу не торчит.

Плюсы: централизованное управление политиками, аутентификацией и шифрованием; RDP полностью скрыт от прямых атак.

Минусы: нужно поддерживать VPN-инфраструктуру, а при росте числа пользователей нагрузка на шлюз резко возрастает. На практике, если развернуть один инстанс OpenVPN на слабой виртуалке и пустить 200 одновременных подключений — утром получите тикет «всё висит». Я решал это кластером из нескольких нод за балансировщиком, развёрнутым через Terraform, а конфигурацию клиентов обновлял через CI/CD — тогда отказоустойчивость на уровне.

Как настроить безопасно:

  • Используйте современные протоколы: IKEv2/IPSec, OpenVPN с TLS, WireGuard.
  • Обязательно включите двухфакторную аутентификацию (2FA).
  • Ограничьте доступ по IP-диапазонам, если возможно (только из офисных подсетей).

2. RDP через Jump-хост (Bastion Host)

Jump-хост — промежуточный сервер, на который можно безопасно зайти извне, а уже с него подключаться к внутренним RDP-машинам. В интернет светится только jump-хост, а внутренние RDP-серверы недосягаемы напрямую.

Типичная реализация: пользователь по SSH (с пробросом портов) заходит на bastion, и оттуда запускает RDP-клиент. Плюсы — централизованный контроль доступа и логирование всех действий.

Минусы: одна точка входа; если jump-хост скомпрометирован, злоумышленник получает ключи от всей внутренней сети. Поэтому я всегда сегментирую доступ и внедряю Just-in-Time привилегии: через временные учётные записи или Azure Bastion. На jump-хосте обязательно включаю MFA (pam_google_authenticator), жёстко ограничиваю права пользователей и отправляю логи в auditd → ELK для расследования инцидентов.

3. RDP через Reverse Proxy / VPN + RDP Gateway

Современный подход — использовать RDP Gateway (Windows) или reverse proxy. Шлюз публикуется в интернете, защищает внутренние RDP-серверы и позволяет включить NLA, 2FA и гранулярные политики.

Что даёт: единая точка аутентификации, интеграция с MFA (например, через Azure AD NPS extension), полное логирование попыток подключений. Настраивал такую связку с Conditional Access: доступ к RDP Gateway получали только устройства, соответствующие политикам Intune.

Важно: никогда не отключайте NLA на шлюзе, ограничьте доступ по IP-диапазонам и обязательно подружите журналы с SIEM — стандартные Windows-логи не всегда достаточно детальны, приходится дорабатывать парсинг.

4. RDP через Zero Trust / SASE-решения

Если внедряете Zero Trust: пользователь подключается к SASE-шлюзу, который проверяет устройство, пользователя, местоположение и политики. Доступ к RDP выдаётся только после успешной проверки. Примеры: Zscaler Private Access, Cloudflare Access, Microsoft Azure Virtual WAN / Private Access.

Это не «волшебная таблетка», а дополнительный слой. Например, Cloudflare Access позволяет опубликовать внутренний RDP через Argo Tunnel, вообще не открывая входящих портов — я применял такой подход для доступа к тестовому кластеру Kubernetes. Но нужно быть готовым к настройке DNS, сертификатов и возможным задержкам. Как FinOps-специалист, я также считаю стоимость на пользователя: SASE-решения могут быть дороговаты для малого бизнеса.

Схемы безопасной публикации VPN

1. VPN с двухфакторной аутентификацией

Это даже не рекомендация, а гигиенический минимум. Положитесь на MFA: Google Authenticator (TOTP), SMS (небезопасно, но допустимо для некритичных пользователей), U2F-токены вроде YubiKey.

Для корпоративных пользователей идеально — интеграция с Active Directory + Azure AD MFA (через NPS expansion) или FreeRADIUS с OTP. Для подрядчиков — отдельные учётки с ограниченными правами и обязательным MFA. На практике настройка FreeRADIUS с Google Authenticator на Linux-сервере занимает 10 минут, но почему-то многие до сих пор пренебрегают.

2. VPN с ограничением по IP-диапазонам

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

3. VPN с сегментацией доступа

Не давайте всем пользователям доступ ко всем ресурсам. Разделите VPN-подключения по группам: офисные сотрудники, удалёнщики, подрядчики — и назначьте разные внутренние маршруты и ACL. Это классический принцип наименьших привилегий.

Я описываю такие политики в YAML и накатываю через Ansible на VPN-шлюз. При добавлении нового сотрудника в группу ACL подтягиваются автоматически — никаких ручных ошибок с забытыми правилами.

4. VPN с ограничением по времени и устройству

Ограничьте время жизни сессии: например, 8–12 часов. Запретите одновременные подключения с нескольких устройств. Проверяйте состояние устройства — антивирус, обновления, членство в домене.

На OpenVPN это делается через duplicate-cn и client-config-dir, на RADIUS-сервере можно задать Session-Timeout. В крупных инсталляциях использую проверку сертификата устройства + пост-аутентификационные скрипты.

Какие настройки RDP и VPN критичны для безопасности

Для RDP:

  • Включите Network Level Authentication (NLA). Без NLA аутентификация идёт на уровне RDP-сессии, а не на уровне сети — это увеличивает риск брутфорса. Если приходится использовать RDP без NLA на устаревших системах, изолируйте такие хосты в отдельный VLAN и разрешайте доступ только с jump-хоста.
  • Ограничьте количество попыток входа. Включите политики блокировки учётных записей после нескольких неудачных попыток (GPO «Account lockout threshold»). Дополнительно я настраиваю fail2ban на RDP Gateway или jump-хосте, чтобы банить IP-адреса.
  • Отключите встроенные учётные записи. Переименуйте Administrator, Guest отключите. Раздавайте минимальные права через группы; автоматизирую это через Ansible win_user.
  • Ограничьте доступ по IP-диапазонам. Если возможно, разрешайте RDP только из VPN-подсети или jump-хоста. На Windows — через Windows Firewall, на Linux-хостах с xrdp — через iptables. Я описываю эти правила в Terraform для автоматического применения на всех новых машинах.
  • Включите аудит входа по RDP. Логируйте все попытки подключения (GPO «Audit logon events»), отправляйте в SIEM (Winlogbeat → Elasticsearch) и настройте алерты на подозрительную активность.

Для VPN:

  • Используйте современные протоколы и шифрование. IKEv2/IPSec с сертификатами, OpenVPN с TLS 1.2+, WireGuard. PPTP — мёртв, L2TP без IPSec — опасно. Для небольших проектов я часто беру WireGuard — скорость и простота настройки через Ansible радуют.
  • Включите MFA. Никаких «nice to have». Интеграция с RADIUS или Azure AD MFA — обязательно.
  • Ограничьте количество одновременных подключений. OpenVPN: «duplicate-cn» и лимиты на пользователя. На IKEv2 — через RADIUS-атрибуты. Это предотвращает расшаривание учёток.
  • Настройте тайм-ауты сессий. Автоматически разрывайте неактивные и абсолютные сессии через 12–24 часа, заставляя переавторизоваться.
  • Интегрируйте с системами мониторинга и SIEM. Логируйте подключения, ошибки, геолокацию. Я загоняю всё в Graylog, строю дашборды и алерты: если вижу вход из нехарактерной страны — немедленно эскалирую.

Типичные ошибки админов при публикации RDP и VPN

  • Открывают RDP/VPN напрямую без дополнительных слоёв защиты. Видел случай: компания держала 3389 наружу на Windows Server 2012 R2 и узнала о проблеме только после шифровальщика.
  • Используют слабые пароли и не включают MFA. Даже сложный пароль не устоит против credential stuffing из утекших баз.
  • Не ограничивают доступ по IP-диапазонам. Любой желающий может достучаться до VPN-шлюза. Хотя бы геоблокировка по странам снижает шум.
  • Дают всем пользователям доступ ко всем ресурсам. Нарушение минимальных привилегий; стоит одному аккаунту скомпрометироваться — и вся сеть открыта.
  • Не ведут логи и не мониторят активность. Инциденты замечают только после жалоб пользователей или шифрования файлов. SIEM и алертинг обязательны.
  • Не обновляют ПО и не патчат уязвимости. Один забытый OpenVPN 2.3 с критической CVE — и дыра готова. Я внедрил автоматическое сканирование уязвимостей через OpenVAS в CI/CD, чтобы такого не повторялось.
  • Используют устаревшие протоколы. PPTP до сих пор встречается в небольших компаниях — убрать немедленно.

Как проверить безопасность текущей публикации RDP и VPN

1. Проверка открытых портов

nmap -p 3389,443,1194,500,4500 . Если RDP светится напрямую — красный флаг. Я периодически запускаю такой скан из Ansible-плейбука, который потом сверяет результаты с ожидаемым состоянием в инвентаре.

2. Тестирование на уязвимости

Nessus, OpenVAS или Tenable — обязательный этап. Проверьте RDP-шлюз, VPN-сервер, jump-хост. Обратите внимание на уязвимости в NLA, шифровании, версиях протоколов. Сканер должен работать по расписанию, отчёт приходить на почту.

3. Анализ логов

Посмотрите количество событий 4625 (Windows) или попыток входа в VPN-логах. Если тысячи в день — уже тревога. Есть ли подозрительные IP? Я настраиваю автоматическую корреляцию: при превышении порога неудачных попыток система сама банит IP.

4. Тестирование MFA и политик

Попробуйте подключиться с неправильным паролем несколько раз — блокируется ли учётка? Работает ли MFA? Проверьте, нет ли исключений для определённых внутренних IP, которые могут быть скомпрометированы. По опыту, такие исключения администраторы часто создают и забывают.

Практический чек-лист: как безопасно открыть RDP и VPN

  1. Определите схему доступа: RDP через VPN, jump-хост, RDP Gateway или Zero Trust. Выбирайте исходя из масштаба и требований безопасности.
  2. Настройте MFA для всех учётных записей, имеющих удалённый доступ.
  3. Ограничьте доступ по IP-диапазонам — хотя бы на уровне файрвола. Если динамические IP, добавьте геофильтрацию.
  4. Включите аудит и логирование всех попыток входа, настройте алерты в SIEM.
  5. Обновите ПО и патчи: убедитесь, что RDP Gateway, VPN-сервер, jump-хост имеют актуальные обновления. Автоматизируйте проверки с помощью Ansible или скриптов.
  6. Проведите тестирование: nmap, скан уязвимостей, проверка MFA и политик блокировок.
  7. Обучите сотрудников: не использовать слабые пароли, не заходить из публичных сетей без локального VPN, не расшаривать учётки.

FAQ: часто задаваемые вопросы

1. Можно ли вообще не публиковать RDP и VPN?

Да. Варианты: использовать только внутренние сети через корпоративный VPN (но сам VPN всё равно где-то публикуется), перейти на облачные рабочие столы — Azure Virtual Desktop, Amazon WorkSpaces — там доступ идёт через HTTPS и аутентификацию облака, порты не торчат. Либо внедрить Zero Trust-решения, которые не требуют публикации портов. Для legacy-систем это выход, но сдвигает затраты в OPEX — нужно считать FinOps-модель.

2. Какой вариант лучше: RDP через VPN или RDP Gateway?

RDP через VPN проще, если у вас уже есть VPN-инфраструктура, но тогда пользователь получает доступ ко всей сети — нужна сегментация. RDP Gateway более гибкий: централизованные политики, интеграция с MFA, детальные логи. В доменной среде я предпочитаю Gateway, потому что через него можно легко включить NAP и проверку здоровья устройства.

3. Нужно ли использовать Jump-хост?

Jump-хост полезен, когда много внутренних RDP-серверов, особенно не в домене или в изолированных сетях. Он даёт единую точку входа и аудита. Но настраивать его нужно жёстко: SSH-туннели с пробросом портов, обязательная MFA, детальный аудит. Я часто использую bastion в паре с автоматическим баном по IP через fail2ban.

4. Как часто нужно менять пароли?

Минимум раз в 90 дней — базовое требование. Но современные рекомендации NIST говорят, что частая смена без компрометации не улучшает безопасность. Лучше внедрить длинные парольные фразы и MFA. Как инженер, я голосую за password manager и повсеместный MFA, а не за принудительную смену каждые 30 дней.

5. Что делать, если обнаружили подозрительную активность?

Немедленно заблокируйте подозрительные учётные записи, соберите логи, изолируйте потенциально затронутые системы, проведите аудит безопасности. В идеале процесс реагирования должен быть описан в runbook и частично автоматизирован: например, SOAR-плейбук при обнаружении аномальной активности сам банит IP, блокирует учётку и создаёт инцидент в тикет-системе.

Заключение

Безопасная публикация RDP и VPN — не «один клик в настройках маршрутизатора», а непрерывный процесс с многослойной защитой. Сочетайте правильные схемы (VPN, jump-хост, RDP Gateway, Zero Trust), строгие политики доступа, MFA и постоянный мониторинг. Как SRE-инженер, я отношусь к этому как к системе: измеряю показатели (время реакции, количество инцидентов), автоматизирую проверки и реагирование, использую IaC для воспроизводимости конфигураций. Если у вас сейчас открыт прямой RDP — сделайте паузу, проверьте логи и начните наращивать защиту поэтапно. Это не усложнит жизнь пользователям, но кратно снизит риск ночного пожара.