Konfigurera och testa e-postaviseringar i Sophos Firewall

För fungerande e-postaviseringar kräver Sophos Firewall två separata konfigurationer: Under Administration > Notification settings konfigureras e-posttransporten. Under System services > Notification list anges vilka händelser som faktiskt ska rapporteras via e-post.

Även karantänsammanställningen för användare använder transporten, men dess schema, portallänk och användartilldelning är separata inställningar.

De synliga autentiserings-, SMTP-, administrations- och sms-texterna under Administration > Messages utgör ett tredje, separat lager. Konfigurera inloggningsmeddelande och meddelandetexter på Sophos Firewall förklarar deras innehåll och tester; en ändrad meddelandetext konfigurerar varken SMTP-transport eller händelseval.

Den snabba vägen:

Konfigurera e-postserver, port, autentisering, kryptering, avsändare och mottagare under Administration > Notification settings.
Skicka ett testmeddelande och bekräfta leveransen i mottagarens inkorg eller e-postserverns spårning.
Aktivera den globala inställningen Email notifications under System services > Notification list.
Välj endast händelser som en ansvarig mottagare kan reagera på.
Utlös utöver testmeddelandet en verklig vald händelse under kontrollerade former och kontrollera leveransen.

Ett lyckat testmeddelande visar endast att SMTP-vägen i grunden fungerar. Det visar ännu inte att den globala e-postinställningen och rätt händelser är aktiverade. Omvänt skickar en vald händelserad inget meddelande så länge e-posttransporten inte fungerar. Denna åtskillnad förklarar också varför en konfigurerad SMTP-server inte ensam uppfyller punkten Notification Emails i Sophos Firewall Health Check i praktiken.

Om WebAdmin inte är tillgängligt eller mottagaradressen behöver korrigeras via kontrollerad CLI-åtkomst, öppna 2. System Configuration > 3. Set Email ID for system notification i CLI:ns Main Menu. System Configuration är alternativ 2 i Main Menu, inte en undermeny till Device Console (alternativ 4). Om du redan befinner dig i alternativ 4, återgå först till Main Menu och välj där alternativ 2. Alternativet ändrar endast administratörens e-postadress för systemvarningar. Det konfigurerar varken e-postserver, avsändare, autentisering och TLS eller den globala inställningen och händelserna i Notification list.

Dokumentera först den tidigare adressen. Bekräfta sedan ändringen med y, ange den nya adressen och kontrollera att adressen som SFOS visar inte innehåller skrivfel. Tryck på Enter för att återgå till menyn. Därefter måste ett testmeddelande och en kontrollerad verklig händelse nå den nya mottagaren; konsolens bekräftelse i sig bevisar inte leverans.

Förbered e-postutskick

Före konfigurationen ska e-postserver, port och autentiseringsmetod stämmas av med den ansvariga e-postadministratören. Om ett FQDN som smtp.example.net används måste brandväggen kunna slå upp det och nå servern via den avsedda routingvägen. En allmän internetanslutning krävs endast om den valda e-postservern eller OAuth-leverantören finns på internet. Ett internt SMTP-relay kan också fungera utan att brandväggen har direkt internetåtkomst.

Dokumentera före en ändring valt e-postserveralternativ, e-postserver, port, Authentication, Connection security, avsändare, mottagare, hanteringsgränssnitt och valda händelser. Om ändringen omfattar certifikatinställningar ska även det aktuella valet under Administration > Notification settings eller Email > General settings dokumenteras. Kontrollera att de inloggningsuppgifter och OAuth-tokens som behövs är säkert tillgängliga i en lösenords- eller hemlighetshanterare; lägg dem inte i oskyddade skärmbilder. Med dessa uppgifter kan den tidigare konfigurationen återställas om den nya e-postvägen inte klarar leveranstestet.

Ett realistiskt exempel:

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: brandväggens interna hanteringsgränssnitt

Alla värden med example.net ersätts med den egna domänen och adresser som e-postadministratören har godkänt. En distributionsadress är oftast bättre än en personlig inkorg: ansvaret kan ändras utan att varje brandvägg måste konfigureras om.

Management interface IP address styr inte vilket gränssnitt SMTP-anslutningen lämnar brandväggen genom. Den valda IP-adressen tas med i aviseringen och hjälper till att identifiera den sändande brandväggen. Vid flera platser bör därför en permanent begriplig hanterings-IP väljas. Om det endast finns en brandvägg kan även None vara tillräckligt.

Fysiska gränssnitt, bridge-gränssnitt och LAG-gränssnitt visas bara i listrutan om de har tilldelats en IP-adress. Om ett gränssnitt saknas förklarar detta krav varför; tilldela inte IP-adresser och ändra inte gränssnitt eller routing enbart för att lägga till identifiering i ett meddelande.

