E-mailmeldingen van Sophos Firewall instellen en testen

Voor werkende e-mailmeldingen heeft Sophos Firewall twee afzonderlijke configuraties nodig: onder Administration > Notification settings wordt het mailtransport ingesteld. Onder System services > Notification list wordt bepaald welke gebeurtenissen daadwerkelijk per e-mail worden gemeld.

De quarantainedigest voor gebruikers gebruikt dit mailtransport ook, maar planning, portaallink en gebruikerstoewijzing zijn afzonderlijke instellingen.

De zichtbare authenticatie-, SMTP-, beheerders- en sms-teksten onder Administration > Messages vormen een derde, afzonderlijke laag. Login-disclaimer en berichten op Sophos Firewall configureren legt de inhoud en tests ervan uit; het wijzigen van een bericht configureert noch SMTP-transport noch gebeurtenisselectie.

De snelle aanpak:

Configureer de mailserver, poort, authenticatie, versleuteling, afzender en ontvanger onder Administration > Notification settings.
Verstuur een testmail en bevestig de aflevering in de doelmailbox of via de tracking van de mailserver.
Activeer onder System services > Notification list de globale schakelaar Email notifications.
Selecteer alleen gebeurtenissen waarop een verantwoordelijke ontvanger kan reageren.
Activeer naast de testmail gecontroleerd een echte geselecteerde gebeurtenis en controleer de aflevering.

Een geslaagde testmail bewijst alleen dat het SMTP-pad in principe werkt. Hiermee is nog niet bewezen dat de globale e-mailschakelaar en de juiste gebeurtenissen zijn geactiveerd. Omgekeerd verstuurt een geselecteerde gebeurtenisregel geen bericht zolang het mailtransport niet werkt. Juist dit onderscheid verklaart waarom alleen een geconfigureerde SMTP-server het onderdeel Notification Emails in de Sophos Firewall Health Check operationeel nog niet afdekt.

Als WebAdmin niet beschikbaar is of het ontvangeradres via gecontroleerde CLI-toegang moet worden gecorrigeerd, opent u in het Main Menu van de CLI 2. System Configuration > 3. Set Email ID for system notification. System Configuration is optie 2 van het Main Menu, geen submenu van de Device Console (optie 4). Als u zich al in optie 4 bevindt, keert u eerst terug naar het Main Menu en kiest u daar optie 2. Deze optie wijzigt alleen het e-mailadres van de beheerder voor systeemmeldingen. Ze configureert noch mailserver, afzender, authenticatie en TLS, noch de globale schakelaar en gebeurtenissen in de Notification list.

Documenteer eerst het vorige adres. Bevestig daarna de wijziging met y, voer het nieuwe adres in en controleer het door SFOS getoonde adres op typefouten. Druk op Enter om terug te keren naar het menu. Vervolgens moeten een testmail en een gecontroleerde echte gebeurtenis de nieuwe ontvanger bereiken; alleen de consolebevestiging bewijst geen aflevering.

Mailverzending voorbereiden

Vóór de configuratie worden de mailserver, poort en authenticatiemethode afgestemd met de verantwoordelijke mailbeheerder. Als een FQDN zoals smtp.example.net wordt gebruikt, moet de firewall deze kunnen omzetten en de server via het bedoelde routeringspad kunnen bereiken. Een algemene internetverbinding is alleen nodig als de gekozen mailserver of OAuth-provider op internet staat. Een interne SMTP-relay kan ook werken zonder directe internettoegang van de firewall.

Leg vóór een wijziging de geselecteerde mailserveroptie, mailserver, poort, Authentication, Connection security, afzender, ontvanger, beheerinterface en geselecteerde gebeurtenissen vast. Als de wijziging betrekking heeft op certificaten, noteert u ook de huidige selectie onder Administration > Notification settings of Email > General settings, afhankelijk van de situatie. Controleer of de benodigde aanmeldgegevens en OAuth-tokens veilig beschikbaar zijn in een wachtwoord- of secretsmanager; zet ze niet in onbeveiligde schermafbeeldingen. Met deze gegevens kunt u de vorige configuratie herstellen als de nieuwe mailroute de afleveringstest niet doorstaat.

Een realistisch voorbeeld:

Mailserver: smtp.example.net
Port: 587
Authentication: Basic
Connection security: STARTTLS
Sender: fw-zrh-01@example.net
Recipient: firewall-alerts@example.net
Management interface IP address: interne beheerinterface van de firewall

Alle waarden met example.net worden vervangen door het eigen domein en de adressen die de mailbeheerder heeft toegestaan. Een distributieadres is meestal beter dan een persoonlijke mailbox: verantwoordelijkheden kunnen veranderen zonder dat elke firewall opnieuw moet worden geconfigureerd.

De Management interface IP address bepaalt niet via welke interface de SMTP-verbinding de firewall verlaat. Het geselecteerde IP-adres wordt in de melding opgenomen en helpt om de verzendende firewall te identificeren. Bij meerdere locaties moet daarom een blijvend herkenbaar beheer-IP worden gekozen; bij slechts één firewall kan ook None voldoende zijn.

