Mailserver Howto für Debian

Nachdem sich Debian immer weiterdreht, habe ich meine  Mail- und Antispamhowtos zusammengefasst und mal auf den aktuellen Stand gebracht. Ich beziehe mich zwar im wesentlichen auf Debian, allerdings dürften abweichend von der Grundinstallation der Pakete, dieses Howto auf jeden anderen Linuxsystem ebenso funktionieren. Als Mailsystem kommen cyrus und postfix zum Einsatz, zur Authentifizierung der saslauthd. Zum Filtern und Virencheck setze ich Amavisd-new, Spamassassin, Razor, DCC und Pyzor ein.

Stand: 06.12.2009

ToDo – List:

– Authentifizierung (unterschiedliche Mechanismen)
– Usermanagement (Ldap)
– Usermanagement (MySQL)
– IMAP Backup

Als erstes installieren wir folgende Pakete:

#>apt-get install spamassassin razor perl pyzor procmail fetchmail postfix amavisd-new cyrus-common-2.2 cyrus-imapd-2.2 cyrus-admin-2.2 sasl2-bin saslauthd sasl2-bin libsasl2-modules libsasl2 libgsasl7 libauthen-sasl-perl ca-certificates

SASLAUTHD

Auch wenn es zunächst unsinnig erscheint, benutzen wir für unser kleines Szenario den saslauthd. Das macht es uns später einfacher den Authentifikationsmechanismus zu ändern. In der der /etc/default/saslauthd überprüfen wir die Konfiguration auf folgende Werte:

CURUS

Die Konfiguration des Imap-Daemon geschiet durch das Editieren der /etc/imapd.conf. Das von Debian angelegte File ist vollkommen brauchbar. Es muss allerdings noch mindestens ein Administrator des Daemons festgelegt werden und wie die Athentifizierung von statten gehen soll..

Hier ein Auszug aus /etc/imapd.conf:

Der User cyrus sollte automatisch von DEBIAN erstellt worden sein. Sollte dies nicht der Fall sein, kann das mittels

nachholgeholt werden.

Mit saslauthd stehen unterschiedliche Möglichkeiten der Authentifizierung zur Verfügung. Ich gehe vorerst nur auf die Voreingestellte ein, gegen die Sasldb.  Bevor man den User cyrus zur Administration des imap-servers verwenden kann, müssen Sie ihm noch ein Passwort zuweisen (Hierzu muss sasl2-bin installiert sein):

Somit sollte der Imapd voll funktionsfähig sein. Nun müssen wir nur noch dafür sorgen, dass die Userkonten eingerichtet werden. Hierfür gibt es als frontend zum Beispiel http://www.web-cyradm.org. Ich möchte hier nur kurz auf die Kommandozeile eingehen.

Abhängig von den Authentifizierungsmechanismen muss man eventuell noch mit

ein Passwort vergeben.

POSTFIX

Bei der Installation wurden Sie in der Regel gefragt, wie POSTFIX genutzt werden soll. (local-delivery, Internet-Site…). Das ist egal, da wir die Konfigurationsdateien sowieso abändern. POSTFIX wird durch die Dateien /etc/postfix/main.cf und /etc/postfix/master.cf konfiguriert. Achtung: bitte etwaige Werte wie Subnetze etc. an die eigenen Gegebenheiten anpassen. Damit das Zusammenspiel mit CYRUS problemlos klappt, müssen folgende Zeilen in die Datei /etc/postfix/master.cf geschrieben werden:

Die Datei /etc/postfix/main.cf wird um folgende Einträge ergänzt:

Der Eintrag mynetworks dient dazu, dass Mails von diesen Rechnern, mit beliebigem Absender verschickt werden können(sogenannter Relayserver).

FETCHMAIL

Wenn der Mailserver mit MX Eintrag für Ihre Domain zu erreichen ist und sie keine weiteren Postfächer und Konten abholen müssen überspringen Sie den Teil. Fetchmail muss mitgeteilt werden, welche Accounts geholt und wie sie verarbeitet werden müssen. Globale Einstellungen können im File /etc/fetchmailrc vorgenommen werden. Hier, die auf unser Szenario abgestimmte, /etc/fetchmailrc.

Im Detail passiert hier folgendes: Wir holen die Emails vom GMX – Konto des Users 1234567 ab und stellen sie lokal an den User test1 zu. Wenn Sie beispielsweise ein sogenanntes Catch-All-Postfach abholen, lassen Sie den Part „is „test1″ here“ einfach weg. Die Mails können dann via den verschiedenen Aliasmechanismen auf unterschiedliche Nutzer verteilt werden.

AMAVIS-NEW

