Sicherer E-Mail Transport: Difference between revisions
Line 106: | Line 106: | ||
* [https://tools.ietf.org/html/rfc7208 RFC7208 (SPF)] |
* [https://tools.ietf.org/html/rfc7208 RFC7208 (SPF)] |
||
* [https://en.wikipedia.org/wiki/Sender_Policy_Framework] |
* [https://en.wikipedia.org/wiki/Sender_Policy_Framework Wikipedia SPF] |
||
* [https:// |
* [https://tools.ietf.org/html/rfc4871 RFC4871 (DKIM)] |
||
* [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail] |
* [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail Wikipedia DKIM] |
||
* [https://tools.ietf.org/html/rfc4035 RFC4035 (DNSSEC)] |
* [https://tools.ietf.org/html/rfc4035 RFC4035 (DNSSEC)] |
||
* [https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions] |
* [https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions Wikipedia DNSSEC] |
||
* [http://tools.ietf.org/html/rfc6698 RFC6689 (DANE)] |
* [http://tools.ietf.org/html/rfc6698 RFC6689 (DANE)] |
||
Check Tools |
==Check Tools== |
||
* |
* |
||
Anleitungen |
==Anleitungen== |
||
* |
* |
Revision as of 11:26, 22 October 2015
Aufbau
Eine E-Mail besteht aus einem Header und einem Body.
Header
Die wichtigsten Header die gesetzt werden sollten, um zum Beispiel nicht direkt als SPAM E-Mail eingestuft zu werden, sind Sender (from), Empfänger (to), das Datum (date) und der Betreff (subject). Darüber hinaus werden auch z.B. Spam Prüfungen und weitere Informationen vom SMTP Server im E-Mail Header festgehalten.
X-Virus-Scanned: amavisd-new at diverse.io X-Spam-Flag: NO X-Spam-Score: 0.524 X-Spam-Level: Subject: ITSec Testmail From: ***@itsec.vog3l.de To: ***@informatik.hu-berlin.de Date: Fri, 09 Oct 2015 15:30:18
Body
Im Body befindet sich der eigentlich Inhalt der versendet werden soll.
Envelope
Beim Versenden verpackt der versendende MTA die E-Mail in eine art Umschlag, wie im Interactions Diagram gut zu sehen ist. Hierbei wird dem empfangenden MTA der Absender (MAIL FROM) und der/die Empfänger (RCPT TO) vor der eigentlichen Übermittlung der E-Mail mitgeteilt. Erst wenn der empfangenden MTA sowohl den Absender als auch die Empfänger akzeptiert wird die E-Mail (Header und Body) nach dem Stichwort DATA übertragen und mit einem Punkt (.) abgeschlossen. Dies hat z.B. den Vorteil ....keine unötige Mail Übertragung
Server Kommunikation
Sicherheitstechniken
SPF
Das Secure Policy Framework (SPF) ist ein Verfahren um das Fälschen von Absenderadressen in E-Mails zu verhindern. Hierfür muss ein Ressource Record vom Typ TXT in der DNS Zone für eine Domain hinterlegt werden.
$ dig -t TXT itsec.vog3l.de itsec.vog3l.de. 291780 IN TXT "v=spf1 mx -all"
Der empfangende MTA kann nun die Felder 'MAIL-FROM' und 'HELO' aus dem E-Mail-Envelope gegen den im DNS hinterlegten SPF Record prüfen und die E-Mail entweder annehmen oder ablehnen. Es wird hierbei allerdings nicht das 'From:' Feld im Header der E-Mail geprüft.
Ein gültiger SPF Record hilft häufig auch dabei, dass E-Mails am Greylistening vorbei kommen, sowie auch einen besseren SPAM Score erzielen.
DKIM
DomainKeys Identified Mail (DKIM) ist eine Technik um E-Mail Spoofing und Phishing zu verhindern. Die E-Mail wird hierfür vom versendenden MTA mit einer Signatur versehen, die vom empfangenden MTA verifiziert werden kann. Somit kann der empfangenden MTA sicherstellen, dass der Versand für diese Domain authorisiert ist und die E-Mail beim Transport nicht modifiziert worden ist.
Ein Signatur sieht wie folgt aus:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=itsec.vog3l.de; s=mail; t=1444297250; bh=bmY+6VYtf/CKbo/kg3vJWg5eDLYfJ8ydsGRhxgoqVn8=; h=Subject:From:To:Date:From; b=gNcTfHCGrV57qtRXukKftJre0IsXa9eaxi0vCZvkWY3WlJezjnbduuDpsfZlLYLbT ERSxXtD20vEBWGXz7PEdy9eoXzIKRT5AY4tDfwRN2KTBWgMrakS5q9JupqlOk5uzcD KXE55K2aIGuPoO20VNOJePTbY2RkLUUxs80R9Ajo=
Die Tags in der Signatur bedeuten folgendes:
- v: Version
- a: Signatur Algorithmus
- c: Autorisierter Algorithmus für Header und Body
- d: Domain
- s: Selektor
- t: Zeitstempel
- bh: Body Hash
- h: Liste aller Header die zur Signatur verwendet wurden. Die DKIM-Signature (mit leerem b=) und der Body sind implizit enthalten.
- b: die eigentliche Signatur
Mit Hilfe des Selektors und der Domain kann der public key wie folgt im DNS ausgelesen werden:
dig -t TXT selektor._domainkey.domain
$ dig -t TXT mail._domainkey.itsec.vog3l.de mail._domainkey.itsec.vog3l.de. 604800 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWLZ/sEpdm76aQkisvQF8P6MSEUAnztt7dBCSuT2u5Q0isG743a24bS0XJGDhtibZmA/yUj7gdaia5vSrH0PB9YSKd6eHQ6KD ARQkDovhisxaj4y4esuOKiQYF3a9MFVpKMQc7rY1W+6JtvbhNJ6qkcZN8ySFxgYkqgiPZIWb1+wIDAQAB"
Zur Prüfung der Signatur errechnet der empfangende MTA den Hash-Wert aus dem Header und dem Body und vergleicht diesen gegen den Hash-Wert, der sich aus der Entschlüsselung des Signatur Hash-Wertes aus dem Header mit dem Public Key ergibt.
DNSSEC
Domain Name System Security Extensions (DNSSEC)
Anleitungen zum Einrichten von DNSSEC:
DANE
DNS-based Authentication of Named Entities (DANE)
TestUmgebung
- Debian 8 (Jessie)
- bind9 9.9.5
- postfix 2.11.3-1
- opendkim 2.9.2-2
Quellen
- RFC7208 (SPF)
- Wikipedia SPF
- RFC4871 (DKIM)
- Wikipedia DKIM
- RFC4035 (DNSSEC)
- Wikipedia DNSSEC
- RFC6689 (DANE)