Sophos Firewall Mail Protection in Legacy mode configureren

In Legacy mode werkt Sophos Firewall als transparante mailproxy. De interne mailserver blijft het werkelijke SMTP-endpoint; de firewall stuurt het verkeer via de bestaande firewall- en NAT-regels door en controleert het daarbij op spam, malware, bestandstypen en Data Control-matches.

Dit verschilt fundamenteel van MTA mode. De firewall wordt geen Mail Transfer Agent, neemt de bezorging via beschermde domeinen niet over en biedt voor dit pad geen MTA mail spool. Een geslaagde SMTP-poorttest bewijst daarom noch de proxyscan, noch dat het juiste beleid is toegepast.

⚠️ Het wijzigen van de SMTP Deployment Mode is een globale wijziging van het mailbeveiligingspad. Voor de omschakeling moeten een backup, bestaand beleid, firewall- en NAT-regels en een getest terugvalpad zijn gedocumenteerd. Een MTA-probleem is geen reden om ongepland naar Legacy mode over te schakelen.

Legacy mode in negen stappen

1. Documenteer het bestaande inkomende en uitgaande SMTP-pad met IP-adressen, poorten, NAT en Firewall Rule IDs.
2. Controleer of een transparante proxy werkelijk beter past dan MTA mode.
3. Zorg voor een configuratiebackup en onafhankelijke beheerstoegang.
4. Kies onder Email > General settings voor Switch to legacy mode.
5. Bepaal de SMTP-groottelimiet, de actie voor te grote berichten, IP Reputation, DoS-limieten en het TLS-gedrag.
6. Maak alleen het benodigde SMTP malware- en SMTP spam-beleid aan of controleer de volgorde ervan.
7. Beperk inkomende DNAT- en uitgaande SNAT-paden tot de werkelijke mailserver.
8. Activeer Scan SMTP of Scan SMTPS in de firewallregels die daadwerkelijk matchen.
9. Valideer inkomende en uitgaande testberichten met Rule ID, beleidsresultaat, certificaat en Legacy-proxylogs.

Kiezen tussen Legacy mode en MTA mode

Legacy mode past vooral bij bestaande omgevingen waarin de interne mailserver al rechtstreeks via NAT is gepubliceerd en dit pad behouden moet blijven. SFOS bevindt zich transparant tussen de externe peer en de server. MX-doel, SMTP-acceptatie en bezorglogica blijven onderdeel van het bestaande mailserverontwerp.

MTA mode is de betere keuze wanneer de firewall zelf berichten moet aannemen, ze per beschermd domein moet routeren en relayen en ze bij tijdelijke bezorgproblemen in een spool moet bewaren. Mail logs en mail spool behoren uitdrukkelijk bij dit bedrijfsmodel. De volledige inrichting staat in Mail Protection in MTA mode configureren.

Volgens de SFOS 22-help is MTA mode niet beschikbaar op XGS 87/87w en XGS 88/88w. Dat maakt Legacy mode echter niet automatisch tot een geschikte cloudmailarchitectuur. Microsoft 365, Google Workspace en moderne gehoste diensten hanteren eigen TLS-, authenticatie- en antimisbruikvereisten. Ondersteuning voor een transparante proxy moet vooraf worden bevestigd.

Kort gezegd: MTA mode heeft een eigen mailflow. Legacy mode beveiligt een reeds werkend SMTP-pad. Wie deze modellen door elkaar haalt, zoekt later in het verkeerde log, bij de verkeerde NAT-bestemming of in een spool die niet bestaat.

Voorbeeldtopologie en terugvalpad

Het volgende voorbeeld gebruikt documentatiewaarden en moet vóór implementatie aan de werkelijke omgeving worden aangepast:

• interne mailserver 10.20.30.25 in de zone DMZ
• openbaar SMTP-adres 192.0.2.25 op het WAN-pad
• inkomende SMTP-service TCP 25
• optioneel SMTPS op TCP 465, alleen wanneer peers en server deze variant werkelijk gebruiken
• firewallregels SMTP_In_Legacy en SMTP_Out_Legacy

