Subject: [ietf-dkim] Re: Amplification attack solution.

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 1 Mar 2006 14:30:54 -0800 (PST)

On Tue, 28 Feb 2006, Hallam-Baker, Phillip wrote:

>> Just so you know the current cisco.com DKIM record results in
>> 342bytes message data (do "dig txt
>> nebraska._domainkey.cisco.com") and security of this key is
>> may not be sufficient and many will probably use 2k ones in
>> the future. The original packet request to retrieve that key
>> was 40-50 bytes in size (only QUESTION section). My estimates
>> is that just one dns server with DKIM record abused by this
>> attack should give about 8x amplification effect (if you like
>> I can write specialized scripts and give exact numbers for
>> several sites).
>
> Unless you are sending the requests out to multiple servers the DNS
> server that is the subject of the attack is going to be throttled by 
> its outbound bandwidth. You can only get the multiplier effect if
> 1) the DNS server is on a bigger pipe than the machine attacking it

In almost all cases that is exactly how it is (i.e. attacker on DSL
and DNS server in colo at datacenter with 100mb or Gb connectivity)

> 2) the DNS server that is attacked has no throttling capability of its 
> own.

In almost all cases that is also how it is right now as well.

> I don't know about you but if I was writing a DNS server I would
> probably have put code in it to prevent this type of attack quite some
> time ago. Otherwise the DNS server is vulnerable to DDoS attack itself.

It is and such attacks directly on dns servers do happen infrequently.
Putting specialized firewalls and advanced coding does not seem to be 
worth it for average installation.

And the real cases of dns amplification that we're seeing in the last few 
months is that each server that is being used is not getting overloaded
because bad guys have a lot of servers (several thousand) to play with 
that have recursion turned on, but overall result is multi-GB DDos 
attack on target. This is typical for distributed attack scenarios.

> A solution is very simple:
>
> 1) keep a cache of the past 10 or so recent requests plus identified
> attacks
> 2) When a new request comes in see if the purported source matches the
> recent request list
> 3) if match not found, insert request in cache, return
> 4) if match found increment tracking counter
> 5) if indicated frequency exceeds threshold, mark as identified attack
> 6) respond to only requestsize/responsesize% of identified attacks
>
> That took me less than ten minutes to think up and I'll bet that similar
> code is already in BIND and that DJB has an even better way to do it.

I do not want to say for sure (especially as I do not use DJB's code) but
I do not think this is part of existing DNS servers code.

What you describe above might be helpful to deal with DDos against DNS 
server itself, I'm not at all sure if this can be tuned for when dns
server is being abused as middle-party. I do not think it is implementable
in such a way that it can be properly tuned because for large dns server 
there are going to be hundreds or thousands (more?) requests per second 
and the attacker packets may well be seen quite a bit less then one in 
last 10 or 100 requests (this really depends on installation site), on
the other hand if number of large requests being watched for is too large, 
it may result in denial of legitimate requests.

I do want to point out again that existing DNS system can already be
abused when you have cases of large dns server records. The reason that
it did not become popular is that number of such servers with very large
records is small and they are very hard to find. This makes them an
inconvenient choice and if the number of intermediaries in DDos is too
small, those intermediate systems will all notice the abuse (because of
greatly increased traffic or server load) and quickly deal with it.

What makes it different is that DKIM deployment would greatly increase
(by several orders of magnitude probably) number of such large records
as well as make it easy to find.

-- 
William Leibzon
Elan Networks
[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html