Sichere Nutzung von (ISi-Mail-Client)

Transkript

1 Sichere Nutzung von (ISi-Mail-Client) BSI-Studie zur Internet-Sicherheit (ISi-S) Version 1.0

2 ISi-Reihe ISi-S Sichere Nutzung von Vervielfältigung und Verbreitung Bitte beachten Sie, dass das Werk einschließlich aller Teile urheberrechtlich geschützt ist. Erlaubt sind die Vervielfältigung und Verbreitung zu nicht-kommerziellen Zwecken, insbesondere zu Zwecken der Ausbildung, Schulung, Information oder hausinternen Bekanntmachung, sofern sie unter Hinweis auf die ISi-Reihe des BSI als Quelle erfolgen. Dies ist ein Werk der ISi-Reihe. Ein vollständiges Verzeichnis der erschienenen Bände findet man auf den Internet-Seiten des BSI. oder Bundesamt für Sicherheit in der Informationstechnik ISi-Projektgruppe Postfach Bonn Tel. +49 (0) Internet: Bundesamt für Sicherheit in der Informationstechnik Bundesamt für Sicherheit in der Informationstechnik

3 ISi-S Sichere Nutzung von ISi-Reihe Vorwort Liebe Leserinnen und Leser, immer mehr Prozesse verlagern sich in die virtuelle Welt des Internets: Kommunikation und Datenaustausch erfolgen per , Bankgeschäfte und Einkäufe werden zunehmend online getätigt. Dabei müssen häufig persönliche und vertrauliche Daten über das Internet versendet werden. Diese sind ein attraktives und lukratives Ziel für Online-Kriminelle, die heute international organisiert und professionell strukturiert zusammen arbeiten. IT-Kriminalität ist für die Angreifer ein lohnenswertes Geschäft bei vergleichsweise niedrigem Risiko. Identitätsdiebstahl und Angriffe mit Schadprogrammen unterschiedlichster Art gehören bei der Nutzung des Internets zu den ernstzunehmenden Bedrohungen für alle Anwender. Diesen Gefahren muss man mit umfangreichen IT-Sicherheitsmaßnahmen entgegentreten. Die BSI-Schriftenreihe zur Internet-Sicherheit (ISi-Reihe) beschäftigt sich mit einzelnen Aspekten der Internet-Sicherheit. Das Modul Sichere Nutzung von beleuchtet Sicherheitsaspekte aus Sicht der Anwender. Es zeigt mögliche Gefährdungen auf und gibt konkrete Empfehlungen für Schutzmaßnahmen. Bonn, im März 2009 Dr. Udo Helmbrecht Präsident des Bundesamtes für Sicherheit in der Informationstechnik Bundesamt für Sicherheit in der Informationstechnik 3

4 ISi-Reihe ISi-S Sichere Nutzung von Inhaltsverzeichnis 1 Einleitung Grundlagen Kommunikation Komponenten Funktionen eines -Clients Protokolle Kommunikationsprotokoll POP Kommunikationsprotokoll IMAP Kommunikationsprotokoll SMTP Kommunikationsschnittstelle MAPI Protokolle für den Adressbuchzugriff Protokolle für den Kalenderzugriff Protokolle zur Authentisierung Übersicht der Protokolle Aufbau und Formate Struktureller Aufbau von s Zeichensätze Dateianhänge Lesebestätigungen HTML Dateien/Postfächer Adressbücher Kalender Übersicht der Formate Sicherheitskomponenten Anti-Phishing Spam-Filter Virenschutzprogramme Personal Firewall Digitale Signatur und Verschlüsselung Standards Übersicht der Standards MailTrusT, SPHINX und Ägypten Sichere Grundarchitektur für normalen Schutzbedarf Sichere -Client-Architektur Komponenten der -Client-Architektur Ein- und ausgehende s Sichere Anbindung der -Clients an den internen -Server Nutzung von S/MIME Beschreibung der Komponenten Sicherheitsaspekte bei der Benutzung von S/MIME gesicherten Nachrichten Nutzung von OpenPGP Beschreibung der Komponenten Sicherheitsaspekte bei der Benutzung von OpenPGP gesicherten Nachrichten Sichere Nutzung der Virtuellen Poststelle Komponenten sicher auswählen, konfigurieren und betreiben (normaler Schutzbedarf) Grundanforderungen an ein sicheres Produkt Bundesamt für Sicherheit in der Informationstechnik

