Community discussions

MikroTik App
 
FIPTech
Member
Member
Topic Author
Posts: 494
Joined: Tue Dec 22, 2009 1:53 am

Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 1:32 am

For security reasons a Management Vlan should not be routable. There should be a setting for this in the router (and Mikrotik switches too) to avoid routing between other interfaces and the management VLAN interface.

This is a security measure that protect the management VLAN from been accessible from other VLANs, if the routing or firewalling is not done correctly.

The same as a voice VLAN is special because it does advertise voice through LLDP-MED, (for phones VLAN autoconfiguration), a management VLAN is special because it must not be reachable from other subnets sitting on other vlans.

Ideally an admin connect with its laptop anywhere in the company and he is identified through 802.1x by the switch he is connected to, then he is directed to the management VLAN by a radius server request / answer.

From here he get an IP address from this VLAN subnetwork and can manage all hardware sitting in the management VLAN.

If you study Procurve L3 manageable switches (i suppose it is the same for other brands), you will find that there is a setting to declare a VLAN as the management VLAN. As soon as you put this tag on it, it is not L3 routed anymore even if L3 routing is enabled in the switch.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1130
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 7:39 am

And your question is?!
What exactly prevents you to configure what you describe?
 
User avatar
vecernik87
Forum Veteran
Forum Veteran
Posts: 772
Joined: Fri Nov 10, 2017 8:19 am

Re: Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 8:30 am

There should be a setting for this in the router (and Mikrotik switches too) to avoid routing between other interfaces and the management VLAN interface.
There is such setting:
/ip firewall filter add action=drop chain=forward place-before=0 out-interface=vlan-mgmt  
Obviously, replace the vlan-mgmt with correct name for your management VLAN. This will work in any firewall, but it will also prevent your management VLAN talking to the internet. Ideally, move it just beneath your "accept established/related" rule.

On the other hand, I can't fully blame you because this is caused by faulty default/factory config included in current (v6.47.2) RouterOS version. Let me explain:.

Default config currently contains following "forward" rules:
/ip firewall {
   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-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
}
(i removed the "input" chain, because it is irrelevant in this context, however, it suffers from the same issue)

With a brief look at it, it seems fine - Accepts data from/to ipsec tunnels, accepts/fasttracks established connections, drops invalid and drops new from wan which are not DST-NATted.
As long as you don't touch your settings, it will be fine. But adding any other interface means, that it will be open to forwarding from anywhere except WAN = not secure by default.
Currently, people have to make an effort to secure their router, which is implicitly insecure.
This approach is something, what I personally strongly disagree and I believe that every interface should be by default secured. Everyone who adds interface can also add FW rule to open it as required.
Correctly, an effort should be required to unsecure the router, which is implicitly secured.

I understand it is impossible to change logic of the whole firewall and that's fine (i.e. if there is no rule at all, traffic will flow), but a small change in default rules would have huge impact on security. My idea is following:
/ip firewall {
   filter add chain=forward action=fasttrack-connection connection-state=established,related comment="fasttrack"
   filter add chain=forward action=accept connection-state=established,related,untracked comment="accept established,related, untracked"
   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=drop connection-state=invalid comment="drop invalid"
   filter add chain=forward action=accept connection-nat-state=dstnat comment="accept all DSTNATed"
   filter add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="accept LAN to WAN"
   filter add chain=forward action=drop comment="drop everything else"
}
With this approach, you are explicitly ending your set of rules using "drop everything else". That means you have to whitelist (allow/accept) every single separate type of traffic you want to allow.
If you had this FW as default and you created the Management VLAN, it would be by default secure.

I admit that splitting the last rule in three separate rules may consume more CPU, but the difference will be negligible. On the other hand, security of this approach is much higher than original defconf. I am confident that the trade-off is worth it.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1130
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 10:45 am

I believe there is even simpler way:
/ip route rule add interface=vlan-mgmt action=drop

With this approach, you are explicitly ending your set of rules using "drop everything else". That means you have to whitelist (allow/accept) every single separate type of traffic you want to allow.
With this logic, on the other hand, any new interface - tunnel, vlan, etc - has to be added to interface-list=LAN (or dealt with any other way) for it to work.
Which is much less "user friendly" for home scenarios.
And as we are talking about the "default" firewall, it has to be more suited for "default" users, that are unlikely to have management vlan or untrusted networks in their LAN.
As for any advanced user - there should be no problem to modify the firewall to suit his needs.
 
FIPTech
Member
Member
Topic Author
Posts: 494
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 1:00 pm

I'm not using the default rules, i have a couple interface lists where i put subnetworks interfaces. I have lists for Backbones, Data Lans, Guests, Management, and so on.

Then filtering in firewall is done so that each class do have separate forwarding capabilities.

So in my case there is no problem, if i don't make errors in the firewall rules.


But the default rules, or dynamically created ones, should allow this kind of security at least for the management VLAN, to avoid mistakes at least on this particular VLAN (or physical interface or whatever interface the management L2 network is on).

This is not something i did invent, this is something done by respected switch manufacturers to avoid attacks directed to the management VLAN.

That's why i propose an option that we could simply set for an interface, to forbid it's routing. Instead of a global IP routing flag.

There are many places inside Router OS where this kind of configuration help is possible for an interface. For example ARP options are manageable by interfaces, auto create default route for tunnel interfaces, add routes for PPP interfaces created by users, add PPP interfaces to an interface list, add DHCP leases to an adress list, insert interfaces dynamically in a QOS queue and so on.

This mean that router OS try to help users in many places for a safer and easier configuration.

Another point (but that is another subject), is that a management VLAN should have highest priority at level 2 everywhere so that network administration can be done even if switches or routers are congested, for example because of an attack.. There are good chances that providers or datacenters that do not follow this rule could have problems to easily stop a DOS attack without physically disconnecting ports.In the real life, we can see from time to time downs times during hours probably because of bad network QOS design.
 
FIPTech
Member
Member
Topic Author
Posts: 494
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 2:10 pm

I believe there is even simpler way:
/ip route rule add interface=vlan-mgmt action=drop
I think that this does not forbid IP traffic from another subnetwork interface to enter in the Management Vlan interface IP address if i'm right. It does just block routed IP outgoing traffic from the router management interface IP to reach other networks.

If there is an IP address on the Router for the management VLAN, then there is a dynamic route created for this subnetwork. This is allowing traffic entering the router from other networks to be routed to the Management VLAN IP. To effectively fully cut routing to and from the management VLAN this dynamic rule should be removed. But it's not possible by design.

So if i'm right this will allow unidirectional traffic, but an attack does not necessarily need a return path to be effective. For example a Wake On Lan action does not need an established session. For example a magic WOL packet entering the subnetwork on its directed broadcast IP address for example. (hopefully directed broadcast is disabled n Mikrotik routers, but can be done manually if needed for routed WOL, adding a static ARP entry to generate a L2 brodacast from the directed broadcast subnetwork IP).

So i think that it's better to filter in the firewall forward chain, or even better fully disable routing in the kernel for a management VLAN or other strategic interface that must not be routed at all, bidirectionally.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1130
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Feature Request : Non routable Management VLAN

Wed Oct 21, 2020 2:55 pm

You might be right.

Ok. Another suggestion: putting vlan-mgmt into separate vrf will definitely make it unroutable, unless needed.

Who is online

Users browsing this forum: No registered users and 5 guests