Blocking Traffic into my Management Port

RouterOS Beginner Basics
1

Hey remember me? The management port guy?

Next simple thing I want to do is block all traffic into the management network. I’ll eventually open that up to VPN but for now block everything. Danged if I can figure it out though. I thought it would be something easy like this

add action=drop chain=forward in-interface-list=MGMT out-interface=!P8-MGMT

I also tried P8-MGMT instead of the interace list MGMT. No go.

I have trouble figuring out with Linux firewalling when the different chains are active. Like if I have P8 is my management interace, and I want to block all incoming traffic from all other ports. Is that a forward rule? Is P8 the input port or the output port? I tried both ways and neither worked.

2

Why would you want to block hte management off bridge access port?
Just disable the port in ethernet interfaces …poof gone.

3

First of all, the filter chains:

  • input handles traffic that is headed to the router itself (e.g. management like winbox, DNS - when served by the router, etc.)
  • output handles traffic that is generated by the router itself (e.g. response packets to any sort of request, DNS requests the router itself makes, etc.)
  • forward handles traffic that the router - well - forwards, that is: it’s neither the one who the packet is destined to, nor the one that originated it - it only facilitates its movement across networks it’s connected to. Other than providing certain services, providing for management functionality, handling this is what the principal job of a router is.

As I mentioned in one of my earlier posts to you, firewalling and related tasks are handled by the Linux netfilter framework. This is the one that handles the majority of traffic on the Internet, even your favorite cloud services like e-mail, etc. so it can be said that it’s pretty well established. Mikrotik has added some useful functionality to it and customized it somewhat, but regarding the basics you get a mostly direct interface to configuring it. You will eventually have to familiarize yourself with the “packet flow”. All the important decisions are succinctly visualized in this oft quoted diagram: (Just disregard the “security” boxes, they’re not used by the majority of the world, only those using the SELinux extensions.)
https://stuffphilwrites.com/fw-ids-iptables-flowchart-v2024-05-22/

Closing tips:

  • every single packet traverses the filter chain - so to understand what you want to do or actually are doing, don’t be afraid to imagine a packet and trace it through the firewall (if no one sees you doing it, don’t be afraid to use your fingers :slight_smile: )
  • every firewall rule in MT has a “log” option, which - unsurprisingly - logs the packets that the rule matches. This is very useful for discovering what exactly is happening. Also, filter rules have a “passthough” action which only matches but otherwise doesn’t alter the packet’s path. You can use this to log or count certain packets.
  • if you follow my advice in the other thread: use a firewall that has a “deny all” at the end of the input and forward chains. This way “how to isolate” becomes “what do I want to allow to cross”, which is much easier to do. If the answer is “nothing”, then you add no such rule and the traffic will be dropped.
4

Because nobody else should be able to get into the management network. That’s what management networks are for.

I don’t want to disable the management interface because it is there to - wait for it - manage

5

But its blocked by default…
Only certain subnets decided by you are part of the management interface.
Only the management interface list has access to the router config.
Only the management vlan and offbridge port are part of this list.
You can even narrow down the interface list further by a source address list if required ( other people on trusted subnet should not require access etc.)

THe management off bridge port is already not accessible to anybody else on layer 2 as
a. its not on the bridge
b. all the other subnets are in vlans
As for L3 firewall rules, as lurker points out, since your last rule in forward chain should be:
add chain=forward action=drop comment=“drop all else”

Then the admin rules you add above this rule are ONLY FOR needed traffic, as the rest of the trafffic is therefore dropped!!

6

Well right now with the config above I plug into one of the bridge ports and I can access Winbox at 10.0.254.1 which means it is not blocked by default. I’m trying to figure out how to block all traffic to that subnet. But I see what you are saying about my last rule in the forward chain should just drop so I’ll look at doing that.

And to lurker888 yes I know I need to learn how it works - and i’m doing reading on Linux firewalling and looking for a good course on LinkedIn learning. This is quite different from most firewalls I’ve ever dealt with. In the meantime some help would be appreciated.

I’m simply trying to block all traffic coming into P8-MGMT, but allow me while connected to that port to go anywhere I want. I’m not clear on why the forward rule I set up didn’t do that.

