Hi, I'm running CentOS 7 on an Internet-facing server. SELinux is in permissive mode for debugging. I've removed FirewallD and replaced it with a custom-made Iptables script. I've also installed and configured Fail2ban (fail2ban-server package) to protect the server from brute force attacks. Out of the box, Fail2ban doesn't seem to play well with SELinux. Here's what I get. $ sudo sealert -a /var/log/audit/audit.log 100% done found 5 alerts in /var/log/audit/audit.log ------------------------------------------------------------ SELinux is preventing /usr/bin/python2.7 from read access on the file disable. ***** Plugin catchall (100. confidence) suggests ***** If you believe that python2.7 should be allowed read access on the disable file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'f2b/f.sshd' --raw | audit2allow -M my-f2bfsshd # semodule -i my-f2bfsshd.pp ... As far as I can tell - and please correct me if I'm wrong - if a package doesn't play well with SELinux in the default configuration, this should be considered as a bug. In that case, the appropriate reaction would be to file a bug on the EPEL mailing list, since EPEL provides the fail2ban-server package. Other than that, the solution suggested by sealert seems to work. $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i my-f2bfsshd.pp $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i my-f2bfsshd.pp $ sudo semodule -i my-f2bfsshd.pp $ echo | sudo tee /var/log/audit/audit.log $ sudo systemctl restart fail2ban $ sudo sealert -a /var/log/audit/audit.log 100% done found 0 alerts in /var/log/audit/audit.log Any suggestions ? Niki -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32 Mob. : 06 51 80 12 12
On Thu, 13 Feb 2020 at 02:42, Nicolas Kovacs <info at microlinux.fr> wrote:> Hi, > > I'm running CentOS 7 on an Internet-facing server. SELinux is in > permissive > mode for debugging. I've removed FirewallD and replaced it with a > custom-made > Iptables script. I've also installed and configured Fail2ban > (fail2ban-server > package) to protect the server from brute force attacks. > > Out of the box, Fail2ban doesn't seem to play well with SELinux. Here's > what I get. > > $ sudo sealert -a /var/log/audit/audit.log > 100% done > found 5 alerts in /var/log/audit/audit.log > ------------------------------------------------------------ > SELinux is preventing /usr/bin/python2.7 from read access on the file > disable. > > ***** Plugin catchall (100. confidence) suggests ***** > > If you believe that python2.7 should be allowed read access on the disable > file > by default. > Then you should report this as a bug. > You can generate a local policy module to allow this access. > Do > allow this access for now by executing: > # ausearch -c 'f2b/f.sshd' --raw | audit2allow -M my-f2bfsshd > # semodule -i my-f2bfsshd.pp > ... > > As far as I can tell - and please correct me if I'm wrong - if a package > doesn't play well with SELinux in the default configuration, this should > be > considered as a bug. In that case, the appropriate reaction would be to > file a > bug on the EPEL mailing list, since EPEL provides the fail2ban-server > package. > >The appropriate action would be to file it as a bug in bugzilla.redhat.com. Posting it to the epel-devel mailing list would probably not get any fix as most packagers are not on it. (They are also not on the fedora-devel list either) Whether it gets fixed or not is going to be up to the packager. EPEL is a volunteer collection where we do not have much man-power to fix things unless the main Fedora packager is involved.> Other than that, the solution suggested by sealert seems to work. > > $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd > ******************** IMPORTANT *********************** > To make this policy package active, execute: > semodule -i my-f2bfsshd.pp > > $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd > ******************** IMPORTANT *********************** > To make this policy package active, execute: > semodule -i my-f2bfsshd.pp > $ sudo semodule -i my-f2bfsshd.pp > $ echo | sudo tee /var/log/audit/audit.log > $ sudo systemctl restart fail2ban > $ sudo sealert -a /var/log/audit/audit.log > 100% done > found 0 alerts in /var/log/audit/audit.log > > Any suggestions ? > > Niki > > -- > Microlinux - Solutions informatiques durables > 7, place de l'?glise - 30730 Montpezat > Site : https://www.microlinux.fr > Mail : info at microlinux.fr > T?l. : 04 66 63 10 32 > Mob. : 06 51 80 12 12 > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Stephen J Smoogen.
On Thu, Feb 13, 2020 at 08:42:29AM +0100, Nicolas Kovacs wrote:> I'm running CentOS 7 on an Internet-facing server. SELinux is in permissive > mode for debugging. I've removed FirewallD and replaced it with a > custom-made Iptables script. I've also installed and configured Fail2ban > (fail2ban-server package) to protect the server from brute force attacks. > [...] > As far as I can tell - and please correct me if I'm wrong - if a package > doesn't play well with SELinux in the default configuration, this should be > considered as a bug. In that case, the appropriate reaction would be to file > a bug on the EPEL mailing list, since EPEL provides the fail2ban-server > package.In your case, you are not using fail2ban in any sort of default configuration. Firewalld is the default firewall management in CentOS 7. fail2ban was set up to use firewalld, and in fact, is much more efficient than using iptables since the fail2ban-firewalld package uses ipsets instead of individual iptables rules.> SELinux is preventing /usr/bin/python2.7 from read access on the file disable.You mention the file 'disable' but I'm not aware of a file called 'disable' in the fail2ban-server package. What file is it trying to read from? Perhaps you've put a file someplace that has a label that makes sense for fail2ban to not be able to read from? -- Jonathan Billings <billings at negate.org>
> On Feb 13, 2020, at 9:01 AM, Jonathan Billings <billings at negate.org> wrote: > > On Thu, Feb 13, 2020 at 08:42:29AM +0100, Nicolas Kovacs wrote: >> I'm running CentOS 7 on an Internet-facing server. SELinux is in permissive >> mode for debugging. I've removed FirewallD and replaced it with a >> custom-made Iptables script. I've also installed and configured Fail2ban >> (fail2ban-server package) to protect the server from brute force attacks. >> [...] >> As far as I can tell - and please correct me if I'm wrong - if a package >> doesn't play well with SELinux in the default configuration, this should be >> considered as a bug. In that case, the appropriate reaction would be to file >> a bug on the EPEL mailing list, since EPEL provides the fail2ban-server >> package. > > In your case, you are not using fail2ban in any sort of default > configuration. Firewalld is the default firewall management in CentOS > 7. fail2ban was set up to use firewalld, and in fact, is much more > efficient than using iptables since the fail2ban-firewalld package > uses ipsets instead of individual iptables rules. > >> SELinux is preventing /usr/bin/python2.7 from read access on the file disable. > > You mention the file 'disable' but I'm not aware of a file called > 'disable' in the fail2ban-server package. What file is it trying to > read from? Perhaps you've put a file someplace that has a label that > makes sense for fail2ban to not be able to read from?This bug (CLOSED WONTFIX) appears to be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1777562 The 'disable' file is /sys/module/ipv6/parameters/disable. Bez Thomas