6. Examples (Beispiele)

Dieser Abschnitt enthält Beispiele für Security-Considerations-Abschnitte und soll dem Leser einen Eindruck vermitteln, was dieses Dokument meint.

Das erste Beispiel ist „rückblickend“ und wendet die Kriterien dieses Dokuments auf das weit verbreitete Protokoll SMTP an. Das zweite Beispiel ist ein guter Security-Considerations-Abschnitt aus einem aktuellen Protokoll.

6.1. SMTP (Simple Mail Transfer Protocol)

Als RFC 821 geschrieben wurde, waren Security-Considerations-Abschnitte in RFCs nicht vorgeschrieben; das Dokument enthält keinen. [RFC 2821] aktualisierte RFC 821 und fügte einen detaillierten Security-Considerations-Abschnitt hinzu. Wir geben hier diesen Abschnitt aus jenem Dokument wieder (mit neuen Abschnittsnummern). Unsere Kommentare sind eingerückt und mit „Hinweis:“ gekennzeichnet. Wir fügen neue Abschnitte zu wichtigen Themen hinzu, markiert mit [NEW] in der Überschrift.

6.1.1. Security Considerations (Sicherheitsaspekte)

6.1.1.1. Mail Security and Spoofing (E-Mail-Sicherheit und Spoofing)

SMTP-Mail ist von Natur aus unsicher, weil selbst gelegentliche Nutzer direkt mit empfangenden und weiterleitenden SMTP-Servern verhandeln und Nachrichten erzeugen können, die einen naiven Empfänger täuschen. Eine solche Nachricht so zu bauen, dass Experten das „Spoofing“ nicht erkennen, ist etwas schwerer, aber nicht genug, um Entschlossene abzuschrecken. Mit wachsender Kenntnis von Internet-Mail wächst das Bewusstsein, dass SMTP-Mail auf Transportschicht weder authentifiziert noch integritätsgeschützt werden kann. Echte Mail-Sicherheit liegt nur in Ende-zu-Ende-Methoden über den Nachrichtenkörpern, etwa mit digitalen Signaturen (siehe [14] und z. B. PGP [4] oder S/MIME [31]).

Hinweis: Ein schlechter Ansatz zur Absenderauthentifizierung ist [IDENT], bei dem der empfangende Mailserver den angeblichen Absender kontaktiert und den Benutzernamen abfragt. Das ist aus vielen Gründen schlecht, u. a. Relaying, TCP-Hijacking und einfaches Lügen des Ursprungsservers. IDENT hat geringen Sicherheitswert; der Einsatz durch empfangende Sites kann Betriebsprobleme verursachen. Viele sendende Sites verwerfen IDENT-Anfragen, Mail bleibt hängen bis zum Timeout.

Verschiedene Protokollerweiterungen und Konfigurationen mit Authentifizierung auf Transportschicht (z. B. SMTP-Client zu SMTP-Server) verbessern die traditionelle Situation etwas. Ohne sorgfältige

Übergabe von Verantwortung in einer durchdachten Vertrauensumgebung bleiben sie schwächer als Ende-zu-Ende-Mechanismen mit digital signierten Nachrichten statt Integrität des Transportsystems.

Versuche, Nutzern das Setzen von Umschlag-Rücklaufadresse und „From“-Kopf auf andere gültige Adressen zu erschweren, sind größtenteils fehlgeleitet: Sie behindern legitime Fälle (Mail im Namen anderer, Antworten an Sonderadressen). (Systeme mit bequemer Nachricht-für-Nachricht-Anpassung sollten eine primäre, dauerhafte Mailbox-Adresse führen, damit Sender-Felder sinnvoll erzeugt werden.)

Diese Spezifikation geht nicht weiter auf SMTP-Authentifizierung ein, außer zu empfehlen, nützliche Funktionen nicht zu deaktivieren, um marginale „Schutz“-Hoffnung gegen unwissende Fälscher.

Hinweis: Zusätzliches Material zu Kommunikationssicherheit und SMTP steht in Abschnitt 6.1.2; in einer finalen Spezifikation würde der obige Text entsprechend angepasst.

Adressen, die nicht in den Kopfzeilen stehen, können in RCPT-Befehlen aus vielen Gründen vorkommen. Häufig: Listenadresse als „list exploder“ und „blind copies“. Bei mehreren RCPT-Befehlen SOLLTEN Client und Server NICHT alle RCPT-Argumente in Kopfzeilen kopieren (weder Trace- noch Info-/Private-Extension-Header). Da die Regel oft verletzt wird und nicht durchsetzbar ist, KÖNNEN sendende Systeme mit „bcc“-Bewusstsein jede Blindkopie als eigene Transaktion mit nur einem RCPT senden.

