Knowledgebase / FAQ - ip-connect GmbH
Knowledgeroot - Version: 0.9.9.5
Menü verstecken Menü ausklappen Menü neuladen Menü einklappen
Menü schliessen
  1.Sendmail als Server    (Zuletzt geändert von rsch an 02.11.2009 23:49:12)
sendmail als Server  
seitenanfang
 

Methoden

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 link 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 link 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.
  • eigene schreiben :-)

download /usr/lib/sasl2/Sendmail.conf

pwcheck_method:saslauthd

Hilfprogramm: /usr/sbin/saslauthd -a pam

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):


download /etc/pam.d/smtp

%PAM-1.0
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth


secrets mechanisms

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 sichere sasldb2 (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!.

SASLv1 SASLv2
[root@mulder ~]# saslpasswd -a Sendmail -u mulder.home.lan -c testuser
Password: *****
Again (for verification): *****
[root@mulder ~]# sasldblistusers
user: testuser realm: mulder.home.lan mech: DIGEST-MD5
user: testuser realm: mulder.home.lan mech: PLAIN
user: testuser realm: mulder.home.lan mech: CRAM-MD5
[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

[...]
dnl --------------
dnl Authentication
dnl --------------
define(`confAUTH_MECHANISMS', `PLAIN LOGIN DIGEST-MD5 CRAM-MD5')dnl
TRUST_AUTH_MECH(`PLAIN LOGIN DIGEST-MD5 CRAM-MD5')dnl
[...]

Nachdem die Konfigurationsdatei link neu erstellt worden ist und der linksendmail 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.

define(`confLOG_LEVEL',`13')
verschieben [Oben]

  2.Quick Start    (Zuletzt geändert von rsch an 02.11.2009 23:47:16)

Sendmail SMTP AUTH Quick Start

Paul Heinlein

Initial publication: July 7, 2004
Most recent revision: October 11, 2004

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:

  1. 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.

  2. 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.

FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl

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.

localhost.localdomain           RELAY
localhost RELAY
127.0.0.1 RELAY
TLS_Clt: ENCR:128

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.

#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth

Start it up

With all those configuration files in place, all that’s left to do is start (or restart) the server software.

/etc/init.d/saslauthd start
/etc/init.d/sendmail start

Gentoo notes

The instructions provided above will work on Gentoo Linux systems with a few modifications:

  • When building sendmail, make sure that your USE variable includes sasl and ssl.

    USE="sasl ssl" emerge mail-mta/sendmail
  • The paths to the key and certificate files in sendmail.cf will be in the /etc/ssl/certs directory tree.

  • Rebuilding sendmail.cf and access.db needs to be done by hand.

    cd /etc/mail
    cp sendmail.cf sendmail.cf.bak
    m4 sendmail.mc > sendmail.cf
    makemap hash access < access
  • Some newer cyrus-sasl ebuilds will look for /etc/sasl2/Sendmail.conf rather than /usr/lib/sasl2/Sendmail.conf.

  • saslauthd startup options are stored in /etc/conf.d/saslauthd. Use the SASL_AUTHMECH variable to specify the authentication mechanism.

  • You’ll need to create the PAM configuration file, /etc/pam.d/smtp:

    #%PAM-1.0
    auth required /lib/security/pam_stack.so service=system-auth
    account required /lib/security/pam_stack.so service=system-auth
  • saslauthd and sendmail can be configured to be started at boot time in the standard Gentoo way.

    rc-update add saslauthd default
    rc-update add sendmail default

Useful links

RFC 2554 defines SMTP AUTH.

SMTP AUTH in sendmail 8.10-8.12 is the more-or-less official HOWTO page on the subject from sendmail.org.

Several online documents are more complete and include many more details than mine: Falko Timme’s Sendmail-SMTP-AUTH-TLS-Howto, John Fullmer’s How to set up SMTP AUTH, and Rodolfo Paiz’ Sendmail SMTP AUTH HOWTO.

 

verschieben [Oben]