5 ISi-S Sichere Nutzung von ISi-Reihe Client Client-Software / Plug-Ins Virenschutzprogramm Anti-Phishing-Software Anti-Spam-Software Personal Firewall Sichere Grundkonfiguration der Komponenten Client Client-Software Virenschutzprogramme Anti-Phishing-Software Anti-Spam-Software Personal Firewall Grundvorgaben für einen sicheren Betrieb Allgemein Richtlinie Client-Software Virenschutzprogramm Anti-Phishing-Software Anti-Spam-Software Personal Firewall Gefährdungen und Empfehlungen mit Varianten für normalen und hohen Schutzbedarf Gefährdungen durch Eindringen Computer-Viren und Würmer Viren und Würmer in verschlüsselten s Nicht aktuelle Virenschutzprogramme Nachladen von Programmen über MIME-Types HTML- Aktive Inhalte HTML- IFrames HTML- OBJECT-Tags Exploits Gefährdungen durch Täuschen, Fälschen und Betrügen Trojanische Pferde Fälschen von Header/Envelope-Daten (Spoofing) Manipulation des Absenderfeldes einer Nachricht (Spoofing) Fälschen von -Inhalten (Spoofing) Verschleierung von Dateianhängen (Spoofing) Hoax Nichtanerkennung einer Nachricht Gefährdungen durch Entwenden und Ausspähen Spyware/Adware Phishing: Ausspähen personenbezogener oder vertraulicher Daten Protokolle ohne Verschlüsselung Gemeinsame Benutzung eines PCs Automatisches Weiterleiten von s Web Bugs Automatische Lesebestätigungen Kompromittierung privater Schlüssel (OpenPGP, S/MIME) Gefährdungen durch Verhindern und Zerstören Spam In Anhängen versteckter Spam Joe-Job-Angriffe Ausgehende DoS-Angriffe Verlust der Verfügbarkeit lokal gespeicherter s Verlust der privaten Schlüssel (VPS, OpenPGP oder S/MIME)...94 Bundesamt für Sicherheit in der Informationstechnik 5

6 ISi-Reihe ISi-S Sichere Nutzung von 5.5 Gefährdungen auf einen Blick Fazit Literaturverzeichnis Anhang Abdeckungsmatrix Glossar Stichwort- und Abkürzungsverzeichnis Bundesamt für Sicherheit in der Informationstechnik

7 ISi-S Sichere Nutzung von ISi-Reihe 1 Einleitung Die ISi-Reihe bietet allen mit der IT-Sicherheit befassten Personen in Behörden und Unternehmen umfassende und aktuelle Informationen zu weiten Bereichen der IT-Sicherheit. Durch ihren Aufbau aus mehreren Teilen wendet sie sich zielgruppenspezifisch an Entscheidungsträger (mit dem Leitfaden ISi-L) sowie an diejenigen, die mit der Umsetzung der IT-Sicherheit betraut sind (Studien ISi-S und Checklisten ISi-Check). Die unterschiedlichen Module der ISi-Reihe befassen sich jeweils mit einem sicherheitsrelevanten Teilbereich von IP-Netzen und IP-Diensten. s sind als Kommunikationsmittel aus Behörden und Unternehmen heute kaum noch wegzudenken. Die Vorteile dieser Art der Mitteilung sind unbestritten, so dass die Handlungsfähigkeit einer Organisation in hohem Maße vom Funktionieren des -Systems abhängt. Es erfolgen häufig Angriffe auf dieses System, um dessen Verfügbarkeit zu beeinträchtigen und an Informationen durch Ausspähen von s zu gelangen. Die Sicherung dieser Lebensader der Kommunikation muss für alle Beteiligten eine hohe Priorität einnehmen. Die vorliegende Studie zeigt auf, wie sich Behörden und Unternehmen gegen diese Gefahren schützen können. Sie stellt eine Grundarchitektur für den -Client vor (in Abschnitt 3), die unter den Gesichtspunkten der IT-Sicherheit dem Schutz der fundamentalen Grundwerte Vertraulichkeit, Verfügbarkeit, Integrität und Authentizität Rechnung trägt. Empfehlungen zur Konfiguration und zum Betrieb runden die Darstellung ab (Abschnitt 4). Die Anforderungen an die IT-Sicherheit variieren von Organisation zu Organisation. Um hier individuelle Anpassungen vorzunehmen, beispielsweise für den hohen Schutzbedarf oder Anpassungen an die Größe der Organisation, werden Varianten vorgestellt (Abschnitt 5), bewertet und Gefährdungen zugeordnet. Zusammen mit der Studie zu -Server [ISi-Mail-Server] können bestehende Systeme sicherer gemacht werden oder auch neue konzipiert, umgesetzt und betrieben werden. Hierzu sind die Checklisten, die ergänzend zu jedem Modul veröffentlicht werden, eine praktische Hilfe. Bundesamt für Sicherheit in der Informationstechnik 7

8 ISi-Reihe ISi-S Sichere Nutzung von 2 Grundlagen Die nachfolgenden Abschnitte befassen sich mit wesentlichen Grundlagen zur Nutzung von . Diese Grundlagen sind die Basis für das Verständnis der übrigen Abschnitte und umfassen die an einer -Kommunikation beteiligten Komponenten, die Funktionen eines -Clients, die Kommunikationsprotokolle, die Verfahren zur Authentisierung, den Aufbau einer und verwendete Formate, die -Sicherheitskomponenten und die digitale Signatur und Verschlüsselung Kommunikation Eine genauere Betrachtung der -Kommunikation zeigt, dass der -Client und der -Server mehrere Komponenten umfasst (Abschnitt 2.1.1). Neben dem eigentlichen Verwendungszweck dem Lesen, Schreiben und Versenden von s bietet der -Client auch weitergehende Funktionen (Abschnitt 2.1.2) Komponenten Eine -Kommunikation umfasst verschiedene Funktionen, die als gesonderte Dienstkomponenten sogenannte Mail Agents darstellbar sind. Die wesentlichen Elemente, die an einer E- Mail-Kommunikation beteiligt sind, werden in Abbildung 2.1 dargestellt und im Folgenden beschrieben. Zu einer -Kommunikation gehören ein Absender, der die erstellt und versendet, und ein Empfänger, dem die zugestellt wird und der sie liest. Sowohl auf Absender- als auch auf Empfängerseite sind ein -Client und ein -Server notwendig. In Abbildung 2.1 ist zu erkennen, dass auf Absender- und auf Empfängerseite beim -Client und beim -Server jeweils andere Komponenten beteiligt sind. 8 Bundesamt für Sicherheit in der Informationstechnik