Fysieke interfaces, bridge-interfaces en LAG-interfaces verschijnen alleen in de keuzelijst als er een IP-adres aan is toegewezen. Ontbreekt een interface, dan verklaart deze voorwaarde waarom; wijs geen IP-adressen toe en wijzig geen interfaces of routing alleen om identificatie aan een bericht toe te voegen.

Mailserver configureren

Built-in of External email server kiezen

Sophos Firewall kan de Built-in email server of een External email server gebruiken. De ingebouwde verzending is praktisch voor een eenvoudige start. In productieomgevingen is een eigen relay- of cloudmailserver vaak beter te volgen, omdat authenticatie, mailtracking, afzenderrechten en afleverfouten centraal zichtbaar zijn.

Daarom adviseren we de External email server wanneer er al een betrouwbaar beheerde SMTP-service beschikbaar is.

Voor de ingebouwde verzending volstaat deze korte route:

Activeer onder Administration > Notification settings de Built-in email server.
Voer de afzender, ontvanger en optioneel Management interface IP address in.
Sla de configuratie op en verstuur de testmail.

Bij de Built-in email server is er geen eigen relaytracking waarmee de beheerder acceptatie en doorsturen kan controleren. Controleer daarom de daadwerkelijke aflevering extra zorgvuldig. Als deze herhaaldelijk mislukt of als het ontvangende domein en de beveiligingsrichtlijnen een gecontroleerd SMTP-pad vereisen, is een External email server de beter beheersbare variant.

External email server instellen

Open Administration > Notification settings.
Selecteer External email server.
Voer het IPv4-adres of de FQDN van de mailserver en de opgegeven poort in.
Kies onder Authentication None, Basic of OAuth 2.0, passend bij de server.
Stel onder Connection security de transportversleuteling in die de mailserver vereist.
Voer de afzender, ontvanger en optioneel Management interface IP address in.
Sla de configuratie op en voer de testmailfunctie uit.

De standaardpoort in SFOS is 25, maar dat is niet voor elke omgeving een aanbeveling. De listener van de eigen relay is bepalend. Gebruikelijk zijn 25 voor een interne relay die op basis van het bron-IP is toegestaan, 587 voor geauthenticeerde verzending met STARTTLS of 465 voor directe SSL/TLS. Poort, authenticatie en versleutelingsmodus moeten als combinatie bij de mailserver passen.

None betekent in de twee keuzelijsten niet hetzelfde: onder Authentication schakelt dit de aanmelding bij de mailserver uit. Dat kan correct zijn voor een interne relay die uitsluitend het bron-IP van de firewall toestaat. Onder Connection security betekent None daarentegen onversleutelde SMTP-overdracht. Deze instelling is ongeschikt voor internetpaden en mag ook intern alleen worden gebruikt als het beveiligingsmodel dit uitdrukkelijk toestaat.

Bij Basic gebruikt de firewall een gebruikersnaam en wachtwoord. De gebruikersnaam is hoofdlettergevoelig. De relay moet de gebruikte aanmeldingsmethode ondersteunen; een foutmelding over de Authentication method wijst met name op een verschil bij LOGIN of PLAIN.

STARTTLS wordt gemakkelijk verkeerd begrepen: de firewall volgt de mogelijkheden van de mailserver. Als de server STARTTLS aanbiedt, wordt de verbinding versleuteld; als de server dit niet aanbiedt, kan het bericht onversleuteld worden overgedragen. Wie versleuteling moet afdwingen, gebruikt SSL/TLS met de bijpassende poort en serverlistener.

⚠️ Allow invalid certificate onder Email > General settings mag niet als snelle workaround worden geactiveerd. Een verlopen of niet-vertrouwd certificaat, of een certificaat dat niet bij de servernaam past, wordt beter op de mailserver of in de vertrouwensketen gecorrigeerd.

Welk certificaat SFOS gebruikt, hangt ook af van de e-mailmodus. Bij STARTTLS in MTA Mode gebruikt de firewall het certificaat onder Email > General settings. In Legacy Mode kan voor STARTTLS rechtstreeks onder Administration > Notification settings een certificaat worden geselecteerd; zonder selectie gebruikt SFOS eveneens het certificaat onder Email > General settings. Bij SSL/TLS gebruikt het systeem het certificaat onder Email > General settings. Wijzig een certificaat daarom niet afzonderlijk zonder rekening te houden met de productieve mailflow.

Gmail en Microsoft 365 met OAuth 2.0

Voor Gmail en Microsoft 365 moet in SFOS 22 en 23 OAuth 2.0 worden geselecteerd. Hiervoor worden in Notification settings Provider, Client ID, Client secret en Refresh token ingevoerd. Het veld Client secret is voor Microsoft 365 optioneel; de hier beschreven Microsoft 365-procedure maakt en gebruikt echter uitdrukkelijk een secret. Daarom wordt het voor deze procedure meegeconfigureerd.

