Hi!
I have a server running CentOS 7.7 (1908) with all current patches installed. I think this server should be a quite standard installation with no specialities
On this server I have fail2ban with an apache and openvpn configuration. I'm using firewalld to manage the firewall rules.
Fail2an is configured to use firewalld:
[root@server ~]# ll /etc/fail2ban/jail.d/ insgesamt 12 -rw-r--r--. 1 root root 356 21. Jan 05:12 00-firewalld.conf -rw-r--r--. 1 root root 610 15. Nov 19:55 apache.local -rw-r--r--. 1 root root 115 15. Nov 19:10 openvpn.local
[root@server ~]# cat /etc/fail2ban/jail.d/00-firewalld.conf # This file is part of the fail2ban-firewalld package to configure the use of # the firewalld actions as the default actions. You can remove this package # (along with the empty fail2ban meta-package) if you do not use firewalld [DEFAULT] banaction = firewallcmd-ipset[actiontype=<multiport>] banaction_allports = firewallcmd-ipset[actiontype=<allports>]
A few days ago I noticed that on restart firewalld complains about a missing ipset:
[root@server ~]# systemctl restart firewalld [root@server ~]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Do 2020-04-09 09:25:28 CEST; 5s ago Docs: man:firewalld(1) Main PID: 8324 (firewalld) CGroup: /system.slice/firewalld.service └─8324 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid
Apr 09 09:25:28 server.my.domain systemd[1]: Starting firewalld - dynamic firewall daemon... Apr 09 09:25:28 server.my.domain systemd[1]: Started firewalld - dynamic firewall daemon. Apr 09 09:25:30 server.my.domain firewalld[8324]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: Set f2b-apache doesn't exist.
Error occurred at line: 2... Apr 09 09:25:30 server.my.domain firewalld[8324]: ERROR: COMMAND_FAILED: Direct: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: Set f2b-apache doesn't exist.
Error occurred at line: 2... Hint: Some lines were ellipsized, use -l to show in full.
Indeed there is no ipset named "f2b-apache", there is no set configured at all:
[root@server ~]# ipset list
There is no error when restarting fail2ban:
[root@server ~]# systemctl restart fail2ban [root@server ~]# systemctl status fail2ban ● fail2ban.service - Fail2Ban Service Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled) Active: active (running) since Do 2020-04-09 09:26:13 CEST; 4s ago Docs: man:fail2ban(1) Process: 8539 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=0/SUCCESS) Process: 8543 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS) Main PID: 8545 (f2b/server) CGroup: /system.slice/fail2ban.service └─8545 /usr/bin/python -s /usr/bin/fail2ban-server -xf start
Apr 09 09:26:13 server.my.domain systemd[1]: Stopped Fail2Ban Service. Apr 09 09:26:13 server.my.domain systemd[1]: Starting Fail2Ban Service... Apr 09 09:26:13 server.my.domain systemd[1]: Started Fail2Ban Service. Apr 09 09:26:13 server.my.domain fail2ban-server[8545]: Server ready
Fail2ban seems to be running fine:
[root@server ~]# fail2ban-client status Status |- Number of jail: 6 `- Jail list: apache, apache-badbots, apache-nohome, apache-noscript, apache-overflows, openvpn
No errors loged in fail2ban.log on restart: [...] 2020-04-09 09:26:13,773 fail2ban.server [8545]: INFO Starting Fail2ban v0.10.5 2020-04-09 09:26:13,799 fail2ban.database [8545]: INFO Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3' 2020-04-09 09:26:13,801 fail2ban.jail [8545]: INFO Creating new jail 'apache-badbots' 2020-04-09 09:26:13,805 fail2ban.jail [8545]: INFO Jail 'apache-badbots' uses poller {} 2020-04-09 09:26:13,805 fail2ban.jail [8545]: INFO Initiated 'polling' backend 2020-04-09 09:26:13,838 fail2ban.filter [8545]: INFO maxRetry: 1 2020-04-09 09:26:13,838 fail2ban.filter [8545]: INFO encoding: UTF-8 2020-04-09 09:26:13,839 fail2ban.actions [8545]: INFO banTime: 172800 2020-04-09 09:26:13,839 fail2ban.filter [8545]: INFO findtime: 3600 2020-04-09 09:26:13,840 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/ssl_error_log' (pos = 588859, hash = 755a00cfc09ef9b2f76d78cff61ea766) 2020-04-09 09:26:13,840 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/error_log' (pos = 27101, hash = 53ba5e7041d49628af3b86be05de6fa7) 2020-04-09 09:26:13,841 fail2ban.jail [8545]: INFO Creating new jail 'apache-noscript' 2020-04-09 09:26:13,843 fail2ban.jail [8545]: INFO Jail 'apache-noscript' uses poller {} 2020-04-09 09:26:13,843 fail2ban.jail [8545]: INFO Initiated 'polling' backend 2020-04-09 09:26:13,851 fail2ban.filter [8545]: INFO maxRetry: 3 2020-04-09 09:26:13,851 fail2ban.filter [8545]: INFO encoding: UTF-8 2020-04-09 09:26:13,851 fail2ban.actions [8545]: INFO banTime: 10800 2020-04-09 09:26:13,852 fail2ban.filter [8545]: INFO findtime: 3600 2020-04-09 09:26:13,853 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/ssl_error_log' (pos = 588859, hash = 755a00cfc09ef9b2f76d78cff61ea766) 2020-04-09 09:26:13,854 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/error_log' (pos = 27101, hash = 53ba5e7041d49628af3b86be05de6fa7) 2020-04-09 09:26:13,855 fail2ban.jail [8545]: INFO Creating new jail 'apache-overflows' 2020-04-09 09:26:13,857 fail2ban.jail [8545]: INFO Jail 'apache-overflows' uses poller {} 2020-04-09 09:26:13,857 fail2ban.jail [8545]: INFO Initiated 'polling' backend 2020-04-09 09:26:13,863 fail2ban.filter [8545]: INFO maxRetry: 2 2020-04-09 09:26:13,863 fail2ban.filter [8545]: INFO encoding: UTF-8 2020-04-09 09:26:13,864 fail2ban.actions [8545]: INFO banTime: 10800 2020-04-09 09:26:13,864 fail2ban.filter [8545]: INFO findtime: 3600 2020-04-09 09:26:13,865 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/ssl_error_log' (pos = 588859, hash = 755a00cfc09ef9b2f76d78cff61ea766) 2020-04-09 09:26:13,865 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/error_log' (pos = 27101, hash = 53ba5e7041d49628af3b86be05de6fa7) 2020-04-09 09:26:13,866 fail2ban.jail [8545]: INFO Creating new jail 'apache-nohome' 2020-04-09 09:26:13,867 fail2ban.jail [8545]: INFO Jail 'apache-nohome' uses poller {} 2020-04-09 09:26:13,868 fail2ban.jail [8545]: INFO Initiated 'polling' backend 2020-04-09 09:26:13,872 fail2ban.filter [8545]: INFO maxRetry: 2 2020-04-09 09:26:13,873 fail2ban.filter [8545]: INFO encoding: UTF-8 2020-04-09 09:26:13,873 fail2ban.actions [8545]: INFO banTime: 10800 2020-04-09 09:26:13,873 fail2ban.filter [8545]: INFO findtime: 3600 2020-04-09 09:26:13,874 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/ssl_error_log' (pos = 588859, hash = 755a00cfc09ef9b2f76d78cff61ea766) 2020-04-09 09:26:13,875 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/error_log' (pos = 27101, hash = 53ba5e7041d49628af3b86be05de6fa7) 2020-04-09 09:26:13,876 fail2ban.jail [8545]: INFO Creating new jail 'apache' 2020-04-09 09:26:13,878 fail2ban.jail [8545]: INFO Jail 'apache' uses poller {} 2020-04-09 09:26:13,879 fail2ban.jail [8545]: INFO Initiated 'polling' backend 2020-04-09 09:26:13,898 fail2ban.filter [8545]: INFO maxRetry: 3 2020-04-09 09:26:13,899 fail2ban.filter [8545]: INFO encoding: UTF-8 2020-04-09 09:26:13,899 fail2ban.actions [8545]: INFO banTime: 10800 2020-04-09 09:26:13,900 fail2ban.filter [8545]: INFO findtime: 3600 2020-04-09 09:26:13,900 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/ssl_error_log' (pos = 588859, hash = 755a00cfc09ef9b2f76d78cff61ea766) 2020-04-09 09:26:13,901 fail2ban.filter [8545]: INFO Added logfile: '/var/log/httpd/error_log' (pos = 27101, hash = 53ba5e7041d49628af3b86be05de6fa7) 2020-04-09 09:26:13,902 fail2ban.jail [8545]: INFO Creating new jail 'openvpn' 2020-04-09 09:26:13,931 fail2ban.jail [8545]: INFO Jail 'openvpn' uses systemd {} 2020-04-09 09:26:13,932 fail2ban.jail [8545]: INFO Initiated 'systemd' backend 2020-04-09 09:26:13,944 fail2ban.filtersystemd [8545]: INFO [openvpn] Added journal match for: '_SYSTEMD_UNIT=openvpn-server@xss.service + _COMM=openvpn' 2020-04-09 09:26:13,944 fail2ban.actions [8545]: INFO banTime: 10800 2020-04-09 09:26:13,944 fail2ban.filter [8545]: INFO maxRetry: 2 2020-04-09 09:26:13,944 fail2ban.filter [8545]: INFO encoding: UTF-8 2020-04-09 09:26:13,945 fail2ban.filter [8545]: INFO findtime: 3600 2020-04-09 09:26:13,949 fail2ban.jail [8545]: INFO Jail 'apache-badbots' started 2020-04-09 09:26:13,952 fail2ban.jail [8545]: INFO Jail 'apache-noscript' started 2020-04-09 09:26:13,954 fail2ban.jail [8545]: INFO Jail 'apache-overflows' started 2020-04-09 09:26:13,956 fail2ban.jail [8545]: INFO Jail 'apache-nohome' started 2020-04-09 09:26:13,961 fail2ban.jail [8545]: INFO Jail 'apache' started 2020-04-09 09:26:13,964 fail2ban.jail [8545]: INFO Jail 'openvpn' started [...]
BUT: SELinux complains about fail2ban:
type=AVC msg=audit(1586413496.76:53507): avc: denied { read } for pid=1324 comm="f2b/f.apache" name="disable" dev="sysfs" ino=1481 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0
So it seems somehow fail2ban does not add the required ip sets correctly.
From what I see in firewalld logfile it seems these problems started after the last updates on April 2nd.
On this day I did a "yum update" which executed without errors and installed:
augeas-libs-1.4.0-9.el7_7.1.x86_64 Do 02 Apr 2020 20:14:27 CEST restic-0.9.6-1.el7.x86_64 Do 02 Apr 2020 20:14:25 CEST python-perf-3.10.0-1062.18.1.el7.x86_64 Do 02 Apr 2020 20:14:23 CEST python3-pip-9.0.3-7.el7_7.noarch Do 02 Apr 2020 20:14:23 CEST borgbackup-1.1.11-1.el7.x86_64 Do 02 Apr 2020 20:14:19 CEST libgudev1-219-67.el7_7.4.x86_64 Do 02 Apr 2020 20:14:18 CEST kernel-tools-3.10.0-1062.18.1.el7.x86_64 Do 02 Apr 2020 20:14:16 CEST pcp-4.3.2-5.el7_7.x86_64 Do 02 Apr 2020 20:14:01 CEST kernel-3.10.0-1062.18.1.el7.x86_64 Do 02 Apr 2020 20:13:44 CEST systemd-python-219-67.el7_7.4.x86_64 Do 02 Apr 2020 20:13:27 CEST systemd-sysv-219-67.el7_7.4.x86_64 Do 02 Apr 2020 20:13:26 CEST rsyslog-8.24.0-41.el7_7.4.x86_64 Do 02 Apr 2020 20:13:26 CEST python2-certbot-apache-1.3.0-1.el7.noarch Do 02 Apr 2020 20:13:25 CEST sssd-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:24 CEST firewalld-0.6.3-2.el7_7.4.noarch Do 02 Apr 2020 20:13:24 CEST sssd-proxy-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:23 CEST sssd-krb5-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:23 CEST sssd-ldap-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:22 CEST sssd-ipa-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:22 CEST sssd-ad-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:22 CEST sssd-krb5-common-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:21 CEST sssd-common-pac-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:21 CEST sssd-common-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:13:20 CEST http-parser-2.7.1-8.el7_7.2.x86_64 Do 02 Apr 2020 20:13:19 CEST python-firewall-0.6.3-2.el7_7.4.noarch Do 02 Apr 2020 20:13:18 CEST certbot-1.3.0-1.el7.noarch Do 02 Apr 2020 20:13:11 CEST python2-certbot-1.3.0-1.el7.noarch Do 02 Apr 2020 20:13:10 CEST python2-acme-1.3.0-1.el7.noarch Do 02 Apr 2020 20:13:09 CEST python-requests-2.6.0-9.el7_7.noarch Do 02 Apr 2020 20:13:08 CEST systemd-219-67.el7_7.4.x86_64 Do 02 Apr 2020 20:13:05 CEST kmod-20-25.el7_7.1.x86_64 Do 02 Apr 2020 20:13:02 CEST binutils-2.27-41.base.el7_7.3.x86_64 Do 02 Apr 2020 20:13:00 CEST pcp-selinux-4.3.2-5.el7_7.x86_64 Do 02 Apr 2020 20:12:48 CEST libsss_autofs-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:47 CEST kernel-tools-libs-3.10.0-1062.18.1.el7.x86_64 Do 02 Apr 2020 20:12:46 CEST python-sssdconfig-1.16.4-21.el7_7.3.noarch Do 02 Apr 2020 20:12:45 CEST libsss_sudo-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:45 CEST firewalld-filesystem-0.6.3-2.el7_7.4.noarch Do 02 Apr 2020 20:12:44 CEST sssd-client-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:43 CEST libsss_nss_idmap-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:42 CEST libipa_hbac-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:42 CEST pcp-libs-4.3.2-5.el7_7.x86_64 Do 02 Apr 2020 20:12:41 CEST pcp-conf-4.3.2-5.el7_7.x86_64 Do 02 Apr 2020 20:12:41 CEST kmod-libs-20-25.el7_7.1.x86_64 Do 02 Apr 2020 20:12:40 CEST libsss_idmap-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:39 CEST libsss_certmap-1.16.4-21.el7_7.3.x86_64 Do 02 Apr 2020 20:12:33 CEST systemd-libs-219-67.el7_7.4.x86_64 Do 02 Apr 2020 20:12:32 CEST
The firewalld errors start exactly after the updates were installed. Does anyone else see similar problems since the last updates?
I googled and found some older postings, but nothing matching the problems I see exactly.
I have other CentOS 7 servers with fail2ban and firewalld which should be updated soon, but before I do this I first want to solve this issue.
Any idea?
Thanks!
- andreas
On 9/04/20 7:48 pm, Andreas Haumer wrote:
Hi!
I have a server running CentOS 7.7 (1908) with all current patches installed. I think this server should be a quite standard installation with no specialities
On this server I have fail2ban with an apache and openvpn configuration. I'm using firewalld to manage the firewall rules.
Fail2an is configured to use firewalld:
<snip>
The firewalld errors start exactly after the updates were installed. Does anyone else see similar problems since the last updates?
I googled and found some older postings, but nothing matching the problems I see exactly.
I have other CentOS 7 servers with fail2ban and firewalld which should be updated soon, but before I do this I first want to solve this issue.
Any idea?
I too had fail2ban fail after an otherwise successful yum update. Mine occurred in Feb when my versions of firewalld etc were updated to the versions you show. Thus far I have not had the opportunity to sort the problem. Lockdown has been quite busy so far, hopefully some slower times coming next week.
Thanks!
- andreas
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi!
Am 09.04.20 um 10:07 schrieb Rob Kampen: [...]
I too had fail2ban fail after an otherwise successful yum update. Mine occurred in Feb when my versions of firewalld etc were updated to the versions you show. Thus far I have not had the opportunity to sort the problem. Lockdown has been quite busy so far, hopefully some slower times coming next week.
Yeah, those pesky real-life biological virus keeps all of us busy just like the virtual ones... ;-)
(Just yesterday I found the following article mentioned on Slashdot: https://www.bloomberg.com/news/articles/2020-04-08/are-you-finally-thankful-...
Made me smile... :-)
Anyway, I digged into the fail2ban problem today and it looks like something changed regarding selinux and fail2ban.
After several iterations with fail2ban restart, ausearch and audit2allow like this:
ausearch -c 'f2b/server' --raw | audit2allow -M f2b-addon
I came up with a SELinux module like that:
module f2b-addon 1.0;
require { type sysctl_net_t; type sysfs_t; type fail2ban_t; class file { getattr open read }; class dir search; }
#============= fail2ban_t ==============
#!!!! This avc is allowed in the current policy allow fail2ban_t sysctl_net_t:dir search;
#!!!! This avc is allowed in the current policy allow fail2ban_t sysctl_net_t:file { getattr open read };
#!!!! This avc is allowed in the current policy allow fail2ban_t sysfs_t:file { getattr open read };
When I load this new module I can restart fail2ban and it finally is able to create a working ipset:
[root@camus ~]# ipset list Name: f2b-apache Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 timeout 10800 Size in memory: 408 References: 1 Number of entries: 3 Members: 223.167.32.161 timeout 10149 93.174.93.143 timeout 10149 5.164.24.192 timeout 10149
I'm neither a fail2ban nor a SELinux expert, but it seems the standard fail2ban SELinux policy as provided by CentOS 7 is not sufficient anymore and the recent updates did not correctly update the required SELinux policies.
I could report this as bug, but where does such a bugreport belong to in the first place?
- andreas
On 4/9/20 6:31 AM, Andreas Haumer wrote: ...
I'm neither a fail2ban nor a SELinux expert, but it seems the standard fail2ban SELinux policy as provided by CentOS 7 is not sufficient anymore and the recent updates did not correctly update the required SELinux policies.
I could report this as bug, but where does such a bugreport belong to in the first place?
- andreas
See https://bugzilla.redhat.com/show_bug.cgi?id=1777562 We're a bit stalled at the moment I'm afradi
On 13/04/20 1:30 pm, Orion Poplawski wrote:
On 4/9/20 6:31 AM, Andreas Haumer wrote: ...
I'm neither a fail2ban nor a SELinux expert, but it seems the standard fail2ban SELinux policy as provided by CentOS 7 is not sufficient anymore and the recent updates did not correctly update the required SELinux policies.
I could report this as bug, but where does such a bugreport belong to in the first place?
- andreas
See https://bugzilla.redhat.com/show_bug.cgi?id=1777562 We're a bit stalled at the moment I'm afradi
Finally had some time to look into this. Happy to say fail2ban now appears to be working.
1. I found that reading the CentOS web site about SElinux was helpful and this led me to issue the following:
semanage permissive -a fail2ban_t
this places just fail2ban requests (got the context from the scontext part of the SElinux error message) into permissive mode rather than the entire OS.
2. Then a look into the SElinux troubleshooter gave me the errors that were occurring and following the suggested instructions I created a my-f2bfsshd.pp & my-f2bfsshd.te
3. restarted fail2ban via systemctl restart fail2ban.service
4. monitored via fail2ban-client status <filter_name> and now get
Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 109 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 3 |- Total banned: 6 `- Banned IP list: 27.78.14.83 116.105.216.179 139.99.71.227
5. set fail2ban back into enforcing with
semanage permissive -d fail2ban_t
All solved for me.
I have now done this on a second machine and it too seems to be functioning again.
HTH
Rob
Am 17.04.20 um 02:59 schrieb Rob Kampen:
On 13/04/20 1:30 pm, Orion Poplawski wrote:
On 4/9/20 6:31 AM, Andreas Haumer wrote: ...
I'm neither a fail2ban nor a SELinux expert, but it seems the standard fail2ban SELinux policy as provided by CentOS 7 is not sufficient anymore and the recent updates did not correctly update the required SELinux policies.
I could report this as bug, but where does such a bugreport belong to in the first place?
- andreas
See https://bugzilla.redhat.com/show_bug.cgi?id=1777562 We're a bit stalled at the moment I'm afradi
Finally had some time to look into this. Happy to say fail2ban now appears to be working.
- I found that reading the CentOS web site about SElinux was helpful
and this led me to issue the following:
semanage permissive -a fail2ban_t
this places just fail2ban requests (got the context from the scontext part of the SElinux error message) into permissive mode rather than the entire OS.
- Then a look into the SElinux troubleshooter gave me the errors that
were occurring and following the suggested instructions I created a my-f2bfsshd.pp & my-f2bfsshd.te
restarted fail2ban via systemctl restart fail2ban.service
monitored via fail2ban-client status <filter_name> and now get
Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 109 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 3 |- Total banned: 6 `- Banned IP list: 27.78.14.83 116.105.216.179 139.99.71.227
- set fail2ban back into enforcing with
semanage permissive -d fail2ban_t
All solved for me.
I have now done this on a second machine and it too seems to be functioning again.
Great that there is a solution. I am just curious; how does your my-f2bfsshd.te looks like?
-- Leon
On 17/04/20 10:55 pm, Leon Fauster via CentOS wrote:
Am 17.04.20 um 02:59 schrieb Rob Kampen:
On 13/04/20 1:30 pm, Orion Poplawski wrote:
On 4/9/20 6:31 AM, Andreas Haumer wrote: ...
I'm neither a fail2ban nor a SELinux expert, but it seems the standard fail2ban SELinux policy as provided by CentOS 7 is not sufficient anymore and the recent updates did not correctly update the required SELinux policies.
I could report this as bug, but where does such a bugreport belong to in the first place?
- andreas
See https://bugzilla.redhat.com/show_bug.cgi?id=1777562 We're a bit stalled at the moment I'm afradi
Finally had some time to look into this. Happy to say fail2ban now appears to be working.
- I found that reading the CentOS web site about SElinux was helpful
and this led me to issue the following:
semanage permissive -a fail2ban_t
this places just fail2ban requests (got the context from the scontext part of the SElinux error message) into permissive mode rather than the entire OS.
- Then a look into the SElinux troubleshooter gave me the errors
that were occurring and following the suggested instructions I created a my-f2bfsshd.pp & my-f2bfsshd.te
restarted fail2ban via systemctl restart fail2ban.service
monitored via fail2ban-client status <filter_name> and now get
Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 109 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 3 |- Total banned: 6 `- Banned IP list: 27.78.14.83 116.105.216.179 139.99.71.227
- set fail2ban back into enforcing with
semanage permissive -d fail2ban_t
All solved for me.
I have now done this on a second machine and it too seems to be functioning again.
Great that there is a solution. I am just curious; how does your my-f2bfsshd.te looks like?
module my-f2bfsshd 1.0;
require { type proc_net_t; type sysctl_net_t; type sysfs_t; type fail2ban_t; class dir search; class file { getattr open read }; }
#============= fail2ban_t ============== allow fail2ban_t proc_net_t:file read; allow fail2ban_t sysctl_net_t:dir search; allow fail2ban_t sysctl_net_t:file { getattr open read }; allow fail2ban_t sysfs_t:file { getattr open read };
-- Leon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Andreas Haumer -
Leon Fauster -
Orion Poplawski -
Rob Kampen