Es gibt keine inhärente Beziehung zwischen „reverse“- (MAIL, SAML, …) oder „forward“- (RCPT-)Adressen in der SMTP-Transaktion („Umschlag“) und den Kopfadressen. Empfangende Systeme SOLLTEN keine solchen Beziehungen ableiten und

Kopfzeilen für die Zustellung ändern. Der „Apparently-to“-Kopf verletzt das Prinzip und führt oft zu unbeabsichtigter Informationspreisgabe und SOLLTE nicht genutzt werden.

6.1.1.3. VRFY, EXPN, and Security (VRFY, EXPN und Sicherheit)

Wie in 3.5: Einzelne Sites können VRFY und/oder EXPN aus Sicherheitsgründen abschalten. Implementierungen, die das erlauben, DÜRFEN nicht den Anschein erwecken, Adressen verifiziert zu haben, die es nicht sind. Bei Abschaltung MUSS der Server 252 zurückgeben, nicht einen mit Erfolg/Misserfolg verwechselbaren Code.

250 mit der VRFY-Adresse nach nur syntaktischer Prüfung verletzt die Regel. Immer 550 zu liefern „unterstützt“ VRFY formal nicht.

In den letzten Jahren sind Mailinglisten-Inhalte beliebte Adressquellen für „Spammer“. EXPN zum „Ernten“ nimmt zu, während Listenadministratoren Schutz einbauen. Implementierungen SOLLTEN EXPN weiter unterstützen, Sites SOLLTEN Abwägungen treffen. Mit SMTP-Authentifizierung können Sites EXPN nur authentifizierten Anfragern anbieten.

Hinweis: Unklar, ob VRFY-Abschaltung viel bringt — oft ist Gültigkeit per RCPT TO feststellbar.

6.1.1.4. Information Disclosure in Announcements (Informationspreisgabe in Ankündigungen)

Dauernd wird diskutiert: Debugging-Nutzen durch Bekanntgabe von Servertyp/-version (manchmal Domain) in Begrüßung oder HELP versus Risiko für Angriffe. Der Debugging-Nutzen steht fest. Befürworter argumentieren, den Server wirklich zu sichern sei besser als Schwachstellen durch Verstecken der Identität zu „schützen“. Sites sollen abwägen; Implementierungen werden dringend ermutigt, Typ/Version mindestens irgendwie anderen Hosts zugänglich zu machen.

6.1.1.5. Information Disclosure in Trace Fields (Informationspreisgabe in Trace-Feldern)

Wenn Mail aus einem LAN kommt, dessen Hosts nicht direkt im öffentlichen Internet stehen, können konforme Trace- („Received“-)Felder Hostnamen preisgeben, die sonst nicht sichtbar wären. Meist unkritisch; Sites mit Namensbedenken sollten es wissen. Die optionale FOR-Klausel bei mehreren Empfängern vorsichtig oder gar nicht setzen, um Blindkopien nicht zu verraten.

6.1.1.6. Information Disclosure in Message Forwarding (Informationspreisgabe beim Nachrichtenweiterleiten)

Wie 3.4: Nutzung von 251/551 zur Ersatzadresse kann sensible Daten preisgeben. Betroffene Sites sollten Serverwahl und -konfiguration sorgfältig treffen.

6.1.1.7. Scope of Operation of SMTP Servers (Geltungsbereich des SMTP-Serverbetriebs)

Ein SMTP-Server darf aus betrieblichen oder technischen Gründen Mail ablehnen. Kooperation macht das Internet möglich. Übermäßiges Ablehnen bedroht die allgegenwärtige E-Mail-Verfügbarkeit; Ausgewogenheit ist nötig.

Relay über beliebige Sites wurde genutzt, um Ursprünge zu verschleiern. Manche Sites beschränken Relay auf bekannte Quellen; Implementierungen SOLLTEN solche Filter ermöglichen. Bei Ablehnung aus Richtliniengründen SOLLTE 550 auf EHLO, MAIL oder RCPT passend verwendet werden.

6.1.1.8. Inappropriate Usage (Unangemessene Nutzung)

