Die digitale Kommunikation ist heute das Rückgrat fast jeder Organisation. E-Mails sind dabei das am weitesten verbreitete Kommunikationsmittel. Doch so alltäglich sie auch sind, E-Mails bergen oft unbeachtete Sicherheitsrisiken. Eines dieser Risiken ist die unbeabsichtigte Offenbarung interner Server-Hostnames in den sogenannten Mail-Headern. Was auf den ersten Blick harmlos erscheinen mag, kann für Angreifer eine wertvolle Informationsquelle darstellen und eine Tür zu Ihrer internen Netzwerkinfrastruktur öffnen. Dieser Artikel beleuchtet, warum diese Offenbarung ein ernstes Problem darstellt und wie Sie proaktiv Maßnahmen ergreifen können, um Ihre Systeme zu schützen.
### Die verborgene Welt der Mail-Header
Jede E-Mail, die Sie versenden oder empfangen, trägt eine Fülle von Metadaten mit sich – die sogenannten Mail-Header. Diese Header sind für den normalen Nutzer meist unsichtbar, aber für Mailserver und Administratoren essenziell. Sie enthalten Informationen über den Absender, den Empfänger, das Thema, Datum und Uhrzeit, aber auch detaillierte Routeninformationen, die die E-Mail auf ihrem Weg von Server zu Server genommen hat. Hierbei kommen oft interne Server-Hostnames ins Spiel.
Typische Header, die interne Hostnames offenbaren können, sind:
* **Received-Header**: Jeder Server, der eine E-Mail auf ihrem Weg weiterleitet, fügt einen „Received”-Header hinzu. Dieser enthält oft den Hostnamen des sendenden und empfangenden Servers, deren IP-Adressen und Zeitstempel. Wenn Ihre interne Infrastruktur mehrere Mailserver oder Applikationsserver umfasst, die E-Mails generieren und weiterleiten, können diese Header eine detaillierte Aufzeichnung Ihrer internen Netzwerk-Topologie preisgeben.
* **Message-ID-Header**: Dieser Header enthält eine eindeutige Kennung für die E-Mail. Oft wird hier der Hostname des Servers verwendet, der die E-Mail ursprünglich generiert hat (z.B. `
* **Return-Path / X-Originating-IP / X-Mailer**: Weniger häufig, aber auch hier können interne Hostnames oder sogar interne IP-Adressen erscheinen, insbesondere wenn E-Mails direkt von Anwendungen oder unzureichend konfigurierten Clients versendet werden.
Diese Informationen sind an sich nicht böswillig, sondern dienen der Nachvollziehbarkeit und Fehlerbehebung. Doch im falschen Kontext können sie zur Einladung für Cyberkriminelle werden.
### Warum die Offenbarung interner Hostnames ein Sicherheitsrisiko ist
Die Preisgabe interner Netzwerk-Informationen mag trivial erscheinen, ist aber für Angreifer ein Gold wert. Sie ermöglicht es ihnen, wertvolle Einsichten in Ihre IT-Infrastruktur zu gewinnen, ohne jemals Ihre Firewall durchbrochen zu haben.
1. **Netzwerk-Topologie-Mapping**: Durch das Sammeln mehrerer E-Mails aus Ihrem Unternehmen können Angreifer ein detailliertes Bild Ihrer internen Mail-Flusswege erstellen. Sie erkennen, welche Server für den E-Mail-Versand zuständig sind, welche zwischengeschaltet sind und welche Hostnamen sie tragen. Dies kann Aufschluss über die interne Netzwerksegmentierung und die Rolle der einzelnen Systeme geben (z.B. „mailgw01”, „appserver03”, „dbserver-prod”).
2. **Gezielte Angriffe (Targeted Attacks)**: Kennt ein Angreifer die Hostnamen und die Struktur Ihrer internen Mailserver, kann er diese Informationen für gezieltere Phishing- oder Social-Engineering-Angriffe nutzen. Er könnte sich beispielsweise als interner Mailserver ausgeben, um Anmeldeinformationen abzufangen oder Malware zu verbreiten.
3. **Schwachstellenanalyse**: Bekannte Hostnamen können mit öffentlich zugänglichen Informationen über Schwachstellen in bestimmten Systemen oder Softwareversionen abgeglichen werden. Ein Angreifer könnte vermuten, dass ein Server mit einem bestimmten Hostnamen eine bestimmte Rolle hat und daher eine bestimmte Software ausführt, für die bereits bekannte Exploits existieren.
4. **DDoS-Angriffe**: Informationen über Ihre internen Systemnamen können auch verwendet werden, um die Komplexität von Distributed Denial of Service (DDoS)-Angriffen zu erhöhen, indem sie sich als Teil Ihrer Infrastruktur ausgeben, um Verwirrung zu stiften oder interne Kommunikationspfade zu überlasten.
5. **Vertrauensbruch**: Die Offenbarung interner Details kann das Vertrauen von Partnern oder Kunden untergraben, da es auf mangelnde Sorgfalt im Bereich der IT-Sicherheit hindeutet.
Kurz gesagt: Jede Information, die Sie einem potenziellen Angreifer über Ihre interne Infrastruktur liefern, ist ein Puzzleteil, das ihm hilft, ein vollständiges Bild zu erhalten und Schwachstellen zu identifizieren. Ihre internen Hostnames sind keine Ausnahme.
### Effektive Strategien zur Verhinderung der Offenbarung
Die gute Nachricht ist, dass es mehrere effektive Methoden gibt, um die Offenbarung interner Hostnames in ausgehenden E-Mails zu verhindern. Diese Maßnahmen erfordern oft Anpassungen an der Konfiguration Ihrer Mail Transfer Agents (MTAs) oder anderer Systeme, die E-Mails versenden.
#### 1. Konfiguration des SMTP-Banners und EHLO/HELO-Kommandos
Wenn Ihr Mailserver eine Verbindung zu einem externen Server aufbaut, stellt er sich in der Regel mit einem EHLO- (Extended Hello) oder HELO-Kommando vor. Der dabei verwendete Hostname und der Name im SMTP-Banner sollten immer ein öffentlich auflösbarer Domainname sein und niemals ein interner Hostname.
* **Postfix**: Bearbeiten Sie die `main.cf` und setzen Sie `myhostname` auf einen öffentlichen Hostnamen (z.B. `mail.ihre-domain.de`). Der Wert für `smtpd_banner` kann ebenfalls angepasst werden, um generisch zu sein (z.B. `smtpd_banner = $myhostname ESMTP`).
* **Exim**: In der Konfigurationsdatei `exim.conf` können Sie `primary_hostname` auf Ihren öffentlichen Hostnamen setzen.
* **Sendmail**: Der `confDH_SHMTP_HOST` oder `confDOMAIN` Parameter sollte auf einen öffentlichen Domainnamen gesetzt werden.
Stellen Sie sicher, dass diese Hostnames nicht mit Ihren internen Hostnames übereinstimmen.
#### 2. Header-Rewriting und -Sanitizing auf dem Mail Transfer Agent (MTA)
Dies ist die mächtigste Methode, um unerwünschte Informationen aus Mail-Headern zu entfernen oder zu ändern. Fast alle modernen MTAs bieten Mechanismen zum Umschreiben von Headern.
* **Postfix Header-Checks**:
Postfix bietet mit `header_checks` eine sehr flexible Methode, um Header basierend auf regulären Ausdrücken zu modifizieren oder zu entfernen.
1. Erstellen Sie eine Datei, z.B. `/etc/postfix/header_checks`:
„`
/^Received:.*internal.hostname.com/ IGNORE
/^Received:.*[192.168./ IGNORE
/^Message-ID:.*@internal.hostname.com/ REPLACE Message-ID:
/^X-Originating-IP:.*[192.168./ IGNORE
„`
Dies sind Beispiele. `IGNORE` entfernt den gesamten Header, `REPLACE` ersetzt ihn. Sie müssen die regulären Ausdrücke an Ihre spezifischen internen Hostnames und IP-Bereiche anpassen. Achten Sie darauf, nicht *alle* `Received`-Header zu entfernen, da dies die Zustellbarkeit beeinträchtigen kann. Idealerweise entfernen Sie nur die *internen* `Received`-Header, während die externen erhalten bleiben.
2. Fügen Sie in `main.cf` hinzu: `header_checks = pcre:/etc/postfix/header_checks`
3. Aktivieren Sie die Änderungen mit `postmap /etc/postfix/header_checks` (wenn nicht pcre/regexp) und `postfix reload`.
* **Exim Header-Rewrite-Rules**:
Exim verwendet Rewrite-Regeln in seiner Konfiguration (`exim.conf`).
„`
begin rewrite
# Remove internal Received headers
^Received:.*from internal.hostname.com.*$ „” f
# Rewrite Message-ID
^Message-ID: <(.*)@internal.hostname.com>$ Message-ID: <[email protected]> T
„`
Die Syntax für Exim ist ebenfalls sehr mächtig und erfordert sorgfältige Konfiguration.
* **Sendmail Header-Checks**:
Auch Sendmail bietet Header-Rewriting über seine Konfigurationsdatei (`sendmail.mc` oder `sendmail.cf`) und kann Regeln verwenden, um Header zu überschreiben oder zu löschen. Dies ist oft komplexer als bei Postfix oder Exim.
Wichtig: Testen Sie Änderungen an den Header-Rewrite-Regeln immer ausführlich, bevor Sie sie in einer Produktionsumgebung anwenden. Fehler können dazu führen, dass E-Mails nicht zugestellt werden oder falsche Header enthalten.
#### 3. Einsatz von Mail-Relays / Edge-Servern
Eine bewährte Methode ist die Nutzung eines dedizierten Mail-Relays oder Edge-Servers, der als Gateway für alle ausgehenden E-Mails dient.
* **Funktionsweise**: Alle internen Systeme leiten ihre E-Mails an diesen Relay-Server weiter. Der Relay-Server ist der einzige, der direkte Verbindungen zu externen Mailservern aufbaut. Bevor er die E-Mails weiterleitet, strip er alle internen Header, die interne Hostnames oder IP-Adressen offenbaren könnten.
* **Vorteile**: Dies zentralisiert die Kontrolle über ausgehende Header. Interne Server können weiterhin ihre internen Hostnames in den Headern verwenden, da der Edge-Server diese entfernt, bevor die E-Mail das Unternehmensnetzwerk verlässt. Der Edge-Server selbst stellt sich dann mit einem öffentlichen Hostnamen vor.
* **Implementierung**: Der Edge-Server muss die oben genannten Header-Rewriting-Regeln anwenden. Stellen Sie sicher, dass nur der Edge-Server externe Mailverbindungen herstellen kann und interne Systeme nicht direkt ins Internet versenden dürfen (dies kann über Firewall-Regeln erzwungen werden).
#### 4. Anwendungsebene berücksichtigen
Manchmal generieren Anwendungen selbst E-Mails und fügen dabei eigene Header hinzu, die interne Informationen enthalten. Überprüfen Sie:
* **Programmcode**: Wenn Ihre Anwendungen E-Mails direkt generieren und Header setzen, stellen Sie sicher, dass sie keine internen Hostnames oder IP-Adressen in Headern wie `Message-ID`, `X-Mailer` oder anderen benutzerdefinierten Headern verwenden.
* **Konfiguration von Anwendungen**: Viele CMS, CRM-Systeme oder andere Anwendungen haben Einstellungen für den „Absender” oder den „Mail From”-Header. Stellen Sie sicher, dass diese auf externe, öffentliche Adressen konfiguriert sind.
#### 5. DNS-Konfiguration
Auch wenn es nicht direkt mit Mail-Headern zusammenhängt, ist eine saubere DNS-Konfiguration wichtig.
* **Split-DNS (Split-Horizon DNS)**: Verwenden Sie unterschiedliche DNS-Ansichten für interne und externe Clients. Interne DNS-Server sollten nur interne Hostnames auflösen, während externe DNS-Server nur die öffentlichen Hostnames und IP-Adressen Ihrer Server kennen sollten. Dies verhindert, dass interne Hostnames unbeabsichtigt über öffentliche DNS-Abfragen preisgegeben werden.
#### 6. Firewall-Regeln
Stellen Sie sicher, dass Ihre Firewall so konfiguriert ist, dass nur autorisierte Systeme (in der Regel der dedizierte Mail-Relay-Server) Port 25 (SMTP) nach außen nutzen dürfen. Alle anderen internen Server sollten nur in der Lage sein, E-Mails an den internen Relay-Server zu senden. Dies verhindert, dass ein kompromittierter interner Server direkt E-Mails mit seinen internen Hostnames ins Internet schickt, ohne dass die Header bereinigt werden.
### Testen und Verifizieren Ihrer Konfiguration
Nachdem Sie die Änderungen vorgenommen haben, ist eine gründliche Überprüfung unerlässlich.
1. **Senden Sie Test-E-Mails**: Senden Sie E-Mails von internen Systemen (z.B. einem Testclient, einer Anwendung) an externe Adressen (z.B. Gmail, Outlook.com, Ihren privaten Mail-Account).
2. **Analysieren Sie die Header**: Öffnen Sie die empfangenen E-Mails in Ihrem externen Postfach und zeigen Sie die „Original-Nachricht” oder „Header” an. Suchen Sie nach allen Vorkommen Ihrer internen Hostnames oder IP-Adressen. Tools wie „MxToolbox Header Analyzer” oder ähnliche Online-Dienste können dabei helfen, Header übersichtlich darzustellen und zu analysieren.
3. **Wiederholen und Anpassen**: Wenn Sie noch interne Informationen finden, passen Sie Ihre Rewrite-Regeln oder Konfigurationen entsprechend an und testen Sie erneut. Dies kann ein iterativer Prozess sein.
### Fazit und Best Practices
Die Offenbarung interner Server-Hostnames in ausgehenden Mail-Headern ist ein vermeidbares Sicherheitsrisiko. Durch sorgfältige Konfiguration Ihrer Mail Transfer Agents, den Einsatz von Edge-Servern und die Berücksichtigung von Anwendungsebenen können Sie Ihre Angriffsfläche erheblich reduzieren. Es geht darum, das Prinzip des „Need-to-Know” auf Ihre extern sichtbaren Metadaten anzuwenden.
Investieren Sie Zeit in die Überprüfung und Härtung Ihrer E-Mail-Infrastruktur. Eine transparente und sichere E-Mail-Kommunikation stärkt nicht nur Ihre eigene IT-Sicherheit, sondern auch das Vertrauen Ihrer Geschäftspartner und Kunden. In der heutigen Bedrohungslandschaft ist jede noch so kleine Informationsquelle für Angreifer potenziell wertvoll – schließen Sie diese Tür und machen Sie Ihre internen Hostnames zu dem, was sie sein sollten: streng interne Informationen.