Gute Idee? Eingehende E-Mails mit eigener Domainendung ablehnen? (weil sie gefälscht sein müssen)

33

Ich habe eine Frage zu unserem Exchange Server: Halten Sie es für eine gute Idee, eingehende externe E-Mails abzulehnen, die am Ende unsere eigene Domain haben?

Gefällt dir eine externe eMail von fake@example.com?

Denn wenn es sich um einen echten Absender in unserem Unternehmen handeln würde, würde die E-Mail niemals von außen kommen?

Wenn ja, wie geht das am besten?

security email-server exchange-2013

— Steffen Maier
quelle

3

Haben Sie gerade eine Spam-Filterlösung installiert?

— Ewwhite

14

Stellen Sie sicher, dass Sie keine Anbieter von Webanwendungen haben, die versuchen, von Ihrer eigenen Domain aus zu senden. Zum Beispiel, wenn Sie ein Abrechnungssystem haben, das Ihren Mitarbeitern möglicherweise E-Mails von "payroll@example.com" sendet. Überprüfen Sie auch, ob Marketing oder HR möglicherweise einen externen Massenmail-Service verwenden und die Mitarbeiter diese Nachrichten erhalten sollen. Normalerweise haben diese Nachrichten einen Absender oder zumindest eine Antwortadresse von jemandem aus dem Marketing oder der Personalabteilung. In solchen Situationen können Sie in der Regel die E-Mail-Server des Dienstes in eine Zulassungsliste aufnehmen und dennoch den Eingang Ihrer eigenen Domain blockieren (das ist, was wir tun).

— Todd Wilcox

6

@NeilMcGuigan Was würde das ausmachen? Die Mail sollte trotzdem von einem internen Mailserver stammen? Es würde nicht von außerhalb des Netzwerks kommen, nur weil er nicht physisch anwesend ist.

— Matt

@ Matt Gotya, Brainfart

— Neil McGuigan

1

Wenn Sie automatische E-Mail-Benachrichtigungen von einem Ihrer Server erhalten haben, z. B. Benachrichtigungen über fehlgeschlagene Cron-Jobs oder versuchten Verstoß von IDS oder Ressourcenverwendungsmonitor, und diese so konfiguriert sind, dass die Absenderadresse mit Ihrem Domainnamen übereinstimmt. Sie müssen darauf achten, diese E-Mails entweder über Ihren internen Mailserver weiterzuleiten oder diese Server als zulässige Absender zu markieren.

— Lie Ryan

53

Ja, wenn Sie wissen, dass E-Mails für Ihre Domain nur von Ihrem eigenen Server stammen sollen, sollten Sie alle E-Mails für diese Domain blockieren, die von einem anderen Server stammen. Auch wenn sich der E-Mail-Client des Absenders auf einem anderen Host befindet, sollte er sich bei Ihrem Server (oder dem von Ihnen verwendeten E-Mail-Server) anmelden, um E-Mails zu senden.

Wenn Sie noch einen Schritt weiter gehen, können Sie Ihren Server so konfigurieren, dass SPF-Einträge überprüft werden. So viele Hosts verhindern eine solche E-Mail-Aktivität. SPF-Einträge sind ein DNS-Eintrag, ein TXT-Eintrag, der Regeln darüber enthält, welche Server E-Mails für Ihre Domain senden dürfen. Wie die SPF-Datensatzprüfung aktiviert wird, hängt von Ihrem E-Mail-Dienst ab und würde den Rahmen dessen sprengen, was hier behandelt werden soll. Glücklicherweise verfügen die meisten Hosting-Umgebungen und -Software über Dokumentation zum Arbeiten mit SPF-Datensätzen. Vielleicht möchten Sie mehr über SPF im Allgemeinen erfahren. Hier ist der Wikipedia-Artikel: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
quelle

3

@ Kurtovic Ein gut konfigurierter E-Mail-Server sollte die abgelehnte E-Mail bouncen, damit der Absender benachrichtigt wird.

— Calimo

8

@Calimo Nicht, wenn E-Mails als Spam abgewiesen werden. Dies würde es dem Spammer nur ermöglichen, es weiter zu versuchen, bis er erfahren hat, was Ihr Algorithmus zulässt und was nicht.

