Countermeasures versus incoming DNS reflection attack

Question

i am currently experiencing a DNS reflection attack towards my server. I am getting a massive amount of answers via UDP from Port 53 that my server has never asked for:

02:53:57.626156 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 267) REFLECTING.OPEN.DNS.SERVER.domain > mydomain.com.11803: 30781- q: RRSIG? . 0/13/1 ns: . NS A.SOMENAMESERVER.NET., .[|domain]

02:53:57.626382 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 267) REFLECTING.OPEN.DNS.SERVER.domain > mydomain.com.11803: 30781- q: RRSIG? . 0/13/1 ns: . NS B.SOMENAMESERVER.NET., .[|domain]

02:53:57.627804 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 267) REFLECTING.OPEN.DNS.SERVER.domain > mydomain.com.24188: 30781- q: RRSIG? . 0/13/1 ns: . NS C.SOMENAMESERVER.NET., .[|domain]

So the countermeasure i thought about is limiting the number of incoming Packets with a source port of 53. Should be no problem with iptables right?

So i put this together with my little iptables skills:

-A INPUT -s A.TRUSTED.NAMESERVER -j ACCEPT

-A INPUT -s B.TRUSTED.NAMESERVER -j ACCEPT

-A INPUT -s C.TRUSTED.NAMESERVER -j ACCEPT

-A INPUT -p udp -m udp --sport 53 -m limit --limit 10/min -j LOG --log-prefix "53 DENY FROM: " --log-level 7

-A INPUT -p udp -m udp --sport 53 -m limit --limit 10/min --limit-burst 20 -j ACCEPT

Logging the attack and bursting it when it gets too much. Well i would not write here if it worked out.

Something must be wrong and i cant figure out what. It logs correctly but it doesn't DROP any packages even if the number is > burst limit.

I am very thankful for help.

Greets Marcel

Answer 1

I can't see any DROP in your rules. Perhaps you want to append

-A INPUT -p udp -m udp --sport 53 -j DROP

at the end of your rules?

Answer 2

If the reflected packets are being sent to a closed UDP port, then the kernel on the receiving end is going to be generating an ICMP error message. This processing is quite cheap, so the processing time needed to process the UDP packet and send an ICMP error is likely to be the least of your concerns.

In some scenarios the upstream bandwidth consumed by the ICMP errors may be a real concern. In such scenarios, rate limit of the ICMP errors may be needed.

Silently dropping all the UDP packets without ever sending an ICMP error is however not advisable. The ICMP errors is the only signal the owners of the involved DNS servers have, that could tell them, that their DNS server is involved in a reflection attack. In other words, by silently dropping the packets, you are hiding the attack from the very people, who could mitigate it.

It is technically possible to design a DNS server with automatic mitigation of reflection attacks. However such mitigation would have to rely on ICMP error messages. If such mitigation methods become widespread, you would make yourself an easier target for A DDoS attack by silently dropping all attack traffic.

If the reflected UDP packets would be arriving at an open UDP port, then processing those reflected packets would become more expensive in terms of CPU time. In such scenarios it would be advisable to use iptables rules to REJECT packets whose source port is 53 or any other used by services commonly abused in reflection attacks and whose destination port is that of the service you are running. I would still not DROP them, but rather use the REJECT target to produce an ICMP error identical to what is seen on a closed port.