Sophos Firewall Mail Protection in MTA mode instellen

Sophos Firewall kan SMTP-verkeer in MTA mode zelf aannemen, controleren en doorsturen naar de interne mailserver of de volgende mailhop. De firewall is dan niet alleen een poortvrijgave voor TCP 25, maar een actieve Mail Transfer Agent met routing, spam- en malwarecontrole, quarantaine, spool en maillogs.

Wij raden Mail Protection op de firewall vandaag vooral aan voor bewust geplande on-premises- of hybride scenario’s, bijvoorbeeld wanneer een lokale Exchange-server of een andere interne mailserver rechtstreeks via de firewall moet worden beschermd. Voor Microsoft 365, Google Workspace en veel moderne cloudmailomgevingen is Sophos Central Email of een andere cloud mail gateway meestal de schonere architectuur, omdat MX, quarantaine, headers, TLS, SPF/DKIM/DMARC en support dichter bij de eigenlijke maildienst liggen.

Wanneer Mail Protection in MTA mode wordt gebruikt, moet het artikel meer bieden dan een feature-uitleg: MX-record, automatische MTA-regel, SMTP route and scan Policy, relayvrijgaven, TLS, gebruikerscontrole, spool, quarantaine en logs moeten bij elkaar passen. Anders kan de firewall legitieme e-mails weigeren, mail vertragen of onbedoeld als relay bereikbaar worden.

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: Firewall accepteert e-mail, controleert die en levert verder af. Inkomende of uitgaande SMTP-mailflow met policies.
• Legacy mode: oudere proxygebaseerde mailverwerking. Bestaande omgevingen die worden gemigreerd of bewust blijven draaien.
• SMTP Relay als lokale dienst: interne systemen verzenden via de firewall. Printers, scanners, applicaties of monitoringsystemen.

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/87w en XGS 88/88w 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

Voor deze handleiding moet MTA mode actief zijn. Als de firewall nog in Legacy mode draait, wordt met Switch to MTA mode omgeschakeld.

Na het activeren maakt Sophos Firewall automatisch een firewallregel voor SMTP/SMTPS aan met de naam Auto added firewall policy for MTA. Deze regel moet zichtbaar blijven en hoog in de regelbasis staan. Een MTA-regel mag niet als een gewone LAN-to-WAN-regel worden behandeld of terloops naar beneden worden verschoven, omdat inkomend SMTP-verkeer anders niet meer in het verwachte MTA-pad terechtkomt.

Daarna worden de basisinstellingen gecontroleerd:

1. Onder SMTP settings de SMTP hostname instellen. Dat is de hostnaam die de firewall in HELO- en bannercontexten voor systeemgegenereerde berichten gebruikt. Niet blind de interne mailservernaam invullen als de publieke mailnaam anders is.
2. Reject based on IP reputation activeren als inkomende SMTP-verbindingen op basis van slechte afzenderreputatie moeten worden geweigerd.
3. Onder SMTP TLS configuration een passend publiek vertrouwd certificaat kiezen als SMTP TLS via de firewall netjes moet worden gepresenteerd.
4. Disable legacy TLS protocols activeren, tenzij bewust gedocumenteerde oude systemen daartegen spreken.
5. Scan outgoing mails activeren als uitgaande berichten van de mailserver via de firewall ook moeten worden gecontroleerd.

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.

Address Group voor maildomeinen aanmaken

Eerst wordt een Address Group voor de beschermde maildomeinen aangemaakt:

1. Email > Address group openen.
2. Add aanklikken.
3. Group type op Email address/domain controleren.
4. Type op Manual laten staan als de domeinen handmatig worden onderhouden.
5. Onder Email address/domain het domein invoeren, bijvoorbeeld example.com, en toevoegen.
6. Save aanklikken.

Hier gaat het om domeinen, niet om afzonderlijke ontvangeradressen. Afzonderlijke bestaande of gemigreerde e-mailadressen kunnen afhankelijk van de configuratie nog werken, maar kunnen in actuele SMTP-route-and-scan-policies niet meer als nieuwe entries worden gepland. Voor een nette doeltoestand moet men daarom met domeinen en passende ontvangercontroles werken.

SMTP route and scan Policy aanmaken

De eigenlijke MTA-policy wordt onder dit pad aangemaakt:

Email > Policies and exceptions > Add a policy > SMTP route and scan

Een typisch verloop voor inkomende mail naar een interne mailserver:

1. Een duidelijke Name instellen, bijvoorbeeld Inbound example.com to Exchange.
2. Onder Protected domain de eerder aangemaakte Address Group kiezen.
3. Route by vastleggen:
   • Static host: voor vaste interne mailserver-IP-adressen.
   • DNS host: voor een DNS-naam zoals mailserver.example.com.
   • MX: wanneer de firewall op basis van MX-records moet afleveren.
4. Bij Static host de interne mailserver onder Host list kiezen. IP-hosts worden indien nodig onder Hosts and services > IP host aangemaakt.
5. Global action op Accept zetten als het domein aangenomen en volgens policy gecontroleerd moet worden.
6. Spam protection activeren en bewust beslissen of spam wordt gewaarschuwd, in quarantaine gezet, gedropt of zonder actie afgeleverd.
7. Malware protection activeren. Voor Zero-Day Protection met Single-Antivirus-Scan moet Sophos als primaire engine worden gebruikt.
8. File protection en Data protection alleen activeren als de gevolgen voor bijlagen, grote berichten, SPX en DKIM begrepen zijn.
9. Save aanklikken.

