Issue Named attack

[EnriqueR]

I am having a problem with my Plesk server since for a few weeks it is being attacked using brute force in named. I have noticed that in the file '/var/log/messages' the following line appears thousands of times:

Nov 22 16:43:04 myserver named[571]: client x.x.x.x#49784: query (cache) 'domain.com/A/IN' denied
Nov 22 16:43:04 myserver named[571]: client x.x.x.x#49784: query (cache) 'domain.com/A/IN' denied
...

Most domain.com logged no longer exist in my VPS.
I have seen in a forum that adding the following content in the file '/etc/named.conf' solves the problem:

options{
...
allow-query-cache { none; };
recursion no;
additional-from-auth no;
additional-from-cache no;
minimal-responses yes;
...
}

But I can not modify this file because on entering it says:

#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED

I created two filter rules in fail2ban (named-refused-tcp, named-refused-udp) explained here and working ok:

https://talk.plesk.com/threads/dns-recurcion-problem-or-attack.312799/

But although it works, it does not stop filtering different IPs without limit. It currently has 1500 and up. According to the modification I indicated above in named.conf, this attack would be solved without having to work fail2ban, which is much more effective.

How can I modify the named.conf file? Or if you have another solution to mitigate the attack ...

 

[trialotto]

@EnriqueR

The problem with Fail2Ban is that it is

- iptables based,
- allowing bans during a specific period of time (hence requiring resources to keep track of IPs to ban and IPs banned)

implying that both Fail2Ban and any iptables based firewall can become a bottleneck, or even a cause of problems.

One can configure Fail2Ban to use a custom jail and filter, in order to block really bad IPs in the /etc/hosts.deny file: this is a quick and efficient fix.

One can also configure named by using the "include" statement in the named.conf file, which allows you to put your modifications in a separate file.

In my opinion, the "hosts.deny" option is the most efficient, if and only if the bad IPs are blocked for a very long period (consider a ban period of 1 year).

Hope this helps a bit.

Regards......

 

[EnriqueR]

@EnriqueR

The problem with Fail2Ban is that it is

- iptables based,
- allowing bans during a specific period of time (hence requiring resources to keep track of IPs to ban and IPs banned)

implying that both Fail2Ban and any iptables based firewall can become a bottleneck, or even a cause of problems.

One can configure Fail2Ban to use a custom jail and filter, in order to block really bad IPs in the /etc/hosts.deny file: this is a quick and efficient fix.

One can also configure named by using the "include" statement in the named.conf file, which allows you to put your modifications in a separate file.

In my opinion, the "hosts.deny" option is the most efficient, if and only if the bad IPs are blocked for a very long period (consider a ban period of 1 year).

Hope this helps a bit.

Regards......

@trialotto I can not use "hosts.deny" because IPs are constantly changing between attacks. And I can not include nothing in the named.conf file because it clearly states that is generated automatically.

 

[trialotto]

@EnriqueR

Using Fail2Ban to write to hosts.deny will allow you to (automatically) update the hosts.deny file (read: add and delete IPs, according to the Fail2Ban jail and filter specifications).

So, IP changes are not that relevant: they simply result in another line in the hosts.deny file.

Regards.....