192.0.2.25 behoort tot het TEST-NET-bereik en is geen productiewaarde. Voer vóór de wijziging een externe inkomende en een uitgaande test met tijdstempel uit. Bewaar de momenteel gematchte Rule IDs, het openbare bronadres van de uitgaande server en de certificaatketen.

Het terugvalpad bestaat niet alleen uit het terugzetten van de modus. Ook nieuwe scanopties, beleidsvolgorde, DNAT, reflexive of handmatige SNAT-regels en tijdelijke tests moeten naar de gedocumenteerde vorige toestand kunnen worden hersteld.

Globale SMTP-instellingen vastleggen

Groottelimiet, oversize-actie en DoS-bescherming

Onder Email > General settings > SMTP settings bepaalt Don’t scan emails greater than de maximale berichtgrootte voor scanning. In het SMTP-pad betekent de waarde 0 volgens de SFOS 22-help 51,200 KB, niet onbeperkt. Voor grotere berichten zijn Accept, Reject en Drop beschikbaar.

Accept bezorgt een te groot bericht zonder scan. Reject weigert het en informeert de afzender, terwijl Drop het zonder melding verwijdert. Deze keuze is een bewuste risico- en bedrijfsbeslissing. Een niet-geteste Drop bemoeilijkt de foutanalyse; een niet-beoordeelde Accept veroorzaakt een scanlacune die moet worden gedocumenteerd.

Verify sender’s IP reputation controleert het IP-adres van de afzender vóór de spamcriteria van het SMTP-beleid. De SMTP DoS-waarden beperken verbindingen, berichten en ontvangers. Productielimieten worden afgeleid uit het werkelijke mailvolume en een baseline, niet uit een algemeen internetvoorbeeld overgenomen.

Bypass spam check for SMTP/S authenticated connections slaat de spamcontrole wereldwijd over voor verbindingen die de mailserver als geauthenticeerd meldt. Dit is alleen verantwoord nadat de authenticatie, toegestane bronnen en bescherming tegen misbruik op dit pad zijn gecontroleerd. Een geslaagde aanmelding vervangt noch de malwarescan, noch een negatieve test met een niet-geauthenticeerde verbinding. Domeinen onder Spam check exceptions vormen eveneens een wereldwijde bypass en worden niet gebruikt als snelle vervanging voor een nauw begrensde uitzondering.

De globale e-mailbanner biedt Inline, no conversion, MIME part en Off. Hij verschijnt alleen wanneer SMTP- of SMTPS-scanning actief is in de overeenkomende firewallregel. Omdat de wijziging van de body een bestaande DKIM-handtekening kan verbreken, wordt het werkelijke uitgaande pad gevalideerd door de headers bij de ontvanger te controleren.

TLS niet overschatten vanwege een selectievakje

Kies onder SMTP TLS configuration het CA- of servercertificaat dat voor scanning is bedoeld. Allow invalid certificate blijft uitgeschakeld. Volgens de help schakelt Disable legacy TLS protocols alleen protocollen vóór TLS 1.1 uit en bewijst dit geen concrete TLS 1.2- of TLS 1.3-sessie.

Sophos wijst daarnaast op een belangrijke Legacy-beperking: de firewall bouwt de TLS-verbinding op via het IP-adres van het domein in plaats van de domeinnaam. Als meerdere domeinen één IP-adres delen, kan de certificaatvalidatie mislukken. In dat geval adviseert Sophos een ander beveiligingspad, zoals Sophos Email Security. De controle wordt niet omzeild met Allow invalid certificate.

Require TLS negotiation dwingt TLS af voor geselecteerde Remote Hosts of netwerken; Require sender email domains doet dit voor afzenderdomeinen. Wanneer de TLS-verbinding niet kan worden opgebouwd, verwijdert SFOS de betrokken berichten. Skip TLS negotiation staat bewust onversleutelde SMTP-verbindingen naar geselecteerde peers toe en hoort alleen in gedocumenteerde uitzonderingen thuis.

Scanbeleid bewust toepassen

Na activering van het Email Protection-abonnement past Sophos Firewall in Legacy mode automatisch het standaardbeleid default-smtp-av toe op SMTP-verkeer. Eigen beleid wordt aangemaakt onder Email > Policies en in lijstvolgorde verwerkt. Controleer daarom eerst welk bestaand beleid de concrete afzender en ontvanger matcht.

