Re: Stopping ddos
On 02/08/2022 22:04, Saleck wrote: Dne úterý 2. srpna 2022 22:02:58 CEST, Robert Moskowitz napsal(a): 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 You could think about adding fail2ban to your server with some custom rules. Helped us in a similar situation. Kind regards, David I'm also a longtime and happy Fail2Ban user, more infos here: https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/ https://ixnfo.com/en/configuring-fail2ban-for-bind9.html HTH, Ed. -- 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
Re: Stopping ddos
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 -- 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
Re: Stopping ddos
On Wed, 3 Aug 2022 13:47:41 +0200 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 > I was using iptables hashlimit for a while but stopped. It wasn't really solving my main problem, which was not so much "overloading" my BIND server as causing my log files to get filled with useless warnings about bad queries (or packets dropped). It would be nice if BIND had way to record such error messages into a dumpable table with query, source IP and count. -- 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
Re: Stopping ddos
On 8/2/22 3:29 PM, Robert Moskowitz wrote:
My clients use my internal view. My external view has:
match-clients { any; };
match-destinations { any; };
allow-query { any; };
allow-query-cache { localhost; };
recursion no;
it's been a while but I don't think you need to respond to requests for
'.' ... so I think you can block access to all zones except the one you
want to respond for.
I am way behind the times, as I really have not made any significant
changes to my config for a couple years. Things have been stable.
And I am running CentOS7-arm which only has 9.11.4...
BTW, I am in the market for a 'affordable' DNS box to run here and get
out of the business of maintaining my own software. I am approaching
72, and not something I want to do anymore. And I have not see a
service provider that would let me really config my own zone files...
I was in the same boat and ended up shifting my personal stuff to
Route53 in Amazon AWS. It costs like, $1 a month per zone to host and
nobody is going to be killing Route53.
You can configure all the records in the zone however you like, and
there are APIs if you want to script things so things like a residential
network connection you can have it update it's A record in Route53 with
a script when the IP changes.
--
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
Re: Stopping ddos
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 -- 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
Re: Stopping ddos
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
Re: Stopping ddos
On Tue, Aug 02, 2022 at 11:16:15PM +0200, 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. Just to give a Heads Up: I have a very similar config in IPFW protecting port 53 with a rate limit. I had put that in because the option was there and I thought it a good idea, and then entirely forgotten about it. I was then very surprized when I couldn't renew my certificates due to creepy and non-reproducible failures. A CA cen send quite an amount of queries when validating a site, and may have tough timeouts. I recommend testing such a rate-limit against DNSviz.net which also sends a high amount of queries. (My actual fault was to forget about the limit, otherwise one could just remove it temporarily during such actions.) -- PMc -- 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
Re: Stopping ddos
On 8/2/22 17:30, Nathan Ollerenshaw via bind-users wrote:
On 8/2/22 1:02 PM, 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:
You're being used as an unwilling participant in a DNS amplification
attack.
Reconfigure your server to not be a public recursive DNS server. Only
respond to requests for your zones.
If you are also providing caching DNS for clients, use views to only
allow those clients to use the server for recursive lookups.
My clients use my internal view. My external view has:
match-clients { any; };
match-destinations { any; };
allow-query { any; };
allow-query-cache { localhost; };
recursion no;
I am way behind the times, as I really have not made any significant
changes to my config for a couple years. Things have been stable.
And I am running CentOS7-arm which only has 9.11.4...
BTW, I am in the market for a 'affordable' DNS box to run here and get
out of the business of maintaining my own software. I am approaching
72, and not something I want to do anymore. And I have not see a
service provider that would let me really config my own zone files...
--
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
Re: Stopping ddos
I've never actually used RRL, but from the manual, it appears to default to a /24 prefix length to determine whether IPv4 clients are "similar" enough to be lumped in the same bucket, for RRL purposes. That might need to be tweaked, depending on the profile of whoever is attacking/abusing you. The option is ipv4-prefix-length. IPv6 has a similar option, defaulting to /56. From your partial log extract, it looks like you're getting hit from different parts of the 114.29.192.0/19 netblock (which, according to APNIC, appears to belong to WebEx/Cisco). That's why I suggested you might want to tweak those settings. From the ARM, it looks like there are other configuration parameters too -- responses-per-second, nodata-per-second, nxdomains-per-second, referrals-per-second -- presumably all intended to provide fine-grained protection with minimal false positives. I would recommend a thorough reading of the ARM, and perhaps consultation with DNS admins who have practical experience with RRL. Hopefully there are some on this list. If you have a robust IPS in place, it should be possible, with the appropriate signature/rule, to drop all incoming root-domain queries. That's a pretty drastic solution, though, and there could be fallout. - Kevin From: bind-users on behalf of Richard T.A. Neal Sent: Tuesday, August 2, 2022 5:20 PM To: r...@htt-consult.com ; bind-users@lists.isc.org Subject: RE: Stopping ddos >> Any best practices on this? >> >> I am running bind 9.11.4 >> >> thanks > You could think about adding fail2ban to your server with some custom rules. > Helped us in a similar situation. You could also take advantage of BIND's built-in Response Rate Limiting which is explained here: https://downloads.isc.org/isc/bind9/9.16.31/doc/arm/html/reference.html#response-rate-limiting I don't recall if BIND 9.11 supports that feature, but even if it does you should really be upgrading to 9.16.31 anyway (the latest Current-Stable, ESV). Best, Richard. -- 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 -- 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
Re: Stopping ddos
On 8/2/22 1:02 PM, 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 You're being used as an unwilling participant in a DNS amplification attack. Reconfigure your server to not be a public recursive DNS server. Only respond to requests for your zones. If you are also providing caching DNS for clients, use views to only allow those clients to use the server for recursive lookups. -- 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
RE: Stopping ddos
>> Any best practices on this? >> >> I am running bind 9.11.4 >> >> thanks > You could think about adding fail2ban to your server with some custom rules. > Helped us in a similar situation. You could also take advantage of BIND's built-in Response Rate Limiting which is explained here: https://downloads.isc.org/isc/bind9/9.16.31/doc/arm/html/reference.html#response-rate-limiting I don't recall if BIND 9.11 supports that feature, but even if it does you should really be upgrading to 9.16.31 anyway (the latest Current-Stable, ESV). Best, Richard. -- 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
Re: Stopping ddos
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
Re: Stopping ddos
On 8/2/22 2:02 PM, Robert Moskowitz wrote: Any best practices on this? It looks like you're dealing with A queries for the root domain. I've blocked this, and similar queries, via iptables firewall in the past. Also, make sure that you apply the same BIND ACL to the cache that you do for queries. -- I had a system that didn't have the same ACL and rogue clients were able to get things from the cache despite not being able to initiate the queries directly. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: Stopping ddos
Dne úterý 2. srpna 2022 22:02:58 CEST, Robert Moskowitz napsal(a): > 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 You could think about adding fail2ban to your server with some custom rules. Helped us in a similar situation. Kind regards, David signature.asc Description: This is a digitally signed message part. -- 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
