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
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html