
Привет Хабр!
Для организации удалённой работы и технической поддержки многие компании продолжают использовать проверенные, но морально устаревшие технологии — RDP и VNC. Несмотря на широкое распространение, эти протоколы несут серьёзные риски для информационной безопасности, особенно критичные в современных условиях.
Ключевые проблемы традиционных решений:
Основной недостаток RDP и VNC — их уязвимость. Стандартные порты (3389 для RDP, 5900 для VNC) легко обнаруживаются при автоматическом сканировании. Смена портов обеспечивает лишь минимальную защиту от массовых атак, но не предотвращает целевое воздействие. Фундаментальные ограничения протоколов усугубляют ситуацию: базовый VNC не поддерживает шифрование трафика, а RDP допускает откат к небезопасным алгоритмам шифрования.
Слабая аутентификация как вектор атаки:
Большинство реализаций VNC и RDP не поддерживают многофакторную аутентификацию, что делает их уязвимыми к перебору паролей и использованию скомпрометированных учётных данных. Исторические уязвимости, такие как CVE-2019-0708 (BlueKeep), демонстрируют катастрофические последствия эксплуатации устаревших протоколов.
Человеческий фактор и сложность администрирования:
Настройка безопасности требует высокой квалификации, а в унаследованных системах часто встречаются ошибки конфигурации. Средства защиты могут отключаться случайно или намеренно, а в крупных инфраструктурах системы безопасности часто развёрнуты фрагментарно.
Современные требования к безопасности:
Актуальные решения должны обеспечивать:
Шифрование трафика по умолчанию с использованием современных алгоритмов
Обязательную многофакторную аутентификацию
Централизованное управление политиками безопасности
Защиту от перебора паролей и автоматических атак
Интеграцию с корпоративными системами аутентификации
Сквозное аудирование всех операций
Стратегия перехода:
Миграция на современные решения требует поэтапного подхода:
Закрытие устаревших портов и протоколов
Внедрение MFA для всех систем удалённого доступа
Настройка мониторинга и системы оповещений
Тестирование решений на пилотных группах
Постепенное расширение охвата
Результат оправдывает затраченные усилия — современные системы удалённого доступа обеспечивают не только безопасность, но и операционную эффективность, что особенно важно в условиях растущих киберугроз и ужесточения требований регуляторов.
В ближайшее время планирую провести сравнительный анализ российских решений для удалённого доступа — следите за обновлениями.
Комментарии (35)

JBFW
03.10.2025 10:05Первое же очевидное решение - ВПН до сервера и работа по rdp внутри безопасного канала.
Это будет лучше чем любое новое закрытое "решение", а накладные расходы на шифрование все равно будут, хоть на транспортном уровне, хоть внутри этого самого решения.
Ах да, ещё требования регуляторов: они могут запретить не-гост, например, или ВПН как таковые...

Cyber_Griffin Автор
03.10.2025 10:05VPN + RDP — рабочая схема, но она требует сложной настройки безопасности на нескольких уровнях.
И как вы сами сказали, требования регуляторов сейчас требуют решения из "коробки" которые соответствуют требованиям, после Аэрофлота и Неофарма ситуация стала еще острее, теперь для госников или холдингов, лучший расклад если не придется переплачивать вендору за серт ФСТЭКа

JBFW
03.10.2025 10:05Настройка безопасности там одна - ВПН канал, его можно вообще на смарт-токенах сделать и тогда никто без токена не пролезет.
А вот некая новая программа - это новые дыры, о которых ещё не узнал )
Так что тут вопрос не в безопасности, а в продаже этого самого "решения" под соусом безопасности и импортозамещения.

Spyman
03.10.2025 10:05Для подключения точка - точка - впн - безопасное решение. Но вот если это целая корпоративная сеть, куда много чего подключено - то безопасность резко падает. Надо это учитывать)

JBFW
03.10.2025 10:05Да ладно?
Чем подключение "командированный Вася заходит на сервер ГК из Магадана" отличается от "бухгалтерия у нас работает с 1С удаленно"?
Мы не говорим про случай, когда ВПН даёт просто доступ в локалку, в которой терминальный сервер, файлопомойка, рабочие станции с расшаренными дисками c$, сетевые принтеры и прочее такое же.

