Server-Hardening Grundlagen für E-Mail-Workloads

E-Mail-Server sind hochwertige Angriffsziele — sie haben oft direkten Internet-Zugang, verarbeiten Daten von externen Quellen und können bei Übernahme als Spam-Schleuder oder für Daten-Exfiltration missbraucht werden. Server-Hardening für E-Mail-Workloads ist daher kein optionales Sicherheits-Add-on, sondern grundlegende operative Praxis.

Bedrohungs-Modell für E-Mail-Server

• Open Relay Missbrauch: Angreifer nutzen Ihren MTA für Spam. Konsequenz: Reputations-Verlust.
• SMTP-AUTH-Brute-Force: bei Erfolg voller Versand-Zugriff.
• Bekannte Software-Lücken: ungepatschte CVEs in Postfix, Exim, OpenDKIM.
• SSH-Brute-Force: Standard-Angriff auf Port 22.
• Konfigurations-Fehler: offene Services, permissive Firewall-Regeln.

Schicht 1: Netzwerk-Hardening

# UFW-Beispiel auf Ubuntu
ufw allow 2222/tcp comment 'SSH'
ufw allow 587/tcp comment 'SMTP submission'
ufw allow 465/tcp comment 'SMTPS'
ufw allow out 25/tcp comment 'SMTP outbound'
ufw default deny incoming
ufw default allow outgoing
ufw enable

SSH absichern

# /etc/ssh/sshd_config
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300

Plus Fail2ban für SSH und SASL-Failures:

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600

[postfix-sasl]
enabled = true
port = 587,465
maxretry = 5
bantime = 7200

Schicht 2: SMTP-Service-Hardening

# /etc/postfix/main.cf
smtpd_recipient_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

smtpd_sender_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

smtpd_helo_required = yes
smtpd_client_connection_rate_limit = 30
smtpd_banner = $myhostname ESMTP
mail_name = Mail Server

SMTP-AUTH absichern

• Nur PLAIN/LOGIN über TLS — keine Klartext-Authentifizierung
• Lange, randomisierte Passwörter (32+ Zeichen)
• Pro Anwendung eigenes SMTP-User
• Fail2ban-Filter für SASL-Failures
• Rotation alle 6-12 Monate

Schicht 3: TLS-Konfiguration

# /etc/postfix/main.cf TLS
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mta.ihr-unternehmen.de/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mta.ihr-unternehmen.de/privkey.pem
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4

Für maximale Sicherheit MTA-STS konfigurieren — zwingt Empfänger zu TLS mit Certificate-Validation:

# DNS-Eintrag
_mta-sts.ihr-unternehmen.de. IN TXT "v=STSv1; id=20260101000000Z"

# HTTPS-Endpoint
https://mta-sts.ihr-unternehmen.de/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mta1.ihr-unternehmen.de
max_age: 604800

Schicht 4: Patch-Management

• Automatisierte Security-Updates: unattended-upgrades für Security-Patches
• Manuelles Review für Major-Versions: Postfix 3.x → 4.x mit Tests
• CVE-Monitoring: Subscribe zu Postfix/Exim Security-Mailing-Listen
• Patch-Window: definierte Wartungs-Fenster mit Rollback-Plan

Schicht 5: Monitoring und Audit-Logs

# Wichtige Log-Quellen
/var/log/mail.log              # Allgemeine SMTP-Events
/var/log/mail.err              # Fehler-Log
/var/log/auth.log              # SSH-Logins, sudo
/var/log/fail2ban.log          # Blocked IPs
/var/log/audit/audit.log       # File-Access, Konfig-Änderungen

Logs sollten zentralisiert in SIEM oder Log-Aggregation (Graylog, Loki, Splunk) — lokale Logs sind bei Server-Kompromittierung möglicherweise manipuliert.

DACH-spezifische Compliance-Aspekte

BSI IT-Grundschutz: Bausteine APP.5.3 (E-Mail-Server) definiert spezifische Hardening-Anforderungen.

DSGVO Art. 32: technische und organisatorische Maßnahmen — Verschlüsselung in Transit, Zugangs-Kontrolle, Pseudonymisierung wo möglich.

Branchenspezifische Standards: BAIT (Banken), VAIT (Versicherungen), KAIT (Kapitalverwaltungsgesellschaften).

Self-Hosting vs. gemanagter Service

Bei Self-Hosting tragen Sie volle Hardening-Verantwortung. Bei gemanagten Services übernimmt der Anbieter Infrastruktur-Hardening, Sie behalten Konfigurations-Aspekte (SMTP-AUTH-Credentials, Anwendungs-Rate-Limits).

Bei Authorize Hosting ist Server-Hardening Bestandteil des Standard-Services — wir betreiben unsere MTA-Infrastruktur nach BSI IT-Grundschutz mit dokumentierter Patch-Pipeline und Audit-Log-Aggregation. Compliance-Dokumentation auf Anfrage für Ihre eigenen Audits verfügbar.