Hello again.
No i’m wondering about firewall, how it is working and what is enough. What is necessary and what is not. It’s is easy to make very long list of firewall rules, but what is really overkill, unnecessary?
If we look an example from Mikrotik documents, “Building Your First Firewall”, we can find this to protect the router itself:
Of course address list should be correct.
This list is nice and short!
I would like to know what are the threats not covered with this setup?
After this there are more rules to protect LAN devices, but at this point i would like to know is that set of rules really enough to protect the router?
Never copy firewall examples without understanding the rules. You do not need ANY such whitelisted IP addresses normally, because access to your router should not be allowed from untrusted networks (the internet side). Normally this “allowed access to router” list must be zero entries long, and access to router should only be via IPsec encrypted VPN.
Oops, that address list in the end was unnecessary, i guess it was used later in that example to cover LAN addresses.
In Mikrotik examples, bogon addresses were handled in ip-firewall-raw section.
What anav did in his de facto default firewall- post, he was using route with blackhole.
Which one is “better”?
I put in there a consensus, which was use routes not firewall rules, and for ver6 use unreachable, but in vers7 only blackhole is available so that is what was stated.
hoeveten is also not wrong… I put in the simplest application of the intent…
I think the best approach for home/CPE devices is find the QuickSet profile that closest matches your needed config. Then start looking at /ip/firewall/connection to decide if all the traffic is expected; if not, you need more rules. And if the connections view is confusing, you may want to stick with the defaults. I’d add “Firewall philosophy” in 2022 should include consideration of IPv6, there is a separate one for IPv6 – something to consider since IPv6 is enabled by default. Mikrotik has a decent default for IPv6, but certainly you can tweak that in pretty similar ways to IPv4.
But IMO… How you want to manage the rules is a philosophical question, Mikrotik has three approach and the right one depend on how you think about your various “groups of network things”. While the actions are important, it’s how you want to do the firewall “traffic matchers” is you filter/NAT/manage rules is the “first step”. What you’re allowed to match on does vary. But in any rule you use any/all of these things to “find” something a rule action should be applied to:
Directly use “interface name” or “IP address/subnet” in a rule, like “ether1”, “wlan1”, etc. as in-interface (or out-interface)
PRO: this make the firewall very easy to read, since the physical ethernet ports align directly with a rule
CON: if you ever change what a port is used for, you may have to change in/out-interface in a few places.
Indirectly, use an " interface list" like “WAN” and “LAN” in /interface/list to avoid the “con” above. Mikrotik’s defaults, QuickSet and the “VLAN your network” series in this forum take this approach. Basically you write the firewall rules INDIRECTLY uses in-interface-list (or out-interface-list) & very simple with only “WAN” and “LAN” to consider in building your rules
PRO: your firewall rules don’t have to change if you add a new network/subnet/VLAN/etc, you just add it to one of the interface lists (and create new ones as you need different types of rules)
CON: this get more complex when dealing L3-only tunnel interface like Wireguard
Use an “ip firewall address-list” for your subnets (and begons, external block lists, etc. if you want). This is the approach of “Your first firewall” in Help
PRO: This offers the most granularity since you specify anything by IP address, range of IP address, subnets, or even DNS names – internal or external
PRO: Since the firewall deals with only Layer3 IP traffic, the rules align directly with other IP stuff. e.g. not just “all IP traffic that come from port X” as you have when using an interface (since there may be multiple subnet/VLAN/IPSec/Wireguard/etc all going on at together at a Layer1/2 interface
PRO: If you think you’ll ever use Wireguard, you may want to design your firewall rules around “address-list”
CON: While Mikrotik “Help” takes this approach, the RouterOS default config, and forum generally steer you to using “interface lists”.
Any can work. Where I think the trouble comes in is when you mixed all of the above approaches… Generally pick one and stick to it.
But if you want to think in “IP ranges/subnets”, then define a /ip/firewall/address-list for each one, and then use the “src/dst-address-list=” in your rules. Conversely, think about your network as a set of “VLANs”, then assign them to an specific interface lists makes sense, and then use the in/out-interface-list in your rules to match traffic. Don’t want to speak in absolutes, certainly LOTS use cases to mix interface lists with firewall address-lists, but your back to you should problem understand the why…:
Disagree ammo, mainly because its the only way to progress? To much agreement leads to stagnation of thought
If one has a need for more than one subnet described in firewall rules, it makes perfect sense to use INTERFACE LISTS!
The only exception to this rule, I can think of, is the trusted (single) subnet, which you may want to use for INPUT chain rules (winbox access to router ) or forward chain rules (access to all subnets) and more specifically for the entries of neigbhours discovery ( for all managed ‘smart’ devices ) and for tools mac server → winmac server entry.
Where firewall address lists makes sense is if you have IP addresses from a subnet but less than an entire subnet, IPs from different subnets and any mix of these with full subnets in describing a group of users to be addressed in rules.
Oh and just to note a single subnet is best described by either an existing interface that defines the subnet or just use the subnet address 192.168.0.0/24 for example.
Both interfaces (or interface lists) and address lists have shortcomings if used alone. If I have LAN 192.168.88.0/24 and allow traffic from LAN interface (in-interface(-list)=LAN), then anyone from LAN can send spoofed packets with other sources. If I allow traffic from LAN subnet (src-address=192.168.88.0/24) then if someone manages to send spoofed packets with this source from elsewhere, they will be allowed. It may not be a big deal when we’re talking about home routers and such. Chances of any of that happening are small, and in neither case there will be bidirectional communication. But the possibility is there. It’s possible to prevent this using RP filter, but unfortunately it’s currently global thing that works silently without any feedback (so really fun to debug), and it’s not compatible with things like dual-WAN (relatively common config nowadays).
It depends. Interface lists make sense when either interfaces can change (then you just update the list and don’t need to change several other things), or when you need same rules for several interfaces. But sometimes I see configs where people have several VLANs, so they add them all in one interface list “VLANS”, because “that’s how it’s done”, but it doesn’t really help then, because they need different rules for each, so they still need to add extra firewall rules with exceptions, because simple in/out-interface-list=VLANS doesn’t do what they need.
Correct, there is no reason to group vlans into an interface unless its more efficient in terms of firewall rules.
One has a total of 5 vlans, they all get internet and thus since all are part of the LAN interface, then a simple LAN to WAN firewall is needed.
However if only 3 vlans have internet, its efficient to make an interface list called VLAN-INT , then a simple VLAN-INT to WAN firewall rule is needed.
I tend to use both in-interface (or lists) and out-interface (or lists) as well as IP addresses, firewall addresses or subnets, where practical, to be as precise as possible with respect to all rules.
That tends to weed out spoofing etc…