9 ISi-S Sichere Nutzung von ISi-Reihe Abbildung 2.1: Komponenten der -Kommunikation -Client-Komponenten Mail User Agent (MUA): Der MUA dient zum Erstellen, Versenden und Anzeigen von -Nachrichten. Geläufige MUAs sind zum Beispiel MS Outlook, Lotus Notes, Mozilla Thunderbird oder Kmail. Mail Retrieval Agent (MRA): Der MRA ist der Teil des -Clients, der s von einem -Server herunterlädt und diese in der Regel auf dem Client lokal speichert. Die Funktionalität dieser Komponente verläuft im Hintergrund und ist für den Nutzer nicht sichtbar. Im vorliegenden Dokument werden die Komponenten MUA und MRA als -Client-Software bezeichnet. Falls notwendig, wird eine explizite Unterscheidung der Komponenten vorgenommen. Wenn der Begriff -Client oder kurz Client verwendet wird, bezeichnet dies in der Regel einen Rechner mit einer installierten -Client-Software. -Server-Komponenten Mail Transfer Agent (MTA): Bundesamt für Sicherheit in der Informationstechnik 9

10 ISi-Reihe ISi-S Sichere Nutzung von Der MTA nimmt s von einem -Client (MUA) oder einem anderen MTA an und leitet diese an einen anderen MTA oder einen MDA (Mail Delivery Agent) weiter. Bekannte MTAs sind zum Beispiel MS Exchange, Postfix, Sendmail, Lotus Domino oder qmail. Mail Delivery Agent (MDA): Der MDA nimmt s von einem MTA entgegen und verteilt sie nach vorgegebenen Regeln auf verschiedene -Postfächer bzw. verwirft sie ( -Filter) oder sendet sie zurück, falls der lokale Dienst nicht zuständig ist. Bekannte MDAs sind zum Beispiel procmail oder maildrop. POP/IMAP Server: Ein POP/IMAP Server stellt dem -Client -Dienst MRA (Mail Retrieval Agent) die s der Postfächer zur Verfügung. In der Praxis sind die verschiedenen Funktionen selten unabhängig voneinander realisiert. Stattdessen werden meist mehrere Agents in einem sogenannten -Server integriert. Das vorliegende Dokument beschäftigt sich in den nachfolgenden Abschnitten nur mit den - Client-Komponenten. Auf die -Server-Komponenten wird detailliert in der Studie [ISi-Mail- Server] eingegangen Funktionen eines -Clients Nach der Einführung in die -Komponenten werden in diesem Abschnitt die wesentlichen Funktionalitäten von -Clients beschrieben. Allgemeine Funktionen Die grundlegende Funktion von -Clients ist die Verwaltung der elektronischen Post. Dazu gehören die essentiellen Aktionen von Lesen, Schreiben und Versenden von s. Das Schreiben von s beinhaltet auch das Beantworten und Weiterleiten von Mails. Darstellung / Anzeige Normalerweise zeigt der -Client in der Eingangsliste empfangener s nur Absenderinformationen (Von, Betreff, Datum, etc.) an. Der Inhalt der Mails wird zu diesem Zeitpunkt noch nicht angezeigt. Dazu muss die komplette noch nicht vollständig vom -Server heruntergeladen werden. Beispielsweise kann bei mobilen Geräten der -Client so konfiguriert werden, dass dieser zuerst nur die Kopfzeilen mit den Absenderinformationen vom -Server holt und als Eingangsliste anzeigt. Viele -Client-Produkte verfügen über eine sogenannte -Vorschau. Diese zeigt bereits den Inhalt einer in einem Vorschau-Fenster an, wenn sie markiert wird. Für die Vorschaufunktionalität muss die vom -Server vollständig heruntergeladen werden, damit der Inhalt anschließend angezeigt werden kann. Der Anwender bekommt dann aber auch s angezeigt, die er zwar auswählt, um diese zu löschen, aber eigentlich nicht lesen will. Dateianhänge in s lassen sich aus dem Vorschaufenster heraus öffnen. Auch Links in den s können verfolgt werden. 10 Bundesamt für Sicherheit in der Informationstechnik