Voor Gmail moeten in Google Cloud een project en de Gmail API worden ingesteld en moeten een OAuth-client en Refresh Token worden aangemaakt. De volgende procedure beschrijft deze stappen. Google en Microsoft wijzigen hun portalen en vereisten onafhankelijk van SFOS; controleer daarom vóór een productieconfiguratie de actuele vereisten van de provider en de machtigingen van het beoogde verzendaccount.

Gmail OAuth 2.0 stap voor stap configureren

Controleer vóór het aanmaken van de Refresh Token het beoogde verzendaccount, de OAuth-client, de Redirect URI en de hieronder beschreven Gmail-scope met uitgebreide rechten. Voor de volgende procedure met User type: External moet ook toestemming voor het productiegebruik van de OAuth-app zijn geregeld. Publish App vervangt noch de vereiste verificatie door de provider, noch de toestemming van de verantwoordelijke Google Workspace- of beveiligingsbeheerder. Als publicatie volgens de actuele Google-vereisten of uw eigen beleid niet is toegestaan, omzeil deze beveiligingsmaatregelen dan niet: gebruik in plaats daarvan een goedgekeurde SMTP-relay voor een blijvend alarmpad.

Meld u aan bij Google Cloud Console met het beoogde Google-account, maak een nieuw project aan en selecteer het.
Open APIs & Services > Library, zoek naar Gmail API en schakel de API in.
Klik onder APIs & Services > Credentials op Create credentials > OAuth client ID.
Als eerst het toestemmingsscherm wordt gevraagd, open dan Configure the OAuth consent screen > Get started. Vul de appnaam en het e-mailadres in, selecteer User type: External, voeg het contactadres van de ontwikkelaar toe en maak de configuratie aan.
Selecteer Create OAuth client, stel Application type: Web application in en geef een unieke naam op.
Voeg onder Authorized redirect URIs exact https://developers.google.com/oauthplayground toe.
Maak de OAuth-client aan en leg de Client ID en Client secret onmiddellijk veilig vast.
Controleer onder Audience het beoogde verzendaccount en de huidige publicatiestatus. Zolang de app op Testing staat, voegt u het account onder Add users toe als testgebruiker. Deze lijst met testgebruikers is geen toegangsbeperking voor een externe app nadat deze is gepubliceerd.
Voer na de vereiste toestemming Publish App uit en controleer of Publishing status van Testing naar In production is veranderd. Een externe app kan dan in principe ook worden geautoriseerd door Google-accounts buiten de lijst met testgebruikers; het geldende account- en organisatiebeleid blijft van toepassing. Maak pas daarna de Refresh Token aan. Een token dat vóór publicatie is aangemaakt, verloopt in deze Gmail-procedure na zeven dagen; maak voor blijvend gebruik daarom na publicatie een nieuwe Refresh Token aan in plaats van de vorige te blijven gebruiken.
Open Google OAuth 2.0 Playground. Schakel via het tandwielpictogram Use your own OAuth credentials in en voer de Client ID en Client secret in.
Klap onder Step 1 Select & authorize APIs Gmail API v1 uit, selecteer de scope https://mail.google.com en start Authorize APIs. Gebruik het beoogde verzendaccount en vergelijk vóór het verlenen van toestemming de weergegeven app en de bijbehorende machtigingen met de goedgekeurde configuratie. Breek bij afwijkingen af en controleer de configuratie.
Wissel onder Step 2 Exchange authorization code for tokens de code om voor tokens en kopieer de Refresh token veilig. Client secret, Authorization Code, Access token en Refresh token horen niet thuis in tickets, onbeveiligde schermafbeeldingen of logs.
Configureer op de firewall onder Administration > Notification settings de External email server met Authentication: OAuth 2.0 en Provider: Gmail. Voer de Client ID, Client secret en Refresh token in, sla op en verstuur een testmail. Bevestig de daadwerkelijke aflevering in de doelmailbox of via de tracking van de mailserver; alleen opgeslagen OAuth-velden bewijzen niet dat het mailpad werkt.

Google beschouwt een OAuth-project met User type External en Publishing status Testing niet als een permanente productieconfiguratie: bij gebruik van de Gmail-scope verloopt de Refresh Token volgens Google OAuth 2.0 na zeven dagen. De hier gebruikte Gmail-scope https://mail.google.com staat naast verzenden ook het lezen, aanmaken en permanent verwijderen van e-mails toe. Daarom moeten de OAuth-app, toegangsgegevens en een bij voorkeur speciaal verzendaccount net zo worden beschermd en beheerd als een mailserverwachtwoord.

Bij Microsoft 365 heeft de app de gedelegeerde machtigingen SMTP.Send en offline_access nodig; voor het verzendende account moet Authenticated SMTP zijn geactiveerd. De gedocumenteerde standaardmethode gebruikt smtp.office365.com, poort 587 en STARTTLS. Als het afzenderadres afwijkt van de aangemelde mailbox, heeft het account bovendien Send As nodig. De volledige Entra-procedure volgt direct hieronder.

Microsoft 365 OAuth 2.0 stap voor stap configureren

