Plesk 12.0.18 Update #68 and Fail2ban 0.9.3 problem

[Linulex]

Hi Jan,

AFAIK fail2ban was working fine...
It was the recent update to Plesk that caused the problem?
Unless I've got things the wrong way around in my head of course...

yes and no

yes: it stopped working at the same time update 68 was released, but that is coincidence
no: plesk doesn't make fail2ban, the fail2ban you have is distributed by epel repositry, so plesk is not responsible for changes to it, and cant be blamed
yes: fail2ban changed something and plesk doesn't handle those changes yet.
no: the version officially distributed by plesk is 0.8.3, so they guarantee plesk works with that version, not another one.

if you want to use the version that is officially by plesk, you can download it here

http://autoinstall.plesk.com/PSA_12.0.18/dist-rpm-CentOS-6-x86_64/opt/fail2ban/
(thanks to UFHH01 for the link, spared me the time to look it up)

But thats 0.8.3, not 0.9.2 like mine, and don't forget to exclude it in the epel repo then.

As for running CentOS 6.6 rather than CentOS 6.7 as you said yourself,
"...is a bugfix and new functionality release, not a security release so there is no harm in downgrading." ;o)

That's something completly different. centos 6.7 IS a security update. centos 6.7 was released on 5 sept 2015
https://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.7

rhel, the upstream 6.7 was released on 22 sept 2015

Take a look at all the errate on or after that date

https://rhn.redhat.com/errata/rhel-server-6-errata.html

Everything released on or after 22 sept with a little lock in front of it is a security update.

I guess I'll have to put some time aside to do the fail2ban downgrade.
What will the situation be if the next fail2ban update happens to be a security one?

then you have a few options:

a) hope plesk fixed it by then for that version
b) use the official supported version
c) temporary remove it and stop using it
d) remove it from plesk and install it trough yum/from source/whatever, configure it trough the commandline, or trough the webmin module or progamme some php scripts yourself, whatever. There is no law you have to do it trough plesk.

We still have several plesk 8.6 servers and are using fail2ban on those in a d) setup. Its installed with yum at the commandline and configured trough the mc editor.

downgrading is very simple
- delete it from plesk
- delete /etc/fail2ban
- install my rpm
- go to plesk, start it, start the jails you want

add exclude=fail2ban* to the epel repo (config file is /etc/yum.repos.d/epel.repo) else you will get the 0.9.3 update again.

Hope this helps a bit
regards
Jan

 

[gbotica]

Hi Linulex,


please use for example:

For Plesk 12.5.30 and CentOS 6.7:
http://autoinstall.plesk.com/PSA_12...an/fail2ban-0.9.2-centos6.15093018.noarch.rpm​

