Comments 32
Для виндовых машин, я бы ещё Remote Desktop Gateway посоветовал.
Тоже отличная и достаточно безопасная альтернатива VPN.
Тоже отличная и достаточно безопасная альтернатива VPN.
Конечно, недавно RCE-шечка была про него и UDP.
На хабре тоже было, но быстро не нашел…
kb.cert.org/vuls/id/491944
betanews.com/2020/01/27/windows-remote-desktop-gateway-rce-exploit
На хабре тоже было, но быстро не нашел…
kb.cert.org/vuls/id/491944
betanews.com/2020/01/27/windows-remote-desktop-gateway-rce-exploit
я знаю про эту уязвимость, а так же то, что уже в январе вышел патч для неё.
portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0609
portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0609
Я правильно понимаю, что решение обеспечивает доступ только по SSH? Через VPN так-то ещё много к чему возникает потребность коннектиться: от бесчисленных вебморд до файловых шар.
Именно это решение — трудно сказать.
А вообще port knocking откроет любые порты.
А вообще port knocking откроет любые порты.
Но в случае с вебмордой, которая вполне может быть HTTP (без SSL), или прямого доступа к базе данных, это не отменяет VPNа. А в статье предлагается VPN убить как класс :)
Правильно предлагают.
Масса мороки при отсутствии гарантии безопасности.
Масса мороки при отсутствии гарантии безопасности.
Как раз мороки-то с VPN меньше всего — настроил и забыл, работаешь одинаково, в какой бы сети: локальной или удалённой, ни находился. А делать отдельную систему с 2FA, port knocking, пробросом портов и т.п. для каждого сервиса в локалке, когда их надо использовать несколько десятков — ну такое…
Гарантии безопасности, опять же, не даёт никто. В сценарии «зловред поселился на ноуте удалённого сотрудника», например.
Поэтому я бы предлагал без радикальных лозунгов в каждом случае использовать оптимальный вариант или их сочетание. И для VPN есть масса применений, когда именно он будет оптимальным выбором. VPN с 2FA или тем же port knocking, например; или второй уровень авторизации для доступа к наиболее критичным сервисам из VPN-подсети.
Гарантии безопасности, опять же, не даёт никто. В сценарии «зловред поселился на ноуте удалённого сотрудника», например.
Поэтому я бы предлагал без радикальных лозунгов в каждом случае использовать оптимальный вариант или их сочетание. И для VPN есть масса применений, когда именно он будет оптимальным выбором. VPN с 2FA или тем же port knocking, например; или второй уровень авторизации для доступа к наиболее критичным сервисам из VPN-подсети.
Ssh port forwarding же никто не отменял? Конечно, это не системное решение проблемы, но зачастую, когда ничего лучше нет — вполне работает
У нас, например, некоторые вебморды и продукты Atlassian доступны только через VPN.
Ваша система, как я понял, такое не обезопасит.
Ваша система, как я понял, такое не обезопасит.
Автор исходит из предположения, что подключившись по VPN к сети компании он попадет в плоскую доверенную локальную сеть. Но мне кажется, что такое можно встретить только в небольших компаниях с начинающим эникеем вместо грамотного админа. В нормальных условиях VPN обычно получает доступ к внутренним ресурсам компании через DMZ и разные прокси-сервисы (выше уже писали). Плюс локальная сеть компании обычно разделяется на подсети, из которых доступны только необходимые ресурсы.
Это не модно ) коллеги же написали, что у них зероу-траст. Никто никому не верит )
У вас тут оксюморон какой-то: из правильного DMZ до чего-то интересного, до чего обычно попадают через VPN, достучаться должно быть невозможно. Или я что-то неправильно понял
Автор потерял суть того, что ВПН — это прежде всего virtual (наложенная сеть). А механизм организации виртуала может быть разный. В том числе и SSH.
Ещё я встретил упоминание в статье, что чаще всего админы используют организацию vpn-доступа типа мост, хотя это вряд ли. Через бридж червям проще пробираться к хостам в доверенной сети. Если брать пример ASA, то мобильный клиент или clientness получают не всю сеть, а только опубликованные для данного пользователя приложения или другие ресурсы. Есть много препятствий для того, чтобы VPN "умер", хотя решение, предлагаемое автором, интересное и представляет собой этакую эшелонированную защиту.
Из того что понял ничего интересного в решении не вижу. Имеем договор с провайдером услуги, который имеет пул белых ip-адресов и пул адресов сервисов. Пул адресов сервисов сопоставлен с именами по гуид на стороне провайдера услуги (привет днс). Дальше банальный ВПН. Сервисы должны быть точно также опубликованы (в данном случае можно закрыться доступом с конкретного адреса провайдера). Теоретически просматривается возможность атаки «человек посередине» между провайдером услуги и опубликованным сервисом.
Также при критичном сервисе авторизация делается по сертификатам. Из статьи использование сертификатов для авторизации не следует(только получение ключей шифрования от сервера). Если конечно гуид это не сертификат в изложении автора…
Плюс в системе безопасности появляется дополнительное звено, не контролируемое в части технических и программных решений.
Т.е. для небольшой организации наверное подойдёт, но нужно оценивать риски и стоимость информации в соотношении со стоимостью услуги. Для более крупных организаций — только самостоятельно(без услуг третьих лиц) контролируемый периметр с разграничением зон доступа.
Пример: чем плох тимвьювер — трафик идёт через провайдера услуги и может им контролироваться.
Также при критичном сервисе авторизация делается по сертификатам. Из статьи использование сертификатов для авторизации не следует(только получение ключей шифрования от сервера). Если конечно гуид это не сертификат в изложении автора…
Плюс в системе безопасности появляется дополнительное звено, не контролируемое в части технических и программных решений.
Т.е. для небольшой организации наверное подойдёт, но нужно оценивать риски и стоимость информации в соотношении со стоимостью услуги. Для более крупных организаций — только самостоятельно(без услуг третьих лиц) контролируемый периметр с разграничением зон доступа.
Пример: чем плох тимвьювер — трафик идёт через провайдера услуги и может им контролироваться.
Teamviewer для небольших организаций плох ещё и тем, что для корпоративного использования спрашивает от 2к рублей ежемесячно. «Бесплатные» варианты я не обсуждаю.). В этом плане chrome remote desktop выигрывает. Кроме того, не контролируется вход (хотя есть возможность организовать сеть из доверенных хостов), возможна компрометации логина-пароля и т.д. а собственный vpn-сервер уже встроен. OASA от Okta все это умеет. Но проблема в том, что когда автор описывает преимущества технологии, он применяет ее для облачного инстанса. Есть и плюшки — услуга у амазона бесплатна, если не превышать определенный порог вычислительных мощностей (количество запросов, время и трафик). Непонятно, как это организовать для сети предприятия. Никакой провайдер интернета услуги ротации публичных адресов не предоставляет, кроме фиксированного пула статических. И хоть один статический нужен, если существует связь с филиалами, значит, мишень для хакеров остаётся. Поправьте меня, если я что-то неправильно понимаю.
Аргумент автора, что причиной уязвимости vpn является неправильная его настройка, вообще рассматриваться не может — нечего экономить на квалифицированном персонале и аудите.
Аргумент автора, что причиной уязвимости vpn является неправильная его настройка, вообще рассматриваться не может — нечего экономить на квалифицированном персонале и аудите.
Согласен полностью. Могу добавить, что, на мой взгляд, разумнее было внедрить сертификаты, двухфакторную авторизацию и защиту стоить с учетом рисков. Что таки да, требует некоторой квалификации от персонала. И даже с этим соломки не напасешься… Что ваннакрай и доказал
Wannacry это уже больше к host-based defence, хотя есть еще ips и антивирусы в почтовых серверах. Но вот автор среди пострадавших перечисляет такие vpn: Pulse Secure «Connect» VPN (CVE-2019-11510), the Fortinet FortiOS VPN (CVE-2018-13379), and Palo Alto Networks «Global Protect» VPN (CVE-2019-1579), посмотрел, в основном в них реализован OpenVPN, в одном есть ещё и remote IPSec. OVPN подразумевает сертификаты и пароли как к самим сертификатам, так и к подключению пользователя ppp. Вроде бы попробуй пройди, но атаки велись с использованием уязвимостей в самих программных реализациях, которые разные в каждой линейке и операционной системе. Например, уязвимость CVE-2019-1579 в ОС Pan-OS роутера "… may allow an unauthenticated remote attacker to execute arbitrary code". И.е. хакер не стремится пройти аутентификацию и авторизацию, он находит такой программный кусок, который позволяет ему выполнить его произвольный код.
Классически из зоны DMZ нет доступа в доверенную сеть. Пример — та же Cisco ASA с ее зонами, из зоны dmz нельзя попасть в зону inside, если иное не прописано в листе доступа, и назначение зоны DMZ это обычно предоставление услуг типа веб-сервера внешним посетителям, часто безо всякой аутентификации.
Наверное нет смысла обсуждать это здесь.
Это всего лишь перевод и автор никогда этого не увидит.
Это всего лишь перевод и автор никогда этого не увидит.
Посоветуйте защиту rdp?
Remote Desktop Gateway с нормальным сертификатом и последними обновлениями
Удаленка — просто и безопасно: rdp, port knocking, mikrotik https://habr.com/ru/post/495596/
У меня реализовано так:
USB live Linux, которая работает на практически любом ноуте/компе.
Там настроенный VPN и клиент RDP до рабочего места сотрудника.
Сотрудник имея с собой эту флешку, может работать даже будучи в гостях.
Так можно делать, но требуются небольшие раз'яснения.
- VPN, а какой конкретно (remote ssl, remote ipsec, openvpn, etc) и какой способ аутентификации используется? Если ipsec, то встречаются ли проблемы преодоления nat, и вообще, какой шлюз доступа в Вашей организации?
- Настроенный, а параметры подключения и аутентификации как сохраняются на образе livecd usb после перезагрузки? Я имею в виду, что обычно livecd, даже есть он на флэшке, это неизменяемый образ, поэтому интересно, как у Вас конкретно реализовано сохранение вносимых в процессе работы (тот же ввод параметров) изменений.
- Какой уровень безопасности установлен в Вашей организации, работает ли она с персональными данными, есть ли безопасности и как они относятся к этому способу мобильного подключения?
Можно теперь те же сценарии рассмотреть, и пояснить, в чем преимущества по сравнению с нормальным VPN?
Я понимаю, если бы была предварительная проверка безопасности удаленного ПК (хотя бы проверка, что есть антивирус, обновлялся относительно недавно...). Впрочем, и это VPN решения делают.
Представьте если на вашем ноутбуке поселился вирус и вы подключаетесь через VPN к сети боевых серверов? Та-дам! У вируса теперь есть доступ на уровне локальной сети к вашему продакшену.В моем представлении, что раньше в такой ситуации злоумышленник/зловред получал доступ к ресурсам, доступным через VPN, что теперь. Разумеется, я говорю про enterprise решения, где VPN открывает доступ только к определенным ресурсам (набор хост: порт), а не во всю ЛВС.
Я понимаю, если бы была предварительная проверка безопасности удаленного ПК (хотя бы проверка, что есть антивирус, обновлялся относительно недавно...). Впрочем, и это VPN решения делают.
Когда клиент готов установить соединение, происходит запрос уникального GUID, с помощью которого выясняется IP.Можно подробней, как происходит запрос и как выясняется IP?
UFO just landed and posted this here
Sign up to leave a comment.
Убийца VPN. Правильный удалённый доступ к боевым серверам