• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Poor fail2ban implementation

Hope the above helps...

Yes it did +1 many thanks.
I suppose i just have to create a list for blocked_ips and manually add them to iptables until a new release of fail2ban comes out.

Is there a special iptables command for ssh, apache, mysql ?
Or would just a block in general be enough for hackers?
 
Hi Noturns,

please have a closer look on the jail "recidive". This can be setup to ban recurring IPs for a much longer time, because it scans the fail2ban.log and bans the recurring IP for as long as defined in the jail.
 
please have a closer look on the jail "recidive"
Good point !

recidive jail: hosts repeatedly banned by fail2ban

IP address ban period is set by default = "604800" seconds
I have now set it to "31556926" seconds = 1 year :cool: 'busted'


edit: i have reset to 604800 seconds after ip adresses where not blocked
 
Last edited:
@Noturns,

Fail2Ban is not intended to set the ban time longer than 604800 seconds (i.e. 7 days), this is the maximum value.

Setting a longer time period will still result in (on the one hand) a temporary ban, not a permanent block and (on the other hand) a ban time of 604800 seconds.

Fail2Ban was designed this way.

Moreover, the tip of IFHH01 is twofold:

a) it gives a good indication of a starting point where to find the IPs that actually deserve a (manual) IP block (i.e. permanent), AND

b) it hints an additional option (as opposed to set higher ban periods) to block more IPs for a longer duration (i.e. 7 days), with this option being an appropriate change of the rulesets for the specific jail. For instance: IPs causing overloads on (Apache) web servers are blocked for a relatively short duration, by a special purpose jails. However, when adding the (apache) web server logs AND an appropriate regexp, the recidive jail will also be able to block IPs that try to hammer (web) servers during several months.

In general, one should be careful with any jail configuration. It is fairly easy to ban the wrong IPs, making your Plesk installation less operational and hence less valuable.

An example is software that is not really well-defined (as often is the case) and does many requests in one hour to the Plesk server.

Imagine that you or one of your clients hosts a web service on the Plesk server and a Fail2Ban is configured to block all requests coming from specific IPs.

You really do not want that scenario to happen, certainly not when Fail2Ban is configured to block certain IPs during 7 days.

In short, be careful with Fail2Ban configurations.

Fail2Ban is dummy proof, but it also entails the danger of automation: the blind trust in the idea that it is "ok", in the sense of "once configured, always good".

By the way, it is adviceable to NOT enter firewall rulesets manually to iptables, INSTEAD one should better use the Plesk GUI, i.e. the Plesk Firewall interface.

The Plesk firewall interface is less error prone (and often prevents small errors, locking you out of the system entirely).

Kind regards....
 
Hi trialotto,

Fail2Ban is not intended to set the ban time longer than 604800 seconds (i.e. 7 days), this is the maximum value.
could you explain, why you declare a maximum value of "604800" seconds for a Fail2Ban bantime? You can even use a bantime of "-1" ( => 0, which defines a bantime without time limits => permanent ban ), so it's not clear, why you declare a time limitation.

Source: http://www.fail2ban.org/wiki/index.php/ChangeLog

...
ver. 0.6.1 (2006/03/16) - stable
----------
- Added permanent banning. Set banTime to a negative value to enable this
feature (-1 is perfect). Thanks to Mannone
...


Imagine that you or one of your clients hosts a web service on the Plesk server and a Fail2Ban is configured to block all requests coming from specific IPs.
Fail2Ban gives the option to whitelist ( ignore ) IPs, which you definetly should use for localhost, your server IP(s) and additional service IP(s). You find this setting over the Plesk Control Panel

Source: Protection Against Brute Force Attacks (Fail2Ban) ( Plesk 12 online documentation )


If an IP address should not be blocked:

  1. Go to Tools & Settings > IP Address Banning (Fail2Ban) > Trusted IP Addresses > Add Trusted IP.
  2. In the IP address field, provide an IP address, an IP range, or a DNS host name, and click OK.

and as always at the "/etc/fail2ban/jail.conf":

