random dns queries with random sources

Hey all,

DNS amplification spoofed source attacks, I get that. I even thought I was getting mitigation down to acceptable levels.

But now this. At different times during the previous days and on different resolvers, routers with proxy turned on, etc...

Thousand of queries with thousands of source ip addresses.

According to my logs, sources are not being repeated (or not with any significant frequency)

What is the purpose of this?

18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query: swe.5kkx.com IN A + (66.199.132.5)
18-Feb-2014 21:45:25.067 queries: info: client 4.109.210.187#55190: query: ngqrbwuzquz.5kkx.com IN A + (66.199.132.7)
18-Feb-2014 21:45:25.105 queries: info: client 91.82.209.221#33924: query: bgbtqcdtzen.5kkx.com IN A + (66.199.132.7)
18-Feb-2014 21:45:25.106 queries: info: client 6.29.8.224#4379: query: uehkaiy.5kkx.com IN A + (66.199.132.7)
18-Feb-2014 21:45:25.106 queries: info: client 67.27.41.169#44000: query: yqv.5kkx.com IN A + (66.199.132.7)
18-Feb-2014 21:45:25.107 queries: info: client 45.207.31.218#30585: query: e.5kkx.com IN A + (66.199.132.7)
18-Feb-2014 21:45:25.644 queries: info: client 95.217.89.95#5396: query: bfpofpj.5kkx.com IN A + (66.199.132.5)
18-Feb-2014 21:45:25.823 queries: info: client 89.47.129.187#12316: query: aocdesguijxym.5kkx.com IN A + (66.199.132.5)
18-Feb-2014 21:45:26.021 queries: info: client 15.205.106.62#34265: query: xqgyahfugnt.5kkx.com IN A + (66.199.132.7)
18-Feb-2014 21:45:26.057 queries: info: client 128.64.33.29#7584: query: ijwhqfmpohmj.5kkx.com IN A + (216.222.148.103)
18-Feb-2014 21:45:26.330 queries: info: client 102.206.85.254#8093: query: ibojknsrqjohib.5kkx.com IN A + (216.222.148.103)
18-Feb-2014 21:45:26.333 queries: info: client 40.121.221.81#10822: query: ebb.5kkx.com IN A + (66.199.132.5)
18-Feb-2014 21:45:26.752 queries: info: client 104.55.169.43#30108: query: l.5kkx.com IN A + (66.199.132.7)

Hey all,

DNS amplification spoofed source attacks, I get that. I even thought I
was getting mitigation down to acceptable levels.

But now this. At different times during the previous days and on
different resolvers, routers with proxy turned on, etc...

Thousand of queries with thousands of source ip addresses.

According to my logs, sources are not being repeated (or not with any
significant frequency)

What is the purpose of this?

Indirect attack on the 5kkx.com servers?

I couldn't resolve that domain or subdomains that I tried.

If that domain did respond, I'd guess it's tailored to be a large junky response. Varying the qname prevents people from using iptables to block specific queries.

Mark Andrews wrote:

What is the purpose of this?

Indirect attack on the 5kkx.com servers?

18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query:
swe.5kkx.com IN A + (66.199.132.5)

I have seen dozens of different second level parts.

How is this any more effective then sending it direct?

Pardon if I missed a memo, but how are your resolver systems receiving these thousands of very different source addresses?

Doug

Totally was trying to figure out how to ask the same thing. How exactly
are you the POC in this situation? lol

Resource-exhaustion attack against the recursive DNS?

If they're attacking the authoritative DNS servers for 5kkx.com, just reflecting gives them indirection and presumably makes traceback harder for 5kkx.com (at least, in the minds of the attackers).

Or maybe they're trying to game 5kkx.com into blocking requests from the recursive servers in question, for some reason.

so... i could be nuts, but in the example joe clipped, the resolved
hosts are either:
66.199.132.5
66.199.132.7
or
216.222.148.103

these are from 2 different PI blocks, but the same named end-user: chl.net.

maybe someone's upset with CHL, whomever that may be.

Fat-finger, sorry - should also state 'Or against the authoritative servers for 5kkx.com?'

apologies. both chl.net and chl.com ... which appear to be parts of
ttec ... which is joe.

