2

I have a disturbing problem for a few weeks now ... One of my three DNS-servers (running bind9 as slave of a Plesk DNS master) is getting spammed with senseless DNS requests. The origin IPs of those requests are from all over the world, so I can't just drop an IP range or a whole country by iptables.

Here are a few log lines so you can see the scheme of those "attacks":

10-May-2015 11:15:54.714 client 120.87.202.161#47441: query: sjgzincrmxobabst.www.luzhiye.com IN A + (my-ip)
10-May-2015 11:15:56.252 client 111.187.196.51#41387: query: mrcf.www.330dp.com IN A + (my-ip)
10-May-2015 11:15:56.806 client 89.90.44.173#56673: query: qzwp.www.330dp.com IN A + (my-ip)
10-May-2015 11:15:57.891 client 116.93.242.237#55721: query: srapafupglkxaver.www.330dp.com IN A + (my-ip)
10-May-2015 11:15:59.611 client 123.153.92.59#20847: query: yj.www.330dp.com IN A + (my-ip)

Those requests are not really attacks because the host server is very relaxed. I tried to block the requests with iptables, but after a few minutes/hours the requested domains are changing, so I have no chance to do so.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             STRING match  "888fy.com" ALGO name bm TO 65535
DROP       all  --  anywhere             anywhere             STRING match  "taohua.me" ALGO name bm TO 65535
DROP       all  --  anywhere             anywhere             STRING match  "yymo.us" ALGO name bm TO 65535
DROP       all  --  anywhere             anywhere             STRING match  "taohuazu.cc" ALGO name bm TO 65535
DROP       all  --  anywhere             anywhere             STRING match  "taohua.me" ALGO name bm TO 65535
DROP       all  --  anywhere             anywhere             STRING match  "227x.com" ALGO name bm TO 65535

Does anyone have experience with these kind of "attack"? How to stop it? I tried to shutdown the whole server for 48 hours. After the restart there were no attacks anymore, but a few hours later they started again.

Configuration (named.conf.local / named.conf.options):

dnssec-validation auto;
allow-new-zones yes;
notify master-only;

auth-nxdomain no;    # conform to RFC1035
listen-on-v6 { any; };

statistics-file "/var/cache/bind/named.stats";
zone-statistics yes;

controls {
        inet * port 953 allow { plesk-ip; 127.0.0.1; } keys {"rndc-key"; };
};

logging {
        channel b_query {
                file "/var/log/bind9/query.log" versions 2 size 1m;
                print-time yes;
                severity info;
        };
        category queries { b_query; };
};

I ran a few online tests to verify again that my DNS server is not an open resolver. Successfully: No open resolver found.

Help is really appreciated!

5
  • 2
    All of the queries in the log excerpt are recursion requests (+), are you allowing this? You almost certainly shouldn't be. May 10, 2015 at 9:33
  • How is your server responding to those requests? I know of a colleague that has some firewall rules that only allow DNS traffic for domains he is authoriative for (eg. jump into a chain, and -j RETURN from it when you find a match; last rule in that chain should be a -j DROP). May 10, 2015 at 9:43
  • Show your named.conf file. May 10, 2015 at 14:40
  • Added named configuration
    – iLLogical
    May 10, 2015 at 18:06
  • Looking at the ownership of those IPs, the forwarding case also seems unlikely unless you run a customer facing service in China. Either your DNS server was an open resolver at some point and has made it into the lists that the botnets are using as attack vectors (whether or not you are currently an open resolver), or they're starting to spew queries at open DNS ports regardless of whether they provide recursion. (something I have not yet seen on the authoritative DNS servers for a MSO that I work with)
    – Andrew B
    May 10, 2015 at 21:23

0

Browse other questions tagged .