none
E2k10 und anonymer Mailversand RRS feed

  • Frage

  • E2k10 HUB/CAS + E2k10 MBX + E2k3 MBX(wird demnächst abgelöst!!!) + O2k10 Clients

    Hallo,

    aktuell ist es so, das scheinbar jeder Domänen Client per Telnetbefehlen (falls installiert) und somit auch Schadsoftware.... Mails über den HUB Server verschicken kann. Es funktioniert auch mit Clients die im Netzwerk sind und nicht zur Domäne gehören und dazu bedarf es nicht einmal eines Domänenbenutzers.
    Es wäre gut, wenn ich das verhindern könnte. Optimal wäre es doch wenn nur Domänenbenutzer Mails verschicken dürften, allerdings ohne das sie sich separat authentifizieren müssen!

    Wir haben unterschiedliche Empfangskonnektoren im Einsatz. Welche, die ein Relaying über anonym, auf Netzwerkadressen eingeschränkt erlauben und einen Default Konnektor der das ganze Subnetz erlaubt und bei dem als Authentifizierung folgendes eingestellt ist:

    Als Permission Groups u.a. Anonymous users:

    Wenn ich Anonymous users deaktiviere, dann kann unsere Umgebung aber doch auch keine regulären Mails von außerhalb der Umgebung empfangen (Kunden, Lieferanten,...), richtig?

    Wie also bekomme ich es hin, dass nicht unerlaubt Mails aus unserer Umgebung verschickt werden können?

    Danke!

    Donnerstag, 22. Februar 2018 09:19

Antworten

  • > sorry das ich vielleicht nicht immer alles direkt verstehe

    Für den Anfang würde es ja reichen, wenn Du den Link liest, den ich Dir geschickt habe. Da wird ja genau das beschrieben, was Du machen willst.

    > aber es handelt sich doch um einen Empfangsconnector.

    Natürlich. Auf einem Sendeconnector gibt es auch weder Berechtigungsgruppen noch Sicherheitsberechtigungen.

    > Dort vergebe ich doch die Berechtigungen (Register Permission Groups)!

    Und Dir ist beim ganzen Lesen nicht aufgefallen, dass "Berechtigungsgruppe" (Permission Group) und "Sicherheitsberechtigung" (Security Permission) zwei unterschiedliche Wörter sind und es möglicherweise um zwei verschiedene Dinge handelt? 

    > In dem Fall Anonymous, genau wie bei dem für das externe Relaying. Bei dem geht es, bei dem Neuen nicht!

    Weil Du beim alten Connector ZUSÄTZLICH zur Permission Group noch eine Security Permission geändert hast.

    Diese zwei Schritte findest Du mehrfach auch in dem Link beschrieben.

    Beispiel 1: For more information about permissions on Receive connectors, see Receive connector permission groups and Receive connector permissions.
    Beispiel 2: Add the Anonymous users (Anonymous) permission group to the Receive connector and add the Ms-Exch-SMTP-Accept-Any-Recipient permission to the NT AUTHORITY\ANONYMOUS LOGON security principal on the Receive connector.
    Beispiel 3: 
    Set-ReceiveConnector "Anonymous Relay" -PermissionGroups AnonymousUsers
    Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"



    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dienstag, 27. Februar 2018 17:47

