Re: will blocking getting hammered by cache request do anything?
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? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: will blocking getting hammered by cache request do anything?
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 0220...@1216=10220...@2024=00220...@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
Re: will blocking getting hammered by cache request do anything?
One thing I should add is that chasing down lack of BCP38 compliance isn't wack-a-mole though it may feel like it. This is a configuration change and as such tends to be premanent especially once it get written into the procedures documents. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
will blocking getting hammered by cache request do anything?
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? 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? Of course, it's prolly not realistic to expect Verizon to do anything above my router. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: will blocking getting hammered by cache request do anything?
In article goov30$ng...@sf1.isc.org, online-reg online-...@enigmedia.com 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. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
