Защита от DDoS в микротике⁠⁠

Тема вроде бы везде расписана, но, как оказалось, расписана не для средних умов(вроде моего), а так же содержит в своем описании ошибки и недочеты. Недавно на одного из провайдеров обрушили такую нехилую атаку более чем с 7000 узлов со всего мира, успешно забив весь канал входящим трафиком, досталось и клиентам прова на белых адресах. И вот что хорошо бы сделать заранее, чтобы как-то нивелировать эффект от атаки немного расскажу, а так же задам уважаемым читателям вопрос по некоторым деталям настройки микрота в этом ключе. Погнали.
Забив в поиске сабж, легко выходим на статью от самого микрота https://help.mikrotik.com/docs/pages/viewpage.action?pageId=..., к котором как бы разжевано что вписать и будет ок. Однако оказалось, что если тупо скопировать приведенный там фрагмент конфига, оно работать не будет, т.к. в нем забыли явно дописать
"/ip/firewall/filter/add chain=forward connection-state=new action=jump jump-target=detect-ddos" (но расписали об этом почему то ниже.Как видим, даже в этой строчке конфига содержатся ошибки в виде "/" вместо пробелов.
Правильно будет

/ip firewall address-list
add list=ddos-attackers
add list=ddos-targets
/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=detect-ddos
add action=return chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddos-targets address-list-timeout=10m chain=detect-ddos
add action=add-src-to-address-list address-list=ddos-attackers address-list-timeout=10m chain=detect-ddos
/ip firewall raw
add action=drop chain=prerouting dst-address-list=ddos-targets src-address-list=ddos-attackers

Вкратце, что оно тут делает: создает 2 списка, в которые потом попадают адреса злоумышленника и жертвы(кто такая жертва-ниже), создаем и отправляем в цепочку обработки detect-ddos (я и не знал, что можно создавать свои цепочки,оказывается, да не представлял зачем) новые соединения с нашим микротом, там мы определяем условия для действий над этим соединением/пакетом, возвращаемся из нее и далее пакеты идут куда там дальше в workflow определено. Тут же добавляем действия, которые мы будем делать, если условие в action=return сработало, в нашем случае добавляем адреса получателя и отправителя в соответствующие списки. У нас в примере указано, что если будет больше 32 пакетов новых соединений в секунду за 10 секунд, то занесем адресочки в списки айайай. Вот тут как раз возникает вопрос: а если мы хотим отслеживать что-то еще, кроме параметра dst-limit, например connection limit, и вот тогда правило будет срабатывать при соблюдении обоих условий, или хотя бы одного? В документации ответ на этот вопрос мне как-то не попался на глаза, может аудитория подскажет. Кстати, в обработке action=jump, рекомендую задать список доверенных адресов в Src.addr.list и поставить на него "!", чтобы эти адреса не попали в список злодеев, а то мало ли, сами себя забаните на микроте, а это никому не нужно. Об этом почему то в мане скромно умолчали, а об этот камень можно больно ударится. Но вернемся к основным действиям. Наши правила успешно создают списки, а уже они обрабатываются в правиле /ip firewall raw, в котором написано следующее: будем отбрасывать все пакеты, адреса которых содержатся в списках ddos-attackers И ddos-targets. Казалось бы, тут все понятно, однако есть нюанс, о котором опять умолчали: если у вас есть правило NAT, перенаправляющее порт 443 на внутренний сервер с адресом 192.168.168.10, то случится.. ничего, защита выше работать не будет и весь траф на наш бедный веб-сервер будет так же литься полноводным потоком . А почему? А потому что мы добавляем адрес жертвы в цепочке forward, а там маячит наш внешний IP, а никак не внутренний адресок сервера.
Так что либо вписывать адреса серверов за NAT ручками в список ddos-targets, либо правило втыкать в другое место цепочки обработки. Но и это еще не всё. Допустим мы где то у какого то клиента завели рассылку почты с нашего сервера, находящегося за нашем же микротом и который внезапно захотел разослать 10 писем одновременно. И что? А то что адресок клиента успешно попадет в список забаненых, т.к. по количеству одновременных коннектов успешно попадает в наш фильтр. Так что придется ставить фильтры со своими параметрами чуть ли не на каждый сервис, который есть за нашим микротом. Вот такие дела.. а казалось бы, что всё просто.