Naar de inhoud
Avanet

E-mailmeldingen van Sophos Firewall instellen en testen

Sophos Firewall

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 snelle aanpak:

  1. Configureer de mailserver, poort, authenticatie, versleuteling, afzender en ontvanger onder Administration > Notification settings.
  2. Verstuur een testmail en bevestig de aflevering in de doelmailbox of via de tracking van de mailserver.
  3. Activeer onder System services > Notification list de globale schakelaar Email notifications.
  4. Selecteer alleen gebeurtenissen waarop een verantwoordelijke ontvanger kan reageren.
  5. 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.

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.

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.

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:

  1. Activeer onder Administration > Notification settings de Built-in email server.
  2. Voer de afzender, ontvanger en optioneel Management interface IP address in.
  3. 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

  1. Open Administration > Notification settings.
  2. Selecteer External email server.
  3. Voer het IPv4-adres of de FQDN van de mailserver en de opgegeven poort in.
  4. Kies onder Authentication None, Basic of OAuth 2.0, passend bij de server.
  5. Stel onder Connection security de transportversleuteling in die de mailserver vereist.
  6. Voer de afzender, ontvanger en optioneel Management interface IP address in.
  7. 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. Volgens Sophos is de gebruikersnaam 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.

Als de firewall Mail Protection in MTA Mode gebruikt, hangt het certificaat dat voor de e-mailverzending wordt gebruikt bovendien af van de configuratie onder Email > General settings. Een wijziging mag daarom niet afzonderlijk worden uitgevoerd zonder rekening te houden met de productieve mailflow.

Gmail en Microsoft 365 met OAuth 2.0

Voor Gmail en Microsoft 365 vereist de huidige SFOS 22-help OAuth 2.0. Hiervoor worden in Notification settings Provider, Client ID, Client secret en Refresh token ingevoerd. Hoewel de algemene Sophos-help het Client secret voor Microsoft 365 als optioneel aanduidt, maakt en gebruikt de door Sophos gedocumenteerde Microsoft 365-procedure er nadrukkelijk een. 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 actuele stappen beschrijft Sophos onder Configure OAuth 2.0 on Gmail.

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 door Sophos 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 actuele Entra-stappen staan onder Configure OAuth 2.0 on Microsoft 365.

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.

⚠️ Sophos vermeldt in de huidige Known Issues list nog steeds NC-166854: Microsoft 365 OAuth voor Notifications werkt niet op de daar genoemde builds 22.0.0.274, 22.0.0.323, 21.0.2.349 en 21.5.1.261. Er wordt geen fixversie genoemd. Controleer daarom de exacte SFOS-build 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.

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 en vooral mislukte installaties, passend bij het eigen updateproces.
  • System: mislukte updates van signatures of databases, systeemstart, hoge CPU-belasting en Gateway status.
  • IPS en Active threat response: eerst kritieke of blokkerende gebeurtenissen als daarvoor een triageproces bestaat.
  • RED, AP en VPN: alleen voor daadwerkelijk gebruikte apparaten en belangrijke verbindingen.
  • Web - Instant alerts: bewust geselecteerde webcategorieën. Deze meldingen worden in 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. Dit betreft bepaalde wijzigingen in HA-rollen en -status, de status van virtuele hosts en opnieuw opstarten of afsluiten via WebAdmin. Ook voor deze meldingen moet het geconfigureerde mailpad bereikbaar zijn.

Testmail en echte gebeurtenis controleren

De controle bestaat uit twee stappen.

1. SMTP-aflevering met een testmail bevestigen

Verstuur de testmail onder Administration > Notification settings. 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.

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;
  • Up/Down van een uitdrukkelijk daarvoor bestemde VPN-testtunnel;
  • 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:

  1. Is Email notifications globaal geactiveerd?
  2. Is de concrete gebeurtenis in de kolom Email geselecteerd?
  3. Heeft de verwachte gebeurtenis werkelijk plaatsgevonden en valt deze in de juiste categorie?
  4. Is er een bekende vertraging of bundeling, bijvoorbeeld bij Web Instant Alerts?
  5. 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 verwerpt. Een VPN-melding hangt af van het tunneltype en de werkelijke Up-/Down-status.

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

  • 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.

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.