Sophos UTM ist seit kurzem ein open Relay? Konfiguration nicht geändert?

Hallo Zusammen,

seit kurzem habe ich auf meiner Firewall das Problem, dass sie offenbar für den Spamversand E-Mails zulässt - ich kann keinen Fehler in der Konfiguration erkennen, zumal ich diese seit Ewigkeiten nicht mehr verändert habe. WEB.DE und GMX haben meine IP schon gesperrt, weshalb ich dringend an dieser Stelle korrigierend eingreifen muss, damit unsere Kunden wieder unsere E-Mails erhalten können.

Hier mal ein Screenshot von SMTP-Logs zugestellter Spam-E-Mails

Im Spooler hängen noch eine Hand voll IP-Adressen:Der Header sieht so aus:

2020-09-30 03:30:07 plant.nl [52.58.78.16]:25 Connection timed out
2020-09-30 03:30:07 ahhilversasdfsadf@plant.nl R=dnslookup T=remote_smtp defer (110): Connection timed out

Hier ein Screenshot vom Spooler:

Die Zustellung der E-Mails an meinen Exchange ist im Routing per Callout gesichert.
Der SMTP-Server der UTM hat bei "Listen Interface" nur die eine externe IP und die internen Netzwerke konfiguriert.

Unter Relaying sind bei "Host Based Relay" eine Hand voll interner Hosts konfiguriert, welche Mails an die Sophos senden dürfen.
Habt ihr noch Ideen, wie ich der Ursache auf die Spur kommen kann bzw. wo ein Konfigurationsfehler vorliegen könnte?
Eigentlich dürfte er doch keine E-Mails zum Weiterleiten annehmen oder?
Viele Grüße

Matthias



