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

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): 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): 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:

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.

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?

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):

Code: Select all

/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

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.

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.

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 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

My WAN is ether8 and my PPPoE port is ether3

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)

okay - so use the in-interface=!pppoe-interface (not ether3, but pppoe1-out or whatever its name may be in your configuration)

PPPoE port is ether3

So you mean this is final ?

/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=!ether3 action=drop
add chain=forward protocol=tcp dst-port=53 out-interface=!ether3 action=drop

Soamz - do this:

/ip address print

and then post the results here

I'll tell you exactly what to type and where to type it.

attached. Thanks!!

Okay - so this is a router with lots of public IP interfaces, and is a PPPoE server - not client?

let me try this a different way:
/ip route print where dst-address=0.0.0.0/0

And does this router have multiple WAN interfaces? (i.e. does it have multiple ways to reach the Internet?)

This is the main Router after which there are 2500 customers PPPOE authenticated and using internet. 

I think, you call is NAS or BRAS router. 

My network is this, 
3 upstreams > 3 dedicated Microtik edge router 
Then it connects to 2 Microtik core routers in VRRP >>
Then it connects to this NAS router >> Customers

Alright - then you need to use address-list to define who may do DNS requests, or use interface groups (only available in RC versions, so for now, I'm going to recommend address list)

/ip firewall address-list
add list=dnsClients address=x.x.x.x/m

do this for each of the IP ranges where you want to allow DNS requests

Then in your input chain, after the rule which allows established,related.....
add these rules:
action=accept protocol=udp dst-port=53 src-address-list=dnsClients
action=drop protocol=udp dst-port=53

This will filter DNS by source IP - which is more sensible in a router configuration such as yours.

Remove the old and place this ?
Sorry, Im just afraid to mess it up always, as once for one single click, whole network had gone down for 1 hour,and I had to drive for 22 kms at 2am in the night. 


So, could you please paste the final version of total code please ?
I will remove the old 4 lines, as I stated in the thread and will paste yours.

And then goto address list and add my network's  5 /24 , so that only customers within my network can access the DNS request.s 

Okay - you need to evaluate this list of rules and understand what it will do before you implement it on your router.
Obviously, I cannot know everything about your configuration, and this list of rules is specific to the posted request - DNS filtering.

First, and most importantly, ADD THE ADDRESS LIST FIRST
A list by itself does nothing, so making it first won't change anything. Only when you make a rule which references it will it do anything.
However, if you make a rule which blocks everything except whatever's in the list - and the list is empty - then you're in effect blocking EVERYTHING.

After creating your list (called AllowedDNS in this example):

/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 protocol=udp dst-port=53 src-address-list=!AllowedDNS action=drop

This is still a "default-allow" policy, but it does solve the problem of filtering DNS as you requested, and since you're having trouble with following the behavior of firewall rules, I'm not going to recommend a default drop policy in case I've forgotten to give a rule to allow something critical to your network's operation.

If the first rule of the input chain is as shown in my code above, then at the very least you cannot kick yourself out of the router with one firewall rule change, because the first rule allows existing connections to continue. You can always try using safe mode, so that if you do something wrong, at least the router will revert the changes automatically when you get disconnected.

First delete my existing 4 rules. 
Then , 

/ip firewall address-list
add list=dnsClients address=x.x.x.x/m

Goto address list and add my IP blocks first. 

Then run 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 protocol=udp dst-port=53 src-address-list=!AllowedDNS action=drop

So basically, accept the connection coming from PPPoE ether 3 port, and only allow the address list IP blocks to access the port 53 and rest IP, drop them.
gg

Still did not end to the final code. 

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):

Code: Select all

/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):

Code: Select all

/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:

Code: Select all

/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

Thanks this worked beautifully and cured a number of issues I've been having.

Hi,

if you want to use your publicly accessible Mikrotik as DNS-Server, then you need to filter DNS Requests in such a way that only outgoing requests to a defined set of DNS-Servers are allowed.
Those same DNS Servers are also allowed inbound, all the rest on Port TCP/53 and UDP/53 is dropped.
Below example allows opendns and google-dns. Works in NAT as well routed scenarios.
ether1 is WAN

I use this now on all my Routers with Public IP's even if the DNS-Server is disabled (in case someone enables it without thinking about the consequences (thousands of DNS requests)

/ip firewall address-list
add address=8.8.8.8 list=dns
add address=4.2.2.2 list=dns
add address=208.67.222.222 list=dns
add address=208.67.220.220 list=dns

/ip firewall filter
add action=accept chain=input comment="Inbound DNS" in-interface=ether1 protocol=udp src-address-list=dns src-port=53
add action=accept chain=forward comment="Inbound DNS" in-interface=ether1 protocol=udp src-address-list=dns src-port=53
add action=accept chain=output comment="Outbound DNS" dst-address-list=dns dst-port=53 out-interface=ether1 protocol=udp
add action=accept chain=forward comment="Outbound DNS" dst-address-list=dns dst-port=53 out-interface=ether1 protocol=udp
add action=drop chain=input comment="Drop DNS" dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input comment="Drop DNS" dst-port=53 in-interface=ether1 protocol=tcp