Спрятать RDP сервер... а как?

Question

[Игорь Захаров]

Собственно, паранойя не знает пределов... Я попал под паранойю своего коллеги... Хочет следующее:

Имеется офис, в котором стоят голые моноблоки и модем. Соответственно нам нужно чтобы на самих офисных компах не было ничего, от слова совсем, кроме RDP клиента, который есть в любой Windows.

Где-то в определенном дата-центре в РФ стоит и вертится сервер терминалов, на который работники и подключаются.

Разумеется, подключаются они по IP, который принадлежит дата-центру, то есть IP палится, где сервер стоит - узнать не проблема.

Товарищ хочет реализовать следующее:
Арендовать сервер в Европе, который будет выполнять роль как-бы прокси или что-то вроде того для RDP сервера, который стоит в России. То есть я так понимаю, нам нужно как-то пробросить порты на сервере в Европе, чтобы подключаясь к нему, соединение RDP шло сразу в РФ.

То бишь таким образом мы спрячем реальный сервер.

Это вообще возможно? Как? 3proxy? ProxyMapper? Socks4/5 ???

P.S: В гугле нашелся сервис безопасного RDP, там предлагают арендовать такой сервис. Но арендовать мы не хочим, надо свое блин...

Comments

[be52]

vpn до сервера в европе а на нем впн до сервера терминалов в рф. элементарно
чекисты будут видеть что в офисе компы подключаются на адрес 192.168.3.2 и на роутере что он подключается к серверу в европе и у него есть маршрут к 192.168.3.2 через этот сервер
что происходит на сервере в европе им не видно

[Дмитрий Энтелис]

в рамках флуда - не забывайте что любую систему проще всего взломать терморектальным способом.

[Игорь Захаров]

hint000, ну, что делать. Мое дело солдатское. Можете раскрыть схему, очень любопытно, тем более что "защита" такого вида - это скорее для продвинутых юзеров, а не для шпионов))

[Kelv13]

У меня не стыкуются 2 вещи в этом вопросе - паранойя и сервер в датацентре РФ... Это, скорее, мазохизм...))

[Andrey Duplitsky]

Ты путаешь понятия. Прокси сервер - это кешируюший данные сервер, для того чтобы их потом быстрее отдавать. А тебе нужно тупо проброс портов и все (например 55555 на 3389) https://losst.ru/probros-portov-iptables-v-linux Для этого можно арендовать самый простой linux сервак. Но для пущей безопасности у данного узла не должны работать ping'и и как следствие не должна работать трассировка пакетов. p.s. Городить огород с vpn не вижу смысла - у rdp достаточно сильное шифрование, а если уж совсем захочется можно сделать tls с сертификатом ))

[Andrey Lutsenko]

Andrey Duplitsky, ну пробросите вы порты в линуксовую машину, стоящую в Европе. И потом что? Как вы с линукса потом пробросите rdp трафик дальше? Нужен vpn, кидающий rdp трафик через европу на RDP сервер.

[Andrey Duplitsky]

Andrey Lutsenko, Андрей какой VPN? Зачем???
Стоит задача - спрятать RDP. Так? То есть нам фактически нужно поменять ip адрес конечного сервера на любой другой. Для этого достаточно иметь сервак с пробросом порта по которому пойдет RDP трафик. Точка!
Единственный минус такого решения в том,что на конечном сервере в логах у всех подключающихся будет один и тот же ip адрес.

[Andrey Lutsenko]

Andrey Duplitsky, Андрей, мне кажется есть некое недопонимание. Проброс порта - это когда вы стучитесь на порт 1234 роутера, а роутер кидает трафик данного порта на порт 9876 на другую машину. dst-nat извне на комп внутри сети. А вот пустить трафик извне через некий узел на другой комп так же где-то в другом месте - это vpn или прокси.
Мне так кажется :)

Answer 1

[Valentin Barbolin]

Что тут сложного? Достаточно 2х правил в iptables. Минус конечно есть - не будет видно IP клиента, на терминальном сервере все будут сидеть с IP VPS сервера (WAN_IP).

