Mark Andrews wrote:
> In message <6.2.3.4.2.20090127162808.02d4a...@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?
