Ich gehe davon aus, das eine funktionsfähige amavis, postfix usw… Konstellation vorhanden ist!
Ich habe einen Server im Internet stehen, welcher sich um meine E-Mails und die meiner Verwanden und Bekannten kümmert. Hier liegen mehrere Domains und die E-Mails in lokalen Postfächern. Diese sind per smtp, imap und webmail zu erreichen.
OS ist Debian Lenny, als MTA nutze ich Postfix welcher mit amavis, spamassassin, clamav, dovecot und etwas Krims mehr zusammenarbeitet.
Meine Idee war nun alle ausgehenden E-Mails jeweils mit DKIM zu signieren und alle eingehenden E-Mails zusätzlich auf eine gültige DKIM Signatur zu prüfen.
Es gibt hier nun mehrere Möglichkeiten dieses umzusetzen. Ich habe mehrere Systeme ausprobiert und finde, für mich ist es über amavis am angenehmsten. Seit der Version 2.6 bringt amavis-new diese Funktionalität mit. Na dann wollen wir mal….
Vorbereitung der Signaturprüfung
Ich habe folgende Einträge in meiner 50-user unter /etc/amavis/conf.d/ dafür ergänzt:
$enable_dkim_verification = 1;
Damit überreden wir amavis die DKIM Signaturen zu prüfen. Dieses läuft in Zusammenarbeit mit spamassassin. Hier müssen folgende Einträge vorgenommen werden:
/etc/spamassassin/v320.pre
loadplugin Mail::SpamAssassin::Plugin::DKIM
Ohne diesen Eintrag wird spamassassin nicht das passende Modul laden und versteht überhaupt nicht was man von ihm will (häufige Fehlerquelle).
/etc/spamassassin/local.cf
#DKIM
score DKIM_VERIFIED -3.0
score DKIM_POLICY_TESTING 0
score USER_IN_DKIM_WHITELIST -8.0
whitelist_from_dkim @kernel-error.de
Hier lege ich nun die Punkte fest, welche von spamassassin vergeben werden. Da natürlich auch Spammer eine DKIM Signatur erstellen könnten (was eher selten ist) gebe ich maximal -3 Punkte für eine erfolgreich geprüfte DKIM Signatur.
Es fehlt nur noch ein Paket: libmail-dkim-perl
Dieses installieren wir einfach schnell mit
apt-get install libmail-dkim-perl
nach!
Ab jetzt werden E-Mails schon auf eine gültige DKIM Signatur überprüft.
Ich werfe, nach einiger Zeit, mal ein: cat /var/log/mail.log|grep dkim_id raus um zu sehen ob schon etwas passiert ist:
Mar 11 10:59:56 kernel-error amavis[10736]: (10736-05) Passed CLEAN, [91.194.xxx.xxx] [91.194.xxx.xxx] <e3@xxxxx.net> -> <xxx@xxx-meckenheim.de>, Message-ID: <0.0.10@e3xxys.net>, mail_id: Cf, Hits: -9.187, size: 33396, queued_as: 6883, dkim_id=eBay@reply.ebay.de,eBay@reply.ebay.de, 6951 ms
Schaut gut aus und im MailHeader dieser E-Mail steht:
Authentication-Results: kernel-error.de (amavisd-new); dkim=pass
header.i=eBay@reply.ebay.de
Authentication-Results: kernel-error.de (amavisd-new); domainkeys=pass
Das geht also schon mal 😀
Vorbereitung der Signierung
In /etc/amavis/conf.d/50-user müssen folgende Konfigurationszeilen eingefügt werden:
$enable_dkim_signing = 1;
dkim_key('kernel-error.de', 'kernel-error', '/pfad/kernel-error.key.pem');
@dkim_signature_options_bysender_maps = (
{ '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
@mynetworks = qw(127.0.0.0/8); # list your internal networks
Zeile 1 bringt amavis dazu E-Mails per DKIM zu signieren.
Zeile 2 sagt amavis wo für die jeweilige Domain (hier kernel-error.de) die Schlüsseldatei liegt.
Zeile 3 gibt vor wie und was signiert werden soll.
Zeile 4 gibt an, welche IP-Netze als lokal behandelt werden sollen. Da dieser Server bei uns im Rechenzentrum steht gibt es kein lokales Netzwerk, bis auf 127…
Jetzt müssen wir noch den Schlüssel erstellen. amavis hilft dabei mit folgendem Befehl:
amavisd-new genrsa /pfad/kernel-error.key.pem
Wir können uns den Schlüssel anschauen und direkt Testen ob amavis alles richtig verstanden hat, mit Hilfe dieses Befehls:
amavisd-new showkeys
Die Ausgabe sollte ähnlich dieser sein:
kernel-error._domainkey.kernel-error.de. 3600 TXT (
"v=DKIM1; p="
"MIGfMCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC/KYIHw8NZNIB"
"SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS6orDC2DzZ7"
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
"qZZZZZZZZZZZZZZZZZZZZZZZZB")
Genau diesen Schlüssel müssen wir nun in den DNS-Eintrag des DNS-Servers eintragen, welcher für die Domain zuständig ist. Der DNS-Server meiner Domain ist ein Bind9. Um diesem meinen Schlüssel schmackhaft zu machen, muss ich ihn noch etwas umformen. Er wird am Ende so ausschauen:
kernel-error._domainkey.kernel-error.de. 3600 TXT "v=DKIM1; p="MIGfMCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC/KYIHw8NZNIBSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS6orDC2DzZ7XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXqZZZZZZZZZZZZZZZZZZZZZZZZB"
Ich habe alle Zeilenumbrüche und ~überfüssige~ ( „ ) sowie die beiden Klammern entfernt. Der Eintrag im Bind schaut nun also so aus:
$ORIGIN .
$TTL 86400 ; 1 day
kernel-error.de IN SOA kernel-error.de. root.kernel-error.de. (
xxxxxxxxx ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
1800 ; retry (30 minutes)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns1.kernel-error.de.
NS ns2.kernel-error.org.
A 213.xx.xx.xx
MX 10 smtp.kernel-error.de.
kernel-error._domainkey.kernel-error.de. 3600 TXT "v=DKIM1; p="MIGfMCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC/KYIHw8NZNIBSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS6orDC2DzZ7XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXqZZZZZZZZZZZZZZZZZZZZZZZZB"
$ORIGIN kernel-error.de.
$TTL 300 ; 5 minutes
imap A 213.xx.xx.xx
smtp A 213.xx.xx.xx
Ein amavisd-new testkeys sollte nun folgendes ergeben:
TESTING: kernel-error._domainkey.kernel-error.de => pass
Ab jetzt werden alle lokalen E-Mails signiert! Hier ist darauf zu achten, dass nur E-Mails signiert werden, welche als lokal eingestuft werden. Wir erinnern uns daran, dass wir 127.0.0.0/8 als lokales Netzwerk eingestuft haben. Wenn also nun E-Mails von Benutzern signiert werden sollen, welche sich mit ihrem E-Mail Client per smtp am Server anmelden und E-Mails verschicken, dann ist noch etwas mehr Arbeit nötig!
Am einfachsten ist es mit zwei verschiedenen IP-Adressen zu arbeiten und für diese Spezielle Regeln anzulegen. Dazu müssen ein paar Einträge in der /etc/postfix/master.cf vorgenommen werden:
213.xx.xx.xx:smtp inet n - - - - smtpd
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o local_header_rewrite_clients=
Ist hier mein Eintrag für E-Mails, welche über den MX Eintrag an meinen Mailserver gesendet werden, also für die Domains und User bestimmt sein sollten, welche ich über meinen Mailserver verarbeite. Die User sollten über diese Adresse keine E-Mails einliefen!!
### Einlieferung eigene Nutzer
213.xx.xx.xxx:smtp inet n - y - 100 smtpd
-o smtpd_proxy_filter=localhost:10028
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=
213.xx.xx.xxx:smtps inet n - y - 100 smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_wrappermode=yes
-o smtpd_proxy_filter=localhost:10028
-o smtpd_sasl_auth_enable=yes
-o content_filter=
Dieses sind nun meine Einträge für die zweite IP-Adresse. Über welche die User, welche sich per sasl anmelden, ihre E-Mails ins System werfen.
localhost:smtp inet n - - - - smtpd
Damit auch mein Webmail sauber funktioniert ist dieser Eintrag zuständig. Sonst lauscht halt keiner mehr lokal 😀
Hier ist nun klar zu sehen, das die per smtp angenommenen E-Mails je nach IP anderen Regeln unterliegen und auch lokal an amavis auf anderen Ports weitergeleitet werden. Dieses müssen wir natürlich amavis auch mitteilen. Wenn amavis nicht weiss das es auf weiteren Ports lausch soll, wird es dieses kaum von sich aus tun. Dafür müssen wir einen Eintrag unter /etc/amavis/conf.d/20-debian_defaults ändern.
$inet_socket_port = [10024,10028,10032]; # listen on multiple TCP ports geaendert
Jetzt geben wir in der /etc/amavis/conf.d/50-user noch unsere spezielle Regel für die sasl Benutzer an:
# DKIM
$policy_bank{'SASLNUTZER'} = { # Einlieferung eigener Nutzer
originating => 1,
os_fingerprint_method => undef, # eigentlich ueberfluessig
};
$interface_policy{'10028'} = 'SASLNUTZER';
Interessant ist hier im Grunde nur:
originating => 1,
Man könnte originating => 1 auch einfach mit in die 20-debian_defaults werfen und sich das mit der zweiten IP und den amavis Regeln sparen. Damit wird aber jede E-Mail als lokal behandelt. Ob das so gut ist bleibt jedem selbst überlassen 😛
Tja, was soll ich sagen, hier ist nun Ende. Sollte es Fragen oder Probleme geben, könnt ihr euch gerne bei mir melden!
Hier nun noch ein Paar Informationen zu DKIM:
DomainKeys ist ein Identifikationsprotokoll zur Sicherstellung der Authentizität von E-Mail-Absendern, das von Yahoo entwickelt wurde und seit Ende 2004 in Erprobung ist. Es wurde konzipiert, um bei der Eindämmung von unerwünschter E-Mail wie Spam oder Phishing zu helfen.
DomainKeys wurde ursprünglich unter dem Titel Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) im RFC 4870 veröffentlicht und unter dem Titel DomainKeys Identified Mail (DKIM) Signatures durch RFC 4871 abgelöst.
Arbeitsweise
DomainKeys basiert auf asymmetrischer Verschlüsselung. Die E-Mail wird mit einer Digitalen Signatur versehen, die der empfangende Server anhand des öffentlichen Schlüssels, der im Domain Name System (DNS) der Domäne verfügbar ist, verifizieren kann. Schlägt dies fehl, hat der empfangende Mail Transfer Agent (MTA) oder das empfangende Anwendungsprogramm die Möglichkeit, die E-Mail zu verweigern oder auszusortieren.
Kern des Verfahrens ist, dass der sendende MTA jede versendete E-Mail im sogenannten „DomainKey-Signature-Header“ mit einer digitalen Signatur des Inhaltes der E-Mail versieht.
Für die Erzeugung des für die Signatur nötigen Hashwertes unterstützt DKIM die Hashfunktionen SHA-1 und SHA-256, wobei die Verwendung von letzterer empfohlen wird. Die anschließende Verschlüsselung des Hashwertes, die letztlich die digitale Signatur zum Ergebnis hat, wird in beiden Fällen mit dem Verschlüsselungsverfahren RSA realisiert. Damit die Signatur mit dem beim E-Mail-Versand verwendeten ASCII-Zeichensatz dargestellt werden kann, wird sie mit Base64 kodiert.
Die so erzeugte digitale Signatur wird vom empfangenden MTA zunächst base64-dekodiert und dann mit dem öffentlichen Schlüssel der angeblichen Absender-Domäne (z.B. yahoo.com) entschlüsselt, der Hashcode der E-Mail wird neu berechnet. Stimmen der gelieferte entschlüsselte und der selbst berechnete Hashcode überein, stammt die E-Mail wirklich von der angegebenen Domäne. Der oder die verwendeten öffentliche(n) Schlüssel werden hierzu im DNS-Eintrag der sendenden Domäne publiziert. Das heißt, dass der DNS als Zertifizierungsstelle fungiert. Eine mit Hilfe von DomainKeys signierte E-Mail bietet also die Möglichkeit, sicher nachzuprüfen, ob die in der E-Mail-Absenderadresse enthaltene Domäne korrekt ist und dass die E-Mail auf dem Weg der Zustellung nicht verändert wurde.
Spamfilterung
Da es sich bei DomainKeys um einen Authentifizierungsmechanismus handelt, dient DomainKeys nicht dazu, Spam zu filtern. Stattdessen begrenzt DomainKeys die Möglichkeit, E-Mail-Absenderadressen zu verschleiern, da man mit DomainKeys feststellen kann, ob eine E-Mail tatsächlich über die angegebene Domäne versendet wurde.
Diese Nachvollziehbarkeit kann dazu verwendet werden, Bewertungssysteme und Filtertechniken von Spamfiltern wirkungsvoller zu gestalten. Zudem kann DomainKeys den Datendiebstahl durch Phishing begrenzen, da teilnehmende Mailversender ihre E-Mails als Originale zertifizieren können. Fehlt eine solche Zertifizierung, obwohl der vermeintliche Absender angibt, seine E-Mails zu zertifizieren, so kann die E-Mail als mögliche Fälschung betrachtet werden.
Lizenzierung
Yahoo hat das Verfahren patentieren lassen und es bei der IETF zur Standardisierung eingereicht. Das Verfahren wurde mittlerweile als Standard RFC 4871 akzeptiert.
Das DomainKeys-Verfahren kann von Yahoo wahlweise unter den Bedingungen der GPL 2.0 oder den Bedingungen des proprietären Yahoo DomainKeys Patent License Agreement lizenziert und verwendet werden.
Dem DomainKeys-Verfahren werden nach dem Scheitern der Standardisierung von Microsofts Sender ID – bei welchem an keine GNU-Lizenzierung gedacht wurde – gute Chancen eingeräumt, sich neben dem Sender Policy Framework (SPF) im Internet zu etablieren.
Unterstützung
Das DomainKeys-Verfahren erfordert größere Modifikationen am Mailserver – entsprechende Anpassungen existieren derzeit für fast alle gängigen Mail Transfer Agenten. Derzeit wird das DomainKeys-Verfahren nur von sehr wenigen Providern unterstützt; bekannte größere Provider, die Domainkeys einsetzen, sind Yahoo, Gmail und Strato.
Das Problem bei dieser und aller anderen Methoden zur Sicherstellung der Absender-Authentizität ist, dass es einen langen Zeitraum brauchen wird, um ein solches System zu verbreiten, da zuerst die Software angepasst werden muss und diese dann auch noch auf den Mailservern zum Einsatz kommen muss.
Weiterentwicklungen
Im Juli 2005 wurde von Cisco und Yahoo ein gemeinsamer Entwurf mit dem Titel DomainKeys Identified Mail (DKIM) bei der IETF eingereicht. Unterstützt wurde dieser Vorschlag nun auch von anderen Größen der IT-Branche, darunter mit Microsoft und AOL auch von denjenigen, die als Alternativlösung SPF vorschlugen. DKIM wurde im Mai 2007 als RFC 4871 veröffentlicht und ersetzte damit den vorherigen Entwurf RFC 4870.
ist hier etwas besonders. Denn das ist die Zeit in Sekunden, welche die Signatur gültig ist. In diesem Fall 360 Tage….
