How to enable Fail2Ban program filters in the ISPConfig server environment

botond published 2018. 07. 16., h - 01:41 time

Content

 

Introductory

A Fail2Ban is a very powerful protection program that can easily prevent, block malicious attempts from our server.

The system includes many filters by default, but only a few are turned on when the program is installed. By enabling them, for example, ApacheAttempts via can also be easily prevented. In this description, the previously compiled perfect server we will enable the Apache filter for Fail2Ban in our environment.

 

 

Jails, filters

Default settings a jail.conf file

Your default filters are stored in /etc/fail2/jail.conf. Here we can see the Apache section, where the same is located Jailbut are not allowed:

Configuring Fail2Ban - View the jail.conf file

The picture shows several Apache Jail (apache, apache-multiport, apache-noscript, etc.). Each option offers a filtering solution for different attack types.

Filters a filter.d directory

If you follow the filter file for that setting in /etc/fail2ban/filter.d:

Configuring Fail2Ban - contents of filter.d filter directory

You can see here that there are 59 filter files present at the moment. These include filter patterns and other settings for that particular Jail. In addition, you can create custom filters that better fit your needs.

Apache filter

Let's look at the "apache-auth" filter in the Apache Jail option:

nano /etc/fail2ban/filter.d/apache-auth.conf
# Fail2Ban apache-auth filter
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# apache-common.local
before = apache-common.conf

[Definition]


failregex = ^%(_apache_error_client)s (AH01797: )?client denied by server configuration: (uri )?\S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01617: )?user .*? authentication failure for "\S*": Password Mismatch(, referer: \S+)?$
            ^%(_apache_error_client)s (AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01614: )?client used wrong authentication scheme: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH\d+: )?Authorization of user \S+ to access \S* failed, reason: .*$
            ^%(_apache_error_client)s (AH0179[24]: )?(Digest: )?user .*?: password mismatch: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH0179[01]: |Digest: )user `.*?' in realm `.+' (not found|denied by provider): \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01631: )?user .*?: authorization failure for "\S*":(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01775: )?(Digest: )?invalid nonce .* received - length is not \S+(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01788: )?(Digest: )?realm mismatch - got `.*?' but expected `.+'(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01789: )?(Digest: )?unknown algorithm `.*?' received: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01793: )?invalid qop `.*?' received: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01777: )?(Digest: )?invalid nonce .*? received - user attempted time travel(, referer: \S+)?\s*$

ignoreregex = 

[...]

Here you can see the regular expressions that this filter is looking for. The first three lines of filters monitor useful things: The first one monitors your attempts to access directories that have been blocked in .htaccesses or virtual hosts, and the second two monitors your attempts to access directories that require basic HTTP authentication when you enter a bad username / password. These are more common cases, but the screenings below are also useful in less frequent cases.

So, in these filter files, we can look at the error messages that the filter is looking for and apply them if we see many of these error messages in our log files.

These filters are really useful when, for example, you are more familiar with open source CMS system we are running a web site where attackers / attackers arrive more routinely and try to identify known vulnerabilities and vulnerabilities.

I am now choosing this Apache filter in this example today because, based on my own practice, I also encountered several typical error messages from the above on this Drupal system page until I turned on this Jail.

Creating and Configuring a Custom Filter a jail.local file

So the task is simple, turn on this filter. We could also do this in the jail.conf file viewed above, but the creators of the program made sure that we did not have to mess with the factory settings, but instead made our custom settings in the local overwrite file (jail.local).

Accordingly, log in as root and open the /etc/fail2ban/jail.local file:

nano /etc/fail2ban/jail.local

Configuring Fail2Ban - Editing /etc/fail2/jail.local for Custom Settings

There are three filter settings in the file, exactly the ones set in perfect server putftftpd, dovecot-pop3imap, and postfix-sasl. We are now adding these with our Apache filter.

You can also copy the apache configuration from the jail.conf file as a sample and then convert it to ISPConfig system. The original settings are thus:

[apache]

enabled  = false
port     = http,https
filter   = apache-auth
logpath  = /var/log/apache*/*error.log
maxretry = 6

And after the changes, it looks like this:

[apache]
enabled  = true
port     = http,https
filter   = apache-auth
# logpath  = /var/log/apache*/*error.log
logpath  = /var/log/ispconfig/httpd/*/error.log
findtime = 3600
maxretry = 3
bantime  = 86400

The following changes have therefore been made:

  • enabled: true: This will enable the filter
  • logpath: Here we changed the path to the Apache log file because ISPConfig is / var / log / ispconfig / httpd /domain name> /error.log stores the Apache error log files of web pages.
    This will filter the error logs of all web pages on the server at the same time.
    (I only commented on the original, but I can take it out.)
  • findtime: Here we set the 3600 second time slice to be monitored
  • maxretry: And here I set it tougher, allowing up to 3 retries before being banned (so 4x can try in total)
  • bantime: I also set this tougher. The basic 600 seconds I pushed up in this filter for a day, just relax the IP address for a day trying.

We add the modified version to the end of the jail.local file:

Configuring Fail2Ban - Adding an Apache Filter to /etc/fail2ban/jail.local

And save it.

 

 

Restart Fail2Ban

restart the Fail2Ban daemon with the following command:

service fail2ban restart

 

Attention!
The jail.local file must exist in the path specified by logpath otherwise it will not restart in fail2! It does not report an error, but it does not restart. Only when you get the status below, you will notice that your daemon is not running.
So if you are experimenting with an empty server that has no web accounts yet, you need to make sure that you have the error.log file in the correct location.
In an empty ISPConfig environment, we can fix this by creating an empty file with the following command:
touch /var/log/ispconfig/httpd/<szervernév>/error.log 
By default, / var / log / ispconfig / httpd / has a directory called the server name. This is where additional subdirectories are created, with the domain names of the web pages you have created, which will already have error.log files.

 

Now that we're done, the system now monitors, filters, and disables errors in the above filter.

 

Inspection, testing

The following command allows us to monitor what was caught in Fail2:

fail2ban-client status apache

And the outcome when there was no ban:

Status for the jail: apache
|- filter
|  |- File list:        /var/log/ispconfig/httpd/szerver1.linuxportal.info/error.log
|  |- Currently failed: 0
|  `- Total failed:     0
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned:     0

You can also view the complete filter test of Fail2Ban with this command (for debugging, etc.):

fail2ban-client -d

The log of Fail2Ban can be found in /var/log/fail2ban.log, which details the system shutdown / boot and the blocked and unlocked IP addresses.

 

Conclusion

With this Fail2Ban setting, we can compete with attackers trying to try through Apache, so we can protect our server more effectively. In addition, the program can provide protection in many other areas of the server where the particular network service records events on a log file basis.