Maak in Microsoft Entra admin center onder Identity > Applications > App registrations een New registration aan.
Geef een unieke naam op. Selecteer voor deze procedure Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant). Selecteer onder Redirect URI het platform Web en voer https://outlook.office365.com/ als URI in. Als alternatief kan http://localhost/ worden gebruikt. De geregistreerde URI moet in de autorisatieaanvraag en bij het uitwisselen van de code voor tokens exact opnieuw worden gebruikt; pas bij gebruik van localhost de redirect_uri in beide volgende voorbeelden aan naar http://localhost/.
Registreer de app en leg de Application (client) ID veilig vast.
Configureer onder API permissions > Add a permission de gedelegeerde SMTP-machtiging voor de Outlook-/Exchange-resource en verleen de vereiste toestemming. Microsoft documenteert hiervoor de scope https://outlook.office.com/SMTP.Send; daarnaast wordt offline_access aangevraagd voor het Refresh Token. De SMTP-machtiging is bepalend, niet een Graph-machtiging zoals Mail.Send. Controleer de resourceselectie en de weergegeven machtigingen aan de hand van de Microsoft-handleiding voor SMTP met OAuth voordat u het token aanmaakt. Ga niet verder met een schijnbaar vergelijkbare machtiging als de juiste ontbreekt.
Controleer in Microsoft 365 admin center voor het verzendaccount onder Users > Active users > Mail > Email apps > Manage email apps de optie Authenticated SMTP. Schakel deze in en sla op als de beveiligingsrichtlijnen dit toestaan. Deze mailboxschakelaar staat los van de appregistratie in Entra admin center.
Maak onder Certificates & secrets > Client secrets > New client secret een secret met een bewaakte vervaldatum aan. Kopieer de weergegeven Value onmiddellijk veilig; na het herladen van de pagina toont Entra deze niet meer.
Open de volgende URL in een browser. Vervang YOUR_CLIENT_ID door de Application ID en YOUR_RANDOM_STATE door een willekeurige waarde die uitsluitend voor deze handeling is gegenereerd; de redirect_uri moet overeenkomen met de appregistratie. Pas de juiste URL-codering toe op de parameterwaarden. De state-waarde moet ongewijzigd in het antwoord terugkomen; een vaste voorbeeldwaarde beschermt deze handeling niet. De Microsoft-handleiding voor de Authorization Code Flow licht de state-controle en PKCE voor geschikte clients toe.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=YOUR_RANDOM_STATE

Meld u aan met het beoogde verzendaccount, vergelijk de teruggegeven state-waarde met de opgeslagen waarde en neem de kortlevende autorisatiecode uit de omgeleide URL pas over als de waarden overeenkomen. Breek bij een afwijking af en begin opnieuw.
Verstuur de code met een API-client als application/x-www-form-urlencoded naar het tokenendpoint. Vervang alle placeholders door de waarden van deze app. Het volgende blok toont de velden voor de leesbaarheid op meerdere regels; voer ze in de API-client als afzonderlijke formuliervelden in, zodat spaties en speciale tekens in de code, het secret en de Redirect URI correct worden gecodeerd. Dit is geen shellopdracht die ongewijzigd kan worden gekopieerd.

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET

Sla de ontvangen Refresh token onmiddellijk veilig op. De autorisatiecode, Client secret, Access token en Refresh token horen niet thuis in tickets, onbeveiligde schermafbeeldingen of logs.
Configureer op de firewall onder Administration > Notification settings de External email server met Authentication: OAuth 2.0 en Provider: Microsoft 365. Voer smtp.office365.com, poort 587, STARTTLS, Client ID, Client secret en Refresh token in, sla op en verstuur een testmail.

Voor deze procedure voor het genereren van tokens moeten het systeem waarop de API-client draait en de firewall dezelfde tijdzone gebruiken. Controleer vooraf de systeemtijd en tijdzone. Wijzig de tijdzone van de firewall niet spontaan in productie; de daarna vereiste herstart hoort in een onderhoudsvenster thuis.

Microsoft Security Defaults schakelen SMTP AUTH uit. Deze beveiligingsinstelling mag niet algemeen voor de hele tenant worden uitgeschakeld om alleen een firewall berichten te laten verzenden. Als de gerichte toestemming voor het verzendaccount niet in het beveiligingsmodel past, is een daarvoor bedoelde interne of externe relay de betere oplossing.

⚠️ De bekende fout NC-166854 betreft Microsoft 365 OAuth voor Notifications op SFOS-builds 22.0.0.274, 22.0.0.323, 21.0.2.349 en 21.5.1.261. Daaruit kan niet worden afgeleid dat elke andere build werkt, noch dat er inmiddels geen correctie beschikbaar is. Controleer vóór ingebruikname de exacte SFOS-build en de fout-/fixstatus die voor die build geldt, en eis een geslaagde testmail. Opgeslagen velden voor Client ID, Secret en Token bewijzen nog niet dat het werkt.

Als een vermelde build is getroffen, wordt een ondersteunde SMTP-relay of een ander geverifieerd mailpad gebruikt totdat een gecorrigeerde firmwareversie betrouwbaar is bevestigd. Onveilige TLS-uitzonderingen of niet-gecontroleerde Basic Authentication zijn geen goede vervanging voor een werkend alarmpad.