11 ISi-S Sichere Nutzung von ISi-Reihe Dateianhänge Dateianhänge sind Dateien (z. B. Texte, Bilder, Präsentationen), die einer angefügt und mit der Nachricht an den Empfänger übertragen werden. Prinzipiell ist die Größe eines Dateianhangs nicht beschränkt, jedoch wird häufig die Größe der gesamten begrenzt. In der Praxis haben oftmals die Provider und Unternehmen zumindest bei eingehenden s eine Größenbeschränkung in den MTAs festgelegt, teilweise auch bei ausgehenden s. Dateianhänge können genutzt werden, um Schadprogramme zu verbreiten, wie Computer-Viren, Würmer etc. Zum Schutz vor solchen Schadprogrammen sollten geeignete Maßnahmen ergriffen werden. Neben dem Einsatz von Schutzprogrammen ist es wichtig die Nutzer zu sensibilisieren, so dass sie keine suspekt erscheinenden Dateianhänge öffnen. Lesebestätigungen Der Absender einer kann eine Lesebestätigung vom Empfänger anfordern, die ihm nach dem Anzeigen, Drucken oder Löschen der Nachricht als zugeschickt wird. Im -Client kann festgelegt werden, ob die Lesebestätigung automatisch, erst nach einer Bestätigung oder grundsätzlich nicht geschickt wird. Adressbücher Adressbücher dienen zur Verwaltung von Kontaktdaten und sind oft in die -Client-Software integriert. Neben der lokalen Speicherung von Kontaktdaten (lokales Adressbuch) können diese auf einem zentralen Server abgelegt werden. Kalender Kalender dienen zur Verwaltung von Terminen und sind oft Bestandteil der -Client-Software. Sie können lokal auf dem Client-Rechner oder auch auf einem zentralen Server gespeichert werden. Verwaltung eingehender s Bei vielen -Clients können Filterregeln definiert werden, so dass eingehende s automatisch in dafür vorgesehene Ordner verschoben werden. Je nach verwendeten Produkten erfolgt die Ausführung von Filterregeln auf dem MUA oder auf dem -Server (siehe Abschnitt 2.4.2). Bundesamt für Sicherheit in der Informationstechnik 11

12 ISi-Reihe ISi-S Sichere Nutzung von 2.2 Protokolle Für die Kommunikation zwischen den verschiedenen -Komponenten sind eine Reihe spezifischer Protokolle erforderlich. Die wichtigsten Kommunikationsprotokolle zum Austausch oder zur Verwaltung von sind POP3 (Abschnitt 2.2.1), IMAP (Abschnitt 2.2.2) und SMTP (Abschnitt 2.2.3). Darüber hinaus existieren proprietäre Protokolle wie beispielsweise Microsoft Messaging API (MAPI), mit dem sich Abschnitt beschäftigt. Der Standardansatz für den Abruf von s ist, dass -Clients regelmäßig eine Verbindung zum -Server aufbauen und dabei prüfen, ob neue s vorliegen. Dies wird Polling genannt. Bei Push- baut der -Server eine Verbindung zum -Client auf, sobald neue s eingetroffen sind. Viele Realisierungen von Push- basieren auf proprietären Protokollen, wie z. B. die Direct Push Technology von Microsoft. Das Lemonade Profile der IETF ([RFC 4550]) ist ein Vorschlag zu einem Standardprotokoll, das auf SMTP und IMAP basiert. Push-Protokolle werden in dieser Studie nicht näher betrachtet. Abschnitt befasst sich mit Protokollen für den Adressbuchzugriff. Protokolle für den Zugriff auf Kalenderdaten werden in Abschnitt beschrieben. Abschnitt betrachtet Protokolle zur Authentisierung Kommunikationsprotokoll POP3 Das Post Office Protocol Version 3 (POP3 [RFC 1939]) ist ein verbindungsorientiertes, textbasiertes Protokoll zum Herunterladen von s von einem POP/IMAP-Server auf einen -Client, wobei die Kommunikation standardmäßig über Port 110/TCP abläuft. Verbindungsorientiert bedeutet, dass vor dem Austausch von Daten eine Verbindung zwischen den Kommunikationspartnern hergestellt wird. Textbasiert heißt, dass Protokollnachrichten in Textdarstellung im Zeichensatz US-ASCII kodiert verschickt werden. POP3 ist vor allem für den Betrieb im abgesetzten Modus (disconnected operation) gedacht, bei dem der Client seine s ohne dauerhafte Verbindung zu einem zentralen -Server auf dem lokalen Rechner verwaltet. Der Client initiiert die Abfrage auf neue s auf dem - Server (Polling). Das Protokoll unterstützt verschiedene Methoden für die Authentisierung des Nutzers (siehe Abschnitt 2.2.7), jedoch keine Mechanismen zur Integritätsprüfung und Verschlüsselung. POP3S Das Protokoll POP3S (POP3 über SSL, [RFC 2595]) basiert auf POP3, nutzt jedoch Secure Socket Layer (SSL bzw. SSLv3) oder Transport Layer Security (TLS bzw. TLSv1) als Transportprotokoll für einen sicheren -Abruf. SSL/TLS ermöglicht eine sichere Kommunikation über unsichere Netze, wie beispielsweise das Internet, so dass Integrität und Vertraulichkeit der übermittelten Daten gewährleistet sind. Dazu bietet SSL/TLS Funktionen zur Verschlüsselung und Authentisierung. Typischerweise wird nur die Identität des -Servers über SSL/TLS geprüft. Es ist aber möglich die Authentisierung so zu erweitern, dass auch die Identität des Benutzers geprüft wird. Dazu muss allerdings eine Public-Key-Infrastructure (PKI) eingeführt werden. SSL/TLS nutzt eine Kombination von asymmetrischer und symmetrischer Kryptografie. Dabei erfolgt die eigentliche Verschlüsselung der Nachricht aus Performancegründen mittels eines symmetrischer Verfahrens. Der dabei gewählte geheime, zufällige Sitzungsschlüssel wird beim Aus- 12 Bundesamt für Sicherheit in der Informationstechnik

