Sophos Firewall-e-mailuitzonderingen veilig maken en testen

Een e-mailuitzondering op Sophos Firewall staat niet simpelweg een afzender toe. Ze slaat geselecteerde beveiligingscontroles over voor een gedefinieerd SMTP-pad. Precies daarom kan ze een bevestigde false positive zorgvuldig oplossen, maar ook ongemerkt SPF, malwarescanning, Zero-Day Protection of DKIM-controles uitschakelen.

⚠️ Maak een uitzondering pas nadat een false positive reproduceerbaar is aangetoond. Sla alleen de getroffen controle over. Kies de nauwste betrouwbare voorwaarde, want bronhost, afzender en ontvanger zijn alternatieven en geen gezamenlijke EN-voorwaarde. All checks en brede wildcards zijn geen snelle standaardoplossing.

De uitzondering in zeven stappen maken

1. Leg testtijd, SMTP-bron-IP, envelope-afzender, ontvanger, onderwerp, Message-ID en de exacte afwijzingsreden vast.
2. Controleer of DNS, routing, relay, TLS of het eigenlijke mailbeleid de fout veroorzaakt in plaats van een beveiligingscontrole.
3. Selecteer onder Email > Policies and exceptions > Add an exception uitsluitend de aantoonbaar getroffen controle.
4. Schakel alleen de nauwste geschikte voorwaarde in onder Sources or hosts, Sender addresses of Recipient addresses.
5. Test één gelijksoortig bericht positief en minstens één variant buiten de scope negatief.
6. Vergelijk onder Email > Mail logs resultaat en Reason voor en na de wijziging; test andere bescherming afzonderlijk met onschadelijke gevallen.
7. Documenteer eigenaar, reden en reviewdatum en verwijder de uitzondering nadat de oorzaak is verholpen.

Wat een uitzondering werkelijk overslaat

SFOS groepeert de controles die kunnen worden overgeslagen op basis van hun effect. Onder Spam protection staan RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF en BATV. Malware protection omvat Malware en Zero-day protection. Onder Other staan Data protection, File protection, Encryption, Banner addition, DKIM signing en DKIM verification.

Deze selectie is geen gemakslijst. Een uitzondering voor SPF laat bijvoorbeeld de overige antispam- en malwarecontroles actief. Een uitzondering voor Malware of Zero-day protection verwijdert daarentegen een centrale inhoudscontrole voor alle berichten die binnen de scope vallen. Encryption, DKIM signing en DKIM verification wijzigen bovendien de vertrouwelijkheid en integriteitscontrole van de uitgaande of inkomende mailflow.

Deze uitzondering hoort bij MTA mode. Een SMTP route and scan-policy combineert routing met acties voor spam, malware, bestanden en gegevens. In legacy mode werkt SFOS als transparante proxy met afzonderlijke SMTP malware scan- en SMTP spam scan-policies; het MTA-uitzonderingsobject is daar niet de juiste instelling. Zie Sophos Firewall Mail Protection in MTA-modus instellen en Mail Protection in legacy-modus configureren.

Encryption betekent hier e-mailversleuteling uit de MTA-policy, zoals SPX-e-mailversleuteling, niet SMTP-transportversleuteling. Require TLS negotiation, certificaatvalidatie en Skip TLS negotiation staan afzonderlijk onder Email > General settings > SMTP TLS configuration. Een e-mailuitzondering verhelpt dus geen TLS-handshake, routing, relay of firewallregels.

Begrijp de matching voordat u opslaat

De drie scopegroepen vormen geen EN-voorwaarde. De officiële SFOS 22.0-API noemt ze ForTheseSourceHost, ORTheseSenderAddresses en ORTheseRecipientAddresses. Bij meerdere actieve groepen volstaat een match op bronhost of afzender of ontvanger. Een bron-IP, partnerdomein en pilotmailbox creëren dus drie matchroutes, geen nauwere combinatie.

Dit object kan geen EN tussen de groepen afdwingen; twee uitzonderingen zouden de scope ook verbreden. Als twee criteria tegelijk vereist zijn, corrigeer dan de oorzaak of scheid de mailflow met een passende policy of gatewayroute.

Sources or hosts

SFOS accepteert IP-adressen, IP-bereiken, IP-lijsten, netwerken of FQDN’s als bron. Wildcard-FQDN’s worden niet ondersteund voor e-mailhostuitzonderingen. *.example.net is daarom geen geldige vervanging voor het waargenomen SMTP-bronadres. Voor localhost is geen uitzondering nodig, omdat SFOS lokale e-mails standaard niet scant.

