Stopping ddos

[Lyle Giese]

Just my opinion.

Don't rate limit tcp.  The RRL feature in Bind only rate limits UDP.  
UDP is connection-less and the source address can be forged, generating 
DDOS traffic to a 3rd party.

Proper DNS software will fall back to TCP.  Because TCP is connection 
based, much harder to forge source address.

Lyle

On 8/3/22 08:30, Robert Moskowitz wrote:
> Thanks.  I will look into this.
>
> On 8/3/22 07:47, Victor Johansson via bind-users wrote:
>>
>> Hey,
>>
>> I just want to add that there is a better way to do this in iptables 
>> with hashlimit. The normal rate limit in iptables is too crude.
>>
>> Below is an example from the rate-limit-chain, to which you simply 
>> send all port 53 traffic from the INPUT chain (make sure to exclude 
>> 127.0.0.1/127.0.0.53 though :) ).
>>
>>
>> -A INPUT -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
>> -A INPUT -p tcp -m tcp --dport 53 -j DNS-RATE-LIMIT
>>
>> -A DNS-RATE-LIMIT -s 127.0.0.1/32 -m comment --comment "Dont 
>> rate-limit localhost" -j RETURN
>> -A DNS-RATE-LIMIT -m hashlimit --hashlimit-upto 100/sec 
>> --hashlimit-burst 300 --hashlimit-mode srcip --hashlimit-name 
>> DNS-drop --hashlimit-htable-expire 2000 -j ALLOW
>> -A DNS-RATE-LIMIT -m limit --limit 1/sec -j LOG --log-prefix "DNS-drop: "
>> -A DNS-RATE-LIMIT -m comment --comment "ansible[dns rate limiting]" 
>> -j DROP
>>
>>
>> //Victor
>>
>>
>> On 8/2/22 23:16, Michael De Roover wrote:
>>> For my servers I'm using iptables rules to achieve ratelimiting. 
>>> They look as follows:
>>> -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent 
>>> --update --seconds 600 --hitcount 4 --name DEFAULT --mask 
>>> 255.255.255.255 --rsource -j DROP
>>> -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent 
>>> --set --name DEFAULT --mask 255.255.255.255 --rsource
>>>
>>> It should be fairly trivial to convert these to use UDP 53, and 
>>> tweak the timings you want. These rules are intended to allow 4 
>>> connections (which normally should be entire SMTP transactions) 
>>> every 10 minutes. Since I have 2 edge nodes with these rules, that 
>>> is doubled to 8 connections total. If you're an authoritative name 
>>> server only, realistically mostly recursors / caching servers would 
>>> query your servers and not too often. You can easily restrict 
>>> traffic here. If you're a recursor too, this becomes a bit more 
>>> complicated.
>>>
>>> Regarding the legitimate queries, it would be prudent to allow 
>>> common recursors (Google, Cloudflare, Quad9 etc) to have exceptions 
>>> to this rule. Just allow their IP addresses to send traffic either 
>>> unrestricted, or using a more relaxed version of the above.
>>>
>>> HTH,
>>> Michael
>>>
>>> On Tue, 2022-08-02 at 16:02 -0400, Robert Moskowitz wrote:
>>>> Recently I have been having problems with my server not responding 
>>>> to my
>>>> requests.  I thought it was all sorts of issues, but I finally 
>>>> looked at
>>>> the logs and:
>>>>
>>>> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
>>>> 114.29.194.4#11205
>>>> (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
>>>> 114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
>>>> 64.68.114.141#39466
>>>> (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
>>>> 209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
>>>> 114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
>>>> 62.109.204.22#4406
>>>> (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518
>>>> (.): view external: query (cache) './A/IN' denied
>>>> Aug  2 15:47:50 onlo named[6155]: client @0xaa882dc8 
>>>> 114.29.202.117#9584
>>>> (.): view external: query (cache) './A/IN' denied
>>>>
>>>> grep -c denied messages
>>>> 45868
>>>>
>>>> And that is just since Jul 31 3am.
>>>>
>>>> This is fairly recent so I never looked into what I might do to 
>>>> protect
>>>> against this.  I am the master for my domain, so I do need to allow 
>>>> for
>>>> legitimate queries.
>>>>
>>>> Any best practices on this?
>>>>
>>>> I am running bind 9.11.4
>>>>
>>>> thanks
>>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220804/e5f52a4a/attachment.htm>