Fehlerhafte Formatierung versucht zu korrigieren.
[bearbeitet von: rentasad um 8:36 AM (GMT -7) am 30 Sep 2020]
Parents
  • Moin,

    zeig mal per Screenshots deine Einstellungen vom SMTP-Proxy, dann können wir mal checken ob da etwas auffälliges zu finden ist.

    --> Tab Erweitert, Relaying, Routing, Allgemein & die Hosteinträge

    By the way:

  • Hallo Jonas,

    danke für Deine Antwort. Anbei der Screenshot:

    Es ist definitiv kein ANY in der Host based Relay-Liste, sondern nur konkrete lokale Hosts die E-Mail versenden.

  • Hi Jonas,

    da gebe ich Dir recht. Dazu ein paar Gedanken

    •  Die AD-Authentifizierung hat den Nachteil, dass die Zustellung bounct, wenn die DCs nicht erreichbar sind, deshalb ist der Callout ja eigentlich ausreichend und normalerweise auch empfohlen, weil die Zustellung dann nachgeholt wird, wenn die Verbindung zum AD / Exchange wieder da ist.
    • meinen OWA habe ich über den IIS per Let's encrypt problemlos anbinden können, so dass ich zumindest keine Zertifikatsprobleme mit der Smartphoneverbindung habe
    • Warum muss ich am Exchange ein öffentliches Zertifikat haben? Die ganze E-Mail-Kommunikation übernimmt doch die Sophos?
    • Warum routet die Sophos E-Mails von einer externen E-Mail-Adresse an extern weiter, auch wenn im Routing nur die @gustini.xx Adressen enthalten sind? Rein einstellungstechnisch sollte das doch garnicht sein oder?

    Zu Deinen Anregungen von vorhin:

    >Authenticated Relay: Dürfen bei euch alle AD-User Mails versenden? Laut Screenshot, ja. Würde ich definitiv auf ein Minimum >beschränken. 

    Das habe ich abgeschaltet.

    >Host-based Relay: Sind alle hinterlegten Server zwingend notwendig? Die einzelnen Hosteinträge überprüfen, auch die IP-Einträge >dahinter. Wieder auf ein Minimum beschränken.

    Tatsächlich sind diese Hosts alle notwendig, es sei denn ich schaffe mir noch einen internen SMTP-Server zum routen an. Das sind alles Server oder Dienste oder Peripheriegeräte, die mir Status-Emails senden.

    Die entscheidende Frage ist doch, warum wird eine E-Mail von der IP 193.169.253.139 durch die Sophos geroutet?

    Könnte es vielleicht auch an einer Multipath-Regel liegen?

    Viele Grüße

    Matthias

  • Hi Matthias,

    chronologisch die Antworten zu deiner Aufzählung:

    • Welchen Exchange setzt ihr ein? Die AD-Authentifizierung funktioniert zb. beim Exchange 2013 nicht, da der Exchangeconnector zur Sophos noch keine Mailadressenüberprüfung anbietet. Dann werden auch E-Mails durchgelassen, die an nicht existierende Mailadressen gesendet werden. Beim Exchange 2019 schaut es wieder anders aus, da müsste der Callout klappen. Das Argument "wenn die DCs nicht erreichbar sind" lasse ich nicht gelten, die MÜSSEN immer 24/7 erreichbar sein, nicht nur für die FW sondern für die ganze Domäne.

    • Klar kannst du auch nur an der Sophos das richtige passende Zertifikat haben, durchgängig sauber ist es aber nur wenn auf dem Exchange auch das dementsprechende richtige SAN Zertifikat läuft (wieder die Frage nach dem Outlook / OWA Zertifikat)

    • Verlass dich nicht nur auf die hinterlegte Domäne unter Routing, diese gilt vorrangig für das empfangen von Mails mit dem anschließendem weiterleiten an den lokalen Mailserver.

    "Tatsächlich sind diese Hosts alle notwendig, es sei denn ich schaffe mir noch einen internen SMTP-Server zum routen an. Das sind alles Server oder Dienste oder Peripheriegeräte, die mir Status-Emails senden."

    Erstell doch einen internen Empfangsconnector auf dem Exchange und lass dort doch die Dienste, Server & Peripheriegeräte verbinden. Vorteil ist, dass du dann nur einen Mailserver/Host hast, der E-Mails über den Sophos SMTP-Proxy senden kann und du diesen dementsprechend schützen & konfigurieren kannst. 

    Das mit der Multipathregel glaube ich zwar nicht, dass diese dafür verantwortlich ist, aber austesten kannst du es ja mittels deaktivieren. Der Bemerk "Nur mit der ANY-Regel funktioniert das Multipath" --> Wirklich? Nehmt mal statt ANY das Netzwerk des SMTP-Proxys und zwar die Netzwerkdefinition "XX ADRESS" + SNAT evt. noch notwendig. Hintergrund, durch den SMTP-Proxy sendet nicht mehr der Exchange SMTP Verkehr raus über die WAN Schnittstelle, sondern die IP-Adresse des SMTP-Proxys.

    Gruß Jonas

  • Hi Jonas,

    danke für Deine ausführlichen Antworten - ich versuche auch der Reihe nach zu antworten.

    AD-Authentifizierung:

    Wir setzen noch einen Exchange 2013 ein, ein Wechseln auf den 2019 ist erst nächstes Jahr geplant. Ursprünglich wollten wir auf Office365 migrieren - die Kippung des Privacy-Shields macht das datenschutzrechtlich jedoch momentan schwer möglich, das guten Gewissens umzusetzen, wenn man so wie wir ein nahezu reines B2C-Unternehmen sind. Von daher weiß ich erstmal, dass die AD-Authentifizierung keine Option ist, danke.

    Mit 24/7 ist es in unserer Infrastruktur nicht immer zu gewährleisten. Wir sind ein Büro mit etwas über 15 Personen und einer überschaubaren Infrastruktur (3 ESXi / Vsphere Essentials (ohne Plus)) - bei Stromausfall / Wartungsarbeiten oder Störungen kann es durchaus (wenn auch sehr selten) mal vorkommen, dass die DCs nicht erreichbar sind - dann kommen die Kunden-Emails nicht an sondern werde sogar rejected.

    Zertifikate:

    Die Clients melden sich via GSTVMEX2.gustini.local an. Der OWA ist von innen unter dem öffentlichen Namen erreichbar, weil die Sophos den den DNS-Eintrag an die entsprechende interne IP weitergibt (A-Record)

    Den Exchange auf ein SAN-Zertifikat umzustellen, hatte ich schon mal versucht (vor Jahren), bin allerdings an der Outlook-Anbindung (Autodiscover etc.) gescheitert - da werde ich mir mal Consulting suchen müssen um das in effektiver Zeit zu lösen.

    >Erstell doch einen internen Empfangsconnector auf dem Exchange und lass dort doch die Dienste, Server & Peripheriegeräte
    >verbinden. Vorteil ist, dass du dann nur einen Mailserver/Host hast, der E-Mails über den Sophos SMTP-Proxy senden kann und du
    >diesen dementsprechend schützen & konfigurieren kannst. 

    Tatsächlich hatte ich das früher. Unsere Versandsoftware ist jedoch ziemlich "Oldschool" - die versendet z.B. die Rechnungs-Emails in dem Moment, in dem die Logistik die Lieferscheine für die Komissionierung ausdruckt. Das Problem beim Exchange war die Verarbeitungsgeschwindigkeit. Der nimmt die E-Mails nicht schnell genug entgegen, so dass der Druck in der Logistik dann zum Geduldsspiel wird. Aus diesem Grund hatte ich dann den Weg über die Sophos gesucht, weil dort die Annahme der E-Mails um Dimensionen schneller ist als am Exchange

    Zur Multipathregel:

    Hintergrund ist, dass wir 3 Internetleitungen haben. QSC, Telekom und Vodafone Kabel.

    Für den Mailversand habe ich die QSC-Leitung genommen, weil ich dort den "sichersten" IP-Kreis habe, der nicht mal wie ein Telekom- oder Vodafone-Kreis pauschal geblacklisted wird. Darüber hinaus ließ sich auch dort am validesten die RDNS-Konfiguartion für meine IP hinterlegen. Auf diese Weise muss ich mit Multipath sicherstellen, dass der RDNS/HELO genau mit der zu sendenden IP-Adresse übereinstimmt.

    Wenn ich dann im "FROM" statt ANY nur das Source-Netzwerk eingegeben habe, ließ sich der E-Mail-Versand nicht auf eine bestimmte Leitung festlegen - die Multipath-Regel hat einfach nicht gegriffen.
    Ich habe den Verdacht, dass diese FROM ANY -> SMTP -> TO ANY sich irgendwie über die Paketregeln oder Routing-Regeln im SMTP-Proxy hinweg setzt?

    Gruß Matthias

  • Habe die Multipath-Regel angepasst - Test steht noch aus:

  • Hallo Matthias,

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. Worried

    When you allow Authenticated Relay, you open the door to this type of exploit.  My guess is that someone has the credentials for one of your users in Active Directory.  This allows the bad guy to authenticate to your SMTP Proxy and to send whatever he wants.

    I don't have any clients that use Authenticated Relay, so I'm not sure what you should look for in the SMTP log to find the compromised user.  If you think my guess is on target, you might want to ask everyone to change their passwords.

    In any case, you will want a blackhole DNAT (see #2 in Rulz (last updated 2019-04-17)) for traffic from 193.169.253.139.

    My recommendation for situations like yours is to NOT use Authenticated Relay, but to use Remote Access so that work-at-home users can connect directly with your Exchange server.  Maybe you need a more-powerful server for Exchange.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

    vielen Dank für Deine Antwort. Das "Authenticated Relay" habe ich als erstes deativiert. Damit meintest Du sicherlich das SMTP-Relay über AD_Authentifizierung. Das war noch ein "Relikt" aus alten Zeiten welches ich nicht mehr benötige.

    Meine Home-User nutzen tatsächlich nur VPN für den Zugriff auf ihr Outlook/Exchange -> Sie arbeiten per RDP auf Ihren PCs.
    Von daher sollte da keine Problemursache liegen. Dennoch benötige ich die OWA-Integration für die Anbindung der Smartphones (Port 443 an Exchange).

    Vielen Dank für den Link auf die "Rule #2 " - das ist sehr informativ.

    Ich habe heute wie im Screenshot gezeigt die Konfiguration der Multipath-Rules geändert in der Hoffnung dass das etwas bewirken kann. Andernfalls weiß ich wie ich dem Weg auf die Schliche komme.

    Hast Du eine Empfehlung, über welche konkreten LOGs ich eine solche Spam-Email analysieren kann?

    Beste Grüße

    Matthias

  • UPDATE: Dein Tipp mit der Authentication war SUPER! Im SMTP-Proxy-Log habe ich nach der IP des Absenders gesucht und habe den kompromitierten User gefunden.

     Endlich weiß ich woher mein Problem stammt! Danke!

    Mit der Deaktivierung der AD-Authentifizierung am SMTP-Relay ist das Problem damit bewiesenermaßen behoben.

    Danke auch nochmal an Jonas für Deinen unermüdlichen Einsatz mir zu helfen!

  • Klingt gut, dass der Konfigurationsfehler gefunden und behoben wurde. Trotzdem zeigt die gesamte Konfiguration, dass viele Konfigurationen noch optimiert / erst noch initial umgesetzt werden müssen. Klar, du kannst es ja jetzt alles so weiter laufen lassen weil das ursprüngliche Problem ist ja jetzt weg - oder aber du gehst jetzt auch alles weitere sauber an und bist safe. Ich lasse hier mal EMOTET im Raum stehen, gerade wieder sehr aktuell im Umlauf ;-) 

    Ansonsten baue ich mal auch ein wenig positiven Druck auf, dein lokaler Exchange hat die IP: 192.168.111.71, deine Outlookclients haben das Netzwerk 192.168.110.x, stimmts? ;-)

    Drei Punkte sind da im generellen anzugehen: Active-Directory, Mailsicherheit & Websurf Sicherheit. Die Sophos unterstützt dich da super bei den beiden letzten genannten Dingen. Dann kannst du deinem Chef jederzeit sagen: "Better be safe than sorry".  

  • Hi Jonas,

    viellkommen richtig, das Thema ist damit noch nicht abgeschlossen. Mein Maßnahmenplan würde jetzt wie folgt aussehen:

    Kurzfristig

    • Den Zugriffsnamen des Exchange von gstvmex2.gustini.local auf eine externe gustini.de-Adrese umstellen
    • In dem Atemzug Autodiscovery so konfigurieren, dass die Smartphone-Anbindung ohne Klimmzüge und manuelle Konfiguration klappt

    Mittelfristig

    • Migrieren auf Exchange 2019
    • Umstellen auf AD-Abfrage im SMTP-Proxy Routing (Das kann ich ja vor einer Wartung auf Callout zurückstellen)

    Darüber hinaus habe ich aber noch das Problem, dass die Mutlipath-Rules nicht funktionieren wie ich sie oben im letzten Screenshot konfiguriert habe - der SMTP-Verkehr dann über ein anderes Interface als konfiguriert geleitet - da ist mir noch nicht so ganz klar woran das liegen könnte. Soll ich dafür mal einen eigenen Thread starten, weil das ein anderes Thema ist? Oder meint ihr ich kann die ANY->SMTP->ANDY über Uplink XY so lassen?

    Viele Grüße
    Matthias

  • Das könntest du mit Split DNS lösen mit dem Exchange (ohne jetzt die weitere AD-Infrastruktur zu kennen). Klar, der beste Weg ist es von der .local Domain wegzukommen, ist aber wieder mit deutlich mehr Aufwand verbunden.

    Autodiscover läuft prima mit MAPI mit HTTPS Verschlüsselung

    Gruß Jonas

Reply
  • Das könntest du mit Split DNS lösen mit dem Exchange (ohne jetzt die weitere AD-Infrastruktur zu kennen). Klar, der beste Weg ist es von der .local Domain wegzukommen, ist aber wieder mit deutlich mehr Aufwand verbunden.

    Autodiscover läuft prima mit MAPI mit HTTPS Verschlüsselung

    Gruß Jonas

Children
No Data