This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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



This thread was automatically locked due to age.
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.

  • anbei noch die fehlenden Screenshots:

    Advanced Settings

  • Moin, 

    danke für die Screenshots, so kann man arbeiten :-)

    Fange ich mal mit den Basics an:

    - Bitte wechselt eurer *.gustini.de Wildcarzertifikat gegen ein SAN Zertifikat für den Exchange & Sophos SMTP-Proxy aus. Sectigo bietet zb. mit dem Sectigo SSL Multidomain was vernünftiges an. 

    - Des Weiteren ist das aktuell dafür genutzte Zertifikat seit dem 21. April abgelaufen, noch ein weiteres Argument für ein jetzt neues SAN-Zertifikat :-)

    - Habt Ihr in eurer DMZ einen produktiv genutzten Backup Mailserver stehen? -> Der MX verweist nämlich darauf. das Zertifikat fehlt hier ganz. Hier muss geprüft werden, ob die Konfiguration passt. 

    - Laut eurer SPF-Konfiguration sind einige viele massige IP-Adressen "zugelassen". Überprüfen und begrenzen

    https://www.spf-record.de/spf-lookup/gustini.de

    -----

    Zu den Screenshots:

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

    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.

    Smarthost-Settings: Auch wenn die Funktion Smarthosts deaktiviert ist, lösche die Einträge dahinter. Ich hatte schon einen Fall, wo durch ein Bug der Smarthost trotzdem genommen worden ist.

    Recipient Verification: Statt Callout passt die Empfängerverifizierung über das Active-Directory besser. Dafür die Authentifizierungsdienste einrichten auf der Sophos.

    Das waren jetzt so meine Rückschlüsse auf Basis der bereitgestellten Informationen, wie die Mailserverkonfiguration im Detail hinter der Sophos ausschaut, kann ich nicht im Detail prüfen (ist ja auch besser so ;-) )

    Die Analyse hat nicht lange gedauert, hat aber gezeigt dass man an einigen Punkten optimieren kann um ein sicheres System bereitzustellen. Gerade in der heutigen gefährlichen Zeit der "Cybergefahren" absolut notwendig. Ich denke, wenn die oben genannten Punkte abgearbeitet werden, wird die Konfiguration auftauchen, die für das aktuelle Problem verantwortlich ist.  Durchaus möglich, dass der Fehler vor der Sophos liegt :-)

    Viele Grüße aus OWL, Jonas

Reply
  • Moin, 

    danke für die Screenshots, so kann man arbeiten :-)

    Fange ich mal mit den Basics an:

    - Bitte wechselt eurer *.gustini.de Wildcarzertifikat gegen ein SAN Zertifikat für den Exchange & Sophos SMTP-Proxy aus. Sectigo bietet zb. mit dem Sectigo SSL Multidomain was vernünftiges an. 

    - Des Weiteren ist das aktuell dafür genutzte Zertifikat seit dem 21. April abgelaufen, noch ein weiteres Argument für ein jetzt neues SAN-Zertifikat :-)

    - Habt Ihr in eurer DMZ einen produktiv genutzten Backup Mailserver stehen? -> Der MX verweist nämlich darauf. das Zertifikat fehlt hier ganz. Hier muss geprüft werden, ob die Konfiguration passt. 

    - Laut eurer SPF-Konfiguration sind einige viele massige IP-Adressen "zugelassen". Überprüfen und begrenzen

    https://www.spf-record.de/spf-lookup/gustini.de

    -----

    Zu den Screenshots:

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

    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.

    Smarthost-Settings: Auch wenn die Funktion Smarthosts deaktiviert ist, lösche die Einträge dahinter. Ich hatte schon einen Fall, wo durch ein Bug der Smarthost trotzdem genommen worden ist.

    Recipient Verification: Statt Callout passt die Empfängerverifizierung über das Active-Directory besser. Dafür die Authentifizierungsdienste einrichten auf der Sophos.

    Das waren jetzt so meine Rückschlüsse auf Basis der bereitgestellten Informationen, wie die Mailserverkonfiguration im Detail hinter der Sophos ausschaut, kann ich nicht im Detail prüfen (ist ja auch besser so ;-) )

    Die Analyse hat nicht lange gedauert, hat aber gezeigt dass man an einigen Punkten optimieren kann um ein sicheres System bereitzustellen. Gerade in der heutigen gefährlichen Zeit der "Cybergefahren" absolut notwendig. Ich denke, wenn die oben genannten Punkte abgearbeitet werden, wird die Konfiguration auftauchen, die für das aktuelle Problem verantwortlich ist.  Durchaus möglich, dass der Fehler vor der Sophos liegt :-)

    Viele Grüße aus OWL, Jonas

Children
  • Hallo Jonas,

    > wenn die oben genannten Punkte abgearbeitet werden, wird die Konfiguration auftauchen, die für das aktuelle
    > Problem verantwortlich ist.  Durchaus möglich, dass der Fehler vor der Sophos liegt :-)

    davon gehe ich grundsätzlich immer zuerst aus :-)

    Danke für Deine Hinweise, ich werde das mal abarbeiten. Authentifizierte AD-Mitglieder kann ich getrost deaktivieren, das ist tatsächlich noch eine historische Einstellung. Die AD-Authentifizierung ist soweit ich weiß schon vorkonfiguriert, also werde ich das mal ausprobieren, wenn das Büro nicht mehr besetzt ist ;-)

    Vielen Dank und ich gebe in Kürze noch mal Feedback.

    Matthias

  • Jonas, zu den Zertifikaten - würde etwas dagegen sprechen, Let's Encrypt-Zertifikate einzusetzen?

    Viele Grüße

    Matthias

  • Hey,

    Lets Encrypt geht technisch auch, ist aber konfigurationstechnisch (initial?) mit Win-Acme ein wenig aufwändiger so wie ich das mitbekommen habe.

  • Alles klar.

    Ich habe eben die AD-Authentifizierung aktiviert und sofort wurde die Testmail requected:

    550 Address not
        present in directory (in reply to RCPT TO command)

    Ich muss aber auch zugeben, ich habe nicht so richtig gecheckt wofür ich die BASE DN benötige. Ich habe keine spezifische OU, in der alle User und Gruppen sind, die sind je nach Verwendungszweck untergliedert in verschiedenen OUs?

    Der AD-Server ist auch hinterlegt und der Servertest ist "passed"

    Kannst Du mir da noch einen hilfreichen Tipp geben?

    Vielen Dank!

  • Moin,

    ich würde sagen, die AD- Authentifizierung kannst du einrichten, wenn  alles andere korrekt konfiguriert ist. Dann können wir uns diesbezüglich nochmal austauschen.   Deshalb die Prio erst auf die anderen Sachen.  

     Beachte: Wie ich sehe, habt Ihr eine .local AD-Domäne. Für .local Domänen kann nur schwer (= direkter ausgesprochen: "gar nicht") ein Zertifikat von einer öffentlichen Zertifizierungsstelle ausgegeben werden. Hier wird die Konfiguration durchaus schwieriger, da man beim Exchange jetzt sich einmal um .local und .de kümmern muss. Eventuell muss man das ganze jetzt splitten auf den SMTP-Proxy, den Exchange und die eigene interne .local Domain sowie öffentliche .de Domain selber. 

  • 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