MX-Loopback

Auf der Seite MX-Record wird erläutert, wie ein Mailserver die zuständige Gegenstelle ermitteln kann, um eine Nachricht zuzustellen. Der MX-Record verweist auf einen Namen welcher wiederum auf eine IP-Adresse verweist.

In einer perfekten Welt sind die so veröffentlichten Mailserver rund um die uhr erreichbar, antworten ohne Fehler auf Verbindungsanfragen und funktionieren einfach. Die Realität sieht aber anders aus. Natürlich sind Systemausfälle, falsch konfigurierte Mailsysteme, Spamschutzfilter etc. immer wieder ein Grund, warum ein Mailserver seine Nachricht erst verspätet oder gar nicht versenden kann. Zudem ist die Existenz eines MX-Records nicht verpflichtend, d.h. es kann Domänen geben, die einfach keine E-Mails annehmen. Aber in all diesen Fällen kann der Mailserver damit umgehen.

Das Problem auf dieser Seite ist ein oft absichtlich falsch gesetzter MX-Eintrag, welcher zu einer Störung des eigenen Mailservers führen kann. Hier sind zwei Angriffspunkte bekannt:

  • MX-Eintrag überlang
    Es gibt keine Vorschrift, wie viele MX-Einträge eine Domäne maximal enthalten darf. Größere Firmen haben oft mehrere Mailserver während kleine Firmen meist nur ein oder zwei MX-Einträge vorweisen können. Ein Angreifer könnte nun 1000 MX-Einträge vornehmen und einen Mailserver z.B. über eine Quittung oder eine unzustellbarkeit eine Mail an diese Domäne senden lassen.
    Wenn der Entwickler des Mailservers solche große Datenmengen nicht abfängt, kann sehr schnell ein Bufferüberlauf in der Namensauflösung auftreten.

Diese Gefahr ist nicht aus der Luft gegriffen. Auch Exchange 2000 hatte zeitweilig das Problem und der SMTP-Dienst ist unsanft beendet worden.

  • MX-Eintrag verweist auf eigenen Mailserver
    In diesem Fall verweist ein MX-Eintrag für eine Domäne z.B. auf die IP-Adresse 127.0.0.1. Versucht nun ihr Mailserver eine Nachricht an diese Domäne zu senden, dann wird er "sich selbst" finden und die Mail an sich selbst zustellen. Nun hängt es davon ab, wie ihr Mailserver konfiguriert ist, ob er die Mail verwirft oder sogar als Schleife immer wieder versendet.
    Wenn es jemand GENAU auf Sie abgesehen hat, kann er natürlich auch ihre interne oder offizielle IP-Adressen als MX-Eintrag einstellen. Hier kann ich nur hoffen, dass ihr Mailserver solche Nachrichten "an sich selbst" ablehnt, da er für die Domäne nicht zuständig ist.

Achtung:"Loopback" ist nicht nur 127.0.0.1 sondern eigentlich alles mit 127.x.x.x.

Mit einer geeigneten Konfiguration ist dies aber sicher zu vermeiden, wie anhand des folgenden Bildes verdeutlicht werden soll.

Betroffen ist nur das System, welches als letzte Kette einer Mailkonfiguration die Mails über MX-Einträge in das Internet versendet. Auf allen Systemen, auf denen Sie die Nachrichten mittels Eintrag eines "Smarthost" versenden, kann das Problem nicht auftreten.

Autoritative Domäne

Der einfachste und wichtigste Schritt ist die Konfiguration der SMTP-Domänen und besser noch der Empfänger, die Sie überhaupt erst annehmen wollen. Ist diese Konfiguration vorgenommen, dann kann jemand im Internet gerne seinen MX-Eintrag auf 127.0.0.1 einstellen. Wenn Sie eine Mail an diese Domäne senden, versucht ihr externes System diese an sich selbst zuzustellen. Da der Zielempfänger natürlich in einer anderen externen Domäne steht, sollte ihr Mailserver schon beim "RCPT TO" auf SMTP-Protokollebene mit einer Fehlermeldung den Versuch beenden. Ihr eigener Mailserver wird dann eine unzustellbarkeit an den internen Absender versenden, der natürlich auch nicht gefälscht sein sollte. Das ist jedoch ihr Verantwortungsbereich.

Oftmals ist dieser Schutz aber nicht aktiv (besonders beim Einsatz eines dummen Relays) oder nur auf dem offiziellen externen Interface zu aktivieren. Dann kann ein System von intern oder ein Prozess auf dem Server selbst über 127.0.0.1 doch Nachrichten einstellen.

Oder Sie erlauben auch intern den "Versand" mit gefälschten Absenderadressen. Dann ist es möglich, dass intern jemand eine Mail an eine solch präparierte 127.0.0.1-Domain versendet und als Absender wiederum eine präparierte Domain verwendet. Dann versucht ihr Mailserver die E-Mail an sich selbst zuzustellen, was nicht geht und der NDR geht erneut an sich selbst, was auch verhindert wird. Ein nicht zustellbarer NDR wird jedoch bei den meisten Systemen gelöscht oder landet in BADMAIL.

TCP/IP-Kommunikation