Example and description at jail.conf:
...
[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1/8 XXX.XXX.XXX.XX1 XXX.XXX.XXX.XXX2 XXX.XXX.XXX.XXX3
...


I can't see any disadvantage of an iptables entry over Fail2Ban to a Plesk Firewall ruleset - could you explain, why you seem to prefer a Plesk Firewall rule to a Fail2Ban ban ( which might be permanent and temporary ) ?
 
@UFHH01,

In response to your post, the following.

could you explain, why you declare a maximum value of "604800" seconds for a Fail2Ban bantime? You can even use a bantime of "-1" ( => 0, which defines a bantime without time limits => permanent ban ), so it's not clear, why you declare a time limitation.

In short, the "7 day maximum" (i.e. 604800) is the maximum period that can be set (in seconds).

Furthermore, the "-1 setting" does not work or does not work properly all the time and/or in all versions.

The same applies to ">604800 seconds" settings.

You can verify this by doing an intensive, long-run test (> 2 months).

Fail2Ban gives the option to whitelist ( ignore ) IPs, which you definetly should use for localhost, your server IP(s) and additional service IP(s). You find this setting over the Plesk Control Panel ....
Source: Protection Against Brute Force Attacks (Fail2Ban) ( Plesk 12 online documentation )
....
and as always at the "/etc/fail2ban/jail.conf":

Example and description at jail.conf: ...

Not necessary to fiddle with the jail.conf file.

It certainly is not adviceable, given the fact that Fail2Ban is allowing for customization in the jail.local file.

Fail2Ban allows and almost prefers all customizations via .local files. Read the "README" file.

Plesk Panel uses the jail.local file to add whitelisted IPs.

In short, after adding a whitelisted IP via the Plesk Panel, no change in jail.conf is required or necessary.

I can't see any disadvantage of an iptables entry over Fail2Ban to a Plesk Firewall ruleset - could you explain, why you seem to prefer a Plesk Firewall rule to a Fail2Ban ban ( which might be permanent and temporary ) ?

Fail2Ban is based on filters, which are very prone to errors due to faulty regexps.

Iptables is based on complex rules, which are very prone to errors, as such very dangerous for the inexperienced sysadmin.

Plesk Firewall is just making work (relatively) easy and (automatically) creates the ruleset that one also can create with manual iptables edits.

Plesk Firewall has some nice advantages over manual editing of firewall rulesets, being

- the creation of rulesets, before activating them (in a different way that iptables allows),
- the possibility to revert some of the (still not activated) rulesets, making it less likely that errors and/or mistakes result in a shutdown of access to the server
- the impossibility to flush rules and/or rulesets with one accidental command, making it more safe,
- easy editing of existing firewall rules and/or rulesets,

and so on.

Fail2Ban is often creating (temporary) rules, that CAN be duplicates of other rules, making the firewall less effective and/or efficient.

Iptables is not that "easy" and/or "forgiving", it is easy for the inexperienced sysadmin to create duplicate rules, when manually editing the firewall.

Plesk Firewall is just making work (relatively) easy and it is very unlikely that duplicate rulesets, as such ineffective and/or inefficient rulesets, are created.

Plesk Firewall in combination with Fail2Ban is associated with

- invisibility of Fail2Ban additions to the (iptables) firewall,
- short duration of Fail2Ban additions to the (iptabels) firewall and hence reduced exposure to ineffectiveness and/or inefficiency.

In short, one can do whatever one desires, but it is adviceable to

- keep temporary IP bans automated with Fail2Ban,
- manage permanent IP blocks with iptables and/or Plesk Firewall, with Plesk Firewall being more safe, easy and so on.

Really, nobody wants to use iptables (certainly not if a GUI in Plesk exists), when a single iptables command can flush all firewall rules/rulesets and/or block full access.

Kind regards.....
 
In short, the "7 day maximum" (i.e. 604800) is the maximum period that can be set (in seconds).
Furthermore, the "-1 setting" does not work or does not work properly all the time and/or in all versions.
The same applies to ">604800 seconds" settings.
You can verify this by doing an intensive, long-run test (> 2 months).
I never experienced any issues regarding your statement and I use Fail2Ban now for over 5 years and tested quite meticulously.

I was just interested, why you seem to think, that the bantime - settings are restricted... nothing more... ^^



It certainly is not adviceable, given the fact that Fail2Ban is allowing for customization in the jail.local file.
Well sorry... I didn't mean to edit the jail.conf - you certainly should always use the jail..local - - sorry that I didn't point that out in my post clearly.
 
@UFHH01

No problem at all, I was just giving some general information and/or some (general) answers to (implicit) questions (if any).

Note that the Fail2Ban project is (on the one hand) tackling multiple issues and (on the other hand) testing the implementation of some (much) desired functionalities, amongst which the permanent IP block (i.e. by means of a database) is the most important.

From the release notes, one can deduce some implicit problems with the current possibilities with respect to permanent IP blocking: the database is intended to allow "... active bans to be reinstated on restart".

In short, permanent IP bans with Fail2Ban are not equal to permanent IP blocks.

Naturally, I hope that the new stable releases of Fail2Ban are able to "allow" of factual permanent IP blocks, persistent in ALL scenario´s.

We will see....

Kind regards......
 
Just an update: after a bruteforce attack yesterday i have set the recidive settings back to the original 604800 seconds and the jail time worked again.
 
Just an update: after a bruteforce attack yesterday i have set the recidive settings back to the original 604800 seconds and the jail time worked again.

@Noturns,

First of all, I am happy to see that your Fail2Ban is set-up properly and working as intended by you.

However, it seems to be the case that your Fail2Ban implementation has not always been working as it is supposed to (for instance, Fail2Ban should be reverting to default values of the settings, if any of the values are not set in an allowed range).

I am working on a "small Fail2Ban project", intended to add some (general) functionality and/or improvements.

Can you be so kind to start a (personal) conversation and provide me with some data?

I would be much obliged.

Kind regards.....
 
Back
Top