Better default for firewall filter

pe1chl · Fri Apr 08, 2016 10:53 pm

I suggest a change in the default firewall rules for the input table:

Now, there are rules to accept icmp, accept established/related, drop from ether1, then fall off the end into a default accept.
This works fine as long as ether1 is the "internet-facing" interface, because a rule is already there to drop new input.

However, it is a risky default because when people add a new internet-facing interface, e.g. a PPPoE interface or
a VPN tunnel to some anonymizing VPN service, that new interface by default accepts input.
Common problem is the DNS service is being attacked from the internet to be used as DDoS reflector.
However, attacking the configuration interface of the router is also possible when the password is weak.

My suggestion is that after the accept icmp, accept established/related, a rule is put to accept "new" from the
interface designated as internal (often it is "bridge-local", now called "bridge", in some routers it could be "ether2-master")
and then follow that by a drop rule that drops everything else.

Then, when a new internet-facing interface is added it is closed by default. Users have to insert a rule to allow
traffic to the router from a newly added interface, which is much more secure.

pe1chl · Wed Apr 20, 2016 3:28 pm

Hopefully this can be given serious consideration, as the victims of DNS attack keep coming in.

Fri Apr 22, 2016 4:13 pm

While it may sound reasonable at the beginning, it may cause problems in other configurations. Unfortunately we cannot make default configuration to suite all possible scenarios. So if you change WAN interface in default configuration, you MUST change also other relevant parts of configuration, including security settings.

There is no such thing as single button "make my router secure", you must know what you are doing and why you are doing.

sash7 · Fri Apr 22, 2016 6:16 pm

well, default config is not mandatory. i use variant with rule accepted my local interface (bridge-local) and then last rule drop everything. no chance to mistake )

pe1chl · Sat Apr 23, 2016 7:44 pm

While it may sound reasonable at the beginning, it may cause problems in other configurations. Unfortunately we cannot make default configuration to suite all possible scenarios. So if you change WAN interface in default configuration, you MUST change also other relevant parts of configuration, including security settings.

There is no such thing as single button "make my router secure", you must know what you are doing and why you are doing.

I have no problem with this myself, I only watch the loads of naive users who view some youtube movie about
how to get a MikroTik configured for PPPoE and then become a DNS attack reflector and report here that their
connection is 100% loaded and is slow.
When you think it is a good situation that people think that MikroTik routers are insecure and perform badly,
you can keep it as-is. But in general I would recommend a default configuration that matches what is OK and
drops everything else by default. This is better for those that do not really know how it works and copy bad recipes.

Mon Apr 25, 2016 11:32 am

When you think it is a good situation that people think that MikroTik routers are insecure

MikroTik routers are not insecure. User alters configuration and makes router insecure, there is only one configuration change that can fix it. Set admin password and do not let such users touch the router

)

Mon Apr 25, 2016 12:46 pm

For common/ordinary user: DDos susceptible = insecure. If I am ill I do not care if it is flu or sore froat ... I want to be healthy and resistant to them.

We know that the word "insecure" has different meaning but users do not care about it. Their connection is overloaded with no "insecure changes" to the default configuration.

Is this really so hard to block UDP 53 in the default configuration ?
You have added undeletable fast-forward rules (quite annoying decision for some users) so you can add this one. Don't you ?

Mon Apr 25, 2016 3:19 pm

Isn't it like with cars or guns? Are cars and guns dangerous? Or the people use them in the bad way? Normally you need a licence to drive a car or carry a gun. You surely know why. The routers are the same. Every admin should know how to use it, what are the risks and how to prevent them. There are not insecure routers, there are just non educated admins...

Mon Apr 25, 2016 3:51 pm

Who was your post for ?
If for me then please answer the question: Who is the default configuration for ? For admins or for ordinary user ?
Admin should not need this ... but if it is already there then why it couldn't be prepared better to not reconfigure it immediately from default configuration to more ... read to better .... secure configuration for each RB.
Ordinary user could expect to receive secure device as it offers him/her the default configuration. Ordinary user could expect that the default configuration is professionally prepared for common SOHO environment.

Conclusion: The dafult configuration should be extended with few common antiDDOS rules.

pe1chl · Mon Apr 25, 2016 4:03 pm

