Product SiteDocumentation Site

Kapitel 11. Netzwerkdienste: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Mail-Server
11.1.1. Postfix installieren
11.1.2. Virtuelle Domains konfigurieren
11.1.3. Einschränkungen beim Empfangen und Senden
11.1.4. Greylisting einrichten
11.1.5. Filter anhand des Empfängers einstellen
11.1.6. Integrating an Antivirus Filter
11.1.7. Spam-Bekämpfung mit SPF, DKIM und DMARC
11.1.8. Authentifiziertes SMTP
11.2. Webserver (HTTP)
11.2.1. Apache installieren
11.2.2. Unterstützung für SSL hinzufügen
11.2.3. Virtuelle Hosts konfigurieren
11.2.4. Gebräuchliche Anweisungen
11.2.5. Protokoll-Analysatoren
11.3. FTP-Dateiserver
11.4. NFS-Dateiserver
11.4.1. NFS absichern
11.4.2. NFS-Server
11.4.3. NFS-Client
11.5. Einrichten von Windows-Freigaben mit Samba
11.5.1. Samba-Server
11.5.2. Samba-Client
11.6. HTTP/FTP-Proxy
11.6.1. Installieren
11.6.2. Einen Cache konfigurieren
11.6.3. Einen Filter konfigurieren
11.7. LDAP-Verzeichnis
11.7.1. Installieren
11.7.2. Das Verzeichnis ausfüllen
11.7.3. Konten mit LDAP verwalten
11.8. Echtzeit-Kommunikationsdienste
11.8.1. DNS-Einstellungen für RTC-Dienste
11.8.2. TURN-Server
11.8.3. SIP Proxy-Server
11.8.4. XMPP-Server
11.8.5. Laufende Dienste auf Port 443
11.8.6. WebRTC hinzufügen
Netzwerkdienste sind die Programme, mit denen Benutzer in ihrer täglichen Arbeit direkt interagieren. Sie sind die Spitze des Eisbergs des Informationssystems und dieses Kapitel richtet sein Hauptaugenmerk auf sie; die verborgenen Teile, auf denen sie aufbauen, sind die Infrastruktur, die wir bereits besprochen haben. Üblicherweise benötigen sie die Verschlüsselungstechnologie, wie sie in Abschnitt 10.2, „X.509-Zertifikate“ beschrieben ist.

11.1. Mail-Server

Die Falcot Corp. Administratoren haben Postfix wegen seiner Zuverlässigkeit und seiner leichten Konfigurierbarkeit als Server für elektronische Post gewählt. Sein Design zwingt dazu, jede Aufgabe als Prozess mit dem geringstmöglichen Satz an Berechtigungen umzusetzen, eine gute Vorbeugungsmaßnahme gegen Sicherheitsprobleme.

11.1.1. Postfix installieren

Das Paket postfix enthält den Kern des SMTP-Daemons. Andere Pakete (wie postfix-ldap und postfix-pgsql) fügen weitere Funktionsmerkmale zu Postfix hinzu, einschließlich des Zugangs zu Zuordnungsdatenbanken. Sie sollten sie nur installieren, wenn Sie wissen, dass Sie sie benötigen.
Während der Installation des Pakets werden mehrere Debconf-Fragen gestellt. Die Antworten ermöglichen es, eine erste Version der Konfigurationsdatei /etc/postfix/main.cf zu erstellen.
Die erste Frage bezieht sich auf die Art der Aufbaus. Nur zwei der vorgeschlagenen Antworten sind im Falle eines mit dem Internet verbundenen Servers relevant, „Internet site“ und „Internet with smarthost“. Die erste ist für einen Server richtig, der eingehende E-Mails empfängt und ausgehende E-Mails direkt an ihre Empfänger verschickt, und ist daher für die Situation der Falcot Corp. gut geeignet. Die zweite ist für einen Server angebracht, der eingehende E-Mails normal empfängt, aber ausgehende E-Mails über einen zwischengeschalteten SMTP-Server - den „smarthost“ - verschickt, statt direkt an den Server des Empfängers. Dies ist meistens für Personen mit einer dynamischen IP-Adresse sinnvoll, da viele E-Mail-Server Nachrichten, die direkt von einer derartigen IP-Adresse kommen, zurückweisen. In diesem Fall ist der Smarthost gewöhnlich der SMTP-Server des ISPs, der stets so konfiguriert ist, dass er E-Mails annimmt, die von den Kunden des ISP kommen, und sie in geeigneter Weise weiterleitet. Dieser Aufbau (mit einem Smarthost) ist auch für Server relevant, die nicht ständig mit dem Internet verbunden sind, da es so nicht erforderlich ist, eine Warteschlange nicht zustellbarer Nachrichten zu verwalten, für die später ein neuer Zustellversuch unternommen werden muss.
Die zweite Frage bezieht sich auf die vollständige Bezeichnung des Rechners, die zur Erstellung von E-Mail-Adressen aus einem lokalen Benutzernamen verwendet wird; die vollständige Bezeichnung des Rechners wird zu dem Teil hinter dem at-Zeichen („@“). Im Falle von Falcot sollte die Antwort mail.falcot.com lauten. Dies ist die einzige standardmäßig gestellte Frage, aber die Konfigurierung, zu der sie führt, ist für die Bedürfnisse von Falcot nicht vollständig genug, weshalb die Administratoren dpkg-reconfigure postfix aufrufen, um so weitere Parameter einstellen zu können.
Eine der zusätzlichen Fragen erkundigt sich nach allen Domain-Namen, die mit diesem Rechner in Zusammenhang stehen. Die Standardliste umfasst seine vollständige Bezeichnung sowie einige Synonyme für localhost, jedoch muss die Hauptdomain falcot.com von Hand hinzugefügt werden. Allgemeiner gesagt sollte diese Frage normalerweise mit allen Domain-Namen beantwortet werden, für die dieser Rechner als MX-Server dienen soll; mit anderen Worten, allen Domain-Namen, für die der DNS angibt, dass dieser Rechner E-Mails annimmt. Diese Information geht in die Variable mydestination der Hauptkonfigurationsdatei von Postfix — /etc/postfix/main.cf — ein.
Rolle des DNS-MX-Eintrags beim Versenden einer E-Mail