13 ISi-S Sichere Nutzung von ISi-Reihe tausch mittels asymmetrischer Verschlüsselung vor unbefugtem Mitlesen geschützt. Dies wird auch als hybrides Verschlüsselungsverfahren bezeichnet. Als asymmetrische Verfahren werden RSA, Diffie-Hellman und DSA genutzt. Für die symmetrische Kryptografie werden RC2, RC4, IDEA, DES, Triple DES, AES oder Camellia verwendet. Damit werden sowohl die Authentisierungsdaten (Benutzername und Passwort) als auch der Text der einschließlich der -Anhänge verschlüsselt übertragen Kommunikationsprotokoll IMAP Das Internet Message Access Protocol Version 4 (IMAPv4 [RFC 3501]) ist ein verbindungsorientiertes, textbasiertes Protokoll für den Zugriff und die Verwaltung von s auf dem - Server, wobei zur Kommunikation standardmäßig Port 143/TCP verwendet wird. IMAP ermöglicht dem Client das Bearbeiten, Verschieben oder Löschen von s auf dem -Server (MDA) mit entsprechenden Funktionen für das Verwalten seiner Mailbox. Das IMAP-Protokoll hat neben dem Polling-Mechanismus eine ähnliche Erweiterung wie Push-E- Mail, womit der -Client über das Eintreffen neuer s benachrichtigt werden kann. Der Client baut eine Verbindung zum Server auf und hält diese mit dem Kommando IMAP IDLE offen. Über diese Verbindung kann der -Server durch das EXISTS Kommando den -Client über neu eingetroffene s benachrichtigen. IMAP unterstützt verschiedene Methoden zur Authentisierung des Nutzers (siehe Abschnitt 2.2.7) und bietet Protokollelemente für das Aushandeln einer SSL/TLS-Verschlüsselung. IMAPS Das Protokoll IMAPS (IMAP über SSL, [RFC 2595]) basiert auf IMAP, nutzt jedoch SSL/TLS als Transportprotokoll für einen sicheren -Abruf. Das Protokoll schützt sowohl die Nutzdaten als auch die Steuerinformationen des Protokolls Kommunikationsprotokoll SMTP Das Simple Mail Transfer Protocol (SMTP [RFC 2821]) ist ein verbindungsorientiertes, textbasiertes Protokoll zur Übertragung von s zwischen -Servern (MTAs) oder zwischen E- Mail-Client und -Server. Ein Client sendet s standardmäßig an Port 25/TCP des MTA (bzw. an Port 587/TCP eines -Servers neuerer Bauart [RFC 4409]), die Weiterleitung zwischen MTAs erfolgt über Port 25/TCP. Tabelle 1 zeigt den Ablauf einer SMTP-Konversation zwischen einem -Client und einem -Server 1 : Nr. SMTP-Befehl Erläuterung 1 telnet server.[domäne].de 25 Verbindungsaufbau server.[domäne].de SMTP service ready Server meldet sich 3 EHLO client.[domäne].de Client sendet ein SMTP-"Hello" und seinen vollständigen Namen 1 Im Beispiel wird beim Verbindungsaufbau das Telnet-Kommando mit Port 25 verwendet. -Server bauen die TCP-Verbindung natürlich selbst auf und verwenden dieses Kommando nicht. Bundesamt für Sicherheit in der Informationstechnik 13

14 ISi-Reihe ISi-S Sichere Nutzung von Nr. SMTP-Befehl Erläuterung mail.[domäne].de Hello [ ], pleased to meet you 250-8BITMIME 250-SIZE 250-DSN 250-PIPELINING 250 HELP Antwort des -Servers mit einer Liste unterstützter Befehle und Mechanismen 5 MAIL FROM: sender@client.[domäne].de Spezifikation des Absenders ok Server akzeptiert den Empfänger 7 RCPT TO: empfaenger@server. [domäne].de Spezifikation des Empfängers ok Server akzeptiert diesen Empfänger 9 DATA Client möchte den Inhalt der Mail senden Enter mail input, end with "." on a line by itself Server wartet auf Daten 11 Subject: Testmail To: empfaenger@server.[domäne].de From: sender@client.[domäne].de Date: Wed, 31 Oct :55: Client sendet den Inhalt der und schließt mit einem. ab. Hallo Empfänger, dies ist eine Testmail. Mit freundlichen Grüßen Sender message accepted for delivery Server hat die akzeptiert. 12 QUIT Client verabschiedet sich server.[domäne].de closing connection Tabelle 1: SMTP-Konversation über Telnet SMTP-Envelope Server verabschiedet sich Ein SMTP-Envelope ist ein Umschlag, der der eigentlichen Mail vorangestellt wird. Er enthält die Absenderadresse und die Liste der Empfänger, an die der Mail-Server die weiterleiten soll. Wenn ein Mail-Server eine Mail an mehrere Mail-Server verteilt, wird die Mail kopiert und jeder Kopie ein eigener SMTP-Envelope vorangestellt, der nur die Empfänger enthält, für die der Mail- Server zuständig ist. Dies kann beispielsweise der Fall sein, wenn in der Empfänger aus unterschiedlicher Domänen angegeben sind. Der Endnutzer bekommt den SMTP-Envelope im Normalfall nicht zu sehen, da diese Informationen beim Einsortieren in das Postfach des Empfängers entfernt werden. 14 Bundesamt für Sicherheit in der Informationstechnik

