Защита от brutforce по 443 порту

[Chai]

Добрый вечер!
За микротиком располагается веб-сервер Zimbra, к нему проброшены порты, в т.я. 25 и 443
443-порт нужен для веб-клиентов.
Напали злобные бруты, не просто с отдельных адресов, но с диапазонов.
Нашел в вики типовое решение защиты от брусфорса, применил, по остальным портам срабатывает, по 443 какая-то загвоздка.

Код: Выделить всё

add action=drop chain=forward comment="------drop 443 brute forcers--------------------------" dst-port=443 log=yes protocol=tcp src-address-list=ssh_blacklist
add action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=1w3d chain=forward connection-state=new dst-port=443 log=yes log-prefix=\
    "---10d 443-----" protocol=tcp src-address-list=ssh_stage3
add action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m chain=forward connection-state=new dst-port=443 protocol=tcp src-address-list=\
    ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m chain=forward connection-state=new dst-port=443 protocol=tcp src-address-list=\
    ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m chain=forward connection-state=new dst-port=443 protocol=tcp

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

Почему так происходит, и что можно сделать?

Спасибо.

[MaxoDroid]

Насколько я понимаю принцип работы с пробросом трафика через конкретный порт микротика (или просто проброс порта входящего соединения), то это происходит цепочкой dstnat в NAT. До того момента, как коннект будет проброшен dst-nat - ом, цепочка для этого трафика пока что имеет вид как "input", а уж потом переходит в состояние "forward" и статусом соединения "established".
Лично у меня таких правил для защиты как туннеля, так и портов NAS, - два.
Но у меня в правилах используется "chain=input" , а у Вас "chain=forward" да еще и "connection-state=new".
Я, конечно, не специалист в области IT-технологий, но мне не совсем понятно, как проходящая цепочка может быть "new"?
Если цепочка входящего трафика по протоколу tcp - новая, то у нее есть флаг "syn", остальные имеют флаг "new".
Ну это мои личные мысли и я могу ошибаться.
Пусть магистры МикроТика меня поправят, если что.

[xvo]

Лично у меня таких правил для защиты как туннеля, так и портов NAS, - два.
Но у меня в правилах используется "chain=input" , а у Вас "chain=forward" да еще и "connection-state=new".

Значит они не работают :)
dst-nat выполняется раньше чем пакет попадает в какую-либо цепочку firewall'а.
Так что правильная цепочка для всего, что было проброшено через роутер - именно forward.
Если вы, наоборот, dst-nat'ом заворачиваете на роутер, тогда да - input.

Ну и дальше у вас тоже все рассуждения неверные: "new" - это статус соединения в connection tracker'е микротика, а не tcp флаг.

[MaxoDroid]

Набрал в Яндексе "брутфорс портов микротик".
Просмотрел примерно с десяток статей. И все они говорят: "chain=input connection-state=new"
Просмотрел пару видосов с MUM.
Вздохнул с облегчением. Так делают все. forward не нашел нигде. Вот пример https://bozza.ru/art-264.html, по которому, видимо, автор и делал защиту.
Покажите, пожалуйста, пример с "chain=forward connection-state=new"

[xvo]

А ничего, что там dst-nat вообще не участвует?!
В примере защита портов самого микротика.
Это раз.

А два, аргумент "посмотрел 15 мануалов, и там не так" вообще забудьте.
Ссылаться на официальную документацию - пожалуйста.
А если кто-то что-то настраивает по мануалу, а оно не работает - вопросы к автору мануала.
То, что половина пользователей, и вы в том числе, не понимаете, какие мануалы в каких случаях применять - это проблема самого подхода "зачем что-то понимать, я просто сделаю как в мануале по шагам", а то, что мануал к вашему случаю не подходит, ну кого такие мелочи волнуют?!

[xvo]

Вот, например, схемка по данному вопросу, официальная:
https://wiki.mikrotik.com/wiki/Manual:P ... ng_Diagram
Из которой совершенно очевидно, что пакеты прошедшие dst-nat до вашего NAS'а, в цепочке input никогда и никаким образом не окажутся, и значит ваши правила по "защите портов NAS'а" не имеют никакого шанса сработать.

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

[MaxoDroid]

Тогда как Вы прокомментируете это :https://wiki.mikrotik.com/wiki/Brutefor ... prevention?

[xvo]

В смысле?
Я же уже прокомментировал: какое ваша ссылка имеет отношение к данному случаю?

Что у вас, что в данной теме, речь идет про защиту порта прокинутого внутрь dst-nat'ом.
А по вашей ссылке, так же, как и по предыдущей, идет защита порта на самом роутере.

[MaxoDroid]

А пусть нам автор укажет источник.
А Вы, пожалуйста, покажите мне на WiKi пример правильной защиты прокидываемых портов.

[Chai]

MaxoDroid
Я для тестов пробовал делать в цепочке input, естественно, ничего не ловилось. В блэк-лист попадают только попавшие в forward. И это работает, потому что дестинейшн в итоге - не сам роутер. PacketFlow все разъясняет. Вопрос только касательно порта 443 - как сделать, чтобы добросовестный веб-клиент не блочился.

xvo
Ну и дальше у вас тоже все рассуждения неверные: "new" - это статус соединения в connection tracker'е микротика, а не tcp флаг.

Вот спасибо за это! Не знал.