Re: Preventing a particular type of nameserver abuse

[Peter Coghlan]

I started this thread back in April in response to high levels of abuse of
my nameserver.  A short summary of the discussion which resulted is that
bind does not provide any way of preventing abuse I was experiencing. (The
abuse was clearly designed to get past any use of rate-limiting to mitigate
it.)

In the last month or so, the level of abuse has declined significantly.
I don't know  whether this is because I have been keeping a very close eye
on traffic incoming to my nameserver and I have been aggressively packet
filtering queries which seem to be probing for the existance of nameservers
to exploit or whether the abuse would have declined anyway without any
intervention by me.  I still see these probes hitting my filters regularly
from some netblocks I have filtered and occasionally they arrive from
addresses I was previously unaware of.  Provided I filter these quickly
when I come across them, the level of abuse seems to stay relatively low,
most of the time.

Today I noticed the traffic below arriving from a netblock I had filtered
many years ago for reasons other than nameserver abuse.  I have never
seen anything like this before arrive at my nameserver.  I would be
interested to know what the experts think bind might have made of this
traffic had it not been filtered out.  I have included some of the more
usual probes before and after the more interesting traffic for context.

Regards,
Peter Coghlan.

09:50:12.36 207.244.251.243.41020 > 192.168.80.24.53:  64379+ A? 
www.hitnslab.cn. (33) (DF) [tos 0x8]
 4508 003d c124 4000 3211 aada cff4 fbf3 E..=.$@.2...
 c0a8 5018 a03c 0035 0029  fb7b 0100 ..P..<.5.)...{..
 0001    0377  0868 6974 .www.hit
 6e73 6c61 6202 636e  0100 01nslab.cn.
09:50:12.36 207.244.251.243.54076 > 192.168.80.24.53:  3073+ A? www.paypal.com. 
(32) (DF) [tos 0x8]
 4508 003c c123 4000 3111 abdc cff4 fbf3 E..<.#@.1...
 c0a8 5018 d33c 0035 0028  0c01 0100 ..P..<.5.(..
 0001    0377  0670 6179 .www.pay
 7061 6c03 636f 6d00 0001 0001   pal.com.

09:57:34.71 104.237.154.253.58759 > 192.168.80.24.53:  18245 updateD 
[b2&3=0x5420] [18516a] [12064q] [21584n] [12081au] (29)
 4500 0039 d431  ef11 e2d6 68ed 9afd E..9.1..h...
 c0a8 5018 e587 0035 0025  4745 5420 ..P5.%..GET
 2f20 4854 5450 2f31 2e31 0d0a 486f 7374 / HTTP/1.1..Host
 3a20  770d 0a0d 0a  : www
09:57:34.72 192.168.80.24.53 > 104.237.154.253.58759:  18245 updateD FormErr- 
[0q] 0/0/0 (12)
 4500 0028 8d61  4011 d8b8 c0a8 5018 E..(.a..@.P.
 68ed 9afd 0035 e587 0014 ee16 4745 d001 h5..GE..
     
09:57:46.16 68.183.137.43.55859 > 192.168.80.24.53:  6+ TXT CHAOS)? 
version.bind. (30) (DF)
 4500 003a 758a 4000 3211 f485 44b7 892b E..:u.@.2...D..+
 c0a8 5018 da33 0035 0026 23eb 0006 0100 ..P..3.5.&#.
 0001    0776 6572 7369 6f6e .version
 0462 696e 6400 0010 0003.bind.
09:57:47.66 68.183.137.43.55700 > 192.168.80.24.53:  0 stat [0q] Type0 (Class 
0)? . (12) (DF)
 4500 0028 765b 4000 3211 f3c6 44b7 892b E..(v[@.2...D..+
 c0a8 5018 d994 0035 0014 3759  1000 ..P5..7Y
         ..

09:57:49.17 68.183.137.43.45866 > 192.168.80.24.53:  29438 op3+ [b2&3=0x1d13] 
[0q] [2au] Type390 (Class 40960)? . (40) (DF)
 4500 0044 77b8 4000 3211 f24d 44b7 892b e.@.2..md..+
 c0a8 5018 b32a 0035 0030 bf58 72fe 1d13 ..P..*.5.0.Xr...
    0002 0001 86a0 0001 977c ...|
         
     
09:57:50.67 68.183.137.43.48542 > 192.168.80.24.53:  33008 [b2&3=0x10] SRV? 
CKAA. (50) (DF)
 4500 004e 78c0 4000 3211 f13b 44b7 892b E..Nx.@.2..;D..+
 c0a8 5018 bd9e 0035 003a a3c9 80f0 0010 ..P5.:..
 0001    2043 4b41 4141 4141  CKA
 4141 4141 4141 4141 4141 4141 4141 4141 
 4141 4141 4141 4141 4100 0021 0001  A..!..
09:57:52.17 68.183.137.43.56294 > 192.168.80.24.53:  26725 updateMA 
[b2&3=0x6c70] [3338a] [3338q] Type0 (Class 0)? . (8) (DF)
 4500 0024 7955 4000 3211 f0d0 44b7 892b E..$yU@.2...D..+
 c0a8 5018 dbe6 0035 0010 5625 6865 6c70 ..P5..V%help
 0d0a 0d0a       ..
09:57:53.67 68.183.137.43.44144 >

Re: Preventing a particular type of nameserver abuse

[Mark Andrews]

> On 15 Apr 2021, at 11:35, @lbutlr  wrote:
> 
> On 14 Apr 2021, at 01:48, Anand Buddhdev  wrote:
>> This is a short-sighted opinion. If just one authoritative server sends
>> out REFUSED responses towards an innocent, it won't matter. But if 1000
>> authoritative servers all send out REFUSED responses towards an innocent
>> IP address, their combined volume and packet rate *is* significant.
> 
> Is it?
> 
> How big is a REFUSED response?

Approximately the same size as the request.  It depends on the request and
the server’s capabilities.

> Even if it is 100 bytes (and I think it is not that large, but I cannot find 
> it), 1000 refused would be 100K.
> 
> How many thoudanss of servers do you need in this "DDoS" to overwhelm a 
> pretty average connection? (My home connection is only 200Mbps down).
> 
> Granted, a million machines would be generating a 100MB of data, which is 
> insignificantes, but the number of pockets at that scale would probably be an 
> issue. But is a million servers realistic?
> 
> I don't think calling this a DDoS is accurate. It is more likely;y there is a 
> known exploit for some servers and they are probing or it is some script 
> kiddie just blasting out packets hoping to get lucky.

If you really want to do something, talk to your local politician and get laws 
written up that require ISPs to deploy BCP38.  This is completely fixable if 
ISPs deploy BCP38 filters on themselves and all of their customers.  There is 
some CAPEX and OPEX to deploying BCP38 filters and making it a requirement 
under law levels the playing field between ISPs.

> -- 
> "Are you pondering what I'm pondering?"
> "I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
>   it doing right now?"
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

On 14 Apr 2021, at 01:48, Anand Buddhdev  wrote:
> This is a short-sighted opinion. If just one authoritative server sends
> out REFUSED responses towards an innocent, it won't matter. But if 1000
> authoritative servers all send out REFUSED responses towards an innocent
> IP address, their combined volume and packet rate *is* significant.

Is it?

How big is a REFUSED response?

Even if it is 100 bytes (and I think it is not that large, but I cannot find 
it), 1000 refused would be 100K.

How many thoudanss of servers do you need in this "DDoS" to overwhelm a pretty 
average connection? (My home connection is only 200Mbps down).

Granted, a million machines would be generating a 100MB of data, which is 
insignificantes, but the number of pockets at that scale would probably be an 
issue. But is a million servers realistic?

I don't think calling this a DDoS is accurate. It is more likely;y there is a 
known exploit for some servers and they are probing or it is some script kiddie 
just blasting out packets hoping to get lucky.

-- 
"Are you pondering what I'm pondering?"
"I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
it doing right now?"

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Peter Coghlan]

Tony Finch wrote:
>Peter Coghlan  wrote:
>> Instead, isn't it the case that bind knows what domains it is authoritative
>> for (or which ones it is supposed to be authoritative for) and bind is
>> therefore in the ideal position to know which queries are abusive and which
>> are not rather than wrapping kludgy filtering mechanisms around it?
>
> Not always, sadly, because of misconfigured (lame) delegations. See the
> earlier messages from me and Ondřej -
>
> https://lists.isc.org/pipermail/bind-users/2021-April/104408.html
> 
> https://lists.isc.org/pipermail/bind-users/2021-April/104423.html
>

But I don't have any misconfigured (lame) delegations and even if I had,
I think I would rather put up with the consequences of the lame delegations
on rare occasions than having my nameserver foisting abuse on others all
the time.

Those that are more worried about having lame delegations don't have to
use any option that would cause error responses to be dropped.

(I've been there and done that with the lame delegations years ago.  When
I fouled up the master, the slaves toiled on regardless, presumably because
the master returned "non-authoritative" or "refused" and nobody noticed there
was any problem.  Meanwhile, the slaves were unable to get zone transfers
from the fouled up master and much much later, they hit whatever the relevant
timeout was and the zone failed completely.  There then followed lots of head
scratching as to why the domain had failed when nothing had changed recently.
I think I would have preferred if it had failed immediately I made the
incorrect change (and I probably failed to notice bind trying to tell me about
it too) because I would have known exactly where to look for the problem.)

>> If there is a resistance to having bind ignore the abusive queries
>> altogether, could we at least have something like "errors-per-minute 1"
>> which would reduce the problem by a factor of 60 compared with
>> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)
>
> There is probably something that might improve things, but I'm not sure
> what it is. I think the minimum RRL rate of 1 per second might be intended
> to work with resolver retry times. I'm wary of suppressing error responses
> without thinking through the possible consequences.
>

But isn't this what the filtering that has been suggested is going to do?
Except isn't the filtering marginally more likely to get fouled up because
of the danger of not keeping the filtering configuration and the bind
configuration in sync with each other?

Regards,
Peter Coghlan.

> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Viking, North Utsire, South Utsire, Forties: Northerly or
> northwesterly 3 to 5, becoming variable 3 or less later. Moderate
> becoming slight. Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Tony Finch]

Peter Coghlan  wrote:
>
> I wouldn't describe it as background radiation or probes.  It doesn't seem
> to be caused by misconfigured or faulty resolvers or anything of that nature.

Hmm, maybe air pollution would be a better metaphor? What I mean is the
kind of continuous low levels of abuse that's definitely harmful in
aggregate, but it's not clear who is responsible or what can be done about
it. These sl/IN/ANY queries are exactly the kind of thing I had in mind.

> It is possible for me to apply filtering that catches most or maybe all of
> this but this only fixes the problem on my server and does nothing to prevent
> the abuse of lots of other servers out there.

Yeah, it's a wicked problem. There's very little one can do as a server
operator except for relatively limited mitigations. The real fix is to
trace back the traffic and do malware analysis of the sources and all that
fun forensic blue team stuff that is a very long way away from my job or
abilities :-) Before DNS I did anti-spam stuff for several years so I have
had to make peace with protecting my systems and users from the worst of
the abuse, without being in a position to do much about the causes, other
than helping to keep our networks clean.