Gebeurtenissen in de Notification list selecteren

Na een geslaagde mailtest wordt System services > Notification list geopend. Activeer daar eerst Email notifications, selecteer vervolgens de selectievakjes in de kolom Email voor de benodigde gebeurtenissen en sla op met Save.

E-mail en SNMP zijn afzonderlijke uitvoerkanalen. Voor traps moeten onder Administration > SNMP ook de SNMP-agent en de passende communities of gebruikers zijn geconfigureerd. Activeer daarna in de Notification list de globale schakelaar SNMP traps en de beschikbare gebeurtenisselectievakjes voor SNMP en sla op. Een e-mailselectie activeert geen traps; per gebeurtenis kan e-mail, SNMP of beide beschikbare kanalen worden gekozen. Het hieronder gelinkte SNMP-artikel legt uit hoe de SNMP-manager wordt ingesteld en gecontroleerd.

Niet elke firewall heeft dezelfde selectie nodig. Een zinvolle basis is afgestemd op de risico’s en de werkelijk gebruikte functies:

Admin: mislukte aanmeldingen en te veel mislukte aanmeldpogingen.
HA: losgekoppelde bewaakte poorten of interfaces wanneer een HA-cluster wordt gebruikt.
Disk/Memory: opslagwaarschuwingen, zodat een vol rapportage- of systeemgedeelte niet pas tijdens het onderhoudsvenster wordt opgemerkt. Opslag en rapporten op Sophos Firewall controleren legt de drempelwaarden en gevolgen uit.
Firmware: nieuwe firmware die klaarstaat voor installatie, succesvol geïnstalleerde firmware en mislukte installaties, passend bij het eigen updateproces.
Alleen SFOS 23 – Firmware > Security updates: Schakel onder System services > Notification list de kolom Email in voor Security updates. De globale schakelaar Email notifications en een werkend SMTP-pad blijven vereist. Voor hotfix-beveiligingsupdates zijn geen SNMP-meldingen beschikbaar; deze beperking geldt niet zonder meer voor alle hotfixes of firmwaregebeurtenissen. Onmiddellijke bezorging is niet gegarandeerd en ontbrekende e-mail bewijst noch succes noch mislukking. Controleer toegepaste updates met de procedure voor hotfixverificatie in SFOS 23.
System: mislukte updates van de WebCat-database, IPS-signatures en antivirusdefinities, systeemstart of herstart, hoge CPU-belasting en Gateway status.
IPS: de niveaus Critical, Major, Moderate, Minor en Warning kunnen worden geselecteerd. De melding vereist dat de firewall de IPS-gebeurtenis logt en het pakket verwerpt. Kritieke gebeurtenissen met een vastgelegd triageproces zijn een geschikt uitgangspunt.
Active threat response: log- en drop-gebeurtenissen voor MDR, NDR Essentials, Sophos X-Ops en threat feeds van derden worden afzonderlijk geselecteerd. De matchtypen en beperkingen staan in de volgende sectie.
RED: verbinding uitgevallen, firmwareupdate mislukt, apparaat automatisch gedeautoriseerd of nieuwe Unlock Code. AP: access point offline of firmwareupdate mislukt. Selecteer alleen meldingen voor daadwerkelijk gebruikte apparaten en wijs een verantwoordelijke ontvanger aan.
VPN: IPsec-tunnel up, down en failover/failback, en tot stand gebrachte of verbroken SSL-VPN-verbindingen. De hieronder toegelichte IPsec-activeringsvoorwaarden zijn beperkter dan deze algemene lijst; de selectie garandeert geen melding voor elke handmatige tunnelwijziging.
Virus: selecteer meldingen voor HTTP, FTP, SMTP, POP3 en IMAP4 op basis van de daadwerkelijk gebruikte beveiligingsfuncties. Het selectievakje vervangt noch de bijbehorende controle noch de gebeurtenisdetectie daarvan.
Web - Instant alerts: bewust geselecteerde webcategorieën. Deze meldingen worden in vaste, niet-wijzigbare batches van vijf minuten verzonden en vereisen een afzonderlijke categorieactivering, zoals beschreven onder Web Categories en Instant Alerts.

Als alle gebeurtenissen zonder onderscheid worden geactiveerd, ontstaat snel alarmmoeheid. Vooral VPN-meldingen kunnen ongeveer elke 60 seconden worden herhaald totdat de oorzaak is opgelost; bij meerdere lokale en externe netwerken kan bovendien één melding per subnetpaar ontstaan. Een kleine selectie met een duidelijke reactie is beter: wie ontvangt de melding, hoe urgent is deze en wat is de eerste controlestap?

Sommige Default Notifications worden automatisch door de firewall verzonden en kunnen niet worden uitgeschakeld: HA-rolwijzigingen vanuit Standalone, Primary of Auxiliary, HA-apparaatstatus faulty, virtuele hosts up/down en opnieuw opstarten of afsluiten via WebAdmin. Ook voor deze meldingen moet het geconfigureerde mailpad bereikbaar zijn. Dat de gebeurteniscategorie niet kan worden uitgeschakeld, garandeert niet dat een bericht een onbereikbare mailbox bereikt.

