© Aaron Amat, 123RF.com

Die Header von E-Mails geben Auskunft über Strukturen des lokalen Netzwerks. Dies lässt sich schon auf dem eigenen Mailserver so weit reduzieren, dass Fremde hier nur solche Daten vorfinden, die für den Transport der Nachrichten notwendig sind.

Prism, Tempora oder auch das gute alte Echelon – all diese Schnüffeleien durch Geheimdienste oder andere, kriminelle Organisationen haben nicht nur Daten als Ziel, deren Übertragung dem Benutzer bewusst ist. Auch die automatisch angefügten Transportinformationen, zum Beispiel bei E-Mails, können wertvolle Hinweise enthalten, die spätere Angriffe erleichtern.

PGP hilft nicht bei Headern

Dagegen helfen auch PGP und GPG mit ihrer Ende-zu-Ende-Verschlüsselung nicht. Die entzieht zwar die Inhalte der E-Mails dem Blick Unbefugter und SSL/TLS verbirgt darüber hinaus auch die Header-Informationen – aber nur während des Transports. Spätestens beim Internet Service Provider (ISP), der die Mails weiterleitet, liegen genau diese Header-Informationen wieder im Klartext vor, obgleich die beteiligten Mailserver die Nachricht verschlüsselt übertragen haben. Solche Header von E-Mails enthalten häufig Informationen, die interne Strukturen des lokalen Netzwerks offenlegen und damit potenziellen Angreifern wichtige Hinweise geben. Dieser Artikel zeigt, wie der Admin die Header auf ein Mindestmaß reduziert.

Sehr verbreitet sind Netzwerk-Konstellationen wie die in Abbildung 1: Ein Router verbindet LAN und ISP. Zwischen ihm und dem eigentlichen LAN mit den Clientrechnern, vielleicht auch weiteren Servern, hängt ein Gateway. Dessen externe Netzwerkschnittstelle ist mit dem Router, eine interne Schnittstelle über einen Switch ist mit den restlichen Maschinen im lokalen Netz verbunden. Die Netzwerkschnittstellen gehören unterschiedlichen Subnetzen an. Im Artikel und in den Listings 1 bis 5 finden die in Tabelle 1 beschriebenen anonymisierten Adressen Verwendung.

Abbildung 1: Die typische Netzwerktopologie eines kleinen Unternehmens mit Client-LAN, Mail-Gateway und Router.

Netz-Architektur

Der Router erhält vom ISP entweder eine dynamische IP und – eventuell auch dynamisch – einen Fully Qualified Domain Name (FQDN), zum Beispiel »Name_meines_Routers.Mein_ISP.com« zugewiesen. Oder er ist auf seiner ins Internet weisenden Schnittstelle mit einer festen, ebenfalls vom ISP zugeteilten IP-Adresse versehen. Die Verbindung vom Router zum Gateway bildet ein eigenes Netz, dessen Netzwerkadresse sich vom eigentlichen LAN unterscheiden sollte.

Auf dem Gateway selbst laufen meist weitere Dienste, etwa DHCP oder DNS, sowohl für die interne Namensauflösung als auch für das Abholen externer DNS-Informationen über einen »forwarders« -Eintrag. Häufig kommen auch Squid als Webproxy und eine Firewall zum Einsatz, wenn das Gateway zugleich als Router dient. Natürlich werden all diese Dienste wie auch der für dieses Thema wichtige MTA (beispielsweise Postfix) und ein lokaler IMAP-Server wie Cyrus oder Dovecot nur an jener Schnittstelle lauschen, die in das LAN weist.

Der lokale Mailserver ist für die Mails der lokalen Domain (»Meine_Domain.local« ) zuständig und auch für die offizielle Domain (»example.com« ). Mails an diese übergibt er an einen Relayhost beim ISP, der sie wiederum an die endgültigen Adressaten weiterleitet. Wie Admins Postfix als Mail Transport Agent dafür konfigurieren, lässt sich in [1] nachlesen. Dieser Artikel konzentriert sich auf das Umschreiben der Header und das Entfernen privater Informationen.