> Instead, isn't it the case that bind knows what domains it is authoritative
> for (or which ones it is supposed to be authoritative for) and bind is
> therefore in the ideal position to know which queries are abusive and which
> are not rather than wrapping kludgy filtering mechanisms around it?

Not always, sadly, because of misconfigured (lame) delegations. See the
earlier messages from me and Ondřej -

https://lists.isc.org/pipermail/bind-users/2021-April/104408.html

https://lists.isc.org/pipermail/bind-users/2021-April/104423.html

> If there is a resistance to having bind ignore the abusive queries
> altogether, could we at least have something like "errors-per-minute 1"
> which would reduce the problem by a factor of 60 compared with
> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

There is probably something that might improve things, but I'm not sure
what it is. I think the minimum RRL rate of 1 per second might be intended
to work with resolver retry times. I'm wary of suppressing error responses
without thinking through the possible consequences.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Moderate
becoming slight. Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Sten Carlsen]

Thanks

Sten

> On 14 Apr 2021, at 19.47, Carl Byington via bind-users 
>  wrote:
> 
> Signed PGP part
> On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote:
> > Interesting, although we host different domains, in and from different
> > geographic areas, we got the same queries as yours on the same day,
> > with some at about the same time (we're EDT).
> > 13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
> > (sl): query (cache) 'sl/ANY/IN' denied
> > 13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
> > (sl): query (cache) 'sl/ANY/IN' denied
> 
> These times are PDT (-0700)
> 
> Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> 
> Apr 12 23:19:15 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> 
> So either 76.20.145.58, or someone forging that source ip, made queries
> to servers in (+), (-0400), and (-0700) at the same time. Malware
> running on 76.20.145.58 is one explanation. Would the REFUSED replies
> carry enough information from the original query to be used as a covert
> communication channel into something listening on 76.20.145.58?
> 
> vpn over dns query-refused replies? That seems a bit far-fetched.

I wonder if it may be an attempt to keep track of the Internet speed across the 
world?
If you send off these queries at the same time to different locations what 
would the round trip time tell you?
It would probably be a fair assessment of the speed of the net - might be a 
replacement for pings.

> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Peter Coghlan]

