I have Rb1100AH core router (pppoe concentrator) and enabled “Allow remote requests” in DNS…
router have static public IP adddress, customers dynamic public IP.
Is there reasonable cause to block DNS requests from outside world and if it is what is most effective solution for that?
I suppose firewall filter, is there any sample code for 100% block that on core router, and customers MT’s as well?
TNX
Create a firewall rule on the input chain to DROP port 53 TCP and 53 UDP on traffic incoming on the WAN interface.
Blocking DNS requests that are not explicitly allowed is a good practice. It will keep your router’s DNS cache from filling up with unexpected queries and it will preserve your bandwidth for your customers instead of public entities.
Assuming your concentrator sits fully between your customers and the internet…
To block all external access to your concentrator DNS relay coming from ether1 add the following to the firewall (adjust ether1 as appropriate to your upstream ether port):
/ip firewall filter
add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
Then, to protect your customer MTs which may be publicly accessible and also running DHCP relay add the following to the concentrator (again adjust ether1 as appropriate to your upstream ether port):
/ip firewall filter
add chain=forward protocol=udp dst-port=53 out-interface=!ether1 action=drop
add chain=forward protocol=tcp dst-port=53 out-interface=!ether1 action=drop
The above will not prevent your customers from using any external publicly accessible DNS server outside your network. Unless you are prohibiting your customer s from access to certain sites and need to control DNS responses, there is no reason to block those tech-savvy customers from choosing their own upstream DNS servers. If you do want to maintain dictatorship control over DNS queries that your customers make, you would need the following rule added to capture and redirect all customer DNS queries to the local concentrator, regardless of DNS server settings on the client side:
/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 in-interface=!ether1 action=redirect
add chain=dstnat protocol=tcp dst-port=53 in-interface=!ether1 action=redirect
I added this two :
/ip firewall filter
add chain=input in-interface=ether8 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether8 protocol=tcp dst-port=53 action=drop
/ip firewall filter
add chain=forward protocol=udp dst-port=53 out-interface=!ether8 action=drop
add chain=forward protocol=tcp dst-port=53 out-interface=!ether8 action=drop
But when I torch ether8, I still get many active connections on port 53.
Why is it so ?
Because the attacker doesn’t know that you have made such rules. Once it gets you stopped responding he will stop trying to abuse you. None new will be repeating it because they will just make a test on you and then they will search some other opened dns server.
Al right so the above code is correct then 
And I can forget about it now ?
All well, right ?
And do I need to delete the last 2 filter rules ?
Check it tomorrow. At least the dns server utilisation should be low immediately. Last two rules just prevent the inner devices to talk with other outer dns servers but they are not effective as they are below the general accepting rule for outbound traffic. It depends on you whether you want allow it or not.
Do you still have the service accepted for both tcp and udp port 53 in the firewall filter rules with the above filter rules?
I applied the above command but all my clients were unable to resolve thereafter, it only worked when i excluded the public name servers included my ip>dns setting. I am using my mikrotik as DNS server for my clients, is this a normal behavior? because i am not seeing the filter catching anything yet.
To block or not to block ? …
If you serve DNS from WAN side for your clients then you have open DNS which is vulnerable for DNS DDoS.
I want to block access to mikrotik DNS from outside, however once i apply the rule indicated above my local users (behind mikrotik) are unable to browse (i.e they are not able to resolve a name but can ping outside). So what am I doing wrong?
Thanks
Those rules assume that ether1 is WAN. If your LAN clients got blocked by them, then it looks like you have things connected to different ports and you need to replace “ether1” by whatever your WAN interface is.
Do you mean, the bottom 2 rules will not the users browse, if they are on google DNS ?
Make sure the input chain contains a rule:
Accept , connection-state=established,related
and that this rule appears before any rule that blocks DNS.
@ZeroByte, I have this 4 only.
/ip firewall filter
add chain=input in-interface=ether8 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether8 protocol=tcp dst-port=53 action=drop
/ip firewall filter
add chain=forward protocol=udp dst-port=53 out-interface=!ether8 action=drop
add chain=forward protocol=tcp dst-port=53 out-interface=!ether8 action=drop
Can you add the extra line please ?
So, this should be on top of all rules ?
yes - before the first two rules of the input chain
You should probably replace the entire input chain with the following:
/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input in-interface=LAN action=accept
add chain=input protocol=icmp action=accept
add chain=input action=drop
If you have multiple LAN segements, it might be easier to specify “in-interface=!WAN” for the second rule - and of course LAN and WAN should be replaced with the actual names of your LAN/WAN interface (whichever version of rule 2 you use).
My WAN is ether8 and my PPPoE port is ether3
So you mean this ?
/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input in-interface=ether3 action=accept
add chain=input protocol=icmp action=accept
add chain=input action=drop
/ip firewall filter
add chain=forward protocol=udp dst-port=53 out-interface=!ether8 action=drop
add chain=forward protocol=tcp dst-port=53 out-interface=!ether8 action=drop
Sorry - but what does this mean? WAN means the Internet interface (the one with the public IP address on it)
So - if you’re connecting to the Internet with pppoe, then the pppoe-out interface is the WAN interface (and not the physical port it runs through)
If you have only one WAN connection, it’s probably best to use “in-interface=!pppoe1-out” on that rule (or whatever the name of your pppoe connection is - not the actual interface)
Think of the logic: I want to accept anything that’s not coming from the internet - so any in-interface other than the WAN interface is acceptable, therefore the rule should accept connections on any interface that is not the WAN interface.
I mean, ether8 is the port which is connected from core router to this Router.
And ether3 is the PPPoE port.
okay - so use the in-interface=!pppoe-interface (not ether3, but pppoe1-out or whatever its name may be in your configuration)