I already wrote about how to ban Wordpress bruteforce attacks with Fail2ban. Then, after my Apache logs, I started to have a look at my ISC Bind name server logs (because I run my own DNS server). And I noticed some bad stuff in them. Nothing really terrifying, but serious enough to decide to do something about it. And I learned a thing on dig. More on that later...

No filter to create, but a hell of a log configuration

Fail2ban installations come with a boatload of filters. Depending on the operating system, the installation path may differ, but if you know where your filter.d directory is, I suggest to have a look at it and check if some of them can be enabled, depending on the server's role. Basically, these files tell Fail2ban how to spot bad stuff. And speaking of bad stuff, there is a file named named-refused that looks for failed zone transfers and denied requests.

The next question is : which log file is needed for the filter to work and what should be there ? It turns out this filter file is self-documented, and if it's not already configured, suggests a security logging configuration for Bind. Here is a copy of it :

logging {
    channel security_file {
        file "/var/log/named/security.log" versions 3 size 30m;
        severity dynamic;
        print-time yes;
    };
    category security {
        security_file;
    };
};

For more information on the logging features of Bind, there is the Bind 9 Administrator Reference Manual.

In my personal case, I already had extensive logging options enabled, with a separate security log file configured.

Fail2ban jail configuration

Once the logging part is read, time for some jail configuration ! The minimum configuration is just enabling the jail, but if the path to the log file is not the default, it can be reconfigured. The below configuration :

• enables the jail;
• gives the log file's path;
• tunes the limit before an IP gets banned.

[named-refused]
enabled = true
logpath = /var/log/named/security.log
maxretry = 3

Fail2ban jail usage

Now, let's restart the fail2ban service to get the new configurations applied, and a few seconds later, check everything is working with the command : fail2ban-client status named-refused. This should work similarly to the previous blog post.

And that thing on dig ?

I run an autoritative-only DNS server, so I have disabled recursion. If something makes a recurse request, it will be denied and there will be a log entry. What I learned from these log lines is that by default, the dig tool makes recurse requests. In order to stop this, it is possible to add the +norecurse option.

I hope you enjoyed this post ! If you did, please share it on your favorite social networks :-)

Photo by Martin Sanchez on Unsplash.