[Unbound-users] Python API extension patch proposal

Stephane Lapie stephane.lapie at darkbsd.org
Mon Jan 5 09:40:06 UTC 2015


> On 2015-01-05 17:42, Tarko Tikan wrote:
> hey,
>> I am currently in the process of dealing with water torture attacks on
>> our cache DNS servers (<randomstring>.domain.com queries that never
>> resolve and end up causing enormous upstream traffic, ultimately
>> crushing the authoritative server for domain.com).
> I wrote https://github.com/tarko/unbound-reqmon while ago to mitigate
> this issue. This will block the domain that is being used for the
> abuse.
> PS! It will need constant attention because it will happily block
> co.uk, com.tw etc. at this point. The logic must really be improved if
> these attacks persist.

Yes, I did something similar to this (crunching unbound logs -> local zone), however, as mentioned in my first mail, there is the need to avoid TLDs,
and to figure the longest delegation point for sure, to be 100% sure of what you will end up auto-blocking.

We threw that idea out of the window when "co.jp" got locked out in the dead of the night because one of our corporate customers hammered our DNS server with infected clients on his ActiveDirectory network. (more than 1000 queries on "whatever.domain.co.jp" -> cut last two units -> "co.jp" -> OOPS.)

In Japan, these attacks have reached a point where manual handling and whack-a-mole are not realistic anymore, also the delegation point information lies in the infra cache, and execution of unbound-control is extremely expensive performance-wise, so I came to the conclusion that this processing is best done within Unbound itself, as a patch or a python module.

Alternatively, thinking back to your method : it might be a sound idea to patch unbound-control itself, and to add an option that list requests along with their delegation point name, to perform what you are doing in a more safe manner.

Cheers,
-- 
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo


More information about the Unbound-users mailing list