• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Server get flooded - DDos using OpenDNS resolver

JazZ

New Pleskian
Hello,

Since two days, my server running on Debian Wheezy with Plesk 12.5 is getting flooded by an attacker using OpenDNS resolver to DDos Avast Secure DNS. Those queries are correctly denied but it generates huge I/O level while writing the denied queries in log files (daemon.log and syslog).

Thank to Fail2Ban, I was able to ban the fakes IP and the server is back to normal I/O level.

But the queries keeps coming adding more and more fakes IP addresses to the banned list (around 3000 now).

The problem is those banned IP are maybe trusted users and because of the new fail2ban rule, the access to server will be refused.

Here is a sample of the daemon.log file :

Jan 27 20:47:43 server named[xxxx]: client 37.110.213.97#51810: query (cache) '2.SecureDNS.AVASt.CoM/TXT/IN' denied
Jan 27 20:47:49 server named[xxxx]: client 154.0.26.150#38513: query (cache) '2.SECUredNs.Avast.cOM/TXT/IN' denied
Jan 27 20:47:50 server named[xxxx]: client 154.0.26.150#33704: query (cache) '2.sEcurEDns.avasT.COm/TXT/IN' denied
Jan 27 20:47:54 server named[xxxx]: client 154.0.26.150#50798: query (cache) '2.sEcUreDns.avasT.com/TXT/IN' denied
Jan 27 20:48:06 server named[xxxx]: client 201.79.137.74#54727: query (cache) '2.SeCuREDnS.AvAST.CoM/TXT/IN' denied
Jan 27 20:48:07 server named[xxxx]: client 201.79.137.74#54735: query (cache) '2.secuReDNs.avaSt.cOM/TXT/IN' denied
Jan 27 20:48:11 server named[xxxx]: client 201.79.100.41#54754: query (cache) '2.SeCUrEDNS.AVAsT.COM/TXT/IN' denied
Jan 27 20:48:12 server named[xxxx]: client 77.147.247.52#62948: query (cache) '2.SecUREdns.AvAsT.COM/TXT/IN' denied
What is the best solution to handle this ? Is OpenDNS resolver required ?

Thank you for any help. It will be really appreciated.
 
Its a bit technical but this post should point you in the right direction:
DNS Amplification Attacks Observer: [Iptables DNS Rules]

Hello, thank you for your reply. You're right, it's technical and unfortunately, I'm not skilled enough to build the right iptable rule following the link you shared.

Another solution would be to disabled OpenDNS Resolver. But, I'm not sure if I can do that and keep hosted websites accessible from the web ?
 
Last edited:
Alright, after read the link content several times, I think I understood the point.

In the presented case, he base the iptable rule on DNS Transaction ID, DNS Type, Domain Name and the Flag. In my case, the DNS transaction ID is always different.

Do you think I can build the iptable rule only on the DNS Type, the Flag and the Domain Name ?
 
Hum, no, I can't base the iptable rule on the Domain Name because the case is random too.

I'm failing to find a solution for this...
 
I don't think the case should matter for the iptables u32 module. This rule would work:

Code:
iptables --insert INPUT -p udp --dport 53 -m u32 --u32 "0>>22&0x3C@20&0xFFFFFFDF=0x01320953&&0>>22&0x3C@24&0xDFDFDFDF=0x45435552&&0>>22&0x3C@28&0xDFDFDFDF=0x45444e53&&0>>22&0x3C@32&0xFFDFDFDF=0x05415641&&0>>22&0x3C@36&0xDFDFFFDF=0x53540343&&0>>22&0x3C@40&0xDFDFFFFF=0x4f4d0000&&0>>22&0x3C@44&0xFF000000=0x10000000" -j DROP -m comment --comment "DROP DNS Q TXT 2.securedns.avast.com"
 
I don't think the case should matter for the iptables u32 module. This rule would work:

Code:
iptables --insert INPUT -p udp --dport 53 -m u32 --u32 "0>>22&0x3C@20&0xFFFFFFDF=0x01320953&&0>>22&0x3C@24&0xDFDFDFDF=0x45435552&&0>>22&0x3C@28&0xDFDFDFDF=0x45444e53&&0>>22&0x3C@32&0xFFDFDFDF=0x05415641&&0>>22&0x3C@36&0xDFDFFFDF=0x53540343&&0>>22&0x3C@40&0xDFDFFFFF=0x4f4d0000&&0>>22&0x3C@44&0xFF000000=0x10000000" -j DROP -m comment --comment "DROP DNS Q TXT 2.securedns.avast.com"

Thank you very much ! I wish I could build something like this myself.

I'm trying to understand the syntax and how it works. Could you help me break it down ?

Code:
0>>22&0x3C@20&0xFFFFFFDF=0x01320953

From what I read, the first part (0>>22&0x3C@) jumps over the IP header (dynamically). The second one (20&0xFFFFFFDF) tells to start from the 20th bytes (from the position) and defined the mask (What's the difference between FF and DF ?). The last part (=0x01320953) is the value being checked.

So, four bytes on four bytes, we check if the Domain Name == 2.SECUREDNS.AVAST.COM
The last one checks if the query type is TXT.

Is it right ?

Unfortunately, it does not work. The requests keep flooding the daemon.log file. Are you sure that the module u32 does not care about the case ?
 
Great ! Sorry, you were right, u32 is case insensitive. The problem was coming from the last 4 bytes (there is only 3 last bytes). I think it was out of range. How to match them so ?

The daemon.log file doesn't get flooded anymore. Thank you !
 
You can use the tool below to generate u32 rules for any domain and query type:

GitHub - dowjames/generate-netfilter-u32-dns-rule.py: Produces a Linux Netfilter u32 rule to match DNS requests for a given domain name and/or a given query type.

Usage:

Code:
./generate-netfilter-u32-dns-rule.py --qname 2.SecUREdns.AvAsT.COm --qtype TXT
0>>22&0x3C@20&0xFFFFFFDF=0x01320953&&0>>22&0x3C@24&0xDFDFDFDF=0x45435552&&0>>22&0x3C@28&0xDFDFDFDF=0x45444e53&&0>>22&0x3C@32&0xFFDFDFDF=0x05415641&&0>>22&0x3C@36&0xDFDFFFDF=0x53540343&&0>>22&0x3C@40&0xDFDFFFFF=0x4f4d0000&&0>>22&0x3C@44&0xFF000000=0x10000000

Then add the string provided in an iptables rule:
Code:
iptables --insert INPUT -p udp --dport 53 -m u32 --u32 "0>>22&0x3C@20&0xFFFFFFDF=0x01320953&&0>>22&0x3C@24&0xDFDFDFDF=0x45435552&&0>>22&0x3C@28&0xDFDFDFDF=0x45444e53&&0>>22&0x3C@32&0xFFDFDFDF=0x05415641&&0>>22&0x3C@36&0xDFDFFFDF=0x53540343&&0>>22&0x3C@40&0xDFDFFFFF=0x4f4d0000&&0>>22&0x3C@44&0xFF000000=0x10000000" -j DROP -m comment --comment "DROP DNS Q TXT 2.securedns.avast.com"
 
Last edited:
I see !

This looks useful. The only thing that doesn't work is the type check but I do without it. = )

Thank you again @danami !
 
Back
Top