Настройка безопасного rdp доступа к рабочей машине?

Question

[asgard88]

Добрый день товарищи! Хочу реализовать возможность безопасного подключения к рабочей машине. Суть такова — имеется машина на win7, хочу сделать проверку при подключении по rdp более надежную, нежели просто логин/пароль.


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


В идеале использовать только стандартные средства ms windows, без установки vpn клиентов, драйверов, токенов, смарткарт или подобного. Разворачивать в сети win server, с центром сертификации, для подключения к 1 машине думаю лишне, да и лицензию покупать надо.


Что посоветуете?


P.s. было бы круто сделать просто самопальный сертификат, сбросить на его на флеху, а рабочую машину заставить проверять есть ли нужный сертификат у клиента.


P.P.S в мир электронных сертификатов, шифрования и подобной паранойи попал впервые, поэтому от огромного количества решений по госту, iso и других технологий просто голова идет кругом.


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

Comments

[lotte123]

Thinstuff, экономично и стабильно. Сами пользуемся))

Answer 1

[script88]

а не лучше сделать через teamviewer?! чем изобретать велосипед

Comments

[arturos]

Тимвьювер годен для разовой работы но не для постоянной, и уж точно не годен для сёрфинга в интернете через него..

[script88]

arturos: Не увидел каких либо доводов.
При нормальном канале, ТМ работает более чем адекватно.

[arturos]

script88: Я ежедневно в ТМ сижу более 4х часов (и канал интернета у меня отличный), потому могу с уверенностью сказать о нём.

Answer 2

[Сергей Альтман]

К сожалению, Windows Server не умеет проверять подлинность клиента по сертфикату. Все те инструкции в интернете, как использовать сертификат - они для того, чтобы КЛИЕНТ проверил подлинность СЕРВЕРА, чтобы не подключиться к "поддельному" серверу.

Еще раз другими словами: сервер подлинность клиента проверяет только по паролю. Чтобы клиент, проверил подлинность сервера - можно использовать сертификат.

Answer 3

[ZoraX]

Можно сделать круче и намного безопаснее без всяких сертификатов прикрученных к винде и прочее:
1. Поднимаем свой openacess vpn сервер на любом облачном VDS сервере, или другом ресурсе. Кстати можно поднять vpn на этом же сервере к которому планируется доступ через RDP (главное чтобы ip адрес был внешний и к нему был доступ из большого интернета)
2. Запоминаем ip адрес этого сервера, в случае с all in one решением, запоминаем внутренний локальный адрес, который каждый раз будет выдаваться нам при подключении к vpn
3. На роутере делаем проброс портов для RDP, в качестве локального порта указываем 3389, в качестве порта торчащего наружу, любой кроме дефолтного. Протолол - TCP IP либо both , адресом источника указываем ip адрес того openvpn сервера. (пункт2)
4. Таким образом, достучаться к Вашему удаленному рабочему столу можно будет только подключившись через vpn, остальные соединения с любых других адресов будут отбрасываться.

Comments

[arturos]

Соглашусь с этим, неплохое решение, но частично.

Это не защищает никак от MiM и прочих атак между VDS и домом.

[ZoraX]

arturos: О какого рода атаках Вы говорите в данном случае, я не понимаю.
1) Я устанавливаю vpn соединение через openvpn c openvpn acess server например в США или Европе (естественно VDS должен быть там и на нём поднят ацесс сервер)
2) С этого момента я не подвержен никаким атакам "человек по середине" , так как весь трафик уже шифруется.
3) Я соединяюсь со своим сервером по RDP уже с новым Ip адресом, который прописан в файрволе как единственный разрешенный к соединению, все остальные соединения рубятся файрволом.
По-моему, схема надёжная и безопасная как 5 пальцев.
И да.. чтобы не заморачиваться каждый раз , находясь внутри локальной сети у себя, я настроил второй ярлык для RDP в котором указан локальный адрес подключения для сервера.

Answer 4

[IgorK11]

Еще подскажите простой способ логирования рдп соединений, кто когда заходил с какого ip.

Integra Login Analytics RDP

