правила файервола...

Первый комментарий: Просто отбрасывать все фрагменты — плохая практика. Вы скорее сломаете нормальную работу, чем защитите mikrotik от «сплойта». (Представьте себе сайт, который позволяет фрагментацию пакетов и находится за каналом с низким MTU в интернете. Вы просто не сможете им пользоваться.) Второй комментарий: Если хотите заниматься детальной проверкой подписей атак, стоит поднять snort-сервер и связать его с API для добавления злонамеренных источников в черный список, а правила фаервола при этом сделать простыми. Однако, если хотите просто автоматически блокировать хосты, которые сканируют порты... Поведение Fail2ban: Создайте два списка IP-адресов: unbannable и blacklist. Список unbannable — это хосты, которые никогда не должны блокироваться автоматически. Если кто-то поймёт, что у вас есть такая fail2ban-система, он может начать шлёпать поддельные пакеты “от” важных сайтов (скажем, ваших DNS-серверов) на случайные порты, чтобы ваш правило забанило именно эти DNS-серверы. (Ужас!) blacklist — очевидно. Сделайте эти правила первыми в соответствующих фильтрах:

chain=input src-address-list=blacklist action=drop  
chain=output dst-address-list=blacklist action=drop  
chain=forward dst-address-list=blacklist action=drop  
chain=forward src-address-list=blacklist action=drop  

Если решите ставить snort-сервер, на этом остановитесь и настройте способ, чтобы snort мог добавлять адреса в blacklist. (unbannable в этом случае ничего не даст, можно удалить) А теперь главное — после правила “accept connection-state=established,related” во входящей цепочке добавьте такие правила:

action=accept in-interface=!wan  
action=jump jump-target=allowed-services connection-state=new limit=10,5  
action=drop connection-state=invalid limit=5,2  
action=drop src-address-list=unbannable  
action=add-src-to-address-list address-list=blacklist log=yes log-prefix="blacklisting new host:"  
action=drop  

Обратите внимание на правило jump — оно переводит в новую цепочку “allowed-services”. Это цепочка правил для портов, на которых хотите открывать сервисы (если таковые есть). Последнее правило в этой цепочке — просто “drop все”. Пример цепочки allowed-services:

action=accept chain=allowed-services protocol=tcp dst-port=80,443,8080,10000-11000  
action=accept chain=allowed-services protocol=tcp dst-port=25 src-address-list=spamfilters  
action=accept chain=allowed-services protocol=udp dst-port=53 src-address=1.2.3.4  
...  
action=drop chain=allowed-services  

Syn-флуды: Есть опция, которая по умолчанию выключена, называется syncookies — стоит почитать про неё и понять, подходит ли она вам. Честно говоря, я бы не углублялся так сильно в правила обработки пакетов.

chain=input in-interface=ether1 protocol=tcp connection-state=new tcp-flags=!syn (в Winbox это в разделе Дополнительно, в TCP flags выберите syn и отметьте галочкой !) action=drop

Когда речь заходит о NAT-переадресации портов, указывать обратный путь не нужно. Любая транслция, которая происходит, будет записана в таблицу в оперативной памяти. Пакеты проверяются именно по этой таблице перед тем, как попасть в цепочку — так быстрее. Поэтому достаточно сделать правило типа: in-interface=ether5 protocol=tcp dst-port=80 action=dst-nat to-addresses={внутренний IP веб-сервера}. Не волнуйтесь насчет интерфейса выхода.

Если прокси явно настроен в браузерах, то NAT-правила не нужны.

Если хотите перенаправлять пользователей на прокси: chain=dstnat in-interface=!ether4 protocol=tcp dst-ports=80 action=dst-nat to-addresses={веб-прокси} to-ports=8080

Обязательно поставьте это правило после правила «прозрачного» доступа к веб-серверу, потому что оба срабатывают на dst-port 80, но правило для прокси говорит «не ether4» — ether5 тоже подходит под !ether4, так что убедитесь, что сначала проверяется нужное правило.

Dstnat работает без указания интерфейса, а вот srcnat без интерфейса не работает — такова суть NAT.