Hi,
/export has one disadvantage as compared to Winbox/WebFig, it doesn't auto-arrange the rules to display them sorted by chains, so I always do that manually to be able to review the dependencies among the rules; another feature is that
/export, unlike
/print, doesn't show dynamically added rules as it's not its job.
So I've re-grouped your filter rules by chains and numbered them to make it easier to refer to them.
Before commenting on individual rules, I'd recommend you to make yourself familiar with the idea of stateful firewall and connection tracking. Each packet is inspected by all firewall rules from the top of the respective chain until one of rules which match to the real fields of the packet header and the metafields associated to the packet by previous stages of firewall processing provides a final decision about the packet (accept, drop or reject). As matching to each rule consumes some CPU cycles, it is important that an average packet would pass through as few rules as possible or, in another words, that the topmost rules match on most packets and the less likely a packet is to match a given rule, the lower in the list the rule was.
So given the above, rules 9 and 10 can be merged into one by use of combined match condition
connection-state=established,related, but the result should be moved to the position in
chain=input. Rules 13 and 14 in
chain=forward are properly placed in this regard relatively to the other rules in their chain, howeverer their mutual order is wrong - rule 13 shadows rule 14 so none of your connections is ever fasttracked. Rule 13 has to stay, however, because a small share of packets belonging to fasttracked connections is not acually fasttracked, and these packets need rule 13 to be let through by the filter.
Rule 2 should not only be right the next one after 9+10, so that flood SYNs would waste as little as possible CPU by being dropped before other rules; only after it, rule 1 should follow, to handle only SN flood sources which haven't be added to the Syn_Flooder list yet. However, a much better place for Rule 2 is in
/ip firewall raw, because by placing it there you drop those packets already before handling in connection tracking which is a CPU-expensive operation too. Rule 1 must stay in
/ip firewall filter.
Rules 2 and 4 may be merged into one if you merge the address-lists into one; rules 1 and 3 must stay separate as the criteria differ. In any case, banning an IP address for misbehavior may be different, as it is too easy to spoof a source address, so if someone sends you a SYN flood impersonating one of the addresses from which you access your machine remotely, he locks you out for a week. Which means that rule 6 should be placed before rules 1 and 3 and inverted - instead of "drop what comes from a source missing on the list of permitted ones", it should say "accept what comes from a source which is on the list of permitted ones". The way rule 6 is written now just drops these packets a few rules earlier than rule 12 would drop them anyway
provided that it is active. So the right order of actions is to first invert rule 6 (change
action from
drop to
accept adn remove the exclamation mark in the
src-address-list clause in a single step), then disconnect and re-connect using Winbox and check that rule 6 has counted a hit, and then enable rule 12. The role of rule 12 is critical - it says "drop everything which wasn't accepted by any of the preceding rules", and if it is missing, everything which didn't match any of the preceding rules will be accepted which is definitely not what you want. So you have to double-check that all addresses from which you want to permit management access,
including the LAN ones (which may be represented by the whole LAN subnet, though), will be on the address-list.
Rules 7 and 8 accept DNS requests from any source, including WAN. This is only a good idea in a limited number of cases, otherwise you open the door to various kinds of DNS attacks against your own system or against other systems - one more time a DNS request with a spoofed src-address will be responded to that spoofed address, so your machine will be overloading someone else's resources, hiding the actual attacker.
The ICMP chain to which you send the icmp packets using rule 5 can be basically reduced to rule 20. The thing is that an ICMP echo request creates a new tracked connection if it bears a yet unknown ID. ICMP echo responses are related to existing tracked connections (so those which are not will not be accepted by rule 9+10 moved to the top of the list, and thus will be dropped by rule 12), and all other ICMP types are relatable to existing TCP or UDP traffic and as such they will be either accepted by 9+10 as they match
connection-state=related if they really are related, or dropped by rule 12 if they are not. In general, any tighter restrictions on ICMP are a really bad idea.
The only thing is that if you want rule 20 to really throttle ping floods, rule 20 should not only replace rule 5 and rule 15 but it should be also placed before rule 9+10, as all ICMP echo requests bearing the same ID are considered part of an established connection if the first one of them has been accepted.
As rule 17 does not check for interface-list WAN, you can easily cut off your internal mailserver if the connection to some downstream SMTP server fails outside your network - your one will keep retrying and rule 17 will ban it, and the ban will continue being renewed. For rule 18, the same as for rules 2 and 4 applies.
Rule 19 just protects the rest of the world from this Mikrotik going mad - I don't think it makes any sense. Chain output only cares about packets sent by the Mikrotik itself.
/ip firewall filter
1. add action=add-src-to-address-list address-list=Syn_Flooder address-list-timeout=30m chain=input comment="Add Syn Flood IP to the list" connection-limit=30,32 protocol=tcp tcp-flags=syn
2. add action=drop chain=input comment="Drop to syn flood list" src-address-list=Syn_Flooder
3. add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=21,3s,3,1
4. add action=drop chain=input comment="Drop to port scan list" src-address-list=Port_Scanner
5. add action=jump chain=input comment="Jump for icmp input flow" jump-target=ICMP protocol=icmp
6. add action=drop chain=input comment="Block all access to the winbox - except to support list # DO NOT ENABLE THIS RULE BEFORE ADD YOUR SUBNET IN THE SUPPORT ADDRESS LIST" disabled=yes dst-port=8291 protocol=tcp src-address-list=!support
7. add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
8. add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp
9. add action=accept chain=input comment="Accept to established connections" connection-state=established
10. add action=accept chain=input comment="Accept to related connections" connection-state=related
11. add action=accept chain=input comment="Full access to SUPPORT address list" src-address-list=support
12. add action=drop chain=input comment= "Drop anything else! # DO NOT ENABLE THIS RULE BEFORE YOU MAKE SURE ABOUT ALL ACCEPT RULES YOU NEED" disabled=yes
13. add action=accept chain=forward connection-state=established,related
14. add action=fasttrack-connection chain=forward connection-state=established,related
15. add action=jump chain=forward comment="Jump for icmp forward flow" jump-target=ICMP protocol=icmp
16. add action=drop chain=forward comment="Drop to bogon list" dst-address-list=bogons
17. add action=add-src-to-address-list address-list=spammers address-list-timeout=3h chain=forward comment= "Add Spammers to the list for 3 hours" connection-limit=30,32 dst-port=25,587 limit=30/1m,0 protocol=tcp
18. add action=drop chain=forward comment="Avoid spammers action" dst-port=25,587 protocol=tcp src-address-list=spammers
19. add action=jump chain=output comment="Jump for icmp output" jump-target=ICMP protocol=icmp
20. add action=accept chain=ICMP comment="Echo request - Avoiding Ping Flood" icmp-options=8:0 limit=1,5 protocol=icmp
21. add action=accept chain=ICMP comment="Echo reply" icmp-options=0:0 protocol=icmp
22. add action=accept chain=ICMP comment="Time Exceeded" icmp-options=11:0 protocol=icmp
23. add action=accept chain=ICMP comment="Destination unreachable" icmp-options=3:0-1 protocol=icmp
24. add action=accept chain=ICMP comment=PMTUD icmp-options=3:4 protocol=icmp
25. add action=drop chain=ICMP comment="Drop to the other ICMPs" protocol=icmp
