Inhaltsverzeichnis
Postfix ArchLinux - Konfiguration: main server - DANE-Konfiguration
Postfix ist Wietse Venema's Mail-Server, welcher bei „IBM research“ als Alternative zum ehemals weit verbreiteten Programm Sendmail entwickelt wurde. Postfix erhebt den Anspruch ein schneller, einfach zu administrierender und sicherer Mail-Server zu sein.
Postfix wird von Wietse Venema entwickelt.
| Beschreibung | Externer Link |
|---|---|
| Homepage | http://www.postfix.org |
| Ankündigungen | http://www.postfix.org/announcements.html |
| Dokumentation | http://www.postfix.org/documentation.html Postfix TLS Support Postfix Connection Cache |
Ab hier werden zur Ausführung nachfolgender Befehle root-Rechte benötigt. Um der Benutzer root zu werden, melden Sie sich bitte als root-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root:
$ su - Password:
Vorhaben
Es soll für die Kommunikation via E-Mail mit Postfix nachfolgendes Konstrukt, wie in der gezeigten Skizze zu sehen ist, zum Einsatz kommen:
┌──────────────────────┐ ┌──────────────────────┐ ┌───┐ │ Postfix- │ │ Postfix- │ │ I │ │ null client │ │ main client │ │ N │ ├──────────────────────┤ ├──────────────────────┤ │ T │ │ │ dane-only │ │ dane │ E │ │ Listen 'localhost' ┼─────────────────► Listen 'interface' ┼────────► R │ │ Cert 'self-signed' │ │ Cert 'officialone' ◄────────┼ N │ │ │ │ │ may │ E │ │ Relay: main client │ │ 'mx1.tachtler.net' │ │ T │ │ │ │ │ │ │ └──────────────────────┘ └──────────────────────┘ └───┘
Damit der Postfix-null client via TLS/StartTLS-Verschlüsselung senden kann, muss zuerst ein Zertifikat erzeugt werden. Dabei soll ein sogenanntes Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat zum Einsatz kommen.
Damit der Postfix-main client via TLS/StartTLS-Verschlüsselung senden und empfangen kann, ist ein Zertifikat von einer „offiziellen“ Zertifizierungsstelle erforderlich. Dies dient dann zur TLS/StartTLS-Verschlüsselung in beide Richtungen für eingehend und ausgehend.
Die interne Kommunikation vom Postfix-null client zum Postfix-main client soll via TLS/StartTLS-Verschlüsselung mittels „dane-only“ erzwungen werden.
Die externe Kommunikation vom und zum Postfix-main client via TLS/StartTLS-Verschlüsselung soll mittels „dane“ versucht werden.
Siehe auch nachfolgenden internen Link weiter unten:
Voraussetzungen
Für die nachfolgende Installation wird vorausgesetzt,
- dass eine lauffähige Version von Postfix ab Version 3.9
vorhanden ist und die unter nachfolgenden Links beschriebenen Installationen und Konfigurationen von Postfix als Mindestvoraussetzung zwingend durchgeführt wurden:
Grundlagen TLSA-Record
Der TLSA-Record ist wie folgt aufgebaut:
_[Port]._[Protokoll].[SUBDOMAIN].[DOMAIN].[TLD] [TTL] IN TLSA (DATEN = [Zahl] [Zahl] [Zahl] [HASH])
Für einen Standard SMTP Server wäre das z.B. das der Port 25 und das TCP Protokoll. Im Feld Record wird daher folgendes eingegeben: _25._tcp
Wenn das Zertifikat für einen Host einer Subdomain gültig ist muss der Record z.B. für die bekannte mx Subdomain wie folgt aussehen: _25._tcp.mx
Das Daten Feld enthält 4 Informationen getrennt von Leerzeichen und optional von einer Klammer umschlossen:
([Zahl] [Zahl] [Zahl] [HASH])
Die erste Zahl ist ein Wert von 0 bis 3:
- 0: Der Hash gehört der Zertifizierungsstelle die Zertifikate für diesen Host ausstellen darf. Der Client muss die Zertifizierungsstelle kennen oder diese muss von einer vertrauten Zertifizierungsstelle unterschrieben sein.
- 1: Der Hash gehört dem Serverzertifikat. Es muss von einer Zertifizierungsstelle unterschrieben sein der vom Client vertraut wird.
- 2: Der Hash gehört einer Zertifizierungsstelle die Zertifikate für diesen Host ausstellen darf. Der Client soll Ihr Vertrauen auch wenn sie ihm Unbekannt und von keiner bekannten Zertifizierungsstelle unterschrieben ist.
- 3: Der Hash gehört dem Serverzertifikat und der Client soll diesem ohne weitere Prüfung der Vertrauenskette trauen.
Die Zweite Zahl kann 0 oder 1 sein und gibt an wie der Hash überprüft wird:
- 0: Es wird ein Hash vom kompletten Zertifikat erstellt.
- 1: Es wird nur ein Hash vom Public Key und des Algorithmus erstellt.
Die Dritte Zahl enthält einen wert von 0 bis 2:
- 0: Der Hash enthält das komplette Zertifikat (nicht empfohlen).
- 1: Der Hash enthält einen SHA-256 Hash.
- 2: Der Hash enthält einen SHA-512 Hash.
Vorbereitung
Nachfolgende Anleitung aus dem internen Link, zeigt wie Zertifikate generell durch die Verwendung von Let's Encrypt erstellt werden und muss zwingend bereits erfolgreich durchgeführt worden sein !!!
HINWEIS - Ein aktuell generiertes Zertifikat muss bereits vorhanden sein !!!
Nachfolgend wird in dieser Anleitung davon ausgegangen, dass ein
- Let's Encrypt-Zertifikat
in nachfolgendem Verzeichnis liegt:
/etc/postfix/ssl/certs/server.tachtler.net.pem
TLSA-Record - Let's Encrypt
Nachfolgend soll ein TLSA-Records erstellt werden. Der Grund dafür liegt in der Erneuerung des eigentlichen Let's Encrypt-Zertifikats, welche nach aktuellem Stand nur Zertifikate für 90 Tage ausstellt. Dies würde es erforderlich machen, auch den TLSA-Record alle 90 Tage zu erneuern.
HINWEIS - Eine Erneuerung alle 90 Tage ist bei entsprechender Gestaltung des TLSA-Records NICHT erforderlich!
Siehe auch den externen Link: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
Bei der Verwendung von Let's Encrypt-Zertifikaten mit 90-tägigem Ablaufdatum ist darauf zu achten, dass
- keine „3 0 1“ und keine „3 0 2“ DANE TLSA-Datensätze veröffentlicht werden.
Die Erneuerung von Let's Encrypt-Zertifikaten führt zu einem neuen Zertifikats-Digest (Fingerprint) und macht die TLSA-Datensätze ungültig.
Stattdessen sollte mindestens ein
- „3 1 1“-Datensatz
wie im folgenden Abschnitt erläutert, veröffentlicht werden.
Bei „3 1 1“-Datensätzen muss sichergestellt sein, dass die Erneuerung von Let's Encrypt-Zertifikaten kein neues Paar aus privatem und öffentlichem Schlüssel erzeugt, sondern dass bei künftigen Aktualisierungen des Zertifikats den selben öffentlichem Schlüssel verwendet wird.
Damit nun, wenn einmal die Erstellung eines neuen Zertifikats nicht rechtzeitig erfolgt, eine Art „Fallback“-Szenario existiert, kann auch ein TLSA-Record für das Root-Zertifikat der Let's Encrypt CA zusätzlich erstellt werden.
Durch die Erstellung eines TLSA-Records für das Root-Zertifikat der Let's Encrypt CA ist dies eben das „Fallback“-Szenario. Das bedeutet, dass so lange bis das eigentliche Let's Encrypt-Zertifikat erneuert wurde, weiterhin der TLSA-Record der Let's Encrypt-CA (Root-Zertifikat) gültig ist und zur Validierung verwendet werden kann.
WICHTIG - Sollte sich jedoch das Let's Encrypt-Root-Zertifikat „Let’s Encrypt Authority X3“ Zertifikat einmal ändern, muss auch dieser TLSA-Record erneuert werden!
TLSA-Record - Generierung
Nachfolgend soll auf Basis des TLSAGEN-Script der [*] sys4 AG der FINGERPRINT des eigentlichen Let's Encrypt-Zertifikats erstellt werden.
Dazu soll der FINGERPRINT des eigentlichen Let's Encrypt-Zertifikats, welches hier im Verzeichnis mit nachfolgendem Namen
/etc/postfix/ssl/certs/server.tachtler.net.pem'
liegt, verwendet werden.
Nachfolgender Aufruf des einzeiligen Befehls sollte nachfolgende Ausgabe erzeugen:
# printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' mx1.tachtler.net $(openssl x509 -in /etc/postfix/ssl/certs/fullchain.tachtler.net.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"') _25._tcp.mx1.tachtler.net. IN TLSA 3 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f
Parameter für den Aufruf:
- Die DANE-EE(3) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
3 1 1 - Die Domäne muss entsprechend angepasst werden, hier verwendet:
mx1.tachtler.net - Der Speicherort und der Dateiname des Zertifikats, hier verwendet:
/etc/postfix/ssl/certs/fullchain.tachtler.net.pem
Das Ergebnis ist der fertige TLSA-Record:
_25._tcp.mx1.tachtler.net. IN TLSA 3 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f
TLSA-Record - DNS-Eintrag
Nachfolgend wird dargestellt, wie die DNS-Records entsprechend im jeweiligen DNS-Server hinterlegt werden können:
_25._tcp.mx1.tachtler.net. IN TLSA 3 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f
Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen:
# dig _25._tcp.mx1.tachtler.net IN TLSA +dnssec +multi ; <<>> DiG 9.20.3 <<>> _25._tcp.mx1.tachtler.net IN TLSA +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26003 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;_25._tcp.mx1.tachtler.net. IN TLSA ;; ANSWER SECTION: _25._tcp.mx1.tachtler.net. 300 IN TLSA 3 1 1 ( ADEA18BBACB8A8F1370659BD3CC0A3A209BC27BFEF82 942C3ADE758622CA0A5F ) _25._tcp.mx1.tachtler.net. 300 IN RRSIG TLSA 13 5 300 ( 20241209102503 20241125142958 5902 tachtler.net. xNwzakBF8mJf+sJD3V48Ct2YmSJVE1YbJtq4g52avOhR TQOO/JDMqo9D59s9gGJNYEJkIW+YT3sdraNOO6tzdg== ) ;; Query time: 43 msec ;; SERVER: 10.0.0.20#53(10.0.0.20) (UDP) ;; WHEN: Mon Nov 25 16:33:26 CET 2024 ;; MSG SIZE rcvd: 209
DANE-Konfiguration: smtp
WICHTIG - Bei der TLS-Konfiguration: smtp handelt es sich um die verschlüsselte Kommunikation, bei der der Postfix (MTA) als client agiert! |
|---|
Nachfolgend soll die externe Kommunikation vom Postfix-main server ins Internet via TLS/StartTLS-Verschlüsselung mittels „dane“ versucht werden.
Transport Layer Security (TLS, früher SSL genannt) bietet zertifikatsbasierte Authentifizierung und verschlüsselte Sitzungen. Eine verschlüsselte Sitzung schützt die Informationen, die mit SMTP-Mail oder mit SASL-Authentifizierung übertragen werden.
smtp_tls_security_level
HINWEIS - Parameter: smtp_tls_security_level
- Da eine vollständige Konfiguration für
danedurchgeführt wurde, kann der Parameter nun aufdaneabgeändert werden!
Der Postfix SMTP/LMTP-Client implementiert mehrere TLS-Sicherheitsstufen. Diese Stufen werden in den folgenden Abschnitten ausführlicher beschrieben
| Stufe der Verschlüsselung | Beschreibung |
|---|---|
none | Auf dieser Ebene werden keine zusätzlichen Attribute unterstützt. |
may | Die optionalen Attribute „ciphers“, „exclude“ und „protocols“ (verfügbar für opportunistisches TLS mit Postfix ≥ 2.6) und das Attribut „connection_reuse“ (Postfix ≥ 3.4) überschreiben die Konfigurationsparameter smtp_tls_ciphers, smtp_tls_exclude_ciphers, smtp_tls_protocols und smtp_tls_connection_reuse. Auf dieser Ebene und höher setzt das optionale Attribut „servername“ (verfügbar mit Postfix ≥ 3.4) den globalen Parameter smtp_tls_servername ausser Kraft und ermöglicht die Konfiguration der SNI-Erweiterung, die an den entfernten SMTP-Server gesendet wird, pro Ziel. Das optionale Attribut „enable_rpk“ (Postfix ≥ 3.9) übersteuert den Parameter main.cf smtp_tls_enable_rpk. Wenn opportunistische TLS-Handshakes fehlschlagen, versucht Postfix die Verbindung mit deaktiviertem TLS erneut. Dies ermöglicht die E-Mail-Zustellung an Standorte mit nicht interoperablen TLS-Implementierungen. https://www.postfix.org/postconf.5.html#smtp_tls_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_protocols https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse https://www.postfix.org/postconf.5.html#smtp_tls_enable_rpk |
encrypt | E-Mails werden nur zugestellt, wenn der entfernte SMTP-Server STARTTLS anbietet und der TLS-Handshake erfolgreich ist. Auf dieser Ebene und höher setzt das optionale Attribut „protocols“ den Parameter main.cf smtp_tls_mandatory_protocols ausser Kraft, das optionale Attribut „ciphers“ setzt den Parameter main.cf smtp_tls_mandatory_ciphers ausser Kraft, das optionale Attribut „exclude“ (Postfix ≥ 2. 6) überschreibt den Parameter main.cf smtp_tls_mandatory_exclude_ciphers, und das optionale Attribut „connection_reuse“ (Postfix ≥ 3.4) überschreibt den Parameter main.cf smtp_tls_connection_reuse. Das optionale Attribut „enable_rpk“ (Postfix ≥ 3.9) übersteuert den Parameter main.cf smtp_tls_enable_rpk. https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse https://www.postfix.org/postconf.5.html#smtp_tls_enable_rpk |
dane | Die TLS-Richtlinie für das Ziel wird über TLSA-Einträge in DNSSEC ermittelt. Wenn keine TLSA-Datensätze gefunden werden, wird die effektive Sicherheitsstufe may verwendet. Wenn TLSA-Einträge gefunden werden, aber keine verwendbar sind, ist die effektive Sicherheitsstufe encrypt. Wenn brauchbare TLSA-Einträge für den entfernten SMTP-Server gefunden werden, muss das Serverzertifikat mit den TLSA-Einträgen übereinstimmen (und der SNI-Name wird bedingungslos auf die TLSA-Basisdomäne gesetzt). RFC 7672 (DANE) TLS-Authentifizierung und DNSSEC-Unterstützung sind mit Postfix 2.11 und höher verfügbar. Das optionale Attribut „connection_reuse“ (Postfix ≥ 3.4) setzt den Parameter main.cf smtp_tls_connection_reuse ausser Kraft. Wenn die effektiv verwendete Sicherheitsstufe may ist, überschreiben die optionalen Attribute „ciphers“, „exclude“ und „protocols“ (Postfix ≥ 2.6) die Konfigurationsparameter smtp_tls_ciphers, smtp_tls_exclude_ciphers und smtp_tls_protocols. Wenn die effektive Sicherheitsstufe verschlüsselt ist, überschreiben die optionalen Attribute „ciphers“, „exclude“ und „protocols“ (Postfix ≥ 2.6) die Konfigurationsparameter smtp_tls_mandatory_ciphers, smtp_tls_mandatory_exclude_ciphers und smtp_tls_mandatory_protocols. https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse https://www.postfix.org/postconf.5.html#smtp_tls_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_protocols https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols |
dane-only | Die TLS-Richtlinie für das Ziel wird über TLSA-Einträge in DNSSEC ermittelt. Wenn keine TLSA-Einträge gefunden werden oder keine verwendbar sind, wird keine Verbindung mit dem Server hergestellt. Wenn brauchbare TLSA-Einträge für den entfernten SMTP-Server gefunden werden, muss das Serverzertifikat mit den TLSA-Einträgen übereinstimmen. RFC 7672 (DANE) TLS-Authentifizierung und DNSSEC-Unterstützung sind mit Postfix 2.11 und höher verfügbar. Die optionalen Attribute „ciphers“, „exclude“ und „protocols“ (Postfix ≥ 2.6) setzen die Konfigurationsparameter smtp_tls_mandatory_ciphers, smtp_tls_mandatory_exclude_ciphers und smtp_tls_mandatory_protocols ausser Kraft. Das optionale Attribut „connection_reuse“ (Postfix ≥ 3.4) übersteuert den Parameter main.cf smtp_tls_connection_reuse. https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse |
fingerprint | Verfügbar mit Postfix 2.5 und höher. Bei dieser Sicherheitsstufe gibt es keine vertrauenswürdigen Zertifizierungsstellen. Die Vertrauenskette des Zertifikats, das Ablaufdatum, … werden nicht überprüft. Stattdessen listet das optionale Attribut „match“ oder der Parameter main.cf smtp_tls_fingerprint_cert_match die Zertifikatsfingerabdrücke bzw. die Fingerabdrücke des öffentlichen Schlüssels (ab Postfix 2.9) von akzeptablen Serverzertifikaten auf. Der zur Berechnung des Fingerabdrucks verwendete Digest-Algorithmus wird mit dem Parameter smtp_tls_fingerprint_digest ausgewählt. Mehrere Fingerabdrücke können mit einem „pipe“-Trennzeichen in einem einzigen Übereinstimmungsattribut kombiniert werden, oder es können mehrere Übereinstimmungsattribute verwendet werden. Das Zeichen „:“ wird nicht als Trennzeichen verwendet, da es zwischen jedem Paar von Fingerabdruckziffern (hexadezimal) steht. Die optionalen Attribute „ciphers“, „exclude“ und „protocols“ (Postfix ≥ 2.6) setzen die Konfigurationsparameter smtp_tls_mandatory_ciphers, smtp_tls_mandatory_exclude_ciphers und smtp_tls_mandatory_protocols ausser Kraft. Das optionale Attribut „connection_reuse“ (Postfix ≥ 3.4) übersteuert den Parameter main.cf smtp_tls_connection_reuse. Das optionale Attribut „enable_rpk“ (Postfix ≥ 3.9) setzt den Parameter main.cf smtp_tls_enable_rpk ausser Kraft. https://www.postfix.org/postconf.5.html#smtp_tls_fingerprint_cert_match https://www.postfix.org/postconf.5.html#smtp_tls_fingerprint_digest https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse https://www.postfix.org/postconf.5.html#smtp_tls_enable_rpk |
verify | E-Mails werden nur zugestellt, wenn der TLS-Handshake erfolgreich ist, die Zertifikatskette des entfernten SMTP-Servers validiert werden kann und ein DNS-Name im Zertifikat den angegebenen Übereinstimmungskriterien entspricht. Bei dieser Sicherheitsstufe wird davon ausgegangen, dass DNS-MX-Lookups sicher genug sind, und der im Serverzertifikat überprüfte Name wird möglicherweise über nicht authentifizierte DNS-MX-Lookups ermittelt. Der Name des Serverzertifikats muss entweder mit dem optionalen Attribut „match“ oder dem Wert des Parameters main.cf smtp_tls_verify_cert_match übereinstimmen. Mit Postfix ≥ 2.11 modifiziert das Attribut „tafile“ optional die Verifizierung der Vertrauenskette auf die gleiche Weise wie der Parameter smtp_tls_trust_anchor_file. Das „tafile“-Attribut kann mehrfach angegeben werden, um mehrere Vertrauensanker-Dateien zu laden. Das optionale Attribut „connection_reuse“ (Postfix ≥ 3.4) übersteuert den Parameter main.cf smtp_tls_connection_reuse. https://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match https://www.postfix.org/postconf.5.html#smtp_tls_trust_anchor_file https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse |
secure | E-Mails werden nur zugestellt, wenn der TLS-Handshake erfolgreich ist, die Zertifikatskette des entfernten SMTP-Servers validiert werden kann und ein DNS-Name im Zertifikat den angegebenen Übereinstimmungskriterien entspricht. Auf dieser Sicherheitsstufe werden DNS MX-Lookups, obwohl sie potenziell zur Bestimmung der IP-Adressen der Next-Hop-Gateways verwendet werden können, nicht als sicher genug für die TLS-Peername-Verifizierung angesehen. Stattdessen wird der im Serverzertifikat verifizierte Standardname direkt vom Next-Hop bezogen oder explizit über das optionale Attribut „match“ angegeben, das den Parameter main.cf smtp_tls_secure_cert_match ausser Kraft setzt. Die optionalen Attribute „ciphers“, „exclude“ und „protocols“ (Postfix ≥ 2.6) setzen die Konfigurationsparameter „smtp_tls_mandatory_ciphers“, „smtp_tls_mandatory_exclude_ciphers“ und smtp_tls_mandatory_protocols ausser Kraft. Mit Postfix ≥ 2.11 modifiziert das Attribut „tafile“ optional die Verifizierung der Vertrauenskette auf die gleiche Weise wie der Parameter smtp_tls_trust_anchor_file. Das „tafile“-Attribut kann mehrfach angegeben werden, um mehrere Vertrauensanker-Dateien zu laden. Das optionale Attribut „connection_reuse“ (Postfix ≥ 3.4) übersteuert den Parameter main.cf smtp_tls_connection_reuse. https://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_exclude_ciphers https://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols https://www.postfix.org/postconf.5.html#smtp_tls_trust_anchor_file https://www.postfix.org/postconf.5.html#smtp_tls_connection_reuse |
smtp_dns_support_level
| Information | Beschreibung |
|---|---|
| Dokumentation | https://www.postfix.org/postconf.5.html#smtp_dns_support_level Postfix TLS Support |
| Defaultwert | smtp_dns_support_level = |
| Neuer Wert | smtp_dns_support_level = dnssec |
| Beschreibung | Grad der DNS-Unterstützung im Postfix-SMTP-Client. Wenn smtp_dns_support_level auf dem leeren Standardwert belassen wird, steuert der „Legacy-Parameter disable_dns_lookups, ob DNS im Postfix-SMTP-Client aktiviert ist, ansonsten wird der „Legacy-Parameter“ ignoriert. Der Postfix SMTP-Client betrachtet nicht-MX [nexthop] und [nexthop]:port Ziele als gleichwertig mit statisch validierten MX-Einträgen der Form nexthop. IN MX 0 nexthop. Bei eingeschalteter dnssec-Unterstützung gelten daher validierte Hostname-zu-Adresse-Lookups für die nexthop-Domäne eines beliebigen [nexthop]- oder [nexthop]:port-Ziels. Dies gilt auch für LMTP-inet:host- und inet:host:port-Ziele, da LMTP-Hostnamen nie Gegenstand von MX-Lookups sind. HINWEIS - Die Einstellung smtp_dns_support_level = dnssec wird nur dann empfohlen, wenn die TLS-Sicherheitsstufen dane oder dane-only verwendet werden. Andernfalls bietet die Aktivierung der DNSSEC-Unterstützung in Postfix keine zusätzliche Sicherheit. Die DNSSEC-Unterstützung von Postfix hängt von einem vorgeschalteten rekursiven Nameserver ab, der DNSSEC-Signaturen validiert. Ein solcher DNS-Server wird immer gefälschte DNS-Antworten herausfiltern, auch wenn Postfix selbst nicht für die Verwendung von DNSSEC konfiguriert ist. Bei Verwendung der Postfix-DANE-Unterstützung sollte der Parameter smtp_host_lookup den Wert dns enthalten, da DANE nicht auf Hosts anwendbar ist, die über native Lookups aufgelöst werden. Wie bereits erwähnt, ist Postfix kein validierender Stub-Resolver; er verlässt sich auf den konfigurierten DNSSEC-validierenden rekursiven Nameserver des Systems, um die gesamte DNSSEC-Validierung durchzuführen. Da die DNSSEC-validierten Antworten dieses Nameservers vollständig vertrauenswürdig sind, wird dringend empfohlen, dass der MTA-Host über einen lokalen DNSSEC-validierenden rekursiven Caching-Nameserver verfügt, der auf einer Loopback-Adresse lauscht, und so konfiguriert ist, dass er nur diesen Nameserver für alle Lookups verwendet. Andernfalls kann Postfix für „Man-in-the-Middle-Angriffe“ anfällig sein, die Antworten vom rekursiven Nameserver fälschen. HINWEIS - Die DNSSEC-Unterstützung erfordert eine Version von Postfix, die gegen eine halbwegs moderne DNS-Resolver-Bibliothek kompiliert wurde, die die Resolver-Optionen RES_USE_DNSSEC und RES_USE_EDNS0 implementiert. |
| DNS-Unterstützung | Beschreibung |
|---|---|
disabled | Deaktiviert DNS-Lookups. Es werden keine MX-Lookups durchgeführt und Hostname-zu-Adresse-Lookups sind bedingungslos „nativ“. Diese Einstellung ist nicht für Hosts geeignet, die Mails an das öffentliche Internet zustellen. HINWEIS - In einigen veralteten Anleitungsdokumenten wird empfohlen, DNS-Lookups in einigen Konfigurationen mit content_filters zu deaktivieren. Dies ist nicht mehr erforderlich und es wird dringend davon abgeraten. |
enabled | Aktiviert DNS-Lookups. Für Nexthop-Zieldomänen, die nicht in [] eingeschlossen sind, werden MX-Lookups durchgeführt. Wenn dns und native im smtp_host_lookup-Parameterwert enthalten sind, wird zuerst DNS abgefragt, um MX-Host-A-Datensätze aufzulösen, gefolgt von nativen Suchvorgängen, wenn in DNS keine Antwort gefunden wird. |
dnssec | Aktiviert DNSSEC-Suchvorgänge. Die Einstellung dnssec unterscheidet sich in folgenden Punkten von der obigen Einstellung enabled: Alle MX-Lookups setzen RES_USE_DNSSEC und RES_USE_EDNS0, um DNSSEC-validierte Antworten anzufordern. Wenn die MX-Antwort DNSSEC-validiert ist, werden die entsprechenden Hostnamen als validiert betrachtet. Die Adressabfragen von validierten Hostnamen werden ebenfalls validiert (vorausgesetzt natürlich, smtp_host_lookup enthält dns. Vorübergehende Ausfälle bei der DNSSEC-aktivierten Auflösung von Hostnamen in Adressen blockieren alle nativen Suchvorgänge. Zusätzliche native Nachforschungen finden nur statt, wenn DNSSEC-Anfragen schwer fehlschlagen (NODATA oder NXDOMAIN). |
/etc/postfix/main.cf
Falls vorstehende Änderungen durchgeführt wurden, sollte ein Neustart von Postfix nichts mehr im Wege stehen.
Bevor der der postfix/master-Daemon/Dienst zum ersten mal gestartet werden soll, ist eine Überprüfung der korrekten Konfiguration durch nachfolgenden Befehl, zu empfehlen
postconf -n
und es sollte eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen:
# postconf -n alias_database = $alias_maps alias_maps = lmdb:${config_directory}/aliases compatibility_level = 3.9 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, server.idmz.$mydomain myhostname = mx1.tachtler.net mynetworks = 127.0.0.0/32 10.0.0.0/24 192.168.0.0/24 [::1]/128 [fd00:0:0:10::]/64 [fe80:0:0:10::]/64 [fd00:0:0:192::]/64 myorigin = server.idmz.$mydomain proxy_interfaces = 88.217.171.167 recipient_canonical_maps = lmdb:${config_directory}/recipient_canonical_maps smtp_dns_support_level = dnssec smtp_tls_CApath = ${config_directory}/ssl/certs smtp_tls_block_early_mail_reply = yes smtp_tls_chain_files = ${config_directory}/ssl/certs/server-chain.pem smtp_tls_connection_reuse = yes smtp_tls_exclude_ciphers = ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA, ECDHE-RSA-CAMELLIA256-SHA384, DHE-RSA-CAMELLIA256-SHA256, DHE-RSA-CAMELLIA256-SHA, AES256-SHA256, AES256-SHA, CAMELLIA256-SHA256, CAMELLIA256-SHA, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA, AES128-SHA256, AES128-SHA, CAMELLIA128-SHA256, CAMELLIA128-SHA smtp_tls_loglevel = 1 smtp_tls_mandatory_exclude_ciphers = ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA, ECDHE-RSA-CAMELLIA256-SHA384, DHE-RSA-CAMELLIA256-SHA256, DHE-RSA-CAMELLIA256-SHA, AES256-SHA256, AES256-SHA, CAMELLIA256-SHA256, CAMELLIA256-SHA, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA, AES128-SHA256, AES128-SHA, CAMELLIA128-SHA256, CAMELLIA128-SHA smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3 smtp_tls_protocols = >=TLSv1.2, <=TLSv1.3 smtp_tls_security_level = dane smtp_tls_session_cache_database = lmdb:${data_directory}/smtp_scache smtpd_tls_CApath = ${config_directory}/ssl/certs smtpd_tls_ask_ccert = yes smtpd_tls_chain_files = ${config_directory}/ssl/certs/server-chain.pem smtpd_tls_exclude_ciphers = ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA, ECDHE-RSA-CAMELLIA256-SHA384, DHE-RSA-CAMELLIA256-SHA256, DHE-RSA-CAMELLIA256-SHA, AES256-SHA256, AES256-SHA, CAMELLIA256-SHA256, CAMELLIA256-SHA, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA, AES128-SHA256, AES128-SHA, CAMELLIA128-SHA256, CAMELLIA128-SHA smtpd_tls_loglevel = 1 smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA, ECDHE-RSA-CAMELLIA256-SHA384, DHE-RSA-CAMELLIA256-SHA256, DHE-RSA-CAMELLIA256-SHA, AES256-SHA256, AES256-SHA, CAMELLIA256-SHA256, CAMELLIA256-SHA, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA, AES128-SHA256, AES128-SHA, CAMELLIA128-SHA256, CAMELLIA128-SHA smtpd_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3 smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = lmdb:${data_directory}/smtpd_scache tls_append_default_CA = yes tls_preempt_cipherlist = yes tls_random_bytes = 255
HINWEIS - die Konfiguration des postfix/master-Daemon/Dienst konnte korrekt gelesen werden, wenn die Konfiguration ohne Fehlermeldungen erscheint, was letztendlich zwar nicht bedeutet, das Sie auch korrekt ist, aber zumindest syntaktische Fehler ausschliesst !!!
Neustart
Zuerst sollte nun der postfix-Server mit nachfolgendem Befehle neu gestartet werden:
# systemctl restart postfix.service
Mit nachfolgendem Befehl kann der Status des Postfix-Servers abgefragt werden:
# systemctl status postfix.service
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: >
Active: active (running) since Tue 2024-11-26 06:31:38 CET; 2min 11s ago
Invocation: 72b01e328d9b4689a06b3cb0a7b45f51
Process: 4071 ExecStart=/usr/bin/postfix start (code=exited, status=0/SUCCE>
Main PID: 4316 (master)
Tasks: 3 (limit: 2315)
Memory: 2.6M (peak: 4.1M)
CPU: 238ms
CGroup: /system.slice/postfix.service
├─2143 /usr/lib/postfix/bin/master -w
├─2144 pickup -l -t unix -u
└─2145 qmgr -l -t unix -u
Nov 26 06:31:38 server systemd[1]: Starting Postfix Mail Transport Agent...
Nov 26 06:31:38 server postfix[4316]: postfix/postlog: starting the Postfix mai>
Nov 26 06:31:38 server postfix/postfix-script[4316]: starting the Postfix mail >
Nov 26 06:31:38 server postfix/master[4316]: daemon started -- version 3.9, con>
Nov 26 06:31:38 server systemd[1]: Started Postfix Mail Transport Agent.
Nachfolgender Befehl listet die IP-Adressen und die Ports auf, auf denen der Postfix-Server lauscht:
# ss -taubenp | grep postfix
tcp LISTEN 0 100 0.0.0.0:25 0.0.0.0:* users:(("master",pid=4316,fd=13))
ino:19824 sk:4 cgroup:/system.slice/postfix.service <->
tcp LISTEN 0 100 [::]:25 [::]:* users:(("master",pid=4316,fd=14))
ino:19825 sk:a cgroup:/system.slice/postfix.service v6only:1 <->
Test
Ein Test, ob die interne Kommunikation vom Postfix-null client zum Postfix-main client via TLS/StartTLS-Verschlüsselung und mittels „dane-only“ erzwungen wird, kann erst erfolgen, wenn die nachfolgenden Konfigurationen innerhalb des Konstrukts
wie folgt durchgeführt werden.
Es kann mit einem kleinen Test vom
- Postfix-null client
aus herausgefunden werden, ob lokal erzeugte e-Mails auch intern Zugestellt werden können, was ausnahmsweise mit nachfolgendem Befehl (und nicht mit telnet) durchgeführt werden soll:
# echo "Test E-Mail - DANE - null client und main server" | /usr/sbin/sendmail root
Als Ergebnis sollten zwei Dinge kontrolliert werden:
- Die Log-Einträge im
systemd-journald - Der Inhalt in der (falls nicht schon vorhandenen) neu im mbox-Format erstellten Datei
/var/spool/mail/klaus
Der Inhalte der Log-Einträge im systemd-journald auf dem
- Postfix-null client
sollte eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:
# journalctl -u postfix*
wonach eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen sollte: (Nur relevanter Ausschnitt):
Nov 26 12:00:46 client postfix/pickup[2609]: 060138A: uid=0 from=<root> Nov 26 12:00:46 client postfix/cleanup[2630]: 060138A: message-id=<20241126110046.060138A@client.idmz.tachtler.net> Nov 26 12:00:46 client postfix/qmgr[2145]: 060138A: from=<root@client.idmz.tachtler.net>, size=313, nrcpt=1 (queue active) Nov 26 12:00:46 client postfix/tlsproxy[2639]: CONNECT to [fd00::10:10:0:0:60]:25 Nov 26 12:00:46 client postfix/tlsproxy[2639]: Verified TLS connection established to mx1.tachtler.net[fd00::10:10:0:0:60]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bit raw public key) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256 Nov 26 12:00:46 client postfix/smtp[2637]: Verified TLS connection established to mx1.tachtler.net[fd00::10:10:0:0:60]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bit raw public key) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256 Nov 26 12:00:46 client postfix/tlsproxy[2639]: DISCONNECT [fd00::10:10:0:0:60]:25 Nov 26 12:00:46 client postfix/smtp[2637]: 060138A: to=<root@tachtler.net>, orig_to=<root>, relay=mx1.tachtler.net[fd00::10:10:0:0:60]:25, delay=0.18, delays=0.03/0.04/0.1/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 0D4BA180089) Nov 26 12:00:46 client postfix/qmgr[2145]: 060138A: removed
HINWEIS - Wichtig ist hier das auftauchen von
Verified TLS connection established …
Der Inhalte der Log-Einträge im systemd-journald auf dem
- Postfix-main server
sollte eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:
# journalctl -u postfix*
wonach eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen sollte: (Nur relevanter Ausschnitt):
Nov 26 12:00:45 server postfix/smtpd[4316]: connect from client.idmz.tachtler.net[fd00::10:10:0:0:80] Nov 26 12:00:46 server postfix/smtpd[4316]: Trusted TLS connection established from client.idmz.tachtler.net[fd00::10:10:0:0:80]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bit raw public key) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256 Nov 26 12:00:46 server postfix/smtpd[4316]: 0D4BA180089: client=client.idmz.tachtler.net[fd00::10:10:0:0:80] Nov 26 12:00:46 server postfix/cleanup[4320]: 0D4BA180089: message-id=<20241126110046.060138A@client.idmz.tachtler.net> Nov 26 12:00:46 server postfix/qmgr[3095]: 0D4BA180089: from=<root@vml080.idmz.tachtler.net>, size=832, nrcpt=1 (queue active) Nov 26 12:00:46 server postfix/smtpd[4316]: disconnect from client.idmz.tachtler.net[fd00::10:10:0:0:80] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Nov 26 12:00:46 server postfix/local[4321]: 0D4BA180089: to=<klaus@server.idmz.tachtler.net>, orig_to=<root@tachtler.net>, relay=local, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Nov 26 12:00:46 server postfix/qmgr[3095]: 0D4BA180089: removed
WICHTIG - Die E-Mail liegt nicht auf dem „null client“, sondern auf dem unter relayhost definierten Ziel!
Auf dem „main server“ kann der Inhalt der im mbox-Format angelegten Datei /var/spool/mail/klaus angesehen werden und sollte ebenfalls eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:
# cat /var/spool/mail/klaus
wonach eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen sollte:
# cat /var/spool/mail/klaus From root@client.idmz.tachtler.net Tue Nov 26 12:00:46 2024 Return-Path: <root@client.idmz.tachtler.net> X-Original-To: root@tachtler.net Delivered-To: root@tachtler.net Received: from client.idmz.tachtler.net (client.idmz.tachtler.net [IPv6:fd00::10:10:0:0:80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bit raw public key) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.idmz.tachtler.net", Issuer "www.tachtler.net" (verified OK)) by mx1.tachtler.net (Postfix) with ESMTPS id 0D4BA180089 for <root@tachtler.net>; Tue, 26 Nov 2024 12:00:46 +0100 (CET) Received: by client.idmz.tachtler.net (Postfix, from userid 0) id 060138A; Tue, 26 Nov 2024 12:00:46 +0100 (CET) Message-Id: <20241126110046.060138A@client.idmz.tachtler.net> Date: Tue, 26 Nov 2024 12:00:46 +0100 (CET) From: root@client.idmz.tachtler.net Test E-Mail - DANE - null client und main server