Tightened DNS security question re: DNS amplification attacks.

Wed Jan 28 00:58:34 UTC 2009

Mark Andrews wrote:
> In message <6.2.3.4.2.20090127162808.02d4ae50 at imap.ameslab.gov>, "Douglas C. St
> ephens" writes:
>> At 03:16 PM 1/27/2009, Nate Itkin wrote:
>>> On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote:
>>>> < ... snip ... >
>>>> dns queries to the . hint file
>>>> are still occuring and are not being denied by our servers. For example:
>>>> 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view
>>>> external-in: query: . IN NS +
>>>> < ... snip ... >
>>>> since you can't put a "allow-query { none; };" in a hint zone, 
>>> what can I do
>>>> to deny the query to the . zone file?
>>>
>>> AFAIK, that's about the best you can do with the DNS configuration. You've
>>> mitigated the amplification value, so hopefully the perpetrator(s) will drop
>>> you. If you're willing to keep up with the moving targets, the next level
>>> is an inbound packet filter. Add to your inbound ACL:
>>>
>>> deny udp host 64.57.246.146 neq 53 any eq 53
>>>
>>> Also on this topic:
>>> Coincident with this DNS DOS, I started seeing inbound PTR queries from
>>> various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers).
>>> They receive no response, yet they persist.  Anyone have thoughts on their
>>> part in the scheme?
>>>
>>> Best wishes,
>>> Nate Itkin
>> I'm not seeing those PTR queries for 10.0.0.0/8, but then my perimeter
>> ingress/egress filters (BCP 38) toss most of that kind of junk before my
>> DNS servers ever see it.
>>
>> I agree that is as far as one can go with BIND, right now.  However, that
>> isn't making the perpetrators cease and desist.  I am seeing ongoing query
>> attempts coming in and refusal packets going back out, and the targets
>> don't seem to change until I do something to block them.  So mitigating
>> the amplification factor does not seem of interest to these perpetrators.
>> On the contrary, even REFUSED responses can aggregate with some amplified
>> responses to enhance the apparent DoS goal.  Thus BCP 140 seems to be
>> less than completely effective because it is less than universally applied
>> (i.e., older versions of BIND or misconfigured BIND.)  I think the same
>> situation is true with BCP 38: less than universally applied.  So do I wait
>> for universal application of these BCPs, or do I take responsibility for
>> doing what I can to make my network resources less appealing for abuse?
>>
>> I choose the latter, and that is why went to the effort of blocking this
>> abusive traffic before it reaches my authoritative-only DNS servers.
>> Nevertheless, I also agree with a point made last week that trying to keep up
>> with the changing targets is a game of whack-a-mole that is and will continue
>> to be a drain on network management resources -- if the detection and respons
>> e
>> continues to be deployed manually.  This is why I wrote some Perl for my
>> authoritative-only servers to automate detection and response at the server
>> level.  Granted it isn't a permanent solution, but at least it is a place
>> to start.  I appended that code below for those who are interested in it.
> 
> 	Which will just make the attacks evolve.  It's pretty easy
> 	to design a amplifing DNS attack which is almost indetectable
> 	unless you know which addresses are being targeted.  This
> 	one is highly visible in the logs.
> 
> 	A much more productive task would be to trace back the
> 	offending traffic and to put into place policies which
> 	require BCP 38 deployment by those you connect to.
> 
> 	Mark

Are we still seeing DNS DDoS attack?