RE: Bind stats - denied queries?
Every entry is relevant, because that is how you configured it to be. Do
you even know that this limit is configured in your config at
'rate-limit {};'? It logs everything that exceeds this limit. (<- notice
the . period)
So you can dump queries from a host 192.168.a.b, exceeding this limit
and your log entry is incorrect! Because it will have 192.168.a.0 and
not 192.168.a.b. Let me put it like this, logging 192.168.a.0 is just
plain stupid. Your log an incorrect event! The idea about logs, is that
they are correct.
-Original Message-
Sent: Monday, November 30, 2020 10:45 PM
To: Marc Roos; bind-users; kpielorz.lst
Subject: Re: Bind stats - denied queries?
Am 30.11.20 um 20:01 schrieb Marc Roos
> You assume incorrectly that every such log entry is from spoofed
> traffic.
every relevant one, yes
> This is about correct logging. Even if it is spoofed, logging the
> correct spoofed address is better than logging a range (that include
> ip's that are maybe not even participating)
there is nothing like "not even participating" in a /24 in case of
reflection
> There is only, but only one advantage I can think of, and that is
> grouping to one log entry.
no, it logs what it does: responses to that /24 are rate-limited because
otherwise you won't be able to reduce the impact
you still refuse to understand wo is attacker and who is victim! *you
are* the attacker sending responses larger then the request to the
forged sources
you are *not* target, you are part of the attack und you have no way to
do anything against that on a UDP protocol except rate-limit your
responses because you have no way to find out the real source
> -Original Message-
> Subject: Re: Bind stats - denied queries?
>
> the source of dns amplification is *always* spoofed because it's by
> design the IP of the victim and not the offender
>
> the goal of dns amplification is to flood the connection of the victim
> until no regular traffic is possible
>
> the same /24 is sharing the same line and so it doesn't make sense in
> that context talk about single ip's at all
>
> it also doesn't make sense to write abuse reports for such things
> because additionally to the technical packet flood you also flood
> human ressources with nosense there
>
> they aren't the offender, they can't do anything about your issue
> because the are *the victim*
>
> you are one of thousands or even millions of hosts the attacker is
> trying to get responses from to the victim
>
> please try to understand
> https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack
> / and RRL is only useful for that type of attack, everything else
> don't matter for a DNS server and more important you can't distinct it
> anyways
>
> Am 30.11.20 um 18:23 schrieb Marc Roos:
>> Regardless if the source is spoofed or not, one should log it.
>> Especially with this amazon abuse cloud, how can you report abuse,
>> they want to have an ip address to be able to investigate if
>> something
>
>> originated from their network.
>>
>> If you log 0/24 you might as well log no range at all.
>>
>> Am 30.11.20 um 11:12 schrieb Marc Roos:
>>> Are newer version of bind still logging like this
>>>
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses
>>> to
>>> 3.9.41.0/24
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses
>>> to
>>> 3.9.41.0/24
>>>
>>> I already reported, that it is not to smart to log 3.9.41.0/24,
>>> better
>>
>>> could be logged 3.9.41.100/24 so you know the offending ip
>>
>> there is nothing like an "offending ip" in case of dns-amplification
>> which is usually what happens in context of RRL
>>
>> it's the forged destination of the attack you see and nothing else
___
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: Bind stats - denied queries?
--On 30 November 2020 at 08:53:27 -0600 Lyle Giese wrote: Be careful 'rejecting' these outright. These queries are UDP traffic(not TCP) and the source address is easily forged. RRL is the correct way to limit these. So, as the original person that posted the question :) My question still stands (I'd never presumed this was valid traffic) - what I'm trying to find out if buried within the trove of stats produced by 'rndc stats' is there any counter, that counts: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " i.e. 'Denied' queries. I can see stats for pretty much everything, e.g. Queried, notified, all the different record types - there's a block in the stats file of: " 749045 queries resulted in nxrrset 45 queries resulted in SERVFAIL 15291 queries resulted in NXDOMAIN " But I was expecting to see something like: 34343 queries resulted in DENIED But I can't see it - or anything that's really applicable? And, as everyone else is talking about RRL - is there a stat that would appear for that, e.g. 234829 queries resulted in RATELIMIT Or similar? Currently we're just trying to easily graph the DENIED queries to see how much of the total traffic it is. -Karl ___ 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
RRL outcome on legitimate traffic...
Hi all, So there's been quite a thread - that originally started as "Bind stats - denied queries" - and morphed into a whole discussion on spoofed UDP, logging, RRL etc. In my original post - I never said the original traffic was likely legitimate in anyway (just so we're clear - I didn't start that aspect of that thread). So, Obviously RRL is pretty much all you can do with this stuff - presumably, if someone throws a lot of queries that 'trip' the RRL - but, say spoofed from another ISP's actual DNS servers/network - the idea is that those IP's legitimate UDP queries will start getting dropped :( - but the other ISP's DNS will then, hopefully switch from UDP to TCP to get an answer? Looking at the distribution of rubbish we're seeing - I'm suspecting some of the limits would have to be 'really low' to catch some of this stuff (i.e. some times we just see 5 queries from an IP, and then nothing for hours - even from within the same /24). Obviously the server can weather a quite a bit of this, and you can't "block everything" (which is - in a circle, why I was asking originally about getting stats for it :) Regards, -Karl ___ 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: RRL outcome on legitimate traffic...
You need to look at the reply named sends when it trips and starts limiting UDP traffic source from a given IP address. It tells the requestor to try again using TCP instead of UDP. So if the requestor is a legit dns server, it will retry using TCP and still get a valid answer. Named does not blindly just drop traffic. Lyle Giese LCR Computer Services, Inc. On 12/1/20 4:58 AM, Karl Pielorz wrote: Hi all, So there's been quite a thread - that originally started as "Bind stats - denied queries" - and morphed into a whole discussion on spoofed UDP, logging, RRL etc. In my original post - I never said the original traffic was likely legitimate in anyway (just so we're clear - I didn't start that aspect of that thread). So, Obviously RRL is pretty much all you can do with this stuff - presumably, if someone throws a lot of queries that 'trip' the RRL - but, say spoofed from another ISP's actual DNS servers/network - the idea is that those IP's legitimate UDP queries will start getting dropped :( - but the other ISP's DNS will then, hopefully switch from UDP to TCP to get an answer? Looking at the distribution of rubbish we're seeing - I'm suspecting some of the limits would have to be 'really low' to catch some of this stuff (i.e. some times we just see 5 queries from an IP, and then nothing for hours - even from within the same /24). Obviously the server can weather a quite a bit of this, and you can't "block everything" (which is - in a circle, why I was asking originally about getting stats for it :) Regards, -Karl ___ 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: Bind stats - denied queries?
On 2020-12-01 04:43, Karl Pielorz wrote: So, as the original person that posted the question :) My question still stands (I'd never presumed this was valid traffic) - what I'm trying to find out if buried within the trove of stats produced by 'rndc stats' is there any counter, that counts: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " I think you are asking the wrong question and looking at the wrong feature. You can probably do what you're after with statistics-channels. https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statistics-channels-statement-grammar ___ 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: RRL outcome on legitimate traffic...
--On 1 December 2020 at 08:24:50 -0600 Lyle Giese wrote: You need to look at the reply named sends when it trips and starts limiting UDP traffic source from a given IP address. It tells the requestor to try again using TCP instead of UDP. So if the requestor is a legit dns server, it will retry using TCP and still get a valid answer. Named does not blindly just drop traffic. Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to stop sending responses). Documentation for rate-limit seemed a bit patchy e.g. KB aa-00994 references to "See ARM 6.2.15" - which doesn't exist. In fact a lot of the KB documents reference Bind 9.9 - and things have moved on. But I can see it's better explained in the current ARM / Section 4.2.14.19 now. In fact, that entry also covers/says "Legitimate clients react to dropped or truncated response by retrying with UDP or with TCP respectively" - looks like it documents where these are in stats as well (RateDropped / QryDropped et'al) - so I think I'm good to go. -Karl ___ 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: RRL outcome on legitimate traffic...
Probably best to ask Paul Vixie for confirmation. I had implemented RRL when it was still an addon and that was what was documented back then. On 12/1/20 10:15 AM, Karl Pielorz wrote: --On 1 December 2020 at 08:24:50 -0600 Lyle Giese wrote: You need to look at the reply named sends when it trips and starts limiting UDP traffic source from a given IP address. It tells the requestor to try again using TCP instead of UDP. So if the requestor is a legit dns server, it will retry using TCP and still get a valid answer. Named does not blindly just drop traffic. Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to stop sending responses). Documentation for rate-limit seemed a bit patchy e.g. KB aa-00994 references to "See ARM 6.2.15" - which doesn't exist. In fact a lot of the KB documents reference Bind 9.9 - and things have moved on. But I can see it's better explained in the current ARM / Section 4.2.14.19 now. In fact, that entry also covers/says "Legitimate clients react to dropped or truncated response by retrying with UDP or with TCP respectively" - looks like it documents where these are in stats as well (RateDropped / QryDropped et'al) - so I think I'm good to go. -Karl ___ 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: Bind stats - denied queries?
--On 1 December 2020 at 10:14:50 -0600 Chuck Aurora wrote: On 2020-12-01 04:43, Karl Pielorz wrote: So, as the original person that posted the question :) My question still stands (I'd never presumed this was valid traffic) - what I'm trying to find out if buried within the trove of stats produced by 'rndc stats' is there any counter, that counts: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " I think you are asking the wrong question and looking at the wrong feature. You can probably do what you're after with statistics-channels. https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statis tics-channels-statement-grammar Thanks - I'll go check that out - it looks far better / correct than parsing the stats file. As for the wrong question - I don't get why it's 'wrong' to ask if there's a better way of getting the total number of "denied" entries such as the one above, rather than 'cat /var/log/messages | grep | wc -l' type affair ? - Unless 'denied' effectively appears as some other stat already? At this stage we're trying to work out how much traffic is getting denied (as it's likely junk) vs. regular responses etc. -Karl ___ 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: Bind stats - denied queries?
On 2020-12-01 10:25, Karl Pielorz wrote: --On 1 December 2020 at 10:14:50 -0600 Chuck Aurora wrote: On 2020-12-01 04:43, Karl Pielorz wrote: So, as the original person that posted the question :) My question still stands (I'd never presumed this was valid traffic) - what I'm trying to find out if buried within the trove of stats produced by 'rndc stats' is there any counter, that counts: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " I think you are asking the wrong question and looking at the wrong feature. You can probably do what you're after with statistics-channels. https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statis tics-channels-statement-grammar Thanks - I'll go check that out - it looks far better / correct than parsing the stats file. As for the wrong question - I don't get why it's 'wrong' to ask if there's a better way of getting the total number of "denied" entries Sorry, I skimmed the post quickly and thought you simply were asking about parsing the stats file. ___ 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: Bind stats - denied queries?
--On 1 December 2020 at 10:30:21 -0600 Chuck Aurora wrote: As for the wrong question - I don't get why it's 'wrong' to ask if there's a better way of getting the total number of "denied" entries Sorry, I skimmed the post quickly and thought you simply were asking about parsing the stats file. np - I'm happily staring at statistics channel output now, Cheers, -Karl ___ 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