fcoder
03.10.2025 10:05Я перепробовал десятки разных тулов удалённого подключения и не нашёл ничего даже отдалённо похожего на RDP.
С точки зрения юзабилити там чаще всего там проблемы с пробросом оборудования на хост, поддержки мониторов, горячих клавиш и буфера обмена. В родном виндовом стеке можно делать ctrl+c/ctrl+v на текст, выделенную картинку или файл. Она сразу понимает какие у меня мониторы и микрофон. Win+буква работает корректно в удалённой системе, а не бесит перепрыгиванием в домашнюю. Почему так сложно поддержать совсем базовый UX? Или "разработчики" подобных систем неспособны собрать минимальный набор требований?
С точки зрения безопасности, часто исходники закрыты, а серверная часть требует связи с материнским кораблём. Это для меня абсолютно дисквалифицирующий фактор. О какой безопасности можно говорить вообще?
kenomimi
03.10.2025 10:05Для частного использования Spice работает отлично - 2-3 FHD экрана, и на 4G модеме оно почти не лагает, разве что видео рывками показывает. Пользуюсь уже несколько лет, очень доволен. У него защита никакая, но стандарт отрасли - ipsec (или иной впн), а уже внутри все сервисы, так что не критично.
А вот для многопользовательской терминальной фермы кроме rdp ничего как-то и не завезли. Или анально-закрытое облачное с приличной вероятностью взлома со стороны вендора (сломают облако - считай сломают всех клиентов разом), или решения за миллиарды (которые еще и не работают хорошо без постоянной поддержки вендора), или тормозящие наколенные поделки.

Al_Tar
03.10.2025 10:05Spice за собой тянет KVM : по нему Вы только к ВМ под KVM afaik можете получить. А если в инфре другой гипервизор ,или удаленная машина - физическая?

Shaman_RSHU
03.10.2025 10:05Думал, что проблема преувеличена, но потом с помощью shodan.io увидел, что открытых в Интернет RDP портов - 3,110,255

Spyman
03.10.2025 10:05Ну ssh портов открытых в интернете скорее всего ещё больше - но это же не значит, что они все уязвимы)

seriouskaktus
03.10.2025 10:05Какой смысл в этой сгенерированной чатгпт статье? Сказать, что нативные протоколы небезопасны и поголовно переходите на проприетарные anydesk?

Isiirk
03.10.2025 10:05О чем статья? RDP прекрасно себя чувствует и прекрасно шифруется хоть по самое не балуй, вы с какой планеты? При этом стабилен, функционален и ни каких проблем не вызывает, в отличии от всего остального, что есть на рынке

dimsoft
03.10.2025 10:05Никто не догонит rdp на windows по скорости, т.к ему не надо ждать всей картинки и потом её сживать и передавать.

edst_land_ru
03.10.2025 10:05RDP + Wireguard = быстро и надежно.
Помнится, до того, как я познал WireGuard VPN, был сильно удивлен, как жестко долбятся боты в открытый RDP. Перевешивать его с 3389 порта на другой смысла никакого. Только в связке с VPN
А внутри сети - TightVNC с жесткими правилами доступа

JBFW
03.10.2025 10:05Тут проблема другого плана: упомянутые "регуляторы" уже зарегулировали Wireguard, чтобы люди их запреты не обходили - поэтому придется искать другие варианты.
Но направление поисков верное...
edst_land_ru
03.10.2025 10:05На этот случай есть процедура внесения IP в белый список, я не поленился и внес, и вроде пока регуляторы меня не блокируют.

Black_Spirit
03.10.2025 10:05Несколько лет есть в аренде vps с windows server. Ничем не прикрытым 3389 открыт в интернет. Хотя ничего критичного на сервере не запущено, но пока не взломали.
Да, для чего-то более серьезного у меня свой способ защиты rdp.