Is this really so hard to block UDP 53 in the default configuration ?
You have added undeletable fast-forward rules (quite annoying decision for some users) so you can add this one. Don't you ?

I don't think that is the proper solution.
IMHO the proper solution is to invert the rules from what they are now.
I.e. not "allow everything except from ether1-gateway", but "drop everthing except from the LAN (ether2 or bridge1)".

That will solve the port53 problem, and at the same time it will close the router for attempts to find the admin password,
etc.

Mon Apr 25, 2016 4:12 pm

Yes.... it is even better and it fits perfectly into >> "secure SOHO" router for non-admins << strategy.

Mon Apr 25, 2016 4:45 pm

That's right. Drop everything, allow exclusions. Because I am not regular soho user, I would appreciate blank config. I am removing the defaults anyway everytime I power up new device and I am sad that there are staying some dynamic / default things even though uselessly. I have never seen any case where defaults fitted the needs. I understand that someone can start with defaults and then he changes something he doesn't understand enough. But I am very far from blaming mikrotik that it is their fault because they made routers insecure. Not at all.

Mon Apr 25, 2016 4:56 pm

It is not "blaming" ... it is just asking for better default configuration if it is proposed to user.
It is same process as asking for new features and bugfixes in the ROS.

pe1chl · Mon Apr 25, 2016 4:59 pm

Of course I also examine the rules closely, and modify them as required.
But again, this request is not for my personal benefit, but for the benefit of the average user and for the
reputation of MikroTik.
What is distributed has by default an open resolver that is guarded by a specific-drop rule.
That works until a special interface for internet is manually added, e.g. for PPPoE, without modifying
the firewall.
As the firewall config is in a completely different place than the addition of a PPPoE interface, I can
understand how this is going wrong. And it would be easy to fix by using a different, and in general
much more recommendable default of "reject everything except what you know is local (trusted)", so
when a new interface is added it is not wide-open.

Mon Apr 25, 2016 5:57 pm

And what rules do you propose to fix setups where clients adds another lan interface or adds VPN? This is also configured in completely different place and instantly blocks DNS for new LAN interfaces.

I'm sure there are a lot more examples when your proposed solution will cause problems for user.

Current set of rules is optimal, easy to understand so that users can start working with firewall.

If you can think set of rules not complicated to fix problems above I will gladly change set in default configuration.

docmarius · Mon Apr 25, 2016 8:04 pm

There are much more inexperienced users adding a PPPoE interface than inexperienced users adding a second LAN or a VPN. Usualy, in the later case, they are actually not inexperienced anymore and can handle firewall changes.

pe1chl · Mon Apr 25, 2016 8:33 pm

And what rules do you propose to fix setups where clients adds another lan interface or adds VPN? This is also configured in completely different place and instantly blocks DNS for new LAN interfaces.

The big difference is that in these cases the error is noticed quickly because something that should be passed is
being blocked. When a PPPoE internet interface is added and the router is inadvertently left wide open, the
problem is not immediately noticed and later it breaks down because the bad guys have found the open resolver.

Of couse the quickstart has a mode to setup PPPoE and I presume that when it is done that way the firewall rules
are adjusted automatically (no router available at this moment to clear and try this - probably later this week), however
there are "instructions" floating around on internet, especially in the circles where PPPoE is needed, that explain
the creation of a PPPoE interface but do not mention this critical step.

freemannnn · Mon Apr 25, 2016 10:39 pm

quick set for pppoe should change the default drop input firewall (input interface) from ether1-gateway to pppoe-out1.
i was one of the unlucky guys having 100% cpu usage from dns attack! (at my first steps with ros)

Zorro · Tue Apr 26, 2016 12:45 am

whitelisting most essential services access(from FEW present/accesible from WAN interfaces)always not bad idea.
as for DNS amp and NTP amp attacks - usually affected devices/hosts - do even more dammage to other routers in internet, than suffer themselves. that aside CPU and RAM stress.

pe1chl · Tue Apr 26, 2016 10:38 am

quick set for pppoe should change the default drop input firewall (input interface) from ether1-gateway to pppoe-out1.
i was one of the unlucky guys having 100% cpu usage from dns attack! (at my first steps with ros)

