Sophos Firewall Mail Protection in MTA mode instellen

Sophos Firewall kan e-mailverkeer niet alleen als normale firewallverbinding toestaan, maar in MTA mode ook zelf als Mail Transfer Agent tussen internet en de interne mailserver werken. De firewall accepteert SMTP-verbindingen, controleert berichten met Mail Protection en levert ze daarna af bij de gedefinieerde mailserver.

Vandaag raden we Mail Protection op de firewall alleen nog aan voor bewust geplande speciale gevallen, bijvoorbeeld wanneer een lokale Exchange-server of een andere interne mailserver direct via de firewall moet worden beschermd. Voor Microsoft 365, Google Workspace en de meeste moderne cloudmailomgevingen is Sophos Central Email meestal de betere oplossing. Central Email staat dichter bij de eigenlijke maildienst, integreert schoner met cloudmailboxen, vermindert de complexiteit in de firewallregels en voorkomt veel klassieke MTA-onderwerpen zoals MX-wijzigingen, lokale spools, relayvragen en foutanalyse op de firewall.

Nog een praktisch punt: Email Protection op de firewall voelt in vergelijking met Sophos Central Email al langer als een bestaande functie die vooral relevant blijft voor bestaande on-premises mailservers. Wie vandaag iets nieuws plant, moet daarom eerst nagaan of een cloud mail gateway de schonere architectuur is.

Technisch is dit sterk, maar ook foutgevoelig als DNS, MX-record, TLS, relay, gebruikerscontrole, policies en logs niet netjes gepland zijn. Een verkeerd geconfigureerde MTA kan legitieme e-mails blokkeren, de mailflow vertragen of in het slechtste geval als relay worden gezien.

Dit artikel legt de praktische opbouw uit voor Sophos Firewall Mail Protection in MTA mode. Het vervangt geen Sophos Central Email-planning. Voor veel Microsoft 365- of Google Workspace-omgevingen is een cloud mail gateway vaak passender. Maar wanneer een lokale Exchange, een hybride mailserver of een bewust firewallgebaseerd SMTP-pad wordt gebruikt, is een duidelijk beheerplan nodig.

Wanneer Mail Protection op de firewall zinvol is

Mail Protection op Sophos Firewall is vooral zinvol wanneer SMTP-verkeer bewust via de firewall moet lopen en de firewall meer moet doen dan alleen poort 25 doorsturen.

Typische scenario’s:

• Inkomende e-mails moeten eerst op de firewall worden geaccepteerd en gecontroleerd.
• Een interne mailserver mag niet rechtstreeks vanaf internet bereikbaar zijn.
• Spam-, malware-, bestandstype- of contentcontrole moet vóór aflevering plaatsvinden.
• Uitgaande e-mails moeten gecontroleerd via de firewall of een smarthost worden verzonden.
• Quarantaine, mail spool en SMTP-logs moeten op de firewall traceerbaar zijn.

Niet elke mailsetup hoort via de firewall te lopen. Als Sophos Central Email, Microsoft Defender for Office 365 of een andere cloud mail gateway al de volledige mailflow overneemt, moet Mail Protection op de firewall niet extra ertussen worden gezet zonder de mailflow precies te documenteren. Dubbele gateways leiden snel tot onduidelijke verantwoordelijkheden bij quarantaine, headers, SPF/DKIM/DMARC, TLS en troubleshooting.

MTA mode, Legacy mode en SMTP Relay onderscheiden

Bij Sophos Firewall moeten drie zaken duidelijk gescheiden worden:

MTA mode is de normale doelmodus voor moderne firewall-Mail-Protection-scenario’s. De lokale dienst SMTP Relay is daarentegen een Device Access-onderwerp. Die mag alleen vanuit gedefinieerde interne netwerken bereikbaar zijn. Een te brede vrijgave kan relaymisbruik bevorderen. Het hardenen van lokale diensten is beschreven in Sophos Firewall-toegang beveiligen: Device Access correct configureren.

Vereisten

Voor de inrichting moeten deze punten duidelijk zijn:

