Erzeuge eine Sendmail.conf in SASL Libary Verzeichnis, üblicherweise in /usr/lib/sasl.(/usr/lib/sasl2).
Dort wird die Methode festgelegt, wie sich am System authentifiziert werden soll, bsp. lokale Nutzertdaten, SASL Benutzerdatenbank oder über PAM (LDAP,MySQL...).
PLAIN mechanism:
Die PLAIN Methoden bieten selbst keine sichere (im Sinne von verschlüsselt) Methode der Authentifizierung, sie sollten nur im Hinblick auf starke Verschlüsselung eingesetzt werden. Hier werden die Passwörter im Klartext übertragen!
SASL stellt eigene interne Optionen für pwcheck_method:
Übersicht Authentifizierungsmethoden
SASLv1
SASLv2
passwd
/etc/passwd
shadow
/etc/shadow
Läuft der Server unter root Rechten stellt dies kein Problem dar. Andere Daemons sind aus sicherheitstechnischen Gründen nicht auf root Rechte angewiesen und benötigen dann ein Hilfsprogramm oder spezielle Privilegien um /etc/shadow zu lesen.
kerberos_v4
Wurde (hier) in der SASL Konfiguration deaktiviert
pam
PAM (pluggable authentication module) ist Standard auf Linux/Solaris Systemen. Die Authentifizierung kann beliebig vom Systemadministrator vergeben werden. PAM wird in aktuellen Versionen durch die Konfigurationen in /etc/pam.d/ gesteuert, die Module selbst authentifizieren gegen Radius, NIS, LDAP traditionell /etc/{passwd,shadow} oder sonstiges. Wurde SASL mit PAM kompiliert ist dies der Standard, sendmail nutzt als Servicenamen beispielsweise smtp.
sasldb
speichert Passwörter in einer SASL eigenen Datei (/etc/sasldb),
ist nötig um shared secret mechamisms zu nutzen.
eigene schreiben
auxprop
prüft Passwort gegen userPassword Attribut in einem eigenen Modul. Die Software selbst beinhaltet ein solches Plugin und nutzt dazu die /etc/sasldb2.
saslauthd
Überprüft die Werte mit einem Hilfsdaemon, der die unterschiedlichen Mechanismen kennt (pam, passwd, shadow etc). Die Applikation selbst braucht also keine root rechte mehr. Zusätzlich muss noch /usr/sbin/saslauthd -a MECH gestartet werden. MECH bezeichnet dann die Methode (bsp. PAM). Im Quellcode ist zusätzlich noch ein testsaslauthd (make testsaslauthd) Programm enthalten, um die Einstellungen des Daemons zu überprüfen.
Für die Methode PAM muss natürlich jeder Dienst in /etc/pam.d/ konfiguriert sein, sendmail nutzt hierfür den Namen smtp.
PAM selbst benötigt noch Angaben über die Art der Authentifizierung (lokal, MySQL, LDAP etc.), dazu wird noch eine Servicedatei smtp in /etc/pam.d/ erzeugt.
Eine einfache Konfigurationsdatei für lokale Authentifizierung per passwd/shadow sieht folgendermassen aus (Mandrake):
Die Cyrus SASL library unterstützt shared secret Authentifizierungsmethoden: CRAM-MD5 und DIGEST-MD5, durch den Einsatz werden keine Passwörter im Klartext über die Leitung gesendet.
Eine SASL DB Passwortdatei wird mittels saslpasswd2 (saslpasswd) für CRAM-MD5, DIGEST-MD5 und PLAIN erzeugt.
Diese Methoden basieren auf der Tatsache, das Server und Klient sich ein secret teilen, normalerweise ein Kennwort. Diese Methode ist sicherer als einfach das Kennwort über die Leitung zu senden.
*Note: sendmail verlangt eine sicheresasldb2 (sasldb), Eigentümer root oder trusted user und nur für diese(n) lesbar, da dort sensitive Daten wie Passwörter hinterlegt sind. sasldb selbst speichert Klartextkennwörter!.
[root@mulder]# saslpasswd2 -a Sendmail -u mulder.home.lan -c testuser Password: ***** Again (for verification): ***** [root@mulder]# sasldblistusers2 testuser@mulder.home.lan: userPassword testuser@mulder.home.lan: cmusaslsecretOTP
Sendmail Macro Konfiguration
Die Optionen für die .mc Macro Datei:
AuthMechanisms (confAUTH_MECHANISMS)
definiert eine Liste von Mechanismen die von sendmail angeboten werden, natürlich können die offeriert werden die auch installiert sind. Die Schnittmenge taucht nach dem AUTH Schlüsselwort der EHLO Antwort auf. default: GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
C{TrustAuthMech} (TRUST_AUTH_MECH())
definiert die Liste von Mechanismen die für Mailrelaying erlaubt sind
Hier ein Auszug aus der Sendmail Konfigurationsdatei /etc/mail/sendmail.mc
Nachdem die Konfigurationsdatei neu erstellt worden ist und der sendmail Daemon gestartet wurde kann durch ein Verbindungsaufbau die Antwort festgestellt werden:
[mulder ~]$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost.home.lan (127.0.0.1). Escape character is '^]'. 220 mulder.home.lan ESMTP Sendmail 8.13.4/8.13.4; Fri, Fri, 5 Dec 2003 11:53:15 +0100 EHLO localhost 250-mulder.home.lan Hello localhost.home.de [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP
Falls keine AUTH Zeile auftaucht sollten eventuelle Sicherheitsprobleme und die Logfiles überprüft werden (unsichere Dateien). Um mehr Informationen in den Logdateien zu erhalten ist es sinnvoll den LogLevel auf 13 zu erhöhen.
How to enable SMTP AUTH on a Linux system running sendmail.
Table of Contents
Introduction
What follows are the steps I took to implement the policies we’ve established at work for our authenticated mail relay, currently running Fedora Core 2:
All inbound connections except those originating on the localhost must authenticate against our local password map. We rely on the Pluggable Authentication Modules (PAM)—not Kerberos or SASL—for authentication and authorization, so passwords are sent over the wire with the LOGIN or PLAIN authentication mechanism.
All inbound connections must be transported over an SSL connection with a key length of at least 128 bits.
Configure sendmail.cf
There are two key elements in a sendmail.cf that’ll work as I intended: authentication mechanisms and SSL path information. I’m not a hardcore sendmail guru, so I rely completely on the m4 macro mechanism for building my configuration. Here are the key bits that need to get pushed into /etc/mail/sendmail.mc. (If you’re new to SSL, you might find my instructions for building a self-signed certificate helpful.)
dnl dnl The following allows relaying if the user authenticates, dnl and disallows plaintext authentication (PLAIN/LOGIN) on dnl non-TLS links. dnl define(`confAUTH_OPTIONS', `A p')dnl dnl dnl Accept PLAIN and LOGIN authentications. dnl TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl dnl dnl Define paths to directory hosting certs of trusted certificate dnl authorities (like VeriSign) and path to local certificate. dnl define(`confCACERT_PATH',`/etc/mail/certs')dnl define(`confCACERT',`/etc/mail/certs/ca-bundle.crt')dnl define(`localCERT', `/etc/mail/certs/our-cert.pem')dnl define(`confCLIENT_CERT',`localCERT')dnl define(`confCLIENT_KEY',`localCERT')dnl define(`confSERVER_CERT',`localCERT')dnl define(`confSERVER_KEY',`localCERT')dnl
For our purposes, sendmail absolutely must have an access map. It’s almost always part of a standard configuration, but here’s the macro just in case.
Once the macro file has been updated, regenerate sendmail.cf.
make sendmail.cf -C /etc/mail
Configure access.db
The access map is configured to enforce the 128-bit-key policy. Our /etc/mail/access is quite simple. Mail originating on the local host is relayed, while everyone wanting to connect via SSL (which is everyone) must have 128-bit crypto.
Note: You may find that that the TLS_Clt setting breaks your configuration. Deleting it probably won’t hurt anything.
After updating the text version of the access map, then rebuild the binary version.
make access.db -C /etc/mail
Configure saslauthd
Since sendmail is linked to version 2 of the Cyrus SASL libraries, it relies on saslauthd to handle plaintext authentication. On Fedora Core systems, the default authentication mechanism is the local shadow password file. In our environment, however, I need to use PAM. Implementing the change is a simple matter of altering the MECH setting in /etc/sysconfig/saslauthd.
# the default is "shadow", but we're using "pam" MECH=pam # these two settings are the defaults SOCKETDIR=/var/run/saslauthd FLAGS=
Fedora’s sendmail package ships with a SASL configuration file, /usr/lib/sasl2/Sendmail.conf, that should work out of the box. It’s a one-liner.
pwcheck_method:saslauthd
Note: Newer versions of Cyrus SASL will look for /etc/sasl2/Sendmail.conf rather than /usr/lib/sasl2/Sendmail.conf. Sooner or later, this change will also impact Fedora.
Also, you’ll want to make sure that saslauthd is started at boot time.
chkconfig saslauthd on
Configure PAM
Fedora’s sendmail package also ships with a working PAM configuration file, /etc/pam.d/smtp, but it’s worthwhile to double-check that it exists and contains the two requisite lines.