Bij cloudmaildiensten of verspreide gateways kan één IP te beperkt zijn, terwijl een volledig providernetwerk veel te breed kan zijn. Gebruik uitsluitend een gepubliceerd bronobject dat daadwerkelijk in de eigen mailflow is waargenomen. Als andere tenants dezelfde provider-IP’s delen, kan zelfs dat object te breed zijn. Sla een beveiligingscontrole niet uitsluitend vanwege dat netwerk over.

Afzender en ontvanger

Voor Sender addresses en Recipient addresses is een adres zoals sender@example.net of een wildcard zoals *@example.net toegestaan. Een tweede groep is geen nauwere verankering, omdat deze met OF is verbonden. Een afzender is geen onafhankelijk vertrouwensbewijs wanneer SPF of DKIM wordt uitgezonderd; een ontvangeruitzondering geldt voor passende berichten van alle afzenders.

BATV heeft een ongebruikelijke speciale regel: om de BATV-controle voor e-mails van een afzender over te slaan, moet diens adres zowel onder Sender addresses als onder Recipient addresses worden ingevoerd. Ontbreekt een van beide velden, dan is de uitzondering voor deze BATV-situatie niet volledig.

Een nauw begrensde uitzondering maken

Het voorbeeld betreft een bevestigde SPF-false-positive van een dedicated partnergateway. 203.0.113.25 is een documentatieadres en wordt vervangen door het openbare IP uit Mail logs. Het voorbeeld is alleen geschikt als dit IP uitsluitend bij de vertrouwde gateway hoort; voor een gedeeld cloudrelay is de bypass te breed.

1. Open Email > Policies and exceptions > Add an exception.
2. Voer een traceerbare naam in, zoals FP-SPF-partner-example-review-2026-09-30.
3. Selecteer bij de over te slaan controles uitsluitend SPF.
4. Voer onder Sources or hosts de host 203.0.113.25 in.
5. Laat Sender addresses en Recipient addresses uitgeschakeld of leeg; ze voegen OF-matches toe.
6. Sla op zonder meer hosts of controles toe te voegen.

De naam bevat bewust de oorzaak en reviewdatum. Hij vervangt echter geen documentatie in de wijziging of het ticket. De naam dwingt technisch geen vervaldatum af; de eigenaar moet de review daadwerkelijk uitvoeren.

Positieve en negatieve tests uitvoeren

De partner verzendt hetzelfde gecontroleerde bericht opnieuw; het mag niet meer mislukken om de bevestigde SPF-Reason. Filter onder Email > Mail logs op tijd, afzender, ontvanger of onderwerp en op Result en Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification en BATV hebben eigen Reason-filters. Gebruik voor verdieping smtpd_main.log en bij afwijzingen smtpd_reject.log; Sophos Firewall-services en -logs licht ze toe.

Voer daarna een negatieve test uit via een gecontroleerd SMTP-pad dat niet is uitgezonderd. Die mag de gedocumenteerde controle niet door deze uitzondering omzeilen. Bij een bronhostuitzondering zijn andere afzenders of ontvangers via hetzelfde IP geen negatieve tests: ze matchen dezelfde OF-tak. Een onschadelijk bestand kan Malware en File Protection afzonderlijk testen; gebruik geen echte malware.

Een succesvolle aflevering bewijst de scope niet. De officiële Mail logs-documentatie beschrijft Reasons en afleverstatus, maar geen veld “matched exception” en geen lijst met overgeslagen controles. Beoordeel daarom Reason voor/na, configuratie en afzonderlijke positieve en negatieve gevallen samen. Presenteer aflevering niet als bewijs dat alle andere beveiligingsfuncties zijn uitgevoerd.

Risicovolle uitzonderingen herkennen

Eén brede domeinwildcard of een groot bronnetwerk kan de beveiliging voor een aanzienlijk deel van de mailflow verwijderen. Beide invoeren maakt de scope niet nauwer, maar voegt OF-matches toe. Vooral uitzonderingen voor Malware, Zero-Day Protection, Data protection en File protection vereisen een gedocumenteerde risicoafweging en een zeer kleine, zelfstandig betrouwbare scope. Bij een nog onbekende scanfout wordt niet uit voorzorg de hele groep uitgeschakeld.

Ook de ogenschijnlijk functionele opties zijn beveiligingsrelevant. Het overslaan van Encryption kan vertrouwelijke inhoud onbeveiligd verzenden. Zonder DKIM signing ontbreekt de geplande uitgaande handtekening; zonder DKIM verification wordt een inkomend identiteitsbewijs niet beoordeeld. Een Banner-uitzondering kan verplichte teksten of markeringen verwijderen. Stem zulke wijzigingen af met de verantwoordelijken voor mail en compliance.