Did you use quickset to setup PPPoE and did it not set your firewall correctly?
Or did you follow one of those "instructions" and merely add a PPPoE interface to the router without using quickset?

I ask this because I would assume that quickset would do the correct thing, but when it doesn't the situation is even
worse than I imagined...

Tue Apr 26, 2016 11:30 am

It is not possible to satisfy everyone and make perfect configuration for any possible case.

Default firewall at the moment is correct and does everything what is necessary for default configuration.

As soon as you change something it is you responsibility to adjust rest of configuration except cases when you use QuickSet.

If you use QuickSet, then firewall is automatically adjusted and WAN interface from ether1 changes to tunnel.

You can always use Flashfig and put another configuration on devices by default:
http://wiki.mikrotik.com/wiki/Manual:Flashfig

freemannnn · Tue Apr 26, 2016 12:39 pm

I was a newbie and use quickset. Now i dont use quickset

pe1chl · Tue Apr 26, 2016 3:42 pm

It is not possible to satisfy everyone and make perfect configuration for any possible case.

That was already stated, but still the default configuration should not leave gaping holes when newbies configure
the router...

Default firewall at the moment is correct and does everything what is necessary for default configuration.

As soon as you change something it is you responsibility to adjust rest of configuration except cases when you use QuickSet.

If you use QuickSet, then firewall is automatically adjusted and WAN interface from ether1 changes to tunnel.

That is great, but apparently a lot of newbies don't use quickset and instead follow incomplete instructions they
find on forums or youtube