7

Thats how I setup all of my devices.
A port is taken off the bridge
It is given its own IP address
Its added to the management interface list and LAN interface list (normally so it can access internet if need be)
DONE!
/ip address
add address=192.168.210.1/30 interface=etherX network=192.168.210.0 { /30 → ensures that only one valid IP can be used to enter port 192.168.210.2 }
/interface list members
…
add interface=etherX list=LAN
add interface=etherX list=MGMT
add interface=VLAN-MGMT list=MGMT

++++++++++++++++++++++++++++++

Assumes my other standard setup items:

(input chain)
add chain=input action=accept comment=“admin access” in-interface-list=MGMT
(forward chain)
add chain=forward action=accept comment=“admin access” in-interface-list=MGMT out-interface-list=LAN

/ip neighbours discovery
set interface-list=MGMT

/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=MGMT

Since the last rule in my forward chain is found below, no traffic to the offbridge port is permitted at Layer 3.
add chain=forward action=drop comment=“drop all else”

8

Here goes…

Let’s examine the “should not happen” case that you cite and work our way to a solution. Note that in your example (access to management interface from non-management port) the traffic does not even involve the management port in any way.

First of all, you should be aware of the fact that even though when you assign an address to the router (as far as I can tell 10.0.254.1/24) you specify assigning it on an interface (P8-MGMT), this interface does not own the address in the sense that the router will be happy to receive (and reply to) packets destined to this address coming in on any of its interfaces. (This is btw what’s called having a “weak host model”; I’m afraid that for such a fundamental networking concept no really good internet sources exist for what this exactly entails, but the gist of it is the previous sentence.) So some other way of restricting this traffic must be employed. Many services (including winbox) allow different filtering options, but in my opinion filtering connection attempts that are clearly not allowed in the firewall is just good practice.

Note that according to the above explanation about the “weak host model”, this also entails that unless the given service takes other precautions, once enabled, e.g. winbox is not only available on the 10.0.254.1 address, but on any other addresses the router possesses.

So where in the firewall? Simple: packets which are destined to be received by the router itself traverse the input chain (not forward).

So the appropriate rules are: (WinBox works on tcp/8291)

add chain=input action=accept in-interface-list=MGMT protocol=tcp dst-port=8291 comment="allow winbox from mgmt"
add chain=input action=drop protocol=tcp dst-port=8291 comment="drop winbox coming from anywhere else"

Note that rules are executed in strict order. Once the fate of the packet is decided by an action such as accept/drop, the processing ends there. (Some actions, such as fasttrack, mark-connection, etc. only have a side effect and processing continues.)

Now this works specifically for winbox. You can image adding ssh, webfig, webfig-ssl etc.

Generally it’s better to allow specifically what you want and drop the rest. This is doubly so for the input chain: whatever services run on the router (or will be added perhaps in a later update) shouldn’t be accessible by default, only the ones you specifically allow. Now our input chain looks something like this:

add chain=input action=accept connection-state=established,related
add chain=input action=drop connection-state=invalid
add chain=input action=accept protocol=icmp
add chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN comment="allow dns udp from anywhere but WAN"
add chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN comment="allow dns tcp from anywhere but WAN"
add chain=input action=accept protocol=tcp dst-port=8291 in-interface-list=MGMT comment="allow winbox only from MGMT"
add chain=input action=accept protocol=tcp dst-port=22,80,440 in-interface-list=MGMT comment="also allow ssh, webfig, webfig ssl only from MGMT"
add chain=input action=drop

This - as the comments say, allows access to the built-in DNS server from any of your network, except WAN (DNS uses both UDP and TCP), and allows certain services only from MGMT. Of course you may want to customize which services and from where you want to be available.

If you decide to simply allow everything from the MGMT interface(s) - which is a perfectly valid way of thinking, after all the management port is trusted implicitly, you can simply use one rule for the management part of things:

add chain=input action=accept in-interface-list=MGMT comment="in MGMT we trust"
9

Thank you both I’ll be reviewing both responses a bit later today.