Intern

Damit Postfix die internen Mails richtig verarbeitet, bekommt der Eintrag »mydomain« in der Datei »/etc/postfix/main.cf« den Namen der internen Domain zugewiesen, also »Meine_Domain.local« . Der Eintrag »myhostname« wird durch die Installation auf den FQDN des Gatewayrechners (»Gateway.Meine_Domain.local« ) selbst gesetzt, »mydestination« legt der Admin jetzt noch auf »Meine_Domain« (neben »localhost« und »localhost.Meine_Domain« ). Damit fühlt sich Postfix für alle Mails an Adressen der internen Domain »Meine_Domain.local« und die des Gatewayrechners zuständig. Diese Mails bleiben im Haus und landen sofort beim lokalen IMAP-Server.

Extern

Damit die externen Mails, also alle, die Postfix nicht an »Adresse@Meine_Domain.local« ausliefern soll, an den MTA des ISP (»smtp.Mein_ISP.com« ) weitergereicht werden, weist der Admin dem Eintrag »relayhost« den Namen des MTA des ISP zu, also »relayhost=smtp.Mein_ISP.com« . Eingehende Mails von »Adresse@externe_Domain.com« an »Adresse@example.com« erreichen den MTA nicht direkt. Vielmehr holt Fetchmail sie vom POP3- oder IMAP-Server des ISP ab und leitet sie an den lokalen MTA weiter, der sie auf die Postfächer der LAN-Benutzer verteilt. Zusätzlich zum eigentlichen Mailtransport arbeitet vielerorts ein Contentfilter wie der Virenscanner Amavis, der die Mails auf Malware und Spam überprüft.

Per Default eher eine Plaudertasche

Listing 1 zeigt, wie geschwätzig sich Postfix und andere in der vorliegenden Konfiguration verhalten, wie freimütig sie zahlreiche interne Informationen in die Welt hinausposaunen. Am besten liest man die Headerdaten von unten nach oben, also in der Reihenfolge, in der sie auch beim Verschicken dieser Mail entstanden sind.

01 Received: from Gateway.Meine_Domain.local
02   (Name_meines_Routers.Mein_ISP.com [1.2.3.4])
03   by smtp.Mein_ISP.com (xxxxx xxxx) (RZmta 31.27 DYNA|AUTH)
04   with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 906d2cp5H92jgY
05   for <Adresse@Externe_Domain.com>;
06   Mon, 17 Jun 2013 11:10:34 +0200 (CEST)
07  Received: from localhost (localhost [127.0.0.1])
08   by Gateway.Meine_Domain.local (Postfix) with ESMTP id 69CF0E009C
09   for <Adresse@Externe_Domain.com>; Mon, 17 Jun 2013 11:10:34 +0200 (CEST)
10  X-Virus-Scanned: Debian amavisd-new at Gateway.Meine_Domain.local
11  Received: from Gateway.Meine_Domain.local ([127.0.0.1])
12   by localhost (Gateway.Meine_Domain.local [127.0.0.1]) (amavisd-new, port 10024)
13   with ESMTP id zWPSMoUged0u for <Adresse@Externe_Domain.com>;
14   Mon, 17 Jun 2013 11:10:32 +0200 (CEST)
15  Received: from host1.Meine_Domain.local (host1.Meine_Domain.local [192.168.0.10])
16   by Gateway.Meine_Domain.local (Postfix) with ESMTP id F1516E0067
17   for <Adresse@Externe_Domain.com>; Mon, 17 Jun 2013 11:10:31 +0200 (CEST)
18  To: Adresse@Externe_Domain.com
19  Subject: test
20  From: "Dr. Harry Knitter" <ich@example.com>
21  User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; )
22  Date: Mon, 17 Jun 2013 11:10:31 +0200
23  X-KMail-Transport: Gateway.Meine_Domain.local
24  X-KMail-QuotePrefix: >
25  MIME-Version: 1.0
26  Content-Type: Text/Plain;
27    charset="iso-8859-15"
28  Content-Transfer-Encoding: 7bit
29  Message-Id: <201306171110.31512.ich@example.com>
30  X-Seen: false
31  X-ENVELOPE-TO: <Adresse@Externe_Domain.com>
32  X-Length: 3387
33  X-UID: 21011
34  Status: R
35  X-Status: N
36  X-KMail-EncryptionState:
37  X-KMail-SignatureState:
38  X-KMail-MDN-Sent:

Die Geschwätzigkeit beginnt bereits beim E-Mail-Client des Senders. Die Header »X-Kmail-*« (Zeilen 23 bis 24 und 36 bis 38) verraten zusammen mit dem Header »User-Agent« (Zeile 21) schon mal den Namen des SMTP-Servers »Gateway.Meine_Domain.local« , den verwendeten E-Mail-Client und zusätzlich dessen Version, den verwendeten Desktop samt Versionsnummer und auch noch die Version des Linux-Kernels dieses Rechners. Alles unnötige Informationen, die sich entfernen lassen.

Besonders interessant ist es, die Zeilen 15 bis 1 in dieser, dem Transport in umgekehrter Reihenfolge zugeordneten Auflistung zu lesen: Von unten nach oben zeigen sie den Weg der E-Mail über die Server vom Absender bis zum Empfänger. Der erste Received-Header (Zeilen 15 bis 17) verrät bereits den FQDN des Clientrechners »host1.Meine_Domain.local« des Benutzers mit dessen IP im LAN. Das sind schon wertvolle Informationen über den internen Aufbau des Firmennetzwerks. Zusätzlich erscheint auch gleich wieder der Name des Gatewayrechners, also des SMTP-Servers »Gateway.Meine_Domain.local« .

Alles bekannt: IP, Client-OS, Netz, AV-Software

Der nächste Received-Header zusammen mit dem X-Virus-Scanned-Header erzählt allen, dass auf dieser Maschine Amavis die Mails auf Schadsoftware untersucht, und nennt den Port 10024, an dem Amavis lauscht. Die Zeilen 7 bis 9 entstanden bei der Rückgabe der Mail von Amavis an die Warteschlange des MTA, sie enthalten keine nützlichen Informationen.

Aber ganz oben in den Zeilen 1 bis 6 findet sich der letzte Received-Header, den der MTA des ISP geschrieben hat, nachdem die Mail den lokalen MTA und damit das interne Netz endgültig verlassen hatte Dieser Eintrag enthält keine internen Informationen mehr, gibt aber die externe IP des Routers und den vom DHCP des ISP zugewiesenen temporären FQDN preis. Zudem zeigen die Received-Header den Softwarenamen des Mailservers, in diesem Falle Postfix.

Wer seinen FQDN nicht der ganzen Welt mitteilen will oder muss, wählt einfach einen unverfänglichen Namen, der bestimmt nicht mit anderen Servern oder Diensten kollidiert.

Example.com

Gut ist, wenn der FQDN auch noch einen offiziellen Anklang hat wie die Test-Domain »example.com« . Da der lokale MTA Postfix ja nur im internen Netz zu sehen ist, spielt es meist auch keine Rolle, wenn er den Namen »smtp.example.com« erhält, zumal ein »dig smtp.example.com« (Listing 2) keinen Konflikt mit irgendeiner offiziellen Adresse gleichen Namens erkennen lässt.

01 ; <<>> DiG 9.7.3 <<>> smtp.example.com
02 ;; global options: +cmd
03 ;; Got answer:
04 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59422
05 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
06
07 ;; QUESTION SECTION:
08 ;smtp.example.com.      IN      A
09
10 ;; AUTHORITY SECTION:
11 example.com. 3600       IN      SOA     dns.Mein_ISP.com. hostmaster.Mein_ISP.com. 2012020100 86400 7200 604800 7200
12
13 ;; Query time: 190 msec
14 ;; SERVER: 192.168.0.1#53(192.168.0.1)
15 ;; WHEN: Mon Jun 24 11:01:16 2013
16 ;; MSG SIZE  rcvd: 118