RDP_IP='192.43.76.78'
WAN_IP='54.23.45.43'
WAN_INTERFACE=ens33
SRC_PORT_FORWARD=3389
DST_PORT_FORWARD=3389
echo 1 > /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A PREROUTING -i $WAN_INTERFACE -p tcp  --dport $SRC_PORT_FORWARD -j DNAT --to-destination $RDP_IP
sudo iptables -t nat -A POSTROUTING -d $RDP_IP -p tcp  --dport $DST_PORT_FORWARD -j SNAT --to-source $WAN_IP

Comments

[Alexey Dmitriev]

Не будут, если сервер в Европе будет промежуточным VPN сервером, к которому будет идти VPN из офиса, и от которого будет идти VPN к конечному серверу. Никакого NAT, только маршруты и в подключении RDP будет адрес сервера из серой подсети.

Answer 2

[АртемЪ]

Да, это возможно, и делается очень просто.
Арендуете промежуточный сервер, настраиваете на нем проброс портов на сервер терминалов и все.
В общем VDS за 200-300рублей в месяц, и три строчки в iptables для проброса портов на нем. Делается за 15минут.
Никаких прокси, VPN, и прочего городить не нужно совсем в данной ситуации.

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

Comments

[Игорь Захаров]

Так и сделал, взял VDS самый скромный за 220 руб. но встрял с настройкой haproxy пока ((. Вечер впереди, поковыряюсь.

[АртемЪ]

Никита Шинкевич, Какой haproxy? Зачем он там???

[turone]

Никита Шинкевич, просто проброс небезопасно даже если другой порт, все равно рано или поздно этот порт и ip просканят - тогда будут атаки на rdp, пускай и по прокинутым портам. Для действительного сокрытия и безопасности используйте порт кнокинг- в ответе ниже подробнее.

[Ivan_65536]

Можно то же самое, только на промежуточном сервере поставить routeros.
Ставится по инструкции, админится проще для не Linux специалистов.

[АртемЪ]

Ivan_65536, Так а что там админить? Один прокинутый порт? Один раз вбил правила за минуту, и забыл.

Answer 3

[Dmytro Yunh]

Ещё один вариант решения для грязных извращенцев может выглядеть так:
Арендуете "секретный" сервер
На нем поднимаете впн сервер
С терминальника в РФ цепляетесь к впн на "секретном" сервере
С рабочих мест также цепляетесь к впн на "секретном" сервере
К терминалке ходите по впн
Схема:
Терминалка в РФ >> впн на "секретном" сервере
Рабочее место >> впн на "секретном" сервере
Рабочее место >> впн >> Терминалка в РФ
Профит, входящие порты на терминалке в РФ закрыты напрочь, "секретный" сервер светит в мир только порт для впн.
З.Ы.
Данную схему можно упростить не используя клиентские впн подключения с рабочих мест:
На "секретном" сервере, пробросив входящий порт, сразу на интерфейс впн и подцепленный с терминалки IP адрес.
В данном случае, схема получается примерно такой:
Терминалка в РФ >> впн на "секретном" сервере
Рабочее место >> {любой_порт} на "секретном" сервере >> проброс порта к IP:3389 прицепленной по впн Терминалки в РФ >> Терминалка в РФ

Comments

[Игорь Захаров]

Хороший вариант, как раз от VPN отказываться очень не хочется. Сейчас пользуем L2TP.

Answer 4

[Игорь Захаров]

Друзья спасибо всем за советы и мнения! Очень рад что тема нашла отклик. Надеюсь все написанное пригодится не только мне.

Самостоятельно пришел к следующему решению:

Решил не возиться пока с Linux ввиду недостатка опыта работы с оным, а взял в Финляндии виртуалку с Windows Server 2016 за 3$ в мес. На арендованном забугорном сервере поднята SoftEther VPN Server с SecureNAT. Виртуальная машина с сервером терминалов, расположенная в РФ коннектится через L2TP VPN к этому серверу. А юзеры терминалов коннетятся к нему же таким же образом через L2TP VPN.

Получилась схема: Клиент RDP через VPN -> Сервер в Финляндии (SoftEtherVPN Server) > VPN до сервера в РФ.

Приятно порадовала скорость подключения, лагов нет, качество согласно индикатору RDP 8.1 хорошее.

Более того, покуда в свойствах VPN подключения российского сервера ставим галочку шлюза удаленной сети, удалось дать пользователям RDP сервера доступ в сеть через тот же Финский сервак. Тепеперь у наших RDP юзеров в офисе на сервере терминалов есть еще и интернет, который так же анонимизирован насколько возможно (финский IP).

Всем спасибо!

Comments

[Sukubus]

За 3$ в месяц наверное будет ограничение по трафику. Можно использовать CMAK для создания "коннектоидов". Он позволяет не использовать впн как шлюз по умолчанию и добавлять нужные маршруты пользователям. Я бы не издевался над пользователями и устанавливал впн с офисного маршрутизатора.

[Игорь Захаров]

Sukubus, разумеется, с маршрутизатора будет. Но и на компах автозапуск VPN не проблема...

Answer 5

[Владимир Куц]

Пробрасываете VPN до своего сервера терминалов - и вперед...
Можно пробросить VPN на сервере в Европе до сервера терминалов, и наружу прокинуть RDP

Comments

[Игорь Захаров]

Этот вариант в голову пришел сразу же, но... Хотелось бы сделать по другому, ибо в перспективе у нас будет на один, а два терминальных сервера в РФ, соответственно на сервере в Европе надо сделать так:
IP_ЗА_БУГРОМ:6088 > проброс на > IP_RDP_СЕРВЕРА_#1_В_РФ:3389
IP_ЗА_БУГРОМ:6099 > проброс на > IP_RDP_СЕРВЕРА_#2_В_РФ:3389

[pfg21]

Никита Шинкевич, конечно можно. всего лишь правильные записи в иптейблес. или правильно проброс портов.

[АртемЪ]

Владимир Куц, Городить VPN для этой задачи совершенно излишне, он вообще не нужен и не решает никаких задач.
Зачем делать VPN и пробрасывать порты, если можно просто пробросить порты?

[Владимир Куц]

АртемЪ, цель - "Спрятать RDP сервер". Через VPN мы скрываем все сервисы сервера наружу. Кроме VPN, подключаясь по которому - получаем требуемое - и RDP и что угодно еще.
Чтобы просто пробросить порт - нужно светить открытым RDP портом на терминальном сервере наружу.

[АртемЪ]

Владимир Куц,

Через VPN мы скрываем все сервисы сервера наружу.

Как?
VPN это виртуальная частная сеть. Она ничего не скрывает.

Все неиспользуемые сервисы блокируются файерволом.
Используемый сервис - RDP прячем за другим сервером.

Чтобы просто пробросить порт - нужно светить открытым RDP портом на терминальном сервере наружу.

Разумеется.
Во первых без этого никак не обойтись.
Во вторых что в этом такого?

VPN совершенно излишнее нагромождение в данном случае.
Его вполне уместно применять когда нужно создать изолированную сеть, или шифровать трафик в сети например.

[Владимир Куц]

АртемЪ,

Как?
VPN это виртуальная частная сеть. Она ничего не скрывает

Странно что вам приходится это разжевывать:
Внешний интерфейс терминального сервера - на неком адресе x.x.x.x
Вешаем на этом терминальном сервере RDP-сервер слушать на адрес 10.0.1.1. Прокидываем VPNом доступ в сеть 10.0.1.0/24 снаружи с нашего сервера в Нидерландах.
Снаружи адрес 10.0.1.1 не виден - виден только x.x.x.x через который мы соединяемся с сервера в Нидерландах.
RDP-сервер спрятан внутри сервера на 10.0.1.1 и не виден снаружи как следует из заголовка вопроса.

Во первых без этого никак не обойтись

Легко - выше я все описал

Answer 6

[Sukubus]

Я уже лет 5 занимаюсь подобной работой для бухгалтерий и могу сказать, что у вы много чего делаете не так
1) сервер в РФ сразу идёт лесом, т.к. любой обэп или отдел к сможет легко нагнуть вашего хостера. Сервер должен находиться в Европе. Причем некоторые типа хэцнера тоже сотрудничают с нашими и просто могут закрыть вам доступ.
2) скорее всего ваш сервер сидит в интернете что называется голой опой(порт rdp открыт). И даже если вы измените порт рдп, то он все равно просканиваться ботами и у вас постоянно будет идти подбор паролей. В качестве временного решения можно получить на работе постоянный ip у провайдера и настроить фаерволл сервера на подключение по rdp с этого ip. Но это отменит возможность подключения с разных мест... Best practics - это использование варитуальных машин на сервере, которые будут сидеть за виртуальным роутером. Далее делается шифрованный туннель между роутером в вашем офисе и виртуальным роутером и подключаются люди по рдп уже внутри этого туннеля по серым ip-адресам. Я предпочитаю использовать оборудование mikrotik. Виртуалки также удобны тем, что их легко можно бэкапить, а также переносить на другие сервера в случае расширения.

