Sophos UTM Email Protection: Empfänger verifizieren mit LDAP SSL

Die Sophos UTM Email Protection enthält einen Bug bei dem die Empfängerverifizierung einfach übersprungen wird. Im Falle der Empfänger Prüfung mittels Active Directory und der Abfrage via SSL findet keine Verifizierung der Empfänger statt. Hier einmal die problematischen Einstellungen:

  • Empfängerverifizierung mittels Active Direcory

Email Protection

  • Abfrage des Active Directory mit SSL

SNAGHTML6f6526

Im Live Log der Email Protection führt es dann zu folgenden Logeinträgen:

2016:11:16-20:45:43 utm exim-in[25000]: 2016-11-16 20:45:43 [127.0.0.1] F= R= Verifying recipient address in Active Directory 
2016:11:16-20:45:43 utm exim-in[25000]: 2016-11-16 20:45:43 H=mx.frankysweb.com [127.0.0.17]:46804 Warning: ACL "warn" statement skipped: condition test deferred: failed to bind the LDAP connection to server 127.0.0.2:636 - ldap_bind() returned -1 

Das Abfragen des Domain Controller schlägt fehl, und die Empfängerverifizierung wird übersprungen.

Empfängerprüfung via Serveranfrage (CallOut)?

Das Verhalten ist insbesondere mit Exchange 2013 und Exchange 2016 unschön, denn eine Empfängerprüfung via CallOut (Mit Serveranfrage) ist ohne Edge Transport Server nur schwer umzusetzen.

image

Da Recipient Validation erst am Hub Transport Connector stattfindet, aber nicht am FrontEnd. Exchange wird in diesem Fall also immer mit “250 Recipient OK” antworten. Die fehlende Empfänger Prüfung auf Exchange Seite ist hier Architektur bedingt. Eine Mail wird vom “Default Frontend”-Empfangsconnector immer angenommen und stumpf an den “Default”-Empfangsconnector weitergeleitet:

image

image

Die Empfängerverifizierung ist in diesem Fall also immer für die Mail Protection der UTM erfolgreich, denn erst der nachgelagerte Connector führt die Validierung des Empfängers durch. Dies ist übrigens auch der Fall, wenn die Exchange AntiSPAM Agents installiert werden.

LDAP SSL abschalten?

Äh? Nein, weil NEIN!

Sophos UTM Mail Protection anpassen (Workaround)

Das Anpassen der UTM Konfiguration via Shell wird wohl Probleme beim Support nach sich ziehen, darauf wird bereits beim Login hingewiesen:

NOTE: If not explicitly approved by Sophos support, any modifications
done by root will void your support.

Das Vorgehen sollte also mit dem Support abgesprochen werden. Ich habe nur die Home Version, also kann ich eh nicht auf den Support zurückgreifen.

Nachdem man sich auf der Shell mittels “sudo su –“ Root-Rechte verschafft hat, kann die folgende Datei mittels VI editiert werden:

vi /var/chroot-smtp/etc/openldap/ldap.conf

image

In der Datei wird die folgende Zeile hinzugefügt:

TLS_REQCERT allow

image

Danach die Datei speichern und die Mail Protection neustarten. Jetzt klappt auch die Empfängerprüfung mittels LDAP SSL:

2016:11:16-20:46:23 utm exim-in[24512]: 2016-11-16 20:46:23 [127.0.0.1] F= R= Verifying recipient address in Active Directory 
2016:11:16-20:46:23 utm exim-in[24512]: 2016-11-16 20:46:23 H=mx.frankysweb.com [127.0.0.1]:46468 F= rejected RCPT : Address not present in directory 

5 Gedanken zu „Sophos UTM Email Protection: Empfänger verifizieren mit LDAP SSL“

  1. Betrifft diesen Known Issue, leider noch kein Fix vorhanden bzw. angekündigt.
    Daher dieser Workaround aktuell die einzige Lösung. Danke Frank!

    ID24065 9.004 Regression from V8: Recipient Verification against AD not working with LDAP-SSL
    ————————————————————————
    Description: SMTP recipient verification against AD is not working with
    LDAP-SSL.
    Workaround: Option 1: Switch to non encrypted LDAP connections or
    recipient verification with callout.

    Option 2: Add the following line to
    /var/chroot-smtp/etc/openldap/ldap.conf

    TLS_REQCERT allow

    According to http://linux.die.net/man/5/ldap.conf :

    TLS_REQCERT
    Specifies what checks to perform on server
    certificates in a TLS session, if any. The can be
    specified as one of the following keywords:

    allow
    The server certificate is requested. If no certificate
    is provided, the session proceeds normally. If a bad
    certificate is provided, it will be ignored and the
    session proceeds normally.
    Fixed in: ………….

    Antworten
  2. Hallo Franky

    Leider hat die aktuellste Firmware 9.408-4 einen groben Schnitzer!
    Konkret ist eine Folge des Updates, dass unter der Einstellung Definitionen & Benutzer/ Authentifizierungsdienste/ Register Server/ Punkt Bind-DN bzw. Bind- Kennwort dieses „zurückgesetzt“ wurde. Das neue setzen des Active Directory Kennworts für den hinterlegten AD- Benutzer bringt zwar eine erfolgreichen Test, jedoch bleibt auch auf diese Art und Weise das Kennwort nicht gespeichert.

    Wird die Einstellung nach dem Speichern erneut editiert und gleich wieder erneut der Servereinstellungstest vorgenommen, so wird dieser wieder fehlschlagen, was wiederum zur Folge hat, dass die Empfängerverifizierung via Active Directory nicht mehr funktioniert (Punkt Email Protection/ SMTP/ Routing/ Empfängerverifizierung)

    Ja, ein krasser Fehler, somit werden bis das nächste Update herauskommt, sicher keine Mails mehr empfangen werden können, ausser es gibt auch hierfür einen Workaround, welchen ich zurzeit nicht kenne :-(

    Antworten
  3. Gibt es ein Update zu dem bekannten Bug mit der Empfängerverifizierung und dem LDAPS Signing? Ich würde gerne auf LDAPS umstellen, wenn die UTM damit zurechtkommt.

    Antworten

Schreibe einen Kommentar