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
--
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