01 Received: from smtp.example.com
02   (Name_meines_Routers.Mein_ISP.com [1.2.3.4])
03   by smtp.Mein_ISP.com (xxxxx xxxx) (RZmta 31.27 DYNA|AUTH)
04   with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 906d2cp5H92jgY
05   for <Adresse@Externe_Domain.com>;
06   Mon, 17 Jun 2013 11:10:34 +0200 (CEST)
07  Received: from localhost (localhost [127.0.0.1])
08   by smtp.example.com (Postfix) with ESMTP id 69CF0E009C
09   for <Adresse@Externe_Domain.com>; Mon, 17 Jun 2013 11:10:34 +0200 (CEST)
10  X-Virus-Scanned: Debian amavisd-new at smtp.example.com
11  Received: from smtp.example.com ([127.0.0.1])
12   by localhost (smtp.example.com [127.0.0.1]) (amavisd-new, port 10024)
13   with ESMTP id zWPSMoUged0u for <Adresse@Externe_Domain.com>;
14   Mon, 17 Jun 2013 11:10:32 +0200 (CEST)
15  Received: from host1.Meine_Domain.local (host1.Meine_Domain.local [192.168.0.10])
16   by smtp.example.com (Postfix) with ESMTP id F1516E0067
17   for <Adresse@Externe_Domain.com>; Mon, 17 Jun 2013 11:10:31 +0200 (CEST)
18  To: Adresse@Externe_Domain.com
19  Subject: test
20  From: "Dr. Harry Knitter" <ich@example.com>
21  User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; )
22  Date: Mon, 17 Jun 2013 11:10:31 +0200
23  X-KMail-Transport: Gateway.Meine_Domain.local
24  X-KMail-QuotePrefix: >
25  MIME-Version: 1.0
26  Content-Type: Text/Plain;
27    charset="iso-8859-15"
28  Content-Transfer-Encoding: 7bit
29  Message-Id: <201306171110.31512.ich@example.com>
30  X-Seen: false
31  X-ENVELOPE-TO: <Adresse@Externe_Domain.com>
32  X-Length: 3387
33  X-UID: 21011
34  Status: R
35  X-Status: N
36  X-KMail-EncryptionState:
37  X-KMail-SignatureState:
38  X-KMail-MDN-Sent:

Dass der Name des MTA nicht im DNS auflösbar ist, bedeutet nach Erfahrung des Autors nur in selten ein Problem. MTAs und Spamfilter, die das bemerken, werden es zwar monieren, bewerten dieses Manko jedoch nie so stark wie andere Faktoren. Außerdem wäre ja in der Regel auch der ursprüngliche FQDN ebenfalls nicht durch eine DNS-Abfrage des MTA des ISP auflösbar.

Wer den Mailserver neutral benennen will, setzt in der »main.cf« -Konfigurationsdatei »myhostname« auf den Wert »smtp.example.com« . Nach einem Neustart und einer Test-E-Mail zeigt Postfix die veränderten, jetzt deutlich diskreteren Headerdaten (Listing 3). Doch Zeile 23 zeigt immer noch, dass der User Kmail verwendet hat, und posaunt im Header »X-KMail-Transport« den internen Namen des Mailgateways hinaus.

Individuelle Anpassungen bleiben hier nicht aus, doch die sollte der Admin nicht auf Client-Seite erledigen müssen, denn das führt schnell zur ungeliebten Turnschuhadministration, wobei der Administrator auf jedem Client den Postausgangsserver neu eintragen müsste. Hier hilft es, gleich mehrere der immer noch übrig gebliebenen Fliegen mit einer Klappe zu erschlagen und alle unnötigen und geschwätzigen Header komplett zu eliminieren.

Posix oder PCRE