Bij meerdere interne mailservers is de routingsoort belangrijk. Bij Static host wordt naar de volgende host gewisseld als de eerste host niet bereikbaar is. Bij DNS host met meerdere A-records kan de aflevering worden verdeeld. Dat is praktisch, maar moet passen bij het mailserverdesign, TLS-certificaten en foutanalyse.

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?
• Moet Recipient verification per Callout of Active Directory worden gebruikt?
• Wie mag quarantaine controleren en e-mails vrijgeven?
• Welke false-positive-processen zijn er?

Bij Spam Protection moeten SPF, RBL, Greylisting, BATV en Recipient verification niet als pure checkboxen worden behandeld. RBL- of SPF-hits worden niet zoals normale spamacties verwerkt, maar kunnen berichten direct weigeren. Recipient verification vermindert backscatter en ongeldige ontvangers, maar kan bij AD-, TLS- of mailserverproblemen zelf een foutbron worden.

Bij uitgaande berichten is DKIM bijzonder gevoelig. SPX-versleuteling, subjectprefixen, geblokkeerde bestandstypen, Data Protection of een uitgaande banner kunnen headers of body wijzigen. Daardoor kan een DKIM-hash bij de ontvangende MTA breken. Als uitgaande signatures belangrijk zijn, moet worden besloten of de ondertekening op de mailserver, op Sophos Firewall of op een later gateway gebeurt.

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.
• Onder Email > Relay settings zijn bij Host-based relay alleen gedefinieerde mailservers, scanners of applicatieservers als toegestane bronnen ingevoerd.
• Niet benodigde zones, gastnetwerken en untrusted netwerken mogen niet algemeen relayen.
• Als cloudservices zoals Exchange Online Protection via de firewall moeten afleveren of relayen, moeten de toegestane bronbereiken zeer precies worden onderhouden. Brede Any-vrijgaven zijn een Open-Relay-risico.
• 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:

• SMTP MTA: smtpd_main.log.
• SMTP-fouten: smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Anti-Spam: sasi.log.
• Legacy SMTP/MTA: awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
• POP/IMAP Proxy: warren.log.

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.

Quarantaine direct in WebAdmin controleren

Als een firewall via Sophos Central wordt beheerd, is toegang via Central handig. Voor Mail Protection moet men toch weten waar de quarantaine lokaal staat en hoe die direct op de firewall wordt gecontroleerd.

Email > SMTP quarantine

Daar kunnen quarantainemails worden gefilterd op periode, afzender, ontvanger, onderwerp en quarantainereden. Voor beheer zijn vooral drie acties relevant:

• Delete: Bericht uit quarantaine verwijderen.
• Release: Bericht vrijgeven aan de ontvanger.
• Release and report: Bericht vrijgeven en als fout geclassificeerd melden.

Belangrijk: met virus geïnfecteerde berichten en berichten die door Zero-Day Protection als kwaadaardig zijn beoordeeld, kunnen niet zomaar worden vrijgegeven. Voor Zero-Day-Protection-items zijn bovendien passende rechten nodig als ze moeten worden verwijderd. Als de quarantaine volloopt, worden oudere e-mails opgeschoond. Dat is nog een reden om quarantaine en opslag niet pas bij klachten te controleren.

Bij SFOS 22.0 MR1 is er een belangrijk bijzonder geval: als de firewall via Sophos Central wordt beheerd, kunnen quarantaine-acties zoals Release of Delete mislukken met Invalid API request. Dat betekent niet automatisch dat mailflow, quarantaine of MTA-policy defect is. De praktische workaround is direct in te loggen op de lokale WebAdmin van de firewall en het bericht onder Email > SMTP quarantine vrij te geven of te verwijderen.

Na een update naar SFOS 22.0 MR2 of nieuwer moet de workflow opnieuw worden getest: plaats een onschadelijk testbericht in quarantaine, voer de actie uit via het geplande beheerpad en controleer daarna Log Viewer, quarantaine en mailbox van de ontvanger.

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.

Quarantaine-actie meldt Invalid API request

Als Release of Delete bij een via Sophos Central geopende firewall mislukt met Invalid API request, controleer eerst de SFOS-versie. Bij SFOS 22.0 MR1 kan precies deze workflow geraakt worden.

De volgende stap is niet om de mailpolicy opnieuw te bouwen. Ga eerst direct naar de lokale WebAdmin van de firewall en bewerk het bericht onder Email > SMTP quarantine. Documenteer daarna:

1. SFOS-versie en build.
2. Of de actie via Sophos Central of direct in WebAdmin is uitgevoerd.
3. Afzender, ontvanger, onderwerp en quarantainereden.
4. Resultaat na een test via de directe WebAdmin.
5. Of een update naar SFOS 22.0 MR2 of nieuwer gepland of al geïnstalleerd is.

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.
• Address Group voor de beschermde domeinen is netjes onderhouden.
• Firewallregelvolgorde verhindert niet dat de MTA-regel grijpt.
• TLS, DKIM, banner, SPX en Data Protection zijn op neveneffecten gecontroleerd.
• SMTP Relay is alleen vanuit gedefinieerde interne bronnen toegestaan.
• Quarantaine- en false-positive-proces zijn vastgelegd.
• Aliasadressen zijn in het quarantaine- en digestproces meegenomen.
• Directe WebAdmin-toegang voor quarantainevrijgaven is bekend als Central-acties mislukken.
• 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