• Sophos Firewall met geldige Email Protection of passend bundle.
• Niet elk model ondersteunt MTA mode. XGS 87 en XGS 88 zijn appliances zonder MTA-mode-ondersteuning.
• Publieke DNS-zone en MX-record zijn bekend.
• Interne mailserver, doelpoort en afleverpad zijn gedocumenteerd.
• Publiek IP-adres of WAN-adres voor inkomend SMTP-verkeer is gedefinieerd.
• Firewall kan de interne mailserver routeren en bereiken.
• Uitgaande DNS-toegang van de firewall werkt.
• Gewenste TLS- en certificaatstrategie is duidelijk.
• Quarantaine- en vrijgaveproces is organisatorisch gedefinieerd.

Voor wijzigingen aan de mailflow moet een onderhoudsvenster worden gepland. Een test op productieve MX-records zonder terugvalplan is riskant, omdat inkomende e-mails afhankelijk van de afzender snel vertraagd of geweigerd kunnen worden.

Doelarchitectuur vastleggen

Eerst moet worden besloten welke richting de firewall moet verwerken.

Inkomende mailflow

Bij inkomende mailflow wijzen externe MX-records naar het publieke adres waarop Sophos Firewall SMTP accepteert. De firewall controleert het bericht en stuurt het door naar de interne mailserver.

Typisch verloop:

1. Externe afzender verbindt per SMTP met het publieke MX-adres.
2. Sophos Firewall accepteert de verbinding in MTA mode.
3. Mail Protection controleert afzender, ontvanger, spam, malware, bijlagen en policy.
4. De firewall levert de e-mail af bij de interne mailserver.
5. De interne mailserver levert in de mailbox af of verwerkt het bericht verder.

Belangrijk is dat de interne mailserver niet daarnaast ongefilterd vanaf internet bereikbaar blijft. Als parallel nog een DNAT-regel direct naar de mailserver wijst, loopt mogelijk een deel van het verkeer langs Mail Protection. Voor normale serverpublicaties is Server via DNAT publiceren de passende basis, maar bij MTA mode is de firewall zelf het SMTP-aannamepunt.

Uitgaande mailflow

Bij uitgaande mailflow verzendt de interne mailserver via Sophos Firewall. De firewall kan berichten controleren, naar een smarthost doorsturen of direct afleveren, afhankelijk van de configuratie.

Vooraf duidelijk maken:

• Mag het publieke firewall-IP rechtstreeks e-mails verzenden?
• Kloppen SPF, DKIM en DMARC voor de gekozen verzendroute?
• Is een provider-smarthost nodig?
• Moet uitgaand SMTP-verkeer tot bepaalde interne systemen worden beperkt?
• Waar worden geweigerde of vertraagde berichten bewaakt?

Voor uitgaand mailverkeer moet een eigen, traceerbare regel- en policystructuur worden gebruikt. Een algemene LAN to WAN-regel zonder duidelijke beperking is voor mailservers meestal te grof. De basis voor regelvolgorde en securityprofielen staat in Sophos Firewall-regels begrijpen en netjes opbouwen.

MX-omstelling en externe tests voorbereiden

Een Mail Protection-omstelling wordt pas kritisch wanneer externe afzenders de nieuwe route echt gebruiken. Daarom moeten MX-record, DNS-TTL, externe bereikbaarheid en rollback vóór de productieve wijziging worden gecontroleerd.

Voor de omstelling:

• Huidig MX-record, prioriteit en TTL documenteren.
• DNS-TTL vroegtijdig verlagen als snelle terugval nodig kan zijn.
• Oud mailpad en nieuw Sophos Firewall-adres duidelijk onderscheiden.
• Oude directe DNAT-regels naar de mailserver identificeren.
• Testontvangers en testafzenders definiëren.
• Terugvalplan vastleggen: oude MX, oude DNAT-regel of tijdelijke smarthost.
• Monitoring voor spool, quarantaine en mailserverqueue voorbereiden.