Tony Finch wrote:
> Peter Coghlan  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.
> 
> There have been several helpful replies, but to be honest I wouldn't spend
> too much effort on low levels of abuse unless you want to use it as a
> learning exercise. (I would care if it was multiple abusive queries per
> second...)
>

I think a learning exercise would be very useful as there seems to be very
little awareness of this issue and I found it very difficult to find any
discussion or analysis of it anywhere.  From the replies to my posting here,
it seems apparant that my nameserver is definately not the only one which is
experiencing this abuse.

I am seeing abusive query rates of 5 per second for sustained periods of the
day.  As far as I can see this is specially designed to get in under the
widely suggested "errors-per-second 5" rate limiting.

>
>> 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.
>
> RRL is designed to avoid interfering with legitimate traffic, but that
> does mean that some abuse traffic leaks through. Its aim is to stop
> amplification, so that the attackers don't get any benefit from abusing
> your server.
>

Sure but something is clearly benefitting from the abuse because it is
going on day in, day out for months now and it it is apparantly happening
on servers other than mine too.

Also, my nameserver doesn't receive any legitimate traffic at all which my
nameserver replies to with "refused" responses.

>
> But it sounds to me like your problem traffic is more like background
> radiation (e.g. probes) than active abuse; if so it's likely that RRL will
> not deter them.
>

I wouldn't describe it as background radiation or probes.  It doesn't seem
to be caused by misconfigured or faulty resolvers or anything of that nature.
Exactly the same queries (including the same source port and query id) are
repeated over and over again whether a "refused" reply is provided or not.
It seems pretty clearly abusive to me even if the exact purpose of the abuse
is not so obvious yet.

>
>> 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.
>
> If all the problem traffic is sl. IN ANY, then I suggest permanently
> leaving in place a filter to drop those queries. Use a string match rule,
> like Grant Taylor suggested, but match the queries instead of the
> responses, so they don't clutter your query logs.
>

>From what I can see, roughly half of the problem traffic is sl/IN/ANY and the
other half is ./IN/ANY.  Some of the problem traffic has source ports less
than 1024 and some doesn't. ([tos 0x8] is often thrown in for good measure
too. I wonder what that's about?)

It is possible for me to apply filtering that catches most or maybe all of
this but this only fixes the problem on my server and does nothing to prevent
the abuse of lots of other servers out there.

Besides, I'm not really that concerned about the effect on my nameserver, I am
more concerned about the effect of the abusive traffic being reflected by
my nameserver and various other nameservers onto innocent third parties
with little or no awareness that this is happening.

