Bind stats - denied queries?

[Marc Roos]

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