Abbildung 11.1. Rolle des DNS-MX-Eintrags beim Versenden einer E-Mail

In manchen Fällen kann während der Installation auch gefragt werden, welchen Netzwerken es erlaubt sein soll, E-Mails über den Rechner zu verschicken. In seiner Standard-Konfiguration akzeptiert Postfix nur E-Mails, die von diesem Rechner selbst kommen; das lokale Netzwerk wird gewöhnlich hinzugefügt. Die Falcot Corp. Administratoren haben 192.168.0.0/16 zur Standardantwort hinzugefügt. Falls diese Frage nicht gestellt wird, ist mynetworks die relevante Variable in der Konfigurationsdatei, wie in unten stehendem Beispiel zu sehen ist.
Lokale E-Mail kann auch durch procmail zugestellt werden. Dieses Programm ermöglicht es Benutzern, ihre ankommende E-Mail nach Regeln, die in der Datei ~/.procmailrc gespeichert sind, zu sortieren. Sowohl Postfix als auch Exim4 schlagen standardmäßig procmail vor, aber es gibt Alternativen wie maildrop oder Sieve-Filter.
Nach diesem ersten Schritt verfügen die Administratoren über die folgende Konfigurationsdatei; sie wird als Ausgangspunkt verwendet, um in den nächsten Abschnitten einige weitere Funktionsmerkmale hinzuzufügen.

Beispiel 11.1. Anfängliche /etc/postfix/main.cf-Datei

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

11.1.2. Virtuelle Domains konfigurieren

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

11.1.2.1. Virtuelle Alias-Domains

Eine virtuelle Alias-Domain enthält nur Aliasse, das heißt Adressen, die nur E-Mails an andere Adressen weiterleiten.
Eine derartige Domain wird durch das Hinzufügen ihres Namens zur Variablen virtual_alias_domains und das Eintragen eines Verweises auf eine Adressen-Bezugsdatei in die Variable virtual_alias_maps aktiviert.
virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
Die Datei /etc/postfix/virtual stellt eine Zuordnung in einer recht einfachen Syntax dar: jede Zeile enthält zwei durch Leerzeichen getrennte Felder; das erste Feld ist der Alias-Name, das zweite eine Liste der E-Mail-Adressen, an die er weiterleitet. Die spezielle Syntax @domain.com deckt alle übrigen Aliasse in der Domain ab.
webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com
Nach der Änderung von /etc/postfix/virtual muss die Postfix-Tabelle /etc/postfix/virtual.db mit sudo postmap /etc/postfix/virtual aktualisiert werden.

11.1.2.2. Virtuelle Postfach-Domains

An ein virtuelles Postfach adressierte Nachrichten werden in Postfächern gespeichert, die keinem lokalen Systembenutzer zugeordnet sind.
Um eine virtuelle Postfach-Domain zu aktivieren, ist es erforderlich, diese Domain in der Variablen virtual_mailbox_domains einzutragen und in virtual_mailbox_maps einen Verweis auf eine Mailbox-Bezugsdatei anzugeben. Der Parameter virtual_mailbox_base enthält das Verzeichnis, in dem die Postfächer gespeichert werden.
virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
Der Paramater virtual_uid_maps (beziehungsweise virtual_gid_maps) verweist auf die Datei, die den Bezug zwischen der E-Mail-Adresse und dem Systembenutzer (beziehungsweise der Gruppe) enthält, dem das entsprechende Postfach „gehört“. Um alle Postfächer zusammen fassen zu können, die dem selben Benutzer beziehungsweise der selben Gruppe gehören, weist man mittels der Syntax static:5000 eine feste UID/GID (hier mit dem Wert 5000) zu.
Auch die Syntax der Datei /etc/postfix/vmailbox ist recht einfach: zwei durch Leerzeichen getrennte Felder. Das erste Feld ist eine E-Mail-Adresse innerhalb einer der virtuellen Domains, und das zweite ist der Ort des dazugehörigen Postfachs (relativ zum Verzeichnis, das in virtual_mailbox_base angegeben ist). Falls die Bezeichnung des Postfachs mit einem Schrägstrich (/) endet, werden die E-Mails im maildir-Format gespeichert; anderenfalls wird das traditionelle mbox-Format benutzt. Das maildir-Format verwendet ein ganzes Verzeichnis zur Speicherung eines Postfachs, wobei jede individuelle Nachricht in einer eigenen Datei gespeichert wird. Dagegen ist beim mbox-Format das gesamte Postfach in einer einzigen Datei gespeichert, wobei jede Zeile, die mit „From “ beginnt (From gefolgt von einem Leerzeichen), den Beginn einer neuen Nachricht anzeigt.
# Jeans E-Mail ist als maildir gespeichert mit
# einer Datei je E-Mail in einem gesonderten Verzeichnis
jean@falcot.org falcot.org/jean/
# Sophies E-Mail ist in einer traditionellen „mbox“-Datei gespeichert
# mit allen Mails zu einer einzigen Datei verkettet
sophie@falcot.org falcot.org/sophie