Comments

[Игорь Захаров]

Спасибо за мнение! Сейчас у нас схема такая:
Сервер RDP висит на аппаратном гипервизоре в виде VM, доступ к нему идет только если подключиться по L2TP VPN, соответственно все порты вовне закрыты наглухо, кроме VPN. Поэтому и думаю, что лучше попытаться построить схему: VPN до Сервер в Европе, а затем с сервера в Европе VPN до сервера в РФ...

[Sukubus]

Сервер в РФ как ни крути так себе идея...

[Игорь Захаров]

Sukubus, ну понятное дело, но пока так. Все со временем)

Answer 7

[Владимир]

берете виртуалку, ставите haproxy, вам нужен режим tcp

Comments

[Игорь Захаров]

Обычный VDS? Извините за тупость, я понимаю как с кретинами вроде меня тяжело общаться, когда нет компетенции в IT :(

[Игорь Захаров]

VDS с минимальным железом + CentOS 7 + haproxy если я правильно въехал в тему...

[Владимир]

да обычный vds/vps с линуксом - каким не особо важно убунту там или центос - берите то что лучше знакомо вам или другу/коллеге который может подсказать.
устанавливаете haproxy, настраиваете конфиг - вам нужно настроить секцию frontend - какой ип ипорт слушать, режимм работы - tcp, и имя бекенда куда будет перенаправлятся трафик.
потом настраиваете секцию backend там тоже режим tcp и указание ип и доп параметров куда направлять запросы, примеров и документации полно. пар frontend backend может быть много, в вашем случае две.

[Владимир]

Никита Шинкевич, да CentOS 7 + haproxy подойдет, по ресурсам - в вашем сценарии работы нагрузки на цпу или память не ожидается, только трафик будет.
1 ядро и 512мб памяти должно хватить.

[Игорь Захаров]

Владимир, спасибо за развернутый совет!

Answer 8

[Sanes]

Арендовать сервер в Европе, который будет выполнять роль как-бы прокси или что-то вроде того для RDP сервера, который стоит в России.

Больно не будет из-за задержек по сети?

Comments

[Игорь Захаров]

Вероятно будет, может тогда эта истерия пройдет. Попытка не пытка...

[Sanes]

Никита Шинкевич, Давно бы уже сделали. Делается за 10 мин.

Answer 9

[Alexey Dmitriev]

Сервер в Европе - промежуточный VPN сервер, к которому будет идти VPN из офиса (openvpn\wiregurd c каждого моноблока или общий VPN на выходе из офиса), от которого будет идти VPN к конечному серверу. Никакого NAT, только маршруты и в подключении RDP будет адрес сервера из серой подсети.
И да - будут подлагивания.

Comments

[SuiInc]

Пиши на почту [e-mail], в конце UA. За не большую плату организую все и выдам в аренду (в Хельсинках) сервер любой конфигурации, схема следующая: на ПК будут стоять linux (т.е. минус лицензии на windows уже) по рдп будут подключать к серваку, который будет виден только для этого офиса. Если нужно будет организую тревожную кнопку которая будет отрубать сервер там.

Answer 10

[Андрей Ермаченок]

Перед тем, как это мутить, нужно четко понимать, кто, что и для чего прячет, что вы или ваш товарищ с этого будете иметь и пр.
Учтите, с помощью термо-ректального дешифратора легко вскрываются все пароли, ищется и сервер в Европе, и Терминал в России, и даже находится убийца Кеннеди.

Comments

[Игорь Захаров]

ахаха)) ну, это человеки повернутые на шпиономании и иже с ним. Ничего незаконного в деятельности фирмы по продаже автозапчастей нет. Разве что уборщицу на склад по ТК не оформили.)