For Plesk 12.0.18 and CentOS 6.7 ( please use the official Fail2Ban - version 0.9.2 from the official Fail2Ban - github, if you don't want to use the Plesk - version 0.8.13 from http://autoinstall.plesk.com/PSA_12.../fail2ban/fail2ban-0.8.13-14052018.noarch.rpm ):

mkdir -p /root/addons/plesk/fail2ban
cd /root/addons/plesk/fail2ban
wget https://github.com/fail2ban/fail2ban/archive/0.9.2.tar.gz
tar -zxvf 0.9.2.tar.gz
cd fail2ban-0.9.2
python setup.py install

To be able to use the Plesk pre-configured jails and configuration files, you may use the Fail2Ban - files from Plesk 12.5.30 ( you will need to install "rpm2cpio" to do that ! ):

mkdir -p /root/addons/plesk/fail2ban/plesk_12.5.30
cd /root/addons/plesk/fail2ban/plesk_12.5.30
wget http://autoinstall.plesk.com/PSA_12...or-12.5.30-cos6.build1205150901.17.noarch.rpm
rpm2cpio plesk-fail2ban-configurator-12.5.30-cos6.build1205150901.17.noarch.rpm | cpio -i --make-directories

You can now copy the files from "/root/addons/plesk/fail2ban/plesk_12.5.30/etc/fail2ban" to "/etc/fail2ban":

cp -avr /root/addons/plesk/fail2ban/plesk_12.5.30/etc/fail2ban /etc/fail2ban

​

If you experience issues as described:

Please try to use the recommendation from https://github.com/fail2ban/fail2ban/issues/1122 / https://bugzilla.redhat.com/show_bug.cgi?id=1272681

Original /etc/fail2ban/action.d/iptables-common.conf


Change to:


If you experience any issues, please report back what you did and please add again possible errors from your logs.

I thought the lockingopt = -w was only introduced in Fail2ban 0.9.3?

 

[UFHH01]

Hi gbotica,

the string "-w" is a WAIT FOR THE LOCK - option ( otherwise contemporaneous commands will only execute ONE command, the others are dropped and not executed ), passed over to iptables - commands from Fail2Ban. Since 08.08.2013, iptables 1.4.20 ( release date ), iptables is able to interpret this "-w" string, in order to WAIT FOR THE LOCK, so that multiple iütables commands are queued, instead of being dropped to one possible command. As you can see in the original commit at https://github.com/fail2ban/fail2ban/commit/38c320798dc1e8124cd0950a8f2eb08ab7427c7f , there is only an additional entry, which could have been passed over to iptables by each and everyone at any time - you could have modified it on your very own after installing iptables 1.4.20 on your system since 08.08.2013 :

+
+# Option:  lockingopt
+# Notes.:  Option was introduced to iptables to prevent multiple instances from
+#          running concurrently and causing irratic behavior.  -w was introduced
+#          in iptables 1.4.20, so might be absent on older systems
+#          See https://github.com/fail2ban/fail2ban/issues/1122
+# Values:  STRING
+lockingopt = -w
+
+# Option:  iptables
+# Notes.:  Actual command to be executed, including common to all calls options
+# Values:  STRING
+iptables = iptables <lockingopt>

"+iptables = iptables <lockingopt>" => iptables COMMAND_STRING_AS_DEFINED_AT_lockingopt_=_ => iptables -w

=> instead of only using the command "iptables", you now use the command "iptables -w"​

 

[gbotica]

Hi gbotica,

the string "-w" is a WAIT FOR THE LOCK - option ( otherwise contemporaneous commands will only execute ONE command, the others are dropped and not executed ), passed over to iptables - commands from Fail2Ban. Since 08.08.2013, iptables 1.4.20 ( release date ), iptables is able to interpret this "-w" string, in order to WAIT FOR THE LOCK, so that multiple iütables commands are queued, instead of being dropped to one possible command. As you can see in the original commit at https://github.com/fail2ban/fail2ban/commit/38c320798dc1e8124cd0950a8f2eb08ab7427c7f , there is only an additional entry, which could have been passed over to iptables by each and everyone at any time - you could have modified it on your very own after installing iptables 1.4.20 on your system since 08.08.2013 :

+
+# Option:  lockingopt
+# Notes.:  Option was introduced to iptables to prevent multiple instances from
+#          running concurrently and causing irratic behavior.  -w was introduced
+#          in iptables 1.4.20, so might be absent on older systems
+#          See https://github.com/fail2ban/fail2ban/issues/1122
+# Values:  STRING
+lockingopt = -w
+
+# Option:  iptables
+# Notes.:  Actual command to be executed, including common to all calls options
+# Values:  STRING
+iptables = iptables <lockingopt>

"+iptables = iptables <lockingopt>" => iptables COMMAND_STRING_AS_DEFINED_AT_lockingopt_=_ => iptables -w

=> instead of only using the command "iptables", you now use the command "iptables -w"​

Hi, Yes, I understand, thanks for your explanation.

I should have been clearer, what I was referring to was @Linulex saying:

If you experience issues as described:

Please try to use the recommendation from https://github.com/fail2ban/fail2ban/issues/1122 / https://bugzilla.redhat.com/show_bug.cgi?id=1272681
​

But their instructions are regarding installation of Fail2Ban 0.9.2 which doesn't use the '-w' iptables option, that was introduced with 0.9.3. Or, perhaps I'm completely missing the point..?

 

[UFHH01]

Hi gbotica,

if you already installed an iptables 1.4.20 ( and later versions ) on your server(s) and would like to take advantage of the "-w" - option for iptables, then you should feel free to implement the additional code from Fail2Ban v. 0.9.3 ( ../action.d/iptables-common.conf ) inside the "[Init]" - section:

# Option:  lockingopt
# Notes.:  Option was introduced to iptables to prevent multiple instances from
#          running concurrently and causing irratic behavior.  -w was introduced
#          in iptables 1.4.20, so might be absent on older systems
#          See https://github.com/fail2ban/fail2ban/issues/1122
# Values:  STRING
lockingopt = -w

# Option:  iptables
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables = iptables <lockingopt>

... , on every Fail2Ban - version, which have an "[Init]" - section defined and where other action.d - configuration files include iptables-common.conf with the command "before = iptables-common.conf". ( sorry... I have no clue, when this action.d - command was implemented into Fail2Ban, must be years ago. ). This procedure will then use "iptables -w", instead of "iptables".

 

[RuslanT]

Hello, the issue was reported to development team with ID: PPPM-3464

 

[Azurel]

I have this problem too: http://talk.plesk.com/threads/since-today-fail2ban-not-working.335791/ since #68 with centOS 6.7.

How is the status of this reported ticket?