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

За пятнадцать лет в IT-аутсорсинге я разбирал шифровальщиков больше раз, чем хотелось бы. И в девяти случаях из десяти история начинается одинаково: где-то в настройках роутера или сервера стоит проброс порта 3389 наружу. Не потому что кто-то злонамеренно открыл дверь настежь. Просто когда-то бухгалтеру понадобилось работать из дома, айтишник (штатный, приходящий, неважно) сделал проброс за десять минут — и забыл про него на три года. А через три года туда постучались.

Почему я говорю именно про порт, а не про пароль

Стандартная реакция руководителя, когда я поднимаю эту тему: «У нас сложный пароль, восемь символов, цифры и заглавные буквы, всё по инструкции». Отвечаю всегда одно и то же: пароль тут вообще не главный вопрос. Проблема не в том, что пароль подберут. Проблема в том, что порт 3389, торчащий в интернет, сам по себе — сигнальная ракета для сканеров.

Боты сканируют весь диапазон IPv4 постоянно, круглосуточно, без выходных. Shodan и Censys — это открытые поисковики по устройствам в интернете, там любой желающий вбивает запрос «port:3389» и получает список из миллионов адресов с открытым RDP. Ваш сервер туда попадёт не через неделю — через несколько часов после того, как проброс появится. Дальше начинается перебор: тысячи попыток входа в минуту, по словарям утёкших паролей, по спискам типичных логинов вроде admin, buh, 1cuser, director.

У одного клиента, торговая компания на 18 рабочих мест, я поднял логи Windows после инцидента. За месяц до шифрования — 340 тысяч неудачных попыток входа с трёхсот с лишним IP-адресов. Триста дней в квартал такой сервер живёт как мишень в тире, и рано или поздно кто-то попадёт.

Как на самом деле заходят: не только через подбор пароля

Подбор пароля — это самый очевидный, но далеко не единственный сценарий. RDP-клиент и сервер в Windows регулярно получают уязвимости, которые позволяют выполнить код или обойти аутентификацию вообще без пароля. Помните историю с BlueKeep в 2019 году? Уязвимость в самом протоколе RDP, эксплуатация без единого клика пользователя, просто по факту доступности порта. Microsoft тогда выпустила патч даже для снятой с поддержки Windows XP — настолько серьёзно всё было.

Второй сценарий — это купленный доступ. На теневых форумах есть целый рынок под названием RDP-шоп: продают уже взломанные учётки к серверам по 5-20 долларов за штуку, с указанием страны, версии Windows, прав пользователя. Шифровальщику необязательно взламывать вас самому. Он просто покупает уже готовый вход, потому что кто-то до него это уже сделал автоматизированным перебором.

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

Почему шифровальщик — это конец истории, а не начало

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

У клиента из производственной сферы, завод на 40 человек, взлом через RDP случился в пятницу вечером. Шифрование запустилось в субботу в три часа ночи — специально выбрано время, когда никто не увидит и не остановит процесс. К понедельнику были зашифрованы: файловый сервер, база 1С, резервные копии на NAS (потому что NAS был в той же сети с теми же учётными данными администратора). Восстановление заняло 11 дней и обошлось дороже, чем вся годовая IT-инфраструктура компании.

Отдельно скажу про Veeam. Многие уверены — раз есть бэкапы, можно спать спокойно. Но если сервер с бэкапами подключён к той же сети и виден с того же скомпрометированного контроллера домена, шифровальщик доберётся и до него. Резервные копии должны быть изолированы — либо offline-копия, либо иммутабельное хранилище, либо хотя бы отдельные учётные данные без доверия к домену. Это тема для отдельного разговора, но упомянуть здесь обязательно.

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

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

Первый и самый правильный вариант — VPN. Ставите на периметре шлюз (тот же Keenetic с поддержкой WireGuard, или отдельный сервер), сотрудник сначала поднимает VPN-туннель, и только потом изнутри защищённого канала подключается по RDP к нужной машине. Порт 3389 при этом вообще не выставлен в интернет — его видно только из VPN-сети. Даже если у сотрудника угонят пароль от RDP, без VPN-ключа злоумышленник до него просто не доберётся.

