Linux-Magazin Clean Linux (Vorschau)

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.
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/Muster Aktion«. 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
header_checks=pcre:/etc/postfix/header_U
checks
in der Konfigurationsdatei »main.cf« teilt
Postfix mit, wo er die entsprechenden Informationen
zu suchen hat. Der Befehl
postmap ‐q Suchmuster pcre:/etc/postfix/U
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.
Transportverschlüsselt und mit Ende-zu-
Ende-Verschlüsselung des Inhalts bleiben
so kaum mehr nützliche Informationen
für potenzielle Angreifer übrig. Die