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.
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.
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 )
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.
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 )
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 ?
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…
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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…
)