SMTP schützt nicht vor unerwünschter Massen-Werbemail (Spam). A priori Spam von Nicht-Spam zu unterscheiden ist extrem schwer. Protokollseitig ist Spam nicht von anderer Mail zu trennen — fast nur sozial/subtil. (Werbemail eines Händlers, bei dem man kaufte — Spam?) Anti-Spam beschränkt sich oft auf bekannte Spammer zu blockieren oder zu bestrafen. [RFC-2505] gibt umfangreiche Hinweise. Kurz hier.

Hauptwerkzeug: Blacklists. Autoritäten wie [MAPS] listen bekannte Spammer; Server blockieren IPs.

Zur Vermeidung von Blacklists verschleiern Spammer Identität (falsche SMTP-Identität, Open Relay). Daher auch Blacklists [ORBS] für offene Relays.

6.1.1.8.1. Closed Relaying (Geschlossenes Relaying)

Viele Server sind geschlossene Relays und relayen nur für identifizierbare Clients. Relays sollten konsistente Absenderadresse zur bekannten Identität verlangen. Für identifizierbare Netze (Firma, ISP) reicht es, alle anderen IP-Adressen zu blockieren. Sonst explizite Authentifizierung: TLS [STARTTLS] und SASL [SASLSMTP].

6.1.1.8.2. Endpoints (Endpunkte)

Realistisch können SMTP-Endpunkte nicht allen unauthentifizierten Absendern den Dienst verweigern — das bräche Interoperabilität. Ausnahme: Endpunkt empfängt nur von einem anderen Server, der wiederum unauthentifizierte Nachrichten annehmen kann. Beispiel: öffentliches Gateway, interne Server nur zum Gateway.

6.1.2. Communications security issues (Kommunikationssicherheit)

SMTP bietet keine Kommunikationssicherheit — viele Angriffe möglich. Passiv reicht, um Klartext zu lesen. Keine Endpunktauthentifizierung. Absender-Spoofing und Mail-Fälschung trivial. Manche Implementierungen fügen Hostnamen per Reverse-DNS hinzu (nur so sicher wie DNS schwer zu spoofen ist — wenig), meist unsichtbar für Nutzer. Empfänger-Spoofing via Hijack oder DNS-Spoofing. Gateways erfordern Vertrauen in alle Zwischenstationen — auf dem globalen Internet fast unmöglich.

Gegenmaßnahmen, Schicht für Schicht höher: SMTP über IPSEC, SMTP/TLS, S/MIME und PGP/MIME.

6.1.2.1. SMTP over IPSEC (SMTP über IPsec)

SMTP über IPSEC kann Vertraulichkeit zwischen Absender und erstem Hop oder zwischen Gateways bieten — Kanalsicherheit für SMTP. Direkt vom Client zum Gateway des Empfängers kann das stark helfen (Empfänger vertraut trotzdem dem Gateway). Schutz vor Replay, da Daten und Pakete geschützt sind.

Endpunktidentifikation problematisch ohne kryptographische Authentifizierung der Empfängeradresse. Absenderidentifikation fehlt meist — nur Maschine authentifiziert. Absenderidentität steht im From-Kopf — leicht spoofbar. Ohne strenge Policy auch aktiver Downgrade zu Klartext.

Fehlende standardisierte IPsec-API erschwert portable Nutzung.

Implementierer/Administratoren DÜRFEN NICHT IPsec voraussetzen ohne Anhaltspunkte (z. B. bestehende SA). Opportunistischer Aufbau einer SA zum Peer beim Zustellen kann sinnvoll sein. VPN-Tunnel zwischen Sites hat großen Wert bei Vertraulichkeit, mit den genannten Einschränkungen. Siehe [USEIPSEC].

6.1.2.2. SMTP/TLS (SMTP über TLS)

SMTP mit TLS [STARTTLS] ähnlich IPSEC. TLS-Zertifikate enthalten Hostnamen — Empfängerauthentifizierung etwas klarer, aber DNS-Spoofing möglich. Viele TLS-Implementierungen haben exportierbaren (schwachen) Modus — für hohe Sicherheit deaktivieren. Replay-Schutz wie bei IPSEC. [Hinweis: Security Considerations im SMTP-over-TLS-Dokument sind lesenswert.]

6.1.2.3. S/MIME and PGP/MIME (S/MIME und PGP/MIME)

S/MIME und PGP/MIME sind nachrichtenorientiert — Objektsicherheit pro Nachricht. Je nach Einstellung Absender-/Empfängerauthentifizierung und Vertraulichkeit. Identifikation betrifft Personen/Schlüssel, nicht nur Maschinen — Ende-zu-Ende möglich. Kein Replay-Schutz. Identifizierungsmerkmale ermöglichen Verkehrsanalyse trotz Vertraulichkeit.

