Tightened DNS security question re: DNS amplification attacks.

Douglas C. Stephens stephens at ameslab.gov
Wed Jan 28 18:32:04 CST 2009


At 09:21 PM 1/27/2009, Paul Vixie wrote:
>"Douglas C. Stephens" <stephens at ameslab.gov> writes:
>
> > ...
> > 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.
>
>this is an odd implementation choice.  the 1PPS query stream is still using
>your line even with this defense in place.  the 1PPS response stream and the
>CPU cycles it takes to generate that stream isn't a burden on you (compared
>to the 1PPS query stream that you can't stop anyway).  so the only reason to
>block these appears to be so that you don't participate in the attack, or in
>other words to cut down the burden on the victim.  with me so far?
>
>the burden on the victim isn't going to drop materially by what you did since
>hundreds of thousands of other servers are not going to block it.  but if the
>victim is a recursive nameserver, then your blocking them will mean that they
>cannot access the zones you're authoritative for.  so, no positive, but some
>negative, for the only person in the whole equation who can be affected by
>the blocking you're doing.
>
>i don't get it.  with a cost:benefit matrix like that one, why is anybody
>blocking this traffic?  (i note with some alarm that ten years after i shot
>it down, i still get queries to rbl.maps.vix.com, so the possibility that the
>blocks some folks might put in place to ...manage?... this attack will have a
>long term bad effect on our heirs and assigns.  i know your perl script will
>expire things 60 seconds after they stop spewing, but i fear that others are
>blocking these in hardcode.
>
>(looking for ". IN NS" as the q-tuple pattern is not a solution, since the
>bad guys can pretty trivially change the question they ask into one you're
>willing to answer.)
>
>(REFUSED is nice because it's small, but the bad guys aren't lacking for bots
>to transmit spoofed packets from, they Do Not Need amplification, and all
>forms of error rate limiting are also new attack vectors.)
>
>(is there a name-and-shame registry for networks that do/don't implement
>BCP38? if not i guess i'll start one and hope that various auditors will use
>google and notice me.)
>--
>Paul Vixie


Paul,

Arrrg.  I checked and you're right about the ACL blocking potentially
legitimate queries from the victim's IP address of authoritative
zones served from my authoritative-only DNS servers.  This is an issue
if the victim is running a recursive DNS server at that IP address.
However, is this really an issue if the victim is running a non-
recursive DNS server or another kind of server at that IP address?  In
the latter case, I think not.  In the former case, maybe, if it is an
authoritative-only DNS server that doesn't call its own system stub
resolver, or if it is a forwarding DNS server configured to query my
authoritative-only servers (though goodness knows why someone would
want to do that).  Obviously my code did not vet the detected IP
address for these cases, and I don't see any way to do so.

The 1 pps query stream is not a burden to my line, nor to my servers.
My goal was to make it more difficult for these perpetrators to relay
this garbage off my authoritative-only servers, and thus reduce the
abusive traffic being reflected towards their target(s).  As you said,
the "bad guys" aren't lacking for bots, and they don't need, nor seem
interested in, amplification.  I hadn't noticed BIND having any handles
to turn for this.  Maybe I'll work on that, or just rebuild my kernels
to include the u32 IPtables module.

As for why to block near the reflector?  Given the cost/benefit you
pointed out, and using my tool or other simpler ACLs, you're right, it
doesn't make sense.  However, using proper DPI tools (which obviously
my tool was not), why shouldn't those who are able to block near the
reflector?  A variation on the IPtables u32 rule I saw posted
elsewhere, or a handle to turn in BIND, based on signatures of known
abusive query patterns would accomplish for DNS attack vector what
anti-virus has been doing for decades for workstation and server
systems, would it not?  (Yes, yes, I know, signature-based tech is
bloated and dying, and behavioral tech is the wave of the future,
but right now signatures are all there is for this attack vector.)

To address another critique of the posting of my tool, evolution of
this form of attack is inevitable.  For example, several people have
suggested that the next variation will be to change the query data
from asking for a root referral to asking for some other zone for
which my authoritative-only servers are not authoritative.  I'm not so
sure, though, about the "bad guys" changing their query into something
my authoritative-only servers should answer and not REFUSE.  I think
changing to querying for a zone my servers are authoritative for would
come after simple permutations of their initial static query signature.
Though it may be a recent innovation to use a botnet to carry out these
attacks, the vector itself is not new, and they started with a simple
static query signature. Their botnet CinC channels seem sophisticated
enough to divide labor to send out spam, but are they sophisticated
enough to determine which zones I host authoritative-only and then
hammer out spoofed-source-address queries for only those zones?  If not,
then a signature-based DPI blocking tool would likely have an appreciable
dampening effect.  If so, then at least it would raise the bar, as has
most other anti-virus and anti-spyware tech.

Anyway, I think the "bad guys", if they cared at all, will already be
aware of the fact that the community has identified their attack
signature.  This is because either they are monitoring the down-ness
of their targets, or because folks on this list and others have been
posting details about identified targets since last week.  In some way
they must be aware when targets are identified by the community, since
the targets keep changing as they are found and dealt with.

Finally, I agree with Mark Andrews that BCP 38 is the ultimate best
response, right now, and that a cooperative community of network
operators working together is the best way to track down from where
this garbage is coming.  At least that is when said community is small
enough and clueful enough.  I should wonder, though, (as have others
on this list) if the operators of the network(s) where these spoofed
query packets originate are complying with BCP 38?  Or if the operators
of the networks upstream are complying with it?  Also, that is assuming
that the packets are originating from sufficiently stubby networks
where BCP 38 can be applied.  Yep, I'm full of cheery thoughts like
these.



--
Douglas C. Stephens             | UNIX/Windows/Email Admin
System Support Specialist       | Network/DNS Admin
Information Systems             | Phone: (515) 294-6102
Ames Laboratory, US DOE         | Email: stephens at ameslab.gov 





More information about the NANOG mailing list