[dns-operations] DDoS botnet behaviour

[Kyle Creyts]

It seems to me that it might be pertinent to split this discussion
into clear threads. There are several different attack patterns being
discussed here, and it is my opinion that they have distinct and
different solutions, and may merit separated discussion, or at least
identification.

The < https://www.dns-oarc.net/wiki/mitigating-dns-denial-of-service-attacks
> page doesn't describe the categories of attacks for which the
mitigations provide remedy; hopefully someone clueful enough is
envolved in the remediation, but for the sake of completeness, it
might be expected that this information, or links to it, be included
in the wiki.

I'm not suggesting detailing every edge case, but I think a brief
summary might be in order.

Something brief describing the nature of several example cases for
which each mitigation is optimal, and maybe a pros/cons list for each
might be very useful to someone attempting to mitigate.


On Sun, Jun 10, 2012 at 4:36 PM, Vernon Schryver <vjs at rhyolite.com> wrote:
>> From: Jim Reid <jim at rfc1035.com>
>
>> My logs tended to have a few hundred entries at a time for the same
>> (spoofed?) IP address. So as soon as I blackholed the last IP address
>> in the log file, entries for another would be appended. At 4am and
>> there's a caffeine deficit, this looks like a new client has
>> immediately popped up to replace the one that's just been nuked. In
>> fact, the "new" IP address was already there and its queries were lost
>> amongst the noise of the other 100+ addresses that were firing crap at
>> the name server.
>
> That raises two issues.
>
> A problem with the response rate limiting code I've been working is
> logging.  One needs to be able to find out response have been rate
> limited and why.  To answer that question, my current logging code
> simply logs to a new BIND9 category whenever it drops a response (or
> would have dropped when in test mode).  The problem is that even on
> my small DNS servers that generates too much noise.  My plan is to
> change from instantaneous to retrospective logging that says something
> equivalent to "10.2.3.4 recently asked 27 times for A records for
> example.com and the last 13 responses were dropped."
>
>
> The second issue concerns log noise and the popular enthusiasm for
> using Bloom filters for DNS response rate limiting.  I've heard more
> than one suggestion for using Bloom filters for DNS response rate
> limiting.  Bloom filters are a great idea for some things but I think
> they a problem instead of a solution here.  The problem is suggested
> by the word "probabilistic" in "Part of a series on Probabilistic data
> structures" on https://en.wikipedia.org/wiki/Bloom_filter
>
> It's like the difference between accounting and statistics.  You don't
> (and for privacy reasons must not) care exactly how many nearby
> households have incomes above or below twice the median for your
> neighborhood.  A statistical statement like 99.9% of your neighbors
> earned $31,000 +/-$10,000 is fine.  On the other, accounting hand,
> you'd be unhappy if your bank told you that 0.1% of your bank statements
> would be fiction, and you'd have to guess which.
>
> Bloom filters have false positives.  If you know enough about your
> data, you can make the false positive probability as low as you like,
> but you cannot make that probability zero without giving up the reasons
> why you chose a Bloom filter.  Never mind the difficulities in knowing
> enough about your DNS query stream, and not that it is always a
> probability distribution as opposed to a rate.  Computing that
> distribution depends on hard to answer questions such as how independent
> your hash functions really are on your real data.
>
> The connection with logging is that you need to be able to answer
> the question "Why did your DNS server drop my requests?"  With any
> sort of probabilistic filter including Bloom filters, you won't be
> able to say "You sent more than X requests" without turning on
> query-logging and slogging through GBytes of log lines.
>
> I think doing the retrospective logging I plan would make any Bloom
> filter scheme equivalent to a straight forward hash table.  Log messages
> saying "IP addresses that the filter says are the same recently asked
> 27 times for A records for example.com and the last 13 responses were
> dropped" would not satisfy people wanting to know why their customer's
> browsers are stalling when trying to get to their web sites.
>
>
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
Kyle Creyts

Information Assurance Professional
BSidesDetroit Organizer