Archiv der Kategorie: Linux Howto

THINK UNBLOG GNU/Linux Tutorials Howto Workaround DevOps Code.

Postfix mit SASL-Authentifizierung verwenden

SMTP-Server müssen entscheiden, ob ein SMTP-Client autorisiert ist E-Mails zu versenden, für die der Server selbst zuständig ist.

Simple Authentication and Security Layer (SASL) Integration Postfix


Diese Anleitung beschreibt, wie man ein MTA (Mail Transport Agent) Postfix unter CentOS 7 mit CyrusSASL zur SMTP-Authentifizierung (SMTP-Auth) erweitert. Danach können Clients E-Mails mittels SMTP-Auth versenden. Diese Anleitung ist geprüft unter CentOS Linux release 7.7.1908 (Core), mit Postfix v2.10.1 und Cyrus-SASL 2.1.26. Es wird davon ausgegangen das Postfix bereits konfiguriert ist und TLS (Transport Layer Security) implementiert ist.

Postfix implementiert die SASL Library nicht selbst, sondern verwendet vorhandene Implementierungen als Bausteine. Dies bedeutet, dass einige SASL-bezogene Konfigurationsdateien zu Postfix gehören, während andere Konfigurationsdateien zu der spezifischen SASL-Implementierung gehören, die Postfix verwenden wird.

Cyrus-SASL Installation

Als root die Pakete mit folgendem Command installieren:

yum install cyrus-sasl cyrus-sasl-plain -y

Die einzelnen SASL-Mechanismen werden als RPMs installiert.

Es folgt die Einbindung für Postfix, hierzu die modifikation in der Datei /etc/postfix/master.cf vornehmen:

==========================================================================
 service type  private unpriv  chroot  wakeup  maxproc command + args
 (yes)   (yes)   (yes)   (never) (100)
 ==========================================================================
 smtps     inet  n       -       n       -       -       smtpd
   -o syslog_name=postfix/smtps
   -o smtpd_tls_wrappermode=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Damit Postfix mit SASL funktioniert, darf Postfix nicht im chroot-Verzeichnis laufen, Zeile smtps bei Position 5 (n).

SMTP-Auth für lokale Benutzer konfigurieren, wir editieren die Postfix Datei /etc/postfix/main.cf:

smtpd_tls_auth_only = no
smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = !gssapi, !login, static:all
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd 

Die Konfiguration von Cyrus-SASL erfolgt durch zwei Dateien. Die erste Datei /etc/sysconfig/saslauthd kann übernommen werden:

# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.
SOCKETDIR=/run/saslauthd

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
MECH=pam

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.
FLAGS=

Die SASL-Mechanismen PLAIN und LOGIN, CRAM-MD5 und DIGEST-MD5 kommen oft zum Einsatz, hierfür ist die Konfigurationsdatei /etc/sasl2/smtpd.conf zuständig, die bereitstellung wurde ebenfalls bei der Installation durchgeführt:

pwcheck_method: saslauthd
mech_list: plain login CRAM-MD5 DIGEST-MD5

Nun Cyrus-SASL Library Daemon starten und den systemd autostart aktivieren, anschliessend Postfix re-starten:

systemctl start saslauthd
systemctl enable saslauthd
systemctl restart postfix 

Der SMTP-Submission Support auf Port 587 ist nun aktiviert, überprüfen lässt sich dies mit folgendem Kommando:

ss -tuln4 | grep 587
tcp    LISTEN     0      100       *:587                  *:*

Zur Authentifizierung am SMTP-Gateway wird nun ein Benutzer erstellt, dieser E-Mails über den MTA versenden soll:

adduser -M -s /sbin/nologin User24
passwd User24

Eine lokale UserID ist für unsere Anforderung hier ausreichend, Cyrus-SASL unterstützt weiter LDAP und SQL, um mit beispielweise Kopano oder einem AD Verzeichnisdienst zu interagieren.

Cyrus-SASL SMTP-Auth Testen

Welche Mechanismen zur Authentifizierung innerhalb von STARTTLS unterstützt werden, kann mit OpenSSL überprüft werden:

openssl s_client -connect mail.relayhost.net:587 -starttls smtp

In der Ausgabe von openssl ein EHLO übergeben:

EHLO Hans
 250-mail.relayhost.net
 250-PIPELINING
 250-SIZE 27262976
 250-ETRN
 250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5
 250-ENHANCEDSTATUSCODES
 250-8BITMIME
 250 DSN

