this could be a quite noob question to ask, but I am quite stuck now and getting dumber by the minute.
I have one MT 6.47.3v with a pretty basic setup, one static IP for the Internet and some 2 subnets inside. Most of the NATed traffic is RDP forwards from some random port to 3389 and that works fine.
Its dtsnat on the WAN interface from some port to the IP of the machine, port 3389.
The problem comes when I get a lot of brute force or pentest traffic to that particular port from some unknown IP, its not doing any harm (yet!), but, when I then try to make a filter rule to filter that IP (or its range), I am not able to do that. Packets still go through.
Only when I DISABLE that NAT, I see packets are getting filtered and dropping. But, then I don’t have NAT there…
How can I filter some IPs, but still have NAT, cause my impression is that its first NATed and then goes thru a filter.
I can post some specifics of the configuration, but I assume I am just dumping and missing some simple options to do this.
Filtering dst-nat ed packets seems to work ok here.
One guess:
If you copied and modified the default defconf: drop all from WAN not DSTNATed rule and edited it.
You need to remove the connection state (! dst-nat) setting from your new rule.
Also:
You should be using a newer version of RouterOS,
(and reset to defaults and apply your changes to that, the defaults do sometimes change, usually improving)
You should be using some sort of VPN for RDP access. (Wireguard in V7 is very good, worth the upgrade by itself)
Show us firewall configuration (execute /ip firewall export file=anynameyouwish from UI, fetch the file off device, open it with text editor and copy-paste it here inside [__code] [/code] environment).
It would be much easier, if you’d have explicit ultimate rule in the line of chain=forward action=drop … preceeded by explicit allow rules.
Now, if you build a black list of addresses, it’s wise to have white list as well. So you first accept connections from whitelisted addresses, then drop attempts from blacklisted addresses and later deal with the rest. Whitelist is important if you’re building blacklist automatically … it’s fairly easy to fake source addresses only to make one of your trusted addresses to a black list and then you can loose access …
If you want to do something like this for dst-nated connections, it would look something like this:
Where to place these rules? Rules get evaluated from top to bottom and first matching executes. So place the rules as high as possible because you want to drop unwanted connections as possible. But not above rules which are more specific and may have different outcome. Also keep rules which accept packets of already established connections (and related packets) at the top … which will deal with wast majority of packets real quick and won’t waste CPU cycles by evaluating rules which won’t apply.
And keep in mind that NAT-ed traffic is handled by chain=forward. For dst-nated traffic, rules will see the rewritten dst-addresses (dst-nat is done before firewall).
There’s another possibility: raw rules … so you collect addresses into BL with filter rules but drop traffic in raw (similar concepts apply, but sooner).
Regarding the convolution of FW setup: if you go ahead and upgrade ROS to latest v6 stable (6.49.x), have a look at default config. Fairly recent ROS versions come with very decent default firewall ruleset … you should study them and rework your firewall to make it more compact and yet more secure. Quite probably you’ll only have to add the dst-nat rules and a very few others.
Yeah, I know. I inherited this issue and am trying to fix it now.
I get this BL WL. I will try to make it that way. src-address-list is a path from the root or from some specific dir?
But, I think this is the key part:
And keep in mind that NAT-ed traffic is handled by chain=forward. For dst-nated traffic, rules will see the rewritten dst-addresses (dst-nat is done before firewall).
Even if I make this, how will it work if dst-ant is done before the firewall? Thats my main issue. Receiving to NATed port some strange IPs, trying to get to RDP inside, which I can not filter with firewall due to that fact you mentioned.
There’s another possibility: raw rules … so you collect addresses into BL with filter rules but drop traffic in raw (similar concepts apply, but sooner).
How does this work? What do you mean “drop traffic in raw”?
I’m not sure I’m getting your question. src-address-list acts similarly to src-address … but takes name of address list as parameter. You have a feasible address list in your config already (WL, constructed in /ip firewall address-list), and you can construct other address lists similarly (static) or by using firewall filter rules (with action=add-src-to-address-list, see firewall properties list).
But you can, NAT is one stage in packet processing and it doesn’t make packets skip firewall. NAT indeed has some “matcher” properties (e.g. src-address or dst-address), but they only govern whether connection gets NATed or not … it does not mean that “non-matching” connections won’t pass device, it only means they will pass un-NATed if firewall doesn’t block them. So seeing properties with same names as in firewall filters might mislead somebody into thinking that NAT does the blocking as well. However, default firewall filter ruleset has an ultimate rule in chain=forward which essentially says “drop all packets coming in through one of WAN interfaces and are not dstnat-ed” (which packets, not matching any dst-nat rule, aren’t). You have a similar rule, but it is disabled.
The only difference between “simply routed” packets and “NAT-ed” packets is that “simply routed” packets enter firewall processing unaltered while DSTNAT-ed packets have headers already rewritten. Alas, with DST NAT only dst-address and dst-port get rewritten, src- counterparts remain unchanged. So firewall can act on both varieties of packets similarly (as long as the matcher part of rules inspects src-* fields).
You may want to study packet flow. It’s dense, but after you get it, it’s rewarding.
Note: I’m linking documents from older (wiki-style, accessible via https://wiki.mikrotik.com//wiki/) MT documentation, they apply to ROS v6. With ROS v7, some things changed and newer (confluence-style or whatever, accessible via https://help.mikrotik.com/docs/) documentation applies better.
So I’ll again full heartedly recommend you: have a look at contemporary default firewall configuration, understand it, and try to replace the mess you have with a simpler, yet more secure, ruleset.
Only a “practical” suggestion, if I may (as a complete firewall rules n00b).
Add a CLEAR comment to EACH firewall filter rule you have, when you add a rule you have clear in your mind why you are adding it and what it should do, when, months later, you review the firewall rule if there is not such a comment you have to re-parse the rule and attempt to understand what it does (and you might make a mistake here) and remember or re-construct the actual reason why it was added (and here you might make another mistake/assumption).
When there are only a handful of such rules and they are simple enough it is not difficult, but if you have tens of them, it is easy to get confused when you review them at a later time.
I agree with the suggestion to put comments that mean something to you for each firewall rule. Makes it far easier to remember a year down the road what you were doing.
The approach is problematic ( more interested in blocking traffic vice focusing on needed traffic and simply dropping all else, Your attempt to run RDP for clients is going to cause issues. First and foremost RDP is an old protocol not considered secure. Its been replaced by citrix type functionality in most places. Why not provide Wireguard connectivity for clients if they have to reach certain devices???
There is quite frankly a freaking mess in your NAT rules ( both sourcenat and dstnat ).
I wouldn touch this with a 10 foot pole, but impressed you came up with this on your own and didnt use reddit or youtube to build it.
When your interested in simplifying let me know.
Yes, this router is like your old ugly friend, you know its there, but you pretend its not.
I will go thru all these suggestions, first I upgraded it to the latest stable version.
I
I wouldn touch this with a 10 foot pole, but impressed you came up with this on your own and didnt use reddit or youtube to build it.
Yeah, I am actually too old not to use forums and ask if I don’t know something
I will try to figure out my own something and post when I have things sorted for a quick check up.