Alle Antworten

  • Woher weißt du, dass die Mails tatsächlich unerlaubt von euch versendet wurden?
    Es können auch "Mail delivery"-Nachrichten zurückkommen, wenn jemand von ganz außerhalb in eurem Namen Mails versendet und diese dann nicht zustellbar sind.
    Es gibt so Tage, da kommen dann ab und zu 100te solcher Nachrichten bei mir an, verhindern lässt sich dies überhaupt nicht.

    Technisch gesehen müsste dies mit Firewalleinstellungen machbar sein.
    Die Clients in eurem Netz dürfen für die Mail-Port's nur an euren Mailserver (Exchange) senden und nicht nach draußen (was in diesem Fall auch das Nutzen privater Mailkonten verhindert).
    Die Konfiguration für Mailkonten muss bei den Clients gesperrt werden, da man ja sonst neue Konten einrichten könnte.

    Donnerstag, 22. Februar 2018 11:06
  • Hallo,

    ich habe mich wahrscheinlich nicht klar ausgedrückt, sorry!

    Ich kann z.B. mit einem Client im Netz per Telnet Mails verschicken. Das will ich verbieten. Wenn das jeder mit einem beliebigen NB im Netz kann, kann das auch eine Schadsoftware. Das würde ich gerne verbieten!

    Ich könnte nun Port 25 aus den Netzen verbieten, den muss ich aber offen halten, da es auf einigen Clients Tools gibt, die über Port 25 verschicken können müssen. Da die Clients mit dem Tool wechselnde IP Adressen erhalten, kann ich das auch nicht mit Regeln abfangen! Von daher muss es sehr wahrscheinlich anhand von Authentifizierung gehen.

    Danke!

    Donnerstag, 22. Februar 2018 11:35
  • Eine Firewall kann neben den Portregeln auch Programme sperren.
    Somit müsstest du den Port 25 generell sperren, aber für deine Clienttools das Senden über Port 25 zulassen.

    Eine andere Idee habe ich dazu auch nicht.

    Wobei aber eigentlich die meisten Mailprovider inzwischen auf Verschlüsselung umgestellt haben sollten und Port 25 somit nicht mehr zugänglich sein sollte.

    Donnerstag, 22. Februar 2018 12:00
  • Unsere Firewall kann keine Apps sperren!
    Es geht nicht um die Provider sondern den Mailversand von intern über unseren HUB Server.

    Danke!

    Donnerstag, 22. Februar 2018 12:12
  • Das verstehe ich nun nicht.
    Heißt das, euer interner Mailserver ist per Telnet erreichbar?
    Dann ist das doch euer Sicherheitsproblem.
    Oder geht man per Telnet z.B. an den 1und1-Server oder gmail o.ä.?

    Die Windowseigene Firewall könnte aber App's sperren, man muss sie nur scharf schalten.

    Donnerstag, 22. Februar 2018 12:39
  • Der Server ist intern per Telnet erreichbar. Ich rede nur von intern auf unseren Mailserver.
    Donnerstag, 22. Februar 2018 13:25
  • Moin,

    die Standard-Einstellungen sehen wir folgt aus:

     - ohne Ameldung -> nur interne Empfänger

     - mit Anmeldung, aber nur mit der zur Anmeldung gehörenden Mail-Adresse -> alle Empfänger

    Das wird geregelt über die Sicherheitsberechtigungen auf dem Connector. Sollte das bei dir anders sein, muss das jemand umgestellt haben:

    https://technet.microsoft.com/en-us/library/mt668454(v=exchg.160).aspx

    Der erste Eingangskanal ist hierbei das Trippel "eigene IP-Adresse, eigener Port, Remote IP-Adresse".

    Innerhalb des Trippels kann man nicht weiter differenzieren, was bedeutet, dass Programme, die vom gleichen Host kommen, mit gleichen Einstellungen senden müssen.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 22. Februar 2018 13:52
  • Hallo Robert,

    danke, aber ich verstehe das nicht wirklich.
    Wo finde ich das mit ohne Anmeldung und mit Anmeldung zugehörende Mail Adresse?

    Du meinst wahrscheinlich folgendes was ich getestet habe:
    Telnettest mit nicht Domänencomputer: Dort muss ich im Telnet eine in der Organisation verfügbare email Adresse als Absender verwenden und kann dann auch nur intern Mails versenden.
    Telnettest mit Domänencomputer: gleiches wie im Test zuvor. Warum geht das nicht nach extern?
    Telnettest mit Domänencomputer aber mit ExchangeAdminrechten: Absendeadresse kann auch fiktiv sein. Empfänger nur Organisations intern.

    Die Berechtigungen vom Empfangsconnector hatte ich ja angehängt.
    Mit Trippel meinst du wahrscheinlich die Einstellungen im Register Network.

    Es sieht also so aus, als wenn ich in unserem Netz nur intern mit Telnet relayen könnte. Die Frage ist welche Einstellung das nun beeinflusst das es nicht nach extern geht und ob ich das auch intern verbieten kann.

    Donnerstag, 22. Februar 2018 15:18
  • Hast Du Dich in der SMTP-Verbindung im Telnet Test authentifiziertert? Vermutlich nein, also war das ohne Anmeldung und wie Du selbst bemerkt hast, konntest Du nur intern schicken.

    Wie die Sicherheitsberechtigungen auf einem Connector geändert werden habe ich Dir im Link geschickt.

    > Die Frage ist welche Einstellung das nun beeinflusst das es nicht nach extern geht

    Die Sicherheitsberechtigung auf dem Connector.

    > ob ich das auch intern verbieten kann.

    Ein neuer Connector anlegen mit den internen IP-Adressen und dort anonyme Benutzer nicht zu lassen. das bedeutet dann aber, dass ALLE internen Verbindungen mit Anmeldung erfolgen müssen.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 22. Februar 2018 15:35
  • Moin, Moin,

    Mit Trippel meint Robert, dass Du Exchange SMTP Dienste durch Empfangskonnektoren an eine IP & Port auf dem Exchange binden kannst. In der Konfiguration des Konnektors kannst Du jetzt festlegen welche Quell IPs (SMTP-Clients) mit diesem Konnektor sprechen dürfen.

    Jedes Mailsystem auf das ein MX Record zeigt muss anonyme Verbindungen auf SMTP Port 25 zulassen. Sonst könnte je keiner aus der weiten Welt Dir schreiben.

    Telnet dein_mail_server 25
    220 dein_mail_server Microsoft ESMTP MAIL Service ready
    ehlo xxxxxxx.yyy
    250-dein_mail_server Hello [Quell-IP]
    250-SIZE 37748736
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-X-ANONYMOUSTLS
    250-AUTH NTLM
    250-X-EXPS GSSAPI NTLM
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250 XRDST
    mail from: deine_EXCHANGE_SMTP_Adresse
    250 2.1.0 Sender OK
    rcpt to: 12344321@xxxyyyxxxyyy.de
    550 5.7.1 Unable to relay

    Und siehe da wenn nicht jemand an den Einstellungen geschraubt hat, dann erfolgt kein Relay.

    Gruß Malte

    Donnerstag, 22. Februar 2018 15:37
  • Hallo Malte,

    vielen Dank für deine Antwort!

    Das mit dem Connector weiß ich im Prinzip und habe ja auch seit Jahren welche eingerichtet, so wie oben geschrieben. Das Anonymous aktiviert sein muss, damit ich aus der Welt Mails empfangen kann, hatte ich ja oben auch gefragt/vermutet. Also, kann ich Anonymous im Client Empfangsconnector nicht entfernen, da die User ja ansonsten keine Mails von extern erhalten würden. Damit kann ich dann also auch nicht verhindern das man in dem Netz der Outlookclients Mails mit Telnet oder sonst was verschickt. Richtig?

    Danke!

    Donnerstag, 22. Februar 2018 16:53
  • Ich wusste gar nicht das man sich im Telnet Auth. kann. Ich dachte der Context unter dem es läuft reicht.

    Über AUTH LOGIN scheint es zu gehen, nachdem ich meinen User und Pwd base 64 gewandelt habe.

    Wenn ich Anonymous verbiete bekommen die User aber auch keine Mails mehr von außerhalb der Organisation, richtig?

    Danke!

    Donnerstag, 22. Februar 2018 16:58
  • SMTP hat eine eigene Authentifizerung, "Windows integriert" gibt es nur mit speziellen Applikationen (zu denen Telnet nicht geört).

    > Wenn ich Anonymous verbiete bekommen die User aber auch keine Mails mehr von außerhalb der Organisation, richtig?

    Du verbietest es ja nur auf dem Connector mit den internen IP-Adressen.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 22. Februar 2018 17:00
  • Hallo und danke bis hier hin.

    Ich habe nun mal einen weiteren Connector angelegt um von einer Adresse X Mails nach extern zu verschicken. Allerdings schickt er die nicht raus. (Relaying nicht möglich) Wenn ich auf einem anderen bestehenden Connector die IP des Clients eintrage, dann kann ich nach extern verschicken.

    Ich habe bei dem neuen Connector die gleichen Einstellungen wie bei dem alten verwendet und hier kann ich nichts rausschicken.

    Dauert es bis ein neuer Connector funktioniert? Muss ich den irgendwie noch zusätzlich registrieren,....?

    Danke!

    Freitag, 23. Februar 2018 12:19
  • Hallo Paulchen,

    alle Exchange Server Versionen haben mit der Installation einen Satz von Standard Konnektoren mit eingerichtet. Bis zur Version 2010 wurde nicht unterschieden zwischen Client- & Serverkommunikation und Frontend & HubTransport.

    Die durch die Installation eingerichteten Konnektoren, sind so konfiguriert, dass erstmal kein Open Relay möglich ist.

    So ist der "Default FrontEnd SERVERNAME" für die interne Kommunikation zwischen Exchange Servern, SMTP in von externen Systemen vorkonfiguriert und akzeptiert Verbindungen von allen Quell IPs. Auf diesen Konnektor dürfen nur Exchange Server und Anonyme Verbindungen erfolgen. Exchange Server (Gruppe Exchange Installed Systems oder so ähnlich) dürfen nach erfolgter Authentifizierung auch Relay durchführen lassen. Anonyme Verbindungen dürfen nur Nachrichten an Empfänger der Exchange Organisation übergeben. Ein Relay ist also nicht möglich.

    Dieser "Default FrontEnd SERVERNAME" ist auch für die SMTP Kommunikation zwischen Exchange Servern notwendig. Selbst wenn Du nur einen Exchange Server hast, dann solltest Du am Scope des Konnektors nichts ändern.

    Wenn Du verhindern möchtest, das Benutzer von ihrem Client aus diesen Konnektor verwenden, dann erstelle einen zusätzlichen Empfangs Konnektor für Port 25, der alle IP Adressen Deiner Clients im Scope enthält (und nur die der Clients). Als Permission Groups stellst Du "Exchange Users" ein.

    Welchen Konnektor ein Exchange Server dem Kommunikationspartner anbietet erfolgt nach dem Prinzip "best match".

    https://technet.microsoft.com/en-us/library/jj657447(v=exchg.150).aspx

    https://www.msxfaq.de/connector/receiveconnector.htm

    Gruß Malte


    • Bearbeitet Malte Pabst Freitag, 23. Februar 2018 19:37
    Freitag, 23. Februar 2018 19:34
  • Hallo Malte,

    danke für die Antwort.

    Ich habe mehrere Connectoren: Client (Port 587); Default (25) und einen Externes Relay.

    Über den externen Relay  (25) können irgendwelche Kopierer, Produktionsmaschinen nach Extern Mails verschicke. (Permission Anonymous) Dort ist eingestellt, das bestimmte Adressen über den Hub Server Mails versenden dürfen. Wenn ich dort die Adresse meiner Supermailer Clients eintrage können Mails nach extern verschickt werden und ich kann per Telnet mit fiktiven Adressen nach extern schicken. Da ich das aber nicht für das Netz der Supermailerclients will (zumal die dynamische Adressen haben) Habe ich 1:1 zu dem Verteiler einen neuen Connector angelegt, und das Netz odereine einzelne IP aus dem Supermailernetz eingetragen und es kann nichts relayed werden. Ich verstehe nicht warum das mit dem bestehenden Connector geht, aber mit einer "Kopie" davon nicht!

    BEst match dürfte doch nicht greifen, da ich nach Extern vom Supermailerclient nur verschicken kann, wenn ich es in den Connector Externes Relay eintrage. Wenn ich es da rausnehme match ja nichts. Also dürfte dann nur der neu angelegte Connector matchen, tut er aber nicht!

    Ist es ein Problem wenn er den gleichen Port und HUB Server hat wie der andere Connector? Quellnetz ist ja anders. Beim Anlegen des Connectors habe ich im Wizard Custom ausgewählt, das kann doch auch nicht das Problem sein. Config sieht wie folgt aus:

    Danke!

    Dienstag, 27. Februar 2018 15:08
  • Moin,

    auch auf die Gefahr hin, mich wiederholt zu wiederholen:

    Anonymes Relay über Sicherheitsberechtigungen auf dem Connector geregelt.

    Diesen Link hatte ich Dir bereits oben am 22.02. gegeben, er gilt weiterhin unverändert:

    https://technet.microsoft.com/en-us/library/mt668454(v=exchg.160).aspx


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dienstag, 27. Februar 2018 15:18
  • Hallo Robert,

    sorry das ich vielleicht nicht immer alles direkt verstehe aber es handelt sich doch um einen Empfangsconnector. Dort vergebe ich doch die Berechtigungen (Register Permission Groups)! In dem Fall Anonymous, genau wie bei dem für das externe Relaying. Bei dem geht es, bei dem Neuen nicht!

    Ich kann dir leider nicht folgen, Sorry!

    Danke!

    Dienstag, 27. Februar 2018 16:12
  • > sorry das ich vielleicht nicht immer alles direkt verstehe

    Für den Anfang würde es ja reichen, wenn Du den Link liest, den ich Dir geschickt habe. Da wird ja genau das beschrieben, was Du machen willst.

    > aber es handelt sich doch um einen Empfangsconnector.

    Natürlich. Auf einem Sendeconnector gibt es auch weder Berechtigungsgruppen noch Sicherheitsberechtigungen.

    > Dort vergebe ich doch die Berechtigungen (Register Permission Groups)!

    Und Dir ist beim ganzen Lesen nicht aufgefallen, dass "Berechtigungsgruppe" (Permission Group) und "Sicherheitsberechtigung" (Security Permission) zwei unterschiedliche Wörter sind und es möglicherweise um zwei verschiedene Dinge handelt? 

    > In dem Fall Anonymous, genau wie bei dem für das externe Relaying. Bei dem geht es, bei dem Neuen nicht!

    Weil Du beim alten Connector ZUSÄTZLICH zur Permission Group noch eine Security Permission geändert hast.

    Diese zwei Schritte findest Du mehrfach auch in dem Link beschrieben.

    Beispiel 1: For more information about permissions on Receive connectors, see Receive connector permission groups and Receive connector permissions.
    Beispiel 2: Add the Anonymous users (Anonymous) permission group to the Receive connector and add the Ms-Exch-SMTP-Accept-Any-Recipient permission to the NT AUTHORITY\ANONYMOUS LOGON security principal on the Receive connector.
    Beispiel 3: 
    Set-ReceiveConnector "Anonymous Relay" -PermissionGroups AnonymousUsers
    Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"



    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dienstag, 27. Februar 2018 17:47
  • "Natürlich. Auf einem Sendeconnector gibt es auch weder Berechtigungsgruppen noch Sicherheitsberechtigungen."

    Und genau das ist doch sein Problem, dass er das Senden verhindern will.
    I.d.R. muss man sich allerdings zum Senden ja auch erst mal anmelden wie zum Abholen.

    Dienstag, 27. Februar 2018 19:59
  • "Natürlich. Auf einem Sendeconnector gibt es auch weder Berechtigungsgruppen noch Sicherheitsberechtigungen."

    Und genau das ist doch sein Problem, dass er das Senden verhindern will.
    I.d.R. muss man sich allerdings zum Senden ja auch erst mal anmelden wie zum Abholen.


    Das ist bei Exchange schon so geregelt, wie Robert schreibt. Alle Berechtigungen hängen am Receive Connector.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 27. Februar 2018 20:49
  • > Und genau das ist doch sein Problem, dass er das Senden verhindern will.

    Er hat mittendrin das Thema gewechselt. Aus "wie verbiete ich anonym senden" wurde "warum geht der zweite anonym Connector nicht".

    Ist aber im Prinzip egal: Beide Fälle werden über Berechtigungsgruppen, event. Sicherheitsberechtigungen und vermutlich einem eigenen Connector geregelt.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 28. Februar 2018 07:31
  • Um das Thema abzuschließen:

    Im bereits erstellten Connector habe ich die Auth. auf Basic gestellt, die Berechtigungsgruppen auf Exchange User und die Sicherheitsberechtigungen wie folgt:

    Es hatte nicht funktioniert, weil das Recht MS-Exch-SMTP-Accept-Any-Recipient nicht gesetzt war.

    Nun können nur auth. Benutzer mit ihrem Massenmailtool Mails verschicken und keine Anonyme aus dem Netzsegment.

    Danke für die Unterstützung!

    Donnerstag, 8. März 2018 14:25