15 ISi-S Sichere Nutzung von ISi-Reihe Im Beispiel in Tabelle 1 gehören die Zeilen 5 und 7 zum SMTP-Envelope. SMTPS SMTP ist ungesichert und unverschlüsselt, wie man bei den Klartextmeldungen in Tabelle 1 erkennen kann. Zur Absicherung kann das Transportprotokoll Transport Layer Security (TLS) genutzt werden, das den Transportkanal kryptografisch sichert. Diese Erweiterung für Secure SMTP über SSL/TLS ist in [RFC 3207] beschrieben und wird als SMTPS bezeichnet. Dabei werden sowohl die Authentisierungsdaten (Benutzername und Passwort) als auch der Text der einschließlich der -Anhänge verschlüsselt übertragen. Es muss allerdings beachtet werden, dass SSL/TLS eine Punkt-zu-Punkt-Verschlüsselung ist. Das bedeutet, dass der SSL/TLS-Tunnel bei jedem MTA abgebrochen und zum nächsten MTA wieder neu aufgebaut wird. Es besteht somit keine Ende-zu-Ende Verschlüsselung wie bei S/MIME oder OpenPGP (siehe Abschnitt 2.5) Kommunikationsschnittstelle MAPI MAPI (Messaging Application Programming Interface) ist eine proprietäre Programmierschnittstelle, die aus verschiedenen Programmelementen besteht und in denen verschiedene Funktionen implementiert sind. Ein Programmelement dient dazu über das RPC-Protokoll s zum Microsoft Exchange Server zu verschicken und vom Server abzuholen. Andere MAPI-Programmelemente verwalten Termine, Kontakte, Aufgaben und s auf einem zentralen -Server Protokolle für den Adressbuchzugriff Ein -Client kann zur Organisation der Kontaktdaten einen lokalen Verzeichnisserver nutzen. In der Regel verwendet der -Client für den Zugriff auf den Verzeichnisserver das Protokoll LDAPv3 (Lightweight Directory Access Protocol Version 3, [RFC 4510]) und kann dort Kontaktdaten abfragen und ggf. ändern. Die Authentisierung erfolgt bei LDAPv3 normalerweise im Klartext. Zur Erhöhung der Sicherheit beschreibt [RFC 4513] Authentisierungs- und Sicherheitsmechanismen von LDAP wie z. B. SASL und STARTTLS. Einige Produkte verwenden zur Realisierung von Adressbüchern proprietäre Protokolle Protokolle für den Kalenderzugriff Die Verwaltung von Terminen innerhalb des -Clients kann über die lokale Kalenderfunktionalität oder über einen zentralen Server erfolgen. Für die Kommunikation mit einem zentralen Server kann CalDAV ([RFC 4791], kurz für Calendering Extensions to WebDAV) benutzt werden. Das Protokoll CalDAV greift über WebDAV (Web-based Distributed Authoring and Versioning) auf Kalenderdateien zu. WebDAV ist ein Standard zur Bereitstellung von Dateien im Internet, der dem Benutzer ermöglicht auf die Dateien wie auf eine Festplatte zugreifen zu können. CalDAV nutzt das Protokoll HTTP für die Kommunikation zwischen -Client und -Server und erweitert HTTP um Kalenderfunktionalitäten. Ferner gibt es proprietäre Lösungen für den Kalenderzugriff wie z. B. das Exchange-Protokoll (die Microsoft Bezeichnung ist RPC/IP), bei dem über eine MAPI-Schnittstelle mit dem Server kommuniziert werden kann. Bundesamt für Sicherheit in der Informationstechnik 15

