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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
