Спасибо, Илья! Тогда полный элемент фаервола с учетом того, что мне нужно защищаться только от внешних угроз, скорее всего, будет таким: Код: # Посылаю в цепь проверки только те запросы, которые идут из внешнего мира – WAN add action=jump chain=forward connection-state=new dst-port=5000,5001,6690,80,443,5005,5006 jump-target=check-bruteforce \ in-interface-list=WAN protocol=tcp add action=jump chain=forward connection-state=new dst-port=5000,5001 jump-target=check-bruteforce \ in-interface-list=WAN protocol=udp # Дропаю, все, что попало в список "bruteforcer" add action=drop chain=forward connection-state=new log=yes log-prefix="--DROP NAS_PORTs brute forcer--" \ src-address-list= bruteforcer # Тут идут ступени для аутентификации (все, как Вы написали): add action=add-src-to-address-list address-list=bruteforcer address-list-timeout=10m chain=check-bruteforce \ src-address-list=bruteforce-stage-5 add action=add-src-to-address-list address-list=bruteforce-stage-5 address-list-timeout=1m chain=check-bruteforce \ src-address-list=bruteforce-stage-4 add action=add-src-to-address-list address-list=bruteforce-stage-4 address-list-timeout=1m chain=check-bruteforce \ src-address-list=bruteforce-stage-3 add action=add-src-to-address-list address-list=bruteforce-stage-3 address-list-timeout=1m chain=check-bruteforce \ src-address-list=bruteforce-stage-2 add action=add-src-to-address-list address-list=bruteforce-stage-2 address-list-timeout=1m chain=check-bruteforce \ src-address-list=bruteforce-stage-1 # Принимаювсе, чтопрошлопроверку add action=accept chain=forward connection-state=new dst-port=5000,5001,6690,80,443,5005,5006 protocol=tcp add action=accept chain=forward connection-state=new dst-port=5000,5001 protocol=udp Но тут у меня ещё один вопрос. В фаерволе "Из коробки" есть правило, по которому дропаются все новые проходящие соединения, которые (как я думаю) по NAT не имеют назначения, то есть идет атака на сеть за Микротиком: Код: add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN Правда, тут есть еще вопрос. А как может быть forward=!dstnat, если мы порты проверяем, а в правиле Код: add action=accept chain=forward comment="Accept Forward Established,Related" connection-state= established,related мы пропускаем только установленные соединения и соединения, связанные с ними. Скажите, пожалуйста, если это правило имеет смысл, то, как я понимаю, оно должно быть ниже, что бы проверка прошла корректно.
Здравствуйте. Можно несколько вопросов? Для чего в правиле: Код: #Пошла защита от брутфорса. Грохаем все что попало в адрес-лист BruteForcer. Оно специально стоит ПОСЛЕ отправки на проверку. add action=drop chain=forward comment=Drop-Bruteforcers connection-state=new src-address-list=bruteforcer - указывать именно NEW соединения, ведь мы явно блокируем уже сам источник. Почему занесение в новую цепочку и проверку проводим в фильтре, а не в мангле? И при защите RDP от брутфорса надо позаботиться о защите на прикладном уровне. При использовании ранних версий RDP серверов, подбор паролей может осуществляться в рамках одной установленной (ETABLISHED) tcp сесси. А вообще, в ROS есть же встроенная функция PSD, где можно выбрать таймаут, за который она отслеживат количество портов. Выставляем таймаут побольше, выбираем общий вес и вес по портам, и отлично отлавливаем сканеры портов.
Я бы вам посоветовал уменьшить таймаут промежуточных списков, т.к. тот же мобильный DS Cloud может довольно часто слать запросы на подключение по 6690 порту и источник может часто попадать в список bruteforcer. И наверное, к данным правилам не мешало бы добавить исключение из источников локальную сеть (а лучше все bogon сети), если используется hairpin NAT для доступа по внешнему адресу из той же сети.