Konfigurera e-postservern

Välj Built-in eller External email server

Sophos Firewall kan använda Built-in email server eller en External email server. Den inbyggda utskicksfunktionen är praktisk för en enkel start. I produktionsmiljöer är ett eget relay eller en molnbaserad e-postserver ofta lättare att följa upp, eftersom autentisering, meddelandespårning, avsändarbehörigheter och leveransfel syns på en central plats.

Vi rekommenderar därför External email server när det redan finns en tillförlitligt hanterad SMTP-tjänst.

För den inbyggda utskicksfunktionen räcker följande korta arbetsgång:

Aktivera Built-in email server under Administration > Notification settings.
Ange avsändare, mottagare och valfritt Management interface IP address.
Spara och skicka testmeddelandet.

Med Built-in email server finns ingen egen relayspårning där administratören kan följa mottagning och vidarebefordran. Kontrollera därför den faktiska leveransen särskilt noggrant. Om den misslyckas upprepade gånger eller om mottagardomänen och säkerhetskraven kräver en kontrollerad SMTP-väg är en External email server det alternativ som är lättare att hantera.

Konfigurera External email server

Öppna Administration > Notification settings.
Välj External email server.
Ange e-postserverns IPv4-adress eller FQDN och den föreskrivna porten.
Välj None, Basic eller OAuth 2.0 under Authentication så att det passar servern.
Ställ in den transportkryptering som e-postservern kräver under Connection security.
Ange avsändare, mottagare och valfritt Management interface IP address.
Spara och kör funktionen för testmeddelande.

Standardporten i SFOS är 25, men den är inte en rekommendation för varje miljö. Det avgörande är det egna relayets lyssnare. Vanliga alternativ är 25 för ett internt relay som godkänner käll-IP, 587 för autentiserad överföring med STARTTLS eller 465 för direkt SSL/TLS. Port, autentisering och krypteringsläge måste tillsammans passa e-postservern.

None betyder inte samma sak i de båda urvalsfälten: Under Authentication inaktiveras inloggning på e-postservern. Det kan vara korrekt för ett internt relay som endast godkänner brandväggens käll-IP. Under Connection security betyder None däremot okrypterad SMTP-överföring. Den inställningen är olämplig för internetvägar och bör även internt endast användas när säkerhetsmodellen uttryckligen tillåter det.

Med Basic använder brandväggen användarnamn och lösenord. Användarnamnet är skiftlägeskänsligt. Relayet måste stödja den autentiseringsmetod som används. Ett felmeddelande om Authentication method pekar särskilt på en skillnad mellan LOGIN och PLAIN.

STARTTLS missförstås lätt: Brandväggen följer e-postserverns kapacitet. Om servern erbjuder STARTTLS krypteras anslutningen. Om den inte gör det kan meddelandet överföras okrypterat. Den som måste tvinga fram kryptering använder SSL/TLS med en port och serverlyssnare som passar detta.

⚠️ Allow invalid certificate under Email > General settings bör inte aktiveras som en snabb lösning. Ett certifikat som har gått ut, inte är betrott eller inte passar servernamnet bör i stället korrigeras på e-postservern eller i förtroendekedjan.

Vilket certifikat SFOS använder beror också på e-postläget. Med STARTTLS i MTA Mode använder brandväggen certifikatet under Email > General settings. I Legacy Mode kan ett certifikat för STARTTLS väljas direkt under Administration > Notification settings. Om inget väljs använder SFOS också certifikatet under Email > General settings. Med SSL/TLS används certifikatet under Email > General settings. Ändra därför inte ett certifikat isolerat utan att ta hänsyn till det produktiva e-postflödet.

Gmail och Microsoft 365 med OAuth 2.0

För Gmail och Microsoft 365 ska OAuth 2.0 väljas i SFOS 22 och 23. Provider, Client ID, Client secret och Refresh token anges då under Notification settings. Fältet Client secret är valfritt för Microsoft 365, men arbetsflödet för Microsoft 365 som beskrivs här skapar och använder uttryckligen en secret. Därför konfigureras den också i detta arbetsflöde.

För Gmail måste ett projekt och Gmail API konfigureras i Google Cloud samt en OAuth-klient och Refresh Token skapas. Följande arbetsflöde beskriver dessa steg. Google och Microsoft ändrar sina portaler och krav oberoende av SFOS. Kontrollera därför leverantörernas aktuella krav och det avsedda avsändarkontots behörigheter innan konfigurationen tas i produktion.

Konfigurera Gmail OAuth 2.0 steg för steg

