05 Січ
Во время карантинов и локдаунов удаленная работа на терминальном сервере становится все популярнее день ото дня. Зачастую, доступ к серверу предоставляется в открытом виде, как есть. Это, конечно, очень удобно и позволяет работать из любой точки мира, без каких либо ухищрений. Но все ли так радужно, как кажется на первый взгляд при такой организации доступа. Если зайти на самом сервере в Просмотр событий → Журналы Windows → Безопасность, отфильтровать события Фильтр → Ключевые слова → Аудит отказа, то предстанет пред ясны очи преинтереснейшая картина, например такая:
Как видно, каждую секунду этот терминальный сервер пытаются поиметь в такой нехитрый способ, как «брутфорс» или «подбор паролей». Конечно, система отплевывается от домогателей, как может, но вскрыть такой сервер со свободным внешним доступом – дело времени и, учитывая современные технические возможности сетей и ботов, не такого уж и продолжительного.
VPN-ом ли единым?
Часто начинающие админы просто меняют порт для подключения по протоколу RDP на сервере или на маршрутизаторе со стандартного 3389, на какой-то другой. На пару недель этого может и хватит, но потом ваш новый порт все равно просканируют, уж можете и не сомневаться. А если уж ваш терминал-сервер засветился в сети со стандартным портом, то вычислят ваш новый порт куда быстрее.
Безусловно, максимально надежным было бы, закрыть серверу внешний доступ и подключаться к нему только через VPN. Да, все верно, для стационарного подключения между филиалами, офисами и т.п. – безусловно, постоянный VPN-канал по любой технлогии – и никаких проблем. А вот для “подвижного” состава домашних/мобильных пользователей есть некоторый треш, который просто сводит на нет все ваши потуги.
- Классическая свистопляска: пользователей много, ресурсы ограничены, сроки “на вчера”
- Уже сложившаяся годами система-структура, но с безопасностью таки ж надо что-то делать
- Некоторые провайдеры блокируют VPN PPTP/L2TP... На кой, спрашивается?
- На домашнем роутере закрыт проходищий VPN, пароль от роутера никто не знает...
- На личном компьютере пользователя просто дичь какая-то – ничего не настраивается
- Нет удаленного доступа к компу пользователя, переговоры с пользователем зашли в тупик
- Необходимлсть дополнительный клика для подключения VPN выводит пользователя в ступор
Весь этот кошмарный сон админа можно было бы еще продолжать, наверняка у каждого найдется что-то свое… Но работатьто надо, доступ нужен, VPN не светит, голый сервер выставлять тоже не кошерно… Блин, а делать то что???
Fail2ban для Mikrotik – в помошь
Под Linux есть интересный пакет для борьбы с частыми попытками неудачных авторизаций – fail2ban. В общих чертах принцип работы fail2ban выглядит таким образом. Программа с заданной регулярностью проверяет логи контролируемых служб на предмет неудачных авторизаций. При выявлении явно нездоровой ситуации сиситема блокирует доступ с подозрительных IP.
Конечно же, ваш роутер никоим образом не может знать о реальной ситуации с авторизацией за его пределами, однако по косвенным признакам он вполне может судить об успешности этого процесса. При успешной авторизации через любую службу сеанс подключения продолжится и все последующие пакеты будут иметь статус established. При попытке неавторизованного подключения сеанс будет сброшен и следующее подключение будет уже считаться новым со статусом пакетов new. Если число новых подключений, т.е. пакетов со статусом new от одного источника (одного IP адреса) за определенный промежуток времени превышает пороговое, можно считать это поводом для занесения источника в черный список.
Для того, чтобы можно было корректно отследить ситуацию по неуспешным RDP-авторизациям, прежде всего, необходимо на терминальном сервере разрешить подключения только от компьютеров на которых работает авторизация с проверкой на уровне сети. В таком случае проверка авторизации происходит отдельно еще до передачи данных самого удаленного стола – при неудачной авторизации сеанс прерывается. А иначе, проверка учетных данных ведется уже в рамках установленного RDP-сеанса и подбирать там пароль можно до бесконечности – никакой fail2ban тут не поможет.
Как это делает Микротик
В Mikrotik RouterOS есть правила по подсчету количества отправленных пакетов или бит за единицу времени, но нет никаких счетчиков новый сессий, потому придется мастерить из того, что есть в распоряжении.
Чтобы реализовать изложенные принципы в Microtik воспользуемся возможностью добавлять в списки адресов по заданным условиям. При регистрации проходящего пакета с внешнего интерфейса на порт 3389 его источник заносится в список для попытки №1 и находится там заданное время. Если регистрируется 2-й пакет пакет со статусом new и его источник находится в списке 1й попытке, то IP его источника заносится в список попыток №2 тоже на заданное время. И так столько раз, сколько мы попыток отводим на неудачные регистрации. На последнем этапе IP источника заносится в финальный список на срок “что бы мало не показалось”.
Сколько ж надо попыток и с каким интервалом?
Обычно на авторизацию дается 3…5 попыток. Особенность протокола RDP заключается в том, что после успешной авторизации создается новое подключение, в котором уже и ведется дальнейшая работа. Таким образом, за каждую успешную авторизацию будет засчитываться, как 2 попытки. Если клиент авторизуется только с 3-й попытки ему будет засчитано 4.
Сильно борзые боты тупо ломятся несколько раз в минуту – их выкупить вообще не проблема. Более осторожные пробуют пристроиться раз в 2…3 минуты. Еще более вальяжные (или сильно хитрые?) могут домогаться ваш сервер с интервалом до 10 минут – наверно, думают, что их не заметят. Ага, как же… Ну больше интервал делать, думаю, смысла нет, ибо эффективность работы такого бота уже сильно поддается сомнению. Да авторизованный клиент при неустойчивой связи тоже может попасть под раздачу.
Еще следует учесть такой момент, что на одним IP клиента может быт несколько компов. Тогда при одновременном подключении 3-х компов клиент может запросто попасть в бан за 6 новых сеансов за короткий промежуток.
Из личного опыта замечу, что оптимально 6 разрешенных попыток в интервале 10 минут – это обеспечит подключение до 3 авторизованных сеансов в течение 10 минут. Если подключается бОльшая сеть, то тут по-любому надо заносить ее внешний IP в список исключений (и не забыть, чтобы он был у них постоянным).
Еще один момент – неустойчивая связь со стороны клиента, например, мобильный интернет где-то в поле. В таком случае следует учесть его переподключения из-за обрывов связи. При заданном интервале 10 минут, и количеством ступеней проверки 6 получаем минимальное врем работы без переподключения 3 минуты.
И еще не все… Отдельный момент на случай, если по какой-то причине ваш терминальный сервер окажется недоступен или просто не будет отвечать на запросы. Фишка в том, что стандартный виндовый RDP-клиент, если не смог получить ответ, делает 5 (пять!) попыток с коротким интервалом. А это значит, что, если у вас сервер недоступен, то все, кто захочет к нему подключится, стройными рядами пойдут в бан! Не забывайте на это время отключать соответствующие правила проверки.
Итак… Ближе к делу. В Mikrotik правила можно создавать руцями, но гораздо удобнее просто без мороки внести все в Терминале: New Terminal – просто копируем команды целиком тут, и вставляем их там. У меня группа внешних интерфейсов названа WAN-list, у вас может быть по другому – делайте соответствующие коррекции.
Конечно, все правила для файрвола можно было бы свалить в одну кучу в Filter Rules, но это будет совсем не по фен-шую – посему правила для сбора списков и прочей маркировки прописываем в разделе Mangle: IP → Firewall → Mangle, а правила блокировки в разделе Raw: IP → Firewall → Raw. К тому же использование Raw позволяет сбивать нарушителей еще на подлете, не особо нагружая ресурсы маршрутизатора.
Правила маркировки выполняются по очереди все подряд. Чтобы отмежевать их от остальных правил и не лепить все в кучу, выделим все наши правила в отдельную цепочку jump-target=rdp-bot-detect. Для этого задаем все наши условия (строка 3) для входа в цепочку правил маркировки: для New-пакетов в цепочке Forward с интерфесов в группе WAN-list для протокола TCP и порта 8389 за исключением белого списка клиентов (и себя). Добавлять свой IP во все списки исключений – крайне важно, дабы не зарубить ненароком доступ самому себе. Не забываем давать информативные метки для комментария и префикса на случай записи в логи.
/ip firewall mangle
add action=jump chain=forward comment="RDP bot detect" connection-state=new \
dst-port=8389 in-interface-list=WAN-list jump-target=rdp-bot-detect protocol=tcp \
src-address-list=!clients-list log-prefix="-> RDP-bot detect -"
add action=add-src-to-address-list address-list=rdp-drop-list chain=rdp-bot-detect \
address-list-timeout=25w5d in-interface-list=WAN-list src-address-list=rdp_stage6 \
log-prefix="+ RDP-bot list -"
add action=add-src-to-address-list address-list=rdp_stage6 address-list-timeout=10m \
chain=rdp-bot-detect src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 address-list-timeout=10m \
chain=rdp-bot-detect src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 address-list-timeout=10m \
chain=rdp-bot-detect src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 address-list-timeout=10m \
chain=rdp-bot-detect src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 address-list-timeout=10m \
chain=rdp-bot-detect src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 address-list-timeout=10m \
chain=rdp-bot-detect
Внутри самой цепочки rdp-bot-detect уже необязательно проверять условия для пакетов, достаточно указать соответствие списку предыдущей стадии и само действие добавления в список следующей стадии. Да, все правила идут наоборот, все потому, что правила маркировки при прохождении по цепочке условий не останавливают на себе, а пробегают по всем правилам.
Правило для блокировки, как я писал выше прописываем в разделе Raw. При добавлений любых правил блокировки обязательно делаем все в SafeMode. Добавляем правило и сразу отключаем его, а после того, как убедимся, что правила маркировки работают правильно, можно включить и правила блокировки.
/ip firewall raw
add action=drop chain=prerouting comment="drop RDP list" in-interface-list=WAN-list \
src-address-list=rdp-drop-list
Ловим засранца «на живца»
Метод fail2ban неплохо отлавливает тех, кто уже подсел к вам на хвост. Однако, не лишним будет еще добавить работу на опережение, для отлова тех, кто еще не выкупил измененный порт для RDP-подключения, но потенциально им может стать.
Идея использовать “приманку” или, как ее еще называют HoneyPot, в борьбе с докучливой нечистью, наверное,, восходит к доисторическим временам. Принцип предельно прост – выставить на показ якобы уязвимые места, собрать и там уже прибить всех, кто на это поведется. Mikrotik позволяет сделать это без особого напряга.
В нашем случае, мы якобы оставляем “открытыми” на роутере популярные порты Telnet, FTP и RDP (21, 22, 23, 3389) и собираем адреса всех, кто туда попытается заломиться, в отдельный список, по которому и будем их потом нещадно банить. Главное, предварительно отключить соответствующие службы на маршрутизаторе или изменить их порт. Например, перевести RDP на подключение по 8389.
Все просто, на первый взгляд, но есть в этом деле чутка нюансов. Уже за первые сутки работы “приманки” в список Микротика набивается более 1000 адресов, а то и пару тысяч. Конечно, такой “улов” по началу не может не радовать начинающего админа, но есть тут обратная сторона медали…
Для понимания происходящего для начала обратим внимания на счетчики собирающего и блокирующего правил. Если сбросить эти счетчики и через сутки-двое сопоставить их показания, сколько было сработок блокирующего правила с объемом списка блокировки, то можно заметить, что самих блокировок было в несколько раз меньше, чем адресов. Это обусловлено тем, что многие обращения были просто разовым сканированием и в дальнейшем просто не повторяются. И что же тут плохого, казалось бы. А дело в том, что огромные списки адресов съедают и память и ресурсы процессора. Для слабенького роутера, наподобие HAP Lite, это может стать критично, да и мощной железяки, наверняка, и без этого есть, чем заняться.
На этот счет есть идея, запихивать с стоп-лист не все подряд адреса, а только те, что повторно попадутся “на живца”, ну скажем так, в течение суток. Как и в предыдущем скрипте, при первом обращении, заносим адрес супостата в промежуточный список на сутки, а при рецидиве, уже добавляем его на месяц в стоп-лист:
/ip firewall mangle
add action=jump chain=input connection-state=new dst-port=21,22,23,3389 \
in-interface-list=WAN-list jump-target=honeypot-detect protocol=tcp \
log-prefix="-> HoneyPot detect -" src-address-list=!white-list \
comment="add to HoneyPot list"
add action=add-src-to-address-list chain=honeypot-detect address-list=honeypot-drop-list \
address-list-timeout=4w2d src-address-list=honeypot-list-stage1
add action=add-src-to-address-list chain=honeypot-detect address-list=honeypot-list-stage1 \
address-list-timeout=1d
а потом баним все подключение по этому списку:
/ip firewall raw
add action=drop chain=prerouting comment="drop HoneyPot list" in-interface-list=WAN-list \
src-address-list=honeypot-drop-list
Практика показывает, что в финальном адрес-листе на длительную блокировку оседает не более 30…40 особо настойчивых претендентов, которые в дальнейшем как раз и могут стать источником регулярных поползновенией в вашу песочницу. А на остальных “залетных” не стОит и акцентировать внимание и ресурсы.
Еще раз напомню, не забывать о мерах собственной предосторожности не потерять связь с маршрутизатором: обязательно добавляем в исключения белый список со своим IP адресом – src-address-list=!white-list.
Также, как и в для первого метода, полезным будет периодически просматривать оба списка адресов, на предмет принадлежности их одной подсети. При наличии нескольких смежных адресов, полезно блокировать всю подсеть, если вы точно не ожидаете из нее никаких подключений.