Also, I don't believe a sufficiently portable filtering mechanism exists
which can be deployed across all the platforms that bind can be deployed
on.

Even if everybody could start filtering queries for "sl" and the root
nameservers, what's to stop the abusers moving on to using a different
domain name when they discover this filtering being applied?

Instead, isn't it the case that bind knows what domains it is authoritative
for (or which ones it is supposed to be authoritative for) and bind is
therefore in the ideal position to know which queries are abusive and which
are not rather than wrapping kludgy filtering mechanisms around it?

If there is a resistance to having bind ignore the abusive queries
altogether, could we at least have something like "errors-per-minute 1"
which would reduce the problem by a factor of 60 compared with
"errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

Regards,
Peter Coghlan.

>
> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
> becoming rough. Fair. Good.
> 
___
Please visit https://lists.isc.org/mailman/listinfo

Re: Preventing a particular type of nameserver abuse

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote:
> Interesting, although we host different domains, in and from different
> geographic areas, we got the same queries as yours on the same day,
> with some at about the same time (we're EDT).
> 13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
> (sl): query (cache) 'sl/ANY/IN' denied
> 13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
> (sl): query (cache) 'sl/ANY/IN' denied

These times are PDT (-0700)

Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied
Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied

Apr 12 23:19:15 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied

So either 76.20.145.58, or someone forging that source ip, made queries
to servers in (+), (-0400), and (-0700) at the same time. Malware
running on 76.20.145.58 is one explanation. Would the REFUSED replies
carry enough information from the original query to be used as a covert
communication channel into something listening on 76.20.145.58?

vpn over dns query-refused replies? That seems a bit far-fetched.



-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHcqsRUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEvgACgh6muAlNI6qk99Rd9sLaSp29IESQA
njJo7E3ajD0Yw/ja7VOStNhgkxDd
=tlQQ
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

Interesting, although we host different domains, in and from different 
geographic areas, we got the same queries as yours on the same day, with some 
at about the same time (we're EDT).

13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.365 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.366 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.568 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.820 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied


13-Apr-2021 03:04:25.379 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:25.553 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied

This is not a complete list, but they all were on Apr 13 (and near your times).

==

On Tue, 13 Apr 2021 15:23:20 +0100 (WET-DST)
Peter Coghlan  wrote:

> Hi Paul,
> 
> Many thanks for your reply.  Yours is exactly the sort of reply I was hoping
> for because I feel like I have been banging my head on a brick wall for months
> now looking for someone else who cares whether their nameserver is an engine
> for this sort of abuse.  I was beginning to wonder if I was the only person
> in the world seeing this kind of abuse and regarding it as a problem.
> 
> I will leave another while to see if more clueful replies like yours arrive
> and then I will reply back to the list again myself to try to move the thread
> in the direction of requesting a solution which can easily be implemented by
> anyone and does not involve packet filters, firewalls, IPtables and so on.
> 
> In the meantime, I thought it would be interesting to see if I also got
> the same abusive queries you logged below.  Unfortunately (or fortunately)
> I am packet filtering incoming queries with source port 80 so they did not
> make it as far as the logs in my case.  Here are a few that did make it to
> my logs.  Maybe they are in yours too?
> 
> Regards,
> Peter Coghlan.
> 
> 13-Apr-2021 06:20:10.867 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.396 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.743 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.804 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.746 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.935 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:33.993 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:34.047 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Tony Finch]

sth...@nethelp.no  wrote:
>
> Agree that you should be able to ignore them. But as a practical matter,
> ignoring them *may* result in the question being asked again and again,
> while REFUSED *may* stop the client from asking more.

REFUSED leads to retries too: if the client is a legit resolver it will
retry using the other authoritative servers. For example, when I changed
private.cam.ac.uk from refusing external queries to replying with an empty
answer, the load on our auth servers dropped by half.

Retries following REFUSED are also one reason why the RFC 8482 minimal-any
option is not refuse-any: when an ANY attack is bouncing off a recursive
server, the authoritative server can reduce the power of the attack by
returning a small cacheable answer. This reduces the load on the
authoritative servers (no retries), and on the recursive servers (no need
to recurse and retry), and reduces the volume of the attack traffic.

Probe traffic like these sl/IN/ANY queries is a very different matter. I
wouldn't expect any kind of reasonable behaviour, so it makes sense to
drop the queries as early as possible.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Fitzroy, Sole: Easterly or southeasterly 4 to 6. Moderate or
rough. Showers at first in northwest Fitzroy, otherwise fair. Good.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[sthaug]

> I'm not talking of DNS *resolvers* here. I'm talking of authoritative
> servers. If my authoritative server is authoritative for zones A, B and
> C, then I should only get queries for those zones from legitimate
> resolvers and clients. Queries for any other zones should *not* be
> coming to my server. I shouldn't even be obliged to answer with REFUSED.
> I should just be able to ignore those queries completely as junk.

Agree that you should be able to ignore them. But as a practical matter,
ignoring them *may* result in the question being asked again and again,
while REFUSED *may* stop the client from asking more.

I run one of the authoritative name servers for no (Norway). That name
server receives its share of completely irrelevant queries, e.g. (25
queries from just now):

NS? .
ANY? sl.
ANY? sl.
A? d2cnv2pop2xy4v.cloudfront.net.
NS? .
A? www.google.li.
A? tussilagobarnehage-no02c.mail.protection.outlook.com.
A? handball-havdur-no.mail.protection.outlook.com.
A? tronica-no.mail.protection.outlook.com.
A? storage-support.glb.itcs.hpe.com.
A? msgr-latest.c10r.facebook.com.
NS? .
A? mqtt.c10r.facebook.com.
A? inappcheck.itunes.apple.com.edgekey.net.
Type65? inappcheck.itunes.apple.com.edgekey.net.
Type65? e69896.dscapi6.akamaiedge.net.
A? e69896.dscapi6.akamaiedge.net.
A? javvs-no.mail.protection.outlook.com.
A? clients4.google.com.
A? clients.l.google.com.
A? storage-support.glb.itcs.hpe.com.
A? au-bg-shim.trafficmanager.net.
NS? .
ANY? sl.
ANY? sl.

And here again we see the queries for .sl. In any case, the volume of
these queries is so low (on the order of 0.1% of the total) that I
don't really care. I'm not going to spend any time worrying about the
resource usage of these queries.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Ondřej Surý]

