Default Disable Allow Remote Requests in IP->DNS

RouterOS General
1

Hello,

I support few ISPs and I find that in the default configuration of routerboard IP–>DNS is enabled. We find that this results in Huge DNS requests going (over time) to the router and they exhaust their Fair Usage policy (GB download/upload limits. this causes lot of arguments between the ISP and customers.
I suggest that the default setting be configured to off. with a warning if someone wants to enable that.

Thanks/ DP

2

Default firewall configuration protects router from DNS attacks.
We are not responsible if configuration was altered to accept such attacks.

3

This has been discussed before, the default configuration of the Firewall in RouterOS is especially
vulnerable to changes people make in the router setup, not in the firewall but in the interfaces setup.
This can easily be prevented by a small change in the default Firewall, but it appears that MikroTik
is unaware of best practices in Firewall setup (default deny policy) and only keeps re-iterating that
it is all the user’s fault.

4

There are 2 option - you use default configuration, or you don’t and clear configuration and build it from 0. Both options have DNS secured.

5

And what happens if the user removes this rule? It is the same result.

6

But if user does not remove this rule ? What then ?

Normis… it is very easy change which offers much more secure default rules.
If you want to ask "what if " again and again then the best option is to make empty configuration the default one. Then the user is fully responsible for troubles.

Please answer th question:
What is the problem to deny access from the default WAN interface ? It is only one additional line of configuration more.

7

Default configuration is already denying access from WAN interface (only ICMP is allowed).

8

I don’t understand the problem.

SITUATION A (now):

  1. Default Firewall blocks access to router
  2. User removes Firewall, and
    = DNS becomes accessible

SITUATION B (your proposal):

  1. Remote requests is off
  2. User enables remote requests
    = DNS becomes accessible

The end result is the same. The user will remove any config, even if you have multiple locations to turn it off, most problems are caused by removing config, and not adding it back in the right places.

9

Your “situations A and B” are NOT what people complain about. Try looking at it at a different angle:

SITUATION A (now)

  1. Default firewall block access on (lets say) ether1 interface (which is considered WAN in the default configuration).
  2. User configures PPPoE client and the newly created pppoe-out1 interface becomes the new WAN.
  3. User has access to the internet, so it’s not quite obvious that firewall rules need to be adjusted.
    = DNS server becomes world accessible.

SITUATION B (what’s proposed)

  1. Default firewall allows access to the router on LAN port only, denies everything else (we are talking about INPUT chain here).
  2. User configures PPPoE client and the newly created pppoe-out1 interface becomes the new WAN.
    = DNS server is still only accessible via LAN port.
10

Nice answer. It would be great if the original request was formed like this, with a clear example.

11

Stuation B:
Client removes port from the bridge, instantly locked out of the router and unable to connect, RMA tickets “ethernet stopped working”
Client creates IPIP tunnel, tunnel doesn’t work - support tickets and forum posts “buggy version, tunnels doesn’t work”.
And so on.

Topic was discussed already here
http://forum.mikrotik.com/t/better-default-for-firewall-filter/97023/1

And as it was mentioned in topic, if anyone can provide set of rules that will fix all user problems then please do, we will change default configuration.

12

It is always possible to lock yourself out of the router. That does not change. When you remove all
ports from bridge-local without moving the LAN IP address to a physical port first, you will lose access too!
It does not require an RMA because you can restore it using the reset procedure, or via RS232 when available.

When a newly added tunnel does not allow connection to the router, that is not really as important. Most people
will use tunnels for forwarding, and forwarding is not affected by this change. Forwarding is not that important
because 99% of users have NAT and forwarding from the internet is disabled by default anyway. Those who
have an IP block on internet and want forwarding normally have to change the firewall anyway.

Maybe you would need to add another way of interface grouping, not by name but by “type”.
Say, you have a LAN and a WAN type. New pseudo-interfaces like PPPoE by default go into the WAN type unless
there is real reason to believe that this interface would be a LAN, as would be the case for an explicitly
defined tunnel. The type would be changable and the firewall would disallow external access from the
WAN-type interfaces. At least this shows clearly to the user if his new interface is going to be for local
access. Of course it still allows mistakes to be made. What we are after is a change to improve security
for the newbie, not a change that ends all need for configuration.

13

These discussions wouldn’t be performed here if there were blank config and nothing else in each new device. Big warning on each box: “This device is not secured at all. You are responsible for what you set and where you connect it to.”

Car manufacturers are not responsible for the car crashes when the drivers didn’t do what they should or did what shouldn’t.

14

That is correct. This is how I received my CCR-1009. I’m not sure if this was a bug or if it is always
like that, but it only got a 192.168.88.1/24 address and nothing else. No DHCP server even.
Very convenient because I did not have to delete all that crud that I normally have to delete from a router
that I want to deploy as a real router not a NAT device for home usage, but I can understand that most
routers are used in that environment and a default config is a nice selling point.
Only my point is that this default config can easily be made a little more robust against a typical
problem. (adding PPPoE interface)