Dear Folk,
There is a DNS infection world wide that is spewing requests for non existent domains
to random DNS servers around the world including many of our tiks in service.
Here is the problem:
Tik has 5 ports, ether1 facing the outside world, the other 4 facing
our customers some of whom are also infected.
Infected DNS requests are coming in to the tik on all ports.
I wish to block ALL DNS requests to port 53 coming in on port 1, and redirect
all other DNS requests aimed at the tik to another bigger linux server that can handle
the infected load for further analysis and control.
I can use dst-nat to redirect the incoming requests to the tik to my other server, but
this also sends the incoming requests on ether 1.
I can block incoming requests on ether 1 using rules in the INPUT firewall.
But I can’t do both, as dst-nat is consulted first, and thus the input rules
are ignored.
Can someone please tell me the correct firewall rules to:
1.) DROP all incoming dest port 53 requests on ether1
2.) Redirect all remaining dest port 53 requests to 64.57.176.24 which is my other
server.
Eternally obliged,
Homer W Smith
CEO Lightlink Internet
The dst-nat also accepts other parameters which allow you to select src and dst address and incoming port.
So if you do the dst-nat only for the desired ports in tour dst-nat rule, you will get what you need.
e.g. redirect only packets NOT coming from eth1.
/ip firewall nat
add action=dst-nat chain=dstnat comment=DNS-TCP dst-port=53 in-interface=\
!eth1 protocol=tcp to-addresses=64.57.176.24
add action=dst-nat chain=dstnat comment=DNS-UDP dst-port=53 in-interface=\
!eth1 protocol=udp to-addresses=64.57.176.24
/ip firewall filter
add action=drop chain=input comment=DNS dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input comment=DNS dst-port=53 in-interface=ether1 protocol=tcp
too brilliant…
I do however wonder why mikrotik does not allow dropping packets in the DNAT rules,
as standard linux iptables does. 
I also feel it would be a lot more intuitive and educational if the firewalling were
arranged the way iptables is and the packet flow is, namely have tabs for prerouting, routing
and post routing, and sub tabs under that.
Thanks Homer
Dear Folks,
Here is more on the DNS war and the use of DNAT to direct all port 53 to
a known good DNS source.
Tik A ← Tik B ← Internet
Tik A has 5 ports, port 1 goes to Tik B which is default gateway
The other 4 ports are customer ports.
There is an uncountable number of DNS requests coming from the internet to port 53 going to Tik A and to every possible
IP behind Tik A (static public IP’s).
I have placed a deny rule on Tik B forbidding any packts from
B to A with dest port 53, which seems to work.
In Torching the remaining ports on Tik A it is apparent that each customer has his
own concept of where to get DNS. Some are 8.8.8.8, some are a local DNS server that is proper,
and some are to the Tik itself which points its DNS to the local DNS server.
As an experiment in law and order, I put in a
DNAT udp port 53 to 64.54.176.24 which is a test local DNS server
DNAT tcp port 53 to 64.57.176.24
Now ether1 shows that MOST of the port 53 traffic going to 64.57.176.24 as they should be,
and answers coming back.
However a few connections going through the tik are still going to 8.8.8.4 or a few other
random self chosen servers out on the net. Even after clearing the conntrack table.
Where does this leakage come from?
I have often noticed leakage in linux iptables, src natted 10.s will get through the rules
and end up going out the door to no avail.
Any I doing something wrong, or is DNAT leakey?
Thanks Homer
This is one of the most standard DDoS attacks. The best thing you can do is drop all requests on port 53 coming from the outside.
The attackers target open dns server to use them as amplification devices. The dns server of router os does not allow acl lists to choose who can query the server and for what.
So in short if you have a lot of dns traffic you most probably have or had recently in the past an open dns in your network.