[Network173]

Если так тотально не доверять людям которые на тебя работают , то по-любому, кто-то на зло сделает что нить.
А по вопросу, есть такая мысль
Покупается статика, где сидят все userы, на роутер поднимается vpn, Сервак цепляется к локалке по vpn, когда нужно, все видя его как локальную тачку (а сам сервак хоть, где в деревне на 4ж модеме с нормальной скоростью)

[Андрей Ермаченок]

Network173, потому и спрашивал, от каких угроз нужно защититься? От инсайдеров, от ОБЭП, от конкурентов?
Всякие НаКоленкеСделанные решения создают впечатление защиты, а по факту оказываются дырявыми, как решето...

Answer 11

[ChMikhail]

Как вариант. Ограничить вход по ИП, поднять pritunl. Добавить его ИП в разрешенные, через pritunl делаем маршруты до rdp сервера.
На выходе можем контролировать пользователей vpn через веб интерфейс (если уволился удаляем и он не подключится больше). Доступ до сервера только через vpn шлюз, инет через обычный шлюз.

На сервер кроме как с подключеным vpn не попасть никак, так как стоит ограничение по ip, если есть ad то можно приобрести enterprise версию pritunl и сделать синхронизацию с ad. Не надо будет вручную пользователей создавать в pritunl.

