В связи с пандемией вируса covid-19 и всеобщим карантином во многих странах единственным выходом многих компаний, чтобы продолжать работу — удаленный доступ к рабочим местам через интернет. Есть много относительно безопасных методов для удаленной работы — но учитывая масштаб проблемы, необходим простой для любых пользователей метод удаленного подключения к офису и без необходимости дополнительных настроек, объяснений, утомительных консультаций и длинных инструкций. Таким методом есть любимый многими админами RDP (Remote Desktop Protocol). Подключение напрямую к рабочему месту по RDP идеально решает нашу задачу, кроме одной большой ложки дегтя — держать отрытым для интернета порт RDP очень небезопасно. Поэтому ниже предлагаю простой, но надежный метод защиты.
Так как часто я сталкиваюсь с небольшими организациями, где в качестве выхода в интернет используют устройства Mikrotik, то ниже будет показано, как это реализовать на микротике, но метод защиты Port Knocking легко реализуем и на других устройствах более высокого класса при аналогичных настройках входного маршрутизатора и firewall.
Коротко о Port Knocking. Идеальная внешняя защита сети подключенной к интернет — это когда все ресурсы и порты закрыты извне фаерволом. И хотя роутер с таким настроенным фаерволом никак не реагирует приходящие извне пакеты, он их прослушивает. Поэтому можно роутер настроить так, что при получении определенной (кодовой) последовательности сетевых пакетов на разные порты, он (роутер) для IP откуда пришли пакеты отрывает доступ к определенным ресурсам(портам, протоколам и пр).
Теперь к делу. Детального описания настройки фаервола на микротике делать не буду — в интернете для этого полно качественных источников. В идеале firewall блокирует все входящие пакеты, но
Разрешает входящий трафик от уже установленных(established, related) соединений.
Теперь настраиваем Port Knocking на Микротике:
Теперь подробнее:
первые два правила
запрещают входящие пакеты с IP адресов, которые попали в черный список при сканировании портов;
Третье правило:
добавляет ip в список хостов, которые сделали правильный первый стук на нужный порт (19000);
Следующие четыре правила:
создают порты ловушки для желающих просканировать ваши порты, и при обнаружении таких попыток заносят их ip в черный список на 60 минут, в течении которых первые два правила не дадут таким хостам возможности постучаться в правильные порты;
Следующее правило:
помещает ip в список разрешенных на 1 минуту (достаточно для установления соединения), так как сделан второй правильный стук в нужный порт(16000);
Следующая команда:
перемещает наши правила вверх по цепочки обработки фаерволом, так как скорее всего у нас уже будут настроены разные запрещающие правила, которые не дадут сработать нашим вновь созданным. Самое первое правило в микротике начинается с нуля, но у меня на устройстве ноль быль занят встроенным правилом и невозможно было переместить — я переместил на 1. Поэтому смотрим по нашим настройкам — куда можно переместить и указываем нужный номер.
Следующая настройка:
осуществляет проброс произвольно выбранного порта 33890 на обычный RDP порт 3389 и ip нужного нам компьютера или терминального сервера. Таких правил мы создаем для всех необходимых внутренних ресурсов, желательно выставляя нестандартные(и разные) внешние порты. Естественно, что ip внутренних ресурсов должны быть либо статичными либо закреплены на DHCP сервере.
Теперь наш микротик настроен и нам нужна простая для пользователя процедура подключения к нашему внутреннему RDP. Так как у нас это в основном Windows пользователи, то создаем простой bat файл и назовем его StartRDP.bat:
соответственно 1.htm содержит следующий код:
тут содержится две ссылки на мнимые картинки которые находятся по адресу my_router.sn.mynetname.net — этот адрес мы берем из системы DDNS микротика предварительно включив это в нашем микротике: заходим в меню IP->Cloud — ставим галочку DDNS Enabled, нажимаем Apply и копируем dns имя нашего роутера. Но это обязательно лишь когда внешний ip роутера динамический или используется конфигурация с несколькими провайдерами интернета.
Порт в первой ссылке :19000 соответствует первому порту по которому нужно стучаться, во второй соответственно второму. Между ссылками короткая инструкция, которая показывает, что делать если вдруг наше соединение из-за коротких неполадок в сети оборвалось — обновляем страницу, порт RDP для нас вновь открывается на 1 мин минуту и наш сеанс восстанавливается. Также текст между тегами img образует для браузера микрозадержку, которая снижает вероятность доставки первым пакета на второй порт (16000) — пока за две недели пользования (30 человек) таких случаев не было.
Далее идет файл 1.rdp, который мы можем настроить один для всех или отдельно для каждого пользователя (я так и сделал — легче потратить дополнительно 15 минут, чем несколько часов на консультации тех, кто не смог разобраться)
из интересных настроек тут use multimon:i:1 — это включает использование нескольких мониторов — некоторым это необходимо, а включить сами не додумаются.
connection type:i:6 и networkautodetect:i:0 — так интернет у большинства выше 10 мбит, то включаем тип соединения 6(локальная сеть 10Мбит и выше) и отключаем networkautodetect, так как если по умолчанию(auto), то даже редкая небольшая задержка в сети автоматически надолго устанавливает заниженную скорость для нашего сеанса, что может создавать заметные задержки в работе, особенно в графических программах.
disable wallpaper:i:1 — отключаем картинку рабочего стола
username:s:myuserlogin — логин пользователя указываем, так как значительная часть наших пользователей не знает своего логина
domain:s:mydomain — указываем домен или имя компьютера
Но если мы хотим упростить себе задачу по созданию процедуры подключения, то можем воспользоваться и PowerShell — StartRDP.ps1
Также немного про RDP клиент в Windows: MS прошла долгий путь оптимизации протокола и его серверной и клиентской части, реализовала много полезных фич — таких как работа с аппаратным 3D, оптимизация разрешения экрана под ваш монитор, мультиэкран и прочее. Но естественно, все реализовано в режиме обратной совместимости и если клиент Windows 7, а удаленный ПК Windows 10, то RDP работать будет используя протокол версии 7.0. Но благо можно обновлять версии RDP до более свежих версий — например можно повысить версию протокола с 7.0(Windows 7) до 8.1. Поэтому для удобства клиентов нужно максимально повысить версии серверной части, а также скинуть ссылки на обновление до новых версий клиентов протокола RDP.
В итоге мы имеем простую и относительно безопасную технологию удаленного подключения к рабочему ПК или терминальному серверу. Но для более безопасного подключения наш способ Port Knocking можно усложнять для атаки на несколько порядков, путем добавления портов для проверки — можно по той же логике добавить 3,4,5,6… порт и в таком случае прямое вторжение в вашу сеть будет почти неосуществимым.
Заготовки файлов для создания удаленного подключения к RDP.
Так как часто я сталкиваюсь с небольшими организациями, где в качестве выхода в интернет используют устройства Mikrotik, то ниже будет показано, как это реализовать на микротике, но метод защиты Port Knocking легко реализуем и на других устройствах более высокого класса при аналогичных настройках входного маршрутизатора и firewall.
Коротко о Port Knocking. Идеальная внешняя защита сети подключенной к интернет — это когда все ресурсы и порты закрыты извне фаерволом. И хотя роутер с таким настроенным фаерволом никак не реагирует приходящие извне пакеты, он их прослушивает. Поэтому можно роутер настроить так, что при получении определенной (кодовой) последовательности сетевых пакетов на разные порты, он (роутер) для IP откуда пришли пакеты отрывает доступ к определенным ресурсам(портам, протоколам и пр).
Теперь к делу. Детального описания настройки фаервола на микротике делать не буду — в интернете для этого полно качественных источников. В идеале firewall блокирует все входящие пакеты, но
/ip firewall filter
add action=accept chain=input comment="established and related accept" connection-state=established,relatedРазрешает входящий трафик от уже установленных(established, related) соединений.
Теперь настраиваем Port Knocking на Микротике:
/ip firewall filter
add action=drop chain=input dst-port=19000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=drop chain=input dst-port=16000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=add-src-to-address-list address-list="remote_port_1" address-list-timeout=1m chain=input dst-port=19000 protocol=tcp comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=19001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=18999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=16001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=15999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="allow_remote_users" address-list-timeout=1m chain=input dst-port=16000 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
move [/ip firewall filter find comment=RemoteRules] 1
/ip firewall nat
add action=dst-nat chain=dstnat comment="remote_rdp" src-address-list="allow_remote_users" dst-port=33890 in-interface-list=WAN protocol=tcp to-addresses=192.168.1.33 to-ports=3389Теперь подробнее:
первые два правила
/ip firewall filter
add action=drop chain=input dst-port=19000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=drop chain=input dst-port=16000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRulesзапрещают входящие пакеты с IP адресов, которые попали в черный список при сканировании портов;
Третье правило:
add action=add-src-to-address-list address-list="remote_port_1" address-list-timeout=1m chain=input dst-port=19000 protocol=tcp comment=RemoteRulesдобавляет ip в список хостов, которые сделали правильный первый стук на нужный порт (19000);
Следующие четыре правила:
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=19001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=18999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=16001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=15999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRulesсоздают порты ловушки для желающих просканировать ваши порты, и при обнаружении таких попыток заносят их ip в черный список на 60 минут, в течении которых первые два правила не дадут таким хостам возможности постучаться в правильные порты;
Следующее правило:
add action=add-src-to-address-list address-list="allow_remote_users" address-list-timeout=1m chain=input dst-port=16000 protocol=tcp src-address-list="remote_port_1" comment=RemoteRulesпомещает ip в список разрешенных на 1 минуту (достаточно для установления соединения), так как сделан второй правильный стук в нужный порт(16000);
Следующая команда:
move [/ip firewall filter find comment=RemoteRules] 1перемещает наши правила вверх по цепочки обработки фаерволом, так как скорее всего у нас уже будут настроены разные запрещающие правила, которые не дадут сработать нашим вновь созданным. Самое первое правило в микротике начинается с нуля, но у меня на устройстве ноль быль занят встроенным правилом и невозможно было переместить — я переместил на 1. Поэтому смотрим по нашим настройкам — куда можно переместить и указываем нужный номер.
Следующая настройка:
/ip firewall nat
add action=dst-nat chain=dstnat comment="remote_rdp_to_33" src-address-list="allow_remote_users" dst-port=33890 in-interface-list=WAN protocol=tcp to-addresses=192.168.1.33 to-ports=3389осуществляет проброс произвольно выбранного порта 33890 на обычный RDP порт 3389 и ip нужного нам компьютера или терминального сервера. Таких правил мы создаем для всех необходимых внутренних ресурсов, желательно выставляя нестандартные(и разные) внешние порты. Естественно, что ip внутренних ресурсов должны быть либо статичными либо закреплены на DHCP сервере.
Теперь наш микротик настроен и нам нужна простая для пользователя процедура подключения к нашему внутреннему RDP. Так как у нас это в основном Windows пользователи, то создаем простой bat файл и назовем его StartRDP.bat:
1.htm
1.rdpсоответственно 1.htm содержит следующий код:
<img src="http://my_router.sn.mynetname.net:19000/1.jpg">
нажмите обновить страницу для повторного захода по RDP
<img src="http://my_router.sn.mynetname.net:16000/2.jpg">тут содержится две ссылки на мнимые картинки которые находятся по адресу my_router.sn.mynetname.net — этот адрес мы берем из системы DDNS микротика предварительно включив это в нашем микротике: заходим в меню IP->Cloud — ставим галочку DDNS Enabled, нажимаем Apply и копируем dns имя нашего роутера. Но это обязательно лишь когда внешний ip роутера динамический или используется конфигурация с несколькими провайдерами интернета.
Порт в первой ссылке :19000 соответствует первому порту по которому нужно стучаться, во второй соответственно второму. Между ссылками короткая инструкция, которая показывает, что делать если вдруг наше соединение из-за коротких неполадок в сети оборвалось — обновляем страницу, порт RDP для нас вновь открывается на 1 мин минуту и наш сеанс восстанавливается. Также текст между тегами img образует для браузера микрозадержку, которая снижает вероятность доставки первым пакета на второй порт (16000) — пока за две недели пользования (30 человек) таких случаев не было.
Далее идет файл 1.rdp, который мы можем настроить один для всех или отдельно для каждого пользователя (я так и сделал — легче потратить дополнительно 15 минут, чем несколько часов на консультации тех, кто не смог разобраться)
screen mode id:i:2
use multimon:i:1
.....
connection type:i:6
networkautodetect:i:0
.....
disable wallpaper:i:1
.....
full address:s:my_router.sn.mynetname.net:33890
.....
username:s:myuserlogin
domain:s:mydomainиз интересных настроек тут use multimon:i:1 — это включает использование нескольких мониторов — некоторым это необходимо, а включить сами не додумаются.
connection type:i:6 и networkautodetect:i:0 — так интернет у большинства выше 10 мбит, то включаем тип соединения 6(локальная сеть 10Мбит и выше) и отключаем networkautodetect, так как если по умолчанию(auto), то даже редкая небольшая задержка в сети автоматически надолго устанавливает заниженную скорость для нашего сеанса, что может создавать заметные задержки в работе, особенно в графических программах.
disable wallpaper:i:1 — отключаем картинку рабочего стола
username:s:myuserlogin — логин пользователя указываем, так как значительная часть наших пользователей не знает своего логина
domain:s:mydomain — указываем домен или имя компьютера
Но если мы хотим упростить себе задачу по созданию процедуры подключения, то можем воспользоваться и PowerShell — StartRDP.ps1
Test-NetConnection -ComputerName my_router.sn.mynetname.net -Port 19000
Test-NetConnection -ComputerName my_router.sn.mynetname.net -Port 16000
mstsc /v:my_router.sn.mynetname.net:33890Также немного про RDP клиент в Windows: MS прошла долгий путь оптимизации протокола и его серверной и клиентской части, реализовала много полезных фич — таких как работа с аппаратным 3D, оптимизация разрешения экрана под ваш монитор, мультиэкран и прочее. Но естественно, все реализовано в режиме обратной совместимости и если клиент Windows 7, а удаленный ПК Windows 10, то RDP работать будет используя протокол версии 7.0. Но благо можно обновлять версии RDP до более свежих версий — например можно повысить версию протокола с 7.0(Windows 7) до 8.1. Поэтому для удобства клиентов нужно максимально повысить версии серверной части, а также скинуть ссылки на обновление до новых версий клиентов протокола RDP.
В итоге мы имеем простую и относительно безопасную технологию удаленного подключения к рабочему ПК или терминальному серверу. Но для более безопасного подключения наш способ Port Knocking можно усложнять для атаки на несколько порядков, путем добавления портов для проверки — можно по той же логике добавить 3,4,5,6… порт и в таком случае прямое вторжение в вашу сеть будет почти неосуществимым.
Заготовки файлов для создания удаленного подключения к RDP.
x893
А не проще один UDP 1194 открыть и всё через него?
AcidVenom
На какие только ухищрения не идет человек, чтоб не настраивать VPN в 2020.
aglgl
Так через vpn пойдет весь трафик, а нужен только рдп.
AcidVenom
Не используйте основной шлюз в удаленной сети.
aglgl
Сложно проследить сделают ли все пользователи это. В любом случае получается придется писать батник.
И что делать когда в сети не только win, а так же mac os, ios, android.
werter78
Выдавать маршруты локальным клиентам к ресурсами в удаленной сети по dhcp (option 121,249), напр.
AcidVenom
Как костыльное решение можно использовать отдельный бридж с включенный proxy-arp.
aglgl
Но в итоге получается легче как в статье описанно.
turone Автор
Вы openvpn имеете ввиду? Микротик нормально не стягивает по опенвпн, особенно если много подключений. Раньше я так и делал — ставил отдельно на виртуальной машине openvpn сервер, но у одной организации такой возможности не было, а было много стационарных ПК и пользователей с разным опытом работы, и чтобы упростить себе задачу попробовал метод описанный в статье и был очень удивлен, что почти не было вопросов и все ~30чел без каких либо проблем подключились и успешно работали. Поэтому и написал пост.
remzalp
Микротик умеет отлично pptp, l2tp, ipsec, настраивается всё в несколько тыков. Зачем openvpn?
turone Автор
1194 порт — человек вроде про openvpn спрашивал. Микротик — отличная вещь не спорю, но pptp, l2tp, ipsec — будет больше вопросов по подключению, как пользоваться и как шлюзы на клиенте настраивать и прочее. Вариант в посте мне очень по душе пришелся — скинул людям файлы подключения, короткую инструкцию и в ответ — тишина, только вижу, что подключаются и тихо работают.
perlestius
Как по мне, лучше уж PPTP/L2TP и перенос PBK-файла, можно через батник, чтобы по клику всё настраивалось.
Описанное в статье, конечно, интересно, но, ИМХО, выглядит как велосипед.
turone Автор
Я не отстаиваю, что какое либо решение лучше или хуже, просто в последних двух компаниях, где срочно нужна была удаленная работа и доступ именно к рабочим ПК и серверам, это решение было оптимальным. А например там, где в основном ноуты, которые можно взять домой, то лучшим является ваш вариант.
Dmitry_Shapiro
Считаю, что вы совершенно правы, не стоит домашние компы в сеть пускать.
А насколько безопасным вы считаете подключение по RDP через RD-Gateway с аутентификацией на Радиусе? Насколько я помню, там RDP поверх HTTP бегает.
turone Автор
Насколько помню поверх https. Там шифрованный трафик — это относительно безопасно — приблизительно на одном уровне с VPN связью, но как и VPN иногда всплывают уязвимости к некоторым атакам. Для пущей надежности можно вместе с Port Knocking использовать, но как по мне — то теряется тогда простота из-за появления дополнительной промежуточной точки отказа — RD Gateway, хотя безопасность немного выше, хотя задержки тоже на 1-2мс растут .
Dmitry_Shapiro
Да, вы правы, разуммется, поверх https. Спасибо за ваше мнение.
SinnerLike
Ещё бы ключ IPsec передавался с этим файлом…
Было лень искать как. Закинул этот файл в самораспаковывающийся архив с распаковкой в необходимый каталог и инструкцию куда ключ забивать.
Hardened
Текущая практика служб информационной безопасности в средних и крупных компания заключается в том, чтобы разрешать вход в корп сеть через VPN только с доверенных устройств. Например, корпоративных ноутбуков, которые могут быть не у всех сотрудников. Подключение домашнего ПК — это дыра, кто знает что на нем сидит и в какие ещё сети торчит.
Касательно SIP чем не устраивает проброс аудио и видео в RDP сессии с офисного ПК? Если там софтфон, а не аппарат, то проблем на первый взгляд не вижу. Но VoIP не мой конёк. Поделитесь
AcidVenom
Основные подсети закрывается файерволом от туннелей VPN, оставляются только нужные секторы. Не обязательно давать доступ во всю сеть.
Hardened
Скажем так — на сети для офисных ПК в нормальной организации правила навешены. Как и на остальные сети. МСЭ тут без разницы, физически вы за компом сидите или через VPN. А вот дырки во вне в случае с VPN потенциально появляются, причем пропорционально числу сотрудников. И если они из дома сидят это еще пол беды. А если из общественных сетей?
AcidVenom
Мы переходим в плоскость гипотетических «а если». Открытый порт на белом IP куда страшнее, потому что он там и останется годами в отличие от ноутбука, который через 20 минут исчезнет в неизвестном направлении.
Hardened
Только на домашнем ПК уже может сидеть зараза, а ноутбук не понятно в каких wifi сетях бывает.
Модели угроз на гипотетических «если» и строятся.
Для VPN нужен один порт. Для предложенного автором в статье варианта — два. Разница не драматическая.
trnc
Ваш вариант имеет право на жизнь для RDP. А что если нужен SIP? SIP сервер находится в локальной сети и внешего IP не имеет. Попробуйте в случае SIP настроить через проброс. Вот в этих случаях и выручает L2TP, PPTP. Подключился к шлюзу по VPN на котором уже включен SIP ALG и проблема решена. Не приходится лишний раз заморачиваться с настройкой сервера и доп. опциями типо NAT aware, не приходится думать и гадать: «а на всех ли железках по пути следования пакетов от дома работника до сервера будет включен SIP ALG?» Если возможность есть, то лучше использовать VPN, тем более на микротике для этого есть все, как минимум в случае L2TP и PPTP.
turone Автор
В той компании где первоначально я настроил через Port Knocking там стоят мощные стационарные ПК для работы с CAD/CAM приложениями, с кучей специфичных настроек и настроенной инфраструктурой. Задача была массово настроить каждому пользователю доступ к его ПК, что было успешно сделано за короткое время. А для SIP и некоторых других специфичных задач либо для ноутов — однозначно L2TP, PPTP, IPSEC.
werter78
Затем, что во вне может быть открыт только 80\TCP и 443\TCP. И перевесив OVPN-сервер на эти порты можно решить эту проблему. А если прикрутить обфускацию овпн — получится оч вкусно v2ray.com/en/index.html, pluggabletransports.info/implement/openvpn/
Повторить что-то подобное с pptp, l2tp, ipsec у вас не получится.
remzalp
Учитывая, что человек на входе в сеть настраивает стук по портам, мне кажется, ему прав хватит и остальное разрешить.
be52
Опенвпн не надо поднимать на микротике. Поднимайте его прямо на сервере терминалов или рабочей станции(без маршрутизации и маскарада, просто туннель от хоста до хоста с пробросом порта на роутере).
Если сложно то поднимайте wireguard, там даже мартышка осилит.
turone Автор
Во второй компании, где вариант с port knocking реализовал, так и было до этого. Но попросили вариант попроще для RDP, я им настроил, скинул файлы и пока (3 дня) там все (~10 чел.) довольны.