plesk-fail2ban-configurator-12.0.18-cos7.build1200140807.16.noarch
fail2ban-0.8.13-centos7.14071718.noarch
CentOS Linux release 7.1.1503 (Core)
Derived from Red Hat Enterprise Linux 7.1 (Source)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="
https://www.centos.org/"
BUG_REPORT_URL="
https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
CentOS Linux release 7.1.1503 (Core)
CentOS Linux release 7.1.1503 (Core)
cpe:/o:centos:centos:7
The reason why your installation works is that you miss the EPEL repository, but I need it for different reasons, most because of image optimization tools. Once adding the EPEL repository fail2ban is fetched from the EPEL repository and this is version 0.9.x. If doing an uninstall and installing via Plesk instead of manually installing the RPMs (however that's that e.g. Virtuozzo does if you work with containers, they don't run the autoinstaller, they install the RPMs or more detailed link the symlinks to the installed RPMs in the vz repository), always the EPEL version is fetched. I have no idea on how to force the version been installed by adjusting yum, when the installation is done via autoinstaller. I'm able to prevent yum to update fail2ban with the EPEL repository, but as I don't see any parallels plesk repository, I can't add and also can't install via yum (which maybe a reason for selinux to fail after updating CentOS to release 7.1.1503 just recently, before it was
7.0.1406, for sure always patched with latest updates, but that didn't break fail2ban, just the last bigger update to the new release 7.1.1503 included some extra updates like selinux and breaked fail2ban, which after manual install recently worked.
But I'm sure it's about selinux after looking at different (more destroying) helps like in this forum recommending an iptables -F which result in kicking me out of the system completely, I came across, that the issue is strange and all strange issues are in conjunction with selinux (e.g. there are selinux bugs which prevent OpenVPN from being used by default, need special adjustment (Fix selinux context of files: restorecon -Rv /etc/openvpn). Also looking the journal, it exactly states:
Apr 06 13:16:30 vm1.heutger.net fail2ban-client[129006]: ERROR Directory /var/run/fail2ban exists but not accessible for writing
Apr 06 13:16:30 vm1.heutger.net systemd[1]: fail2ban.service: control process exited, code=exited status=255
Apr 06 13:16:30 vm1.heutger.net systemd[1]: Failed to start Fail2ban Service.
Apr 06 13:16:30 vm1.heutger.net systemd[1]: Unit fail2ban.service entered failed state.
but the directly is accessible for writing, I also changed the rights to 777, no changes. However, looking at audit.log with audit2allow, I directly see:
type=AVC msg=audit(1428318989.451:8071): avc: denied { write } for pid=128986 comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=14979 scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u
bject_r:var_run_t:s0 tclass=dir
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
However, creating a SElinux rule therefore, recently result in an error, that the type fail2ban_client_t does not exist. Using setenforce 0 afterwards everything worked well, but that couldn't be the solution.
However, now it seemed to work out (not sure why) as I first did the steps you recommended and afterwards did the steps I recently did:
grep fail2ban-client /var/log/audit/audit.log | audit2allow -M mypol2
semodule -i mypol2.pp
systemctl start fail2ban failed again
grep fail2ban-client /var/log/audit/audit.log | audit2allow -M mypol3
semodule -i mypol3.pp
systemctl start fail2ban started successfully
However, it looks-a-like Plesk is not really SElinux-compatible as consulting the audit.log there are many more problems in conjunction with Plesk which seems to be the reason why some additional strange topics occur, e.g. xferlog is always empty:
type=AVC msg=audit(1425783060.027:122912): avc: denied { read write } for pid=26750 comm="httpd" path="/var/asl/data/updates-data" dev="sda3" ino=2578583 scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u
bject_r:var_t:s0 tclass=file
type=AVC msg=audit(1425786803.191:123052): avc: denied { write } for pid=32605 comm="py-limit-out" path="/usr/local/psa/var/psasem.sem" dev="sda3" ino=2149093341 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u
bject_r:var_t:s0 tclass=file
type=AVC msg=audit(1425786803.256:123053): avc: denied { write } for pid=32606 comm="check-quota" path="/usr/local/psa/var/psasem.sem" dev="sda3" ino=2149093341 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u
bject_r:var_t:s0 tclass=file
type=AVC msg=audit(1425786803.270:123054): avc: denied { write } for pid=32609 comm="sendmail.postfi" path="/usr/local/psa/var/psasem.sem" dev="sda3" ino=2149093341 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u
bject_r:var_t:s0 tclass=file
type=AVC msg=audit(1425823993.114:124420): avc: denied { open } for pid=81221 comm="in.proftpd" path="/var/log/plesk/xferlog" dev="sda3" ino=3221527233 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u
bject_r:cron_log_t:s0 tclass=file
type=AVC msg=audit(1428140424.860:656): avc: denied { read } for pid=4018 comm="smtp" name="resolv.conf" dev="sda3" ino=1073846856 scontext=system_u:system_r
ostfix_smtp_t:s0 tcontext=system_u
bject_r:httpd_sys_content_t:s0 tclass=file (which also started with the update)
type=AVC msg=audit(1428133956.001:288): avc: denied { open } for pid=2391 comm="httpd" path="/var/log/modsec_audit.log" dev="sda3" ino=2149026881 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u
bject_r:var_log_t:s0 tclass=file
Using an admin panel which finally does not work with the base system (which now has SElinux enabled by default) is really sad. Always adjusting SElinux can't be the solution.
For anyone following this thread, fail2ban can be fixed by:
module mypol 1.0;
require {
type var_run_t;
type fail2ban_t;
class sock_file { create unlink getattr };
}
#============= fail2ban_t ==============
#!!!! This avc is allowed in the current policy
allow fail2ban_t var_run_t:sock_file { create unlink getattr };
module mypol2 1.0;
require {
type var_run_t;
type fail2ban_client_t;
class dir write;
}
#============= fail2ban_client_t ==============
allow fail2ban_client_t var_run_t:dir write;
module mypol3 1.0;
require {
type var_run_t;
type fail2ban_client_t;
class sock_file write;
class dir write;
}
#============= fail2ban_client_t ==============
#!!!! This avc is allowed in the current policy
allow fail2ban_client_t var_run_t:dir write;
allow fail2ban_client_t var_run_t:sock_file write;
I will now try to solve all the other policy issues.
Facebook
Twitter
