RDP в интернет: почему нельзя

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

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

Почему «у нас нестандартный порт» не спасает

Смена порта с 3389 на другой номер снижает шум в логах, но не делает сервис невидимым. Сканеры перебирают диапазоны портов и определяют RDP по поведению сервиса. Это как перенести входную дверь с фасада во двор, но оставить её открытой и подписанной.

Ещё один аргумент — «у нас сложный пароль». Это лучше, чем простой, но пароль остаётся единственным фактором. Его могут подсмотреть, подобрать из утечек, украсть с домашнего компьютера или получить через фишинг. Если RDP открыт наружу, любой такой пароль сразу становится пропуском к серверу.

Даже при включённом Network Level Authentication и блокировках после неудачных попыток публикация RDP в интернет остаётся лишним риском. Эти настройки снижают часть угроз, но не отвечают на главный вопрос: почему рабочий стол сервера вообще доступен всему интернету?

Что делать вместо прямого RDP

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

Для более зрелой инфраструктуры используют терминальные шлюзы, bastion-host, Zero Trust Network Access или удалённые рабочие места через управляемые сервисы. Название не так важно, как принцип: сервер не публикует RDP напрямую, вход проходит через контролируемую точку, а действия можно журналировать.

Для подрядчиков стоит заводить отдельные учётки, а не давать общий admin. После работ доступ закрывается. Пароль хранится в корпоративном менеджере, а не пересылается в чат. Если подрядчик меняется, это особенно важно проверить в рамках IT-аудита перед сменой подрядчика.

Как проверить, торчит ли RDP наружу

Начните с инвентаризации. Какие внешние IP есть у офиса, клуба, сервера в дата-центре или облаке? Какие правила проброса портов настроены на роутере? Что открыто в панели хостинга или облачного firewall? Часто RDP публикуется не на самом сервере, а правилом NAT на маршрутизаторе, о котором забыли.

Можно проверить внешние порты снаружи: с домашнего интернета, мобильной сети или через сетевые инструменты подрядчика. Важно смотреть не только 3389, но и нестандартные порты, которые перенаправлены на RDP внутри. Если непонятно, куда ведёт правило, лучше временно не удалять его наугад, а сначала выяснить владельца и назначение.

На Windows-серверах полезно посмотреть журнал входов: откуда подключались, какие учётки использовались, сколько неудачных попыток. Если за ночь видны сотни неуспешных логинов с разных стран, это не «фон интернета», а сигнал закрывать публикацию и менять подход.

Что делать, если RDP уже открыт

Не обязательно устраивать ночную революцию. Но порядок должен быть быстрым и аккуратным.

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

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

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

А если нужен доступ «прямо сейчас»

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

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

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