SMTP malware scan

Een SMTP malware scan-beleid stuurt geblokkeerde bestandstypen, MIME-uitzonderingen, antivirusscanning en bezorgacties aan. Bij Single antivirus geldt de geselecteerde engine volgens de help alleen voor inkomende berichten; uitgaande berichten worden door beide engines gescand. Dual antivirus voert de primaire en secundaire engine na elkaar uit.

De actie Quarantine wordt gecombineerd met de acties voor ontvanger en beheerder. Don’t deliver, Deliver original en Remove and deliver hebben sterk verschillende gevolgen. Een beveiligde of niet-scanbare bijlage mag niet automatisch met malware worden gelijkgesteld. Elke actie vereist daarom een testbericht, een verwachte ontvangerstoestand en een gedocumenteerd vrijgavepad.

Quarantine betekent niet automatisch dat de ontvanger geen bericht krijgt; de Delivery option for recipient blijft bepalend. Volgens Sophos werkt Notify sender alleen samen met Don’t deliver. Beveiligde bijlagen worden niet gescand, maar kunnen nog steeds een melding activeren. De afzonderlijke beheerdersactie bepaalt of geen kopie, het origineel of een bericht zonder bijlage naar de beheerders gaat. Deze vier resultaten worden niet uit één geslaagd testbericht afgeleid.

SMTP spam scan

Een SMTP spam scan-beleid kan matchen op spamclassificatie, bron of bestemming, RBL, berichtgrootte, headers of een Data Control List. Afhankelijk van het pad zijn Reject, Accept, Change recipient, Prefix subject, Drop en Quarantine beschikbaar.

Het criterium Data control list en de SPX-toewijzing in dit beleid gelden alleen voor uitgaande berichten. None past de gekozen actie daarentegen toe op alle berichten tussen de opgegeven afzender- en ontvangergroepen. Change recipient bezorgt niet ook aan de oorspronkelijke ontvanger, maar vervangt deze door de geconfigureerde bestemming. Deze drie bereiken worden met een positieve en een negatieve ontvangersituatie getest voordat het beleid in de productievolgorde wordt geplaatst.

Eigen bestandstypen en Data Control voorbereiden

In Legacy mode worden eigen bestandstypen onder Email > Policies > File type > Add gemaakt op basis van een template, bestandsextensies of MIME-typen. Voer extensies zonder voorafgaande punt in; alleen eigen typen zijn bewerkbaar. Een nieuw type wordt niet automatisch aan bestaande policies toegevoegd. Open de betrokken scanpolicy, voeg het bestandstype toe en sla de policy opnieuw op. Een positieve bijlagetest en een vergelijkbare negatieve test tonen of de bedoelde policyactie werkelijk wordt toegepast.

Een Data Control List wordt onder Email > Data control list > Add opgebouwd uit de benodigde Content Control Lists. Met de filters Type en Region worden alleen passende patronen voor financiële, identiteits- of andere gevoelige gegevens geselecteerd. Een lijstmatch bepaalt nog geen actie; die staat in de gekoppelde scanpolicy. Een kleine pilotlijst met een positieve en een negatieve inhoudstest is veiliger dan een brede verzameling niet-gecontroleerde CCL’s.

In Legacy mode kan SPX in dit beleid worden geselecteerd voor uitgaande berichten. Wachtwoordmodel, portal en validatie vormen echter een afzonderlijke beveiligingsprocedure; zie SPX-e-mailversleuteling configureren. Voeg geen Data Control List of SPX-toewijzing toe aan de eerste basistest van de proxy.

Schakel bij een bevestigde misclassificatie geen breed beleid uit. E-mailuitzonderingen veilig maken en testen legt uit hoe afzonderlijke controles voor een exacte combinatie van bron, afzender en ontvanger worden overgeslagen en hoe daarna niet-matchend verkeer wordt getest.

Optionele e-mailjournaling privacybewust gebruiken

Onder Email > General settings > Email journaling > Add kan SFOS kopieën van inkomende SMTP/S-berichten voor geselecteerde ontvangers of adresgroepen naar een afzonderlijk journaladres sturen. De selectie Any omvat alle inkomende berichten. De functie geldt alleen voor SMTP/S en journaliseert geen POP- of IMAP-verkeer.