16 ISi-Reihe ISi-S Sichere Nutzung von Die Open Source Initiative Kolab verwendet IMAP für die Übertragung und Verwaltung von Kontakt- und Kalenderdaten. Gruppenkalender und Gruppenkontaktordner werden mittels IMAP Access Control Lists (ACL) unterstützt Protokolle zur Authentisierung Authentisierung bezeichnet den Vorgang, bei dem beispielsweise die Identität eines -Clients oder eines -Servers überprüft wird. Drei der wichtigsten und gebräuchlichsten Protokolle werden in diesem Abschnitt dargestellt. SASL SASL (Simple Authentication and Security Layer) stellt Funktionen für die Authentisierung für unterschiedliche verbindungsorientierte Protokolle (z. B. SMTP, IMAP und POP3) zur Verfügung und ist in [RFC 4422] definiert. Durch SASL werden Anwender authentisiert bzw. -Clients am -Server authentisiert, und es ist möglich eine verschlüsselte Verbindung auszuhandeln. Der Ablauf einer Authentisierung ist in Abbildung 2.2 dargestellt. Der Client initialisiert eine Anfrage zur Authentisierung an den Server. Der Server antwortet dem Client mit Informationen über die unterstützten Authentisierungsmechanismen. Aus diesen wählt der Client einen Mechanismus aus und übermittelt nun seine Authentisierungsdaten zum Server, der sie verifiziert. Bei erfolgreicher Verifizierung wird der Client für bestimmte Aktionen autorisiert. Optional kann nach erfolgreicher Authentisierung ein Mechanismus verwendet werden, der sowohl eine verschlüsselte Verbindung als auch die Sicherstellung der Integrität erlaubt. Abbildung 2.2: SASL-Authentisierung Zur Übertragung der Authentisierungsdaten gibt es unterschiedliche Mechanismen. Beim einfachen Mechanismus PLAIN werden alle Daten der Authentisierung im Klartext ausgetauscht. Wenn auf der Transportebene zusätzlich noch mit SSL/TLS verschlüsselt wird, werden sowohl Authentisierungsdaten als auch Nutzdaten geschützt. Daher ist hierbei der Mechanismus PLAIN ausreichend. 16 Bundesamt für Sicherheit in der Informationstechnik

17 ISi-S Sichere Nutzung von ISi-Reihe SMTP-Auth SMTP-Auth ([RFC 4954]) ist eine Erweiterung des SMTP-Protokolls, bei der der -Client sich am Server authentisiert. Nach der Aushandlung eines Authentisierungsverfahrens kann sich der -Client am -Server authentisieren. Bei den Authentisierungsverfahren PLAIN und LOGIN wird Benutzername und Kennwort unverschlüsselt übertragen. Daher ist die Verwendung von SSL/TLS sinnvoll, um die Authentisierungsdaten zu schützen. Die Authentisierung mit SMTP-Auth erfolgt nach dem EHLO-Befehl (vgl. Tabelle 1). In der nachstehenden Tabelle 2 ist ein Ausschnitt einer Authentisierung mit SMTP-Auth dargestellt: 250 AUTH CRAM-MD5 LOGIN PLAIN Nach dem EHLO antwortet der Server mit einer Liste der unterstützten Authentisierungsverfahren (hier CRAM-MD5, LOGIN, PLAIN) AUTH LOGIN 334 VXNlcm5hbWU6 QmVudXR6ZXJuYW1l 334 UGFzc3dvcmQ6 QmVudXR6ZXJwYXNzd29ydA== Gewähltes Authentisierungsverfahren: LOGIN Im nächsten Schritt werden Benutzername (Username)und Passwort (Password) abgefragt. Da LOGIN gewählt wurde, werden die Daten Base64-kodiert übertragen. Nachstehend sind die Daten der linken Seite im Klartext dargestellt: Username: Benutzername Password: Benutzerpasswort 235 ok Server akzeptiert den Empfänger Tabelle 2: Authentisierung mit SMTP-Auth Nach erfolgreicher Authentisierung ist eine Änderung (Fälschung) des SMTP-Envelopes, der Header-Daten oder des -Bodys durch den Benutzer aber immer noch möglich, da mittels des SMTP-Auth-Mechanismus der Benutzer authentisiert wird, aber nicht die Envelope- und Header- Daten oder der Inhalt des -Bodys. Der Empfänger kann nicht feststellen, ob der Absender authentisiert worden ist, da die Authentisierung üblicherweise zwischen sendendem -Client und sendendem -Server stattfindet. SMTP-after-POP SMTP-after-POP ist ein Verfahren, das einem -Client erlaubt, auf Basis einer vorab durchgeführten erfolgreichen Authentisierung über das POP3-Protokoll, s zum -Server zu verschicken. Beim Versenden einer mittels SMTP findet die Identifikation des -Clients über die IP-Adresse statt, die vorher bei einer zuvor erfolgreichen POP3-Authentisierung verwendet wurde. Dieses Verfahren hat den Vorteil, dass beim -Client kein zusätzliches Protokoll realisiert werden muss. Dagegen können folgende Nachteile entstehen: Bundesamt für Sicherheit in der Informationstechnik 17

