Hi All,

With the press around DNS amplification we took another look at some of the 'culprits' and of the reality is that any Mikrotik with "Allow Remote Requests" will fall into this category.

Its a simple enough fix - add a /ip firewall rule on the input table blocking requests from non-customer ranges.... but I think Mikrotik should rather take a proactive stance here.

I'd like to suggest the following on Mikrotik DNS - a SIMPLE ACL list.
This ACL should likely use the current /ip firewall address-list for consistency. If a 'allowed' address-list is specified then add a dynamic input firewall rule which matches that.

Would certainly help with some of the issues out there

Thoughts?

I would come at it from the other direction - deny first and permit later. Any internet facing RouterOS should have "drop all" rule in the input chain and above that some specific permit rules for the traffic that is to be allowed. The same approach should be taken in the forward chain on devices which have a "firewall" role.

Most of RouterBOARD products are intended for professionals. And has minimal configuration to allow easier access to the router. SOHO RouterBOARDS have default configuration that can be easily used and is more intended for not so experienced users have default rule to deny all connection from intended WAN port. That is so for several years already. If you have interest in topif of protecting your router you can look up various threads in forums and pages on wiki.mikrotik.com

Is this pro-active enough?

I prefer the way things are done currently.

If I want to protect myself, let me do it, don't do it first and then make me work around it.
This works in the SOHO environment, but not in professional systems.

A good guide to protect yourself is great. I have to admit the Wiki firewall examples/information is lacking a little bit. Perhaps some updates and more examples would be nice.

Most of RouterBOARD products are intended for professionals. And has minimal configuration to allow easier access to the router. SOHO RouterBOARDS have default configuration that can be easily used and is more intended for not so experienced users have default rule to deny all connection from intended WAN port. That is so for several years already. If you have interest in topif of protecting your router you can look up various threads in forums and pages on wiki.mikrotik.com

Is this pro-active enough?

I was simply suggesting that you add exactly that ip firewall rule for the 'not so experienced' users. As you say the platform is meant for professionals but the reality is that most of them ALSO don't implement this.

+1
i was attacked too as my allow remote request was enabled. More used to working on djbdns or bind which are more secure. They should add allowed subnets in their dns server. Moreover in earlier versions allow remote request used to be off by default if my memory serves me right. Now its on by default so making an open resolver (am i right). They should clearly mention on manual or wiki about usage of allow remote request.

1) Allow-remote-requests if OFF by defualt. Wipe all the settings with "/system reset-config no-default-config=yes" (you should always do this) and check for yourself.
2) If you enable it and not secure it by firewall, its your fault you get attacked. Its just like with any other network service.
3) Learn to firewall, and all will be fine.
4) Dont expect professional grade equipment to hold your hand and do things in config for you with one button click. No other vendor does this either...

I think you're missing the point ....

I have no problem doing the firewalling - as we always do - I'm trying to improve usability in a product that is becoming commodity - professional does not have to equal non-user-friendly.

I think you're missing the point ....

I have no problem doing the firewalling - as we always do - I'm trying to improve usability in a product that is becoming commodity - professional does not have to equal non-user-friendly.

As it was pointed out above, default config is already secure. If user reconfigures the device to be unsecure, there is no stopping them.

I guess option to allow remote requests per interface (or per IP range) would do the job. That would allow us to set it on for lan interfaces only and, thus, be most useful, most obvious, and very easy to use.

But hey, if I want it to be easier to use then I am not professional...

I'll risk my own professionalism-factor too and say +1 for previous poster.. It would be very nice feature to be able to enable or disable DNS-server per interface.

What is the difference between these commands (just examples!) ?

/ip dns allow-remote-requests-from=ether2
/ip firewall filter in-interface=ether1 protocol=tcp port=53 action=reject

If we would add the first one, it would be yet another place to look why something is disabled somewhere. In the case of Firewall, all restrictions are in one place. You don't need to cycle through lots of menus just to find why your DNS doesn't work.

We just got slammed by this problem at a remote site. This costs us a fair amount of money to identify and resolve, not to mention the victim. While this product is usually sold to people who know what a DNA AA is, it would seem prudent to have this feature default off, or handled through a UDP Port 53 firewall rule.

The use of the word "Remote" can give someone a clue that this is not Eth port, LAN/WAN specific - but all ports. The typical user will use Eth0 for the WAN, the remaining ones for the LAN. So maybe restrict Eth0 by default....

Its not clear what the gateway Eth0 would need this capability - in most applications. But I do like the flexibility.

We had it enabled because we use static IPs on the LAN, and wanted to avoid having to enter the ISP-specific DNS addresses in each client; now we just enter the gateway IP in clients for the DNS and its resolves. Thus, we only need to change the router's DNS when we change ISPs or DNS addresses - not all clients. But I will fiddle with the firewall rules to restrict new DNS queries from Eth0.

