I bought my first Mikrotik router (hap ax2) that I plan to use as a wired router at home (so I already removed the wifi-qcom package).
When looking at the default firewall config, it seems that it contains some rules for features I do not plan to use. So I tried to minimize the Firewall Rules config, from a zero-trust perspective, to have a solid but minimalistic base before configuring everything else (some VLANs mostly). But as this is my first Mikrotik router, I would like to know if the changes I made would not cause issues, or make the setup less secure.
Here is what I changed:
I do not plan on using Raw rules, so I removed the ‘untracked’ state from the Accept rules
I will not be monitoring or troubleshooting my router from the WAN, so I removed the ‘defconf: accept ICMP‘ rule. LAN ICMP traffic is still allowed by the ‘defconf: drop all not coming from LAN‘ rule
I will not be using CAPsMAN, so I removed the ‘defconf: accept to local loopback (for CAPsMAN)‘ rule
I do not have any IPsec tunnels, so I removed the ‘defconf: accept in ipsec policy‘ and ‘defconf: accept out ipsec policy‘ forward rules
I don’t need port forwarding from WAN to LAN, so I modified the drop rule on forward to drop all WAN traffic (instead of allowing dstnat)
my ISP hands out an IPv4 address and I don’t use IPv6 on my LAN, so I disabled IPv6 all together
This gives the below Firewall rules configuration
Do you see any issues with this config vs the default config?
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
1 ;;; Input: Accept established,related
chain=input action=accept connection-state=established,related log=no log-prefix=""
2 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid
3 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN
4 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related
5 ;;; Forward: Accept established,related
chain=forward action=accept connection-state=established,related log=no log-prefix=""
6 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid
7 ;;; Forward: drop all from WAN
chain=forward action=drop in-interface-list=WAN log=no log-prefix=""
This was the default config:
filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked" filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid" filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP" filter add chain=input action=accept src-address=127.0.0.1 dst-address=127.0.0.1 in-interface=lo comment="defconf: accept to local loopback (for CAPsMAN)" filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN" filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy" filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy" filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack" filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked" filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid" filter add chain=forward action=drop connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
I would put back the "allow from loopback" rule. It's not only for capsman, and it's generally expected that any host (and a router is one as well) is able to reach itself.
The other is that the default forward drop from WAN can be replaced with
This currently has the same effect, but it has the benefit of following "the allow what I list explicitly and drop everything else" philosophy, which should be the default for any strict fw. The same treatment can be applied to the input chain as well.
Concur with lurker, the previous capsman centric rule has been replaced by a general router lo service which can prove useful is many ways, and is no risk.
In terms of the other entries, I was unaware that on the input/forward chain untracked referenced only raw rules, but if so, seems ok.
Same with ipsec, I usually do the same.
Same with port forwarding rule………
all you need is LAN to WAN
potentially admin to vlans
Drop all else.
on the input side, I typically do not allow LAN because only the admin requires access to the router.
So for me its
input chain in-interface-list=LAN src-address=ADMINLIST
input chain allow LAN to port 53,123 UDP
input chain allow LAN to port 53 tcp
Drop all else.
I also disable ivp6 and remove all address lists and rules save two
input chain drop
forward chain drop.
The thinking is if somehow software update somehow enabled ipv6, the rules would be in place to stop any traffic.
The devices will still communicate with each other in IPv6, because disabling the IPv6 firewall doesn't prevent Layer 2 traffic. In fact, to prevent it (only traffic passing through the router), the ipv6 firewall must be left enabled.
Regardless, the router can and does generate IPv6 traffic because it isn't considered a chain in your 2 rules.
If there are switches or other L2 communication methods between the devices, a firewall rule won't block LAN traffic anyway.
I won't add any comments on the configuration because, in my opinion,
everything was already wrong from the start,
as if ICMP was NOT only useful for a couple of stupid things and that's it...
I've been waiting for YEARS for ANYONE to prove to me that the default rules (which I didn't write)
are wrong or unsafe (aside from the fixes already known and applied in old IPv6-only rule) on WAN side.
I'm still waiting for ANYONE... And ideology doesn't matter here...
Thanks rextended, I was thinking about WAN to LAN or WAN to LAN traffic vis-a-vis IPV6. I certainly do not know anything about intra router L2, IPV6 traffic. I would probably not be concerned, but I should be …….. are you suggesting I somehow lock that down as well???
Worry is solved with Botex I am told………. Personally against injecting chemicals for cosmetic reasons.
But I do want to know what the connection is between raw rules and untracked in both chains??
If the default firewall has 11 rules (8 ignoring IPsec) and yours only has 4...
What comes to mind?
From now on, I personally will no longer provide any help to anyone who doesn't strictly start with the default firewall configuration.
All these fantasists who make machines a mess because they think the default values were randomly placed there,
and think that their work of deleting default rules is smarter, don't deserve to waste my time.
I prefer to help others who want to be helped,
rather than users who want be complimented "Look what a great job I did, did I delete well and put enough random things?".
I would add - as a side note - that (within limits) the number of firewall rules do not affect speed or CPU usage in a meaningful way, so having 1, 4, 8 or 11 (or 25) doesn't change anything, see:
The only reason to have less rules is that the export is more readable, at the cost of risking to make the router either insecure or working in strange ways.
In each rule, we only work with established, related, and new connections, so an invalid connection will be dropped. Why then do we add invalid?
Why put the invalid rule second if, according to the counter, most users will only have it for less than 0.1% of the total number of packets? What nonsense?
I get your point, but part of my LAN devices are allowed to talk to each other. The once that aren’t will be placed in a separate, more restricted VLAN (I still need to add that config).
I you believe there is only one magic universal set of default firewall rules that work for every situation, then others are not the fantasists.
While there is nothing wrong with the RouterOS default firewall rules, they are not suited for every situation and have to be adapted accordingly. And that’s what I’m doing here.
If you are still having issues with me deleting the ICMP rule, take a look at other router/firewall manufacturers. Many of them block ICMP for IPv4 by default, and they have been doing that for many many years. Or are you claiming that only Mikrotik knows what they are doing and all others are wrong?
I you don’t want to help people because they don’t strictly start with the default firewall configuration, that’s fine, but don’t pollute their topics with your rants.
If you don’t add the ‘drop invalid’ rule, and don’t add it as the second rule, invalid packets would be allowed in each of the other ‘accept’ rules, which typically are not stateful. So you either have to block invalid packets early on (easiest), or make all follow-up rules stateful (more complex).