Fouten per symptoom afbakenen

Het bericht wordt nog steeds afgewezen

Beoordeel eerst het nieuwe logitem in plaats van het oude testbericht. Het werkelijke bron-IP, de envelope-afzender, de ontvanger en de Reason moeten overeenkomen met de scope en de gekozen controle. Een wildcard-FQDN onder Sources or hosts werkt niet. Wanneer het bericht wordt afgewezen vanwege RBL, IP reputation, RDNS/HELO of een andere controle, lost een uitsluitend op SPF gerichte uitzondering die afzonderlijke reden niet op.

De uitzondering geldt voor te veel berichten

Vergelijk de drie scopegroepen afzonderlijk met de mailflow. Elke actieve OF-groep vergroot de set matches. Beperk de uitzondering tot één betrouwbare groep met zo weinig mogelijk waarden en herhaal de negatieve test.

De e-mail doorstaat de controle, maar wordt niet afgeleverd

Een uitzondering bestuurt beveiligingscontroles, niet MX, de interne route, SMTP-TLS, relay of de doelmailserver. Mail logs en de spool tonen of het bericht na de scan nog mislukt door DNS, routing, policy of aflevering. Controleer bij een TLS-fout het certificaat, Require TLS negotiation en de peer; Encryption in de uitzondering en een bredere scope lossen dit niet op.

De BATV-uitzondering wordt niet toegepast

Controleer of hetzelfde afzenderadres onder Sender addresses en Recipient addresses staat. Vergelijk daarna opnieuw de specifieke BATV-Reason en de overige scopevelden. Een tweede, bredere uitzondering is geen vervanging voor het ontbrekende BATV-veld.

Beheer en rollback

Elke uitzondering krijgt een eigenaar, een bewezen false-positive-reden en een reviewdatum. Vergelijk wijzigingen met de audit trail; Configuratiewijzigingen op Sophos Firewall volgen beschrijft het passende bewijs. De werkelijke mailflow blijft daarnaast zichtbaar in Mail logs en de MTA-bestanden.

Leg vooraf naam, controles, scopewaarden en eerdere Reason vast. Verwijder voor een toestandbehoudende rollback alleen de nieuwe uitzondering en laat policies en andere uitzonderingen intact. Test daarna de oorspronkelijke fout en een controlebericht; plan bij een onopgeloste oorzaak eerst een onderhoudsvenster of nauwere correctie.

E-mailuitzonderingen via de XML API duiden

Bij automatisering heet het MTA-uitzonderingsobject ExceptionPolicy. Leg vóór een wijziging de bestaande naam, de overgeslagen controles en alle scopewaarden vast. Toegang, expliciete schrijfbewerkingen, de interpretatie van XML-antwoorden en veilige herhaalpogingen worden uitgelegd in Toegang tot de Sophos Firewall XML API beveiligen. De onderstaande toelichting beschrijft het gedocumenteerde contract voor SFOS 22/23, niet een getest schrijfverzoek.

Skip-schakelaars en matchlijsten afzonderlijk behandelen

De controlevelden binnen MalwareProtection, SpamProtection en Other bepalen wat wordt overgeslagen; ze schakelen niet de algemene e-mailbeveiliging in. Zo is Malware in het uitzonderingsobject een skip-selectie, geen activering van de malwarescanner. De referentie vermeldt voor de meeste van deze velden Enable/Disable. Los daarvan activeren de eveneens scalaire schakelaars ForTheseSourceHost, ORTheseSenderAddresses en ORTheseRecipientAddresses welke scopegroepen worden gebruikt. Hun waarden zijn eveneens Enable/Disable, geen IP- of adreslijsten.

De bijbehorende waarden staan in het gedocumenteerde objectvoorbeeld afzonderlijk en genest:

• SourceHostList/SourceHost: meerdere stringwaarden voor bronhosts; de parametertekst noemt IP/FQDN.
• SenderAddressesList/Address: meerdere afzenderadressen, met ondersteuning voor e-mailwildcards.
• RecipientAddresses/Address: meerdere ontvangeradressen, eveneens met ondersteuning voor e-mailwildcards.

