Fail2Ban SSH Nginx Persistent Bans Ubuntu 16.04Fail2Ban 0.91 for SSH Nginx Persistent Bans on Ubuntu 16.04

Fail2Ban is one of the greatest linux security modules out there. Many Linux administrators have at one point or another, or even constantly, found their servers under attack. If you have not heard of Fail2Ban it’s certainly time you dedicated some time setting it up to help you block many types of DDOS and brute force exploit attempts against your server.

Why Fail2Ban and is it enough?

Fail2Ban is certainly not the only security module for a Linux or Ubuntu server but it is in my opinion absolutely essential to help you not only block rogue attempts but to also know that it is happening in the first place.

Your first steps in securing any Linux server involve a lot more than just setting up Fail2Ban. So if basic security is what you are after right now then this guide is perhaps a little beyond you. You should rather be getting your Firewall (IP Tables), SSH Shell Access with Keys, Tripwire, Log Monitor, Apache and Nginx security and seriously strong password schemes setup before you even go any further.

Do you even have a security model to follow or are you just scrambling around trying to stop people from already brute force attacking your server?

Certainly follow this guide if you answered yes to the last question but please make sure you deal with securing your entire server and not just plugging holes. Fail2Ban is not a band-aid although it can be used very effectively as one but it really should be considered a tool and not something to rescue you from an already compromised server.

So what exactly is Fail2Ban?

Fail2Ban at the time of this writing is now at version 0.91 and it has come a long way since it was first created and since I started using it. Fail2Ban is an open source project that effectively scans your server log files in real time looking for any activity that matches any of the filters / jails you have enabled in the configuration file.

If Fail2Ban sees any activity like, oh let’s say someone trying to access your server with SSH it immediately picks up this activity in your /var/log/auth.log file and then carries out whatever banning policy you have set for that particular behavior.

It’s a very simple concept and when configured properly it is a really invaluable set and forget tool for dealing with offenders and also helping you have first hand knowledge of what is going on all the time.

Fail2Ban SSH Nginx Persistent Bans Ubuntu 16.04The concepts and required components

An essential part of this tutorial is that you have a working IPTables Firewall setup on your Ubuntu server. If you have not even set up IPTables then you will need to do that before even continuing because Fail2Ban uses IPTables to block offenders in real time. It’s also essential that you have IPTables-Persistent running on your Ubuntu server which loads your IPV4 and IPV6 rules at startup every time you reboot your server.

This guide also assumes you are running Nginx or an Apache web server. The first part of this guide will deal with setting up Fail2Ban for an Nginx web server and setting up the jails for SSH attacks. At the end of the article I will also show you some jails for Apache and how to enable and configure them.

So … talking concepts …. you have now seen me talk about jails a few times already, what are they and how do they work? Essentially jails are just configuration sections inside Fail2Ban. Each jail deals with one type of attack and it can be configured to do certain things. Fail2Ban comes with many preconfigured jails that simple have to be enabled or disabled as you please.

Each jail also has a corresponding action and filter file which are the files which give that jail the ability to do certain things like write an entry into your iptables, send you an email and later remove an entry from your firewall when it has expired.

Basic Banning with Fail2Ban

Let’s also understand the concepts now of basic banning. A first time offender comes along and tries to get into your server guessing usernames and passwords against SSH. So he tries a brute force attack and sends 40 usernames and passwords in just 5 seconds. Your SSH jail will ban him for 10 minutes or so after just picking up 6 attempts from your auth.log file. So in this case the SSH jail was set to ban after just 6 attempts and to drop the intruder from accessing the server for just 10 minutes. Now don’t forget¬† the intruder sent 40 attempts, we will deal with that later.

Now let me also explain why in this case I only said 10 minutes. 10 minutes is more than enough to drop IP’s who are out there scanning hundreds of IP’s a minute and carrying out bruce force attempts. Most of their brute force attempts last a few seconds and they are already gone and scanning another server unless they got into yours. So in most cases you may never see that IP attack again and if they do we deal with them with persistive banning.

The reason for this thought process is that you don’t need to be creating hundreds of firewall rules in your iptables every day for each and every single IP address that happened to try and exploit you. Your iptables will become a mess very quickly and it is better to rather deal with repeat offenders very separately from the once-offs.

Also keep this in mind, after going through this guide and setting up Fail2Ban you will for the first time ever actually know people are trying to attack your server and you will have many emails in just 24 hours which you never had before. This information should not scare you, it’s information and it’s valuable information. It does not mean you must now go overboard and start blocking every single IP address you see and waste your time sending emails to network’s abuse departments. You will quickly find yourself with no time left in a day to do anything else.

Ok, Ready Set and GO, let’s start configuring Fail2Ban

On Ubuntu installing Fail2Ban is very easy, it’s in the repo’s so it’s a matter of simply running

sudo apt-get install fail2ban

That was easy ūüôā Fail2Ban also uses either sendmail or mail to send you emails about the attacks. In this tutorial I just use the mail command which uses mailutils. So install it.

sudo apt-get install mailutils

Ok so now we have the basics, now it is time to start configuring Fail2Ban and your first jail.

The first thing you will do now is create copies of the config files where you will configure your jails. It is important not to go messing with the main config files. Fail2Ban checks for your local copies and this is the correct way of configuring things and it is easier to diagnose when you have made a syntax mistake in a file.

There are two files we will deal with here your jail.local and fail2ban.local files. These files do not exist so we will create them.

sudo cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

So now we have our local files so we can now take a look inside the first one.

sudo nano /etc/fail2ban/fail2ban.local

I never haphazardly copy and paste stuff from forums (and neither should you) because it always causes trouble but be assured this has been all been thoroughly tested.

This whole tutorial is aimed at giving correct advice and settings for Fail2Ban as I have already been through so many forums with some very bad copy and paste settings for Fail2Ban, mostly older versions, that will break this new version quickly.

With that said, you do all of this at your own risk and I am not responsible for anything else that happens as a result. That unfortunately just has to be said.