Anand,

I understand that this topic is something you feel passionate about, but alas, 
it’s more complicated than just dropping REFUSED answers. Any lame delegation 
would be then susceptible to cache poisoning. Also it would be a protocol 
violation.

A small well-maintained authoritative server might be able to safely disable 
such answers, but it’s not cure-all, and it could quickly bite you back even in 
case of small authoritative servers. Imagine admin of example.org botches up 
delegation of vpn.example.org and would be able to poison the cache somewhere. 
There too many possible scenarios where things might go wrong and shifting the 
blame from lack of BCP38 implementation to well-behaved DNS servers isn’t 
particularly helpful.

I think dropping such answers would be very similar to: 
https://www.cvedetails.com/cve/CVE-2008-3337/ and 
https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2008-02.html

Ondřej 
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 14. 4. 2021, at 9:49, Anand Buddhdev  wrote:
> 
> On 14/04/2021 00:29, @lbutlr wrote:
> 
>>> A legitimate client, following a normal chain of referrals, has *no*
>>> reason to query a server for zones it is not authoritative for.
>> 
>> Well, that's not really true. A mobile user might have their device
>> configured to always check their corporate DNS server first, for
>> example, then fall back if that fails.
> 
> I'm not talking of DNS *resolvers* here. I'm talking of authoritative
> servers. If my authoritative server is authoritative for zones A, B and
> C, then I should only get queries for those zones from legitimate
> resolvers and clients. Queries for any other zones should *not* be
> coming to my server. I shouldn't even be obliged to answer with REFUSED.
> I should just be able to ignore those queries completely as junk.
> 
>> Refusing makes everything faster, ignoring breaks things and makes things 
>> slower.
>> 
>> When a DNS host refuses a query, it will not be queried again, wen
>> it times out, is is still in the rotation.
> 
> This is a misbelief. When a resolver fails to get an answer from an
> authoritative server (whether explicitly with a REFUSED response, or
> just a timeout), it may lower the preference for that name server, but
> will eventually retry, in case that server is able to answer for that
> zone again.
> 
>>> Most of the time, such a query would only arrive at a name server from a 
>>> naughty
>>> client.
>> 
>> Unlikely as there is no benefit to the "naughty" client. This is not
>> a
>> amplification attack, the refusal is a short packet, meaning the query
>> from the client is probably larger than the response. Very inefficient
>> for naughty clients.
> 
> Amplification isn't necessary for causing a DDoS towards an innocent
> client. Even a high-enough packet rate (with small packets), can
> overwhelm the upstream router of the client, or use up a significant
> portion of the bandwidth. It can also cause problems for the client
> whose networking stack has to deal with the packets. Whether an unwanted
> packet is of 100 bytes or 1000 bytes, the network stack has to deal with
> it somehow.
> 
>>> And then, replying with any response, even REFUSED, is
>>> satisfying this client's naughtiness.
>> 
>> How?
> 
> A spoofer gets to generate responses, however, small, towards an
> innocent client.
> 
>>> I think it's quite okay for an authoritative name server to simply DROP
>>> UDP queries for zones
>> 
>> It's not.
> 
> If you try to SSH to a server that you're not supposed to connect to,
> and it drops your packets, you won't complain right? So why are you so
> bothered about a DNS server that drops queries it's not supposed to be
> receiving? The DNS resolution protocol is clear. A resolver is supposed
> to follow a chain of referrals, and not query any random server on the
> Internet. So a legitimate resolver has no business querying random
> authoritative servers for zones they're not supposed to serve.
> 
>>> that it's not authoritative for. It's better to
>>> ignore naughty clients, and give them the cold shoulder, and not
>>> participate in reflection attacks using REFUSED responses.
>> 
>> How do you imagine this is a reflection attack? It is far too small
>> to be an effective attack for anything.
> 
> This is a short-sighted opinion. If just one authoritative server sends
> out REFUSED responses towards an innocent, it won't matter. But if 1000
> authoritative servers all send out REFUSED responses towards an innocent
> IP address, their combined volume and packet rate *is* significant.
> 
> Regards,
> Anand
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.

Re: Preventing a particular type of nameserver abuse

[Anand Buddhdev]

On 14/04/2021 00:29, @lbutlr wrote:

>> A legitimate client, following a normal chain of referrals, has *no*
>> reason to query a server for zones it is not authoritative for.
> 
> Well, that's not really true. A mobile user might have their device
> configured to always check their corporate DNS server first, for
> example, then fall back if that fails.