Nuttige externe controles vanaf een systeem buiten het eigen netwerk:

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

De commando’s vervangen geen volledige mailflowtest, maar tonen snel of DNS, poort 25 en STARTTLS in principe bereikbaar zijn. example.com en mail.example.com moeten worden vervangen door het echte domein en de echte mailhost.

Na het omschakelen moet direct een inkomende testmail worden gestuurd en het volledige pad worden gedocumenteerd:

• Verbinding zichtbaar in Log Viewer?
• Vermelding in smtpd_main.log aanwezig?
• Ontvangercontrole succesvol?
• Aflevering aan interne mailserver uitgevoerd?
• Bericht in de mailbox aangekomen?
• Geen parallelle directe aflevering langs de MTA?

Als de firewall wel e-mails accepteert maar niet aflevert, moet de MX niet meteen worden teruggezet. Eerst moet duidelijk worden of het een intern routing-, DNS-, TLS- of mailserverprobleem is. Als externe afzenders echter geen verbinding met de firewall kunnen opbouwen of legitieme e-mails breed worden geweigerd, is snelle terugval naar het vorige mailpad vaak zinvoller dan lang experimenteren in het productieve MX-pad.

MTA mode activeren

De basisinstellingen staan in Sophos Firewall onder:

Email > General settings

Daar wordt de e-mailmodus vastgelegd. Voor deze handleiding is MTA mode relevant. Na de wissel moet worden gecontroleerd of bestaande policies, hostobjecten en maildomeinen nog bij de gewenste werking passen.

In bestaande omgevingen niet zomaar tussen Legacy mode en MTA mode wisselen zonder de mailflow te testen. Verwerking, logs en policylogica verschillen. Voor een migratie moeten actuele firewallconfiguratie, MX-records, mailserverconnectors en relayinstellingen worden gedocumenteerd.

SMTP-routing en domeinen configureren

Voor inkomende e-mails moet de firewall weten welke domeinen hij moet accepteren en waarheen hij die moet afleveren.

Typisch verloop:

1. Onder Email > Policies and exceptions respectievelijk in de Mail Protection-zones de betrokken domeinen en doelservers plannen.
2. Maildomein invoeren, bijvoorbeeld example.com.
3. Interne mailserver of hostobject als afleverdoel definiëren.
4. Controleren of de firewall de mailserver op de doelpoort bereikt.
5. TLS-eisen en certificaten controleren.
6. Testmail van extern naar een bekende ontvanger sturen.

Voor interne mailservers is DNS bijzonder belangrijk. De firewall moet interne doelen correct kunnen oplossen, en externe afzenders moeten het publieke MX-record bereiken. Als interne DNS-resolutie een rol speelt, helpt DNS Request Routes op Sophos Firewall instellen.

Policies voor spam, malware en bijlagen plannen

Mail Protection is slechts zo goed als de policies die daadwerkelijk van toepassing zijn. Een policy moet niet alleen worden aangemaakt, maar met een duidelijk doel worden benoemd.

Belangrijke policyvragen:

• Welke domeinen of ontvangersgroepen worden geraakt?
• Wordt inkomend, uitgaand of bidirectioneel mailverkeer verwerkt?
• Wat gebeurt er bij spam, malware, verdachte bijlagen of ongewenste bestandstypen?
• Worden e-mails geblokkeerd, in quarantaine geplaatst, afgeleverd of met headers gemarkeerd?
• Wie mag quarantaine controleren en e-mails vrijgeven?
• Welke false-positive-processen zijn er?

Als Zero-Day Protection wordt gebruikt, kunnen verdachte e-mailbijlagen aanvullend worden geanalyseerd. De grenzen, rapporten en vrijgavebeslissing worden uitgelegd in Sophos Firewall Zero-Day Protection begrijpen en beheren.

Relay en Device Access beveiligen

Een veelgemaakte fout is de verwarring tussen MTA-mailflow en een open SMTP Relay. De firewall mag niet vanuit willekeurige netwerken als relay worden gebruikt.

Controleren:

• Onder Administration > Device access is SMTP Relay alleen vanuit benodigde interne zones bereikbaar.
• Als ACL Exception Rules worden gebruikt, zijn bronnen nauw gedefinieerd.
• Alleen gedefinieerde interne mailservers, scanners of applicatieservers mogen via de firewall relayen.
• Vanuit WAN, gastnetwerken en untrusted zones is SMTP Relay niet algemeen vrijgegeven.
• Logging is actief, zodat misbruik of foutconfiguraties opvallen.

Als printers, scanners of applicaties e-mails moeten verzenden, moet daarvoor een eigen intern relaypad worden gedocumenteerd. Zulke systemen moeten niet direct met willekeurige externe SMTP-doelen spreken als de omgeving dat kan vermijden.

Mailflow testen

Na de inrichting is één succesvolle verzending niet genoeg. Er moeten meerdere tests worden uitgevoerd en de resultaten gedocumenteerd.

Inkomend testen

Minimaal controleren:

• Extern MX-record wijst naar het verwachte adres.
• Poort 25 is van buiten bereikbaar.
• Firewall accepteert de verbinding in MTA mode.
• E-mail wordt naar de interne mailserver doorgestuurd.
• Ontvanger bestaat en ontvangt het bericht.
• Spam- of malwaretest wordt zoals verwacht behandeld.
• Quarantaine- of logvermelding is traceerbaar.

Uitgaand testen

Minimaal controleren:

• Interne mailserver verzendt via de verwachte route.
• Firewallregel en mail policy grijpen in.
• SPF, DKIM en DMARC passen bij de verzendroute.
• Doelserver accepteert het bericht.
• Bounces of Deferred-meldingen worden bewaakt.
• Geen andere interne systemen verzenden ongepland direct naar extern.

Logs controleren

Voor snelle visuele controle helpt Log Viewer. Voor diepere analyse zijn de maillogbestanden belangrijk. De toewijzing staat in Sophos Firewall Troubleshooting: services en logs.

Relevante logbestanden:

Bij acuut troubleshooting moet het testtijdstip worden genoteerd, afzender, ontvanger, onderwerp, bron-IP en Message-ID worden verzameld en daarna Log Viewer en logbestanden op tijd worden gecorreleerd.

Quarantaine, spool en opslag

Mail Protection maakt lokale data aan. Afhankelijk van volume belanden berichten in quarantaine, spool of tijdelijke gebieden. Daardoor worden opslagruimte, SSD-status en recoveryplan relevanter dan bij een pure firewallregel.

Praktische beheervragen:

• Wie controleert quarantaine en hoe vaak?
• Hoe worden false positives vrijgegeven?
• Wanneer wordt een bericht verwijderd in plaats van vrijgegeven?
• Hoe wordt een groeiende mail spool herkend?
• Is er monitoring voor opslagruimte en System Health?
• Wordt na firmware-updates een korte mailflowtest ingepland?

Voor opslag- en reportingonderwerpen passen Sophos Firewall-opslag en reports opruimen en Sophos Firewall SSD Health controleren. In HA-omgevingen moet daarnaast worden gelet op het feit dat mailquarantaine en verwerkte maildata nodegebonden bedrijfsdata kunnen zijn. De HA-basis staat in Sophos Firewall HA-clustervarianten.

Troubleshooting

Externe e-mails komen niet aan

Eerst DNS en bereikbaarheid controleren: MX-record, publiek IP, poort 25, NAT-resten, MTA mode en verantwoordelijk maildomein. Daarna in Log Viewer en in smtpd_main.log controleren of de verbinding de firewall bereikt. Als geen verbinding zichtbaar is, ligt het probleem waarschijnlijk vóór Mail Protection.

Firewall accepteert e-mails, maar levert ze niet af

Dan zijn interne mailserver, routing, DNS, doelpoort, TLS, ontvangercontrole of policy waarschijnlijker. Controleer of de firewall de mailserver kan bereiken en of de mailserver de verbinding accepteert. Reject-logs en mailserverlogs moeten tijdgerelateerd samen worden beoordeeld.