Ist OpenSSL nicht vorliegend, kann dazu auch Telnet genutzt werden, es wird zum Gateway mail.relayhost.net über Port 587 eine Verbindnung hergestellt, dazu kann auch PuTTY oder KiTTY verwendet werden.

KiTTY Configuration

Nun möchten wir uns beim Gateway (MTA) Authentifizieren. Der Benutzername und das Passwort muss im base64-codierten Format an das SMTP-Gateway übertragen werden, Hierzu gibt man die folgenden Befehlszeilen ein, um die base64-Codierung für den Benutzername und das Passwort zu erhalten.

echo -en "userxy" | base64
dXNlcnh5
echo -en "password" | base64
cGFzc3dvcmQ=

Die SASL SMTP-Auth Konfiguration und Authentifizierung überprüft man wie folgt mit ausführen der folgenden Zeilen im Terminal, nach Eingabe von AUTH LOGIN der mit Base64 codierte Benutzername und das Passwort einfügen.

AUTH LOGIN
dXNlcnh5
cGFzc3dvcmQ=
$ telnet mail.relayhost.net 25
Trying mail.relayhost.net...
Connected to mail.relayhost.net
Escape character is '^]'.
220 mail.relayhost.net ESMTP MAIL Service ready at  Sat, 12 Mar 2019 09:26:12
EHLO smtp.example.com
250-smtp.example.com Hello
250-AUTH=LOGIN
250-AUTH LOGIN
250-TURN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK
AUTH LOGIN
334 VXClcm5hbWU6
dXNlcnh5
334 UGFzc4dvcmQ8
cGFzc3dvcmQ=
235 2.7.0 Authentication successful

Die Ausgabe SMTP-Auth von Postfix mit Cyrus-SASL.

Die oben kodierten Credentials bei den 334 Prompts einfügen, hier bei Zeile 24 als userxy und bei Zeile 26 unser password.

  Ein 250 STARTTLS in der Ausgabe zeigt die Voraussetzungen, das Klartext-Benutzernamen mit Passwort durch STARTTLS geschützt an das SMTP-Gateway übermittelt werden.

Eine weitere einfache Möglichkeit gibt es mit SMTPConsole ein SMTP-Gateway zu testen.

Mit SMTP Console testen
SMTPConsole

sudo Passwort Default Timeout verlängern

sudo Passwort Default Timeout mit visudo verlängern

Auch Systemverwalter authentifizieren sich als normale Benutzer und verwenden sudo, wenn administrative Aufgaben erledigt werden. Beim ersten Aufruf fragt sudo nach dem Passwort, danach ist sudo für einige Zeit aktiv.

Der sudo Default Passwort Timeout Wert beträgt 15 Minuten. Wenn sudo innerhalb von 15 Minuten (900 Sekunden) ein weiteres mal ausgeführt wird, bleibt die Aufforderung das Kennwort erneut einzugeben aus.

sudo timestamp timeout verlängern

Der timestamp_timeout definiert die Anzahl Minuten, die vergehen bevor sudo erneut nach dem Passwort fragen soll. Bearbeite zum Ändern des timestamp_timeout die Datei /etc/sudoers.

Ich empfehle deb Befehl visudo zu verwenden, um die Datei /etc/sudoers zu bearbeiten. Füge den Wert timestamp_timeout auf der Zeile nach „Defaults“ hinzu, in der Datei /etc/sudoers.

$ sudo su

sudoers Defaults anzeigen

Der grep Befehl zeigt die Ausgabe der betreffenden Zeilen.

$ grep Defaults /etc/sudoers

Hier ein sudoers bei Linux Mint.

sudo Passwort Default Timeout verlängern
Linux Mint: grep Defaults /etc/sudoers

Die Standardeinstellung ist „Defaults env_reset“.

$ sudo visudo 

Default Passwort Timeout verlängern

Editiere sudoers so das die Zeile Defaults folgendes zeigt:

Defaults    env_reset,timestamp_timeout=-0

timestamp_timeout=-1 (minus eins) bewirkt, dass das sudo-Passwort nie abläuft.

  Bei Debian/Ubuntu Distributionen hat die Option -0 nicht funktioniert. Ein höheren Wert zB. 60 wird akzeptiert.

timestamp_timeout=0 (null) bewirkt, dass das sudo-Kennwort alle 0 (null) Sekunden abläuft. Dies bedeutet, dass mit jedem aufruf von sudo nach dem Kennwort gefragt wird.