Второй вариант — RD Gateway, штатный компонент Windows Server. Это шлюз, который принимает RDP-подключения через HTTPS-порт 443, с обязательной двухфакторной аутентификацией. Внешне для сканера это выглядит как обычный веб-сервер, а не как RDP — уже само по себе снижает интерес ботов на порядок. Третий вариант, который я всё чаще рекомендую малому бизнесу — вообще отказаться от прямого RDP в пользу брокера удалённых рабочих столов вроде TeamViewer Tensor или AnyDesk для бизнеса, где подключение идёт через посредника, а не напрямую на ваш IP.

Двухфакторная аутентификация — не опция, а обязательный минимум

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

Практическая реализация недорогая: Duo, Microsoft Authenticator в связке с Azure AD, или даже простой TOTP-плагин для RD Gateway. У клиента из юридической фирмы, 12 рабочих мест, внедрение заняло два дня и обошлось примерно в 15 тысяч рублей разовой настройки плюс копейки за лицензии. После этого блокировка учётной записи после пяти неудачных попыток входа и уведомление в телеграм при подозрительной активности стали штатной практикой, а не экзотикой.

И да, здесь снова придётся столкнуться с ворчанием сотрудников — «зачем эти лишние коды, раньше было проще». Отвечаю обычно так: раньше было проще, потому что было опаснее, просто вы этого не видели. После первого реального инцидента у клиента такие вопросы исчезают сами собой.

Сегментация сети и права доступа — вторая линия обороны

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

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

У клиента из сферы торговли после аудита мы обнаружили: 23 рабочих места, из них 19 имели RDP-доступ к серверу баз данных с правами локального администратора. Спросил директора, зачем — ответ был «так исторически сложилось, никто не убирал». Через месяц оставили пять учёток с реальной необходимостью, остальным настроили доступ только к нужным папкам через обычный файловый шаринг.

Что я рекомендую сделать прямо на этой неделе

Если вы дочитали до этого места и не уверены, открыт ли у вас RDP наружу — это проверяется за пять минут. Зайдите на любой публичный сканер портов, введите ваш внешний IP-адрес (его легко узнать через whatismyip), проверьте порт 3389. Если он отвечает — у вас открытая дверь, и это стоит закрыть не в следующем квартале, а сегодня вечером.

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

И последнее. Я регулярно слышу от директоров: «у нас маленькая компания, кому мы вообще интересны». Отвечу прямо — вы не интересны конкретному человеку, который сидит и целится именно в вас. Вы интересны боту, который сканирует миллионы адресов подряд и не делает разницы между заводом на 500 человек и бухгалтерией на пять. Автоматизация атаки означает, что размер бизнеса давно перестал быть защитой.

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

У нас сложный пароль и включена блокировка после нескольких попыток входа. Этого достаточно?
Нет. Блокировка после неудачных попыток защищает от простого перебора, но не от уязвимостей самого протокола RDP и не от купленных на теневых форумах уже готовых учётных данных. К тому же массовая блокировка учёток при DDoS-подобном переборе иногда сама превращается в проблему — легитимные сотрудники не могут зайти. Порт всё равно нужно убирать из прямой видимости интернета.

Сколько стоит перейти с прямого RDP на VPN или RD Gateway?
Для компании до 20-30 рабочих мест обычно это 15-40 тысяч рублей разовой настройки, если оборудование уже есть — роутер с поддержкой VPN или сервер под RD Gateway. Если нужно докупать железо, добавится его стоимость, но начать можно и с бесплатного WireGuard на существующем Keenetic. Сравните это с 11 днями простоя и стоимостью восстановления после шифрования — вопрос экономики решается сам собой.

У нас RDP открыт годами и ничего не случилось. Зачем что-то менять сейчас?
То, что не случилось пока — это не показатель безопасности, а вопрос времени и удачи. Сканеры находят открытые порты в среднем за несколько часов после появления, а дальше всё зависит от того, кто первым доберётся до вашего пароля или уязвимости. Большинство моих клиентов приходили с этим вопросом уже после первого инцидента — я предпочитаю разговаривать об этом до, а не после.

Что делать, если удалённый доступ нужен не сотрудникам, а внешнему подрядчику — например, программисту 1С?
Точно так же не давать прямой RDP наружу. Заведите отдельную временную учётную запись с ограниченными правами, подключайте подрядчика через тот же VPN или через Gateway с включённым журналированием сессий, и обязательно отключайте доступ сразу после завершения работ. Подрядчики — частый источник компрометации именно потому, что их учётки живут в системе месяцами после того, как работа давно закончена.