because your fail2ban.local file is a LOCAL file, you can replace everything in the file with just the following below. This is basically just what is in the fail2ban.conf file but without all the comments. I find this approach neater for me but for now you can just leave the file as is if you want all those comments to be able to understand the later. Remember you can always view the main fail2ban.conf file if you require those commented sections again. So here is my fail2ban.local file contents with all comments removed.

# Fail2Ban local configuration file

[Definition]
loglevel = INFO
logtarget = /var/log/fail2ban.log
syslogsocket = auto
socket = /var/run/fail2ban/fail2ban.sock
pidfile = /var/run/fail2ban/fail2ban.pid
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 86400

Nothing in my fail2ban.local has been changed other than the log level which I have changed from ERROR to INFO.

You can now CTRL+X and save the file.

The next file we will open is your jail.local file. Once again I have stripped out all the comments to make it neater and I have also removed all the jails I do not use or ever need. Remember, you can always add additional jails later by simply copying them from the jail.conf file which as I mentioned never ever gets fiddled with.

sudo nano /etc/fail2ban/jail.local

In my case below I only have 6 jails, so everything else has been removed from my jail.local file. So let’s open our jail.local file and replace everything inside with the following. The bolded sections below must be changed to reflect your own email addresses etc. You should also remove the 111.111.111.111 and 222.222.222.222 IP addresses from the ignoreip line, they are just their to demonstrate syntax.

I have also wildcarded the log locations so that even when logs are rotated and become .log.gz Fail2Ban will continue monitoring them. Likewise if you have more than one web site running on the server make sure they all end in access.log so if you have site1-access.log and site2-acccess.log Fail2Ban will still read all of them.

NOTE: In the older 0.8 version of Fail2Ban, each IP was added on a single line with ignoreip = before each IP. This does not work anymore on 0.9 and crashes Fail2Ban on a restart. It took me 2 hours to figure that one out and it was not documented anywhere. In fact it is just this one silly syntax mistake that seems to have people running around saying their Fail2Ban is broken and then having people on forums telling them to disable all sorts of things like SELinux (AppArmor) on their servers. Trust me, you never need to disable SELinux, doing so it just utterly stupid advice. Fail2Ban works 100% perfectly out of the box on Ubuntu and the only time it will not start on an Ubuntu server is when your config files are messed up, it really is as simple as that !!!

#
# Local Jail.conf File
# Comments: use '#' for comment lines and ';' (following a space) for inline comments


[INCLUDES]
before = paths-debian.conf

[DEFAULT]

# Add any IP's to ignore below - all on one line with spaces 
# between them remove 111.111.111.111 and 222.222.222.222
# they are just here to demonstrate syntax
ignoreip = 127.0.0.1/8 111.111.111.111 222.222.222.222
ignorecommand =

# Ban and Fine Time in Seconds
bantime  = 600
findtime  = 600

# Maximum attempts before banning intruder
maxretry = 6

backend = auto
usedns = warn
logencoding = auto

# Default Action All Filters Disabled
enabled = false

# Default Filter Name Uses Jail Name
filter = %(__name__)s

# Mail Settings
destemail = me@mydomain.com
sender = fail2ban@mydomain.com
sendername = Fail2Ban
mta = mail

# Firewall Defaults
protocol = tcp
chain = INPUT
port = 0:65535
banaction = iptables-multiport

