CentOS - Apr 2020 - fail2ban firewalld problems with current CentOS 7

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-for-your-it-person-now

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 at 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

-- 
Andreas Haumer                     | mailto:andreas at xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20200409/33d7abf9/attachment.sig>

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

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

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