Comments 34
Обычные сертификаты все еще работают и они все еще гораздо лучше и надежнее всех этих странных велосипедов.
Есть большой минус у "обычных сертификатов" - уровень пользователей должен быть соответсвующим.
Зачем? Выдать настроенный ноут и все из коробки само будет работать.
Боже, да вам надо дать ноутбук с линуксом и понаблюдать как вы будете настраивать из коробки.
Линукс ноуты + Вин сервера по RDP это странная конфигурация. Но в общем почему бы и нет? Когда такую конфигурацию принимали за стандарт отдел занимающийся наливкой ноутов и их выдачей пользователям должен был озаботится стандартными конфигурациями, так чтобы все работало из коробки само. Можно считать что эта проблема у них решена.
На более типовой конфигурации Вин ноут + Вин сервер по RDP все настраивается легко и без страданий.
Вы рассматриваете какой то корпоратив корпоративный, где ноуты, как горячие пирожки выдают настроенные с блэкджэком и куртизанками. В реальности есть куча ситуаций, когда люди используют личные устройства (домашний ноут с WinXP живым на борту, макбук на который свежий RDP клиент просто не встаёт), а им работать надо. Удаленно подключиться, сделать бухгалтерские документы и 100500 ещё других дел. Да, это не по RFC и не суперсекьюрно (если трафик слушать будут и анализировать), но для компании из 10-20 человек это не важно. Важна доступнусть с любого места: в случае моего велосипеда ниже не нужно ничего пользователю настраивать - имя пользователя и пароль они сами знают, а адрес сервера и ссылку для открытия порта можно хоть продиктовать, хоть написать...любой RDP клиент подойдёт. Страданий нет - полчаса на сервере и 2 минуты на клиенте любого уровня отбитости.
Я рассматриваю любую контору которая хотя бы немного дорожит своими данными и хотя бы немного заботится о безопасности.
Наливать единичные вин ноуты с сертификатами в ручном режиме справится типичный аникейшик. Тот же кто принтеры чинит. Один раз все сделать и написать понятную ему инструкцию может любая внешняя консалтерская контора. И даже возьмет за это не очень много денег.
Наливать десятки-сотни вин ноутов с сертификатами сможет любой нормальный вин админ. Он при таком парке технике все равно нужен.
Для исключительных случаев когда кому-то с правами администратора надо срочно залогиниться с чужого железа ему можно держать сертификат файликом где-то. В виде исключения (небезопасно но в общем бывает). Можно считать что этот человек справится. Если не справится значит ему не надо. Пусть ждёт пока новый рабочий ноут до него доедет.
А вот контора позволяющая коннектится к своим серверам с домашних компов с WinXP может смело ставить пароль 123456 на сервера. Хуже все равно не будет.
Нет смыла делать плохой велосипед, когда есть хорошо работающий промышленный стандарт. Этот стандарт хорошо адаптируется для любых нужных вам масштабов. И он гарантирует защиту от большого числа векторов атаки. В отличии от любого вашего велосипеда.
Мне искренне жаль, что вы стали жертвой маркетологов. Распишете, пожалуста, на пальцах чем подход "Подключиться с сретификатом под Win11" особо "безопасней и лучше" варианта, описанного мной ниже (открытие порта через веб и подключение с самоподписанным сертификатом)?
Я про обычный сертификат. Его невозможно подобрать, злоумышленнику можно разрешить слушать весь трафик, если немного озаботится то этот сертификат даже украсть с клиента невозможно. Максимально возможная надежность, которую человечество придумало. Максимальные гарантии и при этом удобно пользоваться.
А вы вместо этого предлагаете какой-то костыль который не защищает ни от чего. Защиту от скрипт кидди мы же не считаем важной?
При чем тут веб я не понял. Обычный сертификат и обычный ключ. Если нужна повышенная безопасность, то ключ неэкспортируемый на специальной железке у клиента.
Да, а от прилетевшего трафика по попытке перебора паролей сертификаты не спасают и как итог в вашей схеме - тормоза в сессиях у удалёнщиков либо вовсе отказ в обслуживании. В вашу связку нужно одно звено минимум добавить, которое будет "отсекать плохих", если уж корпоративно так всё. Сертификаты вы тоже попробуйте настроить в односерверной конфигурации - то ещё развлечение. Велосипеды могут сколько угодно быть странными и небезопасными, но они работают и на них ездят иначе они были бы не востребованы.
Вы уже считали сколько ддоса такого надо чтобы затормозить типичный сервер? Уже делали простейшую защиту от него? Ну там rps limiter какой по вкусу.
Велосипеды работают ровно до тех пока не сломаются. Стандартные решения работают всегда. Любой новый человек в стандартном решении разберется путём Гугла ключевых слов. А вот в велосипеде вероятно даже разбираться не станет, а просто его выключит или переделает на что-то.
Вы как будто никогда не закапывали велосипеды в пользу стандартных подходов. Это много боли и непонятных проблем.
Насколько помню, нативно авторизации по клиентским сертификатам нет в rdp, даже с rds gateway. Есть разве что смарткарты, а нативно реализована валидация серта сервера. Можно изобразить, если использовать html5 клиенты например. Если что-то изменилось, был бы признателен за ссылку на документацию
Энтерпрайз без ключей в 2022 году? Зря вы считаете что МС вообще ничего в безопасности не понимает.
по первой ссылке - это смарткарта. работа через смарткарты реализована давно, тут вопросов нет.
по второй ссылке - описана валидация серта сервера, тоже вопросов нет.
Using certificates for authentication prevents possible man-in-the-middle attacks. When a communication channel is set up between the client and the server, the authority that generates the certificates vouches that the server is authentic. As long as the client trusts the server it is communicating with, the data being sent to and from the server is considered secure
>Зря вы считаете что МС вообще ничего в безопасности не понимает.
не надо мне приписывать то, чего я не говорил :)
не надо мне приписывать то, чего я не говорил :)
Считать что логин по сертификатам не работает, это оно и есть.
Давайте вот так:
RDP Sign-in with Windows Hello for Business Certificate Authentication
After adding the certificate using an approach from any of the previous sections, you should be able to RDP to any Windows device or server in the same Forest as the user’s on-premises Active Directory account, provided the PKI certificate chain for the issuing certificate authority is deployed to that target server.
Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid Azure Active Directory-Joined client where the authentication certificate has been deployed.
Attempt an RDP session to a target server.
Use the certificate credential protected by your Windows Hello for Business gesture.
c натяжкой (требуется win hello, azure ad и подключение к нему клиентских устройств) но считается, спасибо :) попозже почитаю внимательнее, что там используется "под капотом", мб просто выдаёт керберос-токен и дальше прозрачный rdp (но доступ к кейтабам проверяется winhello), или ещё что.
заметьте, я не не был уверен в правоте - поскольку несколько лет не занимался безопасностью терминальных ферм и серверов:)
PS судя по всему, там да, под капотом эмуляция смарт-карты - https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop?source=recommendations ну и помимо сертов, можно использовать и биометрию
Я делал велосипед чуть проще.. Поднял apache веб сервер с PHP на нестандартном 32888, запилил скрип аля "если get['abrvalg']==777 определяй ip клиента, добавляй в файл ips.txt и запускай скрипт powershell", а скрипт powershellа просто читал ips.txt и добавлял в нужное правило. Пользователь если не может достучаться до сервера просто проходит по ссылке http://123.456.78.9:32888/noconf.php?abrvalg=777 после чего сразу логинится. Из подводных камней - только настройка прав вебсервера.
А в чем проблема просто банить тех, кто пароли подбирает? 5 неверных попыток - и до свидания. Ну и нормальные пароли, закрытые порты кроме нужных и обновления вовремя. У меня пока ни один из серверов не сломали.
Просто заставить пользователя запускать что-то, кроме rdp-клиента - без шансов. Даже впн не всегда могут. Молчу уж про самописные костыли.
И юзеры сами себя блочат и добавляют головной боли админам.
различные fail2ban всегда требуют больше ресурсов, т.к. парсинг логов у сервера где мало ресурсов и много попыток подобрать пароль особенно ботнетом, модет нехило нагрузить сервак.
всегда есть вероятность что пользователь установил пароль который отвечает требованиям сложности, но есть во всех словарях, пример - Qwerty123!. Тогда первая попытка брутфорса может быть удачной.
Ну да, приходится иногда юзеров их бана вынимать. Впрочем, я таких в белый список добавляю, если часто косячат.
У сервера терминалов ресурсов обычно достаточно для того, чтобы от ботов отбиваться.
Нельзя доверять пользователям ставить пароль. 16 случайных символов вполне устойчивы. Ну и не только ведь пароль подобрать надо, но и логин. Который тоже можно pwgen'ом сгенерить. Ну или как минимум - никаких стандартных админов и главбухов.
Ссылку открыть через браузер перед RDP - очень сложно? 5 неверных попыток и до свидания - куда до свидания? На уровне фаервола вы забанить сможете только через самописные костыли. При работе ботнета подбор производится с сотен ip и в большинстве случаев быстрее происходит замедление аутентификации лигитимных подключений или таймауты AD, в случае разгильдяйства откровенного могут и пароль подобрать. То, что у вас ни один из серверов - ошибка выжившего, не более.
Fail2ban + rds gateway + требования к паролям (включая проверку по словарям, благо такие решения есть) кмк более юзер-френдли. Ну и если что-то кликать населению перед началом работы - то уж лучше впн-клиент, это как-то поприятнее. Хотя бы ssh в туннельном режиме:)
Но ваш способ тоже интересный, спасибо что поделились:)
Port Knocking, использую его на RouterOS, <…> для Windows не существует подобного штатного функционала
насколько я помню, на RouterOS он такой же «штатный», как на Windows — можно заскриптовать штатными средствами
Прочитал ваш скрипт:
послушать первый порт и запомнить ip первого подключившегося клиента
послушать второй порт и запомнить ip первого подключившегося клиента
если эти ip совпадают — пустить по rdp
А теперь вернёмся к вводным — вас регулярно сканируют: если очерёдность сканирования совпадает — ваша поделка открывает доступ. (вы настроили как в примере: 65000, 9999; сканер идёт от бОльших к меньшим и благополучно стучится сначала в 65000, потом в 9999, а потом попадает на открытый rdp 3389).
Второй момент — если легитимный пользователь стучится во время сканирования, он с большой вероятностью не достучится.
Именно поэтому Port Knocking реализуется совсем иначе, через аналитику firewall’а и бан тех ip, с которых после обращения к первому порту полезли не на второй.
Где Вы увидели в тексте утверждение что Port Knocking на RouterOS "штатный"? Было только утверждение что я его использую на RouterOS.
Большинство сканеров не сканируют все порты, это долго. Сканируют обычно по возрастанию. Проверял Nmap-м, OpenVas-м, Nessus-м. Можно по желанию слушать 3 порта, например 65000, 9999, 65003 и это уменьшит вероятность, попасть сканеру в правило. Если уж совсем заморочится, то можно миксовать TCP с UDP и ICMP, да еще и с разными длинами пакетов.
Вероятность что именно в тот самый момент когда пользователь хочет подключиться, сканируют именно один из двух портов, ничтожно мала. В крайнем случае пользователь еще раз постучится. На момент публикации статьи PortKnocer работал на нескольких серверах на протяжении 3-х недель и не возникло проблем.
Банить те IP которые постучались на первый, но не постучались на второй, так можно и своих забанить, вдруг пользователь прервал работу Knocker-а. Но идея имеет право на жизнь, обдумаю ее детальней.
За Port-Knocker у меня остались fail2ban-ы, НО т.к. событий в журнале Security стало на порядок меньше, он работает быстрее и меньше нагружает систему. Более точная информация: а) Cyberarms intrusion detection, до PortKnocking - cpu 5%, ram - 21mb. б) PortKnocking - cpu 0%, ram - 3mb. в) Cyberarms intrusion detection, после PortKnocking - cpu < 1%, ram - 21mb.
Развитие идеи port knocking - это single packet authorization, когда сеть открывается только после стука по нескольким портам одним пакетом, причём последовательность портов уникальна и каждый раз генерируется с помощью HOTP, например, 23076 64251 33198 50071. Это не заменяет аутентификации по сертификатам, но решает проблему сканирования. (источник).
Тоже раньше обдумывал различные способы авторизации пользователя на открытом RDP сервере, но потом плюнул, настроил на роутере (кинетик) Wireguard VPN и горя не знаю. Удивлялся масштабам хакерских атак - открытый в инет RDP долбят тысячи раз в секунду. Один раз удалось как-то продолбить и зашифровали все файлы на сервере шифровальщиком )))
В телегу приходит сообщение, что IP добавлен, а в правиле брандмауэра новый IP не появляется.
На сколько я смог разобраться, проблема в этом месте:
$CurrentIPs += $IP2
После этого у меня переменная CurrentIPs имеет вид 1.1.1.12.2.2.2 (айпишники склеиваются)
Меняю эту строчку на $CurrentIPs += ", $IP2" и CurrentIPs имеет вид 1.1.1.1, 2.2.2.2.
И если вручную выполнить следующую строчку:
Set-NetFirewallRule -DisplayName "!RDP-for-port-knocking" -RemoteAddress 1.1.1.1, 2.2.2.2
то правило брандмауэра изменяется как и должно, но вот автоматом всё равно не работает...(
Проблема проявляется только когда указан один адрес SafeIPs.
Если указано 2 и более, то всё ок.
Так что указывайте что-то вроде "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" (именно без пробелов) и всё будет ок.
Ещё добавил правила для UDP по аналогии, рядом с TCP-шными (для RDP порта).
И утилита paping.exe у меня не запускается ни на одной машине, так что нашел другую утилиту. Вот батник:
PortQry.exe -n 1.1.1.1 -o port1,port2 -nr
start mstsc /v:1.1.1.1:RDPportАвтору спасибо за инструмент. Пару дней поигрался, всё ок.
Сохранил себе в архив на будущее.
Port Knocking для Windows