Trotzdem kann es sinnvoll sein, auch auf IP-Ebene die Konfiguration zu härten. Egal, ob dieses letzte System nun selbst nur ein "Relay", ein "Proxy" oder ihr einziger Mailserver ist, so können Sie sich den Versand und besonders den Empfang von Nachrichten mittels SMTP als eigenständige Prozesse vorstellen. für die Kommunikation wird das Protokoll TCP/IP verwendet, zu dem Netzwerkkarten konfiguriert sein müssen.

  • Netzwerkkarte 1 (1.1.1.1)
    Ein PC hat immer mindestens eine Netzwerkkarte, die direkt, über einen Router oder eine Firewall an Internet angeschlossen ist. Durch diese Netzwerkkarte bekommt ihr PC eine IP-Adresse. Über diese Schnittstelle ist meist auch das Default Gateway konfiguriert und erreichbar
  • Loopback Adapter 127.0.0.1
    Zusätzlich hat jedes System mit TCP/IP aber auch noch die besondere Adresse 127.0.0.1, die im Bild auch als Netzwerkkarte eingetragen ist.
  • Netzwerkkarte 1 (2.2.2.2) und weitere optional
    Einige Mailserver haben sogar weitere Netzwerkkarten

Wenn ihr PC mehrere Netzwerkkarten als "Team" verschaltet hat, dann zählen Sie bitte einfach die IP-Adressen ihres PCs. Windows Teaming erlaubt mehrere Netzwerkkarte als "eine virtuelle Karte" zusammen zu schalten, um Ausfälle zu reduzieren und Bandbreite zu addieren.

Um nun erwünscht und unerwünschte Kommunikation zu steuern müssen Sie verstehen, was passiert. Wenn das System mit einem anderen System "spricht" muss es nämlich eine IP-Adresse aus seinen Pool verwenden. Hierbei gilt:

Von Nach SourceIP ZielIP Beschreibung

System

Internet

1.1.1.1

InternetIP

Normaler versand einer Mail an ein gültiges System

System

1.1.1.1

1.1.1.1

1.1.1.1

Hier versucht das System drei verschiedene Arten mit sich selbst zu sprechen. Beachten Sie, dass hier nicht immer 127.0.0.1 als SourceIP zum Einsatz kommt !!

System

127.0.0.1

1270.0.1

1270.0.1

System

2.2.2.2

2.2.2.2

2.2.2.2

System

intern

2.2.2.2

intern

Diese Verbindung kennzeichnet eine Mail vom Relay zum internen System

intern

1.1.1.1

intern

1.1.1.1

Diese Verbindung kann funktionieren. Das interne System kann oftmals dank Leitwege eine Verbindung zu 1.1.1.1 aufbauen. Das Rückpaket wird dann aber wieder mit der 2.2.2.2 an das interne System versendet !!!

intern

127.0.0.1

 

 

Diese Verbindung ist nicht möglich. Das Interne System kann nie den Loopback Adapter des Relay adressieren

intern

2.2.2.2

intern

2.2.2.2

Dies ist der normale Weg zum Versand einer Mail eines internen Mailserver an das Gateway

Internet

System

InternetIP

1.1.1.1

Die ist der normale Weg zum Empfang einer Mail aus dem Internet

Internet

127.0.0.1

x

x

nicht möglich

Internet

2.2.2.2

x

x

nicht möglich

Die Tabelle soll deutlich machen, dass die SourceIP ihres Servers abhängig vom Ziel sich ändern und selbst wenn das System mit sich selbst spricht, gibt es mehrere Kombinationen. Aus diesem Wissen können Sie nun ihren eingehenden SMTP-Server konfigurieren, denn Sie wissen genau, welche IP-Adresse von wo zu erreichen ist.

  • Global SourceIP = 127.0.0.1 verhindern
  • Global SourceIP = 1.1.1.1 verhindern
  • Global SourceIP = 1.1.1.1 verhindern
  • Intern
    nur bekannte Mailserver erlauben
  • Internet: Stop 127.0.0.1
    Der Server muss keine Verbindungen von 127.0.0.1 annehmen
  • Internet: Stop 1.1.1.1
    Der Server wird auch nicht mit seiner externen Adresse an sich selbst senden
  • Internet: Stop Intern
    Sie können auch alle internen "privaten" Adressen verbieten, das diese nie das externe Interface erreichen können

Eine solche Sicherung verhindert allerdings, dass z.B. das Gateway selbst mittels Blat sich selbst mal eine Mail versendet.

Exchange 2007 und 2010

Exchange 2003 und älter können mit dem Problem von Loopback-Adresse noch nicht umgehen und erzeugen eine Schleife, bis der Hopcount überschritten wurde., Exchange 2007 und 2010 hingegen erkennen diese Fehlkonfiguration und beenden den unfug mit einer unzustellbarkeitsmeldung:

 

Zusammenfassung

Eigentlich ist es schon erschreckend, dass nicht alle Mailserver von sich aus einen MX-Eintrag auf 127.0.0.1 als ungültig ablehnen. Allerdings verbietet die RFC einen solchen Eintrag nicht und es kann ja auch Einsatzfälle dazu geben. Wenn aber ein Störer oder Spammer so versucht, Rückantworten zu unterdrücken oder Systeme zu stören, dann wirft dies ein eher schlechtes Licht auf den Administrator. Ein korrekt konfiguriertes System sollte nämlich kein Problem mit solchen Nachrichten haben. Sie sollten Sie daher eher fragen warum ihr Mailserver, der nur Nachrichten von Extern erhalten soll, z.B.: Nachrichten mit internen Absenderadressen oder externen Zieladressen überhaupt annimmt. Würde ihr eingehender Mailserver diese gleich ablehnen, dann wäre die Schleife unterbrochen noch ehe Sie angefangen hat.

Weitere Links