Kontrollera det avsedda avsändarkontot, OAuth-klienten, Redirect URI och det Gmail-scope med omfattande behörigheter som beskrivs nedan innan Refresh Token skapas. För följande arbetsflöde med User type: External måste även användning av OAuth-appen i produktion vara godkänd. Publish App ersätter varken den verifiering som leverantören kräver eller godkännande från ansvarig Google Workspace- eller säkerhetsadministratör. Om publicering inte tillåts enligt Googles aktuella krav eller interna policyer ska dessa skydd inte kringgås: använd i stället ett godkänt SMTP-relay för en varaktig larmväg.

Logga in på Google Cloud Console med det avsedda Google-kontot, skapa ett nytt projekt och välj det.
Öppna APIs & Services > Library, sök efter Gmail API och aktivera API:t.
Klicka på Create credentials > OAuth client ID under APIs & Services > Credentials.
Om medgivandeskärmen först krävs öppnar man Configure the OAuth consent screen > Get started. Ange appnamn och e-postadress, välj User type: External, lägg till utvecklarens kontaktadress och skapa konfigurationen.
Välj Create OAuth client, ställ in Application type: Web application och ange ett unikt namn.
Lägg under Authorized redirect URIs till exakt https://developers.google.com/oauthplayground.
Skapa OAuth-klienten och dokumentera omedelbart Client ID och Client secret på ett säkert sätt.
Kontrollera det avsedda avsändarkontot och aktuell publiceringsstatus under Audience. Så länge appen står på Testing läggs kontot till som testanvändare under Add users. Denna lista med testanvändare begränsar inte åtkomsten till en extern app efter publicering.
Utför Publish App efter nödvändigt godkännande och kontrollera att Publishing status har ändrats från Testing till In production. En extern app kan då i princip auktoriseras även av Google-konton utanför listan med testanvändare; gällande konto- och organisationspolicyer måste fortfarande följas. Skapa Refresh Token först därefter. I detta Gmail-arbetsflöde upphör en token som skapats före publicering att gälla efter sju dagar; skapa därför en ny Refresh Token efter publicering för varaktig drift i stället för att fortsätta använda den tidigare.
Öppna Google OAuth 2.0 Playground. Aktivera Use your own OAuth credentials via kugghjulsikonen och ange Client ID och Client secret.
Under Step 1 Select & authorize APIs, expandera Gmail API v1, välj scope https://mail.google.com och starta Authorize APIs. Använd det avsedda avsändarkontot och jämför den visade appen och dess behörigheter med den godkända konfigurationen innan samtycke ges. Avbryt och kontrollera konfigurationen vid avvikelser.
Växla koden mot tokens under Step 2 Exchange authorization code for tokens och kopiera Refresh token på ett säkert sätt. Client secret, Authorization Code, Access token och Refresh token hör inte hemma i ärenden, oskyddade skärmbilder eller loggar.
Konfigurera på brandväggen under Administration > Notification settings en External email server med Authentication: OAuth 2.0 och Provider: Gmail. Ange Client ID, Client secret och Refresh token, spara och skicka ett testmeddelande. Bekräfta den faktiska leveransen i mottagarens inkorg eller e-postserverns spårning; sparade OAuth-fält bevisar inte i sig att e-postvägen fungerar.

Google behandlar inte ett OAuth-projekt med User type External och Publishing status Testing som en permanent produktionskonfiguration: När Gmail-scope används upphör Refresh Token att gälla efter sju dagar enligt Google OAuth 2.0. Utöver att skicka e-post tillåter det Gmail-scope https://mail.google.com som används här även läsning, skapande och permanent radering av e-postmeddelanden. OAuth-appen, inloggningsuppgifterna och ett så dedikerat avsändarkonto som möjligt måste därför skyddas och hanteras lika noggrant som ett lösenord till en e-postserver.

För Microsoft 365 behöver appen de delegerade behörigheterna SMTP.Send och offline_access. Authenticated SMTP måste vara aktiverat för avsändarkontot. Det dokumenterade standardförfarandet använder smtp.office365.com, port 587 och STARTTLS. Om avsändaradressen avviker från den inloggade inkorgen behöver kontot dessutom Send As. Den fullständiga Entra-proceduren följer direkt nedan.

Konfigurera Microsoft 365 OAuth 2.0 steg för steg