I'm not talking of DNS *resolvers* here. I'm talking of authoritative
servers. If my authoritative server is authoritative for zones A, B and
C, then I should only get queries for those zones from legitimate
resolvers and clients. Queries for any other zones should *not* be
coming to my server. I shouldn't even be obliged to answer with REFUSED.
I should just be able to ignore those queries completely as junk.

> Refusing makes everything faster, ignoring breaks things and makes things 
> slower.
> 
> When a DNS host refuses a query, it will not be queried again, wen
> it times out, is is still in the rotation.

This is a misbelief. When a resolver fails to get an answer from an
authoritative server (whether explicitly with a REFUSED response, or
just a timeout), it may lower the preference for that name server, but
will eventually retry, in case that server is able to answer for that
zone again.

>> Most of the time, such a query would only arrive at a name server from a 
>> naughty
>> client.
> 
> Unlikely as there is no benefit to the "naughty" client. This is not
> a
> amplification attack, the refusal is a short packet, meaning the query
> from the client is probably larger than the response. Very inefficient
> for naughty clients.

Amplification isn't necessary for causing a DDoS towards an innocent
client. Even a high-enough packet rate (with small packets), can
overwhelm the upstream router of the client, or use up a significant
portion of the bandwidth. It can also cause problems for the client
whose networking stack has to deal with the packets. Whether an unwanted
packet is of 100 bytes or 1000 bytes, the network stack has to deal with
it somehow.

>> And then, replying with any response, even REFUSED, is
>> satisfying this client's naughtiness.
> 
> How?

A spoofer gets to generate responses, however, small, towards an
innocent client.

>> I think it's quite okay for an authoritative name server to simply DROP
>> UDP queries for zones
> 
> It's not.

If you try to SSH to a server that you're not supposed to connect to,
and it drops your packets, you won't complain right? So why are you so
bothered about a DNS server that drops queries it's not supposed to be
receiving? The DNS resolution protocol is clear. A resolver is supposed
to follow a chain of referrals, and not query any random server on the
Internet. So a legitimate resolver has no business querying random
authoritative servers for zones they're not supposed to serve.

>> that it's not authoritative for. It's better to
>> ignore naughty clients, and give them the cold shoulder, and not
>> participate in reflection attacks using REFUSED responses.
> 
> How do you imagine this is a reflection attack? It is far too small
> to be an effective attack for anything.

This is a short-sighted opinion. If just one authoritative server sends
out REFUSED responses towards an innocent, it won't matter. But if 1000
authoritative servers all send out REFUSED responses towards an innocent
IP address, their combined volume and packet rate *is* significant.

Regards,
Anand
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 
'sl/ANY/IN' queries logged by our BIND and got:

2 Comcast cable IPs (hsd1.tx.comcast.net and hsd1.ma.comcast.net)
1 OVH Hosting IP (Montreal)
1 Afranet IP (Tehran!)

The whois info for the OVH IP contains the line:

  Comment:   Failover IPs


On Tue, 13 Apr 2021 14:04:14 -0700
Carl Byington via bind-users  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote:
> > Reading this thread, I considered simply enabling the fail2ban
> > named-refused jail, but they advise against it because it would end
> > up
> > blocking the victim rather than the attacker.  
> 
> In the particular case of the .sl denied queries, I don't think these
> are forged queries from the attack victim. Something else is going on
> here. We see queries from systems like these, almost exclusively
> consumer endpoints:
> 
> 142-197-133-231.res.spectrum.com.
> mta-162-154-195-235.kya.rr.com.
> mobile-166-173-63-176.mycingular.net.
> prg03s05-in-f193.1e100.net.
> prg03s05-in-f1.1e100.net.
> pool-173-79-59-79.washdc.fios.verizon.net.
> 174-30-51-96.wrbg.centurylink.net.
> c-174-53-75-253.hsd1.va.comcast.net.
> 174-081-062-250.res.spectrum.com.
> cpe-174-106-58-62.ec.res.rr.com.
> 192.sub-174-214-12.myvzw.com.
> stop-looking-at-drifteds-ip.gov.
> 252.243.53.179.d.dyn.claro.net.do.
> ip184-186-26-40.no.no.cox.net.
> dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
> dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
> customer-189-216-112-75.cablevision.net.mx.
> 189.223.57.66.dsl.dyn.telnor.net.
> 212-149-157-12.rev.dnaip.fi.
> 
> It seems unlikely that someone is trying to attack those specific
> endpoints. Unless the attack is *very* widely distributed and they are
> actually attacking the ISP infrastructure. But in that case, this seems
> to be a simultaneous attack on almost every major ISP, which I find
> unlikely.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
> n0zp1wmsrlc9yeDc/wXJCy8xBToC
> =Ir5g
> -END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[@lbutlr]

On 13 Apr 2021, at 04:02, Anand Buddhdev  wrote:
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.

Well, that's not really true. A mobile user might have their device configured 
to always check their corporate DNS server first, for example, then fall back 
if that fails.

Refusing makes everything faster, ignoring breaks things and makes things 
slower.

When a DNS host refuses a query, it will not be queried again, wen it times 
out, is is still in the rotation.

> Most of the time, such a query would only arrive at a name server from a 
> naughty
> client.

