Just noticed a very high count of open connections from outside IP's pounding on my public IP port 53 -- a quick test showed that it was acting as an open DNS server.

I shut it down and changed DHCP so that internal clients will just get 8.8.8.8 for their DNS server.

What is the best practice for allowing the router to server INTERNAL dns requests but continue to deny external requests from the public ip?

Very good question... I'd like to know the answer also.

It's crazy how that type of service was open to the public when you don't even need it... Or maybe there is legitimate use for this?

I think the best approach is to drop all packets on the input chain with the exception of SSH (maybe HTTP) and even that I would put on another port. If (and only if) something doesn't work, then check the firewall rules to allow access. "Better safe than sorry".

Add rules to drop TCP and UDP port 53 on the external interface. Put them in both the input and forward chains.
Edited to add:
The parameter you want is
in-interface="ether1"
If ether1 is your external interface.

Sent from my LG-D800 using Tapatalk

I've done the above...however DNS relay itself is not available on the inside of the network.

"drop tcp/udp port 53 ether1-gateway on both the input & forward chains"

If I check the "allow remote requests" box under IP / DNS -- it allows foreign access to the public IP side for queries, ignoring the rules.

Must be something simple that I'm missing?

Randomly I can see literally hundreds of DNS query attempts (like 600-770 at the moment) that are going "unreplied" from some crappy broken systems out there that keep pounding on it. It's possible that this IP address from Comcast was assigned to someone else that had an opendns policy and now I'm stuck with getting the queries.

It would be nice to use it as threat indication and add to a DNS blocklist like the ssh bruteforce filter does.

If you leave your dns open then it doesn't take long for hackers to find it and use it for dns amplification attacks

If you leave your dns open then it doesn't take long for hackers to find it and use it for dns amplification attacks

Obviously we don't want that -- hell I don't even want them using it to bypass whatever DNS servers they are using -- or using it to fill up the cache in my system.

Fundamentally there must be a way to shutdown/ignore the requests from outside the network on the public IP while simultaneously leveraging the DNS proxy/cache of the RouterBoard from the inside/offnet addresses.

There is, you just block incoming traffic to port 53 from outside (WAN interface).

I know you tried, but it looks like you made some mistake. You may have some other rules before the blocking ones, that allow incoming requests. Or your blocking rules are not correct. In any case, it should be something simple, just review it carefully and you should find it. If not, you may do export and post it here and someone else might find it for you.

It should be like this assuming your WAN connection is on either1. This drops new connections coming in ether1. This will still allow DNS requests to go out from the router and then back in without allowing NEW connections from unwanted outsiders.
Also, the post saying you should be blocking the forward chain is incorrect. If any clients request DNS from behind the router without using the router this will block those connections. Traffic to the router is INPUT and traffic through the router is FORWARD.

I block forward as well on the external interface as it allows me to dst-nat port 53 for internal access without having opened that server to traffic from the outside. Your assertion that it will block requests from the he internal network is not correct. Replies are accepted with standard rules for established, related.

Sent from my LG-D800 using Tapatalk

My assertion is 100% correct if these rules are added to a firewall with no other rules. Which would look like this.

Add rules to drop TCP and UDP port 53 on the external interface. Put them in both the input and forward chains.
Edited to add:
The parameter you want is
in-interface="ether1"
If ether1 is your external interface.

There are no "standard" rules, every firewall should be built to fit a need. The first thing we do when we get a new routerboard is remove the default config as it is designed for the basic home user. Also, the standard rules which mikrotik provide in the default config only apply to the input chain and have no rules for the forward chain. If using the default config provided by mikrotik you should not be having this problem anyway as the only thing it allows in the WAN interface is ICMP.

http://wiki.mikrotik.com/wiki/Manual:De ... igurations

What do you mean by this? I had a couple other engineers here in the office look at this and they are not sure what you mean either. We are just curious.

I block forward as well on the external interface as it allows me to dst-nat port 53 for internal access without having opened that server to traffic from the outside.

Here's what I have at the moment:

/ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Accept established connections
chain=input action=accept connection-state=established log=no log-prefix=""

1 ;;; Accept related connections
chain=input action=accept connection-state=related log=no log-prefix=""

2 ;;; invalid connections
chain=input action=drop connection-state=invalid log=no log-prefix=""

3 ;;; UDP
chain=input action=accept protocol=udp log=no log-prefix=""

4 ;;; invalid connections
chain=forward action=drop connection-state=invalid log=no log-prefix=""

5 ;;; Port scanners to list
chain=input action=add-src-to-address-list protocol=tcp psd=21,3s,3,1 address-list=port scanners address-list-timeout=2w log=no log-prefix=""

6 ;;; NMAP FIN Stealth scan
chain=input action=add-src-to-address-list tcp-flags=fin,!syn,!rst,!psh,!ack,!urg protocol=tcp address-list=port scanners
address-list-timeout=2w log=no log-prefix=""

7 ;;; SYN/FIN scan
chain=input action=add-src-to-address-list tcp-flags=fin,syn protocol=tcp address-list=port scanners address-list-timeout=2w log=no
log-prefix=""

8 ;;; SYN/RST scan
chain=input action=add-src-to-address-list tcp-flags=syn,rst protocol=tcp address-list=port scanners address-list-timeout=2w log=no
log-prefix=""

9 ;;; FIN/PSH/URG scan
chain=input action=add-src-to-address-list tcp-flags=fin,psh,urg,!syn,!rst,!ack protocol=tcp address-list=port scanners
address-list-timeout=2w log=no log-prefix=""