Unless there is another way to have this off, and handle the clients DNS similarly.

Current default config is fine, it blocks anything coming from WAN (I have no idea since which RouterOS version). This one is from SXT, where wireless interface is supposed to be WAN by default: As you can see, incoming packets to port 53 have no chance. And if you do complete reset to no settings, remote DNS requests are disabled completely by default, so that's fine too.

The problem is when users start messing with the config (generally speaking, nothing against you ). And they do, because e.g. forwarding a port is a common thing. Look at the forum how it goes, how many threads about port forwarding troubles exist. Be sure that for every such thread here, there are thousands of users all over the world doing the same and completely messing up their firewall in the process. If they accidentally disable the blocking rule, they won't ever notice, because it won't break anything from their perspective.

So no matter how much secure is default config, it does not mean much. People will break it and MikroTik can't do much about it. Except maybe this older idea could help a little: Feature request: DNS setup for local networks Unfortunately, it did not get any feedback from MikroTik. But if the proposed allow-remote-requests=localnets was used in default config, it would not be so easy to get DNS resolver open to whole world. It would not stop those wanting to do it. But it could not happen by accident if someone was just playing with firewall rules.

Thanks. If I understand, a WAN DNS request would be considered a "new" connection, which would not be acted upon on the input chain, yes?

What remains unknown through is whether enabling DNS "Allow Remote Requests" still accepts port 53 on the WAN port.

We had to shut down the remote router to stop the pain, so I will check how and where we configured the input chain drop.

Greg

Thanks. If I understand, a WAN DNS request would be considered a "new" connection, which would not be acted upon on the input chain, yes?

Yes, but not because it came from the WAN. A LAN-originated DNS request would be new as well. In the input chain, a connection is new because it originated from outside the Mikrotik's brain. A new connection is a new connection, regardless of which interface it originated from.

Remember - there really is no such thing as a WAN or LAN interface. A router is just a "room full of doors" - and it's only convention which says "this is the front door" and "this is the back door"