Unlikely as there is no benefit to the "naughty" client. This is not a 
amplification attack, the refusal is a short packet, meaning the query from the 
client is probably larger than the response. Very inefficient for naughty 
clients.

> And then, replying with any response, even REFUSED, is
> satisfying this client's naughtiness.

How?

> I think it's quite okay for an authoritative name server to simply DROP
> UDP queries for zones

It's not.

> that it's not authoritative for. It's better to
> ignore naughty clients, and give them the cold shoulder, and not
> participate in reflection attacks using REFUSED responses.

How do you imagine this is a reflection attack? It is far too small to be an 
effective attack for anything.


-- 
'Today Is A Good Day For Someone Else To Die!' --Feet of Clay

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote:
> Reading this thread, I considered simply enabling the fail2ban
> named-refused jail, but they advise against it because it would end
> up
> blocking the victim rather than the attacker.

In the particular case of the .sl denied queries, I don't think these
are forged queries from the attack victim. Something else is going on
here. We see queries from systems like these, almost exclusively
consumer endpoints:

142-197-133-231.res.spectrum.com.
mta-162-154-195-235.kya.rr.com.
mobile-166-173-63-176.mycingular.net.
prg03s05-in-f193.1e100.net.
prg03s05-in-f1.1e100.net.
pool-173-79-59-79.washdc.fios.verizon.net.
174-30-51-96.wrbg.centurylink.net.
c-174-53-75-253.hsd1.va.comcast.net.
174-081-062-250.res.spectrum.com.
cpe-174-106-58-62.ec.res.rr.com.
192.sub-174-214-12.myvzw.com.
stop-looking-at-drifteds-ip.gov.
252.243.53.179.d.dyn.claro.net.do.
ip184-186-26-40.no.no.cox.net.
dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
customer-189-216-112-75.cablevision.net.mx.
189.223.57.66.dsl.dyn.telnor.net.
212-149-157-12.rev.dnaip.fi.

It seems unlikely that someone is trying to attack those specific
endpoints. Unless the attack is *very* widely distributed and they are
actually attacking the ISP infrastructure. But in that case, this seems
to be a simultaneous attack on almost every major ISP, which I find
unlikely.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
n0zp1wmsrlc9yeDc/wXJCy8xBToC
=Ir5g
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Julien Salort]

Le 13/04/2021 à 00:55, Richard T.A. Neal a écrit :


That's exactly what I do - I have some code that's watching for a frequent occurrence of these 
sorts of queries and then adds a firewall rule for a predetermined amount of time to simply drop 
the incoming packets at the firewall - this prevents them from reaching BIND in the first place and 
thus consuming system resource on the BIND server. And I say "predetermined amount of 
time" because that rule is then removed after a period of time in case the abuse was 
"unintentional" (ahem), or in case it came from a system using a non-static IP (i.e. a 
different user may be using that IP now, so I don't want to block them).


Do you block specifically the dns queries in the firewall, or straight 
out block the IP?


Reading this thread, I considered simply enabling the fail2ban 
named-refused jail, but they advise against it because it would end up 
blocking the victim rather than the attacker.


I understand that always ignoring these request may be bad if it causes 
some timeout somewhere (though I still do not quite fully understand 
what legitimate requests those may be for a server which only does 
authoritative answers). Couldn't bind then have a built-in option to 
ignore repeated attempts from a given host, and cap the number of error 
codes sent to a given host per day?


Julien

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Tony Finch]

Anand Buddhdev  wrote:
>
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.

That's true for cases like .sl and other domains whose delegations are set
up correctly, but if a server is accidentally lame then it's helpful to
return REFUSED so that resolvers don't have to wait for a timeout before
trying other servers. A quick REFUSED will also avoid messing up the
resolver's per-server statistics that might interfere with queries for
authoritative zones.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Fitzroy: Southeasterly 5 to 7, becoming variable 2 to 4 at
times in south. Moderate or rough, occasionally slight in south.
Thundery showers, fog patches. Moderate, occasionally very poor.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Tony Finch]

Peter Coghlan  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.

There have been several helpful replies, but to be honest I wouldn't spend
too much effort on low levels of abuse unless you want to use it as a
learning exercise. (I would care if it was multiple abusive queries per
second...)

> 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.

RRL is designed to avoid interfering with legitimate traffic, but that
does mean that some abuse traffic leaks through. Its aim is to stop
amplification, so that the attackers don't get any benefit from abusing
your server.

But it sounds to me like your problem traffic is more like background
radiation (e.g. probes) than active abuse; if so it's likely that RRL will
not deter them.

> 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.

If all the problem traffic is sl. IN ANY, then I suggest permanently
leaving in place a filter to drop those queries. Use a string match rule,
like Grant Taylor suggested, but match the queries instead of the
responses, so they don't clutter your query logs.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
becoming rough. Fair. Good.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Anand Buddhdev]

Hi Ondrej, and others,

A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for. Most of
the time, such a query would only arrive at a name server from a naughty
client. And then, replying with any response, even REFUSED, is
satisfying this client's naughtiness.

I think it's quite okay for an authoritative name server to simply DROP
UDP queries for zones that it's not authoritative for. It's better to
ignore naughty clients, and give them the cold shoulder, and not
participate in reflection attacks using REFUSED responses.

Regards,
Anand

On 13/04/2021 11:47, Ondřej Surý wrote:

> Yes, the legitimate client would be susceptible to spoofing. No
> answer means larger time windows to guess the port+msgid combination.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Borja Marcos]