Active threat response: match en kanaal onderscheiden

Voor elk van de volgende matchtypen zijn een Log event en een Drop event beschikbaar:

Destination match for all traffic: het doeladres komt overeen met een vermelding in een threat feed.
Remote source match for inbound traffic: het externe bronadres van inkomend verkeer komt overeen.
Local source match for outbound traffic: het lokale bronadres van uitgaand verkeer komt overeen.

Een logmelding alleen bewijst geen blokkering. Omgekeerd hangt een drop-gebeurtenis af van de daadwerkelijke match en de bijbehorende Active threat response-configuratie; het e-mailselectievakje veroorzaakt geen match en maakt geen nieuwe beveiligingsregel aan.

De Sophos-help voor meldingen noemt matching van lokale en externe bronadressen voor Sophos X-Ops als niet ondersteund. Dit is echter in tegenspraak met de SVG-verkeersmatrix, zoals vastgelegd in het NDR-/ATR-artikel, met name bij matching van lokale bronadressen. De e-mailoptie bewijst daarom noch een bepaalde X-Ops-matchwerking, noch dat deze tegenstrijdigheid is opgelost; verduidelijk omstreden gevallen afzonderlijk voordat u er een beveiligingsvoorwaarde van maakt. Remote-source-match-meldingen worden niet doorgestuurd naar de centrale Sophos-service, maar hun logs zijn wel zichtbaar in Central Firewall Reporting (CFR). De naam van de centrale service verschilt per versie (Sophos Central of Sophos Fusion); dit betekent niet dat er meer meldingen worden doorgestuurd. Controleer daarom voor deze gebeurtenissen het lokale e-mail-/logpad en vertrouw niet uitsluitend op de centrale weergave van meldingen.

Activeringsvoorwaarden en herhalingen begrijpen

Een aangevinkt selectievakje betekent niet dat elke korte statuswijziging een e-mail oplevert. In SFOS 22.0 en 23.0 gelden voor de volgende gebeurtenissen deze voorwaarden:

Admin: Sign-in failed omvat onjuiste aanmeldgegevens of een onjuiste OTP (eenmalig wachtwoord). Too many failed sign-in attempts wordt geactiveerd zodra het aantal mislukte pogingen is bereikt dat onder Administration > Admin and user settings > Login security is ingesteld. Deze drempel verklaart de melding; het is geen instructie om een accountblokkering te veroorzaken.
High CPU usage: De eerste meldingslogregel ontstaat pas als de CPU-belasting 95% bereikt en minstens 25 minuten onafgebroken op of boven 95% blijft. Daarna ontstaan elke 25 minuten nieuwe regels totdat de belasting onder 95% daalt. Een korte CPU-piek zonder gebeurtenismail bewijst dus geen SMTP-fout.
Gateway status: De gebeurtenisselectie is standaard ingeschakeld. Voor verzending moet de afzonderlijke globale schakelaar Email notifications toch actief zijn.

Bij schijfgebeurtenissen moet het gebruik minstens 50 seconden onafgebroken op of boven de betreffende drempel blijven. Daarna worden logs en meldingen met de volgende standaardfrequentie herhaald totdat het gebruik onder de drempel daalt:

Gebied	Meldingsdrempel	Herhaling
Configuratieopslag	≥80%	elke 50 seconden
Signatureopslag	≥90%	elke 50 seconden
`/var`	≥80%	elke 12 uur

Bij /var levert de lagere drempel al logs op; meldingen beginnen pas bij de hogere drempel van 80%. Als het gebruik de hogere drempel overschrijdt en daarna onder de lagere daalt, wordt het herstel gelogd, maar wordt geen herstelmelding verzonden. Dit staat los van het waarschuwings- en stopgedrag van rapporten in het hierboven gelinkte opslagartikel; een ontbrekende herstelmail is hier geen afleverfout.

Voor IPsec is het gedocumenteerde bereik beperkter dan een willekeurige VPN-Up/Down-wijziging: meldingen gelden alleen voor host-to-host- en site-to-site-tunnels met de beschreven voorwaarden voor verbroken verbindingen:

Dead peer detection (DPD).
Het opnieuw tot stand brengen van de verbinding na DPD mislukt.
De IPsec Security Association (SA) is verlopen en moet opnieuw tot stand worden gebracht.
Deze lijst omvat ook dat de tunnel na verlies van verbinding zonder ingrijpen van de beheerder weer actief wordt.

Als in de instellingen van de IPsec-verbinding een beschrijving is vastgelegd, bevat de melding die ook. Dit garandeert geen meldingen voor elke handmatige verbreking of voor remote-access- of SSL-VPN-tunnels.

De CPU-tijden beschrijven de aanmaak van meldingslogs en de schijfintervallen de gedocumenteerde herhaling, niet een gegarandeerd aankomsttijdstip in de mailbox. Vergelijk bij ontbrekende mail eerst de gebeurtenisvoorwaarde, het logtijdstip en de mailservertracking. Veroorzaak geen CPU- of schijfverzadiging, aanmeldblokkeringen, HA-onderbrekingen of VPN-storingen in productie alleen om een melding te testen.