De twee Address-velden hebben dezelfde naam, maar zijn niet uitwisselbaar: pas de bovenliggende container bepaalt of het om afzenders of ontvangers gaat. Een gevulde container vervangt niet de controle van de bijbehorende scopeschakelaar. Extra lijstitems vormen geen aanvullende EN-voorwaarde; elke extra geactiveerde groep creëert het hierboven beschreven OF-matchpad. Met name zou een extra ontvangerslijst de bronhost-bypass ook openstellen voor berichten van andere bronnen. Vergelijk schakelaars en opgeslagen lijsten daarom altijd samen met de goedgekeurde scope. De speciale BATV-regel en de beperking voor wildcard-FQDN’s blijven gelden.

Volgens de referentie is Name verplicht en maximaal 100 tekens lang. Optionele velden en lege standaardwaardekolommen bewijzen daarentegen niet dat weggelaten waarden bij een update behouden blijven of op Disable worden gezet. Kopieer geen productie-uitzondering uit het uitgebreide voorbeeld van de fabrikant: het activeert meerdere skip-velden en alle drie de scopegroepen tegelijk.

Controleer vóór een schrijfverzoek de lokale API help: Het voorbeeld toont CheckForSPF met Disable, terwijl de parametertabel CheckforSPF vermeldt met de onopgeloste waarden $EMAILPROTECTION{SMTP_CHECK_SPF_ENABLE} en $EMAILPROTECTION{SMTP_CHECK_SPF_DISABLE}. RBL en RDNSAndHelo staan in de tabel, maar ontbreken in het objectvoorbeeld; de bannerselectie is daar geschreven als BanerAddition. Corrigeer deze schrijfwijzen niet op eigen initiatief, raad geen tokenwaarden en leid uit ontbrekende velden geen XML-plaatsing af. Als de exacte tags, toegestane waarden of de concrete bewerking voor de geïnstalleerde build onduidelijk blijven, stop dan de schrijfbewerking en stem dit af met Support; daarom bevat dit onderdeel geen uitvoerbaar XML-schrijfsjabloon.

Antwoorden onderscheiden en de opgeslagen toestand controleren

De toewijzing in de referentie moet samen met de bewerking worden gelezen. De waarden zijn XML-statuscodes, geen HTTP-statuscodes; Message.* zijn onopgeloste documentatiesymbolen, geen aangetoonde runtimeteksten of foutoorzaken die uitsluitend uit de naam kunnen worden afgeleid.

Add en Update verwijzen hier naar respectievelijk Exception Policy Add en Exception Policy Update. Hoewel de pagina ook Exception Policy Delete in de titel noemt, bevat de statustabel geen Delete-toewijzing. Pas een succescode voor Add/Update niet toe op Delete en verzin geen concrete validatieregel op basis van een symboolnaam.

Open na elke schrijfpoging, ook bij 200, de uitzondering opnieuw onder Email > Policies and exceptions en vergelijk de daadwerkelijk opgeslagen naam, alle skip-selecties, alle drie de scopeschakelaars en elke host-/adreslijst met de gewenste toestand. Controleer bij het verwijderen of precies het bedoelde object ontbreekt en of de toestand van andere uitzonderingen ongewijzigd is. Bewaar de Audit Trail en het volledige, opgeschoonde API-antwoord. Pas daarna bevestigen de hierboven beschreven positieve en negatieve tests het effect op de mailflow.

Lees bij 502, een fout, een time-out of een onduidelijk antwoord vóór elke herhaalpoging de daadwerkelijke toestand uit: een bestaande naam kan al naar een andere uitzondering verwijzen of afkomstig zijn van de eerste poging. Dupliceer niet met een nieuwe naam, voeg geen extra OF-groepen toe en sla geen verdere controles over alleen om de fout te omzeilen. Controleer voor 541–545 de bewerking, de code, de daadwerkelijke antwoordtekst en de opgeslagen configuratie samen; een onopgeloste symboolnaam rechtvaardigt geen gegokt herstelverzoek.

Checklist

• Er is een reproduceerbare false positive met de exacte Reason.
• Bron-IP, envelope-afzender, ontvanger en Message-ID zijn gedocumenteerd.
• Alleen de getroffen controle wordt overgeslagen.
• Geef de voorkeur aan één geschikte scopegroep; extra groepen verbreden de match via OF.
• Wildcard-FQDN’s worden niet als hostuitzondering gebruikt.
• Een BATV-uitzondering bevat het afzenderadres in beide adresvelden.
• Positieve en negatieve tests plus Reasons voor en na bevestigen het beoogde effect.
• De overige spam-, malware-, bestands-, gegevens- en DKIM-controles blijven actief.
• Eigenaar, reden, reviewdatum en rollback zijn gedocumenteerd.

FAQ