Page 1 of 1

Allow choice of binding interface for NTP and DNS servers

Posted: Sun Feb 09, 2014 7:02 pm
by TonyJr
Hello,

I would like to propose allowing to choose the interface that the NTP and DNS servers built into RouterOS bind to, rather than having to set a separate firewall rule to specify access rules for them.

Example:

Letter from ISP: 'you have open DNS resolver, you may be susceptible to DDoS'.
Me: :?:

I have NTP server enabled and DNS set to 'allow remote requests'.
I look at the firewall and see for UDP, I have the standard 'allow udp -> input' rule.
Running UDP port scanner on ISP interface, ports 53, 123 and 161 are open. So I have to add a firewall rule just above the standard 'allow UDP -> input' to block access from ISP interface. It works fine and solves the problem, but it is one extra firewall rule, for both ipv4 and ipv6. Maybe it will be better to choose the binding interfaces than have the extra firewall rule?

This also highlighted to me how I have never tested for open UDP ports before :shock: . I assumed all port scanner and security tools automatically tested them. Lesson: never assume, always check!

Any comments or feedback?

Tony

Re: Allow choice of binding interface for NTP and DNS server

Posted: Sun Feb 09, 2014 9:21 pm
by Zavi
Maybe it's good idea to have DNS and NTP (and other) servers configured the same way as DHCP (per interface), i don't know.
But for sure you should have a "block everything" rule below the rules, in which you allow something.
I think it would be unnecessary more complicated to have access configuration at more places (such as SSH allowed IPs are both in services and in firewall). But in that case, i would like the "port list" feature, so i don't need special firewall rule for every service, or just option to enter more ports in firewall rule configuration.

Re: Allow choice of binding interface for NTP and DNS server

Posted: Sat Feb 15, 2014 4:39 pm
by Hammy
Every service to which RouterOS is capable of responding to should have the ability to define what IPs (not interfaces) it responds to. You don't need firewall rules chewing up system resources to block things that shouldn't even be available to begin with.