> 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
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

Reply via email to