Testmail en echte gebeurtenis controleren

De controle bestaat uit twee stappen.

1. SMTP-aflevering met een testmail bevestigen

Controleer eerst de mailconfiguratie die onder Administration > Notification settings is opgeslagen en voer de testmailfunctie uit die in de gebruikte SFOS-build beschikbaar is. Het pad voor de rapporttest is Reports > Show report settings > Report scheduling: selecteer een rapport, open Send test mail, voer het e-mailadres van de testontvanger in en klik op Send. Deze rapporttest controleert het mailtransport, niet de gebeurtenisselectie; de ontvanger ervan is niet automatisch de opgeslagen ontvanger voor systeemmeldingen. De succesmelding van de firewall is nog niet voldoende: in de doelmailbox, spamfilter of mailservertracking moet zichtbaar zijn dat het bericht daadwerkelijk is geaccepteerd en afgeleverd. De rapportinhoud en planning worden afzonderlijk gecontroleerd, zoals beschreven in het hieronder gelinkte rapportartikel.

Controleer daarbij:

Afzender en ontvanger zijn correct.
De verwachte firewall is herkenbaar aan onderwerp, inhoud of beheer-IP.
Het bericht komt niet permanent in spam of quarantaine terecht.
De distributielijst accepteert berichten van de geconfigureerde afzender.

2. De volledige gebeurtenisketen testen

Activeer daarna gecontroleerd een geselecteerde gebeurtenis. Geschikte voorbeelden zijn:

één mislukte aanmelding met een testaccount, nadat aanmeldblokkeringen en drempelwaarden zijn gecontroleerd;
een gedocumenteerde VPN-gebeurtenis op een uitdrukkelijk daarvoor bestemde testtunnel, alleen als het tunneltype en de activeringsvoorwaarde overeenkomen met de geselecteerde melding; alleen een handmatige IPsec-Up/Down-wijziging is geen betrouwbare meldingstest;
Gateway status tijdens een geplande WAN-failovertest.

Een productieve gateway, een HA-poort of de firewall zelf opnieuw starten of loskoppelen alleen voor een e-mailtest zou buitenproportioneel zijn. Een al gepland onderhouds- of failoverscenario is de betere test.

Pas als de gebeurtenis binnen de verwachte tijd bij de juiste ontvanger aankomt, is de volledige keten bevestigd: gebeurtenisdetectie, gebeurtenisselectie, globale e-mailschakelaar, SMTP-transport en aflevering.

Fouten systematisch afbakenen

De testmail mislukt al

De SFOS 22-API onderscheidt meerdere foutklassen:

Failed to connect of SMTP server failed to respond: controleer FQDN-resolutie, route, poort, voorliggende firewall en listener van de mailserver.
Password mismatch: controleer gebruikersnaam, hoofdletters en kleine letters, wachtwoord en eventueel een geblokkeerd account.
Authentication method mismatch: controleer of relay en SFOS bij Basic Authentication beide LOGIN of PLAIN ondersteunen.
STARTTLS not supported: poort en Connection security passen niet bij de serverlistener.
Mail server refused to communicate: controleer relaytoestemming, afzenderadres, toegestaan bron-IP en mailserverlogs.
Couldn’t generate the OAuth 2.0 access token: controleer Provider, Client ID, Secret, Refresh Token, machtigingen en systeemtijd.

Vanaf een beheersysteem met een vergelijkbaar netwerkpad kunnen DNS en STARTTLS vooraf worden gecontroleerd zonder de mailserver te wijzigen:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

Vervang smtp.example.net en 587 door de eigen server en poort. nslookup bevestigt alleen de naamomzetting van het beheersysteem. openssl s_client toont SMTP-bereikbaarheid, TLS-handshake en certificaatketen, maar controleert noch de route vanuit het perspectief van de firewall, noch de aanmelding of latere aflevering.

In Log Viewer en voor een diepere analyse in cschelper.log kan het testmoment worden gecorreleerd met de door het systeem gegenereerde e-mail. De toegang tot servicelogs en het onderscheid met Advanced Shell staan beschreven onder Sophos Firewall-services en -logs. MTA-logs zoals smtpd_main.log horen voornamelijk bij Mail Protection en zijn niet algemeen het Notifications-log.

De testmail komt aan, maar gebeurtenismails ontbreken

Dan werkt het transport en begint het zoeken onder System services > Notification list:

Is Email notifications globaal geactiveerd?
Is de concrete gebeurtenis in de kolom Email geselecteerd?
Heeft de verwachte gebeurtenis werkelijk plaatsgevonden en valt deze in de juiste categorie?
Is er een bekende vertraging of bundeling, bijvoorbeeld bij Web Instant Alerts?
Tonen spamfilter, quarantaine of mailservertracking een acceptatie of weigering?

Bij een afzonderlijke speciale gebeurtenis moet bovendien de inhoudelijke voorwaarde worden gecontroleerd. Een IPS-melding ontstaat bijvoorbeeld niet alleen door een geactiveerd selectievakje, maar pas wanneer een passende IPS-regel de gebeurtenis registreert en het pakket verwerpt. Een VPN-melding hangt af van het tunneltype en de werkelijke Up-/Down-status.

