At 09:21 PM 1/27/2009, Paul Vixie wrote:
"Douglas C. Stephens" <steph...@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: steph...@ameslab.gov