11.1.3. Einschränkungen beim Empfangen und Senden

Die wachsende Zahl unerwünschter Massen-E-Mails (spam) macht es erforderlich, bei der Entscheidung, welche E-Mails ein Server annehmen sollte, in zunehmendem Maße strikt zu sein. Dieser Abschnitt zeigt einige der in Postfix enthaltenen Strategien.
Wenn die Ablehnungsregeln zu streng sind, kann es passieren, dass sogar berechtigter E-Mail-Verkehr gesperrt wird. Es ist daher eine gute Angewohnheit, während dieser Zeit mit der Richtlinie soft_bounce = yes Einschränkungen zu testen und die dauerhafte Ablehnung von Anfragen zu verhindern. Wenn eine Direktive vom Typ reject mit warn_if_reject vorangestellt wird, wird nur eine Protokollmeldung aufgezeichnet, anstatt die Anfrage abzulehnen.

11.1.3.1. IP-basierte Zugangsbeschränkungen

Die Anweisung smtpd_client_restrictions bestimmt, welchen Rechnern es erlaubt ist, mit dem E-Mail-Server zu kommunizieren.
Wenn eine Variable wie im Beispiel unten eine Liste von Regeln enthält, werden diese Regeln der Reihe nach von der ersten bis zur letzten ausgewertet. Jede Regel kann die Nachricht entweder annehmen, zurückweisen oder die Entscheidung einer nachfolgenden Regel überlassen. Daher ist die Reihenfolge wichtig und das Vertauschen zweier Regeln kann zu einem völlig anderen Verhalten führen.

Beispiel 11.2. Beschränkungen aufgrund von Client-Adressen

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net
Die Anweisung permit_mynetworks, die als erste Regel verwendet wurde, akzeptiert alle E-Mails, die von einem Rechner im lokalen Netzwerk (wie in der Konfigurationsvariablen mynetworks festgelegt) kommen.
Die zweite Direktive würde normalerweise alle E-Mails zurückweisen, die von Rechnern ohne vollständig gültige DNS-Konfiguration kommen. Solch eine gültige Konfiguration bedeutet, dass die IP-Adresse einem Namen zugeordnet werden kann und dass dieser Name wiederum der IP-Adresse zugeordnet ist. Diese Beschränkung ist häufig zu strikt, da manche E-Mail-Server keinen umgekehrten DNS für ihre IP-Adresse haben. Dies erklärt, warum die Falcot Administratoren der Direktive reject_unknown_client den Modifikator warn_if_reject vorangestellt haben: dieser Modifikator wandelt die Zurückweisung in eine einfache Warnung um, die in den Protokollen aufgezeichnet wird. Die Administratoren können dann die Anzahl der Nachrichten im Blick behalten, die zurückgewiesen würden, wenn die Regel tatsächlich durchgesetzt würde und später aufgrund dieser Informationen eine Entscheidung treffen, ob sie die Durchsetzung aktivieren wollen.
The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
Die letzten vier Regeln weisen jede Nachricht zurück, die von einem Server kommt, der in einer der angegebenen schwarzen Listen aufgeführt ist. RBL ist ein Akronym für Remote Black List und RHSBL steht für Right-Hand Side Black List. Der Unterschied besteht darin, dass erstere IP-Adressen aufführt, während letztere Domänennamen aufführt. Es gibt mehrere solcher Dienste. Sie listen Domänen und IP-Adressen mit schlechtem Ruf, schlecht konfigurierte Server, die von Spammern zur Weiterleitung ihrer E-Mails verwendet werden, sowie unerwartete Mail-Relays wie z.B. mit Würmern oder Viren infizierte Rechner.

11.1.3.2. Die Gültigkeit der Befehle EHLO und HELO überprüfen

Jeder SMTP-Austausch beginnt mit einem HELO (oder EHLO) Befehl, gefolgt vom Namen des sendenden E-Mail-Servers. Die Überprüfung der Gültigkeit dieses Namens kann interessant sein. Um die in smtpd_helo_restrictions aufgeführten Einschränkungen vollständig durchzusetzen, muss die Option smtpd_helo_required aktiviert sein. Andernfalls könnten Clients die Einschränkungen überspringen, indem sie keinen HELO/EHLO Befehl senden.