Gmail OAuth valt uit na een wachtwoordwijziging

Bij de hier beschreven Gmail-meldingsprocedure met de scope https://mail.google.com wordt de Refresh Token ongeldig wanneer het wachtwoord van het gebruikte Gmail-verzendaccount wordt gewijzigd. De firewall kan met dit token dan geen nieuwe Access Token meer ophalen. Dit geldt niet voor alle Google OAuth-tokens of voor Microsoft 365.

Controleer of het wachtwoord van precies dit verzendaccount is gewijzigd. Vergelijk de OAuth-client, het account, de goedgekeurde machtigingen en Publishing status: In production met de gedocumenteerde configuratie. Ook een token dat vóór Publish App is aangemaakt, biedt na zeven dagen geen blijvende basis; onderzoek de twee oorzaken afzonderlijk.
Herhaal met de huidige accounttoegang en de inloggegevens van uw eigen OAuth-client de Gmail-autorisatie en tokenuitwisseling volgens de hierboven beschreven Playground-procedure. Controleer de app en de gevraagde machtigingen vóór het verlenen van toestemming en sla de nieuwe Refresh Token veilig op.
Vervang onder Administration > Notification settings bij Provider: Gmail de ongeldige Refresh token door de nieuwe en sla op. Client ID en Client secret moeten bij de gebruikte OAuth-client horen; wijzig SMTP-, TLS-, afzender-, ontvanger- en gebeurtenisinstellingen niet zonder aanleiding.
Verstuur een testmail en bevestig de daadwerkelijke aflevering in de doelmailbox of via de tracking van de mailserver. Controleer daarna een geselecteerde gebeurtenis die gecontroleerd wordt geactiveerd, zoals beschreven in de sectie over de volledige gebeurtenisketen.

Het opnieuw invoeren van het oude token maakt het niet weer geldig. Stel het accountwachtwoord niet opnieuw in alleen om het eerdere mailpad te herstellen. Blijft de verzending na de nieuwe autorisatie mislukken, leg dan de exacte foutmelding, de SFOS-build en de providerconfiguratie zonder secrets of tokens vast voor verdere analyse. Gebruik tot het herstel is bevestigd een goedgekeurd alternatief alarmpad of de gedocumenteerde SMTP-relay.

Microsoft 365 OAuth wordt opgeslagen, maar verzendt niet

Vergelijk eerst de SFOS-versie en -build met NC-166854. Controleer daarna Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP voor het verzendaccount en de juiste systeemtijd.

Als de testmail op een niet als getroffen vermelde build blijft mislukken, is dat niet automatisch dezelfde fout. De exacte melding, de SFOS-build en de aanmeldlogs van de provider horen dan bij de verdere analyse of in een supportticket.

Meldingen beheren

Als de aflevering na een wijziging mislukt, herstelt u eerst de vastgelegde mailconfiguratie: mailserveroptie, server, poort, Authentication, Connection security, afzender, ontvanger en beheerinterface, plus de vorige certificaatselectie als u die hebt gewijzigd. Laat de gebeurtenisselectie ongewijzigd als deze geen deel uitmaakte van de wijziging. Bevestig na het opslaan het eerdere alarmpad opnieuw met een testmail en een gecontroleerd geactiveerde geselecteerde gebeurtenis. Het herstel is pas voltooid wanneer beide berichten daadwerkelijk zijn aangekomen.

Beheer de ontvanger als functionele distributielijst met een verantwoordelijke eigenaar.
Controleer de testmail en een echte gebeurtenis opnieuw na wijzigingen aan mailserver, DNS, routing, certificaat, toegangsgegevens, OAuth-app of firmware.
Test het volledige alarmpad minstens elk kwartaal als geen centrale monitoring dit continu bewaakt.
Documenteer de geldigheid en rotatie van wachtwoorden, Client Secrets en Tokens.
Pas de gebeurtenisselectie regelmatig aan nieuwe functies en uitgeschakelde services aan.
Leg voor elke belangrijke melding een eerste controlestap en escalatiepad vast.

De dagelijkse Sophos Firewall-beheerchecklist bundelt welke status-, beveiligings- en beheersignalen tijdens de werking ook actief moeten worden gecontroleerd.

E-mail is een goed direct alarmkanaal, maar vervangt geen centrale logopslag of correlatie. Voor een langere geschiedenis en beveiligingsanalyse is Sophos Firewall Syslog naar een SIEM sturen geschikt. Voor klassieke statusbewaking en traps is SNMP-hardwaremonitoring de passende aanvulling.

Voor PDF-analyses die dagelijks of wekelijks worden verstuurd, wordt niet de Notification list gebruikt, maar een afzonderlijke rapportplanning. Sophos Firewall-rapporten plannen en per e-mail versturen legt rapportselectie, bookmark, transporttest en inhoudscontrole uit.

Het ontvangeradres via CLI Main Menu > 2. System Configuration wijzigen