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