Veel e-mails blijven in de spool

Een groeiende spool wijst vaak op afleverproblemen: interne mailserver niet bereikbaar, TLS-eis past niet, DNS-resolutie mislukt of doelserver weigert het bericht. In dat geval niet alleen losse berichten opnieuw afleveren, maar de oorzaak in het routing- en SMTP-pad zoeken.

Een belangrijk geval rond regelvolgorde wordt makkelijk over het hoofd gezien: als een automatisch of handmatig gemaakte firewallregel boven de MTA-regel staat en SMTP-verkeer matcht, wordt de eigenlijke MTA-regel niet meer geëvalueerd. Dan kunnen e-mails in de mail spool blijven hangen, hoewel DNS, poort 25 en mailserver in principe correct lijken.

Controleren:

1. Rules and policies > Firewall rules openen.
2. Regels boven de MTA- of SMTP-regel controleren.
3. Nieuwe automatisch aangemaakte regels, IPsec-regels, hotspotregels of handmatig op Top geplaatste regels controleren.
4. SMTP-test opnieuw uitvoeren en Log Viewer, mail spool en smtpd_main.log vergelijken.

De regel mag niet blind naar beneden worden verplaatst als hij andere productieve doelen vervult. Beslissend is of hij SMTP-verkeer onverwacht vóór de MTA-regel onderschept.

Quarantainedigest ontbreekt voor aliasadressen

Als gebruikers aliasadressen gebruiken, moet men quarantaine-instellingen niet alleen voor het primaire mailadres controleren. Volgens Sophos worden quarantaine-instellingen standaard niet automatisch op aliasadressen toegepast. Als digestmails of vrijgaven voor aliasontvangers ontbreken, moeten aliasadressen samen met het primaire adres in de quarantaine- respectievelijk gebruikerscontext worden meegenomen.

Legitieme afzender wordt als spam herkend

False positives moeten niet meteen met brede uitzonderingen worden beantwoord. Eerst afzenderdomein, SPF/DKIM/DMARC, headers, reputatie, policy-match en getroffen ontvangers controleren. Als een uitzondering nodig is, moet die nauw beperkt en met reviewdatum gedocumenteerd worden.

Interne systemen kunnen niet relayen

Controleer of SMTP Relay onder Administration > Device access vanuit de juiste zone is toegestaan en of de bron bij de ACL past. Daarna maillogs controleren. Als een scanner of applicatie moet relayen, moet de bron als hostobject worden gedocumenteerd en niet onnodig een compleet netwerk worden vrijgegeven.

Na firmware-update werkt mail anders

Na firmware-updates moeten MTA mode, policies, certificaten, mail spool, quarantaine en relevante logs worden gecontroleerd. Voor grotere updates past aanvullend Sophos Firewall vóór SFOS 22-upgrade controleren.

Beheerchecklist

• Mail Protection-licentie en appliance-ondersteuning gecontroleerd.
• MTA mode bewust gekozen en gedocumenteerd.
• MX-record, publiek IP en interne doelserver kloppen.
• MX-omstelling, externe tests en rollback zijn voorbereid.
• Geen parallelle ongefilterde DNAT-regel omzeilt de MTA.
• Inkomende en uitgaande policies zijn begrijpelijk benoemd.
• Firewallregelvolgorde verhindert niet dat de MTA-regel grijpt.
• SMTP Relay is alleen vanuit gedefinieerde interne bronnen toegestaan.
• Quarantaine- en false-positive-proces zijn vastgelegd.
• Aliasadressen zijn in het quarantaine- en digestproces meegenomen.
• Mail spool, opslagruimte en System Health worden bewaakt.
• Logs worden lokaal, in Sophos Central of via Syslog lang genoeg bewaard.
• Na firmware-updates wordt een mailflowtest uitgevoerd.

Voor langere bewaring en correlatie met andere security-events moet men Central Firewall Reporting of Sophos Firewall Syslog naar SIEM sturen controleren.

FAQ