Installation und Konfiguration eines kompletten Mailservers basierend auf
RedHat Linux / Fedora Core mit Hilfe von postfix, amavisd-new,
Spamassassin, OpenAntivirus / ClamAV, uw-IMAP, Squirrelmail
Copyright © 2006 by Stefan Bielenberg
E-Mail: stefan(dot)bielenberg(at)web(dot)de
Revision: Feb 03, 2009
`"
Contents
1 Geschichte machen
2 Überblick behalten
3 Disk-Jockey spielen
3.1 Vorbereitungen
3.2 Installation von RedHat oder Fedora Core
3.3 Austauschen des Mailservers und Test
4 Zur Post gehen
4.1 Postfix als Standalone Mailserver
4.1.1 Die Datei aliases
4.1.2 Die Datei local_domains
4.1.3 Die Datei transport
4.1.4 Die Datei virtual
4.2 Postfix als Relaying Mailserver
4.3 Postfix mit Smarthost und AUTH
5 Zum (An)Schlag ausholen
5.1 Installation von SpamAssassin
5.2 Konfiguration von SpamAssassin
6 Feinde entdecken
6.1 Installation von amavis-new
6.2 Konfiguration von amavis-new
7 Gegenma ßnamen einleiten
7.1 ClamAV installieren
7.2 ClamAV konfigurieren
7.3 ClamAV in Amavisd-new aktivieren
7.4 OpenAntivirus installieren
7.5 OpenAntivirus konfigurieren
7.6 OpenAntivirus in Amavisd-new aktivieren
7.7 Alles testen
8 Wer da?
8.1 Installation und Konfiguration von SMTP-Auth
9 Sicher befördern
9.1 Anlegen von Server-Zertifikaten
9.1.1 Die eigene CA sein
9.1.2 Server-Zertifikate erstellen
9.1.3 Letzte Schritte
9.2 Konfiguration von TLS/SSL
9.3 Nochmal alles Testen
10 Zu Diensten sein
10.1 Installation von POP3, POP3S, IMAP und IMAPS
10.2 Konfiguration von POP3, POP3S, IMAP und IMAPS
10.3 Noch sicherer mit IMAP und CRAM-MD5
11 Reinlassen
11.1 Installation und Konfiguration von Squirrelmail
11.2 Hinzufügen von Plugins
A Aussperren
A.1 Hinweise für die Sicherung mit einer Firewall
B Zwei auf einen Streich - Mail-Logging
C Ein FTP Server mit VSFTPD
D Zeitsynchronisation mit NTP
E Nachlesen
E.1 Antivirus
E.2 Amavis / Scanner
E.3 Postfix
E.4 TLS/SSL
E.5 SMTP-AUTH
E.6 SpamAssassin
E.7 Sonstige
1 Geschichte machen
Ich habe diese Dokumentation geschrieben, nicht weil sie völlig
neue Erkenntnisse vermitteln soll, sondern weil sie eine
Zusammenfassung aller von mir gefundenen und genutzten
Dokumentationen über das Erstellen von Mailserver, die im Internet
zu finden sind, darstellen soll. Und es gibt viele dieser
Dokumentationen, allerdings keine, die alle diese Programme
zusammenfasst und miteinander zu einem Produkt/Paket verbindet.
Daher Dank an alle, die wissend oder unwissend zu diesem Dokument
beigetragen haben. Auf diesem Wege auch an Ralf Spenneberg, dessen
Artikel [1] diesem Dokument als Vorlage diente.
2 Überblick behalten
Dieses Dokument beschreibt die Installation eines kompletten
Mailservers bestehend aus folgenden Komponenten:
- Betriebssystem: RedHat oder Fedora Core
- MTA: Postfix (mit SMTP-Auth und TLS/SSL)
- Filter: Amavisd-new
- AntiSpam: Spamassassin
- AntiVirus: ClamAV und OpenAntivirus
- POP/IMAP: uw-IMAP (IMAPS, POP3S)
- Webmailer: Squirrelmail
- Mail-Logging: Mailgraph
- und vieles andere mehr...
3 Disk-Jockey spielen
3.1 Vorbereitungen
Da Du einen Mailserver installieren willst, solltest Du folgende
Partitionsstruktur beachten:
- / 500 MB
- /usr 2000 MB
- /tmp 500 MB
- /home 2000 MB
- swap 500 MB
- /var Rest
Wobei der Platz, den /var benötigt ausreichend groß gewählt werden
sollte.
3.2 Installation von RedHat oder Fedora Core
Bei der Installation halte Dich vor allem an die Richtlinien im
Installationshandbuch. Wenn Du noch keine Software hast, dann gehe
zu z.B. ftp://ftp.redhat.com/pub/redhat/linux/9/en/iso/i386/ (für
RedHat 9.0) oder zu z.B.
ftp://tux.cprm.net/pub/ftp.redhat.com/fedora/linux/core/1/i386/iso/
(für Fedora Core 1) und lade Dir die ISO-Packages herunter. Eine
Installationsanleitung findest Du bestimmt unter
http://www.redhat.com.
Installiere mit der Distribution auch gleich folgende Software von
den CD's mit:
- Postfix
- Spamassassin
- uw-IMAP
- Squirrelmail
Wenn Du das vergessen solltest, dann kannst Du diese Programme ja
jederzeit mit dem Befehl
# rpm -U -v dateiname.rpm
von der CD nachinstallieren. Ich werde später an den
entsprechenden Stellen noch einmal speziell darauf hinweisen was
zu installieren ist.
3.3 Austauschen des Mailservers und Test
Seit Version 7.3 liefert RedHat alle Distributionen immer mit zwei
Mailservern aus: postfix und sendmail. Da nur immer ein Programm
am Port 25 horchen kann ist (wohl aus historischen Gründen immer)
sendmail als Standard-Mailserver konfiguriert. Um zu überprüfen,
welches Programm zur Zeit installiert ist, tippst Du:
# alternatives --display mta
mta - status is auto.
link currently points to /usr/sbin/sendmail.sendmail
/usr/sbin/sendmail.sendmail - priority 90 slave mta-mailq:
/usr/bin/mailq.sendmail slave mta-newaliases:
/usr/bin/newaliases.sendmail slave mta-rmail:
/usr/bin/rmail.sendmail slave mta-mailqman:
/usr/share/man/man1/mailq.sendmail.1.gz slave mta-newaliasesman:
/usr/share/man/man1/newaliases.sendmail.1.gz slave mta-aliasesman:
/usr/share/man/man5/aliases.sendmail.5.gz
/usr/sbin/sendmail.postifx - priority 30 slave mta-mailq:
/usr/bin/mailq.postfix slave mta-newaliases:
/usr/bin/newaliases.postfix slave mta-rmail:
/usr/bin/rmail.postfix slave mta-mailqman:
/usr/share/man/man1/mailq.postfix.1.gz slave mta-newaliasesman:
/usr/share/man/man1/newaliases.postfix.1.gz slave mta-aliasesman:
/usr/share/man/man5/aliases.postfix.5.gz Current "best" version is
/usr/sbin/sendmail.sendmail.
Um den MTA von sendmail auf postfix zu ändern tippst Du weiterhin:
# alternatives --config mta
There are 2 programs which provide "mta".
Selection Command
-----------------------------------------
*+ 1 /usr/sbin/sendmail.sendmail
2 /usr/sbin/sendmail.postfix
Enter to keep the default[*], or type selection number: 2
Dieses Kommando richtet postfix als Mailserver auf Deinem System
ein, erstellt die entsprechenden Bootdateien und erzeugt ebenfalls
eine Konfiguration mit der man schon vorzüglich arbeiten kann.
Nun solltest Du das System neu booten um ganz sicher zu stellen,
dass alle Prozesse korrekt gestartet sind. Achte auch auf folgende
Zeile beim Booten:
# service postfix status
master (pid 9864) is running
Wenn Du gebootet hast, dann können wir schon mal den Mailserver
testen. Dazu machen wir ein telnet auf Port 25:
# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 station.example.com ESMTP Postfix
quit
221 Bye
Connection closed by foreign host.
Wenn der Mailserver antwortet, dann hast Du schon den ersten
Schritt geschafft, gehe weiter auf LOS und ziehe 4000 ein...
4 Zur Post gehen
Wie alle Mailserver kann auch postfix auf zwei verschiedene Arten
installiert werden. Entweder als Standalone-MTA, der die Email
annimmt und ins Internet verteilt oder als Relaying MTA, der die
Email entgegennimmt und an einen richtigen Mailserver
weiterleitet.
4.1 Postfix als Standalone Mailserver
Ein Standalone Mailserver sendet und empfängt Email selber. Das
bedeutet aber auch, dass er nötigenfalls eine FQDN benötigt, da es
sonst manche Mailserver ablehnen von ihm Email zu empfangen. Es
ist recht einfach eine Konfiguration dafür zu erstellen. Du
benötigst einfach folgende Einstellungen in Deiner
/etc/postfix/main.cf:
# all information mail goes to postmaster
soft_bounce = no
# tell the postmaster about mail problems
# notify_classes = resource, software, bounce, policy
notify_classes = resource, software, policy
# zum Testen Code 450 (später erneut versuchen) einstellen
# wenn alles getestet, dann umstellen auf Code 550 (ablehnen)
# unknown_local_recipient_reject_code = 550
unknown_local_recipient_reject_code = 450
# Queue directory and chroot
queue_directory = /var/spool/postfix
# Location of the post* commands
command_directory = /usr/sbin
# Location of the postfix daemon commands
daemon_directory = /usr/libexec/postfix
# Privileges
mail_owner = postfix
# FQDN of the mailserver
myhostname=host.example.com
# Domain to serve
mydomain=example.com
# Domain to masquerade as
myorigin=$mydomain
# ip addresses to listen on
inet_interfaces = all
# Names to receive email for
mydestination=$mydomain $myhostname localhost localhost.$mydomain
######### to separate domains ###########
# Virt domain names to receive email for (all users here have to defined in virtual_alias_maps,
# if not they are rejected!!!)
virtual_alias_domains = /etc/postfix/local_domains
# define all users for domains in virtual_alias_domains (if not the are rejected!!!)
virtual_alias_maps = hash:/etc/postfix/virtual
#########################################
# ip addresses to relay emails for
mynetworks=192.168.0.0/24, 127.0.0.0/8
# show mailserver name for all
smtpd_banner = $myhostname ESMTP $mail_name
# tell the postmaster about mail problems
notify_classes = resource, software, policy
# IF a relayhost is used for the connection
# to the internet
# relayhost=[$mail.myprovider]
# how to restrict the delivery of the email
smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains, reject_unauth_destination
# Aliases database
alias_database = hash:/etc/postfix/aliases
# if we have more then one domain
virtual_maps = hash:/etc/postfix/virtual
# if we want to change the way of transport
transport_maps = hash:/etc/postfix/transport
# if dns resolution is not permanently available
# disable_dns_lookups=yes
Die Konfiguration in /etc/postfix/master.cf musst Du in
diesem Schritt noch nicht verändern. Sie sieht bis jetzt noch
folgendermaßen aus:
#=====================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
#=====================================================================
smtp inet n - y - - smtpd
#smtps inet n - y - - smtpd \
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission inet n - y - - smtpd \
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628 inet n - n - - qmqpd
pickup fifo n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
#qmgr fifo n - y 300 1 qmgr
qmgr fifo n - y 300 1 nqmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
flush unix n - y 1000? 0 flush
smtp unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
Weitere Informationen findet man in [2] oder in [3].
4.1.1 Die Datei aliases
In dieser Datei stehen alle Benutzernamen und ihre Aliases für die
Suche nach lokalen Benutzern. Ein paar Beispiele:
# ein lokaler Benutzer mit verschieden Mail-Adressen
heinz.mustermann: heinz
hmustermann: heinz
heinzilein: heinz
hm: heinz
# eine lokale Mailing Liste
info: meier, mueller, schmidt, lehmann
# eine lokale Mailing Liste mit externen Mailempfängern
info_all: meier, mueller, schmidt, lehmann, stefan@ibm.de, koch@siemens.de
4.1.2 Die Datei local_domains
In dieser Datei stehen alle virtuellen Domainen, für die Mails angenommen
werden sollen. Die locale Domain muß hier nicht rein, denn wir haben sie
ja schon in mydomain in der main.cf eingetragen. Sie ist die einzige
reale Domain.
Ein paar Beispiele:
example.de
test.de
test-test.com
killer.org
4.1.3 Die Datei transport
Sollen Mails für einige Domains oder User speziell
weitergeleitet werden, dann stehen hier die Regeln dafür. Ein
paar Beispiele:
# Zustellung von eMail erfolgt normal
telmecsa.com local:
# Weiterleitung auf anderen Mailserver
teletext.de smpt:mail.example2.de
4.1.4 Die Datei virtual
In dieser Datei stehen die virtuellen Aliases/Maps von existierenden lokalen Benutzern.
Im Gegensatz zu aliases können hier auch Domains zu den Usernamen geschrieben werden.
User, die hier nicht definiert sind, existieren nicht und Ihre eMail werden nicht angenommen. Daher muß
für jeden existierenden internen Benutzer hier eine eMail-Adresse zugeordnet werden
Ein paar Beispiele:
# hier ein normaler Eintrag für eine Domain mit einem realen User,
# aber mit verschiedenen virtuellen eMail-Namen. Somit kommen alle
# Mails an "meier" an, egal wie man ihn schreibt
bieli.de anything
postmaster@example1.de postmaster
meier@example1.de meier
maier@example1.de meier
meyer@example1.de meier
mayer@example1.de meier
# hier ein Beispiel, wie an alle virtuellen Benutzer einer Domain
# in eine andere holen kann, ohne alles extra noch mal zu schreiben:
@example1.de @example1.com
# Beispiel für ein Catch-All: nimme alle eMails an diese Domain an
# und weise sie dem User "test" zu
@example4.com test
# Umleitung von einer virtuellen externen Domain, die lokal nicht
# existiert auf einen lokalen User. So kann man gut mehrere
# gleiche Mail-Namen benutzen und auf andere interne Umlenken
import@example1.es import_example1
export@example1.es export_example1
import@example2.com import_example2
export@example2.com export_example2
import@example3.com import_example3
export@example3.com export_example3
4.2 Postfix als Relaying Mailserver
Wenn postfix als Relaying Mailserver eingerichtet werden soll,
bedeutet das, dass die ankommenden Emails an einen offiziellen
Haupt-Mailserver weitergereicht werden, der diese dann ausliefert.
Ein Beispiel dafür ist ein Abteilungs-Mailserver, der nur für die
Emails einer speziellen Abteilung zuständig ist, sonst aber nicht
öffentlich auftritt oder von anderen Abteilungen Emails übernimmt.
Soll der MTA als Relay arbeiten, dann müssen einige Optionen
anders eingestellt werden; ansonsten bleiben die Einstellungen, so
wie in Kapitel 4.1.
Die geänderten Zeilen von /etc/postfix/main.cf sehen wie folgt aus:
# Internal Mailserver (IP address)
internal_mail = x.x.x.x
# ip addresses to relay emails for
mynetworks=$internal_mail, 127.0.0.0/8
# how to restrict the delivery of the email
smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains, reject_unauth_destination
# if a relayhost is used for the connection
# to the internet
# relayhost=[$mail.myprovider]
Änderungen an der /etc/postfix/master.cf sind auch bei
dieser Konfiguration nicht notwendig, allerdings benötigt man bei
den meisten Relay-MTAs auch keinen lokalen Auslieferungsservice,
daher folgende Konfiguration:
#=====================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
#=====================================================================
smtp inet n - y - - smtpd
#smtps inet n - y - - smtpd \
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission inet n - y - - smtpd \
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628 inet n - n - - qmqpd
pickup fifo n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
#qmgr fifo n - y 300 1 qmgr
qmgr fifo n - y 300 1 nqmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
flush unix n - y 1000? 0 flush
smtp unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
#local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
Weiterhin benötigt diese Konfiguration Eintragungen in der Datei
/etc/postfix/transport, welche die Methoden der Auslieferung
an interne Mailserver enthält. Diese Datei sollte folgendes
enthalten:
example.com smtp:[ip_internal_mail]
Um die Änderungen daran festzuschreiben und zu aktivieren tippe:
# postmap /etc/postfix/transport
Weitere Informationen findet man in [2] oder in [3].
4.3 Postfix mit Smarthost und AUTH
Manchmal ist es aus einigen Gründen nicht möglich selbst eMails an
andere Mailserver auszuliefern, bzw. diese nehmen keine Mails von
unserem Server entgegen. Günde dafür könnten sein:
- der Mailserver besitzt keinen gültigen MX-Eintrag im
DNS
- der Mailserver besitzt eine dynamische IP-Adresse
- der Mailserver besitzt eine statische IP-Adresse, aber
aus einem Pool von dynamischen IP-Adressen
- der Mailserver ist aus irgendeinem Grund auf eine
Blacklist gelandet
- der Mailserver hat keinen Reverse-DNS Eintrag beim
Provider
Dann ist es sinnvoll einen sogenannten Smarthost zu benutzten. Das
sind Mailserver (meist vom eigenen Provider), die von unserem
Server Mails zur Auslieferung an andere Mailserver entgegennehmen.
Damit geben wir zwar die Verantwortung für die Zustellung von
Mails an einen anderen Server ab, aber das kann in manchen Fällen
die einzige Lösung zu Auslieferung von Mails an bestimmte andere
Server sein.
Manchmal ist der Smarthost so gut konfiguriert, dass er
automatisch erkennt wer bei ihm seine Mails abliefern darf. Z.B.
erkennt manchmal der Mail-Relay eines Providers, welche Rechner
(welche IP-Adressen) zu seinem Netzwerk gehören und lässt ein
Relay zu. In diesem Fall reicht die Aktivierung der folgenden
Zeile in der /etc/postfix/main.cf:
relayhost=[smtp.myprovider.de]
Meistens erlauben diese Smarthost aber nur ein Relay per
Authentifizierung. Dann muß die /etc/postfix/main.cf um
folgende Zeilen ergänzt werden:
relayhost = smtp.myprovider.de
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_always_send_ehlo = yes
smtp_sasl_security_options = noanonymous
Um die SASL-Authentifizierung zu aktivieren ist es nötig weitere
Software-Pakete zu installieren. Welche und wie, dass wird in
Kapitel 8.1 genauer erklärt.
In der Datei /etc/postfix/sasl_passwd werden die Passwörter
für die Authentifizierung wie folgt abgelegt:
smtp.myprovider.de benutzername:passwort
Danach ist noch ein postmap /etc/postfix/sasl_passwd
Einlesen der Konfiguration des Services mit service postfix reload
notwendig. Das wars.
5 Zum (An)Schlag ausholen
SpamAssassin (kurz SA) ist ein Mail-Filter, welcher versucht,
SPAM1 (also unerwünschte Werbemails) als
solchen zu erkennen und markieren. SA sucht mit Hilfe von Regeln
nach Mustern, welche in Werbemails auftreten. Insbesondere werden
dazu der Mailbody, also der eigentliche Text der Mail, sowie die
Anhänge (Attachments) untersucht. Spamassassin bewertet dabei die
eingehende Mail aufgrund zahlreicher Bedingungen und vergibt als
Ergebnis einen Zahlenwert, den 'Spam-Level'. Dieser Wert liegt
nahe bei Null, wenn der Brief (wahrscheinlich) Spam-frei ist, er
kann aber je nach Umfang der Mail beliebig groß sein. Erfahrungen
haben gezeigt, dass ein Spam-Level größer als 6 bereits ein
zuverlässiger Indikator für Spam darstellt. Der eigentliche Text
der Mail wird nicht abgeändert und keine Mail ohne Zutun des
Benutzers wird gelöscht.
Der Benutzer hat nun zwei Möglichkeiten, auf Grund dieses
Spam-Levels Maßnahmen zu ergreifen:
Er kann entweder diesen Wert mit Hilfe seines Mail-Programms
selbst auswerten und bestimmen, ab welchem Spam-Level er
eingehende Email z.B. in einem separaten Ordner ablegt, indem er
in seinem Mail-Programm einen passenden Filter definiert. (Diese
Möglichkeiten haben alle Benutzer, allerdings gibt es
Einschränkungen bei den Mail-Programmen.) Oder er bedient sich des
speziellen Filterprogrammes procmail, das es auch erlaubt,
aussortierte Mail ungelesen zu löschen. Im Gegensatz zu der
anderen Möglichkeit werden so SPAM-Mails erst gar nicht
heruntergeladen, wenn man per POP3 oder IMAP seine Emails lesen
möchte.
5.1 Installation von SpamAssassin
Seit RedHat 8.0 ist SpamAssassin in der Distribution enthalten und
kann so einfach mitinstalliert werden. Ebenfalls werden folgende
Pakete benötigt und müssen mitinstalliert werden:
- perl-Digest-SHA1-x.xx-x.i386.rpm
- perl-Digest-HMAC-x.xx-x.noarch.rpm
- perl-Net-DNS-x.xx-x.noarch.rpm
- spamassassin-x.xx-x.i386.rpm
- OpenSSL Liberies (*.o.2 und *.o.4)
Installiere die genannten Pakete entweder bei der Installation,
nachträglich von den CD's:
# rpm -U -v <Dateiname>.rpm
oder wenn Du beim RedHat/Fedora-Netzwerk angemeldet bist mit:
# yum install <Programmname>
ACHTUNG: bei der Installation von OpenSSL gibt es bei älteren
Version von Redhat oder Fedora einiges zu beachten.
SpamAssassion benötigt die neueste Version von OpenSSL und
OpenSSL-devel (zur Zeit 0.9.7a), allerdings brauchen andere
Programme auf dem Computer immer noch die ältere Version 0.9.6. Um
beide Bibliotheken vorrätig zu halten empfehle ich erst Version
0.9.6 zu installieren, dann in das Verzeichnis /lib zu
wechseln und dort einen Link auf die Bibliotheken zu setzen (wenn
es nicht schon automatisch erledigt wurde):
# ln -s /lib/libssl.0.9.6 /lib/libssl.o.2
# ln -s /lib/libcrypto.0.9.6 /lib/libcrypto.o.2
Danach bitte OpenSSL Version 0.9.7a (vielleicht gibt es schon
neuere Versionen?) installieren und das ganze wiederholen:
# ln -s /lib/libssl.0.9.7a /lib/libssl.o.4
# ln -s /lib/libcrypto.0.9.7a /lib/libcrypto.o.4
5.2 Konfiguration von SpamAssassin
In unserer Installation wird SpamAssassin direkt von amavis-new
als Filter aufgerufen, daher sind weitere Konfigurationen nicht
notwendig. Später kann man gegebenenfalls noch die Datei
/etc/amavisd.conf anpassen, denn dort gibt es auch noch
einige Einstellungen zu SpamAssassin.
SpamAssassin ist schon sehr gut vorkonfiguriert, möchte man
trotzdem noch Änderungen vornehmen, dann kann man das in
/etc/mail/spamassassin tun. In local.cf z.B. mit den
Befehlen:
whitelist_from @guteDomain.com
whitelist_from heinz@andereGuteDomain.de
blacklist_from @boeseDomain.com
blacklist_from teufel@andereBoeseDomain.de
Wenn man mit den Optionen von SpamAssassin nicht vertraut ist kann
man sich unter http://www.yrex.com/spam/spamconfig.php auch
eine Konfiguration automatisch erstellen lassen und diese Datei
als local.cf abspeichern. Ebenso kann man sich auch als User
dort seine persönliche Konfigurations-Datei erstellen und diese
als user.prefs in seinem Home-Verzeichnis in
/home/<user>/.spamassassin abspeichern. Diese überschreibt
dann die Einstellungen, die in der globalen local.cf gemacht
wurden.
ACHTUNG: sollte der Zugriff auf die persönlichen
SpamAssassin-Konfigurationsdateien in
/home/<user>/.spamassassin nicht funktionieren, dann am
Besten das Verzeichnis löschen und neu anlegen. Die
user.prefs sollte man sich natürlich aufgehoben haben. Neue
Hash-Dateien für die persönlich angepasste Spam-Suche kann man
jederzeit aus einzelnen oder gesammelten Spam-Mails erstellen, die
doch noch in der persönlichen Mailbox gelandet sind. Kommandos
kombiniert aus:
sa-learn [--ham|--spam] [--file|--mbox] spam.[mail|mbox]
erledigen das für Dich.
Ich persönlich sammle Spam der durchkommen konnte in einer MBOX
namens doch.junk und Junk, der keiner ist in einer Datei
kein.junk. Ab und zu rufe ich dann meine eigene
'Learn'-Datei auf und beim nächsten Mal landen dann auch diese
Mails an der richtigen Stelle:
echo
echo "Lerne spam: doch.junk ..."
sa-learn --spam --mbox Mail/doch.junk --showdots
echo
echo "Lerne ham: kein.junk ..."
sa-learn --ham --mbox Mail/kein.junk --showdots
echo
echo "Fertig!"
6 Feinde entdecken
Amavis (Kurzform für A Mail Virus Scanner) selber ist kein
Virenscanner, sondern nur ein Aufsatz für einen Mailserver, der
die meist kommandozeilenbasierten Linux-Virenscanner benutzen
kann. Amavis nimmt dabei die E-Mail vom MTA entgegen, extrahiert
die zu überprüfenden Daten und wendet beliebige Virenscanner
darauf an. Meldet einer dieser Virenscanner eine Infektion, stoppt
Amavis die Auslieferung der Mail und versendet stattdessen eine
entsprechende Warnmeldung.
In der neuesten Version (die wir benutzen werden) arbeitet Amavis
als Daemon und SpamAssassin wurde ebenfalls integriert. Es bringt
also nichts, wenn auf dem selben Rechner auch noch Spamassassin
als Daemon läuft. Wir testen das mit:
# service spamassassin status
und
# chkconfig --list | grep spamassassin
Wenn der Daemon läuft, bzw. wenn dort 3:Aus steht
(unterer Befehl), können wir Ihn mit folgenden Befehlen
ausschalten und deaktivieren:
# service spamassassin stop
und
# chkconfig --level 3 spamassassin off
6.1 Installation von amavis-new
Leider ist z.Z. Amavis-new noch kein Bestandteil von RedHat oder
Fedora, daher muss das Programm von Hand installiert werden. Die
Arbeit kann man sich erleichtern, wenn man die entsprechenden
RPM's zur Hand hat. Außerdem benötigt Amavis noch einige weitere
Perl-Pakete und Archivierungsprogramme, wie z.B. zoo, arc und rar.
Die RPM-Pakete für die Installation von Amavis-new kannst man bei
Dag Wieers unter http://dag.wieers.com/packages/amavisd-new/
finden. Um stets aktuell zu sein, kann man Dags Repositories auch
in yum oder up2date einbinden. Weiter Infos dazu
findet man auch auf den Webseiten von Dag.
Weitere benötigte Pakete kann man von den RedHat/Fedora-CDs
installieren oder man findet sie auch bei Dag Wieers:
- perl-Archive-Tar
- perl-Compress-Zlib
- perl-TimeDate
- ncompress
- unarj
Alle RPM-Pakete installiert man mit:
# rpm -U -v dateiname.rpm
oder mit:
# rpm -U -v *.rpm
Nach der Installation sollte man überprüfen, ob in
/etc/passwd nun ein Benutzer amavis vorhanden ist und in
url/etc/mail/aliases die Email-Aliase 'virusalert', 'postfix'
und 'spampolice' angelegt wurden.
Editiere ebenfalls die Datei /etc/postfix/aliases oder
/etc/mail/aliases (sollte ein Link sein) und ändere alle
Aliase, die Emails nach root senden so, dass sie sie danach nach
'postfix' schicken.
Amavis unterstützt nun die folgenden Virenscanner, darunter auch
den OpenAntivirus und den ClamAV, die wir später versuchsweise
installieren wollen. Für einen Produktionsserver empfehle ich
allerdings immer noch einen der anderen, kommerziellen
Virenscanner. Ich persönlich habe gute Erfahrungen mit Panda
Antivirus machen können
(http://www.pandasoftware.com/download/linux/linux.asp). Die
Kommandozeilenversion ist Freeware und eine ältere Version der
Signaturdatei ist auch mit dabei. Allerdings sollte man diese so
bald wie möglich durch eine neue ersetzen. Bei mir beendeten sich
allerdings Linux-Versionen kleiner als 7.x mit einem SIGINT.
- Network Associates Virus Scan
- DrSolomon (obsolete)
- H+BEDV AntiVir/X
- Sophos Sweep
- Kaspersky Lab AntiViral Toolkit Pro (AVP)
- CyberSoft VFind
- Trend Micro FileScanner
- CAI InoculateIT
- F-Secure Inc. (former DataFellows) F-Secure AV
- Panda Soft Antivirus (pavcl)
- OpenAntivirus
- ClamAV bzw. Clamd
6.2 Konfiguration von amavis-new
Nach der Installation von Amavis ist es nun notwendig diesen zur
Zusammenarbeit mit postfix zu konfigurieren. Dazu sind einige
Änderungen in der /etc/postfix/master.cf erforderlich.
Füge folgende Zeilen ein und beachte bitte: keine Leerzeichen bei
den Optionsanweisungen (bei Gleichheitszeichen, oder Kommata)
verwenden!
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o myhostname=mail.test.de
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
Der erste Teil fügt einen zusätzlichen SMTP-Listener auf Port
10025 hinzu. Dieser Daemon wird von Amavis dazu genutzt die
gescannten Email wieder an den MTA zurückzugeben.
Nun füge folgende Zeile in die Datei /etc/postfix/main.cf ein:
content_filter = smtp-amavis:[127.0.0.1]:10024
Mit diesem Befehl wird 'postfix' angewiesen alle Emails für das
Filtern am Amavis auf localhost auf Port 10024 zu schicken. Dort
werden die Emails bearbeitet und über Port 10025 (siehe oben)
wieder zurück an 'postfix' gesendet.
Bitte jetzt die Datei /etc/amavisd.conf öffnen und die
Zeilen suchen in denen steht:
$mydomain = 'mail.domain.com';
$daemon_user = 'sweep';
$daemon_group = 'sweep';
@local_domains_acl = ( ".$mydomain" );
$log_level = 0;
$final_virus_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
$final_spam_destiny = D_DISCARD;
$final_bad_header_destiny = D_PASS;
$warnvirussender = 1;
$warnspamsender = 1;
$warnbannedsender = 1;
$warnbadsender = 1;
$warnvirusrecip = 1;
$warnbannedrecip = 1;
$mailfrom_notify_admin = "virusalert\@$mydomain";
$mailfrom_notify_recip = "virusalert\@$mydomain";
$mailfrom_notify_spamadmin = "spam.police\@$mydomain";
Diese Zeilen nun ersetzen durch:
$mydomain = 'mymail.mydomain.com';
$daemon_user = 'amavis';
$daemon_group = 'amavis';
# Die Prüfungen sollen für alle von Postfix verwalteten
# Domains und Subdomains durchgeführt werden
@local_domains_maps = ( [".$mydomain", "localhost"], read_hash("/etc/postfix/local_domains") );
$log_level = 2;
# Hat heutzutage sowieso kein Zweck mehr den Sender
# der Virenmail zu informieren, durch die falschen Absenderadressen.
$final_virus_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
# Ebenso bei Spam
$final_spam_destiny = D_DISCARD;
$final_bad_header_destiny = D_PASS;
# Notify virus sender? Bloß nicht!
$warnvirussender = 0; # (defaults to false (undef))
# Notify spam sender? Bloß nicht!
$warnspamsender = 0; # (defaults to false (undef))
# Notify sender of banned files? Kann man machen.
$warnbannedsender = 1; # (defaults to false (undef))
# Notify sender of syntactically invalid header containing non-ASCII characters? Bloß nicht!
$warnbadsender = 0; # (defaults to false (undef))
# Notify virus (or banned files) RECIPIENT? Wie man möchte, ich finde es sinnvoll.
$warnvirusrecip = 1; # (defaults to false (undef))
$warnbannedrecip = 1; # (defaults to false (undef))
$warnbadhrecip = 1; # (defaults to false (undef))
$mailfrom_notify_admin = "virusalert\@$mydomain";
$mailfrom_notify_recip = "virusalert\@$mydomain";
$mailfrom_notify_spamadmin = "spampolice\@$mydomain";
Folgende Einstellungen für Spamassassin (in der
/etc/amavis.conf) habe ich bei mir ausprobiert, aktiviert
und halte sie für sinnvoll:
$sa_tag_level_deflt = -999; # zeige Spam-Infos im Mail-Header immer an
$sa_tag2_level_deflt = 5.00; # markiere als Spam
$sa_kill_level_deflt = 15.00; # erweiterte Aktion (delete)
$sa_spam_subject_tag = '***SPAM*** ';
Damit Amavis schon beim Systemstart automatisch mitgestartet wird,
müssen wir noch folgenden Befehl ausführen, wenn es nicht schon
bei der Installation (rpm) durchgeführt wurde:
# chkconfig --level 3 amavisd on
Dann starten wir den 'amavisd'-Daemon mal im Debug-Modus, um zu
testen, ob alles richtig installiert und konfigueriert wurde:
# service amavisd debug
Mit Control-C brechen wir den Testlauf ab. Jetzt fehlen nur noch
ein paar Eintragungen in der Datei /etc/amavisd.conf und wir
sind erst einmal fertig. Vorher müssen wir aber noch den zu
benutzenden Virenscanner installieren.
7 Gegenmaßnamen einleiten
7.1 ClamAV installieren
Für die Installation von OpenAntivirus (OAV) benötigen wir die
entsprechenden RPM-Dateien.
- clamav-*.rpm
- clamav-db-*.rpm
- clamd-*.rpm
Wie auch schon zuvor holen wir uns das am besten von den
Repository-Seiten von Dag Wieers unter
http://dag.wieers.com/packages/clamav/ und installieren es
mit:
# rpm -U -v dateiname.rpm
7.2 ClamAV konfigurieren
Möglicherweise müssen wir noch in den Dateien
/etc/clamd.conf und /etc/freshclam.conf den User von
'clamav' nach 'amavis' ändern (Achtung: gleichen User wie in der
/etc/amavisd.conf benutzen).
Zum Test starten wir mal den ClamAV Daemon mit:
# service clamd start
Wenn alles geklappt hat, sollte ClamAV als Daemon laufen, seine
Signatur-Dateien finden und an Port 3310 lauschen. Überprüfen Sie
bitte die Logfiles unter /var/log/clamav/clamd.log und
/var/log/clamav/freshclam.log auf Probleme!
7.3 ClamAV in Amavisd-new aktivieren
Dazu muß in der Datei /etc/amavisd.conf folgendes
hinzugefügt werden:
### http://www.clamav.net/
['ClamAV-clamd',
\&ask_daemon, ["CONTSCAN {}\n", '127.0.0.1:3310'],
qr/\bOK$/, qr/\bFOUND$/,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],
7.4 OpenAntivirus installieren
Für die Installation von OpenAntivirus (OAV) benötigen wir:
- OpenAntivirus (Scannerdaemon),
- die aktuellen Virus-Signaturen,
- J2RE 1.4 und
- eine Startdatei ScannerDaemon.sh
Das J2RE holen wir uns am Besten als RPM von
http://java.sun.com und installieren es mit:
# rpm -U -v j2re-xxx.rpm
OpenAntivirus (wie brauchen nur den ScannerDaemon) gibt es in
http://sourceforge.net/projects/openantivirus/ und die
aktuellen Viren-Signaturdateien in
http://www.openantivirus.org/latest.php. Den Inhalt des
OAV-Archives kopieren wir am Besten nach /opt/openantivirus
und den Inhalt des Signatur-Archives in ein Unterverzeichnis dort,
so dass OAV seine Daten finden kann.
Zum Test starten wir dort mal den ScannerDaemon mit:
# java -jar Scannerdaemon.jar
Wenn alles geklappt hat, sollte OAV als Daemon laufen, seine
Signatur-Dateien finden und an Port 8127 lauschen.
7.5 OpenAntivirus konfigurieren
Damit OAV schon beim Systemstart automatisch mitgestartet wird,
erweitern wir die Startdatei /etc/rc.local mit folgenden
Befehlen:
if [ -f /opt/openantivirus/ScannerDaemon.sh ]; then
cd /opt/openantivirus
./ScannerDaemon.sh > /dev/null 2>&1
echo -n $"Starting OpenAntivirus-Scanner..."
cd /root
fi
Dann erstellen wir eine Datei Scannerdaemon.sh im
Verzeichnis /opt/openantivirus und schreiben in
Abhängigkeit, wo bei uns das J2RE liegt:
/usr/java/j2re_xxx/bin/java -jar ScannerDaemon.jar &
7.6 OpenAntivirus in Amavisd-new aktivieren
Dazu muß in der Datei /etc/amavisd.conf folgendes
hinzugefügt werden:
### http://www.openantivirus.org/
['OpenAntiVirus ScannerDaemon (OAV)',
\&ask_daemon, ["SCAN {}\n", '127.0.0.1:8127'],
qr/^OK/, qr/^FOUND: /, qr/^FOUND: (.+)/ ],
7.7 Alles testen
So jetzt wollen wir mal alles per Hand starten um zu sehen, ob es
auch so funktioniert, wie wir es uns gedacht haben.
Als erstes starten wir OpenAntivirus in einer eigenen Konsole mit:
# java -jar /opt/openantivirus/ScannerDaemon.sh
Dann können wir amavis-new in einer anderen Konsole im Debug-Modus
starten:
# amavisd debug
Als letztes folgt dann Postfix mit dem Kommando:
# postfix reload
Wenn wir jetzt eine Email per Hand verschicken und vielleicht noch
den Eicar-Virus mit dazupacken (zu finden unter
http://www.eicar.org/anti_virus_test_file.htm), dann sollte
schon einiges zu sehen sein.
# mail -s "Test" benutzername < eicar.com
Der auf Port 8127 (OpenAV) oder 3310 (ClamAV) horchende
Virenscanner sollte den Virus bemerken (siehe
Virus-Konsolen-Ausgabe) und an Amavis zurückmelden (siehe
Amavis-Konsolen-Ausgabe). Amavis wird diese Virus-Mail in
Quarantäne schicken (siehe Quarantäne-Verzeichnis in ...) und
Postfix sollte an root und an den Versender der verseuchten Email
je eine andere Meldung schicken.
Das gleiche können wir jetzt auch mal mit einer Spam-Mail
versuchen. Eine sehr starke Spam-Mail (mit Spam-Level ab 15.00)
sollte auch ins Quarantäne-Verzeichnis geschickt werden und
weniger starke gehen als Spam gekennzeichnet weiter an den
Empfänger, der sie dann mit Procmail oder mit Hilfe seines
Mail-Clienten (Thunderbird, Seamonkey) aussortieren kann. Mails
mit einem Spam-Level <5.00 erhalten einen Vermerk von SpamAssassin
und gehen ebenfalls an den Empfänger. Jede Email wird im Header
als von 'Amavis und SpamAssassin gescannt'
gekennzeichnet.
Weitere E-Mails zum Testen von SpamAssassin findet man in
/usr/share/doc/amavisd-new-xxxxxxxx/test-messages/. Mit
ihnen kann man differenziertes Verhalten testen.
Wenn das alles geklappt hat, dann können wir ja mal den Rechner
neu booten und beobachten, ob Postfix, Amavis und OpenAntivirus
nun gestartet werden - wenn nicht, dann bitte noch einmal die
ganze Installation überprüfen und nachbessern.
Ein verbessertes Mailsystem sollte nun auf Ihrem Rechner laufen.
In den folgenden Kapiteln kümmern wir uns nun um die Verbesserung
und Sicherung des System mit folgenden Komponenten und Verfahren:
- SMTP-Authentifikation
- TLS/SSL Verschlüsselung des Mail-Versands
- Anlegen von Zertifikaten
- Email-Dienste POP3, POP3S, IMAP, IMAPS
- IMAP und CRAM-MD5
- Webaccess mit Squirrelmail
- Hinweise für die Sicherung mit einer Firewall
- Mail-Logging
- FTP Server mit VSFTPD
- Zeitsynchronisation mit NTP
8 Wer da?
Historisch gesehen sind alle SMTP-Server offen für das Versenden
von Email; wenn sie auch noch im Internet stehen, kann die ganze
Welt über sie Mail oder auch Spam verschicken. Um das zu
verhindern wurde unter anderem auch SMTP-Auth entwickelt, so
können nur User Emails über diesen Server versenden, wenn sie sich
vorher durch ein Passwort authentifiziert haben.
8.1 Installation und Konfiguration von SMTP-Auth
Für die Authentifizierung gibt verschiedene Methoden. Im folgenden
werde ich die Installation beispielhaft an 'saslauth' und
'saslauthdb' erklären.
Zuerst müssen wir Cyrus-SASL2 und damit wahrscheinlich folgende
Programme (abhängig von der Authentifizierungsmethode) von den
CD's nachinstallieren:
- cyrus-sasl
- cyrus-sasl-devel
- cyrus-sasl-MD5
- cyrus-sasl-plain
- cyrus-sasl-gssapi
Danach bearbeiten wir die Datei /usr/lib/sasl2/smtpd.conf
und tragen dort die zu verwendende Methode ein:
pwcheck_method: saslauthd
mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
Da wir nur die oben genannten Protokolle zur Authentifizierung
benutzen wollen, muss dort nicht mehr drinstehen. Aber
Achtung: die Reihenfolge der Protokolle bestimmt die
Abarbeitungsreihenfolge durch den 'saslauthd'! Das heisst, erst
versucht er die Authentifizierung mit DIGEST-MD5, dann mit
CRAM-MD5 usw. Wenn also ein User keinen Eintrag in der
/etc/sasldb2 hat (Protokoll CRAM-MD5), dann wird so lange in
der Liste weitergesucht, bis eine andere Authentifizierungsmethode
greift, z.B. funktioniert das Protokoll PLAIN, wenn der User einen
Account auf dem Rechner hat. Funktioniert keine, dann wird mit
einer Fehlermeldung abgebrochen.
Dann starten wir wieder 'setup' auf der Konsole und in 'Dienste'
aktivieren wir 'saslauthd'. Nun müssen wir den Dienst beim ersten
Mal noch von Hand starten, bzw. nach einem Systemneustart würde
dieser Service dann auch laufen:
service saslauthd start
Bitte darauf achten, dass der 'saslauthd' mit der Option 'pam'
gestartet wird (siehe in /etc/sysconfig/saslauthd)!!!
Um Postfix auch noch zu informieren, dass wir ab sofort SMTP-Auth
benutzen wollen müssen wir folgende Änderungen in der
/etc/postfix/main.cf machen:
smtpd_sasl_auth_enable = yes
#Wert für realm, normalerweise der Hostname
#wird aber von SASL selbstständig durch "hostname" gefunden,
#daher hier bitte auskommentieren
#smtpd_sasl_local_domain =
#Zusatz-Optionen: Keine anonyme-Anmeldung verwenden
smtpd_sasl_security_options = noanonymous
#Wieder ein Workaround für ältere Clients und Outlook
#damit auch Outlook die AUTH-Methoden erkennen kann
broken_sasl_auth_clients = yes
#nur SASL Zugänge erlauben
smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination
#ODER meine Netze und SASL erlauben
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Jetzt fehlt uns nur noch ein Benutzername und ein Passwort für
alle User oder für jeden einzelnen Benutzer. Ganz wie es die
Policy des Mailservers vorsieht. Ich zeige hier kurz, wie man
einen Benutzer einrichtet.
Das Programm für den Eintrag eines Benutzers heisst
saslpasswd2 (ACHTUNG: nicht saslpasswd benutzen, das
ist für eine ältere Version des Programmes gedacht). Seine
Einträge macht dieses Programm in /etc/sasldb2 und benutzt
wird es folgendermaßen:
# saslpasswd2 -c <userid>
Man kann das auch nicht-interaktiv machen:
# echo "pAsSwOrD" | saslpasswd2 -p -c Username
Danach sollte zur Probe z.B. im Mozilla unter
Edit®Mail&Newsgroup Account
Settings®Outgoing Server(SMTP) der SMTP-Server
eingestellt werden und mit Ihm die Authentifizierungsmethode mit
Userid und Passwort.
9 Sicher befördern
TLS/SSL sorgt für die sichere Beförderung der Email-Daten
einerseits zwischen Mail-Client und SMTP-Server sowie andererseits
zwischen verschiedenen SMTP-Servern.
Um diese Verschlüsselung zu erreichen benötigen wir postfix mit
TLS/SSL-Unterstützung und ein Server-Zertifikat2,
welches von uns selber (durch einen CA-Schlüssel) unterschrieben
wird. Dafür werden wir unsere eigene Certificate Authority (CA)
sein.
9.1 Anlegen von Server-Zertifikaten
Um verschlüsselt miteinander kommunizieren zu können braucht jeder
Server, der mit TLS/SSL arbeiten will folgende Komponenten:
- einen privaten Serverkey
- einen öffentlichen, von einer CA unterschriebenen Schlüssel
mit dem Namen des Mail-Servers (Server-Zertifikat)
- den öffentlichen Schlüssel der CA (CA-Zertifikat) zum Überprüfen des
eigenen Server-Zertifikates
Wenn das jetzt einer irgendwie nicht verstanden hat, ist es auch
egal, Hauptsache die nun folgenden Schritte werden so ausgeführt
und abgearbeitet, wie beschrieben. Einfach Augen zu und durch.
Besten Dank an Lutz Jänicke für seine Webseite[4].
9.1.1 Die eigene CA sein
Normalerweise sollten die Schlüssel, die wir in 9.1.2
für den Mailserver erstellen von einer bekannten CA (wie z.B.
VeriSign, Thawte, RSA Security) unterschrieben werden. Allerdings
ist das nicht in allen Fällen (Testrechner, interne Server)
notwendig, da es viel Geld kostet. Also basteln wir uns unsere
eigene CA.
OpenSSL sollte installiert sein. Daher können wir gleich in einem
sicheren Verzeichnis, z.B. /root/zertifikate,
# CA.pl -newca
auf der Kommandozeile eintippen3.
Ist dieses Programm nicht installiert kann man sich auch folgende
Toolsammlung von
http://www.openssl.org/contrib/ssl.ca-0.1.tar.gz laden oder
eine neue CA.pl z.B. von
http://www.mit.edu/afs/net.mit.edu/reference/source/openssl-0.9.7-beta3/apps/CA.pl.
Eine Dokumentation zur Benutzung von CA.pl findet man unter
http://www.openssl.org/docs/apps/CA.pl.html.
Die Angaben, die man jetzt machen muss sollten sorgfältig überlegt
sein, da man jetzt die Schlüssel der alles zertifizierenden
Instanz erzeugt. Will man z.B. mit dieser CA auch alle weiteren
Schlüssel der Firma (Email-Schlüssel, Webserver-Zertifikate)
signieren, dann sollte man als Namen gleich den Name der Firma mit
allen Angaben wählen.
Damit alle Benutzer weltweit den Mailserver-Schlüssel (den wir im
nächsten Schritt erstellen) auch überprüfen können müssen wir den
öffentlichen Schlüssel der CA auch veröffentlichen, damit die
Benutzer ihn z.B. auch in Ihren Webbrowser integrieren können. Die
Zertifikate der bekannten Firma sind ja auch schon im Browser
enthalten (siehe Edit®Preferences®Privicy
& Security ®Certificates®Manage
Certificates®Authorities), jetzt fehlt nur noch unser
eigener CA-Schlüssel. Das kann man entweder von Hand in dem oben
genannten Dialog (®Import) machen oder automatisch
über ein Perl-CGI-Script, welches man im Webserver integriert und
das den Pfad zu unserem CA-Schlüssel kennt:
#!/usr/local/bin/perl -T
require 5.003;
use strict;
use CGI;
# hier müssen der Pfad und der Name des CA-Zertifikates
# angegeben werden - könnte bei Ihnen abweichen
my $cert_dir = "/usr/local/ssl/certs";
my $cert_file = "CAcert.pem";
my $query = new CGI;
my $kind = $query->param('FORMAT');
if($kind eq 'DER') { $cert_file = "CAcert.der"; }
my $cert_path = "$cert_dir/$cert_file";
open(CERT, "<$cert_path");
my $data = join '', <CERT>;
close(CERT);
print "Content-Type: application/x-x509-ca-cert\n";
print "Content-Length: ", length($data), "\n\n$data";
1;
Nun reicht es aus im Browser einfach das Script aufzurufen und das
CA-Zertifikat wird automatisch in den Browser eingebunden.
Hat man das Zertifikat nicht über den Browser (egal ob Explorer
oder Mozilla/Firefox) in die Zertifikat-Datenbank geladen und
installiert, dann wird weiterhin jedes Programm das dieses
CA-Zertifikat dort in der Datenbank sucht meckern, dass es den
Aussteller der Server-Zertifikate nicht finden kann. Das ist nicht
schlimm, nervt aber, da man dabei immer Bestätigungsbuttons
drücken muß.
9.1.2 Server-Zertifikate erstellen
Normalerweise läuft das Erstellen eines Zertifikates in zwei von
einander getrennten Schritten ab:
Daher ist das Erstellen der Server-Zertifikate ist ein bisschen
komplizierter, denn wir müssen folgendes beachten: ein normal
erstelltes Schlüsselpaar ist noch einmal durch ein Passwort
geschützt, damit nicht jeder der es besitzt (gestohlen hat) sofort
an die Schlüsselpaare herankommt. Man muss also vorher ein
Passwort eingeben um sie zu benutzten. Das bedeutet in unserem
Fall, immer wenn der Rechner - und damit auch Postfix mit
TLS/SSL-Unterstützung - startet, wird er an einer bestimmten
Stelle anhalten und nach dem Passwort für die Server-Schlüssel
fragen. Wenn wir das nicht wollen und ein Schlüsselpaar ohne
Passwort erstellen wollen, müssen wir folgende Patch vor der
Erstellung der Server-Zertifikate in die Datei CA.pl
einspielen. Dazu sollten wir zuerst eine Kopie der Datei (z.B.
CA_neu.pl erstellen und diese dann an der Stelle:
exit 0;
} elsif (/^-newcert$/) {
# create a certificate
system ("$REQ -new -x509 -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Certificate (and private key) is in newreq.pem\n"
} elsif (/^-newreq$/) {
# create a certificate request
system ("$REQ -new -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Request (and private key) is in newreq.pem\n";
} elsif (/^-newca$/) {
durch folgenden Code ersetzen (patchen):
exit 0;
} elsif (/^-newcert$/) {
# create a certificate
system ("$REQ -new -x509 -nodes -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Certificate (and private key) is in newreq.pem\n"
} elsif (/^-newreq$/) {
# create a certificate request
system ("$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Request (and private key) is in newreq.pem\n";
} elsif (/^-newca$/) {
Mit dieser neuen CA_neu.pl erstellen wir nun die
Server-Zertifikate. Nun müssen wir natürlich bei den Angaben auch
den Namen des Server angeben (z.B. mail.mydomain.com):
# CA_neu.pl -newreq
und unterschreiben die neue erstellten Schlüssel mit:
# CA_new.pl -sign
9.1.3 Letzte Schritte
Nun müssen wir die Schlüssel in die richtigen Verzeichnisse
kopieren:
- Der öffentliche Schlüssel der CA cacert.pem geht
nach /etc/postfix/cacert.pem.
- Das der öffentliche Schlüssel des Servers
newcert.pem (auch Server-Zertifikat genannt) geht
nach /etc/postfix/cert.pem.
- Der private Schlüssel des Server newreq.pem
(auch Request genannt) geht nach /etc/postfix/priv_key.pem.
Jetzt müssen wir noch die richtigen Rechte setzen. Die beiden
cert-Dateien sind öffentlich, daher:
# chmod 644 cacert.pem
# chmod 644 cert.pem
Der Server-Key ist privat daher:
# chmod 600 priv_key.pem
9.2 Konfiguration von TLS/SSL
TLS/SSL ist bereits in SASL2 integriert und damit von uns schon
installiert. Jetzt muss es nur noch aktiviert werden. Dazu
editieren wir als erstes /etc/postfix/master.cf und
aktivieren 3 Zeilen, die bis jetzt deaktiviert waren:
smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
tlsmgr fifo - - n 300 1 tlsmgr
Damit haben wir jetzt "SMTP over SSL" auf Port 465 und "SMTP
over TLS" auf Port 25 zur Verfügung. Je nachdem welche Varianten
die Mail-Clients verfügen kann man dann über die eine oder andere
Weise seine Mails verschicken.
In der /etc/postfix/main.cf müssen wir dann noch die
Konfigurationsanweisungen für die Benutzung von TLS/SSL setzen:
smtpd_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtpd_tls_received_header = yes
# TLS (server side)
smtpd_tls_key_file = /etc/certificates/SMTPpriv_key.pem
smtpd_tls_cert_file = /etc/certificates/SMTPcert.pem
smtpd_tls_CAfile = /etc/certificates/cacert.pem
smtpd_use_tls = yes
# TLS (client side)
smtp_tls_key_file = /etc/certificates/SMTPpriv_key.pem
smtp_tls_cert_file = /etc/certificates/SMTPcert.pem
smtp_tls_CAfile = /etc/certificates/cacert.pem
smtp_use_tls = yes
# nur für ältere Outlook[Express]-Clients, die Port 465 benutzen
# dann aber auch die entsprechende Zeile in der master.cf
# aktivieren!!!
#smtpd_tls_wrappermode = no
smtpd_tls_session_cache_database = sdbm:/etc/postfix/smtpd_scache
# SASL related variables for TLS
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_tls_auth_only = no
Nun müssen wir natürlich Postfix auch noch
einmal neu starten und fertig:
# service postfix reload
9.3 Nochmal alles Testen
Um zu sehen, ob auch TLS/SSL funktioniert machen wir wieder ein
telnet auf den Mailserver:
# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.test.de ESMTP Postfix
EHLO test.com
250-mail.test.de
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-XVERP
250 8BITMIME
quit
221 Bye
Connection closed by foreign host.
Solltest Du auch folgende Zeilen sehen:
250-STARTTLS
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
Ist alles in Ordnung und Du kannst das ganze jetzt mit einer Email
ausprobieren. Dazu stellen wir zur Probe z.B. im Mozilla unter
Edit®Mail & Newsgroup Account
Settings®Outgoing Server(SMTP) zusätzlich 'Use secure
connection (SSL) - When available' ein. Nun sollte die
Kommunikation und die Email-Übertragung immer verschlüsselt
erfolgen. Wenn man sehen will, was genau passiert, kann man in der
Datei /var/log/maillog die Log-Ausgaben lesen.
Eine vollkommen verschlüsselte Kommunikation sieht dann wie folgt aus. Man
erkennt schon wie die Mail vom Mailserver angenommen wird, wie
die Zertifikate und Schlüssel ausgetauscht werden, wie die Mail
weiter an Amavis gesendet wird, wie Amavis seinen Filter
drüberlaufen lässt.
connect from mail.test.de[192.168.100.41]
setting up TLS connection from mail.test.de[192.168.100.41]
SSL_accept:before/accept initialization
SSL_accept:error in SSLv2/v3 read client hello A
SSL_accept:error in SSLv3 read client hello B
SSL_accept:error in SSLv3 read client hello B
SSL_accept:SSLv3 read client hello B
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:SSLv3 read client key exchange A
SSL_accept:error in SSLv3 read certificate verify A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data
TLS connection established from mail.test.de[192.168.100.41]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
DA81373AA3: client=mail.test.de[192.168.100.41], sasl_method=CRAM-MD5, sasl_username=tux@mail
DA81373AA3: message-id=<4006BB0E.6010505@test.de>
DA81373AA3: from=<heinz@test.de>, size=600, nrcpt=1 (queue active)
disconnect from mail.test.de[192.168.100.41]
(04135-01) ESMTP::10024 /var/amavis/amavis-20040115T170919-04135: <heinz@test.de> -> <root@test.de>
Received: SIZE=600 from mail.test.de ([127.0.0.1]) by localhost (mail[127.0.0.1])
(amavisd-new, port 10024) with ESMTP id 04135-01 for <root@test.de>; Thu, 15 Jan 2004 17:09:19 +0100(CET)
(04135-01) Checking: <heinz@test.de> -> <root@test.de>
(04135-01) spam_scan: hits=0 tests=
(04135-01) FWD via SMTP: [127.0.0.1:10025] <heinz@test.de> -> <root@test.de>
starting TLS engine
connect from unknown[127.0.0.1]
connect from mail.test.de[192.168.100.41]
setting up TLS connection from mail.test.de[192.168.100.41]
SSL_accept:before/accept initialization
SSL_accept:error in SSLv2/v3 read client hello A
SSL_accept:error in SSLv3 read client hello B
SSL_accept:error in SSLv3 read client hello B
SSL_accept:SSLv3 read client hello B
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:SSLv3 read client key exchange A
SSL_accept:error in SSLv3 read certificate verify A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data
TLS connection established from mail.test.de[192.168.100.41]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
DA81373AA3: client=mail.test.de[192.168.100.41], sasl_method=CRAM-MD5, sasl_username=test@mail
DA81373AA3: message-id=<4006BB0E.6010505@test.de>
DA81373AA3: from=<heinz@test.de>, size=600, nrcpt=1 (queue active)
disconnect from mail.test.de[192.168.100.41]
Jan 15 17:09:19 mail amavis[4135]: (04135-01) ESMTP::10024 /var/amavis/amavis-20040115T170919-04135:
<heinz@test.de> -> <root@test.de> Received: SIZE=600 from mail.test.de ([127.0.0.1]) by
localhost (mail[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04135-01 for <root@test.de>;
Thu, 15 Jan 2004 17:09:19 +0100 (CET)
(04135-01) Checking: <heinz@test.de> -> <root@test.de>
(04135-01) spam_scan: hits=0 tests=
(04135-01) FWD via SMTP: [127.0.0.1:10025] <heinz@test.de> -> <root@test.de>
starting TLS engine
connect from unknown[127.0.0.1]
AC61874105: client=unknown[127.0.0.1]
AC61874105: message-id=<4006BB0E.6010505@test.de>
AC61874105: from=<heinz@test.de>, size=1020, nrcpt=1 (queue active)
(04135-01) Passed, <heinz@test.de> -> <root@test.de>, Message-ID: <4006BB0E.6010505@test.de>, Hits: 0
(04135-01) TIMING [total 4667 ms] - SMTP EHLO: 3 (0%), SMTP pre-MAIL: 0 (0%), mkdir tempdir: 0 (0%),
create email.txt: 0 (0%), SMTP pre-DATA-flush: 3 (0%), SMTP DATA: 32 (1%), body hash: 1 (0%),
mkdir parts: 22 (0%), mime_decode: 23 (0%), get-file-type: 147 (3%), decompose_part: 10 (0%),
parts: 0 (0%), AV-scan-1: 28 (1%), SA msg read: 1 (0%), SA parse: 1 (0%), SA check: 4317 (92%),
fwd-connect: 34 (1%), fwd-mail-from: 1 (0%), fwd-rcpt-to: 1 (0%), write-header: 5 (0%),
fwd-data: 0 (0%), fwd-data-end: 32 (1%), fwd-rundown: 1 (0%), unlink-1-files: 3 (0%), rundown: 2 (0%)
DA81373AA3: to=<root@test.de>, relay=127.0.0.1[127.0.0.1], delay=5, status=sent (250 2.6.0 Ok,
id=04135-01, from MTA: 250 Ok: queued as AC61874105)
disconnect from unknown[127.0.0.1]
AC61874105: to=<root@test.de>, relay=local, delay=0, status=sent (mailbox)
10 Zu Diensten sein
10.1 Installation von POP3, POP3S, IMAP und IMAPS
Standardmäßig ist der Dienst POP3 für die Benutzung installiert.
Da alle vier Dienste von einem Programm (uw-IMAP) bereitgestellt
werden, müssen wir die anderen, nicht aktiven Dienste nun auch noch
aktivieren. Das passiert mit dem Programm 'Setup' auf der
Kommandozeile und dort über den Menüpunkt Dienste. Einfach nur ein
Kreuz bei iPOP3s, IMAP und IMAPS setzen und fertig.
Wenn uw-IMAP noch nicht installiert ist oder die Dienste in
'Setup' noch nicht existieren, dann müssen wir noch von den CD's
nachinstallieren.
10.2 Konfiguration von POP3, POP3S, IMAP und IMAPS
Nun, da die Dienste aktiviert sind, müssen für die entsprechenden
verschlüsselten Versionen noch die Zertifikate angepasst werden.
Wir benutzen als Zertifikate die gleichen, die wir in Kapitel
9.1.1 erstellt und für die Sicherung des
SMTP-Verkehrs durch TLS/SSL verwendet haben. Allerdings benötigt
uw-IMAP anscheinend den Key und das Zertifikat in einer
Datei. Daher gehen wir in das Verzeichnis /etc/postfix wo
unsere Zertifikate liegen und machen dort:
# cat priv_key.pem cert.pem > cert+key.pem
# cd /usr/share/ssl/certs/
# ln -s /etc/postfix/cert+key.pem imapd.pem
# ln -s /etc/postfix/cert+key.pem ipop3d.pem
Damit haben wir Key und Zertifikat in eine Datei geschrieben, sind
in das Verzeichnis gewechselt, von wo uw-IMAP die PEM-Dateien
erwartet und haben zwei Links auf unsere gerade erstellte
PEM-Datei gesetzt.
Jetzt sollte beim Abfragen mit einem Mailprogramm (wenn
Verschlüsselung für POP oder IMAP eingestellt wurde) auch das
richtige Zertifikat angezeigt werden.
10.3 Noch sicherer mit IMAP und CRAM-MD5
Bei manchen (modernen) Mail-Clients gibt es die Möglichkeit sich
noch sicherer und zwar mit "Secure authentication" auf einem
IMAP-Server einzuloggen. Dazu wird eine spezielle
Authentifizierungsmethode mit CRAM-MD5 angewendet, so wird
vermieden, dass Klartextpasswörter über das Netz übertragen und
somit abgehört werden können.
In unserem uw-IMAP-Server ist diese Möglichkeit schon
eincompiliert. Wir müssen sie nur noch aktivieren, indem wir für
alle User, die diese spezielle Methode des Login benutzen wollen,
eine Datei /etc/cram-md5.pwd anlegen und in ihr den User und
ein Passwort ablegen. Aber Achtung: die User müssen in
der Datei /etc/passwd existieren, sollten aber ein anderes
Passwort für den CRAM-MD5-Login benutzen. Die Rechte der Datei
müssen mit chmod auf 600 gesetzt werden, da die Passwörter
dort im Klartext abgelegt werden.
Bei mir sieht diese Datei folgendermaßen aus:
# CRAM-MD5 authentication database
# Entries are in form: user<one tab>password
# Lines starting with "#" are comments
heinz heinz
meier killer
Nachdem diese Datei angelegt wurde nimmt uw-IMAP nicht mehr
automatisch die Daten aus der /etc/passwd sondern nun aus
der /etc/cram-md5.pwd (nur wenn der User dort vorhanden ist,
ansonsten wird auch weiterhin die /etc/passwd verwendet).
11 Reinlassen
Squirrelmail ist ein Webmailer, ähnlich WebAccess von Microsoft
für seinen MS Exchange Server. Man kann so seine Mail-Accounts
einfach und überall verfügbar über das Internet, nur mit Hilfe
eines Browsers, erreichen.
Squirrelmail lässt sich auf einfache Weise um die verschiedensten
Funktionen (Kalender-, Adressbuch-, Filesharing-Funktion)
erweitern.
11.1 Installation und Konfiguration von Squirrelmail
Wenn Squirrelmail noch nicht auf dem Rechner installiert ist, kann
man mit RPM auch dieses Paket von den CD's nachinstallieren.
Für Änderungen und Anpassungen bearbeitet man die Datei
/etc/squirrelmail/config.php. Für Änderungen am Webserver
kann man die Datei /etc/httpd/conf.d/squirrelmail.conf
anpassen. In Ihr steht auch wie der Webmailer vom Browser aus
aufgerufen wird.
Wenn man denn dann schon in diesem Verzeichnis ist, kann man auch
gleich die Pfade für die Web-Server-Zertifikate in
/etc/httpd/conf.d/ssl.conf anpassen. Dazu passt man in
dieser Datei folgende Zeilen an:
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
Damit sie dann nachher folgendermaßen aussehen und somit auf unser
schon in Kapitel 9.1.2 erstelltes Zertifikat
verweisen:
SSLCertificateFile /etc/postfix/cert.pem
SSLCertificateKeyFile /etc/postfix/priv_key.pem
11.2 Hinzufügen von Plugins
Das Hinzufügen von Plugin ist sehr einfach. Im Prinzip sind
folgende Schritte dazu auszuführen:
- Wechsel in das Verzeichnis Plugins:
# cd plugins/
- Entpacke das Plugin in das Verzeichnis mit:
# tar -xzf /your/path/to/plugin-x.x.tgz
- Gehe ins Verzeichnis config und starte das
Konfigurationsprogramm mit:
# cd ../../config/
# ./conf.pl
- Wähle nun Option 8 und füge das Plugin hinzu.
- Speichern und fertig.
A Aussperren
A.1 Hinweise für die Sicherung mit einer Firewall
Bei der Sicherung des Mailserver sollte man schon die ganzen neu
hinzugekommenen offenen Ports beachten und überprüfen, ob sie nur
für interne Zugriffe oder auch für externe Zugriffe notwendig
sind.
Zur Übersicht hier eine Auflistung aller benutzten Port und ihre
Zuordnung zu Programmen oder Protokollen:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:imaps *:* LISTEN
tcp 0 0 *:pop3 *:* LISTEN
tcp 0 0 *:pop3s *:* LISTEN
tcp 0 0 *:imap *:* LISTEN
tcp 0 0 mail:10024 (amavis-new) *:* LISTEN
tcp 0 0 mail:10025 (amavis-new) *:* LISTEN
tcp 0 0 *:submission (postfix) *:* LISTEN
tcp 0 0 mail:783 (SpamAssassin) *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 *:smtps *:* LISTEN
tcp 0 0 *:http *:* LISTEN
tcp 0 0 *:https *:* LISTEN
tcp 0 0 mail:8127(OpenAntivirus) *:* LISTEN
B Zwei auf einen Streich - Mail-Logging
Ein Mailserver unter Linux ist zwar was Tolles und Mächtiges, was
es jederzeit mit Exchange aufnehmen kann, allerdings, ganz im
Gegensatz zum MS Produkt, sieht man davon leider wenig. Kein
Klicki-Bunti, nicht was sich bewegt oder blinkt. Man selber als
Admin kann zwar in die Logs schauen, was eigentlich ausreicht,
aber anderen nicht sagt. Daher ist es ganz nützlich, wenn man dem
Kunden was Graphisches und Aussagekräftiges zeigen kann. Damit er
weiß wofür er bezahlt hat.
Dabei helfen uns die beiden Tools:
- Mailgraph mit RRDTOOL und
- Pflogsumm
Mailgraph findet man unter
http://people.ee.ethz.ch/~dws/software/mailgraph/, Pflogsumm
auf der Webseite von Jim Seymour
http://jimsun.linxnet.com/postfix_contrib.html und eine
deutsche Version davon auf den Seiten von Patrick Koetter unter
http://postfix.state-of-mind.de/patrick.koetter/pflogsumm/.
Beide Programme sind gut dokumentiert und lassen sich einfach
installieren. Dabei bitte an die mitgelieferten Dokus halten.
Mailgraph kommt mit einem Start-Skript für
/etc/rc.d/init.d/, was zumindest bei Redhat basierten
Systemen einwandfrei funktioniert,
und zwei Dateien: mailgraph.cgi und mailgraph.pl.
mailgraph.cgi wird nach /var/www/cgi-bin/
kopiert und mailgraph.pl nach /usr/local/bin/.
Pflogsumm kopiert man ebenfalls einfach nach
/usr/local/bin/.
Ich habe beide Programme in einem Skript zusammengefasst. Das war
für mich übersichtlicher. Und so geht es:
Die Datei mailgraph.cgi editieren und folgenden Code
hinzufügen:
In der Funktion "sub print_html()" vor der Stelle "print <<FOOTER;"
einfach "&print_pflogsumm('en');" einfügen.
An das Ende des Skriptes einfach folgende Funktion anhängen:
sub print_pflogsumm
{
my $lang = shift;
my $pflog = '/usr/local/bin/pflogsumm';
my $cat = '/bin/cat';
my $maillog = '/var/log/maillog*';
my $prog = $pflog."_".$lang;
$output = `$cat $maillog | $prog -d today`;
print "<br><br><br><hr><H1><a name='teil2'>More Mail Statistics for $host</a></H1>\n";
print "<PRE>$output</PRE>\n";
}
Nun ist es noch so, dass Mailgraph zwar Bounces (schwarz), Rejects
(rot), Viren (gelb) und Spam (grau) korrekt und schön
unterschiedlich farbig darstellt, bei Spam allerdings nur den ganz
schlimmen Spam, der per Amavis-new im Quarantäne-Verzeichnis
landet, ohne das der Empfänger ihn je zu sehen bekommt; bei mir
Spam mit mehr als 20 Spam-Punkten. Wenn man sich jeden erkannten
und markierten Spam, bei mir mehr als 5 Spam-Punkte, anzeigen
lassen will, dann muss man folgende Zeile in der Datei
mailgraph.pl hinzufügen:
In der Funktion "sub process_line($)" unter der Zeile:
elsif($text =~ /^\([0-9-]+\) (Passed|Not-Delivered)\b.*\bquarantine spam/) {
event($time, 'spam'); # amavisd-new-20030616 and earlier
}
folgende Zeile hinzufügen:
elsif($text =~ /^\([0-9-]+\) SPAM-TAG\b.*\bYes/) {
event($time, 'spam'); # um allen erkannten Spam zu sehen
}
Nun kann man sich an der Ausgabe von Mailgraph und Pflogsumm
erfreuen und hat gegebenenfalls ein gutes Argument im Ärmel, wenn
man mit dem Chef um das nächste Update für den veralteten
Virenscanner kämpfen muss (siehe die vielen gelben Balken in den
Grafiken).
C Ein FTP Server mit VSFTPD
Angenommen wird eine Installation, bei der alle lokalen User, d.h.
alle, die einen Account auf dem Rechner besitzen, Lese- und
Schreibzugriff in einer chroot-Umgebung auf Ihr Homeverzeichnis
haben; anonymer FTP-Zugriff wird verboten.
Installiert werden muss dazu das entsprechende RPM-Paket, wenn es
nicht schon bei der Installation mitinstalliert wurde. Ebenfalls
muss das Programm 'setup' auf der Konsole gestartet werden und in
'Dienste' aktivieren wir 'vsftpd'. Nun müssen wir den Dienst beim
ersten Mal noch von Hand starten, bzw. nach einem Systemneustart
würde dieser Service dann auch selbstständig starten:
/etc/rc.d/init.d/vsftpd.
Folgende Einstellung sind in der /etc/vsftpd/vsftpd.conf zu
machen:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=002
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
dirmessage_enable=YES
connect_from_port_20=YES
#chown_uploads=YES
#chown_username=whoever
#xferlog_file=/var/log/vsftpd.log
xferlog_enable=YES
xferlog_std_format=YES
log_ftp_protocol=YES
#idle_session_timeout=600
#data_connection_timeout=120
#nopriv_user=ftpsecure
#async_abor_enable=YES
#ascii_upload_enable=YES
#ascii_download_enable=YES
ftpd_banner=Willkommen zum FTP Service auf Test.de
#deny_email_enable=YES
#banned_email_file=/etc/vsftpd.banned_emails
chroot_local_user=YES
#chroot_list_enable=YES
#chroot_list_file=/etc/vsftpd.chroot_list
#ls_recurse_enable=YES
pam_service_name=vsftpd
userlist_enable=YES
#enable for standalone mode
listen=YES
tcp_wrappers=YES
D Zeitsynchronisation mit NTP
Benötigt wird dazu das Paket ntp. Wenn es noch nicht installiert
sein sollte, dann bitte mit rpm -U <Paketname>
nachinstallieren.
Bitte die Datei /etc/ntp.conf editieren und folgende Angaben
machen:
# generell Zugriff verbieten
restrict default ignore
# Zugriff von folgenden internen Netzwerken zulassen
restrict 192.168.100.0 mask 255.255.255.0 notrust nomodify notrap
restrict 192.168.200.0 mask 255.255.255.0 notrust nomodify notrap
# externe Server für den Zeitabgleich definieren
server 129.132.2.21
server 192.93.2.20
server 130.149.17.21
server 130.149.17.8
restrict 129.132.2.21 mask 255.255.255.255 nomodify notrap noquery
restrict 192.93.2.20 mask 255.255.255.255 nomodify notrap noquery
restrict 130.149.17.21 mask 255.255.255.255 nomodify notrap noquery
restrict 130.149.17.8 mask 255.255.255.255 nomodify notrap noquery
# drift-File setzen
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
Dann mit setup auf der Kommandozeile den NTPD als Service
aktivieren und danach mit /etc/rc.d/init.d/ntpd start starten.
Ab jetzt sollte der NTPD auf diesem System laufen, regelmäßig
Verbindung zu anderen Time-Servern aufnehmen und nötigenfalls die
Systemuhr in kleinen und unauffälligen Schritten
anpassen.
Will man die Systemuhr brutal und sofort auf die richtige Zeit
einstellen (Achtung: das macht das Probleme beim
Servermanagement.) kann man den Befehl ntpdate
<NTP-Servername> dazu benutzen.
Um zu überprüfen, ob NTP auch richtig läuft kann man sich mit
ntpq -p eine kleine Statistik dazu anzeigen lassen.
E Nachlesen
Alle Anregungen dazu wurden im Internet gefunden. Die genutzten
Seiten werden hier - mit Besten Dank an die Autoren - , noch
einmal nach Themen geordnet, aufgelistet:
E.1 Antivirus
E.2 Amavis / Scanner
E.3 Postfix
E.4 TLS/SSL
E.5 SMTP-AUTH
E.6 SpamAssassin
E.7 Sonstige
References
- [1]
-
Ralf Spenneberg.
Implementing a SPAM and virus scanning mail server using RedHat
Linux 8.0 and amavis-new.
December 2003.
- [2]
-
Kyle D. Dent.
Postfix: The Definitive Guide.
O'Reilly, 1th edition, 2003.
- [3]
-
Peer Heinlein.
Das Postfixbuch.
Open Source Press, 2nd edition, 2004.
- [4]
-
Lutz Jänicke.
Postfix/TLS - A TLS extension for POSTFIX.
http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/doc/index.html.
Footnotes:
1Die Bezeichnung SPAM stammt von einem Sketch aus
Monty Python's Flying Circus, der vom britischen Dosenfleisch
gleichen Namens handelt.
2Ich weiss
nicht, warum immer über Server-'Zertifikate' gesprochen wird,
dabei ist es ebenso ein Schlüsselpaar aus öffentlichen und
privaten Schlüsseln, wobei der öffentliche Schlüssel
unterschrieben (zertifiziert) ist, wie z.B. bei GnuPG oder PGP. Es
hört sich wahrscheinlich einfach nur besser an: Zertifikat. :-)
3Wenn das nicht
funktioniert, ist OpenSSL wohl nicht vollständig installiert oder
die Pfade stimmen nicht.
File translated from
TEX
by
TTH,
version 3.80.
On 03 Feb 2009, 19:50.