Beispiel 11.3. Beschränkungen für den in EHLO genannten Namen

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org
Die erste Anweisung, permit_mynetworks, erlaubt es allen Rechnern des lokalen Netzwerks, sich ungehindert einzuführen. Dies ist wichtig, da einige E-Mail-Programme diesen Teil des SMTP-Protokolls nicht in ausreichendem Maße beachten und sich mit unsinnigen Namen einführen können.
The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
Die reject_rhsbl_helo erlaubt es, eine schwarze Liste anzugeben, um den Hostnamen gegen eine RHSBL zu prüfen.
Die Verwendung von permit_mynetworks als erster Regel hat eine interessante Nebenwirkung: die folgenden Regeln gelten nur für Rechner außerhalb des lokalen Netzwerks. Hierdurch ist es möglich, alle Rechner, die sich als Teil des falcot.com-Netzwerks ausgeben, auf die schwarze Liste zu setzen, indem zum Beispiel die Zeile falcot.com ABGELEHNT Sie sind nicht in unserem Netzwerk! zur Datei /etc/postfix/access_helo hinzugefügt wird.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Jede Nachricht hat einen Absender, der durch den Befehl MAIL FROM des SMTP-Protokolls angegeben wird; auch diese Information kann auf verschiedene Weise überprüft werden.

Beispiel 11.4. Überprüfung des Absenders

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net
Die Tabelle /etc/postfix/access_sender ordnet einigen Absendern eine besondere Behandlung zu. Dies bedeutet für gewöhnlich, dass einige Absender in eine Positivliste oder eine schwarze Liste aufgenommen werden.
The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.
Schließlich weist die Regel reject_non_fqdn_sender E-Mails zurück, die vorgeben, von Adressen ohne einen vollständig ausgewiesenen Domain-Namen zu kommen. In der Praxis bedeutet dies, dass E-Mails, die von benutzer@rechner kommen, zurückgewiesen werden: die Adresse muss entweder als benutzer@rechner.beispiel.com oder benutzer@beispiel.com angegeben werden.
Die reject_rhsbl_sender-Regel lehnt Absender ab, die auf einem (domänenbasierten) RHSBL-Dienst basieren.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Jede E-Mail hat wenigstens einen Empfänger, der im SMTP-Protokoll mit dem Befehl RCPT TO angegeben wird. Diese Adressen erfordern ebenfalls eine Gültigkeitsprüfung, selbst wenn dies weniger wichtig sein sollte als die Überprüfung des Absenders.

Beispiel 11.5. Überprüfung des Empfängers

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit
Die grundlegende Regel lautet reject_unauth_destination, und sie verlangt, dass externe Nachrichten an uns adressiert sein müssen; Nachrichten an eine Adresse, die von diesem Server nicht bedient wird, werden zurückgewiesen. Ohne diese Regel wird ein Server zu einem offenen Übermittler, der es Spammern erlaubt, unerwünschte E-Mails zu verschicken; diese Regel ist daher obligatorisch, und sie wird am besten ziemlich am Anfang der Liste platziert, damit nicht andere Regeln die Nachricht zulassen, bevor ihre Zieladresse überprüft worden ist.
Die Regel reject_unlisted_recipient weist Nachrichten zurück, die an nicht existierende lokale Benutzer geschickt werden, was natürlich Sinn macht. Schließlich weist die Regel reject_non_fqdn_recipient nicht vollständig ausgewiesene Adressen zurück; dies macht es unmöglich, eine E-Mail an jean oder jean@rechner zu schicken, und erfordert stattdessen, die vollständige Adresse zu verwenden, wie jean@rechner.falcot.com or jean@falcot.com.
Die Permit-Richtlinie am Ende ist nicht notwendig. Sie kann jedoch am Ende einer Einschränkungsliste nützlich sein, um die Standardrichtlinie auszudrücken.

11.1.3.5. Beschränkungen in Verbindung mit dem Befehl DATA

SMTPs Befehl DATA wird vor dem Inhalt der Nachricht verschickt. An sich stellt er keine Information bereit, außer anzukündigen, was als nächstes kommt.Dennoch kann er Überprüfungen unterworfen werden.

Beispiel 11.6. Überprüfungen von DATA

smtpd_data_restrictions = reject_unauth_pipelining
Die Anweisung reject_unauth_pipelining bewirkt, dass die Nachricht zurückgewiesen wird, falls die aussendende Partei einen Befehl verschickt, bevor die Antwort auf den vorhergehenden Befehl gesendet worden ist. Dies schützt vor einer häufig von Spam-Robotern benutzten Optimierung, da sie sich gewöhnlich keinen Deut um Antworten scheren und sich nur darauf konzentrieren, in möglichst kurzer Zeit möglichst viele E-Mails zu verschicken.

11.1.3.6. Beschränkungen anwenden

Obwohl die Befehle oben Informationen in verschiedenen Phasen des SMTP-Austauschs überprüfen, verschickt Postfix die eigentliche Zurückweisung standardmäßig als Antwort auf den Befehl RCPT TO.
Dies bedeutet, dass selbst wenn die Nachricht aufgrund eines ungültigen EHLO-Befehls zurückgewiesen wird, Postfix den Absender und den Empfänger kennt, wenn es die Zurückweisung bekanntgibt. Es kann dann eine eindeutigere Nachricht protokollieren, als möglich gewesen wäre, falls die Übertragung gleich zu Anfang abgebrochen worden wäre. Außerdem erwarten manche SMTP-Clients keine Störungen bei den frühen SMTP-Befehlen, und diese Clients werden durch die späte Zurückweisung weniger gestört.
Ein letzter Vorteil dieser Vorgehensweise ist, dass die Regeln im Verlauf der verschiedenen SMTP-Stadien Informationen sammeln können; dies ermöglicht es, feinkörnigere Berechtigungen zu formulieren, wie zum Beispiel eine nicht-lokale Verbindung zurückzuweisen, wenn sie sich als lokaler Absender ausgibt.
Das Standardverhalten wird durch die Regel smtpd_delay_reject gesteuert.

11.1.3.7. Filtern aufgrund des Nachrichteninhalts

Das Überprüfungs- und Beschränkungssystem wäre nicht vollständig ohne eine Möglichkeit, Überprüfungen des Nachrichteninhalts durchzuführen. Postfix unterscheidet die Überprüfungen, die es auf die E-Mail-Kopfzeilen anwendet, von denen, die es für den E-Mail-Inhalt benutzt.

Beispiel 11.7. Inhaltsbezogene Filter aktivieren

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
Beide Dateien enthalten eine Liste regulärer Ausdrücke (gewöhnlich als regexps oder regexes bezeichnet) und damit zusammenhängender Aktionen, die ausgelöst werden, wenn die E-Mail-Kopfzeilen (oder der Inhalt) einem Ausdruck entsprechen.

Beispiel 11.8. Beispiel einer Datei /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification
Der erste überprüft die Kopfzeile, die die E-Mail-Software nennt; falls GOTO Sarbacane gefunden wird (ein Programm zum Versenden von Massen-E-Mails), wird die Nachricht zurückgewiesen. Der zweite Ausdruck überprüft den Nachrichtenbetreff; falls er eine Virenmeldung nennt, können wir entscheiden, die Nachricht nicht zurückzuweisen, sondern stattdessen sofort zu löschen.
Die Verwendung dieser Filter ist ein zweischneidiges Schwert, da die Regeln leicht zu allgemein formuliert werden können und als Folge seriöse E-Mails verloren gehen. In diesen Fällen sind nicht nur die Nachrichten verloren, sondern ihre Absender erhalten zudem unerwünschte (und störende) Fehlermeldungen.

11.1.4. Greylisting einrichten

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.
Postfix stellt Greylisting nicht von Haus aus zur Verfügung, jedoch gibt es eine Funktion, mit der die Entscheidung, eine bestimmte Nachricht anzunehmen oder zurückzuweisen, an ein externes Programme delegiert werden kann. Das Paket postgrey enthält genau solch ein Programm, das dafür ausgelegt ist, sich in diesen Dienst zur Delegierung der Zugangsrichtlinien einzubinden.
Sobald postgrey installiert ist, läuft es als Daemon und nimmt an Port 10023 Verbindungen an. Postfix kann dann auf seine Verwendung eingestellt werden, indem der Parameter check_policy_service als zusätzliche Bedingung hinzugefügt wird:
smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023
Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.
Der Hauptnachteil des Greylistings besteht darin, dass seriöse Nachrichten verzögert werden, was nicht immer akzeptabel ist. Es erhöht außerdem die Belastung von Servern, die zahlreiche seriöse E-Mails versenden.

11.1.5. Filter anhand des Empfängers einstellen

In den Abschnitten Abschnitt 11.1.3, „Einschränkungen beim Empfangen und Senden“ und Abschnitt 11.1.4, „Greylisting einrichten“sind zahlreiche Beschränkungsmöglichkeiten betrachtet worden. Sie alle haben ihren Nutzen bei der Begrenzung der eingehenden Spam-Menge, aber sie haben auch ihre Nachteile. Es wird daher immer üblicher, den Filtersatz anhand des Empfängers einzustellen. Bei Falcot Corp. ist das Greylisting für die meisten Benutzer interessant, es behindert jedoch die Arbeit einiger Benutzer, die bei ihren E-Mails kurze Wartezeiten benötigen (wie zum Beispiel der technische Betreuungsdienst). In ähnlicher Weise hat die Handelsabteilung manchmal Probleme beim Empfang von E-Mails einiger asiatischer Anbieter, die vielleicht in schwarzen Listen aufgeführt sind; diese Abteilung hat um eine ungefilterte Adresse gebeten, so dass sie mit ihnen korrespondieren kann.
Postfix bietet eine derartige Filteranpassung mit dem Konzept einer „restriction class“ an. Diese Klassen werden in dem Parameter smtpd_restriction_classes angegeben und in der gleichen Weise wie smtpd_recipient_restrictions festgelegt. Die Anweisung check_recipient_access bezeichnet dann eine Tabelle, die einem bestimmten Empfänger den richtigen Satz von Beschränkungen zuordnet.

