Preventing a particular type of nameserver abuse
bind at iment.com
Tue Apr 13 04:16:53 UTC 2021
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:
12-Apr-2021 23:44:17.767 security: info: client 188.8.131.52#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:44:19.477 security: info: client 184.108.40.206#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:45:00.908 security: info: client 220.127.116.11#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:45:01.263 security: info: client 18.104.22.168#80 (sl): query (cache) 'sl/ANY/IN' denied
Besides not wanting to be an unwilling DDoS amplifier, these bother me because they're filling up my BIND/named log files.
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!
On Mon, 12 Apr 2021 20:41:13 +0100 (WET-DST)
Peter Coghlan <bind at beyondthepale.ie> wrote:
> I have a nameserver which is authoritative for three or four domain names.
> It receives around 1000 queries per day that could be regarded as plausably
> legitimate. It receives around ten times that number of absive queries per
> day from presumably spoofed ip addresses, the vast majority of them IN ANY
> queries for the "sl" domain or for the root nameservers all of which my
> nameserver responds to with return code 5 ie refused.
> In many cases, the source port is a low number such as 53, 80, 96 or 443
> for example which might make some sense if these were TCP queries but they
> are all UDP queries and apart from attempting to target port 53, attempting
> to target the other low UDP port numbers make no sense to me.
> I have searched high up and low down for any discussion about this kind
> of abuse and found very little regarding abusive queries for the root
> nameservers, none at all regarding the sl domain (although it is a difficult
> term to search for) and nothing at all regarding the oddball source ports
> Even though the "refused" responses from my nameserver are "small", the
> general persistence of the abusers over a long period of time suggests to
> me that they are finding these queries effective for some kind of abuse,
> perhaps by way of having a very large number of nameservers return them
> (unless they are too stupid to care whether the queries are answered or
> refused which I suppose is also possible).
> As far as I can see providing no response at all in any instance when a
> code 5 refused response would normally be returned would be the appropriate
> thing for my nameserver to do here and doing this would cause no difficulties
> at all with any legitimate queries or anyone who is not an abuser. Am I
> correct here?
> I have searched for a way to prevent my nameserver from responding
> to these queries at all in order to reduce the impact on the targets
> of this abuse. All results of my research point to the use of
> rate limiting as the only approach available for dealing with this
> sort of issue.
> The abusive queries are clearly designed to circumvent the widely
> suggested "errors-per-second 5" as they arrive in groups of five
> per second and applying this limitation has little or no effect
> on them.
> I have tried "errors-per-second 1" and this seems to reduce the abuse
> by about four fifths but one fifth of it still manages to get through
> and I don't find this acceptable.
> Instead, when I notice particularly heavy abuse of my nameserver,
> I apply packet filtering to prevent the abusive queries from reaching
> my nameserver and therefore to prevent it responding to them. I
> also routinely packet filter all UDP dns queries with source port
> numbers less than 1024 which I hope is the appropriate cutoff point.
> Is there anything else I can do to reduce the impact of this abuse
> of my nameserver on others?
> My feeling is that mine can't be the only nameserver experiencing this
> kind of abuse and that many nameserver admins probably would not even
> notice it unless they had query logging or query-error logging turned
> on and checked the logs.
> Peter Coghlan.
More information about the bind-users