Защита от брутфорса RDP на MikroTik
В данной статье будет описан наиболее оптимальный механизм защиты от подбора паролей (брутфорса) протокола RDP на оборудовании MikroTik используя мощь Firewall Conntrack, дополнительные фильтры MikroTik и, наконец, листы IP адресов. Не подвержен ложно-положительным срабатываниям при подключениях MSTSC и множественных подключениях с одного IP-адреса
Немного теории
RDP – протокол удалённого подключения от Microsoft к удалённому рабочему столу, использующий TLS и TCP/IP как транспорт. Для аутентификации современная реализация RDP использует службу CredSSP, по другому называемая NLA или Network Layer Authentication (Аутентификация на уровне сети) и SPNEGO для передачи аутентификационных данных.
Таким образом, при подключении клиент первым делом инициирует TLS handshake, затем происходит аутентификация CredSSP. Если аутентификация неудачна, сервер сбрасывает соединение. Соответственно, одна попытка подключения = одному TCP соединению.
На данном этапе нужно обратиться к MSTSC (так называемому microsoft terminal server client) и выяснить каким образом происходит подключение.
MSTSC инициирует в лучшем случае 2 соединения до рабочего стола, а в худшем до 6.
Почему?
В процессе подключения MSTSC может показывать различные диалоговые окна, например: диалоговое окно об отсутствии доверия к сертификату сервера, уведомление безопасности о проброшенных ресурсах (дисках, папок, принтеров, смарт-карт), диалоговое окно запроса учетных данных.
После показа каждого диалогового окна и уведомлений MSTSC закрывает соединение, что приводит к ложно-положительному результату (блокировке настоящих клиентов) в реализации защиты на основе этапов в адрес-листах.
Вариант описанный в этой статье лишен этого недостатка и не будет приводить к ложно-положительным блокировкам, также вы сможете настроить его под себя.
Реализация
Все правила, относящиеся к механизму будут располагаться в отдельной цепочке, называемой rdp-brutforce, в которую будут jump-иться пакеты, требующие обработки:
/ip firewall filter
add chain=forward in-interface=ether1 protocol=tcp dst-port=3389 action=jump jump-target=rdp-bruteforce
Это позволит быстро отключить все правила, относящиеся к данному механизму отключением этого правила, также вы можете добавить портов назначения через запятую, если это необходимо и сменить входящий интерфейс.
/ip firewall filter
# [0] отбрасываем пакеты в ловушку, ip-адреса которых уже попали в бан лист
add chain=rdp-bruteforce src-address-list=rdp-brutforce-zlodei protocol=tcp action=tarpit
# [1] возвращаем в обработку пакеты, ip-адреса которых в надежном списке
add chain=rdp-bruteforce src-address-list=rdp-trusted-ips connection-state=established,related action=return
# [2] возвращаем в обработку пакеты новых соединений, ip-адреса которых в надежном списке
add chain=rdp-bruteforce src-address-list=rdp-trusted-ips connection-state=new action=return
# [3] добавляем на сутки в адрес-лист доверенных адресов rdp-trusted-ips ip-адреса, длина соединений которых более 80КБ
add chain=rdp-bruteforce connection-state=established,related connection-bytes=80000-0 action=add-src-to-address-list address-list=rdp-trusted-ips address-list-timeout=1d
# [4] для оставшихся новых соединений ставим лимит по количеству соединений в единицу времени
add chain=rdp-bruteforce connection-state=new dst-limit=10/1h,5,src-address/1h action=return
# [5] и наконец, добавляем в список заблокированных rdp-brutforce-zlodei тех, кто не вписался в ограничение
add chain=rdp-bruteforce connection-state=new action=add-src-to-address-list address-list=rdp-brutforce-zlodei address-list-timeout=3d
Детали реализации
Главным участником является правило c #4, в котором устанавливаются ограничение на количество новых соединений: текущий вариант предполагает максимум 15 попыток в час, при этом за короткий промежуток времени может пройти до 5 попыток (этим устраняется особенность подключения MSTSC); учитываются адрес источника и время истечения попытки 1 час.
Данные параметры были подобраны опытным путем.
Если лимит пройден, то пакет вернется в обработку. Если лимит не пройден, то IP-адрес попадает в блокировку на 3-е суток правилом #5.
Следующим по важности является правило с #3, которое добавляет в список доверенных адресов длина соединений которых более 80 КБ.
Это правило устраняет ложно-положительные блокировки внешних адресов, за которыми более одного клиента, подключающегося к серверу.
Практический пример: у вас есть терминальный сервер и офис с одним IP-адресом, это правило позволяет не добавлять вручную в список исключений IP-адрес офиса.
Он автоматически добавляется в список доверенных адресов, когда количество переданных данных соединения становится более 80КБ, а это происходит, когда один из пользователей успешно зашел в сеанс и получил удалённый рабочий стол.
Для данного IP-адреса более не применяются ограничения на сутки, пока адрес находится в списке доверенных.
Правило #1 блокирует подключения c заблокированных адресов. В данном случае используется ловушка iptables, но вы можете использовать tcp reject или drop по своему усмотрению.
Правила #2 и #3 возвращают в обработку пакеты попавшие в доверенные. Вы можете объединить их в одно, отключив проверку на connection-state, однако достаточно удобно для отладки смотреть сколько новых соединений происходит с доверенных адресов.
Результаты
Инсталляция 1
Обеспечивая защиту более 100 внешних IP-адресов на протяжении полугода имеет следующие счетчики: 5 млрд (!) запросов заблокировано, 80 млн запросов обработано. Таким образом, можно заявлять об эффективности более 98%.
Количество отброшенных пакетов в секунду составляет 120-200 штук в секунду, в списке заблокированных находится 250 адресов.
Инсталляция 2
Обеспечивая защиту на обычной домашней сети с выделенным IP и проброшенными портами RDP имеет следующие счетчики: почти 5 млн запросов заблокировано, 8.5 тысяч обработано. Таким образом, можно заявлять об эффективности более 99.2%.
Заключение
Правила блокировки с минимальными изменениями могут быть адаптированы для других типов протоколов, которые завершают соединение в случае неудачи аутентификации.
Лимиты и другие параметры могут настраиваться под ваше окружение и предполагаемое количество запросов.
Защита от брутфорса RDP на MikroTik: 5 комментариев
Не работает правило №3, подключаюсь с левого айпи, вводя верные учетные данные, но адрес не попадает в лист трастед. Мб я чет не так делаю.
Подключаетесь до рабочего стола? Нужно чтоб по соединению прошло 80+КБ (может пару открытых-перетянутых окон, что-то подобное)
fasttrack отключен?
Да, разобрался, ваш форвард поместил выше остальных форвардов.
Вопрос 1:
Какой порт указывать, если за NATом несколько RDP серверов – перечислить фиктивные типа 33089,33090 или оставить один 3389?
Вопрос 2:
Если у пользователя появился запрос на ввод имени пользователя и пароля, и он не вводит пароль скажем минуту, а потом вводит верно – он попадет в черный список?
> Какой порт указывать, если за NATом несколько RDP серверов – перечислить фиктивные типа 33089,33090 или оставить один 3389?
Перечислять все фактические порты назначения.
Если несколько серверов, но на каждом 3389, то оставить 1 3389.
Если один сервер, но каким-то образом там оказалось несколько RDP серверов, то перечислять все порты назначения.
Если несколько серверов с разными портами назначения, то перечислять порты назначения.
> Если у пользователя появился запрос на ввод имени пользователя и пароля, и он не вводит пароль скажем минуту, а потом вводит верно – он попадет в черный список?
Нет.
mstsc в любом случае дропает соединение при запросе пароля, в данном случае не имеет значения сколько времени вводился пароль.
Скорее наоборот, с течением времени в зависимости от правила могут позволяться дополнительные попытки соединений