Skapa en New registration i Microsoft Entra admin center under Identity > Applications > App registrations.
Ange ett unikt namn. Välj Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) för detta arbetsflöde. Välj plattformen Web under Redirect URI och ange https://outlook.office365.com/ som URI. Alternativt kan http://localhost/ användas. Den registrerade URI:n måste återanvändas exakt i auktoriseringsbegäran och vid tokenutbytet; om localhost används måste redirect_uri ändras till http://localhost/ i båda exemplen nedan.
Registrera appen och dokumentera Application (client) ID på ett säkert sätt.
Konfigurera den delegerade SMTP-behörigheten för Outlook-/Exchange-resursen under API permissions > Add a permission och ge det samtycke som krävs. Microsoft dokumenterar scope https://outlook.office.com/SMTP.Send för detta; dessutom begärs offline_access för Refresh Token. Det avgörande är SMTP-behörigheten, inte en Graph-behörighet som Mail.Send. Kontrollera resursvalet och de visade behörigheterna mot Microsofts anvisningar för SMTP med OAuth innan token skapas. Fortsätt inte med en till synes liknande behörighet om rätt behörighet saknas.
Kontrollera Authenticated SMTP för avsändarkontot i Microsoft 365 admin center under Users > Active users > Mail > Email apps > Manage email apps. Aktivera alternativet och spara om säkerhetspolicyerna tillåter det. Denna inställning för postlådan är inte appregistreringen i Entra admin center.
Skapa under Certificates & secrets > Client secrets > New client secret en secret med ett övervakat utgångsdatum. Kopiera omedelbart den visade Value på ett säkert sätt; Entra visar den inte längre efter att sidan laddats om.
Öppna följande URL i en webbläsare. Ersätt YOUR_CLIENT_ID med Application ID och YOUR_RANDOM_STATE med ett slumpmässigt värde som skapats enbart för detta förfarande; redirect_uri måste stämma överens med appregistreringen. URL-koda parametervärdena korrekt. State-värdet måste returneras oförändrat i svaret; ett fast exempelvärde skyddar inte förfarandet. Microsofts anvisningar för Authorization Code Flow förklarar kontroll av state och PKCE för lämpliga klienter.

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

Logga in med det avsedda avsändarkontot och jämför det returnerade state-värdet med det sparade värdet. Hämta den kortlivade auktoriseringskoden från omdirigeringsadressen först när värdena stämmer överens. Avbryt och börja om vid en avvikelse.
Skicka koden med en API-klient som application/x-www-form-urlencoded till tokenendpointen. Ersätt samtliga platshållare med värdena för denna app. Följande block visar fälten på flera rader för läsbarhetens skull. Ange dem som separata formulärfält i API-klienten så att blanksteg och specialtecken i kod, secret och Redirect URI kodas korrekt. Blocket är inte ett shell-kommando som kan kopieras och köras oförändrat.

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

Spara omedelbart den returnerade Refresh token på ett säkert sätt. Auktoriseringskod, Client secret, Access token och Refresh token hör inte hemma i ärenden, oskyddade skärmbilder eller loggar.
Konfigurera på brandväggen External email server under Administration > Notification settings med Authentication: OAuth 2.0 och Provider: Microsoft 365. Ange smtp.office365.com, port 587, STARTTLS, Client ID, Client secret och Refresh token, spara och skicka ett testmeddelande.

För detta arbetsflöde för att skapa tokens måste systemet som kör API-klienten och brandväggen använda samma tidszon. Kontrollera systemtid och tidszon innan arbetsflödet. Ändra inte spontant brandväggens tidszon i produktion; den omstart som krävs efter ändringen ska genomföras i ett underhållsfönster.

Microsoft Security Defaults inaktiverar SMTP AUTH. Denna skyddsinställning bör inte stängas av generellt för hela tenant endast för att en brandvägg ska kunna skicka meddelanden. Om den riktade aktiveringen för avsändarkontot inte passar säkerhetsmodellen är ett avsett internt eller externt relay den renare vägen.

⚠️ Det kända felet NC-166854 berör Microsoft 365 OAuth för Notifications på SFOS-buildarna 22.0.0.274, 22.0.0.323, 21.0.2.349 och 21.5.1.261. Detta innebär varken att alla andra buildar fungerar eller att ingen korrigering har blivit tillgänglig sedan dess. Kontrollera den exakta SFOS-builden och dess aktuella fel- och korrigeringsstatus innan e-postvägen tas i drift och kräv ett lyckat testmeddelande. Sparade Client ID-, Secret- och Token-fält är ännu inget funktionsbevis.

Om en angiven build berörs ska ett SMTP-relay som stöds eller en annan verifierad e-postväg användas tills en korrigerad firmwareversion har bekräftats på ett tillförlitligt sätt. Osäkra TLS-undantag eller oprövad Basic Authentication är inget bra alternativ till en fungerande larmväg.

Välj händelser i Notification list

