Stopping ddos
Lyle Giese
lyle at lcrcomputer.net
Thu Aug 4 14:54:15 UTC 2022
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>
More information about the bind-users
mailing list