Journaling maakt een extra kopie van de e-mail. Het is niet automatisch een manipulatiebestendig archief en bewijst niet dat aan wettelijke bewaarplichten is voldaan. Voor de activering worden het doel, de bevoegde ontvangers, de toegang tot de journalmailbox, versleuteling, bewaartermijn, benodigde opslag en verantwoordelijke eigenaar vastgelegd.

Voor de eerste test wordt één testmailbox gekozen in plaats van Any. Een inkomend bericht voor deze mailbox moet op de normale bestemming en in de journalmailbox verschijnen; een bericht voor een niet-geselecteerde ontvanger mag geen journalkopie opleveren. Het journaladres mag geen mailflow activeren die de kopie terug naar SFOS stuurt en een lus veroorzaakt.

De ontvangerselectie wordt pas na de positieve en negatieve test uitgebreid. Voor de rollback wordt de journalinvoer verwijderd of de gedocumenteerde vorige toestand hersteld. Reeds afgeleverde kopieën blijven in de journalmailbox en moeten volgens de eigen bewaarregels daarvan worden behandeld.

NAT en firewallregels combineren

Het inkomende SMTP-pad publiceren

Voor inkomende berichten vertaalt een DNAT-regel het openbare WAN-adres naar de interne mailserver. Beperk Original Source zo sterk als het mailontwerp toelaat; Original Destination is het bedoelde openbare adres; Translated Destination is 10.20.30.25 of de werkelijke mailserver. Original service en translated service blijven beperkt tot de daadwerkelijk aangeboden SMTP-poorten.

Een reflexive regel maakt bovendien SNAT aan voor de omgekeerde richting. Selecteer deze alleen als precies deze openbare bronidentiteit voor het uitgaande pad is bedoeld. Meerdere WAN-links, smarthosts of afwijkende providerroutes vereisen een eigen routing- en SNAT-ontwerp. De algemene volgorde en de bestemmingszone na NAT staan in Een server met DNAT publiceren.

Twee nauw begrensde firewallregels gebruiken

Voor validatie zijn afzonderlijke regels duidelijker dan één bidirectionele regel met meerdere zones en Any-objecten:

• Inkomend: WAN naar de zone van de interne mailserver, bestemmingshost 10.20.30.25, alleen vereiste SMTP-services, logging ingeschakeld
• Uitgaand: zone en host van de interne mailserver naar WAN of de concrete smarthost, alleen vereiste SMTP-services, logging ingeschakeld

Activeer onder Scan email content in beide benodigde richtingen Scan SMTP en alleen bij werkelijk SMTPS-gebruik Scan SMTPS. Een ingeschakeld selectievakje voegt een ontbrekende service niet automatisch toe aan een correct beveiligingsontwerp. Service, NAT, serverlistener en scanoptie moeten hetzelfde poortpad beschrijven.

Plaats de regels boven algemenere regels die hetzelfde verkeer al matchen. Na het opslaan is de gelogde Firewall Rule ID doorslaggevend. Regelstructuur, NAT-zone en volgorde worden behandeld in Sophos Firewall-regels veilig configureren.

Mailflow en proxyscan valideren

Stuur eerst een klein extern bericht naar een testmailbox. Laat daarna de interne mailserver een tweede bericht naar een gecontroleerde externe ontvanger sturen. Geef beide tests unieke onderwerpen en UTC-tijdstempels.

Voor STARTTLS op poort 25 en een directe TLS-verbinding op poort 465 helpen vanaf een geautoriseerd testsysteem bijvoorbeeld de volgende alleen-lezen controles:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Vervang mail.example.net door de werkelijke FQDN en test alleen werkelijk aangeboden poorten. OpenSSL bevestigt bereikbaarheid, certificaatketen en onderhandelde TLS-parameters. Het bewijst noch succesvolle mailbezorging, noch malware-, spam- of Data Control-scanning.

In Log Viewer moeten bron, bestemming, service, actie en Firewall Rule ID met de nieuwe regels overeenkomen. Correleer voor de Legacy SMTP/S-proxy awarrensmtp.log en awarrenmta.log met hetzelfde tijdstip. De logbestanden worden uitgelegd in Sophos Firewall-services en -logs.