Efter ett lyckat e-posttest öppnas System services > Notification list. Aktivera först Email notifications, markera sedan kryssrutorna i kolumnen Email för de händelser som behövs och spara med Save.

E-post och SNMP är separata utkanaler. För traps måste även SNMP-agenten och lämpliga communities eller användare konfigureras under Administration > SNMP. Aktivera därefter den globala inställningen SNMP traps och de tillgängliga händelsekryssrutorna för SNMP i Notification list och spara. Ett e-postval aktiverar inga traps; för varje händelse kan man välja e-post, SNMP eller båda kanalerna om de är tillgängliga. SNMP-artikeln som länkas nedan förklarar hur SNMP-managern konfigureras och testas.

Alla brandväggar behöver inte samma urval. En lämplig grund baseras på riskerna och de funktioner som faktiskt används:

Admin: misslyckade inloggningar och för många misslyckade inloggningsförsök.
HA: frånkopplade övervakade portar eller gränssnitt när ett HA-kluster används.
Disk/Memory: lagringsvarningar, så att ett fullt rapport- eller systemområde inte upptäcks först under underhållsfönstret. Tröskelvärden och konsekvenser förklaras i Kontrollera lagring och rapporter i Sophos Firewall.
Firmware: ny firmware som är klar för installation, lyckade firmwareinstallationer och misslyckade installationer i enlighet med den egna uppdateringsprocessen.
Endast SFOS 23 – Firmware > Security updates: Aktivera kolumnen Email för Security updates under System services > Notification list. Den globala omkopplaren Email notifications och en fungerande SMTP-väg krävs fortfarande. SNMP-aviseringar är inte tillgängliga för säkerhetsuppdateringar via hotfix; begränsningen gäller inte generellt för alla hotfixar eller firmwarehändelser. Omedelbar leverans garanteras inte, och utebliven e-post bevisar varken att uppdateringen lyckats eller misslyckats. Kontrollera tillämpade uppdateringar med proceduren för hotfixverifiering i SFOS 23.
System: misslyckade uppdateringar av WebCat-databasen, IPS-signaturer och antivirusdefinitioner, systemstart eller omstart, hög CPU-belastning och Gateway status.
IPS: nivåerna Critical, Major, Moderate, Minor och Warning kan väljas. Varningen förutsätter att brandväggen loggar IPS-händelsen och kasserar paketet. Kritiska händelser med en definierad triageprocess är en lämplig utgångspunkt.
Active threat response: logg- och drop-händelser för MDR, NDR Essentials, Sophos X-Ops och threat feeds från tredje part väljs separat. Matchningstyperna och begränsningarna beskrivs i nästa avsnitt.
RED: anslutningsavbrott, misslyckad firmwareuppdatering, automatiskt återkallad auktorisering för enheten eller ny Unlock Code. AP: accesspunkt offline eller misslyckad firmwareuppdatering. Välj endast meddelanden för enheter som faktiskt används och utse en ansvarig mottagare.
VPN: IPsec-tunnel up, down och failover/failback samt etablerade eller frånkopplade SSL-VPN-anslutningar. Utlösningsvillkoren för IPsec som beskrivs nedan är snävare än denna allmänna lista; valet garanterar inte aviseringar för varje manuell ändring av tunnelstatus.
Virus: välj varningar för HTTP, FTP, SMTP, POP3 och IMAP4 utifrån de skyddsfunktioner som faktiskt används. Kryssrutan ersätter varken motsvarande kontroll eller dess händelsedetektering.
Web - Instant alerts: medvetet valda webbkategorier. Dessa meddelanden skickas i fasta femminutersbatcher som inte kan ändras och kräver en separat kategoriaktivering enligt beskrivningen under Webbkategorier och omedelbara varningar.

Om alla händelser aktiveras generellt uppstår snabbt larmtrötthet. Särskilt VPN-meddelanden kan upprepas ungefär var 60:e sekund tills orsaken har åtgärdats. Vid flera lokala och fjärranslutna nät kan dessutom ett meddelande genereras för varje subnätspar. Ett litet urval med en tydlig reaktion är bättre: Vem tar emot varningen, hur brådskande är den och vilket första kontrollsteg följer?

Vissa Default Notifications skickas automatiskt av brandväggen och kan inte avmarkeras: ändringar av HA-rollerna Standalone, Primary eller Auxiliary, HA-enhetsstatus faulty, virtuella värdar up/down samt omstart eller avstängning via WebAdmin. Den konfigurerade e-postvägen måste vara tillgänglig även för dessa meddelanden. Att händelsekategorin inte kan avmarkeras garanterar inte att ett meddelande når en otillgänglig postlåda.

