Is it a good idea to explicitly block ports for running services from WAN? If so, how?

I have setup a MikroTik hEX Refresh device with the default firewall rules.

I then added a few additional rules. The first 2 rules I added were to drop “everything else” on the input and forward chains. I added these rules at the end, with lowest precedence.

Further to this, I disabled all optional services. I have now only dhcp and winbox services active. These use ports 67 and 8291 respectively.

It would seem reasonable to want to block these services on WAN interfaces, of which I have 2. WAN and WAN2.

In addition, I have two further interfaces, PUBLIC_LAN and DMZ. It would also seem sensible to block winbox on these interfaces as well.

I added 2 rules to block DHCP:

add action=drop chain=input comment="block DHCP 67 from WAN" dst-port=67 in-interface-list=WAN protocol=udp
add action=drop chain=input comment="block DHCP 67 from WAN2" dst-port=67 in-interface-list=WAN2 protocol=udp

I then added a further 4 rules to block WINBOX:

add action=drop chain=input comment="block winbox 8291 from WAN" dst-port=8291 in-interface-list=WAN protocol=tcp
add action=drop chain=input comment="block winbox 8291 from WAN2" dst-port=8291 in-interface-list=WAN2 protocol=tcp
add action=drop chain=input comment="block winbox 8291 from DMZ" dst-port=8291 in-interface-list=DMZ protocol=tcp
add action=drop chain=input comment="block winbox 8291 from PUBLIC_LAN" dst-port=8291 in-interface-list=PUBLIC_LAN protocol=tcp

These rules appear with highest precedence.

I then did a google search and found that WINBOX uses both TCP and UDP.

I wasn’t able to add a rule which says “block traffic destined for this port number”. I had to choose a protocol to be able to add a port number. I guess this might be because some protocols do not use port numbers? I’m not sure about that.

I could add a further 4 rules to block WINBOX on UDP. Or I could create another interface list which includes WAN, WAN2, DMZ and PUBLIC_LAN.

Is there any way just to block the port regardless of whether the connection is TCP, UDP, or something else?

Then additionally, while I assume what I am trying to do here is reasonably sensible, it might not be. There might be something I have overlooked here. Please let me know if this is not a good idea!

I think you started correct: end with a block all rule on both input and forward chain.

Any additional blocking (befor this rule) would be redundant: when you don’t explicitely allow, it is already blocked.

So…for me it makes no sense to have these rules in place.

If you block anything coming from WAN which has not been accepted before, what's the added value to block it again based on protocol or port ?

That’s true, the default rules include this.

I think probably I don’t know enough detail about what defines something as being established, related or untracked.

Somewhat trivial, but this could be used to setup different counters to see what traffic is attempting to connect.

But that isn’t really that useful. It’s somewhat interesting I suppose, bot not something I would actually want to have running long term.

It's like some people wanting to use dynamic address lists for external IPs to see who tries to come in unauthorized and then add those IP addresses to a dynamic block list.

Very nice and all but zero added value (in most cases) and it takes away resources from your router when it has to process all those rules.

Simply drop what's not allowed and be done with it. Much easier.

Ok thanks. I’ll just stick with the default rules + the drop all at end rule then.

Yes, blocking management ports from WAN is a good idea. In RouterOS, you can just restrict Winbox and DHCP access to interface-list=LAN and use /ip service set winbox address=192.168.0.0/24 instead of manual drop rules.

NOTE: IPv4 DHCP is handled differently and is not affected by the usual firewall tables. It's pointless to block or allow the IPv4 DHCP ports in RouterOS firewall.

On the other hand, DHCPv6 traffic do go through the firewall, so you'll can have rules on the IPv6 firewall to drop or allow it (the defconf firewall does have such rules).