Discussion:
[Unbound-users] a mitigation against random subdomain attack
Daisuke HIGASHI
2015-03-22 12:31:34 UTC
Permalink
Hi,

I have implemented mitigation against random subdomain DoS attack (or
sometime referred as water torture attack) for Unbound utilizing
bloomfilter.

https://github.com/hdais/unbound-bloomfilter

It learns qnames which resulted in noerror using bloomfilter in peace
time. When a domain is set to be bloomfiltered (manually or
automatically) it accepts only qnames to be noerror for the domain.

This effectively refuse only bad random queries that result would be
nxdomain while keeping the domain resolvable.

Regards,
--
Daisuke HIGASHI
Maciej Soltysiak
2015-03-24 10:57:54 UTC
Permalink
Hi Daisuke,
Post by Daisuke HIGASHI
Hi,
I have implemented mitigation against random subdomain DoS attack (or
sometime referred as water torture attack) for Unbound utilizing
bloomfilter.
https://github.com/hdais/unbound-bloomfilter
It learns qnames which resulted in noerror using bloomfilter in peace
time. When a domain is set to be bloomfiltered (manually or
automatically) it accepts only qnames to be noerror for the domain.
This effectively refuse only bad random queries that result would be
nxdomain while keeping the domain resolvable.
This is interesting; can you help me understand where does the 9.6 bits
come from?

Also, what would a false positive here be?
A random query that was allowed or a legitimate query that was refused?
Post by Daisuke HIGASHI
Regards,
--
Daisuke HIGASHI
Maciej
Daisuke HIGASHI
2015-03-24 12:55:10 UTC
Permalink
Hi Maciej,
This is interesting; can you help me understand where does the 9.6 bits come
from?
See mathematics in http://en.wikipedia.org/wiki/Bloom_filter .

In current code, k is set to 7, optimizing memory size at
approximately 1% false positive. Under this params you need
only 9.6bits memory per element (unique noerror qnames).

If you think 1% is too high, set k to 10 for 0.1% false positive rate
and you will need 14.5bits per element.

k is set at second arg in daemon.c:bf_create(). Sorry for ugly magic number.
Also, what would a false positive here be?
A random query that was allowed or a legitimate query that was refused?
A false positive is "a random query that was allowed".

Bloomfilter never refuse known qnames. However obviously legitimate
but very rare qnames (names which no client queried in past)
would be refused.

Regards,
--
Daisuke HIGASHI

Loading...