Beispiel 11.9. Beschränkungsklassen in main.cf festlegen

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Beispiel 11.10. Die Datei /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.
The Falcot administrators selected clamav from the homonymous package.
Die Aufgabe, die Verbindung zwischen dem Virenschutz und dem E-Mail-Server bereitzustellen, fällt dem Programm clamav-milter zu. Ein Milter (kurz für Mailfilter) ist ein speziell für die Verbindung mit E-Mail-Servern ausgelegtes Programm. Ein Milter verwendet eine standardmäßige Programmierschnittstelle (API = application programming interface), die eine deutlich bessere Leistung aufweist als Filter außerhalb der E-Mail-Server. Milter wurden ursprünglich von Sendmail eingeführt, aber Postfix ist dem bald gefolgt.
Nachdem das Paket clamav-milter installiert ist, sollte milter umkonfiguriert werden um auf einen TCP-Port statt auf den Named Socket aufzusetzen. Das geht mit dpkg-reconfigure clamav-milter. Wenn die Frage nach dem "Communication interface with Sendmail" gestellt wird geben Sie “inet:10002@127.0.0.1” ein.
Die standardmäßige ClamAV-Konfiguration eignet sich für die meisten Situationen, aber einige wichtige Parameter können noch mit dpkg-reconfigure clamav-base angepasst werden.
Im letzten Schritt wird Postfix angewiesen, den neu konfigurierten Filter zu verwenden. Dies geschieht einfach durch das Hinzufügen der folgenden Anweisung zu /etc/postfix/main.cf:
# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002
Falls der Virenschutz Probleme verursacht, kann diese Zeile kommentiert und dann systemctl reload postfix aufgerufen werden, damit diese Veränderung berücksichtigt wird.
Alle Nachrichten, die von Postfix verarbeitet werden, laufen jetzt durch den Virenschutzfilter.

11.1.7. Spam-Bekämpfung mit SPF, DKIM und DMARC

Die hohe Anzahl unerwünschter E-Mails, die täglich gesendet werden, führte zur Schaffung mehrerer Standards, mit denen überprüft werden soll, ob der sendende Host einer E-Mail autorisiert ist und ob die E-Mail nicht manipuliert wurde. Die folgenden Systeme basieren alle auf DNS und erfordern, dass die Administratoren nicht nur die Kontrolle über den Mailserver haben, sondern auch über das DNS für die betreffende Domäne.

11.1.7.1. Integration des Sender Policy Framework (SPF)

Das Sender Policy Framework (SPF) wird verwendet, um zu überprüfen, ob ein bestimmter E-Mail-Server E-Mails für eine bestimmte Domäne senden darf. Er wird meist über DNS konfiguriert. Die Syntax für den vorzunehmenden Eintrag wird beschrieben unter:
The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.
Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all
Werfen wir einen kurzen Blick auf den Eintrag falcot.org.
# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
Es besagt, dass die IP des Absenders mit dem A-Record für die absendende Domain übereinstimmen muss, als einer der Mail Exchange Resource Records für die aktuelle Domain aufgeführt sein muss oder eine der drei genannten IP4-Adressen sein muss. Alle anderen Hosts sollten so gekennzeichnet werden, dass sie keine E-Mails für die Absender-Domain senden dürfen. Letzteres wird als "Soft Fail" bezeichnet und soll die E-Mail entsprechend kennzeichnen, sie aber dennoch akzeptieren.
Der E-Mailserver postfix kann den SPF-Record für eingehende E-Mails mit dem Paket postfix-policyd-spf-python, einem in Python geschriebenen Policy-Agent, überprüfen. Die Datei /usr/share/doc/postfix-policyd-spf-python/README.Debian beschreibt die notwendigen Schritte, um den Agenten in Postfix zu integrieren, sodass wir ihn hier nicht wiederholen werden.
Die Konfiguration erfolgt in der Datei /etc/postfix-policyd-spf-python/policyd-spf.conf, die in policyd-spf.conf(5) und /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz vollständig dokumentiert ist. Die wichtigsten Konfigurationsparameter sind HELO_reject und Mail_From_reject, die konfigurieren, ob E-Mails zurückgewiesen (Fail) oder mit angehängtem Header (False) akzeptiert werden sollen, wenn die Prüfungen fehlschlagen. Letzteres ist oft nützlich, wenn die Nachricht von einem Spam-Filter weiterverarbeitet wird.
Wenn das Ergebnis von opendmarc (Abschnitt 11.1.7.3, „Integration der domänenbasierten Nachrichtenauthentifizierung, Berichterstattung und Konformität (DMARC)“) verwendet werden soll, dann muss Header_Type auf AR gesetzt werden.
Beachten Sie, dass spamassassin ein Plugin zur Überprüfung des SPF-Eintrags enthält.

11.1.7.2. Integration von DomainKeys (DKIM) Signatur und Prüfung