Answer 12

[turone]

Я думаю что если параноить то по полной, точнее нужно обезопасить себя на всех участках соединения. Но и чтобы решение не слишком мудреное было и без глюков.
Предлагаю следующее:
на арендуемом сервере ставим mikrotik chr, или простой линух и port knocking там настраиваем по аналогии статьи про port knocking, далее пробрасываем там желательно нестандартный rdp порт на ip в вашем дата центре, а в сетевых настройках в дата центре указываем принимать соединения только с ip арендуемого сервера на выбранный нами порт и пробрасываем на наш RDP сервер.
конечная схема выглядит так:
Клиент из офиса стучится по port knocking на арендуемый сервер, ему открывается определенный порт для RDP, потом этот порт прокидывается на ваш сервер в дата центре, устанавливается соединение, клиент спокойно работает, а порт на арендуемом сервере закрывается (кроме установленных соединений).

Answer 13

[Александр Черных]

если захотят - найдут и впн не поможет
логичнее всего соединятся по rdp на сервер физически находящийся в др стране

Comments

[Игорь Захаров]

В перспективе перенести - да. А пока выкручиваться как могЁм...

Answer 14

[MadMarik]

У Гугла можно взять бесплатный впс. На firstvds 55 руб мес, 1 ядро, 512 мб

Answer 15

[Евгений]

Пошагово.
1. Любой vps в европе. Для теста бесплатные гугл или амазон.
2. Ставим любой линукс.
3. Ставим на него pritunl. Выбираем подсеть для впн. Важно: pritunl по умолчанию весь траффик от клиентов заворачивает в себя. Поэтому в pritunl меняем маску 0.0.0.0 на маску своей придуманной подсети. Разрешаем соединения между клиентами.
4. Делаем в притунле аккаунт для сервера. Прибиваем его IP гвоздями (например 10.0.10.250) Забираем конфиг .ovpn
5. На сервере ставим OpenVPN клиент как сервис. Заливаем конфиг. Правим сервис для запуска конфига по умолчанию.
6. Запускаем на сервере овпн. Проверяем, что и после перезагрузки овпн работает.
7. В притунле создаем клиентов и рассылаем им конфиги. И сообщаем, что рдп сервер теперь 10.0.10.250
Ну и как вишенка в датацентре где сервер запрещаем все входящие. Ну почти все.
Просто задача, как конь в вакуме.

Answer 16

[Andrey Duplitsky]

После настройки проброса портов на промежуточном серваке крайне рекомендую поставить на rdp сервер прогу ipban. Этим вы избавите себя от брут-форс атак (перебор логинов-паролей), коих, уж поверьте мне, будет очень много (но это работает только для серверов начиная с 2012).