Bagatur
03.10.2025 10:05SSL VPN до DMZ (ipsec, увы, нередко банят, а в некоторых странах типа ОАЭ можно и огрести), в DMZ терминальник с доменной аутентификацией+ MultiOTP, с этого терминальника уже в интранет.

JBFW
03.10.2025 10:05А вот тут отвечу, почему какая-нибудь крупная компания предпочтет купить проприетарное, вместо этой работающей схемы:
Во-первых, ответственность. Если что-то пойдет не так - нужно будет не своего сисадмина по заднице бить, а выкатить претензию вендору, с компенсациями.
Во-вторых, техподдержка: опять же, вместо толкового сисадмина - договор с поставщиком решения, все проблемы на него, и если что-то пойдет не так см.п.1
Ну ещё и локальный закупщик может подарки от вендоров получать, маркетологи на сотрудничество будут ссылаться, безопасники с себя всю ответственность скинут, вот это всё

severgun
03.10.2025 10:05Нахер нам российские решения? Точнее к чему это ограничение?
Не забудь уточнить сколько из них использует под капотом freerdp, turbo/tigervnc, rustdesk.
Не забудь уточнить кто из них поддерживает несколько пользовательских сессий одновременно. Тимвьюеры, растдески и энидески не нужны
Не забудь уточнить кто из них поддерживает virtualGL или другой способ удаленной отрисовки.
Не забудь уточнить цену.
За пустой ИИ сгенерированный текст маловато минусов.

AndrewTishkin
03.10.2025 10:05Кхм. Два ощущения.
Первое - пиво закончилось и статья прервалась так нормально и не начавшись.
Второе - вроде судя по анекдотам профиля автор суровый дядечка, но по тексту какой-то зелёный стажёр.
Не так давно не смог зайти на виндовый сервер. Грешил на провайдеров, но трассировка обрывалась на входе в ДЦ. Потом вспомнил, что уже несколько лет там работает простой скрипт: он считает виндовые события журнала о неуспешных попытках входа и вносит айпишник в чёрный список системного брандмауэра.
Максимально просто и эффективно. Плюс можно нагуглить ещё некоторые настройки винды, уменьшающие вероятность стороннего проникновения. В качестве резервного способа входа на машинке настроен гугловский ремонт десктоп. Так что проблема с RDP походу высосана не знаю даже из чего - нечего там сосать. А в плане эффективности работы на самом жопном интернете это реально хороший протокол.

kuragami
03.10.2025 10:05Возможно здесь найду ответ: rdp через ms gateway, на котором нужно получить ответ от мобильного приложения. Вообще не получается подключиться на linux (remmina, freerdp и все такое). Клиент не ждёт ответа от gateway и пытается пройти дальше. Все возможные настройки (транспорт, таймауты, сертификаты) - мимо. В win работает только начиная с win10. Приходится запускать виртуалку, что кажется overkill. Может кто сталкивался?
0xC0CAC01A
Вопрос в тему: работающие приложения удалённого доступа к андроиду так и не появились? Человечество утратило знание как писать сервера удалённого доступа?
Shaman_RSHU
Про это https://github.com/Genymobile/scrcpy ?
Cyber_Griffin Автор
Тестил RuDesktop и Ассистент, они работают с Android, но с ограничениями:
В Ассистенте есть только просмотр экрана и передача файлов и он требует ручного подтверждения доступа, в RuDesktop ситуация получше, но как и Ассистенте без root нет полного управления
ajijiadduh
anydesk разве не умеет?
Cyber_Griffin Автор
Если речь идет о корпоративном УД как с ним быть?
tatar221
Он после нескольких подключений денег просит. Полдня сидел настраивал на двух компах и на телефоне. На следующий день отказался подключаться - говорит "дай денег". Компы личные, тел личный.
ilkman
В чем проблема почистить нудные папки и продолжить работать?
tatar221
В критических ситуациях юзаю Chrome Remote Desktop. Меня спасает
4kirill20
+, жаль что меню выпадающее сверху как в AnyDesk в бок не перетащить
m0tral
Microsoft Remote Desktop существует много лет, Windows App сейчас