Answer 5

[oia]

а не проще сменить порт подключения с 3389 на любой другой?

Comments

[iLexx_13]

имхо, не панацея. Обычным nmap'ом узнается что это за порт.
Сертификаты — надежнее, но я сам не пробовал использовать самоподписанные.

[oia]

тогда ipfw ип доступа + mac

[Daemon_Hell]

Какой мак при подключении через интернет? Дальше ближайшего маршрутизатора его не видно.

[АртемЪ]

Замена порта никак не влияет на безопасность. Хотя снижает активность ботов которые регулярно долбят запросами, пытаясь сбрутить пароль.
В общем менять порт есть смысл только если у вас там логин Admin и пароль Admin

[arturos]

Согласен. Это не влияет на защиту. Это может быть только лишь защитой от тупого поиска порта 3389. Но нацеленный скан - покажет его быстро. И уж тем более не защищает от MiM

Answer 6

[iLexx_13]

Эта win7 стоит за каким-нибудь роутером или там есть полноценный шлюз на лине?
Просто в свое время хотел сделать так:
Шлюз на лине, в нем настраивается port-knocking.
Далее создается самораспаковывающийся архив, в котором лежит port-knocking для windows, сохраненный rdp-конфиг, ярлык для помещания его на рабочий стол, и небольшой bat-файл, который и будет запускаться по ярлыку примерно так:
port-knoking 8080
start mstsc rdp.conf
port-knoking 8081
где 8080 — порт, если на него постучаться то откроется порт для rdp
8081 — порт, если на него постучаться то закроется порт для rdp.

