Anyone got any ideas on how I can verify if I already have “deny all” rule set up with my Mikrotik firewall? If not I would like to set it up.
Attached a picture that shows the firewall settings page. I cant see details in items 22 and 23, but i think this might be related to “deny all” rule. Is there any other way to check?
Rule 23 is definitely not a “deny all” rule – it only denies traffic that matches the specified source address list.
Rule 22 “looks” like a deny all rule, but it’s impossible to tell from a Winbox window whether or not there are additional conditions set in columns that are not selected.
To tell for sure, you have to do:
/ip firewall filter export
in a Terminal window and make sure there are no additional conditions of any type.
The MikroTik firewall behaves as if there is an ALLOW ALL rule at the END of each chain.
I would recommend you to explicity add an ALLOW ALL rule at the end of each chain if you do not already have it, then see what the traffic counters do, and if not to wild then add the logging option for that rule.
Now you can see what it is accepting, maybe restructure your firewall so that there is no wanted traffic showing there, and then finally change it to a DENY ALL rule (and probably remove the logging).
Just blindly adding a DENY ALL to a MikroTik firewall will typically lock you out of the device, because the default firewall assumes that anything not being denied is explicitly accepted at the end.
Curious… this is the opposite of the advice I have always heard, which is to craft firewall rules to explicitly allow the traffic you want to allow, then “deny all” at the end. Almost invariably for the input chain, and perhaps for the forward chain as well, depending on your application.
(In my case, the forward chain is an “accept all” because forward is only used for subscribers who pay for public IPs, and it’s up to them to firewall themselves.)
Certainly you don’t put the “deny all” at the beginning, so as to lock yourself out of the router… but at the end it is certainly appropriate. Putting an “accept all” at the end even temporarily (or leaving the implicit one) opens you up to a lot of exploit traffic you may not have expected.
Sure that is the end goal of the rule set, I also use that method all the time.
But: the default behavior of the RouterOS firewall is to ALLOW ALL, so when a chain has no rules at all it will allow everything.
You would typically fill the ruleset with an ALLOW established/related, an ALLOW of the traffic you want, and a final DENY.
However, the default firewall rules in RouterOS do not have ALLOW for all the desired traffic but a DENY of all traffic NOT originating from LAN.
So, when you add a DENY ALL rule at the end of that, without first adding some more ALLOW rules for management etc, you will have locked yourself out of the router!
That is why I wrote my recommendation to FIRST add an ALLOW ALL to SEE what it is catching, so you can add some more ALLOW rules before that until it catches nothing, and only THEN change it into a DENY ALL.
Tried exporting firewall filter and nothing came out for line 22 instead, a bunch of blocked IP came out for line 23. @macsrwe like you said its definitely not line 23.
I will try exporting line 22 again tomorrow. But looks like either its already “deny all” so nothing came out or im doing something wrong.
The point is that we have no clue as to the configuration of the router and especiallly the full set of firewall rules.
So if the OP actually wants to make progress!!
/export hide-sensitive file=anynameyouwish
As for pelchi, yes the default setup is safe enough in that it blocks unsafe traffic out of the box and thus the
'‘open’ rules setup works.
However, as soon as one realizes that
a. unfettered access by all users to the router is not the optimal security setup
b. unfettered access by all users across subnets or vlans is not the optimal security setup.
THen the OP should change to a drop all schema for both input and forward chains.
Where I do agree with you is that those two drop rules should be LAST in any config and should be reviewed to
ensure one has setup access to the router and in the forward chain as desired by at least the ADMIN.
This is actually a natural evolution for a new user. As they get more comfortable and knowledgeable on the router, they will then have the skills to modify rules a bit at a time.
I guess this is a consideration for someone who is going to be starting with today’s “default ROS rules.” When we had to create the standard rules for our network, ROS didn’t ship with any firewall rules at all. Since then, we’ve been provisioning new routers with our own configuration set after removing the default configuration entirely. Most of them are CPEs, which accept admin-type commands only from the “WAN port,” just the opposite of a home router; and others are multidirectional routers with real no “WAN port” or NAT. So I always envision someone starting from scratch with am empty rule set, which may not be the case today.
When you export the rules, use verbose. Otherwise a rule that has only default values tends to be printed with no contents (e.g., “add;”).
How do I access verbose?
@anav Here are some other rules
You are using webfig or WInbox. These are handy tools, but do not provide complete information on your configuration.
Either use a Terminal window in Winbox, or ssh into your router to obtain a native terminal window.