Active threat response: skilj mellan matchning och kanal

För var och en av följande matchningstyper finns både ett Log event och ett Drop event:

Destination match for all traffic: destinationsadressen matchar en post i en threat feed.
Remote source match for inbound traffic: den fjärranslutna källadressen för inkommande trafik matchar en post.
Local source match for outbound traffic: den lokala källadressen för utgående trafik matchar en post.

En loggvarning i sig bevisar inte att trafiken har blockerats. Omvänt beror en drop-händelse på den faktiska matchningen och motsvarande konfiguration av Active threat response; e-postkryssrutan skapar varken en matchning eller en ny skyddsregel.

Sophos aviseringshjälp anger att matchning av lokala och fjärranslutna källadresser inte stöds för Sophos X-Ops. Detta motsägs dock av den SVG-trafikmatris som beskrivs i NDR-/ATR-artikeln, särskilt för lokal källmatchning. E-postalternativet bevisar därför varken en viss X-Ops-matchningseffekt eller att motsägelsen är löst; klargör omstridda fall separat innan de planeras som en förutsättning för skydd. Remote-source-match-varningar vidarebefordras inte till Sophos centrala tjänst, men deras loggar är synliga i Central Firewall Reporting (CFR). Namnet på den centrala tjänsten varierar mellan versionerna (Sophos Fusion (tidigare Sophos Central) respektive Sophos Fusion); detta innebär inte att vidarebefordran av varningar har utökats. För dessa händelser ska därför den lokala e-post- och loggvägen kontrolleras i stället för att enbart förlita sig på central visning av varningar.

Förstå utlösningsvillkor och upprepningar

En aktiverad kryssruta betyder inte att varje kort statusändring genererar ett e-postmeddelande. I SFOS 22.0 och 23.0 gäller följande villkor för dessa händelser:

Admin: Sign-in failed omfattar felaktiga inloggningsuppgifter eller ett felaktigt engångslösenord (OTP). Too many failed sign-in attempts utlöses när antalet misslyckade försök som konfigurerats under Administration > Admin and user settings > Login security har uppnåtts. Tröskeln förklarar varningen; det är inte en instruktion att orsaka en kontospärr.
High CPU usage: Den första aviseringsloggposten skapas först när CPU-belastningen når 95% och ligger kvar oavbrutet på minst 95% i minst 25 minuter. Ytterligare poster skapas var 25:e minut tills belastningen sjunker under 95%. En kort CPU-topp utan händelsemeddelande bevisar därför inte ett SMTP-fel.
Gateway status: Händelsevalet är aktiverat som standard. För utskick måste ändå den separata globala inställningen Email notifications vara aktiverad.

För diskhändelser måste användningen oavbrutet ligga på eller över respektive tröskel i minst 50 sekunder. Därefter upprepas loggar och aviseringar med följande standardintervall tills användningen sjunker under tröskeln:

Område	Aviseringströskel	Upprepning
Konfigurationslagring	≥80%	var 50:e sekund
Signaturlagring	≥90%	var 50:e sekund
`/var`	≥80%	var 12:e timme

För /var genererar redan den lägre tröskeln loggar; aviseringar börjar först vid den högre tröskeln på 80%. Om användningen överskrider den högre tröskeln och sedan sjunker under den lägre loggas återhämtningen, men ingen återställningsavisering skickas. Detta skiljer sig från rapporternas varnings- och stoppbeteende i lagringsartikeln som länkats ovan; ett uteblivet återställningsmeddelande är här inget leveransfel.

För IPsec är det dokumenterade tillämpningsområdet snävare än en godtycklig VPN-Up/Down-ändring: aviseringar gäller bara host-to-host- och site-to-site-tunnlar med de beskrivna frånkopplingsvillkoren:

Dead peer detection (DPD).
Anslutningen kan inte återupprättas efter DPD.
IPsec Security Association (SA) har löpt ut och måste återupprättas.
Denna lista omfattar också att tunneln kommer upp igen efter förlorad anslutning utan administratörens ingripande.

Om en beskrivning har angetts i IPsec-anslutningens inställningar ingår den i aviseringen. Detta garanterar inte aviseringar för varje manuell frånkoppling eller för fjärråtkomst- eller SSL-VPN-tunnlar.

CPU-tiderna beskriver när aviseringsloggar skapas och diskintervallen den dokumenterade upprepningen, inte en garanterad ankomsttid i inkorgen. Om e-post saknas jämförs först händelsevillkoret, loggtidpunkten och e-postserverns spårning. Orsaka inte CPU- eller diskmättnad, inloggningsspärrar, HA-avbrott eller VPN-fel i produktion enbart för att testa en varning.

