Комментарии 58
У вас потерялась вторая часть статьи, где вы описываете способ организации VPN подключения с минимальными телодвижениями для конечного пользователя, работающего из дома.
С минимальными телодвижениями, быстро и бюджетно — это все-таки про сервисную модель. Если интересно, варианты для организации безопасного удаленного доступа, которые предлагаем мы, можно посмотреть тут www.youtube.com/watch?v=FJ9ADBtMF8A
При включенном NLA (что windows давно делает по умолчанию) насколько я понимаю никогда уязвимостей не было, плюс с включенными апдейтами оперативно исправляются и остальные "угловые ситуации", так что для личного пользования я лично не гнушаюсь открывать RDP "в интернеты". Так сказать указываю возможную мотивацию для использования напрямую. :)
А использование нестандартного порта просто делает сервер практически необннаруживаемым.
Заблуждение.
У нас 2 года назад взломали доступ по RDP и внедрили шифровальщик. Хорошо, что у взломанного пользователя никуда к важной инфраструктуре доступа не было. Так что, ущерб был минимальным.
А порт был, таки, нестандартным… да.
У нас 2 года назад взломали доступ по RDP и внедрили шифровальщик. Хорошо, что у взломанного пользователя никуда к важной инфраструктуре доступа не было. Так что, ущерб был минимальным.
А порт был, таки, нестандартным… да.
Распространенное заблуждение. А теперь посмотрите свои логи.
Прошли те времена, сейчас находят и брутят рдп и на чужих портах
NLA действительно включен в Windows по умолчанию и делает невозможной эксплуатацию части уязвимостей, поскольку требует аутентификацию до установления сессии, однако по-прежнему можно осуществить подбор учетных данных, и в нашей практике встречались случаи подбора пароля к RDP при включенном NLA с последующим внедрением вредоносного ПО на системе. К сожалению, практика показывает, что далеко не всегда в инфраструктуре организации возможно оперативно установить свежие обновления безопасности (именно поэтому к каждой исправленной уязвимости пишутся временные меры для тех, кто не имеет возможности установки обновлений). Ситуация с использованием RDP с доступом из сети Интернет для личного использования все же немного отличается от использования удаленного доступа для сотрудников организаций, в последнем случае требуется больше внимания уделить защите этого процесса.
Тут работает принцип Неуловимого Джо.
Обычно поиском доступных серверов с RDP занимаются для продажи доступа всяким майнерам. От них легко защититься нестандартным паролем и ограничением прав учётной записи. Ну и в принципе защита на самом сервере стандартными антивирусными практиками.
А если у злоумышленника цель: получить доступ к серверам компании, то тут уже просто включается борьба «стоимость защиты против стоимости выгоды от взлома». А если цель: любой ценой, то извините, даже VPN не панацея.
Обычно поиском доступных серверов с RDP занимаются для продажи доступа всяким майнерам. От них легко защититься нестандартным паролем и ограничением прав учётной записи. Ну и в принципе защита на самом сервере стандартными антивирусными практиками.
А если у злоумышленника цель: получить доступ к серверам компании, то тут уже просто включается борьба «стоимость защиты против стоимости выгоды от взлома». А если цель: любой ценой, то извините, даже VPN не панацея.
Стойте-стойте. Так мы все же о домашнем использоаании или про "число корпоративных серверов, доступных для злоумышленников из интернета" в пугающую эпоху "глобальной пандемии"?
Графики c отрезанной осью ординат? Очень информативно, да.
Ось была такая: внизу отметка со значением «мало», а вверху отметка со значением «много». Согласитесь, такую и отрезать не страшно.
Около десятка серверов начиная от с 2003 сервера по RDP, на разных портах в разных организациях живут уже более десятка лет. Ни разу ни у кого из них не было проблем, может потому что стандартные пользователи отключены и пароли не очень простые.
Конкуренты в том году больше миллиона отдали за то, чтобы им вернули данные. А так да, до этого у них проблем тоже не было.
Это как с короновирусом сейчас, кто-то недооценивает его опасность… Вот вы в этой группе, только недооцениваете опасность открытых портов в интернет. Достаточно будет ОДНОГО раза и всё, перескочите в альтернативную группу.
Хоть какой UpdatePack от simplix накатите для приличия
Открывать RDP наружу — самоубийственное занятие. На практике несколько раз сталкивался с тем, что сервер был взломан, а все важные данные были зашифрованными. После таких случаев, у этих контор отключался режим скупости и они соглашались на любые траты ради организации безопасного удалённого доступа. Часто просто покупался Mikrotik, на котором поднимался IPSEC/L2TP сервер, а учетки L2TP синхронизировались с Radius или контроллера домена.
Голый RDP в наше время это, конечно, моветон. Сейчас любой Кинетик умеет в OpenVPN и, в принципе, любая небольшая или средней руки контора, может малой кровью и без особого напряга организовать удалёнку.
НЛО прилетело и опубликовало эту надпись здесь
Если речь про домашнего пользователя
OpenSSH есть даже в десятке. Иногда кобызится с ключами работать, надо через icacls права на ~/.ssh/authorized_keys править, но в целом великолепная вещь когда надо и безопастно и прокинуть что угодно. На роутере порт пробрасывается до ПК и вот вам счастье. Уже даже VS Code допилили до возможности с виндой по Remote SSH полноценно работать.
А ещё есть весёленький p2p vpn — tinc.
Со стороны организаций же выталкивать в мир RDP — это реально странно и стрёмно.
OpenSSH есть даже в десятке. Иногда кобызится с ключами работать, надо через icacls права на ~/.ssh/authorized_keys править, но в целом великолепная вещь когда надо и безопастно и прокинуть что угодно. На роутере порт пробрасывается до ПК и вот вам счастье. Уже даже VS Code допилили до возможности с виндой по Remote SSH полноценно работать.
А ещё есть весёленький p2p vpn — tinc.
Со стороны организаций же выталкивать в мир RDP — это реально странно и стрёмно.
Я ждал этой новости.
Когда волна начнет спадать, я также жду роста спроса на (в особенности защищенные) инфраструктурные решения и продукты. В первую очередь в госсекторе. Цифровизация должна пойти в гору на повышеных оборотах. Нашему брату от этого только польза.
Когда волна начнет спадать, я также жду роста спроса на (в особенности защищенные) инфраструктурные решения и продукты. В первую очередь в госсекторе. Цифровизация должна пойти в гору на повышеных оборотах. Нашему брату от этого только польза.
Не холивара ради, но всё же…
1. Чем подбор пароля от RDP сложнее чем подбор пароля от VPN?
2. Чем уязвимость в софте RDP отличается от уязвимости в софте VPN?
3. Ну и в итоге на основании предыдущих пунктов: Чем безопасность подключения по VPN надежнее чем по RDP? При том, что взломав VPN злоумышленник не просто получает доступ к ПК, но и ко внутренней сети.
1. Чем подбор пароля от RDP сложнее чем подбор пароля от VPN?
2. Чем уязвимость в софте RDP отличается от уязвимости в софте VPN?
3. Ну и в итоге на основании предыдущих пунктов: Чем безопасность подключения по VPN надежнее чем по RDP? При том, что взломав VPN злоумышленник не просто получает доступ к ПК, но и ко внутренней сети.
- Тем, что при VPN логин+пароль+ключ.
Совершенно верно.
Логин+Пароль VS Логин+Пароль+Ключ. Других принципиальных отличий по безопасности нет, и я рад, что здесь достаточно компетентный народ, который с пунктом 2 не спорит.
Но, что мешает нам поставить на RDP пользователя длинный пароль? Windows поддерживает макс длину до 127 символов, такой пароль на современных компьютерах подобрать невозможно, его легко сгенерировать, а человеку выполняющему подключение, без разницы, какой длины будет copy/past в строку пароля (мы понимаем, что для RDP заводится спец. пользователь с требуемыми правами).
Соответсвенно, сравниваем 2 конфигурации:
1. RDP с длинным паролем напрямую через интернет.
+ Не требуется лишних телодвижений весь ф-ционал настройки RDP доступен из коробки в Windows.
2. RDP через VPN
— Кроме RDP требуется дополнительная установка/настройка VPN
— Подключение работает медленнее, так как кроме стандартного RDP шифрования дополнительно выполняется ещё и VPN шифрование.
— При взломе VPN, если он настроен по умолчанию (или не достаточно компетентно), хакер получает сразу доступ ко всей внутренней сети, в отличии от доступа к одиночному ПК в случае взлома RDP (хотя и через него тоже потом теоретически можно получить доступ ко внутренней сети).
Как мы видим, обе конфигурации обеспечивают примерно одинаковый уровень безопасности, но вариант «RDP с длинным паролем напрямую через интернет» однозначно выигрывает.
По сему, главный посыл статьи, о том, что RDP напрямую с выходом в интернет – опаснее, чем через VPN, считаю не верным, при условии правильной настройки RDP.
Логин+Пароль VS Логин+Пароль+Ключ. Других принципиальных отличий по безопасности нет, и я рад, что здесь достаточно компетентный народ, который с пунктом 2 не спорит.
Но, что мешает нам поставить на RDP пользователя длинный пароль? Windows поддерживает макс длину до 127 символов, такой пароль на современных компьютерах подобрать невозможно, его легко сгенерировать, а человеку выполняющему подключение, без разницы, какой длины будет copy/past в строку пароля (мы понимаем, что для RDP заводится спец. пользователь с требуемыми правами).
Соответсвенно, сравниваем 2 конфигурации:
1. RDP с длинным паролем напрямую через интернет.
+ Не требуется лишних телодвижений весь ф-ционал настройки RDP доступен из коробки в Windows.
2. RDP через VPN
— Кроме RDP требуется дополнительная установка/настройка VPN
— Подключение работает медленнее, так как кроме стандартного RDP шифрования дополнительно выполняется ещё и VPN шифрование.
— При взломе VPN, если он настроен по умолчанию (или не достаточно компетентно), хакер получает сразу доступ ко всей внутренней сети, в отличии от доступа к одиночному ПК в случае взлома RDP (хотя и через него тоже потом теоретически можно получить доступ ко внутренней сети).
Как мы видим, обе конфигурации обеспечивают примерно одинаковый уровень безопасности, но вариант «RDP с длинным паролем напрямую через интернет» однозначно выигрывает.
По сему, главный посыл статьи, о том, что RDP напрямую с выходом в интернет – опаснее, чем через VPN, считаю не верным, при условии правильной настройки RDP.
2. А что, обязательно выпускать ВПНщиком прям в офисную сеть? Я понимаю, так делают большинство. Но если у нас ВПН для РДП? ТОгда мы получаем сумму времени взлома впн и рдп.
ТОгда мы получаем сумму времени взлома впн и рдп.Теоретически да, если пытаться честно брутфорсом подбирать пароли/ключи то получаем увеличение времени, но по факту даже просто длинный пароль 64 и более символов на RDP подобрать не реально, зачем городить еще доп нагрузку в виде VPN?
А если не честно ломать, через дыры в ПО RDP или VPN, то разницы защиты нет, хакер получает доступ с root к системе и делает всё что ему нужно…
Тем, что VPN по сертификату в изолированную сеть, а там уже доступен только RDP Gateway, к которому дальше подключается клиент.
Ну и приправить Port Knoking'ом и Fail2ban'ом.
Ну и приправить Port Knoking'ом и Fail2ban'ом.
А если белому списку IP-адресов открыть только доступ к RDP? Это решит проблему безопасности?
Вы предлагаете внести в белый список все провайдерские пулы IP-адресов?
У меня 15 сотрудников на удалёнке. Из них у троих только динамический ip. Для них я внёс всю подсеть x.x.x.0/24. А у остальных статика. Сейчас статика — обычное дело, как я погляжу.
Статика — только при наличии технической возможности и за отдельную плату. А ipv6 далеко не все провайдеры предоставляют, к сожалению…
Обычным делом статика была лет 15 назад. Сейчас обычное дело — nat.
Обычным делом статика была лет 15 назад. Сейчас обычное дело — nat.
Ну работает же)
Это пока не найдётся товарищ, выходящий в инет через сотовый модем. Там адреса несколько менее предсказуемы, чем /24.
Вобщем, не надо выдавать ошибку выжившего за общую практику.
Вобщем, не надо выдавать ошибку выжившего за общую практику.
Тогда впн на кинетике, как уже тут говорили.
Э… Кинетик со стороны работы чтоль? Я как-то не готов пускать в рабочую сеть детей :-)
Детей со стороны удаленного работника?) Ну там фильтрация есть.
Э… Фильтрация где? На стороне офиса — все соединения одинаковы, они уже пришли по впн. На стороне кинетика разве что и то не особо возможностей, по-моему,. Но накой так извращаться, если надёжнее просто поставить клиента из заранее подготовленного дистрибутива? Подозреваю, что так заодно и скорость передачи будет повыше, так как openvpn всё ж чувствителен к скорости проца.
Вы имеете в виду ноутбуком обеспечивать с заранее установленным дистрибутивом? И что там будет, отличного от его винды? Или вы хотите ему Линукс поставить?? Продажникам?.. Ну-ну...
Для openvpn под винды вполне можно подгототовить дистрибутив, из которого поставится уже сконфигурированное и готовое к работе. Или вы таки пойдёте к продажникам до дому, ковырять кинетик? А если там не кинетик?
Где-то видел даже онлайн-генератор такого, но не факт, что сейчас найду — мне было не актуально ещё когда настраивал, а теперь на новой работе всё по-другому…
Где-то видел даже онлайн-генератор такого, но не факт, что сейчас найду — мне было не актуально ещё когда настраивал, а теперь на новой работе всё по-другому…
Да не их кинетик. На их компе в два касания устанавливается l2tp.
Но ведь в windows есть свой клиент VPN, который умеет и PPTP, и L2TP? Чем он плох?
Про l2tp ничего плохого не скажу, так как не в курсе, можно ли ему подсунуть конфигурацию в один клик (+«далее-далее-финиш»), а вот pptp просто недостаточно безопасен. Да и gre некоторыми провайдерами и домашними роутерами не пропускается.
Да. От pptp отказался уже давно. А l2tp-соединение появляется в соединениях WiFi. Соединяется так же: кликнул/подключиться — все.
Я про создание конфигурации, а не про запуск. Тот же openvpn в сгенерированном установщике — действительно запустить и потом «далее-далее-далее-финиш».
А запуск под виндой везде более-менее одинаков, по-моему.
А запуск под виндой везде более-менее одинаков, по-моему.
Или внезапно получил сообщение типа «модем занят или неправильно работает» (не очень дословно — но слово «модем» там есть, хотя тут никакого модема нету) вместо попытки соединения по VPN. Лечится перезагрузкой, появляется непонятно почему. OpenVPN на Win10 — тоже иногда странно не работает с первого раза (и не связаны эти 2 события никак). Поэтому или ssh connection forwarding, или отдельная железка.
Так я и говорю: кинетик на стороне офиса с поднятыми туннелями. В винде л2тп подключается к рабочему роутеру.
Вам же «только» RDP надо — не «играть по сети через UDP» или соединяться в произвольное место. Зачем «козе баян»? putty (plink) или другой ssh-клиент+ключик+следящая за коннектом оболочка (чтоб не отвалилась сессия в NAT по тайм-ауту)+connection forwarding на RDP-сервер. На ssh-сервере — фаерволим какие клиенты к какому RDP и т.п. коннектятся. Это настраиваемо для работы и в другую сторону (коннект к клиенту с динамическим IP). Зачем возиться с VPN, который меняет таблицы маршрутизации, не всегда пролезает (привет от GRE) и требует админских прав для настройки на клиенте.
Слава непонятно какому богу, мне RDP не требуется :-)
Но идея мне нравится, чем-то напомнила включение-выключение доступа у одного из местечковых провайдеров — вход putty на шлюз, где шеллом стояла программка, показывающая, сколько байтов утекло и кнопкой «выкл интернет», закрывающей соединение и, соответственно, пока та программка запущена — был разрешен доступ дальше.
Но идея мне нравится, чем-то напомнила включение-выключение доступа у одного из местечковых провайдеров — вход putty на шлюз, где шеллом стояла программка, показывающая, сколько байтов утекло и кнопкой «выкл интернет», закрывающей соединение и, соответственно, пока та программка запущена — был разрешен доступ дальше.
Если деньги не платятся за статику — то никто ничего не обещает. И далее внезапно адрес, не менявшийся месяцами, даже при усилиях со стороны клиента (отключиться на сутки+), вдруг сменяется. Придумайте «весёлые обстоятельства», когда «обычное дело» внезапно закончилось и подключиться не получилоось, а также дальнейшие приключения, самостоятельно :).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про удаленку, незащищенный RDP и рост числа серверов, доступных из интернета