Den besten Mechanismus, um Headerdaten auf das notwendige Maß zu reduzieren, bietet Postfix selbst: den Eintrag »header_checks« in der Konfigurationsdatei »main.cf« und eine passende Tabelle mit regulären Ausdrücken und entsprechenden Anweisungen. Die Tabelle ist folgendermaßen aufgebaut: »/Regulärer_Ausdruck/MusterAktion« . Laut der sehr informativen Manpage zu Header_checks [2] gibt es dabei zwei mögliche Varianten regulärer Ausdrücke: Posix oder PCRE (Perl Compatible Regulary Expressions). Die Handbuchseite rät zur letzteren, weil sie in Sachen Performance der Posix-Variante überlegen sei.

Allerdings fehlt einer Standardinstallation von Postfix zumindest unter Debian das Paket »postfix-pcre« , es lässt sich aber schnell mit »apt-get postfix-pcre« nachinstallieren. »postconf -m« hilft bei der Erfolgskontrolle und listet alle verfügbaren Lookup-Table-Typen auf. Ausführliche Anleitungen zu regulären Ausdrücken und zu PCRE finden sich in [3].

Listing 4 enthält die (kommentierte) Datei »/etc/postfix/header_checks« und ist auf das vorliegende Beispiel abgestimmt. Ihre Einträge entfernen (über die Aktion »IGNORE« ) alle Header, deren Inhalte in der freien Wildbahn nichts verloren haben. Der Eintrag

01 # Nochmal zur Sicherheit Domain entfernen
02 /^.*\.Meine_Domain\.local.*$/i    IGNORE
03 # Amavis braucht auch keiner zu sehen
04 /^.*amavis.*$/i IGNORE
05 # Localhost-Einträge löschen
06 /^Received: from localhost.*$/i IGNORE
07 # Der MUA sollte auch nicht erscheinen
08 /^User-Agent.*$/i        IGNORE
09 # KMail ist eindeutig zu geschwätzig
10 /^X-KMail.*$/i   IGNORE
11 # weitere Regeln für individuelle Mailclients
12 [...]

header_checks=pcre:/etc/postfix/header_checks

in der Konfigurationsdatei »main.cf« teilt Postfix mit, wo er die entsprechenden Informationen zu suchen hat. Der Befehl

postmap -q <I>Suchmuster<I> pcre:/etc/postfix/header_checks

macht die Informationen endgültig verfügbar. Ein nachfolgendes »/etc/init.d/postfix reload« schließt das Ganze ab.

Header bereinigt

Das Ergebnis von Header_checks zeigt Listing 5. In solchen Mails bleiben nur noch die Informationen erhalten, die für ihren Transport unbedingt nötig sind. Informationen über den internen Aufbau des LAN sind weitestgehend eliminiert, nur die externe Router-IP und dessen vom Zugangsprovider zugewiesener Name geben noch Auskunft.

01 Received: from smtp.example.com
02   (Name_meines_Routers.Mein_ISP.com [1.2.3.4])
03   by smtp.Mein_ISP.com (xxxxx xxxx) (RZmta 31.27 DYNA|AUTH)
04   with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 906d2cp5H92jgY
05   for <Adresse@Externe_Domain.com>;
06   Mon, 17 Jun 2013 11:10:34 +0200 (CEST)
07  To: Adresse@Externe_Domain.com
08  Subject: test
09  From: "Dr. Harry Knitter" <ich@example.com>
10  Date: Mon, 17 Jun 2013 11:10:31 +0200
11  MIME-Version: 1.0
12  Content-Type: Text/Plain;
13    charset="iso-8859-15"
14  Content-Transfer-Encoding: 7bit
15  Message-Id: <201306171110.31512.ich@example.com>
16  X-Seen: false
17  X-ENVELOPE-TO: <Adresse@Externe_Domain.com>
18  X-Length: 3387
19  X-UID: 21011
20  Status: R
21  X-Status: N

Transportverschlüsselt und mit Ende-zu-Ende-Verschlüsselung des Inhalts bleiben so kaum mehr nützliche Informationen für potenzielle Angreifer übrig. Die Headerdaten der E-Mail sehen jetzt so aus, als kämen sie von einem einzigen Rechner namens »smtp.example.com« , ganz gleich von welchem Clientrechner im LAN ein Benutzer die E-Mails wirklich abgeschickt hat. Die Headerdaten werden, ausgenommen die unterschiedlichen E-Mail-Adressen und Timestamps, immer gleich aussehen.

