Защита RDP от перебора паролей при помощи оборудования Mikrotik

  • Автор:

rdp-bruteforce-protection-mikrotik-000.pngАтака с полным перебором паролей (брутфорс) - одна из наиболее часто встречающихся угроз в современном интернете. Она базируется не на уязвимостях ПО, а на нарушении политики паролей, что иногда оказывается гораздо более продуктивным. Пользователи не любят сложных паролей и даже когда есть явные требования по сложности стремятся использовать более простые комбинации, либо словарные слова. Многие также используют одну пару логин - пароль для всех учетных записей и при компрометации одной из них эти данные могут попасть в руки злоумышленников. Одним из наиболее часто атакуемых сервисов является RDP и сегодня мы посмотрим, как можно его защитить.

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

В среде администраторов бытует мнение, что выставлять RDP без VPN "наружу" нельзя. На сегодняшний день это не так, современные реализации протокола используют даже по умолчанию SSL-защиту и проверку подлинности на уровне сети (NLA), если использовать поддерживаемые версии ОС и своевременно устанавливать обновления, то RDP будет достаточно надежным для использования без дополнительной защиты.

Но у него, как и у многих иных сервисов, есть слабое место - пароли, а усугубляется ситуация отсутствием штатных средств защиты от их перебора. Существуют решения, которые устанавливаются прямо на RDP-сервер и добавляют необходимую функциональность, но мы пойдем другим путем и будем использовать более подходящее для этого средство - межсетевой экран.

На первый взгляд задача труднорешаемая. Каким образом роутер сможет определить ведется перебор паролей, либо просто подключаются и работают пользователи, ведь через него проходит только транзитный трафик к RDP-серверу, при этом сама сессия шифруется. Но не будем делать скоропалительных выводов. Существует специальный механизм Connection Tracking, который определяет состояние соединения и принадлежащих ему пакетов, всего таких состояний четыре:

  • NEW - новый пакет, не принадлежащий ни одному соединению
  • ESTABLISHED - пакет, принадлежащий уже установленному соединению
  • RELATED - пакет нового соединения, порождённого уже существующим соединением, многие протоколы, например, FTP открывают дополнительные соединения для передачи данных
  • INVALID - все что не относится к первым трем состояниям, это пакет, не принадлежащий ни одному соединению и не являющийся первым пакетом нового соединения.

Исходя из вышесказанного можно прийти к следующему выводу: у работающего RDP-клиента состояние пакетов будет ESTABLISHED, а NEW будет появляться только в начале соединения, если же мы постоянно получаем NEW от клиента - то с большой долей вероятности он занимается перебором паролей. Давайте рассмотрим, как происходит RDP-соединение, схема предельно упрощенная, на уровне минимально необходимом для понимания происходящих процессов.

Современные решения предусматривают проверку подлинности на уровне сети (NLA) и клиент сначала должен пройти процесс аутентификации, прежде чем он сможет подключиться к компьютеру, RDP-сессия при этом не создается. Пакет с запросом аутентификации будет иметь состояние NEW, при неудачной аутентификации каждый новый запрос будет создавать еще один пакет с состоянием NEW.

При успешном вводе учетных данных клиент создаст новое RDP-соединение, первый пакет этого соединения также будет иметь состояние NEW, а все последующие ESTABLISHED.

rdp-bruteforce-protection-mikrotik-001.png

Таким образом успешное RDP соединение предусматривает получение двух пакетов с состоянием NEW, каждая попытка аутентификации еще одного. Это дает возможность достаточно легко отличать легальных пользователей от ботов и злоумышленников. Фактически если в течении короткого промежутка времени мы получили более 2 пакетов в состоянии NEW - то это однозначно свидетельствует, что на той стороне ошиблись при вводе учетных данных.

Так как человеку свойственно ошибаться, то оставим легальным пользователям право на ошибку: три неверных попытки и одна правильная - итого пять пакетов NEW в течении короткого времени, злоумышленник за это время успеет пять раз попробовать ввести учетные данные. Какой промежуток времени взять? Одной-двух минут в целом будет достаточно, даже при ручных попытках ввода. Но не следует устанавливать слишком большой интервал, так как пользователь может случайно отключиться - подключиться снова и попасть под блокировку. Брутфорсом же занимаются преимущественно боты и даже минуты им с лихвой хватит чтобы выйти за пределы лимитов.

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

Для этой цели мы будем использовать добавление адреса-источника в Address List и таблицу Mangle. Почему именно Mangle, ведь действие add src to address list доступно и в Filter? Один из основных принципов построения брандмауэра - это читабельность правил конфигурации. В Filter мы ожидаем увидеть действия, производимые с пакетами на основании тех или иных условий. А вот Mangle предназначена для маркировки пакетов и соединений, и, хотя, добавление в списки не совсем маркировка, логически более верным будет разместить эти правила здесь.

Итак, переходим в IP - Firewall - Mangle и создаем следующее новое правило: Chain - forward, Protocol - tcp, Dst. Port - 3389, Connection State - new.

rdp-bruteforce-protection-mikrotik-002.pngНа закладке Action добавляем действие add src to address list и укажем имя списка rdp_stage1 и время действия записи - 1 минута.

rdp-bruteforce-protection-mikrotik-003.png

В терминале можете выполнить:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_stage1 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp

Что мы сейчас сделали? Для каждого транзитного пакета на порт 3389 с состоянием NEW мы помещаем его адрес-источник в список rdp_stage1 на 1 минуту. Получив еще один такой пакет, мы должны проверить, нет ли его уже в указанном списке, а если есть, то поместить в список rdp_stage2, для этого создаем еще одно аналогичное правило, но с дополнительным условием, на закладке Advanced указываем Src. Address List - rdp_stage1, а на закладке Action в качестве списка указываем rdp_stage2.

rdp-bruteforce-protection-mikrotik-004.png

Это же действие в терминале:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_stage2 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage1

Затем создаем еще одно правило, где указываем Src. Address List - rdp_stage2, а список на закладке Action - rdp_stage3, и еще два, пока не заполним список rdp_stage5.

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_stage3 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage4 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage5 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage4

И, наконец, последнее правило, с условием Src. Address List - rdp_stage5 и действием Action - add src to address list, Address List - rdp_drop и таймаутом, скажем, 30 минут.

rdp-bruteforce-protection-mikrotik-005.pngИли в терминале:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_drop address-list-timeout=30m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage5

Как это все работает? Адрес-источник первого NEW пакета мы помещаем в список rdp_stage1 на одну минуту, если с этого адреса снова придет новый пакет, то адрес источник попадет в список rdp_stage2, тоже на минуту, если в течении этой минуты снова придет новый пакет - то он будет помещен в rdp_stage3 и т.д. Шестой пакет с состоянием NEW попадет в список rdp_drop на полчаса. Время блокировки вы можете выбирать самостоятельно, в зависимости от текущих условий, но следует избегать больших значений, если пользователь таки попадет под блокировку, а администратор случайно не на связи, то полчаса гораздо лучше, чем сутки.

Следующий момент, после того как вы добавили все эти правила, их следует разместить в обратном порядке, от последнего к первому. Почему? Потому что действие add src to address list не является терминальным и пакет продолжает свое движение по цепочке. И если правила оставить в том порядке, в котором они был добавлены то получится следующее: первое правило добавит новый пакет в список rdp_stage1, второе проверит, нет ли его в этом списке, а оно там есть, и добавит в rdp_stage2. Далее вы поняли, адрес источник с первого же пакета добавится последовательно во все списки включая rdp_drop. Поэтому проверять списки надо в обратном порядке, от rdp_stage5 к rdp_stage1.

rdp-bruteforce-protection-mikrotik-006.pngЕсли вы работаете в терминале, то правильная последовательность действий будет выглядеть так:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_drop address-list-timeout=30m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp

Теперь проверим работу наших правил, выполним подключение к RDP одновременно контролируя IP - Firewall - Address Lists. Если все прошло нормально, то мы увидим наш адрес-источник в списках rdp_stage1 и rdp_stage2.

rdp-bruteforce-protection-mikrotik-007.png

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

rdp-bruteforce-protection-mikrotik-008.pngКак видим, практика полностью совпадает с теорией, следовательно, можно переходить к блокировкам, не опасаясь, что пострадают легальные пользователи. Блокировать мы будем в таблице Raw, почему? Raw содержит "сырые" данные о пакетах, до того, как они будут переданы Connection Tracking, а так как определение состояния пакета достаточно ресурсозатратная операция, то отсекая лишний трафик в Raw мы снижаем нагрузку на процессор роутера, что важно в случае достаточно большого списка.

Переходим в IP - Firewall - Raw и создаем новое правило: Chain - prerouting, Protocol -tcp, Port - 3389.

rdp-bruteforce-protection-mikrotik-009.pngНа закладе Advanced указываем Src. Address List - rdp_drop:

rdp-bruteforce-protection-mikrotik-010.pngИ на закладке Action - действие drop.

rdp-bruteforce-protection-mikrotik-011.pngВсе тоже самое быстро делается в терминале следующей командой:

/ip firewall raw
add action=drop chain=prerouting dst-port=3389 protocol=tcp src-address-list=rdp_drop

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

На этом можно считать защиту от брутфорса готовой, на первых порах мы рекомендуем регулярно контролировать содержимое списка rdp_drop на предмет попадания туда легальных клиентов, после чего либо корректировать условия, либо разъяснять пользователям новые правила работы.

rdp-bruteforce-protection-mikrotik-012.png

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

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Дополнительные материалы:


  1. Оборудование MikroTik класса SOHO. Общий обзор и сравнение возможностей
  2. Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование
  3. Базовая настройка роутера MikroTik
  4. Расширенная настройка DNS и DHCP в роутерах Mikrotik
  5. Автоматическое резервное копирование настроек Mikrotik на FTP
  6. Проброс портов и Hairpin NAT в роутерах Mikrotik
  7. Настройка IPTV в роутерах Mikrotik на примере Ростелеком
  8. Настройка VPN-подключения в роутерах Mikrotik
  9. Настройка черного и белого списков в роутерах Mikrotik
  10. Настройка выборочного доступа к сайтам через VPN на роутерах Mikrotik
  11. Настройка OpenVPN-сервера на роутерах Mikrotik
  12. Безопасный режим в Mikrotik или как всегда оставаться на связи
  13. Настройка Proxy ARP для VPN-подключений на роутерах Mikrotik
  14. Настраиваем Port Knocking в Mikrotik
  15. Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
  16. Настраиваем родительский контроль на роутерах Mikrotik
  17. Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
  18. Расширенная настройка Wi-Fi на роутерах Mikrotik. Режим точки доступа

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: Подпишись на наш Telegram-канал