A typical basic firewall input chain looks like this:
1: allow established,related connections (i.e. - allow replies on sockets that I requested)
2: allow in-interface=not wan (i.e. allow anything new, but not from the internet-facing interface)
3: drop all (if a packet gets this far, it's a new or invalid packet on the wan interface - drop it)

The allow-remote-request=yes option on the DNS proxy would not be insecure with the above rules, because if the Mikrotik makes a DNS query, then the reply gets allowed by rule 1, but if a botnet zombie sends a DNS-amp request packet to the Mikrotik, it doesn't match rule 1 ('tik didn't request it), and it doesn't match rule 2 (interface IS wan) so it reaches rule 3 which says drop everything.

Excellent. Thanks. We had remotely shut down the offending router; I I will check the config when we visit the site next to see where the issue was.

Kind of sad that out of the box Mikrotik still has defaults that allow them to be abused.

Someone there must be incredibly stubborn to keep that checkbox checked as a default.

As someone who both has had to fix up customer Mikrotik boxes and has had to deal with 20+Gb/s DDoS attacks (surely many Miks involved in that), it's kind of a joke that in 2016 this is still the default config.

If turning the resolver off breaks things, so be it. Let those that actually can't use their upstream's resolvers figure it out instead of being yet another source of garbage traffic on the interwebs.

Kind of sad that out of the box Mikrotik still has defaults that allow them to be abused.

Someone there must be incredibly stubborn to keep that checkbox checked as a default.

The defaults ALSO have a firewall filter to block all of this. It doesn't matter if the service is enabled if no packets can reach the service.

Probably what happens is that the defaults are set to dhcp-client, and people who have DSL will go in and manually add the pppoe client, but the Internet still doesn't work. Then they find out their nat rules need to get fixed to use the pppoe interface, and then everything starts working and they're happy and log out of the router, never to notice that they didn't go fix the filter input chain, so the router's now wide open.

If the inexperienced user had used the setup wizard to change it to pppoe mode, then the defaults would have been modified and no open resolver would be created.

Kind of sad that out of the box Mikrotik still has defaults that allow them to be abused.

Someone there must be incredibly stubborn to keep that checkbox checked as a default.

The defaults ALSO have a firewall filter to block all of this. It doesn't matter if the service is enabled if no packets can reach the service.

Probably what happens is that the defaults are set to dhcp-client, and people who have DSL will go in and manually add the pppoe client, but the Internet still doesn't work. Then they find out their nat rules need to get fixed to use the pppoe interface, and then everything starts working and they're happy and log out of the router, never to notice that they didn't go fix the filter input chain, so the router's now wide open.

If the inexperienced user had used the setup wizard to change it to pppoe mode, then the defaults would have been modified and no open resolver would be created.

That makes sense. Or a second interface is added for failover.

Bottom line, what's a use-case where you'd actually WANT the resolver listening on external addresses? Maybe like 0.0001% of users would have some use for that, not enough to warrant it as a default "on".

its not not MikroTik-specific as noticed and "common practices" in terms of firewalling/whitelisting DNS services - helpful Anywhere. even with DNSSec and other stuff - its remain good idea.
look for competing companies whitepapers/wiki - they had exactly Same advice's - Protect you services, Restrict access to them(preferably ANY of them)to Only those, who need then and can 4/5 reliably identify themselves(Ip address alone - don't counts much, but good start. spoofing never get old, thanks to lack of strict RFC3074 in edge/border/bras, despite "common practice" advice's and ISC suggestions).

UPDATE: We found that the input chain DROP rule for Eth1-Gateway (WAN) had been disabled, and the "Allow Remote Requests" enabled. Either our error or we had been compromised.

You guys were exactly correct.

To be safe, we reset the config, reloaded new OS V6.33 and FW 3.24 (RB400). While "Allow Remote Requests" is enabled on the default config, so it the DROP input chain rule which protects useless admins.....

I think that is a good compromise. It seems that most consumer routers allow remote LAN requests by default anyway. This way I can setup static LAN ips and DNS for the router address. Much easier.

It's mind boggling to see that this thread started in 2013 and 3 years down the road, it is still of valid concern.

I believe quite a few Mikrotik routers here in Malaysia is or have been a zombie in a DNS amplification attack.

Not the user's fault but the fault of guides that they follow to setup their router. For example, this is a guide that ranks highly in Google for "Mikrotik Unifi Setup Guide". The link has a confidence inspiring domain: mikrotik.com.my.
http://www.mikrotik.com.my/setup-for-unifi/
UniFi is a FTTH service by Telekom Malaysia. http://unifi.my

Following this guide will have the internet up in no time but leaves the default input chain drop rule on ether-gateway1. This is a problem because UniFi uses PPPoE. To be fair, in Sep 2015, the above guide included a note to a youtube video which addresses this problem at 1:41 but, to someone new to Mikrotik, it's not absolutely clear on what to do. Btw the video was made by a fellow Mikrotik forumer, hendry. Kudos to him for alerting the owners of the guide. IMHO, the guide should have been updated to reflect hendry's point but instead, it exists as it is to continue creating zombies.

I made a suggestion how to improve the default firewall to avoid this problem, but it does not appear to
be received well. It should be noted that when you have PPPoE and you configure the router using the
quickset for PPPoE, this problem does not occur. The problem is that people configure their router using
outdated instructions and without knowledge of this problem.
However, using a default-deny firewall as I proposed will at least make them aware of the issue.

yup most people not aware that even with default drop in input chan, if they check allow remote dns request then port 53 will opening its door from outside DNS access and they need to close it from wan side access to secure it.

yup most people not aware that even with default drop in input chan, if they check allow remote dns request then port 53 will opening its door from outside DNS access and they need to close it from wan side access to secure it.

There IS NO default drop in the default ip firewall in MIkroTik routers!
The setting of iptables apparently is to default accept, and the default firewall accepts established/related and icmp,
then drops traffic from ether1, then falls into the open end of accept everything.
This means that whenever you add a new interface that is connected to internet, like when you add PPPoE manually,
you will have created a wide open interface where everyone can abuse your DNS service.
To fix this you have to modify the firewall. That is why I suggest to change the default firewall so that it ends with a drop
rule, and allows traffic from the ether2 or bridge-local explictly. So, when you add another interface it won't accept
incoming traffic by default.

Just to be clear, when I reset the router back to factory defaults in January of 2016, the following rules were created by default (except for Winbox Access)

The highlighted rule takes care of outside (WAN) DNS queries on the Eth1 gatetway, but not the others.

So you can enable Allow Remote Requests safely.

Verified this by pointing my home hosts to this remote router using the WAN IP address as the DNS server.

Just to be clear, when I reset the router back to factory defaults in January of 2016, the following rules were created by default (except for Winbox Access)

The highlighted rule takes care of outside (WAN) DNS queries on the Eth1 gatetway, but not the others.

So you can enable Allow Remote Requests safely.

ONLY when ether1 is in fact your internet connection!
When you need to use PPPoE on top of that, your internet traffic is not coming in on ether1 but on the pppoe
interface, and so this rule needs to be modified when you create a pppoe interface.
Same thing for other special cases, e.g. when you need to use VLAN tagging on the internet interface.

I think it is dangerous situation in the hands of non-technical users.

OK - understand completely. As was noted in an earlier post....RouterOS can be dangerous if one does not pay attention to the details. I would have missed that to be honest.

G

understand now the need of default drop

Mikrotik has ip/services settings
It is just DNS is not in the list.

This is an old topic. After the above, the default firewall has changed and the risk of open DNS resolver in the hands of newcomers is a lot less.
When you still have the old firewall, consider resetting to defaults and re-building your config, even when it costs some effort.