Hoppa till innehållet
Avanet

Konfigurera och testa e-postaviseringar i Sophos Firewall

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.

Den snabba vägen:

  1. Konfigurera e-postserver, port, autentisering, kryptering, avsändare och mottagare under Administration > Notification settings.
  2. Skicka ett testmeddelande och bekräfta leveransen i mottagarens inkorg eller e-postserverns spårning.
  3. Aktivera den globala inställningen Email notifications under System services > Notification list.
  4. Välj endast händelser som en ansvarig mottagare kan reagera på.
  5. 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.

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.

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.

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 denna korta gren:

  1. Aktivera Built-in email server under Administration > Notification settings.
  2. Ange avsändare, mottagare och valfritt Management interface IP address.
  3. 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

  1. Öppna Administration > Notification settings.
  2. Välj External email server.
  3. Ange e-postserverns IPv4-adress eller FQDN och den föreskrivna porten.
  4. Välj None, Basic eller OAuth 2.0 under Authentication så att det passar servern.
  5. Ställ in den transportkryptering som e-postservern kräver under Connection security.
  6. Ange avsändare, mottagare och valfritt Management interface IP address.
  7. 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. Enligt Sophos är användarnamnet case-sensitive. 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.

Om brandväggen använder Mail Protection i MTA Mode beror certifikatet som används för e-postutskick dessutom på konfigurationen under Email > General settings. En ändring bör därför inte göras isolerat utan att det produktiva e-postflödet beaktas.

Gmail och Microsoft 365 med OAuth 2.0

För Gmail och Microsoft 365 kräver den aktuella hjälpen för SFOS 22 OAuth 2.0. Provider, Client ID, Client secret och Refresh token anges då under Notification settings. Den allmänna Sophos-hjälpen beskriver visserligen Client secret som valfritt för Microsoft 365, men Sophos dokumenterade Microsoft 365-arbetsflöde skapar och använder uttryckligen ett sådant. Därför konfigureras det också i detta arbetsflöde.

För Gmail måste ett projekt och Gmail API konfigureras i Google Cloud samt en OAuth client och Refresh Token skapas. De aktuella stegen beskrivs av Sophos under Configure OAuth 2.0 on Gmail.

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 ä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. De aktuella Entra-stegen beskrivs under Configure OAuth 2.0 on Microsoft 365.

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.

⚠️ Sophos listar fortfarande NC-166854 i den aktuella Known Issues list: Microsoft 365 OAuth för Notifications fungerar inte på de builds som anges där, 22.0.0.274, 22.0.0.323, 21.0.2.349 och 21.5.1.261. Ingen korrigerad version anges. Kontrollera därför den exakta SFOS-builden 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.

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 och framför allt misslyckade installationer i enlighet med den egna uppdateringsprocessen.
  • System: misslyckade signatur- eller databasuppdateringar, systemstart, hög CPU-belastning och Gateway status.
  • IPS och Active threat response: börja med kritiska eller blockerande händelser om det finns en triageprocess för dem.
  • RED, AP och VPN: endast för enheter som faktiskt används och viktiga anslutningar.
  • Web - Instant alerts: medvetet valda webbkategorier. Dessa meddelanden skickas i femminutersbatcher 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. Dit hör vissa ändringar av HA-roll och -status, status för virtuella värdar samt omstart eller shutdown via WebAdmin. Den konfigurerade e-postvägen måste vara tillgänglig även för dessa meddelanden.

Kontrollera testmeddelande och verklig händelse

Kontrollen består av två steg.

1. Bekräfta SMTP-leverans med ett testmeddelande

Skicka testmeddelandet under Administration > Notification settings. 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.

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;
  • Up/Down för en VPN-testtunnel som uttryckligen är avsedd för detta;
  • 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:

  1. Är Email notifications globalt aktiverat?
  2. Är den konkreta händelsen vald i kolumnen Email?
  3. Har den förväntade händelsen verkligen inträffat och passar den rätt kategori?
  4. Finns det en känd fördröjning eller gruppering, till exempel för Web Instant Alerts?
  5. 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 och avvisar händelsen. Ett VPN-meddelande beror på tunneltypen och det faktiska Up/Down-tillståndet.

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

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

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.