— Jon Bentley

27

@Calimo - nein. Accept-and-Bounce ist das Schlimmste, was Sie tun können. Sie tragen zur Spam-Abwehr bei und werden sehr schnell auf die schwarze Liste gesetzt. lehnen Sie einfach die unerwünschte E-Mail ab - dies ist das Problem des sendenden Hosts. Wenn Sie das nicht können, akzeptieren Sie, überprüfen Sie und verwerfen Sie, ob es sich um Spam oder Malware handelt. Niemals akzeptieren und abprallen.

— cas

2

@cas: Es gibt eine dritte Alternative: Ablehnung zum Zeitpunkt der SMTP-Annahme. Dies entlastet den sendenden SMTP-Server von der Erstellung einer Fehlerantwort, wenn dies gewünscht wird, und ermöglicht so vielen legitimen Absendern, zu prüfen, ob ihre E-Mails abgelehnt wurden, und gleichzeitig sicherzustellen, dass Sie selbst niemals Spam produzieren.

— R ..

2

@R .. Ich denke, Sie werden feststellen, dass dies keine dritte Alternative ist. Es ist eine Umschreibung dessen, was ich sagte: "lehnen Sie einfach die unerwünschte E-Mail ab - dies ist das Problem des sendenden Hosts."

— cas

31

Dafür gibt es bereits einen Standard. Es heißt DMARC . Sie implementieren es mit DKIM-Signierung (was ohnehin eine gute Idee ist, umzusetzen).

Die allgemeine Übersicht ist, dass Sie jede einzelne E-Mail, die Ihre Domain verlässt, mit einem DKIM-Header signieren (was ohnehin eine gute Praxis ist). Anschließend konfigurieren Sie DMARC so, dass jede E-Mail, die Ihren Mail-Server erreicht, von einer Domäne, deren E-Mail-Eigentümer nicht mit einem gültigen DKIM-Header signiert ist, abgelehnt wird.

Dies bedeutet, dass Sie weiterhin von externen Diensten E-Mails an Ihre Domain senden lassen können (z. B. gehostete Helpdesk-Software usw.), aber Spear-Phishing-Versuche blockieren können.

Das andere gute an DMARC ist, dass Sie Fehlerberichte erhalten, mit denen Sie die Ausnahmebehandlung nach Bedarf verwalten können.

Die Kehrseite ist, dass Sie sicher sein müssen, dass Sie alles gründlich geklärt haben, sonst können Sie möglicherweise legitime E-Mails löschen.

— Mark Henderson
quelle

3

Es wird dringend empfohlen, sowohl SPF als auch DKIM zu implementieren, bevor Sie DMARC testen.

— Todd Wilcox

Wie kann DMARC mit E-Mails von einem anderen Server als Ihrem eigenen arbeiten, z. B. mit externen Diensten, da diese von Ihrem Server nicht signiert würden?

— Jpaugh

1

@jpaugh Sie fügen den öffentlichen Schlüssel der anderen Server zu Ihren DMARC-Einträgen in Ihrem DNS hinzu. Sie können Ihnen den Datensatz zum Hinzufügen geben.

— Mark Henderson

Ich habe diese Antwort +1 gegeben, weil sie technisch korrekt ist - genau dafür ist und was DMARC tut -, aber DMARC ist eine sehr schlechte Idee, wenn Sie mit Dingen wie Mailinglisten zusammenarbeiten möchten, da sie gegen RFCs und RFCs verstößt im Allgemeinen schlecht benimmt.

— MadHatter unterstützt Monica

11

Ein solcher Block kann Spam reduzieren und möglicherweise das Social Engineering erschweren, aber auch legitime E-Mails blockieren. Beispiele hierfür sind Mail-Weiterleitungsdienste, Mailinglisten, Benutzer mit falsch konfigurierten Mail-Clients und Webanwendungen, die E-Mails direkt vom Webhost senden, ohne Ihren Haupt-Mailserver einzubeziehen.