# Our Banning Action
# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
             %(mta)s-whois-lines[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s"]

# Choose default action.
action = %(action_mwl)s

# NOTE: Other actions removed. Review jail.conf file for all 
# other available options like action_ action_mw action_xarf
# action_cf_mwl action_blocklist_de and action_badips
# I find action_mwl to be more than adequate for my needs and 
# the others especially xarf, blocklist_de and badips should 
# be used with utmost care and only when you know what you are doing

#
# JAILS
#

#
# SSH servers
#

[sshd]
enabled = true
port    = ssh
filter = sshd
logpath  = /var/log/auth.*
maxretry = 6

[sshd-ddos]
enabled = true
port    = ssh
filter = sshd-ddos
logpath  = /var/log/auth.*
maxretry = 6

#
# HTTP servers
#

[nginx-http-auth]
enabled = true
port    = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/*access.log*
maxretry = 6

[nginx-botsearch]
enabled = true
port     = http,https
filter = nginx-botsearch
logpath  = /var/log/nginx/*access.log*
maxretry = 6

[nginx-noscript]
enabled = true
port     = http,https
filter = nginx-noscript
logpath  = /var/log/nginx/*access.log*
maxretry = 6


# Jail for more extended banning of persistent abusers
# !!! WARNINGS !!!
# 1. Make sure that your loglevel specified in fail2ban.conf/.local
#    is not at DEBUG level -- which might then cause fail2ban to fall into
#    an infinite loop constantly feeding itself with non-informative lines
# 2. Increase dbpurgeage defined in fail2ban.conf to e.g. 648000 (7.5 days)
#    to maintain entries for failed logins for sufficient amount of time

[blacklist]
enabled = true
logpath  = /var/log/fail2ban.*
banaction = blacklist
bantime  = 31536000   ; 1 year
findtime = 31536000   ; 1 year
maxretry = 10

Now CTRL+X and save the file.

We now have to create our nginx-noscript filter file now which is not there by default. It’s a very simple file which checks for bots that are scanning your server for executable files. In my case I run wordpress on this server so my no-script bot checker for nginx checks for everything except .php files which as you know is what wordpress runs on. You can also add other script types to this config but as it is below is more than enough to detect bots. You will also notice almost everything with Fail2Ban runs using Regex filters so if you understand Regex you can customize Fail2Ban till the end of time.

sudo nano /etc/fail2ban/filter.d/nginx-noscript.conf

and paste the following into the file

[Definition]

failregex = ^<HOST> -.*GET.*(\.asp|\.exe|\.pl|\.cgi|\.scgi)

ignoreregex =

CTRL+X and save the file.

Ok so that’s the basic configuration done for checking our auth and nginx logs for attempts against SSH and Nginx.

Now you must create my custom action and filter files for the [blacklist] repeat offender jail. My [blacklist] jail is an open source project on GitHub.

So now create our action

sudo nano /etc/fail2ban/action.d/blacklist.conf

and paste the following contents into that file

# /etc/fail2ban/action.d/blacklist.conf
# Fail2Ban Blacklist for Repeat Offenders (action.d)
# Version: 1.0
# GitHub: https://github.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning
# Tested On: Fail2Ban 0.91
# Server: Ubuntu 16.04
# Firewall: IPTables
#

[INCLUDES]
before = iptables-common.conf


[Definition]
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#

actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> -p <protocol> -j f2b-<name>
              # Sort and Check for Duplicate IPs in our text file and Remove Them
              sort -u /etc/fail2ban/ip.blacklist -o /etc/fail2ban/ip.blacklist
              # Persistent banning of IPs reading from our ip.blacklist text file
              # and adding them to IPTables on our jail startup command
              cat /etc/fail2ban/ip.blacklist | while read IP; do iptables -I f2b-<name> 1 -s $IP -j DROP; done

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#

actionstop = <iptables> -D <chain> -p <protocol> -j f2b-<name>
             <iptables> -F f2b-<name>
             <iptables> -X f2b-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#

actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j DROP
            # Add the new IP ban to our ip.blacklist file
            echo '<ip>' >> /etc/fail2ban/ip.blacklist

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = <iptables> -D f2b-<name> -s <ip> -j DROP
            # Remove IP from our ip.blacklist file
            sed -i -e '/<ip>/d' /etc/fail2ban/ip.blacklist

[Init]

CTRL+X and save the file

now create our filter file

sudo nano /etc/fail2ban/filter.d/blacklist.conf

and paste the following into that file

# /etc/fail2ban/filter.d/blacklist.conf
# Fail2Ban Blacklist for Repeat Offenders (filter.d)
#
# Version: 1.0
# GitHub: https://github.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning
# Tested On: Fail2Ban 0.91
# Server: Ubuntu 16.04
# Firewall: IPTables
#

[INCLUDES]

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

[Definition]

_daemon = fail2ban\.actions\s*

# The name of the jail that this filter is used for. In jail.conf, name the 
# jail using this filter 'blacklist', or change this line!
_jailname = blacklist

failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)NOTICE\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

ignoreregex = 

[Init]

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=5

CTRL+X and save the file.

Now To make our changes effective now we simply need to restart the Fail2Ban service as follows.

sudo service fail2ban restart

If you get no errors, the service will gracefully restart. If you get any errors then you have a syntax error which is unlikely if you copied and pasted exactly what I had above but let’s say you accidentally typed something and it broke your config file’s syntax …. how do you fix it?

It is actually very simple to diagnose Fail2Ban for syntax errors.

So let’s get into how to diagnose a syntax error and why your Fail2Ban is not restarting.

First make sure it is stopped by running

sudo service fail2ban stop

and

sudo fail2ban-client -vvv -x stop

Now you can start just the client portion of fail2ban with verbose logging to see if there are any errors or warnings. This is done simple by running

sudo fail2ban-client -vvv -x start

It will give you a verbose output of the startup process and there you can quickly trace errors. Remember what I said earlier in this tutorial, the ONLY way you can really break Fail2Ban from restarting is by having broken syntax in your jail.local file or a filter or action file that you messed with.

Do not go messing with other things in Ubuntu trying to get Fail2Ban to work when syntax is what broke it in the first place. There is proof of this, if you run into a serious syntax problem that you cannot solve, simply rename your jail.local file to old.jail.local and restart Fail2Ban and you will see it magically restart. Proof enough that errors are always in your jail.local file.

While you are tracing a syntax error you can continually just start and stop the client portion with the verbose settings as above. When you have it fixed make sure to first stop the client using the sudo fail2ban-client -vvv -x stop command BEFORE you restart the Fail2Ban Service.

Ok so that’s some basics on how to diagnose syntax errors. So now let’s make sure our service is running.

sudo service fail2ban restart
sudo fail2ban-client status

you will get the following output (based on my jail.local file above)

Status
|- Number of jail:      6
`- Jail list:   blacklist, nginx-botsearch, nginx-http-auth, nginx-noscript, sshd, sshd-ddos

So that’s it, your Fail2Ban is now running with the 6 jails I had configured in my jail.local file.

So now how do you test it is working?

This is where you must be careful because you WILL lock yourself out of your server if you do not know what you are doing. I have a completely separate non-critical server with it’s own dedicated IP address which I use for testing. I use that server and that server alone to simulate scan attempts against Fail2Ban, so if that server gets locked out I can still access my main web server which runs Fail2Ban and remove my test server from it’s IPTables and continue testing.

Do not run these tests from your home ADSL / Fibre network as you will lock yourself out and then unless your ISP can issue you another IP address you are screwed for the default time in our jail.local file which bans you for 10 minutes.

So let’s run a simple test then from our dedicated testing server. For this purpose I use an Ubuntu server with the Gnome Desktop environment installed. So it’s as simple as opening firefox and running the following 7 commands one at a time. The reason we run 7 commands because you will see when you run the 7th command that the limit of 6 has been reached and your browser stops responding on the 7th command because fail2ban has blocked you.

http://myserver.ip/test.asp      < (Response 404 not found)
http://myserver.ip/test.cgi       < (Response 404 not found)
http://myserver.ip/test.pl         < (Response 404 not found)
http://myserver.ip/test.scgi      < (Response 404 not found)
http://myserver.ip/somethingelse.asp   < (Response 404 not found)
http://myserver.ip/whatever.exe          < (Response 404 not found)
http://myserver.ip/hey.asp                  < No Response ..... BLOCKED

Now if you look on your server running Fail2Ban you will see your test server is blocked.

sudo iptables -S

At the very bottom you will see your IP blocked as follows

-A f2b-nginx-noscript -s 198.111.222.111/32 -j REJECT --reject-with icmp-port-unreachable

Now remember that the ban is in effect for 10 minutes based on our default bantime = 600 seconds in our jail.local file. So if you did lock yourself out you only have ten minutes to wait before Fail2Ban removes the IPTable entry for you and it does this perfectly too by the way.

You will also see that the default ban action used by Fail2Ban drops the offender with the ICMP Port Unreachable which is enough to let an attacker know you are watching and they have been dropped from accessing your server.

When we deal with permanent bans these are done using the DROP command in iptables which makes it seems to them like your server just does not even exist and is completely offline.

Now also check that Fail2Ban sent you an email about it (assuming you put your email address in properly above in your jail.local file)

If Fail2Ban is mailing correctly you will get an email with the subject.

nginx-noscript: banned 198.111.222.111 from yourserver

In the mail you will see detailed information as follows

Hi,

The IP 198.111.222.111 has just been banned by Fail2Ban after
6 attempts against nginx-noscript.

Here is more information about 198.111.222.111 :

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

Real life hack attempts start surfacing

You will probably also within the first 10-20 minutes of having Fail2Ban running have received several other emails of actual IP’s that have been banned for abusing your server. Isn’t it wonderful to now know its happening ? whereas before you were truly sitting in the dark. As I said earlier don’t get a fright now because you will get notified of each and every intrusion attempt, rest assured that Fail2Ban is dealing with them appropriately don’t get all wound up and stressed out about it.

In fact the first morning I ever got onto my email after first ever configuring Fail2Ban on my primary web server I was quite horrified but it was finally good to know what I previously knew was going on but had no idea how to easily visualize and deal with it.

So let’s get into permanent banning

So now what do we do with repeat offenders and permanently banning them. If you study the original jail.conf file you will see a jail at the very bottom called recidive. The recidive jail deals with repeat offenders but by default Fail2Ban’s recidive jail does not make the bans persistent across reboots and I found recidive to be a little lacking in control and a little bit incomplete for me.

So, I have written my own custom [blacklist] jail for Fail2Ban which does a better job than recidive (for me anyhow) and is 100% fool proof and works across reboots too and I have fully tested it too. So here is how to deal with repeat offenders using my custom [blacklist] jail. My custom jail is based on recidive but it has a lot more control and a lot more certainty. Perhaps one day it will officially replace recidive.

In my [blacklist] jail filter I deal with offenders quite strictly, I drop them for 1 year and I have my jail set to scan through the fail2ban.log file for 10 attempts by the same IP address within a year. So certainly this is something you can change in your own [blacklist] jail you can change the bantime, findtime and maxretry values. Remember the values for bantime and findtime are in seconds and maxretry is a number of attempts to look for.

As you will read a little later, it is important to understand the logic of the [blacklist] jail and once you understand my special note a little lower down about the [blacklist] logic you will then understand why after 10 attempts I block an IP for a year. Look for “Special Note About [blacklist] or Recidive Jailing” lower down.

But let’s say you did want something a little less strict on offenders (keeping in mind they tried to exploit your server of course), then you would change your [blacklist] jail as follows. Which will ban an offender for 30 days if they carry out 20 attacks within a 1 week period.

[blacklist]
enabled = true
logpath  = /var/log/fail2ban.*
banaction = blacklist
bantime  = 2592000   ; 30 days
findtime = 604800   ; 1 week
maxretry = 20

This will check your fail2ban log for 20 attempts by the same IP address anywhere within a period of 1 week and then ban that attacker for 30 days. Why I think you can stick with my original jail rules for [blacklist] is for this reason. If you have a true repeat offender, every 30 days you are simply removing him from IPTables and then the [blacklist] jail will probably just add him right back again. This is why I allow Fail2Ban to scan through a whole years worth of logs and if that person tried more than 10 times block them for 1 year and be done with them.

In other servers of mine running Fail2Ban over an entire year I have perhaps under 100 IP’s that are truly and permanently blocked so it truly does only block those who have been continuously and repetitively bad boys.

Please always remember to sudo service fail2ban restart after every single change to your jail configurations.

ALSO PLEASE PLEASE PLEASE …. only make one change to one jail at a time and test it thoroughly. Do not haphazardly go fiddling with settings all over your jail.local file and then expect they will all just work, you will no doubt just break Fail2Ban which will fail on it’s next restart with syntax errors.

Customizing the Blacklist (Repeat Offender) Jail for Permanent Bans

Earlier on we already created the action and filter for our [blacklist] jail. These file are located in /etc/fail2ban/action.d/blacklist.conf and /etc/fail2ban/filter.d/blacklist.conf. These two actions of mine make bans persistent, which means that every time you reboot your server it will re-add the Bad IP’s into IPTables upon restart.

It will also automatically remove IP’s that have been banned after their time period of being banned has lapsed. If they come back the next day and do it again it will pick them up immediately and ban them again for another whole year.

My custom [blacklist] function / jail requires a simple text file called ip.blacklist which you have to create now on your server.

sudo touch /etc/fail2ban/ip.blacklist

Why I do it this way and why it is done this way is for several reasons. Your main iptables rules.v4 file (part of IPtables-Persistent) is where your default firewall rules are configured. Those rules are your main firewall and should only be changed when you add or remove particular services you want to allow through your firewall or block from your firewall.

The adding of BAD IP’s is only done after the server has started and loaded your rules.v4 file. Fail2Ban then adds the repeat offenders from the ip.blacklsit file which is something that is constantly changing so these rules for the repeat offenders must not be saved to your rules.v4 file at all. It will cause serious duplication issues in your iptables trust me.

Remember Fail2Ban is constantly monitoring your firewall, adding new blocks and removing them when it expires, there is nothing you need to do.

My simple little text file ip.blacklist is super lightweight, as light weight as can be and I can assure you it will add no overhead to fail2Ban or your server. My [blacklist] actions are also very efficient at dealing with any duplicates and are also very efficient at cleaning up after themselves.

Now you can go ahead and test from your TEST server only. The easy way is to run the very same attacks as above against your Nginx server. Run all 7 in a row again because by now your earlier 10 minute ban has expired. So go ahead and run the very same 7 commands as below.

http://myserver.ip/test.asp      < (Response 404 not found)
http://myserver.ip/test.cgi       < (Response 404 not found)
http://myserver.ip/test.pl         < (Response 404 not found)
http://myserver.ip/test.scgi      < (Response 404 not found)
http://myserver.ip/somethingelse.asp   < (Response 404 not found)
http://myserver.ip/whatever.exe          < (Response 404 not found)
http://myserver.ip/hey.asp                  < No Response ..... BLOCKED

You should now be banned again for 10 minutes.

Confirm this on your Fail2Ban server by running sudo iptables -S and see if your IP is once again blocked. Also check your mail again to make sure Fail2Ban sent you another email about this naughty repeat offender namely YOU ūüôā

Wait 10 minutes until you are unbanned by your server and run the very same 7 commands again. Each time you are doing this you are registering 6 attempts against Nginx. So at this point in time having run it twice we have clocked up 6 attempts on 2 separate occasions in one day.

We are looking to reach the magic number specified in our [blacklist] filter of 10 separate attempts. It’s important to understand this logic because it will drive you mad if you don’t and you quickly think jails are not working.

Special Note About [blacklist] or Recidive Jailing -So our [blacklist] filter looks for our IP that took 10 attempts at our server, each attempt tried 6 times so that’s 60 attempts but [blacklist] is looking at the individual attempts spread apart before it gets to its own count of 10 and only then permanently blocks the IP address. Many people make the mistake of thinking that just running the individual intrusion simulations above 12 times should make [blacklist] kick in but it will not. Its only going to see it as 2 attempts of 6 each … not 10 attempts in total. Comprende ? This should now give you a better understanding of how a repeat offender is truly picked up as one.

So we have to repeat this over and over another 8 times at least before our [blacklist] will kick in. You can speed this process up by manually removing your IP address entry from IPTables yourself. I like to do every test thoroughly though to watch the entire adding of temporary bans and that they are cleared each time by Fail2Ban and not me.

You can also speed this up by changing bantime = 10 and maxretry = 1 in your jail.local file. This will ban you for only 10 seconds each time and lock you out after only one attempt. If you understand the basic bantime and maxretry settings you can adjust things very quickly to suit your needs especially when it comes to testing.

Modify the LogRotate Settings for Fail2Ban

Now we also need to modify how our logs are rotated in Fail2Ban so that it has a longer range of log files to access. In my case I want Fail2Ban to be able to scan for attack attempts by one IP anywhere within a year so my log rotate settings for Fail2Ban are as follows.

sudo nano /etc/logrotate.d/fail2ban

and change it to be as follows

/var/log/fail2ban.log {
    			monthly
    			rotate 13
    			compress
			delaycompress
    			missingok
    			notifempty
    			postrotate
			fail2ban-client flushlogs 1>/dev/null
    			endscript
    			create 640 root adm
				}

This rotates the logs on a monthly basis, compresses the old log files into .gz (gzip) format (which Fail2Ban can still scan) and then delete’s old Fail2Ban logs after 13 months.

CTRL+X and save the file

Ok so now if you did all your continuous attack testing against NGINX you will by now have received 10 emails from Fail2Ban each stating that your IP was blocked after 6 attempts against nginx-noscript.

If you have not received an email from Fail2Ban’s [blacklist] filter then run the simulated attacks against nginx one more time.

So now we are permanently banned

Finally you will receive an email from Fail2Ban’s [blacklist] filter saying that the same IP (your testing IP) is blocked permanently.

The subject line of the email will appear as follows

blacklist: banned 198.111.222.111 from yourserver

The contents of the email will appear as follows

Hi,

The IP 198.111.222.111 has just been banned by Fail2Ban after
10 attempts against blacklist.


Here is more information about 198.111.222.111 :


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

If you now go and check iptables you will see your IP is blocked again with the blacklist filter.

sudo iptables -S
-A f2b-blacklist -s 198.111.222.111/32 -j DROP

One last check is to see that it wrote our IP to the ip.blacklist file we created earlier

cat /etc/fail2ban/ip.blacklist

and you will see your IP address listed in the ip.blacklist file

One last test now is to reboot your server and see that the IP gets added to the iptables firewall on startup with a proper drop command in iptables.

So let’s

sudo reboot

after reboot run

sudo iptables -S

and you will now see the following

-A f2b-blacklist -s 198.111.222.111/32 -j DROP

That is it, you now have Fail2Ban configured with perma and persistent banning capabilities and it’s also all fully automated.

Now cleanup after yourself !!!

Remember though that your testing IP is now actually permanently blocked. So it’s a good idea now to delete your IP from the ip.blacklist file and even start with everything afresh and clear your fail2ban log file.

If you dedicate one entire day configuring and testing jails you will have a fully configured Fail2Ban in one day. Then at the end of the day it would be a good idea to stop fail2ban and clear the fail2ban.log file completely and clear all your nginx and auth.log files for good measure and also reboot the server and let it loose to run live now.

To completely flush the Fail2Ban log file and Clear our Blacklist File

sudo service fail2ban stop
sudo truncate -s 0 /var/log/fail2ban.log
sudo truncate -s 0 /etc/fail2ban/ip.blacklist
sudo rm /var/lib/fail2ban/fail2ban.sqlite3
sudo service fail2ban restart

What will happen if you don’t do this?

The next time Fail2Ban starts it will do exactly as it is programmed to do, it will scan through all your auth.log files, find your IP which offended more than 10 times and block it immediately.

Remember computers will only do what you told them to do, so be careful with Fail2Ban, it will block you out.

Now is also an important time to

Whitelist your Important IP addresses

You don’t want your own servers to ever be blocked from contacting each other but it can happen if ever something went wrong. So whitelisting your IP’s of your own and other servers of yours is important to add into your jail.local file in the ignoreip section. PLEASE REMEMBER as noted earlier on. Add the IP’s all on one line seperated by a space between each IP address.

Have fun with Fail2Ban now

Now that you have Fail2Ban running with 6 perfectly functioning jails it is time for you, if you feel the need, to add other jails that you might need.

Let’s say you also run Postfix mail server on your server, you will simply then copy the jail sections from the jail.conf file and paste them into your jail.local file.

PLEASE I cannot stress this enough, only add ONE RULE AT A TIME AND TEST. You really will thank me later for this, I mistakenly spent an entire day diagnosing syntax errors and no functioning jails simply because I too just fiddled with 6 jails all at the same time. Add one test fully and move forward onto the next one.

What about some Apache Jail Rules ?

So now as promised earlier I said I would add some of the jails for Apache Web Server in case you are running that and not Nginx.

From the jail.conf file copy the following jails and past them into your jail.local file and remember … one at a time.

You can by all means paste all 4 of these at one time into your jail.local file but then set the first one to be enabled = true and set the other 3 to be enabled = false. And then just enable the next one after you have tested the first one thoroughly.

[apache-auth]
enabled = true
port     = http,https
logpath  = /var/log/apache2/*access.log*


[apache-badbots]
# Ban hosts which agent identifies spammer robots crawling the web
# for email addresses. The mail outputs are buffered.
enabled = true
port     = http,https
logpath  = /var/log/apache2/*access.log*
bantime  = 172800
maxretry = 1


[apache-noscript]
enabled = true
port     = http,https
logpath  = /var/log/apache2/*access.log*
maxretry = 6


[apache-botsearch]
enabled = true
port     = http,https
logpath  = /var/log/apache2/*access.log*
maxretry = 2

 

These are the only initial jails I would configure for Apache. You will see in the main jail.conf file there are 9 Apache rules, some of them are a little more sensitive and complex and I would start with basics if I were you and then work your way up to seeing later what the other filters do.

Remember that each filter has corresponding files in the /etc/fail2ban/filter.d folder so you can open those files and see what regex expressions they are using and modify them as you need.

BE CAREFUL though with the [apache-noscript] jail above. By default it is configured like our Nginx jail to scan for anyone calling .php, .asp, .exe, .pl and .cgi files so if you are going to use this jail and you are running wordpress sites which rely on PHP, you will need to modify the regex string to exclude PHP.

Inside each filter file you will see documentation and warnings, this is the true place to study what each jail is capable of and Fail2Ban has kept things really simple by naming each filter file the exact same name as the jail.

So let’s say you want to modify or adjust the [apache-noscript] jail’s filter. You will simply first back up the original file. (always back up the original files)

sudo cp /etc/fail2ban/filter.d/apache-noscript.conf /etc/fail2ban/filter.d/apache-noscript.conf.original

Now you can open and edit the filter knowing that you have a backup of the original file.

sudo nano /etc/fail2ban/filter.d/apache-noscript.conf

and you will see the following below. You will simply delete the two bold sections to take PHP out of the equation.

# Fail2Ban filter to block web requests for scripts (on non scripted websites)
#
# This matches many types of scripts that don't exist. This could generate a
# lot of false positive matches in cases like wikis and forums where users
# no affiliated with the website can insert links to missing files/scripts into
# pages and cause non-malicious browsers of the site to trigger against this
# filter.
#
# If you'd like to match specific URLs that don't exist see the
# apache-botsearch filter.
#

[INCLUDES]

# overwrite with apache-common.local if _apache_error_client is incorrect.
before = apache-common.conf

[Definition]

failregex = ^%(_apache_error_client)s ((AH001(28|30): )?File does not exist|(AH01264: )?script not found or unable to stat): /\S*(php([45]|[.-]cgi)?|\.asp|\.exe|\.pl)(, referer: \S+)?\s*$
            ^%(_apache_error_client)s script '/\S*(php([45]|[.-]cgi)?|\.asp|\.exe|\.pl)\S*' not found or unable to stat(, referer: \S+)?\s*$

ignoreregex = 


# DEV Notes:
#
# https://wiki.apache.org/httpd/ListOfErrors for apache error IDs
#
# Second regex, script '/\S*(\.php|\.asp|\.exe|\.pl)\S*' not found or unable to stat\s*$ is in httpd-2.2
#
# Author: Cyril Jaquier

That’s all folks

I hope this has been the thorough step by step guide you had been hoping for among the many out there.

I write these tutorials to help others who are beyond frustration at the very bad advice out there on forums and believe me there is a lot of bad advice out there. I also write these tutorials for myself so that I can always come back to them one day …. when my rusty old brain has forgotten something.

One thing I can tell you about Fail2Ban, it’s a very powerful security module for Ubuntu but it can be easily broken by copying and pasting haphazardly from forums all over the web, that’s why I will end this writing with drumming this into your head ….. only add one jail at a time and test it thoroughly.

I wrote this guide specifically for version 0.91 of Fail2Ban on Ubuntu 16.04 because it is new and there are some syntax changes from the earlier 0.8 versions that just break version 0.91.

So this guide serves to help those setting up Fail2Ban for the first time but it also serves as an invaluable resource for those who have upgraded their Fail2Ban from a 0.8 version and it is using their old config files and now it is broken. Some very simple fixes to your existing jail.local file from an older version will have you up and running in no time and there really is no need to remove and purge it and start fresh.

My custom [blacklist] repeat offender jail is an open source project on GitHub.

Advanced Reporting and Abuse Reporting

For those a bit more serious about security, you could explore some of the other actions which I stripped out of the original jail.conf file. These actions like XARF and BADIPS’s (action_xarf and action_badips) can be set to run on individual jails. So let’s say we actually do want to email the abuse email address on record when our [blacklist] filter permanently bans somebody. Then we simply customise the [blacklist] jail to use the xarf filter which of course you will need to add to your jail.local file.

sudo nano /etc/fail2ban/jail.local

add the following lines under your action_mwl section (add the bold section)

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
             %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s"]

# See the IMPORTANT note in action.d/xarf-login-attack for when to use this action
#
# ban & send a xarf e-mail to abuse contact of IP address and include relevant log lines
# to the destemail.
action_xarf = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath=%(logpath)s, port="%(port)s"]

and then modify the [blacklist] jail filter section to use this new action which reports the offence to the abuse email address which is pulled from the whois records of the network who owns the IP address.

[blacklist]
enabled = true
logpath  = /var/log/fail2ban.*
banaction = blacklist
action = %(action_xarf)s
bantime  = 31536000   ; 1 year
findtime = 31536000   ; 1 year
maxretry = 10

Then CTRL+X and save your jail.local file and then sudo service fail2ban restart

It’s very important to read the following notes about using XARF and only use this when you fully understand what you are doing. Remember what I said earlier, each filter and action file has comments inside them. This is where you learn what filter and actions do and how to use them and customize them.

# Fail2Ban action for sending xarf Login-Attack messages to IP owner
 #
 # IMPORTANT:
 #
 # Emailing a IP owner of abuse is a serious complaint. Make sure that it is
 # serious. Fail2ban developers and network owners recommend you only use this
 # action for:
 #   * The recidive where the IP has been banned multiple times
 #   * Where maxretry has been set quite high, beyond the normal user typing
 #     password incorrectly.
 #   * For filters that have a low likelihood of receiving human errors
 #
 # DEPENDENCIES:
 #
 # This requires the dig command from bind-utils
 #
 # This uses the https://abusix.com/contactdb.html to lookup abuse contacts.
 #
 # XARF is a specification for sending a formatted response
 # for non-messaging based abuse including:
 #
 # Login-Attack, Malware-Attack, Fraud (Phishing, etc.), Info DNSBL
 #
 # For details see:
 # https://github.com/abusix/xarf-specification
 # http://www.x-arf.org/schemata.html
 #
 # Author: Daniel Black
 # Based on complain written by Russell Odom <russ@gloomytrousers.co.uk>

Have FUN with Fail2Ban and Leave any comments below. Also watch out for more Fail2Ban and other Security tutorials coming soon.

Happy Nixing in the Nixing Bowl !!!!

31 thoughts on “Fail2Ban SSH Nginx Persistent Bans Ubuntu 16.04

  1. Pingback: Fail2Ban BlackList Repeat Offender Jail [Foolproof] | Ubuntu 101

  2. Leo says:

    can .gz log be processed?

    sebres commented on Jul 13
    We don’t support parsing of .gz at all (I know no reason why and whether should be expected to parse rotated log files)…
    Just correct your log path – change something like logpath=/var/log/auth.* to logpath=/var/log/auth.log

    If you mean that nothing was changed in your fail2ban configuration, it was possible always misleading. Then your log-rotate configuration changed now (It archived files now into .gz)

    from: https://github.com/fail2ban/fail2ban/issues/1248

  3. Tony says:

    I’ve been running this for a few days now and it’s awesome, thank you! I’m shocked at how many brute force attacks against SSH are happening, there’s quite a few repeat offenders in the blacklist now. Because of this I’m considering having another crack at NAXSI, I tried once before but found it to be cumbersome. Thanks again, this is great.

  4. Nicke says:

    Very nice article. Your settings works as a charm.

    I found a minor misspelling… /etc/lograte.d/fail2ban should be /etc/logrotate.d/fail2ban

  5. RobbieTheK says:

    I’m trying this on Fedora 25. I disabled firewalld, and enabled iptables and made sure to change banaction = iptables-multiport in /etc/fail2ban/jail.d/00-firewalld.conf. From iptables -S I can see this:
    -N f2b-blacklist

    And the sshd jail is working:
    -A f2b-sshd -s 60.10.131.130/32 -j REJECT –reject-with icmp-port-unreachable
    -A f2b-sshd -s 221.194.47.224/32 -j REJECT –reject-with icmp-port-unreachable
    -A f2b-sshd -s 59.45.175.36/32 -j REJECT –reject-with icmp-port-unreachable
    -A f2b-sshd -s 121.18.238.109/32 -j REJECT –reject-with icmp-port-unreachable

    fail2ban.log has these (relevant logs snipped):
    2017-05-01 16:16:03,105 fail2ban.filter [15173]: INFO [blacklist] Found 58.218.198.146
    2017-05-01 16:16:03,529 fail2ban.actions [15173]: NOTICE [sshd] Ban 212.156.72.102
    2017-05-01 16:16:03,533 fail2ban.filter [15173]: INFO [blacklist] Found 212.156.72.102
    2017-05-01 16:16:03,952 fail2ban.actions [15173]: NOTICE [sshd] 121.18.238.109 already banned

    2017-05-01 16:15:55,277 fail2ban.jail [15173]: INFO Initiated ‘systemd’ backend

    2017-05-01 16:15:55,378 fail2ban.jail [15173]: INFO Creating new jail ‘blacklist’
    2017-05-01 16:15:55,378 fail2ban.jail [15173]: INFO Jail ‘blacklist’ uses pyinotify {}
    2017-05-01 16:15:55,385 fail2ban.jail [15173]: INFO Initiated ‘pyinotify’ backend
    2017-05-01 16:15:55,389 fail2ban.filter [15173]: INFO Set maxRetry = 8
    2017-05-01 16:15:55,404 fail2ban.filter [15173]: INFO Set findtime = 604800
    2017-05-01 16:15:55,405 fail2ban.actions [15173]: INFO Set banTime = 2592000
    2017-05-01 16:15:55,409 fail2ban.server [15173]: INFO Jail blacklist is not a JournalFilter instance

    jail.local has this:
    [blacklist]
    enabled = true
    logpath = /var/log/fail2ban.*
    filter = blacklist
    banaction = blacklist
    bantime = 2592000 ; 30 days
    #bantime = 31536000
    findtime = 604800 ; 1 week
    maxretry = 8

    [DEFAULT]
    sender = fail2ban
    ignoreip = 127.0.0.1/8 150.108.68.0/24 150.108.64.0/24 150.108.4.0/24 10.10.3.0/24 10.10.1.0/24 172.21.0.0/12
    bantime = 10800 ;3 hours
    findtime = 86400 ;1 day
    action = %(action_mwl)s
    backend = auto
    mta = sendmail
    logging = debug
    banaction = iptables-multiport

    But ip.blacklist does not have any content:
    -rwxr-xr-x 1 root root 0 May 1 16:15 ../ip.blacklist

    What am I missing?

    • Ubuntu Man says:

      Hi Robbie, make sure that the ip.blacklist file is writable.

      sudo touch /etc/fail2ban/ip.blacklist
      sudo chmod 755 /etc/fail2ban/ip.blacklist

      Then restart Fail2ban and see that it starts writing to the ip.blacklist file.

        • Ubuntu Man says:

          Have you checked that root owns that file and the entire fail2ban folder and subfolders ???

          What does

          ls -la /etc/fail2ban

          reveal ???

          • RobbieTheK says:

            # ls -la /etc/fail2ban
            total 88
            drwxr-xr-x. 6 root root 4096 May 1 15:19 .
            drwxr-xr-x. 156 root root 12288 May 2 02:21 ..
            drwxr-xr-x. 2 root root 4096 May 1 15:24 action.d
            -rw-r–r– 1 root root 2328 Apr 14 17:44 fail2ban.conf
            drwxr-xr-x. 2 root root 6 Apr 14 17:44 fail2ban.d
            drwxr-xr-x. 3 root root 4096 May 1 15:23 filter.d
            -rwxr-xr-x 1 root root 0 May 1 16:51 ip.blacklist
            -rw-r–r– 1 root root 21284 Apr 14 17:44 jail.conf
            drwxr-xr-x. 2 root root 31 Apr 23 02:21 jail.d
            -rw-r–r–. 1 root root 2469 May 1 16:51 jail.local
            -rw-r–r– 1 root root 2375 Apr 14 17:44 paths-common.conf
            -rw-r–r– 1 root root 642 Apr 14 17:44 paths-debian.conf
            -rw-r–r– 1 root root 1070 Apr 14 17:44 paths-fedora.conf
            -rw-r–r– 1 root root 1174 Apr 14 17:44 paths-freebsd.conf
            -rw-r–r– 1 root root 975 Apr 14 17:44 paths-opensuse.conf
            -rw-r–r– 1 root root 290 Apr 14 17:44 paths-osx.conf

          • Ubuntu Man says:

            Hi Robbie, that’s very weird. Please can you check who has ownership of /etc/fail2ban/filter.d/blacklist.conf and /etc/fail2ban/action.d/blacklist.conf files.

            Also please try this on ip.blacklist file for me

            sudo chmod +x /etc/fail2ban/ip.blacklist
            sudo chmod 755 /etc/fail2ban/ip.blacklist
            sudo service fail2ban restart

          • RobbieTheK says:

            Yep I did the wget yesterday and just ran the chmod commands still:
            ls -lt
            total 68
            -rwxr-xr-x 1 root root 0 May 2 09:03 ip.blacklist

            But banning is working:
            2017-05-02 09:03:31,963 fail2ban.filter [9551]: INFO [blacklist] Found 218.87.109.156
            2017-05-02 09:03:32,384 fail2ban.actions [9551]: NOTICE [sshd] 58.218.198.146 already banned

          • Ubuntu Man says:

            Geez, this is so weird, I run this on a bunch of servers but all Ubuntu.
            I’ve never tested this on Fedora …. what version of Fedora are you running so I can test this in a VM for you.
            Also what version of Fail2ban are you running ?

          • RobbieTheK says:

            ls -l /etc/fail2ban/action.d/blacklist.conf
            -rw-r–r– 1 root root 2929 May 1 15:35 /etc/fail2ban/action.d/blacklist.conf
            ls -l /etc/fail2ban/filter.d/blacklist.conf
            -rw-r–r– 1 root root 2076 May 1 15:35 /etc/fail2ban/filter.d/blacklist.conf

            rpm -q fail2ban
            fail2ban-0.9.6-4.fc25.noarch

            Fedora 25

          • Ubuntu Man says:

            Should work, I am downloading Fedora 25 and will test this for you.
            Reminder I am in South Africa on a 5Mbps ADSL line so the iso download could take 2 hours ūüôā

          • Ubuntu Man says:

            Hi Robbie, sorry I was about to and the next morning my father passed away so my hands are so full right now with arrangements. So sorry but I can only look at this next week sometime.

          • Ubuntu Man says:

            Also try this to make sure there is no formatting errors in either of the blacklist.conf files.

            sudo wget https://raw.githubusercontent.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning/master/action.d/blacklist.conf -O /etc/fail2ban/action.d/blacklist.conf

            sudo wget https://raw.githubusercontent.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning/master/filter.d/blacklist.conf -O /etc/fail2ban/filter.d/blacklist.conf

            sudo service fail2ban restart

    • Kamil says:

      I have exactly the same issue like RobbieTheK, but on CentOS 7. It is not writing anything to the /etc/fail2ban/ip.blacklist, however bans are working. I tried with disabled SELinux, but it is not the case. Any ideas?

      • Ubuntu Man says:

        Excuse my tardy reply, been a rough year. Have you tried maybe moving the ip.blacklist file to a different location altogether? Then just modifying line 49 and 52 of /action.d/blacklist.conf

  6. Pritam says:

    Hi, I keep getting this error:

    /etc/cron.daily/logrotate:
    error: fail2ban:11 lines must begin with a keyword or a filename (possibly in double quotes)

    • Ubuntu Man says:

      Make sure your contents of /etc/logrotate.d/fail2ban looks as follows.

      /var/log/fail2ban.log {
      missingok
      notifempty
      monthly
      rotate 13
      create 640 root adm
      postrotate
      /usr/bin/fail2ban-client set logtarget /var/log/fail2ban.log 2> /dev/null || true
      endscript
      }

  7. gucluaydogdu says:

    This was, by far, the best tutorial for a newb like me. Thank you very much! With THIS^ and logging in with an ssh file, I’m confident that those Chinese ip’s won’t be able to do shit ūüôā They can attack all they like now…

  8. Robert says:

    Hi Thanks so much for your sharing.

    I tried to remove php from /etc/fail2ban/filter.d/apache-noscript.conf but I got some problem even with online regex check tool. You mentioned in your post to removed the bold section but I don’t see any BOLD section. Is the below version correct for WordPress? Thank you so much your tutorial helps me a lot.

    failregex = ^%(_apache_error_client)s ((AH001(28|30): )?File does not exist|(AH01264: )?script not found or unable to stat): /\S*(\.asp|\.exe|\.pl)(, referer: \S+)?\s*$
    ^%(_apache_error_client)s script /\S*(\.asp|\.exe|\.pl)\S*’ not found or unable to stat(, referer: \S+)?\s*$

    • Ubuntu Man says:

      Sorry for the late reply Robert, the bolded sections referred to are “111.111.111.111 222.222.222.222” ie. making sure your own IP addresses are whitelisted. If you re-read that section it says “the bolded sections below must be changed” … not removed ūüôā

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.