6.1.3. Denial of Service (Dienstverweigerung)

Diese Maßnahmen schützen nicht vor DoS. SMTP-Verbindungen können Ports, Platte (Mail auf Disk), Speicher (sendmail fork pro Nachricht) binden.

Mit Transport-/Anwendungssicherheit sind Angriffe mit gefälschten RSTs oder Injektion auf einzelne Verbindungen möglich.

6.2. VRRP (Virtual Router Redundancy Protocol)

Das zweite Beispiel stammt aus VRRP, Virtual Router Redundancy Protocol ([VRRP]). Wir geben den Security-Considerations-Abschnitt (neu nummeriert) wieder. Kommentare mit „Hinweis:“.

6.2.1. Security Considerations (Sicherheitsaspekte)

VRRP ist für verschiedene Internetworking-Umgebungen mit unterschiedlichen Sicherheitsrichtlinien gedacht. Das Protokoll umfasst mehrere Authentifizierungsarten: keine, Klartextpasswörter, starke Authentifizierung mit IP Authentication und MD5 HMAC. Details zu Angriffen und empfohlenen Umgebungen folgen.

Unabhängig vom Authentifizierungstyp enthält VRRP TTL=255 setzen und beim Empfang prüfen — schützt vor Injektion aus fernen Netzen. Die meisten Schwachstellen bleiben lokal.

Hinweis: Die folgenden Maßnahmen bieten nur Authentifizierung, keine Vertraulichkeit — explizit außerhalb des Umfangs nennen.

6.2.1.1. No Authentication (Keine Authentifizierung)

Keine Authentifizierung: VRRP-Austausch unauthentifiziert. SOLLTE nur bei minimalem Risiko und geringer Fehlkonfigurationswahrscheinlichkeit genutzt werden (z. B. zwei VRRP-Router im LAN).

6.2.1.2. Simple Text Password (Einfaches Klartextpasswort)

Klartextpasswort authentifiziert den Austausch.

Nützlich gegen versehentliche Fehlkonfiguration und versehentliches Backup zwischen Routern. Neuer Router braucht korrektes Passwort. Schützt nicht vor aktiven Angreifern, die das Passwort im LAN abhören. Simple Text plus TTL erschwert Angriffe von anderen LANs.

EMPFOHLEN bei geringem Risiko aktiver Störung im LAN. Nutzer wissen: Passwort wird oft gesendet — nicht dasselbe wie sicherheitskritische Passwörter.

Hinweis: Klarer machen: keine Auth und Klartext nur für sehr eingeschränktes Bedrohungsmodell (keine böswilligen Knoten im LAN). TTL blockiert Off-LAN, nicht On-LAN-Impersonation. Kompromittierung eines LAN-Knotens reicht zur VRRP-Umstellung — fragiles Modell.

6.2.1.3. IP Authentication Header (IP-Authentifizierungsheader)

IP Authentication Header [AH] mit [HMAC] authentifiziert stark gegen Fehlkonfiguration, Replay und Paketmanipulation.

EMPFOHLEN bei begrenzter Kontrolle über LAN-Administration. Schützt VRRP, nicht andere Angriffe auf geteilte Medien (z. B. gefälschte ARP), unabhängig von VRRP.

Hinweis: AH hier nur EMPFOHLEN ist ein Fehler — gegen Angriffe im selben LAN ist AH oft einzige Schutz und sollte MUST sein, wenn nicht vertrauenswürdige Knoten im Netz sind. AH sollte MUST implement sein.

Hinweis: Kosten-Nutzen von VRRP-Authentifizierung wird nur angedeutet.

[Rest dieses Abschnitts ist NEUES Material] VRRP-Authentifizierung soll verhindern, dass ein Angreifer VRRP-Master wird — Gruppe beitreten (mehrfach), Master „stumm schalten“, sich wählen — dann Verkehr umleiten.

Der Angreifer muss aber nicht Master sein: ARP-Fälschung oder Switch-Täuschung schaden ähnlich; VRRP-Auth schützt nicht.

Authentifizierung macht VRRP bei Fehlkonfiguration spröde: unterschiedliche Passwörter — beide Master — Instabilität.

Diese Abwägung legt nahe, VRRP-Auth ist fragwürdig: marginaler Sicherheitsgewinn, hohes Risiko. Neu bewerten, wenn nicht-VRRP-Bedrohungen wegfallen.