Dkim kann dies bis zu einem gewissen Grad abmildern, indem es eine Möglichkeit bietet, eine Nachricht zu identifizieren, die von Ihrem Netzwerk gesendet, durch eine Mailingliste oder einen Forwarder geleitet und dann auf Ihrer Mail empfangen wurde. Dies ist jedoch keine perfekte Lösung und Sie haben immer noch das Problem, alle legitimen E-Mail-Ursprungspunkte aufzuspüren und sicherzustellen, dass sie einen DKIM-Unterzeichner durchlaufen.

Gehen Sie vorsichtig vor, insbesondere wenn Sie dies in einer vorhandenen Domäne implementieren.

— Peter Green
quelle

3

Vielleicht, aber es gibt einige Fälle, die Sie berücksichtigen müssen, bevor Sie eine solche Änderung vornehmen.

1) Nutzt jemand in Ihrem Unternehmen einen externen Dienst (zum Beispiel Survey Monkey, Constant Contact usw.), um E-Mails zu versenden, die scheinbar von Ihrer Domain stammen? Selbst wenn sie es heute nicht tun, könnten sie es in Zukunft tun?

2) Gibt es eine externe Adresse, die an Ihre Benutzer weitergeleitet wird? Angenommen, das Google Mail-Konto "mycompany.sales@gmail.com" wird an "sales@mycompany.com" weitergeleitet, und Ihr Benutzer "bob@mycompany.com" sendet an "mycompany.sales@gmail.com". In diesem Fall kommt die Nachricht von "außen" an, jedoch mit der Adresse "@ mycompany.com" von :.

3) Haben sich einige Ihrer Benutzer für externe Verteilerlisten angemeldet, bei denen die ursprüngliche Absenderadresse in Nachrichten an die Liste beibehalten wird? Wenn Bob beispielsweise "foo-list@lists.apple.com" abonniert und eine Nachricht sendet, erhält er eine eingehende Nachricht, die etwa so aussieht: Von: bob@mycompany.com An: foo-list@lists.apple. com Absender:

Wenn Ihr Server den Header "Von:" (anstelle von "Absender:") naiv betrachtet, wird diese Nachricht möglicherweise abgelehnt, weil Sie sie von außerhalb empfangen.

Aus all diesen Gründen ist die pauschale Richtlinie "... von einem echten Absender in unserem Unternehmen, die E-Mail würde niemals von außen kommen" nicht immer realisierbar.

— David Gelhar
quelle

2

Sie können dies in PowerShell tun, indem Sie Ihre Receive Connector-Berechtigungen aktualisieren, um anonyme Benutzer vom Senden als autorisierender Domain-Absender auszuschließen:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Das Problem tritt jedoch auf, wenn Sie Remoteanwendungsserver haben, die Status-E-Mails an Sie senden müssen, da diese in der Regel Ihren Domänennamen in der Absenderadresse verwenden. Es ist möglich, einen zusätzlichen Empfangsconnector für die jeweiligen IP-Adressen zu erstellen, damit Sie diese nicht versehentlich ausschließen.

— Neil
quelle

1

GMail hat eine Einstellung, mit der Sie E-Mails mit einer Nicht-GMail-Domain senden können, sofern die E-Mail-Adresse zuerst überprüft wird. Ihre Entscheidung würde diese E-Mails blockieren.

Ob Sie Benutzer haben, die diese GMail-Funktion verwenden, und ob es sinnvoll ist, sie zu bedienen, hängt stark vom Verhalten in Ihrem Unternehmen ab.

— Christian
quelle

-1

SPF heilt dies nicht, da der Umschlag möglicherweise einen ordnungsgemäßen SPF-Pass aufweist (dh Spammer, die einen kompromittierten Server verwenden), während sie die E-Mail im Umschlag fälschen. Was Sie brauchen, ist ein Block in Ihrer eigenen Domain-E-Mail-Nachricht, die einen Ursprungs-E-Mail-Server auf dem Umschlag hat, der für Sie nicht akzeptabel ist.

— Jim
quelle

"Was Sie brauchen, ist ein Block in Ihrer eigenen Domain-E-Mail-Nachricht, der einen Ursprungs-E-Mail-Server auf dem Umschlag hat, der für Sie nicht akzeptabel ist."

— Gathrawn