Firewall: default drop - DstNAT fundamental misunderstanding?

RouterOS General
1

I could do with a sanity check here as I think I've made a mistake that could have been costly. I've got a few sites with some dst NAT port-mapping. One of them just got scanned and found vulnerable as it was letting anybody try to connect. It looks like there's a difference in the routers I'd tested all the firewalling on (7.16.2) and some of the newer ones (7.23.1). I just want to confirm this is a change I made and forgot about rather than something that's changed across ROS versions. Also, whether I should be doing this slightly differently.

Port mapping

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment=RDP dst-port=3389 in-interface=Internet protocol=tcp to-addresses=10.0.0.3

Firewalling to allow only specific IPs to use that port map

/ip firewall filter
add action=accept chain=forward comment="Allow Remote Management - RDP" dst-port=3389 log=yes protocol=tcp src-address-list=RemoteManagement

Default drop rule on routers that are secure

/ip firewall filter
add action=drop chain=forward comment="drop all from WAN including DSTNATed" connection-state=new in-interface-list=WAN

Default drop rule on those that let anyone use the port map

/ip firewall filter
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat in-interface-list=WAN

Given the fact that the working rule here doesn't say "defconf" on the front, I suspect I've tweaked it and then failed to copy that to new routers.

Firstly, can someone confirm that it's me that's been the idiot* please?

Secondly, is it preferable to leave the defconf default drop that doesn't drop anything dstnat'd and instead add a source list to the actual NAT entry via "src address list"?

Many thanks,
Gareth

*knowing when you've been an idiot allows you to avoid the problem in the future...hopefully! :smiley:

2

Since rule order is very important, please post the firewall filter config in one stretch ... with relevant rules in original order. Or better yet, post all rules ...

3

If the rules are in the order the snippets are presented in the post your "Allow Remote Management - RDP" will allow connections from the RemoteManagement address list BUT the "defconf: drop all from WAN not DSTNATed" will then permit all other dstnat connections.

I would say it is preferable to include all of the selection requirements in the NAT dstnat rule, then allow all dstnat connections in a filter rule, this is the intent of the defconf rules so you only have to add a single dstnat rule to configure port forwarding. It avoids accidents from forgetting to filter connections which have not been excluded from being NATed.

I've never been a fan of this particular defconf rule and replace it with

/ip firewall filter
....
add action=accept chain=forward comment="Accept forward destination NAT from WAN interface list" connection-nat-state=dstnat in-interface-list=WAN
add action=drop chain=forward comment="Drop forward everything else from WAN interface list" in-interface-list=WAN
....

so it is possible to see packet counters and/or log the connections which have been NATed separately from all other attempted connections.

4

My preference is to specify at the NAT rule itself the ACL using the "src-address-list" who is actually allowed to hit the DNAT.
In my FW-rules I have 1 generic allow rule in the FORWARD chain allowing anything with a valid DNAT state.

Very easy, clean and just make sure you manage the access-list correctly.

5

Thanks guys and apologies that I've not replied for so long. Definitely not that I'm disinterested (!), just that I've just moved house and don't get a functioning internet connection for another week yet!
I'll start moving the source criteria into the NAT rule - as tdw and jvanhambelgium both said, it makes it neater when it's self-contained. It's just strange that it doesn't seem to be in the documentation or examples anywhere.

6

With the way Mikrotik directly exposes the kernel's firewall functionality, there is almost never a "one true way" of doing things.

Using a "drop except dst-natted" or adding an "accept dst-natted" in the forward chain is a fairly common pattern. Of course this means that any source address restriction should now be applied to the dstnat rule.

This is usually preferred because the restriction lives in the same rule that allows the port mapping to happen.

It is a bit strange that the examples do not mention this (common) scenario. I can only guess, but maybe this is because the prevalence of dynamic IPs has made this somewhat less useful.

While we're on this topic, another useful variation is to use a src-address-list matcher, and then DNS names can be specified in the address list, that are then automatically resolved, populated and updated.

7

Thanks Lurker. Definitely working with restrictions defined in the NAT entry. Lack of docs out me off but it's all good.
Had to go install the Chateau 5G I was using for my only internet connection so now I'm down to a cheap 4G router :frowning: At least I'm getting 10Mbps, it could be worse :wink: Wish me luck on Thursday that they can actually install me a new fibre... rather than turning up and giving me another reason why they've sent the wrong people! facepalm