Home page logo

nanog logo nanog mailing list archives

Re: Tightened DNS security question re: DNS amplification attacks.
From: Mark Andrews <Mark_Andrews () isc org>
Date: Wed, 28 Jan 2009 11:50:55 +1100

In message < () 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 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 neq 53 any eq 53

Also on this topic:
Coincident with this DNS DOS, I started seeing inbound PTR queries from
various hosts on (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, 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
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 Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews () isc org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]