Kontrollera testmeddelande och verklig händelse

Kontrollen består av två steg.

1. Bekräfta SMTP-leverans med ett testmeddelande

Kontrollera först e-postkonfigurationen som sparats under Administration > Notification settings och kör den testmeddelandefunktion som är tillgänglig i den SFOS-build som används. Rapporttestet görs via Reports > Show report settings > Report scheduling: välj en rapport, öppna Send test mail, ange testmottagarens adress och klicka på Send. Detta rapporttest kontrollerar e-posttransporten, inte händelsevalet; dess mottagare är inte automatiskt den sparade mottagaren för systemvarningar. Brandväggens bekräftelse på att utskicket lyckades räcker ännu inte: I mottagarens inkorg, spamfilter eller e-postserverns spårning måste det framgå att meddelandet faktiskt har tagits emot och levererats. Rapportinnehåll och schema kontrolleras separat enligt beskrivningen i rapportartikeln som länkas nedan.

Kontrollera följande:

Avsändare och mottagare stämmer.
Rätt brandvägg kan identifieras genom ämne, innehåll eller hanterings-IP.
Meddelandet hamnar inte permanent i spam eller karantän.
Distributionslistan godtar meddelanden från den konfigurerade avsändaren.

2. Testa hela händelsekedjan

Utlös därefter en vald händelse under kontrollerade former. Lämpliga exempel är:

en enda misslyckad inloggning med ett testkonto efter att inloggningsspärrar och tröskelvärden har kontrollerats;
en dokumenterad VPN-händelse på en tunnel som uttryckligen är avsedd för test, förutsatt att tunneltypen och utlösningsvillkoret stämmer överens med den valda aviseringen; en manuell IPsec-Up/Down-ändring är inte i sig ett tillförlitligt aviseringstest;
Gateway status under ett planerat WAN-failovertest.

Att starta om eller koppla från en produktionsgateway, en HA-port eller själva brandväggen endast för att testa e-post vore oproportionerligt. Ett redan planerat underhålls- eller failoverscenario är ett bättre test.

Först när händelsen når rätt mottagare inom den förväntade tiden är hela kedjan bekräftad: händelsedetektering, händelseval, global e-postinställning, SMTP-transport och leverans.

Avgränsa fel systematiskt

Testmeddelandet misslyckas redan

API:t för SFOS 22 skiljer mellan flera felklasser:

Failed to connect eller SMTP server failed to respond: Kontrollera FQDN-upplösning, route, port, brandvägg uppströms och e-postserverns lyssnare.
Password mismatch: Kontrollera användarnamn, versaler/gemener, lösenord och eventuellt ett spärrat konto.
Authentication method mismatch: Kontrollera om relayet och SFOS gemensamt stöder LOGIN eller PLAIN för Basic Authentication.
STARTTLS not supported: Port och Connection security passar inte serverlyssnaren.
Mail server refused to communicate: Kontrollera relaybehörighet, avsändaradress, tillåten käll-IP och e-postserverloggar.
Couldn’t generate the OAuth 2.0 access token: Kontrollera Provider, Client ID, Secret, Refresh Token, behörigheter och systemtid.

DNS och STARTTLS kan förkontrolleras från ett administrationssystem på en jämförbar nätverksväg utan att e-postservern ändras:

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

smtp.example.net och 587 ersätts med den egna servern och porten. nslookup bekräftar endast namnupplösningen för administrationssystemet. openssl s_client visar SMTP-åtkomst, TLS-handshake och certifikatkedja, men kontrollerar varken routen ur brandväggens perspektiv, dess inloggning eller den senare leveransen.

I Log Viewer och vid en djupare analys i cschelper.log kan testtidpunkten korreleras med det systemgenererade e-postmeddelandet. Åtkomst till Service Logs och avgränsning mot Advanced Shell beskrivs under Sophos Firewall-tjänster och loggar. MTA-loggar som smtpd_main.log hör främst till Mail Protection och är inte generellt loggen för Notifications.

Testmeddelandet kommer fram, men händelsemeddelanden saknas

Då fungerar transporten och sökningen börjar under System services > Notification list:

Är Email notifications globalt aktiverat?
Är den konkreta händelsen vald i kolumnen Email?
Har den förväntade händelsen verkligen inträffat och passar den rätt kategori?
Finns det en känd fördröjning eller gruppering, till exempel för Web Instant Alerts?
Visar spamfilter, karantän eller e-postserverns spårning ett godkännande eller avvisande?

