I have a fail2ban configured like below:

  • block the ip after 3 failed attempts
  • release the IP after 300 sec timeout

This works perfectly and I want to keep it this way such that a valid user gets a chance to retry the login after the timeout. Now, I want to implement a rule where if same IP is been detected as attack and blocked, unblocked 5 times, permanently block the IP and never unblock again. Can this be achieved with fail2ban alone or I need to write my own script to do that?

I am doing this in centos.

  • 3
    It's a rather silly idea - the more rules you add to iptables the slower it gets.
    – symcbean
    Commented Aug 7, 2012 at 13:19
  • 24
    Appreciate your comment but what I need is an answer and not a suggestion. Thanks anyway.
    – BTR Naidu
    Commented Aug 7, 2012 at 13:29
  • 10
    Sometimes the right answer to "how do I do X" is "don't do X".
    – ceejayoz
    Commented Feb 20, 2013 at 16:08

6 Answers 6


Before 0.11, there was no default feature or a setting within fail2ban to achieve this. But starting with the upcoming 0.11 release, ban time is automatically calculated and increases exponentially with each new offense which, on the long term, will mean a more or less permanent block.

Until then, your best approach is probably setting up fail2ban to monitor its own log file. It is a two step process...

Step 1

We could need to create a filter to check for BAN's in the log file (fail2ban's log file)

Step 2

We need to define the jail, similar to the following...

enabled = true
filter = fail2ban
action = iptables-allports[name=fail2ban]
logpath = /path/to/fail2ban.log
# findtime: 1 day
findtime = 86400
# bantime: 1 year
bantime = 31536000

Technically, it is not a permanent block, but only blocks for a year (that we can increase too).

Anyway, for your question (Can this be achieved with fail2ban alone or I need to write my own script to do that?)... writing own script might work well. Setting up the script to extract the frequently banned IPs and then putting them into /etc/hosts.deny is what I'd recommend.

  • 1
    Adding to this excellent answer... Depending on how logging and MaxAuthTries are configured for sshd_config, this could potentially only block 3 failed logins for a sshd "session" - not 3 failed logins provided. For example, by default an attacker could try ['pass1', 'pass2', 'pass3'] in a single session before sshd disconnects. Depending on how sshd is set to log, this could appear as 1, 2 or 3 attempts to fail2ban. Commented Apr 28, 2016 at 17:24
  • 7
    There's the fail2ban recidive filter for that, now. Commented Aug 12, 2016 at 23:31
  • What do you mean by upcoming 0.11 release? The most recent seems to be 10.3.1: github.com/fail2ban/fail2ban/releases
    – user5950
    Commented Jun 1, 2018 at 22:11
  • I hope you meant You can track the progress of "0.11" at github.com/fail2ban/fail2ban/tree/0.11 . Basically, it is not released, yet! Commented Jun 3, 2018 at 13:29

I believe if you put bantime = -1 in that config section, it is a permanent block.

  • 2
    Indeed, setting bantime to any negative value is a permanent ban (as of Fail2Ban ver. 0.6.1 (2006/03/16))
    – voretaq7
    Commented Mar 21, 2013 at 16:41
  • 4
    adding -1 to settings made fail2ban unresponsive
    – Erdem Ece
    Commented Nov 25, 2015 at 11:55

Phil Hagen wrote an excellent article on this subject. "Permanently Ban Repeat Offenders With fail2ban".

His suggestion is the same as Pothi but provides a step by step guide.

This included:

  • separate ban list by jail (ip.blocklist.ssh, ip.blocklist.xxx)
  • ban lists autoloaded if service restart (main advantage of this method imho)
  • email notification if repeater engaged.

fail2ban has already a jail to ban recidive. If you watch /etc/fail2ban/jail.conf, you will found :

# Jail for more extended banning of persistent abusers
# !!! WARNING !!!
#   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

enabled  = false
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime  = 604800  ; 1 week
findtime = 86400   ; 1 day
maxretry = 5

How to add in jail.local ?

enabled  = true
bantime  = 31536000  ; 1 year
findtime = 18144000  ; 1 month
maxretry = 2

For check you loglevel you can do : fail2ban-client get loglevel.

  • set loglevel MYLEVEL : sets logging level to MYLEVEL. Levels: CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG
  • More command on the wiki.

With old version of fail2ban, you can get this bug.


To expand on Chin's answer this is pretty simple. Just edit the 2 settings in /etc/fail2ban/jail.local to match your preferences.

 # ban time in seconds. Use -1 for forever. Example is 1 week.
 bantime  = 604800
 # number of failures before banning
 maxretry = 5

Go to vim, open /etc/fail2ban/jail.conf

and just modify after fail2ban service restart:

# "bantime" is the number of seconds that a host is banned.
bantime  = ***1296000***

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = ***60000***

# "maxretry" is the number of failures before a host get banned.
maxretry = ***3***

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .