I see people using firewall rules to secure the administration of the router but there is also settings that seem to do the same thing such as …
System->Users->Allowed Addresses
and
IP->Services->Available From
Those settings seem to do a pretty good job of securing the administration of the router. Currently I’m using only those settings and no firewall rules to accomplish this. Is that bad?
I’m using both, better be safe than sorry.
1 Like
They are not equal and if you fail to use the firewall rules, you end up making the router open to the internet. In other words infinite access to try different combinations to hack into the router of username, password and IP address. You should of all people understand that security is best served in layers of defense. The firewall rules are one important aspect of that defense layering. Use it!
1 Like
The firewall is better used to control inbound access from the Internet, whereas the IP-based filtering is better at controlling which of the LAN clients gets in.
That’s not to say you couldn’t do it the other way around or in a WAN-and-LAN combo. 
Belt-and-suspenders, right?
Also consider this: not all MT devices run a firewall. Switches are a prime example, because they’re trying to keep bulk traffic off the CPU. Here, your only other alternative to IP-based filter lists are bridge filter rules, which are not 100% equivalent to the software firewall.
1 Like
Your question is actually a pretty good one. Your understanding is correct that the two approaches (configuring the services individually or using the firewall) are nearly equivalent.
I usually use the firewall. My reasons:
- The software that runs the firewall (netfilter) is one of the most used bits of security all over the world - it secures (almost) every cloud service and has an excellent track record. When using the “allowed addresses” thing, it relies on the given service to be correctly programmed - I have no reason to suspect that this is not the case, but if you rely on something for security, there are levels of “sureness”.
- Mikrotik routers have many services, and it’s up to the admin to disable/restrict each one. Doing this in the firewall enables you to allow what you want, and block everything else by default. Doing this one-by-one is a bit like playing whack-a-mole. I mean just listing the things that could be enabled is tiring: uPnP, SMB file sharing, PMP, the list just goes on.
- The firewall actually has many more features. Of course if you’re only restricting things by address, this doesn’t really add anything.
It’s useful to know that “port scanners” usually show the service ports open, even when access is restricted in the “allowed address” way. This doesn’t affect security, but often leads to erroneous reports and unnecessary worry.
1 Like
Typically what I do is
a. list subnets in IP services for winbox that will require access ( could be management vlan or trusted vlan, wireguard etc.
b. Ensure I use interface list for Management and only trusted subnets are allowed as list members
c. ensure I have a firewall address list of authorized users to access config.
→ Only authorized users OR authorized users on trusted interface list have access to input chain on router ( granular IP control ).
Trusted Interface list is used to limit access to winbox by mac address approach. ( tools mac winbox server )
Trusted Interface list is used to permit access to all attached MT devices in the network (neighbours discovery)
Last but not least is admin user name and password.
++++++++++++
default winbox port not used
default password not used
default username not used
+++++++++++++++
No external access to router, only via VPN.
Idea is to minimize any access to config router.
Next step is to try add in 2FA,
1 Like
Agreed. I am a “lock my car in the garage” kind of guy so both is better. But my firewall rules (that you all helped me write in the other topic) do block everything going in to the router that is not originating from my LAN if I remember correctly. So my firewall should be blocking all access to the router from the WAN side.
So then all I have to worry about is the LAN side and since I am on a small home network I’m not too worried about that. I use the settings to allow only the subnet of my personal LAN and thus block my guest LAN. If you are on either LAN you are already in my house so… I have bigger issues.
Do you think I should still have a separate firewall rule also blocking everything except the personal LAN?
Basically how far you go with the “belt and braces” is totally dependent on you. Usually one method is enough - if done properly.
Guest networks are specifically created to provide an isolated non-trusted zone. So this is usually treated as hostile, so for this network no management access is granted. In fact only the most necessary services should be available: dhcp, dns and icmp. (Dns if your router provides dns to the clients.) All other services should be unavailable. This is a surprisingly long list: smb, ftp, telnet, ntp, etc. - this is why it’s good to focus on what’s allowed instead of what’s blocked. This is easy to do in the firewall, but much more error-prone in the many places where services are configured.
Basically a guest network is a LAN, but from a security perspective it’s not trusted - in a way it is a LAN, but not your LAN.
1 Like
And we have a nice tutorial by tangent on how to make a Guest WiFi that is isolated without needing VLANs:
https://tangentsoft.com/mikrotik/wiki?name=Isolated+Guest+WiFi+Sans+VLANs
2 Likes
The important thing to realise is that using the ACL under ip services or system users - that is an ACL placed in part of the auth process not a network level restriction. This means the services (web server, winbox port etc) are still actually open to the world. When there’s a 0-day exploit, even with the ACL’s placed they can still be attacked - there was a way to pull the user/pass database via winbox a few years ago as long as it was listening.
Point is, definitely want to use input filter deny rules to make sure they cant even access the control plane.
2 Likes
Naive, is to expect users on your subnets to be perfect users. Anyone is one click away from compromising your network and thus, only the admin should have access to the router for config purposes…in other words, sure if you have one subnet then just let the users access to needed services like DNS but only you by IP address (static set on dhcp leases, or wireguard remote device) should have access on input chain to config.
1 Like
Sounds good. I agree.
So now, it would seem, that I have to create a few additional rules to allow only my LAN1 access to the device.
On my setup I (currently) have 2 separate bridges with bridge1 being the default bridge that is setup completely default as it comes from the OEM. Then I have bridge2 that is an exact copy but everything is just named “2” after everything so bridge2 and LAN2.
The pertinent FW rules I have are …
interface lists I have LAN & WAN. bridge1 and bridge2 are on LAN list so effectively all rules that pertain to LAN pertain to both LANs.
LAN to device
this allows everything from source “in interface list” of LAN to access the device
LAN to WAN
this allows everything from “in interface list” LAN to list WAN.
So it would seem the thing for me to do would be to …
-
Create a new interface list of LAN2 … then add bridge2 to that interface list and remove it from LAN list.
-
create a new FW rule on input chain that allows LAN2 to device that allows only 53, 67 & 68 for DNS and DHCP.
-
create a new forward chain rule that allows LAN2 to WAN similar to my existing one for LAN1.
Would that do it?
You seem to be getting the gist of the advice correctly, and what you propose is very much how it’s done!
Just two niggles:
- I would give LAN2 interface list a more descriptive name like GUEST or UNTRUSTED
- Regarding the ports: DNS uses both UDP and TCP. And… i hate to bring this up, but DHCP is special - because of reasons
- and the normal firewall rules are unnecessary. They don’t hurt either.
Anyway, good luck and looking forward to seeing the config you come up with.
1 Like
Just another note: MAC-based access (MAC Winbox and telnet) is set up based on interface lists, so be sure to set that to LAN1 only. The same is true for Mikrotik’s discovery protocol (in IP/Neighbor)
1 Like
OK so it looks like I did the following…
- created a new list LAN2 (for now)
- created a rule on forward chain, that allows in interface LAN2 to WAN (seems to be working)
- created 2 rules on input chain, for DNS with dst port 53 UDP and another one for dst port 53 TCP
So your saying I don’t technically “need” to create a rule for the DHCP?
Sounds fine.
DHCP is special in that it has the ability to catch packets before the firewall - this is because DHCP requests are often not “proper IP”. For example for a client that is yet to acquire an address (duh, that’s why it’s doing DHCP) the source address is commonly 0.0.0.0 - this obviously creates certain issues. The client will also not respond to ARP.
The definitive FAQ is this (particularly the boxy part about firewalls)
https://kb.isc.org/docs/aa-00378
Of the common protocols, only DHCP behaves like this. Many don’t even notice this: when you configure a dhcp server on an interface, you usually want it to be accessable on that interface.
Mikrotik’s in-house MAC protocols and discovery also do this, so care should be taken to set the proper interface list. For you, that’s LAN1.
1 Like
OK, all done. Everything appears to be working fine. Thank you all for your education and help and special thanks to lurker888 for hand holding there.