SELinux verhindert, dass Fail2Ban Benachrichtigungen per E-Mail über msmtp versendet

SELinux verhindert, dass Fail2Ban Benachrichtigungen per E-Mail über msmtp versendet

Ich habe msmtp als Null-Client, der sich mit meinem AWS SES-Konto für SMTP verbindet und Warnmeldungen wie cron, monit und hoffentlich bald auch Fail2Ban an meine E-Mail-Adressen sendet. Fail2Ban spielt jedoch nicht mit, oder genauer gesagt, Selinux verhindert, dass etwas passiert.

action_mwl funktioniert im Permissive-Modus einwandfrei. Ich bekomme Sperr-E-Mails. Im Enforcing-Modus protokolliert Fail2Ban einen Fehler und es wird keine E-Mail gesendet. Laut MSMTP-Protokoll wird versucht, die E-Mail zu senden, aber es klappt nicht.

Hier ist ein solcher (Teil eines) Fail2Ban-Logeintrags:

2015-09-29 12:25:12,543 fail2ban.actions        [31113]: ERROR   Failed to execute ban jail 'wordpress' action 'sendmail-whois-lines' info 'CallingMap({'ipjailmatches': <function <lambda> at 0x2c5ac08>, 'matches': u'

msmtp meldet:

Sep 29 12:25:12 host=email-smtp.eu-west-1.amazonaws.com tls=on auth=on user=12345 [email protected] [email protected] errormsg='cannot connect to email-smtp.eu-west-1.amazonaws.com, port 587: Permission denied' exitcode=EX_TEMPFAIL

Es ist weder ein Problem mit der MSMTP-Konfiguration noch mit dem Inhalt des E-Mail-Texts, da ich genau diese Fail2Ban-Nachricht problemlos von der Befehlszeile aus an MSMTP senden kann (direkt oder über den symbolischen Sendmail-Link) und sie wird einwandfrei gesendet. Anmeldeinformationen usw. sind daher in Ordnung. Funktioniert auch über Cron. Das heißt, es ist auch kein Firewall-Problem.

$ sudo ls -lZ /usr/bin/msmtp
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/msmtp

$ sudo ls -lZ /usr/bin/sendmail
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /usr/bin/sendmail -> /usr/bin/msmtp

In jail.conf:

mta = sendmail

sealert gibt mir keine erkennbaren Hinweise oder Maßnahmen.

Ich habe bestätigt, dass fail2ban als Root ausgeführt wird:

$ ps aux | grep fail2ban

Ich habe einige zusätzliche Protokolle hinzugefügt und erhalte dies jetzt in /var/log/messages

Sep 29 16:11:15 ip-172-31-6-51 setroubleshoot: SELinux is preventing /usr/bin/msmtp from name_connect access on the tcp_socket port 587. For complete SELinux messages. run sealert -l 78f05dbd-a953-4196-9f14-afaabb5a4d88
Sep 29 16:11:15 ip-172-31-6-51 python: SELinux is preventing /usr/bin/msmtp from name_connect access on the tcp_socket port 587.

Wo muss ich als nächstes suchen? Wie kann ich feststellen, ob SELinux Fail2Ban problemlos mit msmtp zusammenarbeiten darf?

Antwort1

Nachdem ich eine ausführlichere Protokollierung hinzugefügt hatte, bekam ich genügend Hinweise vom System (und @Michael Hampton), um dies herauszufinden.

yum install setroubleshoot setools

Dies liefert viel mehr Informationen in /var/log/messages und bietet Tools wie:

sealert -a /var/log/audit/audit.log

Auch:

ausearch -m avc

Sie erhalten Anweisungen wie:

Sep 29 16:11:15 ip-172-31-6-51 setroubleshoot: SELinux is preventing /usr/bin/msmtp from name_connect access on the tcp_socket port 587. For complete SELinux messages. run sealert -l 78f05dbd-a953-4196-9f14-afaabb5a4d88

Ausführen des vorgeschlagenen Befehls:

sealert -l 78f05dbd-a953-4196-9f14-afaabb5a4d88

Gibt mir:

If you believe that msmtp should be allowed name_connect access on the port 587 tcp_socket 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:
# grep msmtp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

So tat ich:

$ grep msmtp /var/log/audit/audit.log | audit2allow -M fail2ban_msmtp

Ich habe nachgeschaut, was dabei herauskam:

$ vim fail2ban_msmtp.te

Und dann die Richtlinie installiert, sodass sie nach einem Neustart bestehen bleibt:

$ semodule -i fail2ban_msmtp.pp

Ich habe dann eine zufällige IP gesperrt um eine Sperre mit Bestätigungsmail auszulösen und nun schickt sie mir endlich die gewünschte Mail per msmtp:

$ fail2ban-client set sshd banip 162.229.158.134

Presto! So einfach, dieses SELinux-Zeug.

PS: Ein anderer Weg scheint zu sein (nicht getestet):

$ setsebool -P nis_enabled 1

verwandte Informationen