Zum Hauptinhalt springen

7. Sicherheitsüberlegungen (Security Considerations)

7.1. Mail-Sicherheit und Spoofing (Mail Security and Spoofing)​

SMTP-Mail ist von Natur aus nicht sicher aufgrund von: Fehlen integrierter Authentifizierungsmechanismen, Leichtigkeit des Absenderadressen-Spoofings, Fehlen von Verschlüsselung im Grundprotokoll. Zusätzliche Protokolle wie SPF, DKIM und DMARC helfen, Spoofing zu mildern.

7.2. "Blindkopien" ("Blind" Copies)​

BCC (Blind Carbon Copy, Blindkopie)-Empfänger DÜRFEN NICHT (MUST NOT) in Nachrichtenheadern erscheinen. Dies wird normalerweise durch Erstellen separater SMTP-Transaktionen für BCC-Empfänger oder Entfernen von BCC-Header-Feldern vor dem Senden gehandhabt.

7.3. VRFY, EXPN und Sicherheit (VRFY, EXPN, and Security)​

VRFY- und EXPN-Befehle können verwendet werden, um gültige E-Mail-Adressen zu sammeln. Server KÖNNEN (MAY): Diese Befehle deaktivieren, Authentifizierung vor Verwendung erfordern, generische Antworten zurückgeben.

7.4. Mail-Umleitung basierend auf Antwortcodes 251 und 551 (Mail Rerouting Based on the 251 and 551 Response Codes)​

Antwortcodes 251 und 551 können ausgenutzt werden. Server SOLLTEN (SHOULD) vorsichtig mit automatischer Weiterleitung und in diesen Antworten offengelegten Informationen sein.

7.5. Informationsoffenlegung in Ankündigungen (Information Disclosure in Announcements)​

Server-Begrüßungen (220-Antwort) und EHLO-Antworten SOLLTEN NICHT (SHOULD NOT) detaillierte Softwareversions-Informationen, interne Systemarchitektur oder Sicherheitskonfigurations-Details offenlegen.

7.6. Informationsoffenlegung in Trace-Feldern (Information Disclosure in Trace Fields)​

Received-Header-Felder enthalten IP-Adressen, Hostnamen, Timing-Informationen und interne Netzwerktopologie. Diese Informationen kann für Netzwerk-Mapping, Traffic-Analyse und Identifikation der Sicherheitsinfrastruktur verwendet werden.

7.7. Informationsoffenlegung beim Nachrichtenweiterleiten (Information Disclosure in Message Forwarding)​

Beim Weiterleiten von Nachrichten SOLLTEN (SHOULD) Server: Offenlegung interner Adressen vermeiden, Trace-Informationen beim Überqueren von Vertrauensgrenzen bereinigen, Datenschutzauswirkungen der automatischen Weiterleitung berücksichtigen.

7.8. Widerstandsfähigkeit gegen Angriffe (Resistance to Attacks)​

SMTP-Server SOLLTEN (SHOULD) Schutzmaßnahmen gegen die folgenden Angriffsarten implementieren:

Denial of Service (DoS)​

  • Verbindungslimits pro Quelle
  • Rate Limiting
  • Begrenzung des Ressourcenverbrauchs
  • Durchsetzung von Timeouts

Pufferüberläufe​

  • Strikte Eingabevalidierung
  • Durchsetzung von Längenlimits
  • Sichere String-Verarbeitung

Befehlsinjektion​

  • Korrektes Parsen von Befehlen
  • Validierung von Argumenten
  • Zurückweisung fehlerhaft geformter Eingaben

Directory-Harvest-Angriffe​

  • Rate Limiting für RCPT-TO-Befehle
  • Verzögerte oder generische Antworten
  • Protokollierung und Blockierung von Scan-Verhalten

7.9. Betriebsumfang von SMTP-Servern (Scope of Operation of SMTP Servers)​

SMTP-Server SOLLTEN (SHOULD) ihren Betriebsumfang klar definieren, geeignete Zugriffskontrollen implementieren und zwischen interner Nachrichteneinreichung, externer Nachrichtenweiterleitung und endgültiger Nachrichtenzustellung unterscheiden. Open Relays (offene Relays), also Server, die Mail von jedem Absender an jedes Ziel annehmen und weiterleiten, DÜRFEN NICHT (MUST NOT) bereitgestellt werden, weil sie Spam-Verteilung ermöglichen, Missbrauch erleichtern und die Internet-Mail-Infrastruktur schädigen.

Empfohlene Sicherheitspraktiken​

  1. TLS/STARTTLS verwenden
  2. Authentifizierung implementieren (SMTP AUTH)
  3. SPF/DKIM/DMARC bereitstellen
  4. Rate Limiting
  5. Zugriffskontrollen
  6. Protokollierung
  7. Regelmäßige Updates
  8. Überwachung
Letztes Update am