> On 13 Apr 2021, at 11:31, Julien Salort  wrote:
> 
> Is there really a usefulness to reply with code 5, instead of silently 
> ignoring the request?

Yes, we do it.

imagine a customer who uses to connect from different locations (hence 
different ISPs) and for whatever
reason keeps a static list of resolvers in resolv.conf.

If the customer queries your DNS servers from a non authorized location and 
they ignore the request you
will force the resolver to time out. If, however, the query is refused, the 
resolver will send it to the next
server in the list.

Being short messages means they are useless for a DDoS. Anyway we keep an eye 
on it.





Borja.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Ondřej Surý]

Yes, the legitimate client would be susceptible to spoofing. No answer means 
larger time windows to guess the port+msgid combination.

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 13. 4. 2021, at 11:31, Julien Salort  wrote:
> 
> Is there really a usefulness to reply with code 5, instead of silently 
> ignoring the request?

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Julien Salort]

Le 13/04/2021 à 07:12, Ondřej Surý a écrit :

BIND 9.11 has minimal-any option that’s helpful to reduce the attack 
impact: https://www.isc.org/blogs/bind-release-911/ 



RRL should also help to limit the responses: 
https://kb.isc.org/docs/aa-01000 


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.


I also have a lot of these (sl) queries in my logs.

Would it not be possible to have an option to tell bind to refrain from 
answering to all unauthorized queries over UDP?


Is there really a usefulness to reply with code 5, instead of silently 
ignoring the request?


A built-in option would be much easier than to require every server to 
have a dedicated fancy firewall rule.


But I have no idea how much work it would be to add this feature in bind.


Cheers,


Julien

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Ondřej Surý]

BIND 9.11 has minimal-any option that’s helpful to reduce the attack impact: 
https://www.isc.org/blogs/bind-release-911/

RRL should also help to limit the responses: https://kb.isc.org/docs/aa-01000

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.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 13. 4. 2021, at 6:17, Paul Kosinski via bind-users 
>  wrote:
> 
> 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 107.213.131.17#80 (sl): 
> query (cache) 'sl/ANY/IN' denied
>  12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): 
> query (cache) 'sl/ANY/IN' denied
>  12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query 
> (cache) 'sl/ANY/IN' denied
>  12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#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  wrote:
>> 
>> Hello,
>> 
>> 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
>> either.
>> 
>> 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 names

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

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 107.213.131.17#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#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  wrote:

> Hello,
> 
> 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
> either.
> 
> 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.
> 
> Regards,
> Peter Coghlan.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Preventing a particular type of nameserver abuse

[Richard T.A. Neal]

Grant Taylor wrote:

> You might be able to apply the same methodology to filter unwanted inbound 
> queries to completely avoid sending the reply code at all.

That's exactly what I do - I have some code that's watching for a frequent 
occurrence of these sorts of queries and then adds a firewall rule for a 
predetermined amount of time to simply drop the incoming packets at the 
firewall - this prevents them from reaching BIND in the first place and thus 
consuming system resource on the BIND server. And I say "predetermined amount 
of time" because that rule is then removed after a period of time in case the 
abuse was "unintentional" (ahem), or in case it came from a system using a 
non-static IP (i.e. a different user may be using that IP now, so I don't want 
to block them).

As well as requests for IN ANY sl, I also get a huge number for IN ANY 
census.gov. As with "sl" it's an attack based on the premise that the query is 
very small when compared to the volume of data being sent by return. And bear 
in mind the IP address purporting to send the query could very well be spoofed 
since it's UDP traffic - i.e. the malicious actor is potentially trying to get 
your DNS server to participate in a DDOS DNS attack against a third party. So 
by dropping those requests at the firewall I'm helping to ensure that my BIND 
server isn't a participant in that attack.

Richard.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]


It's not a "BIND" solution, per se, but if you have a
sufficiently-sophisticated IPS (Intrusion Prevention System) you could have
it simply drop all queries of a particular QNAME, or any particular
combination of QNAME, QTYPE, QCLASS, before those packets even get to
named. I know SNORT-based IPSes can do this, not so sure about other IPSes,
but most of them have a custom rule/signature capability. As Grant pointed
out, it wouldn't even need to be a dedicated IPS -- one could potentially
leverage that IPS capabilities of a firewall.


  - kevin

On Mon, Apr 12, 2021 at 4:10 PM Peter Coghlan  wrote:

> Hello,
>
> 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
> either.
>
> 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.
>
> Regards,
> Peter Coghlan.
>
> --Boundary_(ID_/cANmbMgveXk/KlZF+xdIQ)--
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Preventing a particular type of nameserver abuse

[Grant Taylor via bind-users]

On 4/12/21 1:41 PM, Peter Coghlan wrote:
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?


You might consider filtering the egress code 5 from your server via 
local firewall.  I'm not entirely sure how to do this.  But I suspect 
that your platform's firewall has an option.


I know that I've used IPTable's "string" match extension to filter out 
problematic inbound queries at times in the past.  Perhaps something 
like this could be pressed into service to filter outgoing code 5 replies.


You might be able to apply the same methodology to filter unwanted 
inbound queries to completely avoid sending the reply code at all.


All results of my research point to the use of rate limiting as the 
only approach available for dealing with this sort of issue.


There are always multiple ways to do things.  It's a question of how 
practical they are.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users