will blocking getting hammered by cache request do anything?

[David Forrest]

On Sun, 8 Mar 2009, enigmedia wrote:

>>> Hi All: my 9.6.0 server is getting hammered by cache requests from a
>>> specific IP (62.109.4.89) which traces back to what looks like a DSL
>>> netblock in Russia:
>>>
>>> 05-Mar-2009 12:18:01.883 queries: info: client 62.109.4.89#53157: query: .
>>> IN NS +
>>> 05-Mar-2009 12:18:01.883 security: info: client 62.109.4.89#53157: query
>>> (cache) './NS/IN' denied
>>>
>>> I assume that this is some unpatched server (because currently I only see
>>> this single IP trying to connect), but is there any way to tell the
>>> difference between that and a deliberate DDOS attack?
>>
>> Actually, this is almost certainly someone trying to use your server as
>> part of a DNS amplification attack ON that server.  The source IP is
>> spoofed, with the goal of getting lots of servers to send large replies
>> to it.  But since you have recursion and query-cache disabled for
>> external IPs, you're not amplifying anything.
>>
>> My subnet is on a Verizon 3Mbps static "business" DSL connection with a
>> router/firewall NAT'ing the incoming traffic.
>>
>>> My question is, will blocking this from the firewall in front of the box
>>> help in any way to mitigate it's effect on the server? Or do I need to get
>>> my upstream provider to block this IP for it to have any impact? The server
>
>>> isn't "choking" on the volume of requests (yet), and I'm wondering if
>>> blocking the requests at the border of the network would do anything
>>> meaningful?
>>
>> If you block it on the firewall, then the requests will never hit the
>> server, so of course it will mitigate its effect on the server.  It
>> won't help with the downstream bandwidth on your DSL, but it will stop
>> the "REFUSED" replies from being sent back, so your upstream bandwidth
>> will improve.
>
> Thanks Barry: you mentioned that the IP is being spoofed...does that mean the
> IP in the log is not the actual IP that sent the request? If so, would blocking
> it actually work?
>

This question has come up before and I commented thusly with a response 
from Mark Andrews:

> Using allow-query to deny some queries still takes time and resources
from your server as it then sends a "denied" message back to the query 
source. As the source is spoofed it then contributes in a small way to the 
DDoS attack.  I think it is better to just drop the queries on your 
firewall. I found this entry for iptables on the list a while back and it 
works well and drops around a thousand queries a day.

iptables -A INPUT -i $LOCALIF -j DROP -p udp --dport domain -m u32 --u32 
"0>>22&0x3C at 12>>16=1&&0>>22&0x3C at 20>>24=0&&0>>22&0x3C at 21=0x00020001"

Mark replied:
Well you opinion does not match the collective wisdom of dnsop and
dnsext working groups.  These working groups looks at the issue a
while ago and concluded that sending REFUSED was the best response
overall.  Unless you know the packet was forged then dropping it
does additional damage.  Send REFUSED turns you from a amplifies
into a obscurer.

The best thing you can do is make sure that you have deployed BCP
38 on your network.  This will prevent you being a source of spoofed
traffic.

The next best thing you can do is track or get your ISP to track
the offending traffic back to its source and request the BCP 38 be
deployed there.

That way everybody in the world is in a better position.  You can't
detect all reflection attacks at the reflector.  This one is a easy
one to detect.  You can however work to close down the holes in the
global BCP 38 defences.  This attack provides a perfect opportunity
to chase down those holes.

Mark


Mark made that comment and it made sense to me.  A thousand queries daily 
is a negligable load on my server and being an obscurer could be a good 
thing.  Dropping the queries at the firewall does make my logging easier 
to scan though, and, being selfish, I have opted to continue dropping 
them.  I'm just a small user and it is the path of least resistence.  I 
have noticed the attacks are sporadic and I'll go a week or so without 
any and then they recur for a couple of days.

Dave

-- 
David Forrest
St. Louis, Missouri