Der Standard Domain Keys Identified Mail (DKIM) ist ein Absender-Authentifizierungssystem. Der Mail-Transport-Agent, hier postfix, fügt dem Header ausgehender E-Mails eine dem Domänennamen zugeordnete digitale Signatur hinzu. Die empfangende Partei kann den Nachrichtentext und die Header-Felder validieren, indem sie die Signatur gegen einen öffentlichen Schlüssel prüft, der aus den DNS-Einträgen des Absenders abgerufen wird.
Die erforderlichen Werkzeuge werden mit den Paketen opendkim und opendkim-tools ausgeliefert.
Zuerst muss der private Schlüssel mit dem Befehl opendkim-genkey -s WAHLSCHALTER -d DOMÄNE erstellt werden. WAHLSCHALTER muss ein eindeutiger Name für den Schlüssel sein. Er kann so einfach wie "mail" oder das Erstellungsdatum sein, wenn Sie vorhaben, Schlüssel zu rotieren.

Beispiel 11.11. Erstellen Sie einen privaten Schlüssel zum Signieren von E-Mails von falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*
Dadurch werden die Dateien /etc/dkimkeys/mail.private und /etc/dkimkeys/mail.txt erstellt und der entsprechende Besitz festgelegt. Die erste Datei enthält den privaten Schlüssel und die zweite den öffentlichen Schlüssel, der dem DNS hinzugefügt werden muss:
Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
Das opendkim-Paket in Debian ist standardmäßig auf eine Schlüsselgröße von 2048 Bit voreingestellt. Leider können einige DNS-Server nur Texteinträge mit einer maximalen Länge von 255 Zeichen verarbeiten, die durch die gewählte Standardschlüsselgröße überschritten wird. Verwenden Sie in diesem Fall die Option -b 1024, um eine kleinere Schlüsselgröße zu wählen. Wenn die Ausführung von opendkim-testkey erfolgreich ist, wurde der Eintrag erfolgreich eingerichtet. Die Syntax des Eintrags wird hier erklärt:
Zur Konfiguration müssen opendkim, SOCKET und RUNDIR in /etc/default/opendkim ausgewählt werden. Bitte beachten Sie, dass SOCKET über postfix in seiner chroot-Umgebung zugänglich sein muss. Die weitere Konfiguration erfolgt in /etc/opendkim.conf. Es folgt ein Konfigurationsauszug, der sicherstellt, dass die Domain (Domäne) "falcot.com" und alle Subdomains (SubDomain) mit dem Selector (Wahlschalter) "mail" und dem einzelnen privaten Schlüssel (KeyFile) /etc/dkimkeys/mail.private signiert werden. Die "entspannte" Canonicalization (Kanonisierung) sowohl für die Kopfzeile als auch für den Textkörper toleriert leichte Änderungen (z.B. durch eine Mailinglisten-Software). Der Filter läuft sowohl beim Signieren ("s") als auch beim Verifizieren ("v") Modus. Wenn eine Signatur nicht validiert werden kann (On-BadSignature), sollte die E-Mail unter Quarantäne gestellt werden ("q").
[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim
Es ist auch möglich, mehrere Wahlschalter/Schlüssel (KeyTable) und Domänen (SigningTable) zu verwenden und interne oder vertrauenswürdige Hosts (InternalHosts, ExternalIgnoreList) anzugeben, die E-Mails ohne Anmeldeinformationen über den Server als eine der signierenden Domänen senden können.
Die folgenden Direktiven in /etc/postfix/main.cf bewirken, dass postfix den Filter verwendet:
milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345
Zur Unterscheidung zwischen Signierung und Verifizierung ist es manchmal stattdessen sinnvoller, die Richtlinien den Diensten in /etc/postfix/master.cf hinzuzufügen.
Weitere Informationen finden Sie im Verzeichnis /usr/share/doc/opendkim/ und in den Handbuchseiten opendkim(8) und opendkim.conf(5).
Beachten Sie, dass spamassassin ein Plugin zur Überprüfung des DKIM-Eintrags enthält.

11.1.7.3. Integration der domänenbasierten Nachrichtenauthentifizierung, Berichterstattung und Konformität (DMARC)

Der Standard Domain-based Message Authentication, Reporting and Conformance (DMARC) kann verwendet werden, um einen DNS TXT-Eintrag mit dem Namen _dmarc und der Aktion zu definieren, die ausgeführt werden soll, wenn E-Mails, die Ihre Domain als sendenden Host enthalten, nicht mit DKIM und SPF validiert werden können.
Werfen wir einen Blick auf die Einträge von zwei großen Providern:
# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
Yahoo hat eine strikte Politik, alle E-Mails abzulehnen (reject), die vorgeben, von einem Yahoo-Konto aus gesendet zu werden, denen aber DKIM- und SPF-Prüfungen fehlen oder fehlschlagen. Google Mail (Gmail) propagiert eine sehr lockere Richtlinie, in der solche Nachrichten von der Hauptdomain weiterhin akzeptiert werden sollen (p=keine). Für Subdomains sollen sie als Spam markiert werden (sp=quarantine). Die im Schlüssel rua angegebenen Adressen können verwendet werden, um aggregierte DMARC-Berichte an diese zu senden. Die vollständige Syntax wird hier erklärt:
Der Mailserver postfix kann diese Informationen ebenfalls nutzen. Das opendmarc-Paket enthält den notwendigen Milter. Ähnlich wie bei opendkim müssen SOCKET und RUNDIR in /etc/default/opendmarc gewählt werden (bei Unix-Sockets ist darauf zu achten, dass sie sich innerhalb des Postfix-Chroots befinden). Die Konfigurationsdatei /etc/opendmarc.conf enthält detaillierte Kommentare und wird auch in opendmarc.conf(5) erklärt. Standardmäßig werden E-Mails, die die DMARC-Validierung nicht bestehen, nicht zurückgewiesen, sondern durch Hinzufügen eines entsprechenden Header-Feldes gekennzeichnet. Um dies zu ändern, verwenden Sie RejectFailures true.
Der Milter wird dann zu smtpd_milters und non_smtpd_milters hinzugefügt. Wenn wir die Filter opendkim und opendmarc so konfiguriert haben, dass sie auf den Ports 12345 und 54321 laufen, sieht der Eintrag in /etc/postfix/main.cf wie folgt aus:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321
Der Milter kann stattdessen auch selektiv auf einen Dienst in /etc/postfix/master.cf angewendet werden.

11.1.8. Authentifiziertes SMTP

Um E-Mails verschicken zu können, ist es erforderlich, dass ein SMTP-Server erreichbar ist; besagter SMTP-Server muss außerdem E-Mails durchleiten. Für Benutzer, die auf Reisen sind, würde dies bedeuten, dass die Konfiguration des SMTP-Clients regelmäßig geändert werden muss, da Falcots SMTP-Server Nachrichten abweist, die von IP-Adressen kommen, die offensichtlich nicht zum Unternehmen gehören. Es gibt zwei Lösungen: Entweder installiert ein Benutzer auf Reisen einen SMTP-Server auf seinem Rechner, oder er benutzt weiterhin den Unternehmensserver unter Verwendung einiger Hilfsmittel, mit denen er sich als Angestellter authentifiziert. Die erste Lösung wird nicht empfohlen, da der Rechner nicht ununterbrochen verbunden wäre und im Falle von Problemen nicht wiederholt versuchen könnte, Nachrichten zu senden; wir werden uns daher auf die zweite Lösung konzentrieren.
SMTP-Authentifizierung in Postfix ist auf SASL angewiesen (Simple Authentication and Security Layer). Hierzu ist es erforderlich, die Pakete libsasl2-modules und sasl2-bin zu installieren und dann für jeden Benutzer, der eine Authentifizierung beim SMTP-Server benötigt, ein Passwort in die SASL-Datenbank einzutragen. Dies geschieht mithilfe des Befehls saslpasswd2, der verschiedene Parameter akzeptiert. Die Option -u legt die Authentifizierungs-Domain fest, die mit dem Parameter smtpd_sasl_local_domain in der Postfix-Konfiguration übereinstimmen muss. Die Option -c ermöglicht das Anlegen eines Benutzers und -f gestattet es, die Datei zu bestimmen, die benutzt werden soll, wenn die SASL-Datenbank an einem anderen als dem standardmäßig vorgegebenen Ort (/etc/sasldb2) gespeichert werden muss.
# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... geben Sie Jeans Passwort zweimal ein ...]
Beachten Sie, dass die SASL-Datenbank im Verzeichnis von Postfix erstellt worden ist. Um Konsistenz sicherzustellen, wandeln wir außerdem /etc/sasldb2 in einen symbolischen Verweis um, der auf die von Postfix verwendete Datenbank weist. Dies geschieht mit dem Befehl ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.
Nun müssen wir Postfix so einstellen, dass es SASL benutzt. Zunächst muss der Benutzer postfix zur Gruppe sasl hinzugefügt werden, damit er auf die Datenbank des SASL-Kontos zugreifen kann. Einige zusätzliche Parameter sind erforderlich, um SASL zu aktivieren, und der Parameter smtpd_recipient_restrictions muss so eingestellt werden, dass Benutzer, die für SASL authentifiziert sind, ungehindert E-Mails versenden können.

Beispiel 11.12. SASL in /etc/postfix/main.cf aktivieren

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]
Es ist normalerweise keine gute Idee, Passwörter über eine unverschlüsselte Verbindung zu senden. Postfix erlaubt die Verwendung unterschiedlicher Konfigurationen für jeden Port (Dienst), auf dem er läuft. Diese können mit verschiedenen Regeln und Direktiven in der Datei /etc/postfix/master.cf konfiguriert werden. Um die Authentifizierung für Port 25 (smtpd-Dienst) überhaupt abzuschalten, fügen Sie die folgende Anweisung hinzu:
smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]
Wenn Clients aus irgendeinem Grund einen veralteten AUTH-Befehl verwenden (einige sehr alte E-Mail-Clients tun dies), kann die Zusammenarbeit mit ihnen mit der Direktive broken_sasl_auth_clients aktiviert werden.