Voer daarna een negatieve test uit. Een onbedoelde bron, een niet-vrijgegeven poort of een testbericht zonder beleidscriterium mag niet per ongeluk hetzelfde beveiligingspad krijgen. Gebruik geen echte malware bij productietests; gebruik voor de scanvalidatie gevestigde onschadelijke testpatronen en een gecontroleerde mailbox.

Fouten per symptoom afbakenen

SMTP werkt, maar het beleid wordt niet toegepast

Controleer eerst de Firewall Rule ID. Als een andere regel matcht, corrigeer dan volgorde, bron, bestemming, NAT-doel en service. Als de verwachte regel matcht, moeten Scan SMTP of Scan SMTPS, de beleidsvolgorde en de afzender- en ontvangergroepen bij de test passen. Een beleid alleen activeert de transparante proxy niet.

Inkomende mail bereikt de server niet

Controleer het openbare bestemmingsadres, de DNAT-hit, translated destination, bestemmingszone, serverlistener en retourpad afzonderlijk. Een open TCP-verbinding tot de firewall bewijst niet dat DNAT en de firewallregel de interne server bereiken. Packet Capture en Rule ID moeten ingang en forwarding tonen.

Uitgaande mail gebruikt het verkeerde openbare IP-adres

Controleer SNAT, de reflexive regel, WAN-gateway, SD-WAN-route en het gedrag van reply packets. De Legacy-proxy kiest niet automatisch het openbare bronadres dat nodig is voor SPF, RDNS of providertoestemming. Bewijs het concrete pad vóór een globale wijziging van Route Precedence.

TLS mislukt nadat scanning is geactiveerd

Leg FQDN, bestemmings-IP, certificaat, uitgever, keten en onderhandelde versie vast. Bij meerdere domeinen op één IP-adres kan de gedocumenteerde IP-gebaseerde certificaatcontrole de oorzaak zijn. Allow invalid certificate wordt niet als snelle oplossing geactiveerd.

Een bericht ontbreekt en in MTA mail spool staat niets

Dit is geen bruikbaar succescriterium in Legacy mode, omdat mail spool en MTA-specifieke mail logs bij MTA mode horen. De relevante keten bestaat hier uit de firewallregel, NAT, SMTP-serverlogs, Log Viewer, awarrensmtp.log en awarrenmta.log. Controleer berichten in quarantaine afzonderlijk onder Email > SMTP quarantine.

Veilig terugrollen

Herstel voor de rollback eerst de pilotregels en scanopties naar de gedocumenteerde vorige toestand. Verwijder daarna nieuwe beleidstoewijzingen of herstel de volgorde. Verwijder tijdelijke DNAT-, SNAT- of certificaatwijzigingen alleen als geen andere service ervan afhankelijk is.

Herstel pas daarna de SMTP Deployment Mode als de wijziging deze omschakeling omvatte. De oorspronkelijke inkomende en uitgaande mailflow moet weer werken met de verwachte Rule IDs, openbare adressen en serverlogs. Verwijder berichten, quarantaine-inhoud of proxylogs niet als standaardrollback.

Operationele checklist

• Transparante proxywerking is bewust gekozen en MTA-vereisten zijn uitgesloten.
• Backup, beheerstoegang en oorspronkelijke Rule IDs zijn gedocumenteerd.
• SMTP-groottelimiet, oversize-actie, IP Reputation en DoS-limieten zijn onderbouwd.
• Certificaat, TLS-uitzonderingen en betrokken domeinen zijn gecontroleerd.
• DNAT, SNAT, bestemmingszone en werkelijke serverpoorten komen overeen.
• Inkomende en uitgaande firewallregels zijn nauw, gelogd en aantoonbaar gematcht.
• Standaard- en eigen beleid hebben een traceerbare volgorde.
• Optionele journaling is beperkt tot de vereiste ontvangers en heeft een gedocumenteerd doel voor gegevensbescherming en bewaring.
• Positieve, negatieve, TLS- en bezorgtests zijn geslaagd.
• Legacy-proxylogs en mailserverlogs kunnen in de tijd worden gecorreleerd.
• Eigenaar, controledatum en volledig terugvalpad zijn vastgelegd.

FAQ