logo Homepage Wolfgang Wilhelm :: v 0.9.1 21.02.2006 :: (v.0.9 __ 14.04.03)  
 
impressum :: feedback ::  Rubiks Magic ::  aktuelles   
Startseite
 LINKWEG ::: inhalt / sendmail als MTA / SMTP Authentifizierung


sendmail als Mail Transport Agent

 

info  SMTP Authentifizierung

anker sendmail als Server
anker sendmail als Client

 

 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:

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

 

 sendmail als Client  
seitenanfang
 

Arbeitet Sendmail als Client benötigt es einige Informationen um sich gegenüber dem anderen MTA zu authentifizieren. Diese Informationen werden über den Regelsatz authinfo bereitgestellt. Der authinfo Regelsatz sucht den Servernamen mit vorangestelltem Kennzeichen AuthInfo: in der Access Datenbank. Da ich dies etwas suspekt finde nutze ich ein Sendmail externFEATURE zum Auslagern der Informationen. Die Option DefaultAuthInfo ist veraltet und sollte nicht mehr genutzt werden.
*Note: Auch in der Clientversion muss sendmail mit linkSASL gebaut sein.


  FEATURE(`authinfo',`hash /etc/mail/authinfo')
Die Datei besteht aus einer Liste von Schlüsselwörtern: Beispieleinträge:
  AuthInfo:smtpauth.smarthost.tld "U:user" "I:user" "P:secret" "R:smarthost.tld" "M:DIGEST-MD5"
  AuthInfo:smtpauth.smarthost.tld "U:user" "P:Pa55w0rD"

Benutzer- oder Authentifizierungs-ID sowie das Passwort müssen vorhanden sein. Alle anderen Angaben haben Standardwerte. Da diese Tabelle schützenswerte Informationen enthält sollte sie für jeden Benutzer ausser root (oder dem "trusted user") unlesbar gemacht werden.Besondere Beachtung sollte hier dem Realm zukommen, die ist ein wichtiger Bestandteil der shared secret Mechanismen. Beim Provider nach diesem Wert nachfragen, normalerweise ist dies der vollqualifizierte Domänennamen FQDN. Natürlich könnte dort auch ein nicht so einfach zu erratender Wert stehen :-)


Damit der MTA die Post auch über der Mailserver der Providers versendet wird noch der sog. Smarthost definiert.
  define(`SMART_HOST', `smtpauth.smarthost.tld')

Nun noch die link Konfigurationsdateien link generieren und den sendmail Daemon neu starten.

 




left  Software
starke Verschlüsselung  right
 
Seitenanfang
           © 2003 by Wolfgang Wilhelm • mail:   wwilhelm at rz-online dot de handmade by xemacs   Valid XHTML 1.0!
Last modified: Tuesday, 11-Apr-2006 11:02:42 CEST
counter