Stopping ddos

[Robert Moskowitz]

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/20220803/bb1e7145/attachment-0001.htm>