10 ;;; ALL/ALL scan
chain=input action=add-src-to-address-list tcp-flags=fin,syn,rst,psh,ack,urg protocol=tcp address-list=port scanners address-list-timeout=2w
log=no log-prefix=""

11 ;;; NMAP NULL scan
chain=input action=add-src-to-address-list tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg protocol=tcp address-list=port scanners
address-list-timeout=2w log=no log-prefix=""

12 ;;; ping port scanners
chain=input action=drop src-address-list=port scanners log=no log-prefix=""

13 ;;; ftp brute forcers
chain=input action=drop protocol=tcp src-address-list=ftp_blacklist dst-port=21 log=no log-prefix=""

14 chain=output action=accept protocol=tcp content=530 Login incorrect dst-limit=1/1m,9,dst-address/1m log=no log-prefix=""

15 chain=output action=add-dst-to-address-list protocol=tcp address-list=ftp_blacklist address-list-timeout=3h content=530 Login incorrect log=no
log-prefix=""

16 ;;; ssh brute forcers
chain=input action=drop protocol=tcp src-address-list=ssh_blacklist dst-port=22 log=no log-prefix=""

17 chain=input action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=ssh_stage3 address-list=ssh_blacklist
address-list-timeout=1w3d dst-port=22 log=no log-prefix=""

18 chain=input action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=ssh_stage2 address-list=ssh_stage3
address-list-timeout=10m dst-port=22 log=no log-prefix=""

19 chain=input action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=ssh_stage1 address-list=ssh_stage2
address-list-timeout=10m dst-port=22 log=no log-prefix=""

20 chain=input action=add-src-to-address-list connection-state=new protocol=tcp address-list=ssh_stage1 address-list-timeout=1m dst-port=22 log=n>
log-prefix=""

21 chain=input action=drop protocol=tcp in-interface=ether1-gateway dst-port=53 log=no log-prefix=""

22 chain=input action=drop protocol=udp in-interface=ether1-gateway dst-port=53 log=no log-prefix=""

23 chain=forward action=drop protocol=tcp in-interface=ether1-gateway dst-port=53 log=no log-prefix=""

24 chain=forward action=drop protocol=udp in-interface=ether1-gateway dst-port=53 log=no log-prefix=""

Why you have the rule nr. 3? It opens also access to dns service.

Why you have the rule nr. 3? It opens also access to dns service.

THAT is an excellent question -- I took some of this initial config from another site that looked to have a fairly decent initial config...

https://aacable.wordpress.com/2011/08/1 ... wan-users/

BTW, I just Disabled that rule #3 and VOILA! It now behaves as expected.

Good call jarda! Thanks for reviewing the config for us

It should be like this assuming your WAN connection is on either1. This drops new connections coming in ether1. This will still allow DNS requests to go out from the router and then back in without allowing NEW connections from unwanted outsiders.

Code: Select all

/ip firewall filter
add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=tcp

Also, the post saying you should be blocking the forward chain is incorrect. If any clients request DNS from behind the router without using the router this will block those connections. Traffic to the router is INPUT and traffic through the router is FORWARD.

1. i am using pppoe-out1 (ether1) in my mikrotik and my modem is in bridge mode. will it be in-interface=pppoe-out1 ?
2. is this code below makes different (better or worst or same) from your code? i am using this at the moment and i will change to yours!

add action=drop chain=input comment="block dns attacks" dst-port=53 protocol=udp src-address=!192.168.88.0/24
add action=drop chain=input comment="block dns attacks" dst-port=53 protocol=tcp src-address=!192.168.88.0/24

It should be like this assuming your WAN connection is on either1. This drops new connections coming in ether1. This will still allow DNS requests to go out from the router and then back in without allowing NEW connections from unwanted outsiders.

Code: Select all

/ip firewall filter
add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=tcp

Also, the post saying you should be blocking the forward chain is incorrect. If any clients request DNS from behind the router without using the router this will block those connections. Traffic to the router is INPUT and traffic through the router is FORWARD.

1. i am using pppoe-out1 (ether1) in my mikrotik and my modem is in bridge mode. will it be in-interface=pppoe-out1 ?
2. is this code below makes different (better or worst or same) from your code? i am using this at the moment and i will change to yours!

add action=drop chain=input comment="block dns attacks" dst-port=53 protocol=udp src-address=!192.168.88.0/24
add action=drop chain=input comment="block dns attacks" dst-port=53 protocol=tcp src-address=!192.168.88.0/24

Yes. You are correct. The in-interface=pppoe-out1 is the statement you need. You do not need the src-address=!192.168.88.0/24 statement however.

Glad I could help you. It is not so smart to blindly copy everything what you see somewhere. You have to understand what you do and not to do if you don't know what are you doing.

It should be like this assuming your WAN connection is on either1. This drops new connections coming in ether1. This will still allow DNS requests to go out from the router and then back in without allowing NEW connections from unwanted outsiders.

Code: Select all

/ip firewall filter
add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=tcp

Also, the post saying you should be blocking the forward chain is incorrect. If any clients request DNS from behind the router without using the router this will block those connections. Traffic to the router is INPUT and traffic through the router is FORWARD.

I've tried this and it's not working. If you look at my interface list, you see ether1 pumping out 15.7mb of data. Nothing coming from LAN side. I have "allow remote requests" enabled so that my customers can use this as their DNS server. It appears I'm being attacked, and have been researching for 2 days trying to figure out how to stop this. I added the two rules you said, as you can see, why isn't it stopped?

See the connection tracking table and torch the ether1 to know what the traffic is. Anyway your firewall is not secured at all.