Ich installiere Avira AntiVir PersonalEdition Classic. Hier sei darauf verwiesen, dass es noch jede Meneg weitere Virenscanner gibt, die von Amavis-new unterstützt werden. Ansonsten muss man amavis noch verständlich machen, wer sich auf ihn verbinden darf. Dies erfolgt mittels @inet_acl am besten in der 50-user

Abschliessend sollte man noch einige Werte anpassen:

und nicht vergessen folgende Zeilen in /etc/amavis/conf.d/15-content_filter_mode auskommentieren(# entfernen):

SPAMASSASSIN

SpamAssassin wird unter dem User cyrus ausgeführt, deswegen müssen wir ein paar Anpassungen zur Nutzung der Bayes Datenbank vornehmen. Die /etc/spamassassin/local.cf wird wie folgt umgeschrieben:

Damit die Filterung nach Sprachen funktioniert müssen wir in /etc/spamassassin/v310.pre

entkommentieren.

Ebenso müssen wir die /etc/default/spamassassin mittels der Option -A anpassen, ansonsten kann spamc nicht auf den spamd konnektieren, weiterhin ergänzen wir ein Log.

RAZOR

Vipul’s Razor ist ein verteilter serverseitiger Spam Filter. Razor erstellt kontinuierlich einen Katalog Server zur Spamerkennung. Dieser Server wird durch Internetnutzer mit Spam-Mails gefüllt. Erhält der Server dieselbe Spam Nachricht öfters und von verschiedenen Nutzern wird diese im Katalogserver als Spam gelistet. SpamAssassin prüft ob auf dem Razor Server eine Nachricht als Spam gelistet ist und vergibt im Falle einer positiven Anwort Punkte. Damit das auch funktioniert müssen wir unter dem User cyrus Razor einrichten

PYZOR

Pyzor ist ähnlich wie Razor und DCC ein verteiltes System zur Erkennung von Spam und basiert auf der Programmiersprache Python. Leute die unerwünschte Mails bekommen, können diese an öffentliche Pyzor Server senden. Wenn dieselbe Mail von mehreren Nutzern als Spam an die Pyzor Datenbank übermittelt wurde wird diese dort gelistet. Bei der Listung in Pyzor wird nicht der Inhalt der Mail gespeichert sondern eine Checksumme der Nachricht. SpamAssassin kann diese Pyzor Datenbank nutzen um zu prüfen ob Nachrichten als Spam gelistet sind und vergibt in diesem Falle Spampunkte.

Als User curus wiederum richten wir pyzor ein

Wenn ein timout kommen sollte nicht gleich erschrecken, pyzor funktioniert bei mir trotz alledem. Alternativ kann man auch die Datei ~/.pyzor/server editieren und einen alternativen Server eintragen 82.94.255.100:24441. Nachzulesen: Bug Track

DCC

Distributed Checksum Clearinghouse ist ähnlich wie Razor und Pyzor ein verteiltes System zur Erkennung von unerwünschten Werbe-Emails, UBE(englisch: unerwünschte bzw. unverlangte Massenmail), UCE (englisch: unerwünschte bzw. unverlangte Werbemail) oder schlicht Spam oder Junk-Mail.

DCC kann man sich von http://www.rhyolite.com/anti-spam/dcc downloaden. Entpacken Sie das Archiv in ein Verzeichnis und installieren Sie durch folgende Befehle:

SASL & TLS/SSL

Ebenso wichtig wie das Einbinden von Filtermechanismen in einen Maildeamon ist das Verhindern, dass man selbst unwissentlich zum Spammer wird. Im Folgenden soll Postfix so abgesichert werden, dass Mails nur mittels einer Authentifizierung via ssl abgeschickt werden können und Mails die er entgegen nimmt, an ein UserKonto z.B. bei unseren Domain – Hoster ausliefert. Hierzu fügen wir in die /etc/postfix/main.cf folgendes ein:

Zu den Optionen im Einzelnen:

Mit smtp(d)_sasl_auth_enable = yes aktivieren wir die Authentifizierung gegen SASL, sowohl ausgehend als auch eingehend. Mit smtp_always_send_ehlo = yes zwingen wir postfix immer ESMTP konform zu senden. Mit smtpd_sasl_security_options = noanonymous verhindern wir anonyme Anmeldungen. Mit broken_sasl_auth_clients = yes erlauben wir älteren Outlook Clients die Anmeldung. Wenn wir unsere Emails ebenfalls über einen Relayhost mit Authentifizierung schicken wollen(unseren Hoster), sind nachfolgende Zeilen notwendig:

Dann muss die Datei /etc/postfix/sasl_passwd mit folgendem Inhalt angelegt werden:

Wobei relayhost.de unser Relayhost ist, über den wir unsere Emails versenden wollen. Danach wird eine neue Map erzeugt:

Der Parameter smtpd_recipient_restrictions wird so abgeändert, dass unser MTA nur SASL authentifizierte Clients und Clients aus Netzen, die in mynetworks deklariert wurden, akzeptiert. Der Rest wird abgewiesen.Als nächstes konfigurieren wir je nach Installation SASL. In den meisten Fällen muss die /etc/postfix/sasl/smtpd.conf mit folgendem Inhalt angelegt werden:

Abschließend Postfix mittels /etc/init.d/postfix force-reload mit der neuen Konfiguration versorgen und das Ganze testen.

User legen wir wie folgt an:

Nachdem wir unserem User ein Passwort verabreicht haben, können wir die SASL Funktion mittels Telnet überprüfen:

gibt uns den Authentifizierungsstring den wir benötigen, wenn wir uns plain authentifizieren wollen. Nun loggen wir uns in unseren MTA:

SASL funktioniert, nun wir können uns der Verschlüsselung zuwenden.

TLS/SSL

Wenn wir bereits SSL – Zertifikate erworben haben, kopieren wir den öffentlichen nach /etc/ssl/certs/$hostname.pem und den privaten Schlüssel nach /etc/ssl/private/$hostname.key. Solche können beispielsweise hier erworben werden: (CaCert) Vom Gebrauch selber erstellter Schlüssel, die nicht gegen eine Zertifizierungsstelle authorisiert sind, rate ich dringend ab. Auch an dieser Stelle setzen wir TLS eingehend und ausgehend ein.

Letztlich starten wir postfix durch und schauen uns die Logfiles an. Wenn alles ordnungsgemäß konfiguriert wurde, nutzt Postfix nun SASL und TLS als Schutzmechanismen vor unauthorisertem Gebrauch.

SPAMTRAINING & AUSWERTUNG

Mit sa-update besteht ein Tool, mit dem wir das Spamassassin Regelwerk anpassen und aktuell halten können. Der Mechanismus ist immer der gleiche, wenn man sich für einen sogenannten Channel entschieden hat, muss man den gpg Schlüssel importieren und dann sa-update mittels

Um den ganzen Prozess zu vereinfachen habe ich mir ein File /etc/spamassassin/sa-update-channels.txt angelegt und in diesem die Channels eingetragen:

damit alles automatisch funktioniert, auch die gpg – Überprüfung muss noch ein Keyfile angelegt werden /etc/spamassassin/keys

Als nächstes können wir uns dann einen Cronjob einrichten, der die Regelfiles aktualisiert:

Spamassassin übernimmt die neuen regeln nur nach einem Neustart. Dieser sollte jedoch nicht durchgeführt werden, bevor man mittels

die Regeln überprüft hat.

SA-LEARN-CYRUS

In unserer /etc/spamassassin/local.conf haben wir mit bayes_path schon eine globale Bayes Datenbank definiert. Der Grundgedanke dahinter ist, jeden User etwaigen SPAM und HAM in einen bestimmten IMAP-Ordner abzulegen und Spamassassin diese regelmässig lernen zu lassen. Hierzu gibt es ein schönes Tool für den Cyrus, welches mitlerweile der Debian Distribution beiliegt: sa-learn-cyrus Das Tool kommt von  http://www.pollux.franken.de/hjb/mail-server/index.html und leistet schon mehrere Jahre bei mir hervorragend seinen Dienst. Ich habe mich entschieden 2 Imapfolder unter Inbox anzulegen einmal sa-spam und sa-ham. dementsprechend muss in der /etc/spamassassin/sa-learn-cyrus.conf folgendes angepasst werden:

Damit wir keine Berechtigungsprobleme bekommen, folgende Werte noch wie unten beschrieben anpassen:

Mit folgenden Cronjob wird dann automatisch alles eingesammelt:

SA-STATS

Sa-stats ist ein Log-Datei-Analysator,  der Statistiken über die Spam-und Ham-Einträge durch die Analyse der Einträge in einer Log-Datei von pamassassin generiert. Es können Statistiken für eine gesamte Log-Datei bestimmte User, Zeiten oder Domains abgerufen werden.  Die Webseite und den Download findet Ihr hier: Mirror1 Mirror2. Ein Hinweis sa-stats funktioniert bei mir nur korrekt, wenn ich mich in dem Verzeichnis des Logfiles, in unserem Szeanrio /var/log/spamlog, befindet.

CACTI

Als nächstes soll es uns darum gehen Cacti an den Start zu bringen. Cacti soll uns den Überblick über unser Filteraufkommen zeigen. Ich setze dabei eine funktionierende Postfix, Amavis und Spamassassin Installation vorraus, sowie einen funktionierenden Apache und MySQL Datenbank.

Als nächstes richten wir den SNMP Deamon so ein, dass nur lokale Zugriffe erlaubt sind. In /etc/snmp/snmpd.conf ändern wir die Zeile

in

Des weiteren fügen wir unter dem Abschnitt „System contact information“ ein paar Daten ein.

Damit der snmpd nur auf 127.0.0.1 läuft tragen wir noch

in die /etc/snmp/snmpd.conf nach. Danach wird noch in der folgenden Datei /etc/default/snmpd die Zeile „SNMPDOPTS“ durch den Parameter „udp:127.0.0.1:161“ ergänzt. Der snmpd soll schließlich auch nur auf der lokalen IP lauschen.

Damit sollte die Konfiguration des snmpd abgeschlossen sein. Jetzt nur noch schnell ein Neustart zum übernehmen der Änderungen. Zum Schluß können wir das ganze auch schnell mal Testen. Das folgende Kommando sollte diverse Informationen über das System liefern.

Als nächstes kommen wir zur Installation von Cacti.

Am besten legen wir vorher schon die Datenbank und einen Datenbank Benutzer für Cacti an. (MySQL) Der Datenbanknutzer sollte für die spätere Überwachung von mysql mit dem globalen Recht „PROCESS“ angelegt werden. Bitte Datenbankname, Datenbankuser und Password in die gewünschten Werte ändern.

CREATE DATABASE datenbankname;

GRANT PROCESS ON *.* TO ‚datenbankuser’@’localhost‘ IDENTIFIED BY ‚Password‘;

GRANT SELECT , INSERT , UPDATE , DELETE , CREATE , DROP , INDEX , ALTER ON datenbankname . * TO ‚datenbankuser’@’localhost‘;

FLUSH PRIVILEGES;

Einfach Cacti und gleich auch Cactid per apt-get installieren.

apt-get install cacti cactid

Dem Installer geben wir wahrheitsgemäß Auskunft und nach erflogreicher Installation spielen wir die Datenbank ein:

zcat /usr/share/doc/cacti/cacti.sql.gz | mysql -u datenbankuser -p datenbankname

Nun können wir das ganze unter http://hostname/cacti/ bestaunen. Benutzer und Passwort für das erste einloggen ist jeweils „admin“. Nach dem ersten Einloggen, werden wir sofort aufgefordert dies zu ändern.Zum Schluss aktibieren wir noch cactid, da dieser wesentlich performanter läuft. Um cactid zu aktivieren sollte man unter den „Settings“ unter dem Reiter „Paths“ den Pfad zu cactid anpassen… unter Debian /usr/sbin/cactid. Danach unter dem Reiter „Poller“ den „Poller Type“ auf „cactid“ umstellen.

Als nächstes besorgen wir uns von http://forums.cacti.net/download.php?id=4091 das Mailstatistik Paket und installieren dieses wie vorgegeben. Als erstes fügen wir folgende Zeile in die /etc/snmp/snmpd.conf ein:

Hierbei bitte aufpassen, dass der User unter dem der SNMP Deamon läuft auch die Leserechte für /var/log/mail.log und Schreibrechte für /var/log/mailstats.db besitzt und die Pfade korrekt angepasst wurden. Eine einfache aber auch sicherheitstechnisch bedenkliche Methode ist, den snmpd unter root zu starten mittels der Angabe „-u root“ in der /etc/default/snmpd.

Nachdem wir SNMP neugestartet haben, prüfen wir mittels

snmpwalk -v 2c -c public localhost .1.3.6.1.4.1.2021.255

ob unsere Konfiguration erfolgreich übernommen wurde. Parallel dazu können wir auch händisch versuchen ob alles korrekt eingerichtet wurde. Unter dem User snmp starten wir dazu das fetch_mail script wie folgt

./fetch_mail_statistics.pl /var/log/mail.log /var/log/mailstats.db .1.3.6.1.4.1.2021.255 -g .1.3.6.1.4.1.2021.255.1

Wenn alles korrekt läuft, sollte das Script eine ähnliche Ausgabe erzeugen:

.1.3.6.1.4.1.2021.255.2

integer

0

Im falle, dass uns

UCD-SNMP-MIB::ucdavis.255 = No Such Instance currently exists at this OID

filter
filter
transport
transport

angezeigt wird, liegt dies wahrscheinlich darin, dass die Scripte keine ausreichenden Rechte haben. Nun importieren wir in Cacti das xml Template und richten die Graphen ein. Entsprechende Ergebnisse sollten so oder so ähnlich aussehen: