Postfix absichern: Best Practices für die main.cf und der nächste logische Schritt

Ein Linux-Server, ein offener Port 25 und die Welt kann anklopfen. Für Systemadministratoren ist Postfix ein geniales Werkzeug: Es ist blitzschnell, extrem stabil und lässt sich bis ins kleinste Detail konfigurieren. Doch genau hier liegt die Herausforderung. Postfix im Standard-Setup auszuliefern, gleicht heutzutage grober Fahrlässigkeit.

In diesem Guide zeigen wir dir konkrete Konfigurations-Snippets für deine main.cf, um deinen Mailserver vor den gröbsten Angriffen zu schützen. Gleichzeitig werfen wir einen ungeschönten Blick auf die architektonischen Grenzen von Postfix – und zeigen, warum moderne IT-Infrastrukturen das Filtern von E-Mails längst auslagern.

TL;DR – Die wichtigsten Schritte auf einen Blick:

1. Setze strenge smtpd_recipient_restrictions in der main.cf.
2. Aktiviere Postscreen, um Zombie-Bots direkt am Port 25 abzuwehren, bevor der smtpd-Prozess startet.
3. Binde etablierte RBLs (Real-time Blackhole Lists) ein.
4. Erkenne die Grenzen: Für Enterprise-Security, Zero-Day-Schutz und NIS2-Compliance reicht lokales Tuning oft nicht mehr aus. Hier ist ein E-Mail Secure Gateway der Best-Practice-Standard.

1. Die main.cf härten: Hands-on Best Practices

Die main.cf ist das Herzstück deines Postfix-Servers. Mit den richtigen Restriktionen sortierst du bereits 80 % des automatisierten Rauschens aus.

smtpd_recipient_restrictions richtig setzen

Diese Parameter entscheiden, wem dein Server E-Mails abnimmt und wohin er sie weiterleitet. Eine restriktive Konfiguration ist Pflicht, um nicht als Open Relay zu enden.

Füge folgende Parameter in deine main.cf ein:

Bash

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_invalid_helo_hostname,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client b.barracudacentral.org

Was passiert hier?

• reject_unauth_destination: Verhindert, dass dein Server als Open Relay missbraucht wird.
• reject_unknown_*: Blockt E-Mails ab, deren Absender- oder Empfänger-Domains nicht einmal via DNS (MX- oder A-Record) auflösbar sind – ein klassisches Spam-Muster.
• reject_rbl_client: Prüft die einliefernde IP-Adresse gegen etablierte Blacklists und lehnt die Verbindung bei einem Treffer direkt ab.

Zombie-Bots blocken mit Postscreen

Normale Spam-Filter fressen CPU und RAM. Wenn ein Botnet deinen Server mit tausenden Verbindungen flutet (z.B. bei einer Directory Harvest Attack), geht dein Server in die Knie. Postscreen schaltet sich vor den eigentlichen Postfix-Daemon (smtpd) und verlangt von einliefernden Servern ein standardkonformes SMTP-Verhalten. Bots scheitern hier meistens.

Aktiviere Postscreen in der master.cf:

Bash

smtp      inet  n       -       y       -       1       postscreen
smtpd     pass  -       -       y       -       -       smtpd

In der main.cf konfigurierst du dann die Härte:

Bash

postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3, b.barracudacentral.org*2
postscreen_dnsbl_threshold = 3

2. Die Schmerzgrenze: Wann Bordmittel nicht mehr reichen

Wenn du diese Konfigurationen sauber umgesetzt hast, hast du den Grundstein gelegt. Doch die Realität im IT-Betrieb sieht oft düster aus:

1. Maintenance-Hölle: Blacklists ändern sich, False-Positives häufen sich. Administratoren verbringen Stunden damit, legitime E-Mails aus der Quarantäne zu fischen oder Logfiles (/var/log/mail.log) nach abgewiesenen Kunden-Mails zu durchsuchen.
2. Ressourcenfraß: Tools wie SpamAssassin und ClamAV direkt auf dem Mailserver laufen zu lassen, kostet massiv Hardware-Ressourcen.
3. Fehlender Zero-Day-Schutz: Postfix-Bordmittel reagieren meist auf bekannte schlechte IPs oder Signaturen. Gegen polymorphe Viren, hochspezialisierte Phishing-Kampagnen oder ausgeklügelte SMTP-Enumeration sind sie weitgehend machtlos.

IT-Security hat sich gewandelt. Die Zeiten, in denen der Mailserver gleichzeitig auch die Firewall spielen musste, sind vorbei.

3. Der Architektur-Shift: Postfix + Secure Email Gateway

Moderne Infrastruktur-Architektur folgt einem simplen Prinzip: Lass Postfix das tun, wofür es gebaut wurde (E-Mails zuverlässig zustellen). Und lass eine spezialisierte Security-Schicht die Angriffe abwehren.

Anstatt den Traffic erst auf dein lokales Netzwerk prallen zu lassen, schaltest du ein dediziertes E-Mail Secure Gateway vor.

Vergleich: Postfix Standalone vs. Gateway-Architektur

E-Mail-Security auf Enterprise-Niveau: Wie Conbool deinen Mailserver entlastet

Wenn es darum geht, kritische Infrastrukturen – von M365-Tenants bis hin zu On-Premise Postfix-Servern – abzusichern, setzt Conbool exakt an diesem Schmerzpunkt an.

Als spezialisiertes E-Mail Secure Gateway fungiert Conbool als unsichtbarer Schutzschild vor deiner Infrastruktur:

• Schmutz bleibt draußen: Bösartiger Traffic erreicht deinen Postfix-Server gar nicht erst. Das spart Bandbreite und Server-Ressourcen.
• Maximale Compliance: Im Rahmen der neuen NIS2-Richtlinien ist eine hochsichere E-Mail-Infrastruktur unerlässlich. Mit Conbool und unseren ISO 27001 zertifizierten Hosting-Partnern baust du auf ein verlässliches Fundament.
• Kein administrativer Overhead: Wir kümmern uns um die Aktualisierung von Signaturen, Reputationsdatenbanken und Sandboxing. Dein IT-Team gewinnt wertvolle Stunden zurück.

Fazit: Einen Mailserver abzusichern, ist heute keine Frage mehr von komplexen Konsolen-Befehlen, sondern eine Frage der richtigen Architektur. Entlaste deinen Postfix-Server und sichere deine Unternehmenskommunikation kompromisslos ab.

Bereit für eine saubere Infrastruktur? Erfahre mehr über das E-Mail Secure Gateway von Conbool und lagere deinen E-Mail-Schutz an Experten aus.