Gateway-Umgehung: Direct Send abweisen und den eigenen Weg erzwingen

MailGuard prüft jede Nachricht, die durch das Gateway läuft. Alles, was daran vorbeikommt, ist ungeprüft. Es gibt drei Wege daran vorbei, und alle drei sind schließbar.

1. Direct Send bei Microsoft 365

Microsoft 365 nimmt Post für Ihre eigenen Domänen von jedem Absender im Internet an, wenn sie an den Endpunkt ihre-domaene-de.mail.protection.outlook.com geht. Dafür braucht niemand ein Konto, ein Kennwort oder einen Konnektor. Der Weg heißt Direct Send und ist für Geräte im eigenen Netz gedacht, etwa Drucker und Fachanwendungen, die keine Anmeldung beherrschen.

Für einen Angreifer ist er die Umgehung: er schickt an diesen Endpunkt, das Gateway sieht die Nachricht nie, und der Empfänger bekommt sie ohne Prüfung. Der einzige Schutz, der dann noch greift, ist der von Microsoft selbst.

So schließen Sie den Weg. Eine Einstellung in der Exchange-Online-Organisation:

Set-OrganizationConfig -RejectDirectSend $true

Danach weist Exchange Online Post für Ihre Domänen ab, die nicht über einen Konnektor kommt. Der geführte Einrichtungsweg von Conbool setzt die Einstellung auf Wunsch mit, unter Einstellungen, Microsoft 365, Exchange einrichten. Sie können sie auch selbst setzen, der Rückweg ist $false.

Vorher prüfen. Alles, was heute über Direct Send einliefert, hört danach auf zu funktionieren. Das betrifft typischerweise:

• Multifunktionsdrucker mit Scan-to-Mail
• Warenwirtschaft, Zeiterfassung, Ticketsysteme im eigenen Netz
• Überwachungssysteme, die Alarme per Mail schicken

Für jedes dieser Geräte gibt es zwei saubere Ersatzwege: die Anmeldung mit einem eigenen Postfach über SMTP AUTH, oder ein eigener Konnektor für die fest bekannte Ausgangsadresse Ihres Standorts. Der zweite Weg ist für Geräte gedacht, die keine Anmeldung beherrschen.

Eine Liste der betroffenen Einlieferungen finden Sie in der Nachrichtenverfolgung von Microsoft 365: filtern Sie auf eingehende Post ohne Konnektor.

2. Der MX-Eintrag zeigt woanders hin

Das Gateway bekommt Post nur, wenn der MX-Eintrag Ihrer Domäne darauf zeigt. Steht dort noch das alte Ziel, läuft alles am Gateway vorbei, obwohl im Portal alles eingerichtet aussieht.

Conbool prüft das täglich für jede verifizierte Domäne. Zeigt der MX nicht auf uns, wechselt der Schutzzustand der Domäne auf MX fehlt und die Verwaltung bekommt eine Meldung. Sie sehen den Zustand im Modul unter MailGuard, Übersicht.

Prüfen können Sie es selbst mit:

dig MX ihre-domaene.de

Erwartet wird mail.conbool.com.

3. Der zweite MX-Eintrag

Ein zweiter MX-Eintrag mit höherer Vorzugszahl ist als Ausfallreserve gedacht. Ein Angreifer liest ihn genauso wie jeder andere und liefert absichtlich dort ein, weil er dort keine Prüfung erwartet. Zeigt der zweite Eintrag auf Ihr Zielsystem und nicht auf uns, ist er eine offene Tür.

Für Ausfallreserve ist bei Conbool der Notfallbetrieb gebaut: er nimmt Post an und hält sie, solange Ihr Postfach nicht erreichbar ist. Ein zweiter MX-Eintrag am Zielsystem ist damit unnötig.

Noch gravierender ist ein MX auf Microsoft mit niedrigerer Vorzugszahl als der Eintrag auf Conbool. Dann liefert jeder Absender zuerst direkt an Microsoft, und Conbool bekommt nur noch, was dort scheitert. Ist zusätzlich die Sperre aus dem nächsten Abschnitt aktiv, weist Microsoft diese Post ab.

4. Die Sperre der Direktzustellung

Der geführte Einrichtungsweg legt auf Wunsch, ab Werk eingeschaltet, einen eigenen eingehenden Connector an: Conbool Inbound Lockdown (mail.conbool.com). Er ist vom Typ Partnerorganisation, gilt für die Absenderdomäne * und nimmt nur Post an, die mit dem Zertifikat des Conbool-Mailers eingeliefert wird. Alles andere, was an ihre-domaene-de.mail.protection.outlook.com geht, weist Microsoft ab.

Die Sperre ist nicht dasselbe wie RejectDirectSend aus Abschnitt 1. RejectDirectSend weist nur Post ab, die mit einer Ihrer eigenen Domänen als Absender ohne Connector kommt. Die Sperre weist jede Post ab, die nicht über Conbool kommt, gleich von welchem Absender.

Sie gilt nur für Domänen, deren MX vollständig auf Conbool zeigt, dazu immer für die onmicrosoft.com-Adressen. Das prüft der Einrichtungsweg beim Anlegen und trägt nur diese Domänen am Connector ein. Zeigt keine Domäne vollständig auf Conbool, wird die Sperre nicht gesetzt. Eingeschaltet wird sie über Einstellungen, Domains, Domäne öffnen, Einrichtung erneuern, nachdem der MX umgestellt ist.

Geprüft wird nur beim Anlegen. Wird später wieder ein MX auf Microsoft eingetragen, bleibt die Sperre bestehen. Jeder Absender, der diesen Eintrag nutzt, bekommt dann einen Unzustellbarkeitsbericht:

550 5.7.51 TenantInboundAttribution; Rejecting. Recipient has a partner connector
with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.

Das trifft auch Absender, die selbst Microsoft 365 nutzen. Exchange Online stellt an den MX mit der niedrigsten Vorzugszahl zu, oft also direkt an Microsoft. Fällt es nur bei einzelnen Absendern auf, etwa bei Besprechungseinladungen aus Teams, liegt das meist daran, dass deren übrige Post über einen anderen Weg kommt.

So beheben Sie es. Den MX auf Microsoft entfernen, sodass nur noch Conbool eingetragen ist. Ist das nicht sofort möglich, den Connector Conbool Inbound Lockdown im Exchange Admin Center unter Nachrichtenfluss, Connectors vorübergehend deaktivieren und nach der MX-Korrektur die Einrichtung erneuern.

Welche Domänen gesperrt sind, zeigt:

Get-InboundConnector "Conbool Inbound Lockdown*" | Format-List Name,Enabled,AssociatedAcceptedDomains,TlsSenderCertificateName

Was Conbool nicht sehen kann

Ob über Direct Send eingeliefert wird, sieht nur Microsoft. Eine Nachricht, die nie bei uns ankommt, hinterlässt bei uns keine Spur, und wir haben keinen Zugriff auf die Nachrichtenverfolgung Ihres Mandanten. Die Prüfung dieser Lücke ist deshalb Ihre, und diese Seite ist die Anleitung dazu.

Was wir sehen und melden, ist der MX-Eintrag jeder verifizierten Domäne, täglich.