För en enskild specialhändelse bör dessutom dess tekniska villkor kontrolleras. En IPS-varning uppstår till exempel inte endast genom en aktiverad kryssruta, utan först när en lämplig IPS-regel loggar händelsen och kasserar paketet. Ett VPN-meddelande beror på tunneltypen och det faktiska Up/Down-tillståndet.

Gmail OAuth slutar fungera efter ett lösenordsbyte

I det Gmail-arbetsflöde för aviseringar som beskrivs här, med scope https://mail.google.com, blir Refresh Token ogiltig när lösenordet för det Gmail-konto som används för utskick ändras. Brandväggen kan då inte längre hämta en ny Access Token med denna token. Detta gäller inte alla Google OAuth-tokens eller Microsoft 365.

Kontrollera om lösenordet för just detta avsändarkonto har ändrats. Jämför OAuth-klient, konto, godkända behörigheter och Publishing status: In production med den dokumenterade konfigurationen. Inte heller en token som skapats före Publish App är en varaktig grund efter sju dagar; kontrollera de två orsakerna separat.
Använd den aktuella kontoinloggningen och inloggningsuppgifterna för den egna OAuth-klienten för att upprepa Gmail-auktoriseringen och tokenutbytet enligt Playground-arbetsflödet ovan. Kontrollera appen och de begärda behörigheterna innan samtycke ges och spara den nya Refresh Token säkert.
Under Administration > Notification settings, för Provider: Gmail, ersätt den ogiltiga Refresh token med den nya och spara. Client ID och Client secret måste höra till den OAuth-klient som används; ändra inte SMTP-, TLS-, avsändar-, mottagar- eller händelseinställningar utan anledning.
Skicka ett testmeddelande och bekräfta den faktiska leveransen i mottagarens inkorg eller e-postserverns spårning. Kontrollera därefter en vald händelse som utlöses under kontrollerade former enligt avsnittet om hela händelsekedjan.

Att ange den gamla token igen gör den inte giltig. Återställ inte kontolösenordet enbart för att återfå den tidigare e-postvägen. Om utskicket fortfarande misslyckas efter den nya auktoriseringen, dokumentera det exakta felmeddelandet, SFOS-builden och leverantörskonfigurationen utan secrets eller tokens för vidare analys. Använd en godkänd alternativ larmväg eller det dokumenterade SMTP-relayet tills återställningen har bekräftats.

Microsoft 365 OAuth sparar, men skickar inte

Jämför först SFOS-version och build med NC-166854. Kontrollera därefter Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP för avsändarkontot och korrekt systemtid.

Om testmeddelandet fortfarande misslyckas på en build som inte listas som berörd är det inte automatiskt samma fel. Det exakta meddelandet, SFOS-builden och leverantörens inloggningsloggar hör då hemma i den fortsatta analysen eller i ett supportärende.

Hantera aviseringar i drift

Om leveransen misslyckas efter en ändring återställs först den dokumenterade e-postkonfigurationen: e-postserveralternativ, server, port, Authentication, Connection security, avsändare, mottagare och hanteringsgränssnitt samt det tidigare certifikatvalet om det ändrades. Låt händelsevalet vara oförändrat om det inte ingick i ändringen. Efter att inställningarna har sparats bekräftas den tidigare larmvägen igen med ett testmeddelande och en vald händelse som utlöses under kontrollerade former. Återställningen är klar först när båda meddelandena faktiskt har kommit fram.

Använd en funktionell distributionslista med en ansvarig Owner som mottagare.
Testa testmeddelandet och en verklig händelse på nytt efter ändringar av e-postserver, DNS, routing, certifikat, inloggningsuppgifter, OAuth-app eller firmware.
Testa hela larmvägen minst kvartalsvis om ingen central övervakning övervakar den kontinuerligt.
Dokumentera giltighetstid och rotation för lösenord, Client Secrets och Tokens.
Anpassa händelsevalet regelbundet till nya funktioner och avstängda tjänster.
Fastställ ett första kontrollsteg och en eskaleringsväg för varje viktig varning.

Den dagliga administratörschecklistan för Sophos Firewall samlar de status-, säkerhets- och administratörssignaler som också bör kontrolleras aktivt under drift.

E-post är en bra direkt larmkanal, men ersätter inte central logglagring eller korrelation. För längre historik och säkerhetsanalys passar Skicka Syslog från Sophos Firewall till ett SIEM. För klassisk statusövervakning och traps är SNMP Hardware Monitoring ett lämpligt komplement.

För PDF-analyser som skickas dagligen eller varje vecka används inte Notification list, utan ett separat rapportschema. Planera och skicka Sophos Firewall-rapporter via e-post förklarar rapportval, bookmark, transporttest och innehållskontroll.

Ändra mottagaradressen via CLI Main Menu > 2. System Configuration