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&0...@12>>16=1&&0>>22&0...@20>>24=0&&0>>22&0...@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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
