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