[dns-operations] "NS .", the attack of the month?

[Matthew Pounsett]

On 24-Jan-2009, at 18:11 , Noel Butler wrote:

> On Sun, 2009-01-25 at 08:45, Stephane Bortzmeyer wrote:
>>
>> On Sun, Jan 25, 2009 at 08:39:27AM +1000,
>>  Noel Butler <noel.butler at ausics.net> wrote
>>  a message of 65 lines which said:
>>
>> > iptables -A INPUT -p udp --dport 53 -m u32 --u32
>> >  
>> "0 
>> >>22&0x3C at 12>>16=1&&0>>22&0x3C at 20>>24=0&&0>>22&0x3C at 21=0x00020001" -j
>> > DROP
>>
>> Cute :-) I hesitate to deploy a trick that I have trouble to
>> verify. Isn't it better to just follow the recommendations in
>> <https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful 
>> >?
>
> No, that advice is outright wrong! Contributing to the DDoS,  
> (although we should have all be doing it anyway in general) because  
> you are sending the REFUSED pkt back to the victim, so they are  
> essentially telling you how to participate in the DDoS.
>
> extract " Then, a query such as ". IN NS" should result in a REFUSED  
> response."
>
> It's also no longer just ISPrime thats the victim, I am seeing other  
> targets for past 24 hours.

Since you didn't provide a description of what your rule is supposed  
to do, I'm going to have to make an assumption about that.  I'm  
guessing you're looking for queries for ".".  If that's the case, it's  
easily avoided by the attacker sending you queries for "a.".. and then  
when you block that, "b." and so on until they're sending you queries  
for "com." or any other random short QNAME.  You can't enumerate all  
the hosts you're not authoritative for in iptables, and neither is it  
practical to enumerate all of the hosts you are authoritative for.

The config change to emit REFUSED is within the protocol spec, and  
brings the amplification component down to the point where using a  
reflector no longer assists the attacker.  Here's a sample tcpdump of  
a query sent to a server that responds with a REFUSED opcode:

18:42:44.650625 IP (tos 0x0, ttl 64, id 5375, offset 0, flags [none],  
proto UDP (17), length 45) source.host.com.53253 >  
dest.host.com.domain: [udp sum ok] 42422+ NS? . (17)
18:42:44.689461 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto  
UDP (17), length 45) dest.host.com.domain > source.host.com.53253:  
[udp sum ok] 42422 Refused- q: NS? . 0/0/0 (17)

Note the identical query size in the parens at the end of each line.   
The spoofed source, and the response "attack" packet are exactly the  
same size, which means there is no amplification going on here, which  
means there is no encouragement for the attacker to use the reflector.  
They get the same affect as spoofing traffic directly at the target.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20090124/3237e8d4/attachment.sig>