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?

Totally was trying to figure out how to ask the same thing. How exactly are you the POC in this situation? lol On 2/18/14, 7:35 PM, "Doug Barton" <dougb@dougbarton.us> wrote:

On 02/18/2014 07:08 PM, Joe Maimon 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

On 02/18/2014 07:59 PM, Joe Maimon wrote:

Doug Barton wrote:

...

On 02/18/2014 07:08 PM, Joe Maimon 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

Yes, got that bit. :) 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

On Feb 19, 2014, at 12:44 PM, Joe Maimon <jmaimon@ttec.com> wrote:

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

There are ways to deal with it on authoritative servers, like RRL. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Feb 19, 2014, at 1:07 PM, Joe Maimon <jmaimon@ttec.com> wrote:

There are ways to deal with it on resolvers as well, like RRL and IDS and iptables

None of these things work well for recursive resolvers; they cause more problems than they solve. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

Hello everyone I can see such crap traffic from over couple of weeks now but yes it appeared all of sudden and I was also wondering if I am alone experiencing it. 2014-02-19 14:30 GMT+08:00 Joe Maimon <jmaimon@ttec.com>:

Dobbins, Roland wrote:

...

On Feb 19, 2014, at 1:07 PM, Joe Maimon <jmaimon@ttec.com> wrote:

There are ways to deal with it on resolvers as well, like RRL and IDS

...

and iptables

None of these things work well for recursive resolvers; they cause more problems than they solve.

Whatever I am doing appears to be working, at least until this cropped up.

Joe

-- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2

On Tue, Feb 18, 2014 at 10:44 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:

On Feb 19, 2014, at 10:08 AM, Joe Maimon <jmaimon@ttec.com> wrote:

...

What is the purpose of this?

Resource-exhaustion attack against the recursive DNS?

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.

On Feb 19, 2014, at 10:48 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

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

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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Feb 19, 2014, at 10:44 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:

Resource-exhaustion attack against the recursive DNS?

Fat-finger, sorry - should also state 'Or against the authoritative servers for 5kkx.com?' ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

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

Dobbins, Roland wrote:

On Feb 19, 2014, at 12:48 PM, Joe Maimon <jmaimon@ttec.com> wrote:

...

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

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

I dont think so, but I have not compiled the full list of domains and compared the auth servers for each.

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.

----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

Owen DeLong wrote:

On Feb 18, 2014, at 9:48 PM, Joe Maimon <jmaimon@ttec.com> wrote:

This assumes several facts not in evidence:

1. It is an attack. 2. It is deliberate 3. There is a target 4. It is more effective than others

On what do you base those assumptions? To me this looks to be far more likely to be someone’s wayward script, experiment, software, tool, etc. doing something it probably isn’t supposed to be doing.

I have found this occurring on unaffiliated open resolvers (that I happen to support and that I was able to make the choice to close) It has been ongoing for a week or so (but not constant). The domain names have a pattern but are comprised of components that appear to be randomly generated. The source IP addresses for the queries appear to be non duplicated and randomly generated. query logs are available for unicasting to the interested. Has nobody else seen this?

If it happens to also be gathering the answers or information that the author wants (or appears to be doing so), then the author may well be blissfully ignorant of its wayward behavior towards your servers.

Owen

I would like to figure out how. Joe

Dobbins, Roland wrote:

On Feb 19, 2014, at 10:08 AM, Joe Maimon <jmaimon@ttec.com> 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.

Davis, Having seen this in the past, and managing both open resolvers and authoritative servers for several large eyeball networks, I think your assumption is correct this definitely smells like C&C traffic being handled via DNS. Just my 2c - YMMV - All sales final, As is - Dale Rumph - Network Engineer/Security Consultant On Feb 19, 2014 10:58 AM, "Beeman, Davis" <Davis.Beeman@integratelecom.com> wrote:

I am late to this train, but it appears no one else has brought this up. It is a DNS tunneling setup, not an attack. I have been dealing with one of these lately as well. They were using some open resolvers in my network to reflect, but the "random" hostnames in the queries are tunneled traffic or keywords. The original sources of the traffic are probably members of a botnet, and this is being used as a sneaky C&C method. Due to the tiny amount of data you can send in the DNS query name field, this will sort of look like an attack, because they have to send thousands of queries to get anything done.

They are not attacking the authoritative name servers in those domains, as has been suggested, rather the authoritative name server in these domains is the rouge DNS server in use by the bad actor running a botnet.

Davis Beeman Network Security Engineer

-----Original Message----- From: Joe Maimon [mailto:jmaimon@ttec.com] Sent: Tuesday, February 18, 2014 19:08 To: North American Networking and Offtopic Gripes List Subject: 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)

Le 2014-02-19 11:28, Dobbins, Roland a écrit :

...

I am late to this train, but it appears no one else has brought this up. It is a DNS tunneling setup, not an attack.

This makes a lot of sense - good insight, will look into this further!

I use this for free wi-fi in airports and such: http://code.kryo.se/iodine/ If the wi-fi is configured to use an open resolver, we end up with the situation you describe. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca

Beeman, Davis wrote:

rather the authoritative name server in these domains is the rouge DNS server in use by the bad actor running a botnet.

Davis Beeman Network Security Engineer

Somebody must be registering these domain names. And I should be able to compile a list of the auth servers in question. Joe

On 02/20/2014 08:57 AM, Pavel Zeleny wrote:

Masataka Ohta <mohta <at> necom830.hpcl.titech.ac.jp> writes:

...

Joe Maimon wrote:

...

What is the purpose of this? ... Masataka Ohta

Hi guys, for a second, have you any clue how to block this traffic on DNS server side? As our company operates recursive resolvers for our customers, we can see this weird traffic concentrated in our logs. It started Feb 3 about 16:30 (GMT/UTC+1). Very large amount of DNS A queries are sent from source IP addresses of our customers, and they always looks like [randomjunk].SLD.com. We have seen 143 this SLD's so far, and we had to block it manually one by one. We suspect some kind of botnet, because attack wave with new SLD's starts at the same time, coming from broad range of valid non-spoofed source IP addresses. Content of UDP packets belonging to this traffic doesn't seem to have any identical pattern.

Any ideas are highly appreciated. Thank you!

Pavel Zeleny

iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP So, every prefix (length 28) can send 20 r/s with allowed bursts of 100. This requires a Netfilter >= 1.4 (recent options of module hashlimit). -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com