Right. Nonzero chances that you (Joe's site) are the target...

Also, check if you have egress filtering of spoofed addresses below these
DNS resources, between them and any user objects. You could be sourcing
the spoofing if not...

Doug Barton wrote:

Thousand of queries with thousands of source ip addresses.

Pardon if I missed a memo, but how are your resolver systems receiving
these thousands of very different source addresses?

Doug

Thousands of queries _from_ thousands of source ip addresses

likely they are spoofed

this is an example of what I am seeing

root@nameserver3:~# baddnsqueries-srcs 9aq.com | wc -l
1337
root@nameserver3:~# grep 9aq.com /var/log/named/queries | wc -l
1415
root@nameserver3:~# baddnsqueries-srcs 9aq.com | sort -rn -k2 | head -n5
99.86.116.243 1
99.219.232.72 1
99.184.19.178 1
99.155.180.193 1
99.129.26.85 1
root@nameserver3:~# grep 9aq.com /var/log/named/queries | head -n5
18-Feb-2014 22:42:30.754 queries: info: client 93.209.49.151#59706: query: abpdefguvwxym.dlq1.9aq.com IN A + (66.199.132.5)
18-Feb-2014 22:42:30.787 queries: info: client 110.158.165.119#32438: query: ocpkxdfupiy.dlq1.9aq.com IN A + (66.199.132.7)
18-Feb-2014 22:42:31.382 queries: info: client 84.14.84.205#63722: query: abpqeftuiwklz.dlq1.9aq.com IN A + (66.199.132.7)
18-Feb-2014 22:42:31.649 queries: info: client 45.73.65.145#38948: query: pvtlirr.dlq1.9aq.com IN A + (66.199.132.7)
18-Feb-2014 22:42:32.679 queries: info: client 9.121.56.232#18395: query: amo.dlq1.9aq.com IN A + (66.199.132.5)

root@nameserver3:~# cat /usr/local/sbin/baddnsqueries-srcs
#!/bin/bash

if [[ "$1" == "" ]]; then exit 0; fi
grep -E "$1" /var/log/named/queries | cut -f6 -d' ' | cut -f1 -d# | sort

uniq |\

while read INPUT; do
         if [[ "$INPUT" == "" ]]; then
                 continue;
         fi
         echo $INPUT `grep $INPUT /var/log/named/queries | grep -c -E "$1"`;
done

Dobbins, Roland wrote:

What is the purpose of this?

Resource-exhaustion attack against the recursive DNS?

On anything that is going to stay open, not even close.

Premature send - I meant to add 'Or against the authoritative servers for 5kkx.com?'

We've been seeing a spate of reflected (not amplified) DNS attacks against various authoritative servers in Europe for the past week or so, bounced through some type of consumer DSL broadband CPE with an open DNS forwarded on the WAN interface (don't know the make/model, but it was supplied by the broadband operators to the customers), on some European broadband access networks.

Yes, got that bit. :slight_smile: What I'm asking is, why are spoofed queries hitting your "different resolvers, routers with proxy turned on, etc.?"

Are you running open resolvers? If so, please stop doing that, it's widely known to be a bad idea for over a decade now, and you are providing the bad guys a tool to use for DDOS attacks.

If it's something else, please speak up. Regardless of the goal of this particular issue, the way to solve the root problem is to prevent the spoofed packets from getting to your servers in the first place.

Doug

Doug Barton wrote:

Are you running open resolvers?

Yes

If so, please stop doing that,

No

it's
widely known to be a bad idea for over a decade now,

At this point, doing anything on the internet is a bad idea.

and you are
providing the bad guys a tool to use for DDOS attacks.

Get back to me when the same cant be done with auth servers.

George Herbert wrote:

Right. Nonzero chances that you (Joe's site) are the target...

Also, check if you have egress filtering of spoofed addresses below these
DNS resources, between them and any user objects. You could be sourcing
the spoofing if not...

It seems to me that the same|similar dataset of open resolvers to be used for amplification attacks is also being used for this sort of thing, and the overall effect is not large enough to indicate my resources are a target.

What I cant figure out is what is the target and how this attack method is any more effective then the others.

Joe

There are ways to deal with it on authoritative servers, like RRL.

The target appears to be the authoritative servers for the domain in question, yes?

The attacker may consider it more effective because it provides a degree of obfuscation, or maybe he has some reason to game the operators of the authoritative servers in question into denying requests from your recursors.

Most (not all) attackers don't know that much about TCP/IP, DNS, et. al, and they tend to copycat one another and do the same things due to magical thinking.