18 ISi-Reihe ISi-S Sichere Nutzung von Werden dynamische IP-Adressen benutzt, kann es vorkommen, dass der -Client seine IP- Adresse zwischen POP3-Authentisierung und dem Verschicken von s über das SMTP- Protokoll ändert und so ein Senden der verweigert wird. Auf dem -Server muss eine Zeitbeschränkung zwischen POP3-Authentisierung und dem Freischalten von SMTP für den -Client eingestellt werden. Dies kann zu Fehlermeldungen beim -Client führen, wenn dieser außerhalb der Zeitbeschränkung eine verschicken möchte. Der Einsatz von SMTP-after-POP in Zusammenhang mit NAT (Network Address Translation - Sammelbegriff für Verfahren, um automatisiert und transparent Adressinformationen in Datenpaketen durch andere zu ersetzen) kann dazu führen, dass ein ganzes Subnetz freigeschaltet wird. Ein -Client, der eine IP-Adresse verwendet, die vorher bereits bei einer POP3-Authentisierung genutzt wurde (z. B. bei NAT oder dynamischer IP-Adresse), könnte ohne weitere Prüfung s versenden. Prüfung der Absenderadresse Zur Authentisierung des Clients kann die Absenderadresse verwendet werden (z. B. auf Basis der Domänennamen). Problematisch ist hierbei, dass die Absenderadresse innerhalb des SMTP-Protokolls sehr einfach zu fälschen ist und so nur ein ungenügender Schutz vorhanden ist Übersicht der Protokolle Einen schnellen Überblick über die relevanten Protokolle und deren Sicherheitseigenschaften gewährt Tabelle 3. Wenn das Protokoll die Sicherheitseigenschaft besitzt, wird dies in dem zugehörigen Feld mit einem x gekennzeichnet. Ein Minuszeichen ( - ) zeigt an, dass das Protokoll die Sicherheitseigenschaft nicht besitzt. Protokoll Port Sicherheitseigenschaften Authentisierung Integritätssicherung Verschlüsselung Referenz POP3 110/TCP x - - RFC 1939 POP3S 110/995 2 /TCP x x x RFC 2595 IMAP 143/TCP x - - RFC 3501 IMAPS 143/993 3 /TCP x x x RFC 2595 SMTP 25/TCP RFC 2821 SMTP (Nur Client zu Server) 587/TCP x - - RFC 4409 SMTP-Auth 25/TCP x - - RFC 2554 SMTP über TLS (SMTPS) 465/TCP x x x RFC 3207 SASL x x x RFC In [RFC 2595] wird von der Benutzung eines separaten Ports für POP3 (995/TCP) über TLS abgeraten, stattdessen wird das STLS Kommando empfohlen. 3 In [RFC 2595] wird von der Benutzung eines separaten Ports für IMAP (993/TCP) über TLS abgeraten, stattdessen wird das STARTTLS Kommando empfohlen. 18 Bundesamt für Sicherheit in der Informationstechnik

19 ISi-S Sichere Nutzung von ISi-Reihe Protokoll Port Sicherheitseigenschaften Authentisierung Integritätssicherung Verschlüsselung Referenz LDAP 389/TCP x - - RFC 4511 LDAP über TLS (LDAPS) 389/636 4 /TCP x x x RFC 4513 CalDAV 5 x (x) (x) RFC 4791 SMTP-after-POP x - - Prüfung der Absenderadresse x - - Tabelle 3: Übersicht der Protokolle und deren Sicherheitseigenschaften 4 In [RFC 2595] wird von der Benutzung eines separaten Port für LDAP(636/TCP) über TLS abgeraten, stattdessen wird das STARTTLS Kommando empfohlen. 5 Authentisierung kann mittels HTTP umgesetzt werden, Integritätssicherung und Verschlüsselung können mittels HTTPS umgesetzt werden. Bundesamt für Sicherheit in der Informationstechnik 19

20 ISi-Reihe ISi-S Sichere Nutzung von 2.3 Aufbau und Formate Damit die Interoperabilität zwischen verschiedenen -Clients und -Servern gewährleistet ist, sind verschiedene (offene) Standards für den Aufbau und die Formate von s, Postfächern, Kalendern und Adressbüchern spezifiziert worden Struktureller Aufbau von s Eine besteht aus einem Kopfteil ( -Header) und dem Inhalt der Nachricht ( - Body). Das Format einer wird in [RFC 2822] definiert. MIME (Multipurpose Internet Mail Extensions) erweitert den Standard RFC 2822 durch die Definition weiterer Header-Einträge, die die Art der Daten im Body der Nachricht beschreiben. Beispielsweise kann angegeben werden, dass es sich um mehrteilige Nachrichten handelt oder dass ein Bild übertragen wird. Damit ist es möglich, dass Texte im -Body auch mit einem anderen Zeichensatz als 7-Bit-ASCII geschrieben werden können, im -Body auch andere Formate außer Text enthalten sein können, der -Body aus mehreren Teilen bestehen (multipart) kann, in textbasierten Header-Informationen auch ein anderer Zeichensatz als 7-Bit-ASCII verwendet werden kann. Die Erweiterungen werden durch neue Zeilen im Header umgesetzt (siehe Abschnitt 2.3.3). -Header Der -Header beinhaltet Einträge, die Informationen über Absender, Empfänger, Erstellungsdatum und Stationen der Übermittlung geben. -Header- Zeilen From To CC Erläuterung From bezeichnet eine oder mehrere -Adressen (viele Mail-Clients unterstützen nur eine Mail-Adresse), von der die Nachricht gesendet wurde. Beispiel: From: To enthält eine oder mehrere -Adressen, an die die Nachricht gesendet werden soll. Beispiel: To: In CC werden eine oder mehrere -Adressen der Empfänger angegeben, die eine Kopie der erhalten sollen. 20 Bundesamt für Sicherheit in der Informationstechnik