Sensible Daten im Betreff

Apropos E-Mail-Adressen: Viele Sysadmins lassen sich Statusmeldungen per Mail zuschicken. Zum Beispiel könnte die Absenderadresse »root@Meine_Domain.local« lauten, was aber natürlich wieder Rückschlüsse auf Interna zulässt. Address Rewriting [4] beseitigt solche Informationen.

Vorsicht ist ohnehin geboten: Viele Statusmeldungen enthalten den FQDN des betreffenden Rechners aber auch im Betreff. Erwischt Header_checks einen solchen Subject-Header, schmeißt es ihn natürlich auch raus und die Mail erreicht den Empfänger, also den Sysadmin, ohne Betreffzeile – ein großer Nachteil gerade bei Mails mit Logs, die sich Admins gerne per Sieve in Ordner einsortieren lassen, in denen schnell mal hundert Mails liegen. Hier hilft folgende Regel als erster Eintrag in der Datei »/etc/postfix/header_checks« weiter:

/^Subject:(.*)@(.*)\.?<I>Meine_Domain<I>.local(.*)$/i REPLACE Subject:$(1)$(2).

Sie ersetzt den Namen der internen Domain »Meine_Domain.local« einschließlich der Subdomains, also der FQDNs der sendenden Rechner, durch einen Nullstring. Wie der Sysadmin Postfix dazu überredet, ihm den Inhalt solcher Statusmeldungen auch noch automatisch verschlüsselt zu übertragen, beschreibt der Artikel im Linux-Magazin [5].

Finetuning

Anpassungen für den individuellen Bedarf sind im beschriebenen Szenario unvermeidlich. Manche E-Mail-Programme tragen sich nämlich nicht im Header »User-Agent« , sondern mit »X-Mailer« ein. Die beschriebenen Säuberungsaktionen gestalten auch das Debuggen deutlich schwieriger: Wer selbst Analysen von Mailheadern vornehmen will, muss damit rechnen, dass nicht unbedingt alle Transportinformationen eingehender Mails erkennbar sind: Die beschriebenen Maßnahmen wendet Postfix nämlich auch bei eingehenden Mails an.

Schon Fetchmail, das vielleicht die Daten vom ISP abholt, liefert die Mails über den lokalen MTA aus – und weg sind die Header. Allerdings geschieht dies nur ein Mal, wenn Postfix die Mail von Fetchmail erhält. Die später folgenden Zugriffe des MTA, zum Beispiel beim Filtern durch Amavis bis zur Ablage in IMAP, haben keinen Einfluss mehr auf den Inhalt der dabei erzeugten Header, wenn in der Konfigurationsdatei »master.cf« als Option für die Rückgabe der Mail durch den Contentfilter an den MTA »-o receive_override_options=no_header_body_checks« eingetragen ist.

Außerdem machen manche Clients wundersame Dinge: Admins, die mit Kmail testen, werden sich fragen, warum die mit Kmail empfangenen E-Mails dennoch wieder die unerwünschten »X-KMail« -Header aufweisen. Direkt auf dem IMAP sind diese Header in der E-Mail nicht vorhanden. Sie entstehen, wenn Kmail die Mails via IMAP abholt. E-Mail-Adressen, die andere MUAs verwenden, sehen davon also nichts. Verwendet der Sender einen anderen MUA als Kmail, passiert dies ebenfalls nicht.

Fazit

Das Ausplaudern unnötiger und sicherheitskritischer Daten in den Mailheadern ist mit recht einfachen Mitteln zu unterbinden. Die beschriebenen Maßnahmen sind – sieht man von den regulären Ausdrücken ab – ohne Programmieraufwand und ohne Beeinträchtigung der E-Mail-Kommunikation möglich. Zwar bezieht sich das Beispiel auf eine relativ simple LAN-Topologie, die beschriebenen Mechanismen eignen sich aber genauso für größere Installationen.