Again for clarity: this is not a request for my own benefit. I know how to handle these things.
It is a request for the benefit of newbies and MikroTik, because it is easy to get a reputation of delivering bad
or insecure products, and not so easy to get rid of that. It is better to have a configuration that is too secure
than one that allows abuse or worse.
(note that the same users that do not modify their firewall maybe do not put strong passwords on their routers
either, or do not set the password at all. once they are all part of a "MikroTik botnet" you will have a tough time.

Thu Apr 28, 2016 4:37 pm

If you can think set of rules not complicated to fix problems above I will gladly change set in default configuration.

As ROS just received new funcionality calld "interface list" the new default router configuration ought to use them.
It will be so easy to make the new eg. PPoE interface and just include it into particular IN/OUT interface list and all related rules will cover it.
No more copying rules, spying for configuration "holes". Simple and easy.

My proposition is:

1. Block everything for WAN -> LAN direction
2. Accept WinBox from WAN & LAN interface lists
3. Accept all for LAN -> WAN direction
4. FastPath rules ... they could be defaulted but let us disable and remove them without need to reset all configuration

Thu Apr 28, 2016 4:43 pm

Default configuration cannot add user created pppoe interface to wan address list, because such interface does not exist during reset.

Winbox will not be accepted on WAN port because of default username and no password.

You already can disable fasttrack rule without resetting configuration. Just go to firewall select rule and click disable

Thu Apr 28, 2016 5:38 pm

Default configuration cannot add user created pppoe interface to wan address list, because such interface does not exist during reset

But user can add just created interface to default rules....My English should be better

There should be default in-interface-group list and out-interface-group list. All rules should use these lists as sources, targets etc.
If I add the new interface I need only to put it into particular interface groups and ... voila ... all rules cover new interface.

Thu Apr 28, 2016 6:09 pm

Interface group?
Is this in the RC releases or something? That's awesome.

As for original topic, I would say that the default configuration IS a default-deny list --- for ether1 interface. It's a bit grey because of the nature of the input chain / forward chain / output chain behavior (which I love).

Personally, I side with Mikrotik's stance on this because it comes out of the box as a default deny policy on the WAN. A default deny on all INPUT would just lead to another etreme FAQ issue - "I added a new network to my router and cannot get DHCP working on this new network."

Perhaps if there were a new rule after the "default deny ether1" rule - "Default deny public IP source address" - I can see problems with that too, but I think those would be much less common.

Fri Apr 29, 2016 11:07 am

Default configuration cannot add user created pppoe interface to wan address list, because such interface does not exist during reset
But user can add just created interface to default rules....My English should be better
There should be default in-interface-group list and out-interface-group list. All rules should use these lists as sources, targets etc.
If I add the new interface I need only to put it into particular interface groups and ... voila ... all rules cover new interface.

Then again it requires user configuration in the list. Do you really think that user which does not know hot to add simple rule to protect his new port will know where to find this new interface list?
Of course it is easier to just add one interface to the list for those who knows about such feature and and we consider using the list in defconf however it is not going to solve the problem you initially described.

Fri Apr 29, 2016 11:23 am

Then again it requires user configuration in the list. Do you really think that user which does not know hot to add simple rule to protect his new port will know where to find this new interface list?

Yes. Especially if she/he could add PPoE interface.
Adding interface to interface group which is already covered with firewall rules is much easier than creating firewall rule for particular interface.
There is no magic with Add/Select interface-group/Select interface/Apply. Creating Firewall rule requires knowledge of in/out/forward/input/output etc ... for ordinary people THAT IS MAGIC

Zorro · Fri Apr 29, 2016 10:12 pm

aside tweaking(and possibly bloating/expanding)"deafult config" template/setup, advised by topicstarter, which i cannot wholeheartly support(but quite understand both feelings and thoughts behind. and probably experience aswell), but i do admit that improving security of products are one of most important things in networking(aside survivability and manageability improvements), so further improved PSD, integration of IPS/IDS feats(fwsnort should be good option. low-overhead, simple, yet functional. to start make "alike" to merge into ROS). one of competing vendors for example - put nDPI in firmware, another - packed (not simplifield, netfilter-atop only, but full-blown)snort, which is kinda too bloated for mipsbe SoC and 1/2 of Tile CCR's in usual load/throughput.
so packing more conntrack helpers, updating netfilter, kernel, readying ROS to embrace/integrate nftables feats, packing some firewall code from ROSAlab and Gentoo community(Mageia and PCLinuxOS proposed handy tweaks and additions/plugins aswell. PCBSD and OpenBSD stuff kinda incomplete as usual, but quite ambitious. but "aiming high" i was more like dragonflyBSD, both for secuirity and scalability(and NetBSD had elegancy and simplicity, that others may lack somewhat) and HaikuOS, especially for personal/desktop usage.

so bottom line:packing more "security-centered" features into ROS and making WinBOX aware about them to manage are totally cool. and moving upstream in linux, bsd, and networking stacks you notice that there was Several improvements. but packing "oversided defaults" not really flawless idea. there was always "sweet spot", balance between.
(nftables borrow some pfilter feats and bits from other projects. but i don't really prefer stock syntax over netfilter/iptables, despite "obvious" readability.)
so future ROS(RouterOS 7.0 ?)may had bits of IPS, new firewall(or even several of to choose from).
there was several "big things" each Upstream cycles in each area of development. several "port security" feats adjaced to 802.1x-2010 and alikes that aren't part of IEEE/ANSI standards(sadly), but yet well-made.
personally i missed few things in ROS: 1. lack of native agents for popular management(you name it. nagious, zabbix, cacti, etc)but Dude improvemnts and moving with neflow toward Standard variant(from cisco fork)totally cool thing. 2. more configurable(fine-grained control for) PSD. 3. more serious and less penetrable firewall, like say Zorp(which also more functional and extensible).

docmarius · Fri Apr 29, 2016 11:52 pm

I think nobody bothered to actually read and understand the proposal. It's no bloat, just a paradigm shift improving security.

Instead of "accept connected and related, allow all new except ether1" it was proposed to be changed to "accept connected and related, accept new only from local bridge".
In a default configuration, the behavior is identical. It would just protect newly added interfaces from being left wide open by mistake, treating any added interface as a WAN, not a LAN connection. This happens more often, by adding a PPPoE interface required by a lot of providers, than any other scenario.

What I don't get is why is there such opposition? Most of you will not use the default configuration on advanced setups and you will not be affected by the change. Or if you do and add an interface, it usually is a WAN interface for a customer CPE, and that behavior is the desired one, making your life easier, not harder. And of course, for newcomers, it has the advantage of keeping them safe.
Remember the DoS/Winbox issue on ROS 5? And what about the current DNS amplification exploits? This new paradigm could prevent similar issues in inexperienced users.

Sat Apr 30, 2016 12:09 am

What if the default configuration were to include a disabled pppoe1 interface connected to ether1-gateway, and this interface listed as a default-drop interface in the default input/forward chains? The typical novice user would simply enable the interface and enter their credentials. If they rename it, then it's going to pull the firewall rule along for the ride. Only if they remove it and create their own new pppoe client interface will it break the default.

docmarius · Sat Apr 30, 2016 12:17 am

This would actually complicate things a lot by assuming that user actually knows these details beforehand.

The first proposal keeps the firewall rules to only 3:
1. accept established, related
2. accept new from bridge-local
3. drop all (obvious and explicit - easy to grasp)

versus current variant (if I remember correctly):
1. accept established, related
2. drop new from ether1-gateway
3. drop invalid (noob: what the heck is this?)
(4. default accept - to understand this, the new user must actually know that the default rule is accept)

So it is, let's say "minimal invasive". And it has a healthy "drop all" at the end, which is standard best practice.

pe1chl · Sat Apr 30, 2016 12:06 pm

I think nobody bothered to actually read and understand the proposal. It's no bloat, just a paradigm shift improving security.

Instead of "accept connected and related, allow all new except ether1" it was proposed to be changed to "accept connected and related, accept new only from local bridge".
In a default configuration, the behavior is identical. It would just protect newly added interfaces from being left wide open by mistake, treating any added interface as a WAN, not a LAN connection. This happens more often, by adding a PPPoE interface required by a lot of providers, than any other scenario.

That is right, that is the intention of the proposal.
Not to complicate things, not to suggest that this new default is the be-all-end-all of firewalls that never has to be
modified by the admin, but only to have a default firewall that works and keeps working when typical changes are made
by the newbie user who is not yet aware of the importance of the firewall and net security in general.

It does not really matter that the user is to blame or the posters of the bad instructions (not using quickset but
add PPPoE manually) are to blame, it would be easy to prevent these mishaps.

And just look on the forum, there are several threads from victims of DNS attacks, so this is real.

Zorro · Sat Apr 30, 2016 1:30 pm

i don't think present config is good in terms of "bridging anything" lan-side. aside simlicity its not secure too.
as for "stock rules" - naked conntrack is ~ penetrable regardless what you put into. sadly.
so far "dropping anything not established on wan"(and "related" maybe) in input/forward chain is quite coommon/popular thing and accepting "new" lan-side not change anything a lot.
instead of combo of 2+2 rules with (respectively) accepting then and then "dropping rest" that not fit into, you may simply "drop anything that not" in 2 versus 4 rules if you care about simplicity/short config too much.

docmarius · Sat Apr 30, 2016 3:41 pm

so far "dropping anything not established on wan"(and "related" maybe) in input/forward chain is quite coommon/popular thing and accepting "new" lan-side not change anything a lot.

Oh yes it does. Adding a WAN interface without adapting the firewall rules will not expose the router and the LAN to the internet (assuming the rules are duplicated in the input and forward chains). Incoming WAN connections will remain blocked, in contrast to the current set, where they are allowed by the default rules (because the new interface name will not match the WAN drop rule).
This is the issue which we try to address with this proposal: the behavior on WAN interface additions, not an existing working static default setup (which works perfectly as it is, for the given default configuration).
The fact that a certain setup is popular doesn't make it necessary the right choice in this case, where an (uninitiated) user intervention can break things...

To clarify:
Rules:
1. accept established, related
2. drop new from interface "ether-gateway"
(3. default accept)

Now the user adds an interface called "ppoe1" is proud that he managed to startup his Mikrotik, is happy his internet connection is working, and pays no attention to other details.
Any incoming connection via pppoe1 will hit the default accept rule, making rule 2 de facto useless, since there is no traffic on "ethernet-gateway" except PPoE, which will be accepted anyway because of the PPoE client running on ether-gateway. So, under these conditions, there will be default access to webfig, winbox, ftp, ssh, dns (remember, we have the default setup and those are active) and any other possible open service. The forward chain is not affected, since the usual masquerading acts as a firewall.
Under the new proposed rules, incoming new connections will match the 'drop all' rule keeping the router secured, without any other side efects.

Sat Apr 30, 2016 11:26 pm

So, under these conditions, there will be default access to webfig, winbox, ftp, ssh, dns (remember, we have the default setup and those are active) and any other possible open service.

With no password till the proud admin changes it.