Re: [CentOS] 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@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:andr...@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
signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS] fail2ban firewalld problems with current CentOS 7
3507): 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_64Do 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_64Do 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_64Do 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_64Do 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_64Do 02 Apr 2020 20:13:23 CEST
sssd-ldap-1.16.4-21.el7_7.3.x86_64Do 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_64Do 02 Apr 2020 20:13:19 CEST
python-firewall-0.6.3-2.el7_7.4.noarchDo 02 Apr 2020 20:13:18 CEST
certbot-1.3.0-1.el7.noarchDo 02 Apr 2020 20:13:11 CEST
python2-certbot-1.3.0-1.el7.noarchDo 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_64Do 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.noarchDo 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_64Do 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_64Do 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
--
Andreas Haumer | mailto:andr...@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
signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Which is better? Microsoft Exchange 2016 or Linux-based SMTP Servers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Am 18.07.2018 um 20:27 schrieb Johnny Hughes: [...] > > But are you guys really telling you think the calendaring / scheduling for > individual users and the main corporate account, etc. .. are working well > enough with any Linux solution. > [...] Yes, I do think so! :-) At least for up to about 100 users (that's the size of the businesses we usually have as our customers) We implemented Linux-based groupware solutions for those clients in the past (and hopefully will do in the future) based on the following main components: *) Linux (CentOS, SLES, OpenSUSE, depending on customers preferences) *) Cyrus IMAP *) Sendmail [sic] *) OpenLDAP *) SOGO (nobody mentioned SOGO yet, but IMHO it works very well and integrates perfectly into the Linux software stack!) *) Fusiondirectory (was GOSa) *) And the usuall suspects like ClamAV, SpamAssassin, ... This solution provides: *) Basic Mail (Relay, Server, Storage, ...) *) Webmail (through SOGO) *) Calendar and address book Web UI *) Calendar and address book for a desktop client like Thunderbird (CalDAV, CardDAV) *) Web-Based Admin UI for both admins and users (to manage their own accounts) *) Integration with smartphones (mail, calendar, address book) *) Features like shared mailboxes, shared calendars, ... *) Easy integration with all typical Unix/Linux services (Fileserver, Webserver, VPN, ...) I have no experience with Exchange (and I refuse to get any), but I have "some" with Unix/Linux (since 1990. Yes I'm old ;-) For me the above mentined software stack "just works" and it does for the more advanced business use case, too. I can't say anything about solutions for thousands of users, though, so YMMV! Regards - - andreas - -- Andreas Haumer | mailto:andr...@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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFbT5A2xJmyeGcXPhERArplAJ9GILNWEm0S9LlvkNGE/LTUg61ylwCgkkc1 SQvs/o/neTjsio8RmSnfSwc= =dX5+ -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How insecure is NIS ? Possible alternatives ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Am 29.03.2018 um 09:38 schrieb Nicolas Kovacs: > Le 29/03/2018 à 06:44, Keith Keller a écrit : >> I wonder how much support there is for NIS any more in recent distros. Is it >> possible CentOS 7 doesn't support NIS, or does but is buggy? > > I'm planning to test this very soon, probably during the next week, and I'll > report back. > We are using the OpenLDAP + pam_ldap / sssd solution in several smaller networks (up to ~40 Linux clients), but I think it should scale well for larger networks, too. The OpenLDAP solution can also support Samba as domain controller, if you have to support windows clients, too. - From that point on we usually integrate other services like an IMAP server (we use Cyrus IMAP), groupware server (we use SOGo) and many other services which suport LDAP authentication. You can apply LDAP password policies, too. We use GOSa (or it's successor FusionDirectory, see https://www.fusiondirectory.org/) as web frontend, so the users can change their passwords, mail settings etc. on their own (if they are given the rights to do so) With all that you get a nice, easy to manage, well integrated and secure network with a central authentication service all with open source software! It should run with almost all modern linux distributions, even mixed together in the same network. HTH - - andreas - -- Andreas Haumer | mailto:andr...@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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFavJxYxJmyeGcXPhERAokrAKC1czb7l/AWaLZSDJ4g+VlIBN0IIQCgm7Iv p5hn8aLp32GA4mJ49RXqp8A= =s0/Q -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Pacemaker bugs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I think I stumbled on at least two bugs in the CentOS 7.2 pacemaker package, though I'm not quite sure if or where to report it. I'm using the following package to set up a 2-node active/passive cluster: [root@clnode1 ~]# rpm -q pacemaker pacemaker-1.1.13-10.el7_2.4.x86_64 The installation is up-to-date on both nodes as of the current PIT. I have currently the following cluster resources running: [root@clnode2 ~]# pcs status Cluster name: rucluster1 Last updated: Fri Nov 25 11:26:51 2016 Last change: Fri Nov 25 10:51:32 2016 by root via cibadmin on clnode1 Stack: corosync Current DC: clnode2 (version 1.1.13-10.el7_2.4-44eb2dd) - partition with quorum 2 nodes and 12 resources configured Online: [ clnode1 clnode2 ] Full list of resources: p_ip_cluster (ocf::heartbeat:IPaddr2): Started clnode2 Master/Slave Set: ms_drbd_r0 [p_drbd_r0] Masters: [ clnode2 ] Slaves: [ clnode1 ] p_fs_drbd1 (ocf::heartbeat:Filesystem):Started clnode2 p_apache (ocf::heartbeat:apache):Started clnode2 p_dhcpd(ocf::heartbeat:dhcpd): Started clnode2 p_named(ocf::heartbeat:named): Started clnode2 p_slapd(ocf::heartbeat:slapd): Started clnode2 p_postgres (ocf::heartbeat:pgsql): Started clnode2 p_nmb (systemd:nmb): Started clnode2 p_smb (systemd:smb): Started clnode2 p_winbind (systemd:winbind): Started clnode2 PCSD Status: clnode1: Online clnode2: Online Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled The first bug is rather serious, though a workaround exists! The cluster works fine, but as soon as I add a cluster resource of class "service", the cluster manager software runs havoc on node failover. In that situation, the lrmd process hangs in an infinite loop (neither strace nor ltrace show any outout so it seems to be an internal loop without any system or library call) and almost any call to the cluster manager software (crmsh or pcs) runs into a timeout. It's quite hard to recover the whole cluster from this situation. When I replace the resource class "service" with resource class "systemd", everything seems to work just fine. I found a rather old, already closed bug for Fedora which looks similar: <https://bugzilla.redhat.com/show_bug.cgi?id=1117151> Another bug seems to be rather minor: I see following assertions in the corosync logs: Nov 25 11:13:56 [3206] clnode1 crmd:error: crm_abort: pcmkRegisterNode: Triggered assert at xml.c:594 : node->type == XML_ELEMENT_NODE They seem to be related with the drbd resource, but do not cause any functional problem it seems. For this particular problem I found the following patch: <https://github.com/ClusterLabs/pacemaker/commit/68c7506aa84c69e5f425ef5f3025a9efb41d13da> Are these already known bugs? (I searched the CentOS bugzilla site but couldn't find any ticket describing these bugs) Any advise on if or where I should report it? Thanks! - - andreas - -- Andreas Haumer | mailto:andr...@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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFYOBLBxJmyeGcXPhERAmSKAJ9NNI+D2OaBR1I8jum6AywMxQxsmACfU71C HV+6j+4YRy71BkjHfipPJFg= =Okfp -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