Архив настроил так, чтобы после распаковки копировал ярлык на рабочий стол.
Дальше пользователю ничего не надо делать, кроме как кликнуть на ярлык (запустить bat'ник) и ввести логин/пароль от системы.

Несколько запутано все это — но тогда казалось мне, что пользователям будет проще, чем объяснять как установить сертификат/поднять VPN/etc..., да и безопаснее становится, чем просто по логин/паролю.

Comments

[cjey]

не вижу проблемы настроить VPN клиент. Какая разница, настраивать VPN клиент или PorntKnoking?
Плюс VPN в том, что вы получаете доступ во всю сеть и сервисы, а не только к RPD.
Portknoking менее безопасен. После открытия на него точно также может подключиться любой. Его можно забыть закрыть и т.д.

[iLexx_13]

Эммм.
PorntKnoking — делается на сервере — 1 раз,
bat-скрипт — делается тоже 1 раз.

VPN-клиент — на каждой машине.

Это конечно хорошо, если пользователь это умеет делать сам, а если нет?
Я имел в виду, что это можно автоматизировать — и пользователю нужно
1. распаковать.
2. запустить с ярлыка

Я понимаю, что VPN надежнее, после открытия порта — на него может подключиться любой и т.д. Я это рассматриваю со стороны более простой настройки у пользователя, который не сильно понимает что к чему.

[curlydevil]

Настроить VPN-подключение можно 1 раз, сохранить настройки в 1 файл, и дальше файлик этот раздавать кому надо. Кто надо только пароль с логином ведёт и попадёт куда надо.
Разумеется, если дело про винду.

Answer 7

[Александр Гре]

Использовать шифрованный туннель с помощью zebedee. На рабочем компе запускаете zebedee-сервис, а на клиентской машине запускаете консольный клиент zebedee с флешки с помощью батника.

Плюсы:
1. Шифруется канал между клиентской машиной и сервисом.
2. Сжимается трафик.
3. Защита от несанкционированных подключений с помощью ключей.
4. Возможность проброса нескольких портов через один туннель.

Comments

[asgard88]

Спасибо, посмотрю этот продукт.
Хотел приспособить Rohos Logon Key, он умеет создавать ключевые носители, которые проверяют валидность клиента, но к сожалению по RDP пробрасываются только смарткарты и токены, а для их использования на клиенте нужно ставить драйвера. Хотя можно попробовать rutoken flash. Она определяется без драйверов и на нее можно записать сертификат.

Вы навели меня на мысль

Answer 8

[foxnet]

На сколько известно, без центра сертификаций все равно ничего толкового не получится.
Если вам нужен очень очень надежное соединение без домена, то можно использовать IPSec. Это будет требовать настройки на каждом клиенте, но при этом весь трафик будет шифроваться. В этом случае также можно использовать сертификаты, но без центра сертификации и здесь не выйдет. Без центра сертификации IPSec канал можно устанавливать соединение по предварительному ключу.

Comments

[asgard88]

Какой формат имеет предварительный ключ? Не помню, winxp поддерживает ipseс нативно?

[foxnet]

тестовый. winxp поддерживает.

Answer 9

[kirion]

Если еще нужно корпоративное решение по аутентификации, то советую смотреть в сторону One-Time Password технологий. С ними никакой клиентской части не нужно, PKI со всеми вытекающими держать не нужно. Примеры OTP: RSA SecurID, Aladdin OTP, endeed ID.
Только не вешайте голый rdp наружу, он уязвим.

Comments

[Николай Турнавиотов]

При кривых руках уязвим.
Почему у меня 3389 открыт наружу чуть ли не 5 лет, и имея статический внешний ip, нормальное DNS имя, заблокированного стандартного администратора от входа по RDP, логин и 8 значный пароль меня до сих пор не проломали?
ах, да, WinXP, Win7, 2008R2. Все три со всеми доступными обновлениями.

[kirion]

Потому что MS12-020.

[kirion]

Николай, я так понял, что, как вы говорите, «наружу» у вас открыт RDP на ваш сервер terra.mulder.kiev.ua? Могу и ошибаться, много времени не тратил, но…

nmap -sS terra.mulder.kiev.ua
Starting Nmap 6.00 ( nmap.org ) at 2013-05-31 03:06 MSK
Nmap scan report for terra.mulder.kiev.ua (82.144.210.53)
Host is up (0.036s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
85/tcp filtered mit-ml-dev
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
3389/tcp filtered ms-wbt-server

Вы-то правильно приняли меры, чтобы наружу всем не торчало — фильтруете.
У вас даже web-сервер на 85-ом порту не всем доступен. Так все-таки открыт, либо МЭ блочит все подключения к RDP, кроме другого вашего статика, или адреса, которому вы открыли доступ по заявке с сайта? Это кстати подвожу к тому, что если ничего не ограничивает пулять в RDP-сервер извне, то любой скрипт-кидди сможет написать use auxiliary/dos/windows/rdp/ms12_020_maxchannelids где нужно. А завтра, что-нибудь еще. И тут вопрос не в скорости патчевания — они априори реактивны, сналача нашли уязвимость, потом появился патч. Можно ставить все патчи, но вот только они часто появляются после паблика эксплойта.

Атак-серфэйс в прошлом году был большой. Пример. Писались целые бот-сети на скан RDP и захват через него компов по ms12_020.

[Николай Турнавиотов]

kirion Всё бы ничего, но Раз Вы нашли мой домашний сервер — Вы бы могли и узнать, что на 85 порту живет демо приложение домашней бухгалтерии, которое я выставил в мир, а заодно то, что ночью по Киеву сервер обычно выключен, поэтому в момент сканирования Вами порты 85 и 3389 были «фильтрованы». Кстати интересный эффект
Остальные порты фильтруются провайдером. http, https и ssh порты на машине тоже, в общем, открыты, но простенький и уже давно EoL маршрутизатор ентерпрайз уровня Вам об этом не скажет.

Answer 10

[kirion]

Потому что MS12-020.

Answer 11

[asgard88]

Еще подскажите простой способ логирования рдп соединений, кто когда заходил с какого ip.

Comments

[Николай Турнавиотов]

Штатный аудит и штатные логи системы. аудит на события входа, помоему, но не факт что в аудите

Answer 12

[stepanovg]

Подскажите, разве самоподписаный сертификат не спасает в ситуации открытого порта 3389?
(на примере win2008r2/2012)

Answer 13

[Александр Владимирович]

WinSSHD
www.bitvise.com/ssh-server