<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">BIND 9.11 has minimal-any option that’s helpful to reduce the attack impact: <a href="https://www.isc.org/blogs/bind-release-911/">https://www.isc.org/blogs/bind-release-911/</a><div><br></div><div>RRL should also help to limit the responses: <a href="https://kb.isc.org/docs/aa-01000">https://kb.isc.org/docs/aa-01000</a><br><br>Usually the source IP is spoofed, so blocking it might be causing collateral damage in case the target of the attack is a resolver, but again in general case fail2ban that parses named log files might be a good option to add a temporary ban on the ip. Just bear in mind you are not blocking the attacker, but the victim.<br><br>Ondrej<br><div dir="ltr"><div>--</div>Ondřej Surý — ISC (He/Him)<div><br></div><div>My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.</div></div><div dir="ltr"><br><blockquote type="cite">On 13. 4. 2021, at 6:17, Paul Kosinski via bind-users <bind-users@lists.isc.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>We also get *lots* of suspicious queries of the same kind, from various privileged and unprivileged ports, which I'm pretty sure are DDoS attempts. For example:</span><br><span></span><br><span> 12-Apr-2021 23:44:17.767 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied</span><br><span> 12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied</span><br><span> 12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query (cache) 'sl/ANY/IN' denied</span><br><span> 12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#80 (sl): query (cache) 'sl/ANY/IN' denied</span><br><span></span><br><span>Besides not wanting to be an unwilling DDoS amplifier, these bother me because they're filling up my BIND/named log files.</span><br><span></span><br><span>I've tried using IPtables hashlimit to throttle the requests, but have had little success. I've even tried blocking the responses with IPtables packet content matching plus hashlimit, but that doesn't help my log files!</span><br><span></span><br><span>============================================</span><br><span></span><br><span>On Mon, 12 Apr 2021 20:41:13 +0100 (WET-DST)</span><br><span>Peter Coghlan <bind@beyondthepale.ie> wrote:</span><br><span></span><br><blockquote type="cite"><span>Hello,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have a nameserver which is authoritative for three or four domain names.</span><br></blockquote><blockquote type="cite"><span>It receives around 1000 queries per day that could be regarded as plausably</span><br></blockquote><blockquote type="cite"><span>legitimate. It receives around ten times that number of absive queries per</span><br></blockquote><blockquote type="cite"><span>day from presumably spoofed ip addresses, the vast majority of them IN ANY</span><br></blockquote><blockquote type="cite"><span>queries for the "sl" domain or for the root nameservers all of which my</span><br></blockquote><blockquote type="cite"><span>nameserver responds to with return code 5 ie refused.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>In many cases, the source port is a low number such as 53, 80, 96 or 443</span><br></blockquote><blockquote type="cite"><span>for example which might make some sense if these were TCP queries but they</span><br></blockquote><blockquote type="cite"><span>are all UDP queries and apart from attempting to target port 53, attempting</span><br></blockquote><blockquote type="cite"><span>to target the other low UDP port numbers make no sense to me.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have searched high up and low down for any discussion about this kind</span><br></blockquote><blockquote type="cite"><span>of abuse and found very little regarding abusive queries for the root</span><br></blockquote><blockquote type="cite"><span>nameservers, none at all regarding the sl domain (although it is a difficult</span><br></blockquote><blockquote type="cite"><span>term to search for) and nothing at all regarding the oddball source ports</span><br></blockquote><blockquote type="cite"><span>either.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Even though the "refused" responses from my nameserver are "small", the</span><br></blockquote><blockquote type="cite"><span>general persistence of the abusers over a long period of time suggests to</span><br></blockquote><blockquote type="cite"><span>me that they are finding these queries effective for some kind of abuse,</span><br></blockquote><blockquote type="cite"><span>perhaps by way of having a very large number of nameservers return them</span><br></blockquote><blockquote type="cite"><span>(unless they are too stupid to care whether the queries are answered or</span><br></blockquote><blockquote type="cite"><span>refused which I suppose is also possible).</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>As far as I can see providing no response at all in any instance when a</span><br></blockquote><blockquote type="cite"><span>code 5 refused response would normally be returned would be the appropriate</span><br></blockquote><blockquote type="cite"><span>thing for my nameserver to do here and doing this would cause no difficulties</span><br></blockquote><blockquote type="cite"><span>at all with any legitimate queries or anyone who is not an abuser. Am I</span><br></blockquote><blockquote type="cite"><span>correct here?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have searched for a way to prevent my nameserver from responding</span><br></blockquote><blockquote type="cite"><span>to these queries at all in order to reduce the impact on the targets</span><br></blockquote><blockquote type="cite"><span>of this abuse. All results of my research point to the use of</span><br></blockquote><blockquote type="cite"><span>rate limiting as the only approach available for dealing with this</span><br></blockquote><blockquote type="cite"><span>sort of issue.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The abusive queries are clearly designed to circumvent the widely</span><br></blockquote><blockquote type="cite"><span>suggested "errors-per-second 5" as they arrive in groups of five</span><br></blockquote><blockquote type="cite"><span>per second and applying this limitation has little or no effect</span><br></blockquote><blockquote type="cite"><span>on them.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have tried "errors-per-second 1" and this seems to reduce the abuse</span><br></blockquote><blockquote type="cite"><span>by about four fifths but one fifth of it still manages to get through</span><br></blockquote><blockquote type="cite"><span>and I don't find this acceptable.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Instead, when I notice particularly heavy abuse of my nameserver,</span><br></blockquote><blockquote type="cite"><span>I apply packet filtering to prevent the abusive queries from reaching</span><br></blockquote><blockquote type="cite"><span>my nameserver and therefore to prevent it responding to them. I</span><br></blockquote><blockquote type="cite"><span>also routinely packet filter all UDP dns queries with source port</span><br></blockquote><blockquote type="cite"><span>numbers less than 1024 which I hope is the appropriate cutoff point.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Is there anything else I can do to reduce the impact of this abuse</span><br></blockquote><blockquote type="cite"><span>of my nameserver on others?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>My feeling is that mine can't be the only nameserver experiencing this</span><br></blockquote><blockquote type="cite"><span>kind of abuse and that many nameserver admins probably would not even</span><br></blockquote><blockquote type="cite"><span>notice it unless they had query logging or query-error logging turned</span><br></blockquote><blockquote type="cite"><span>on and checked the logs.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Regards,</span><br></blockquote><blockquote type="cite"><span>Peter Coghlan.</span><br></blockquote><span>_______________________________________________</span><br><span>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list</span><br><span></span><br><span>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.</span><br><span></span><br><span></span><br><span>bind-users mailing list</span><br><span>bind-users@lists.isc.org</span><br><span>https://lists.isc.org/mailman/listinfo/bind-users</span><br></div></blockquote></div></body></html>