Konfiguracja i test powiadomień e-mail Sophos Firewall

Aby powiadomienia e-mail działały, Sophos Firewall wymaga dwóch oddzielnych konfiguracji: w sekcji Administration > Notification settings konfiguruje się transport poczty. W sekcji System services > Notification list określa się, które zdarzenia mają być faktycznie zgłaszane pocztą e-mail.

Ten transport wykorzystuje też raport kwarantanny dla użytkowników, ale jego harmonogram, link do portalu i przypisanie kont są oddzielnymi ustawieniami.

Widoczne teksty Authentication, SMTP, Admin i SMS w Administration > Messages stanowią trzeci, niezależny poziom. Konfiguracja komunikatu logowania i wiadomości w Sophos Firewall wyjaśnia ich treść i testy; zmiana wiadomości nie konfiguruje ani transportu SMTP, ani wyboru zdarzeń.

Szybka procedura:

Skonfiguruj serwer pocztowy, port, uwierzytelnianie, szyfrowanie, nadawcę i odbiorcę w sekcji Administration > Notification settings.
Wyślij wiadomość testową i potwierdź jej dostarczenie w docelowej skrzynce lub systemie śledzenia serwera pocztowego.
W sekcji System services > Notification list aktywuj globalny przełącznik Email notifications.
Wybierz tylko te zdarzenia, na które odpowiedzialny odbiorca może zareagować.
Oprócz wiadomości testowej wywołaj w kontrolowany sposób rzeczywiste wybrane zdarzenie i sprawdź jego dostarczenie.

Pomyślnie wysłana wiadomość testowa dowodzi jedynie, że tor SMTP zasadniczo działa. Nie potwierdza jeszcze, że aktywowano globalny przełącznik poczty i właściwe zdarzenia. Z drugiej strony wybrany wiersz zdarzenia nie wyśle wiadomości, dopóki nie działa transport poczty. Właśnie to rozdzielenie wyjaśnia, dlaczego sam skonfigurowany serwer SMTP nie spełnia jeszcze operacyjnie punktu Notification Emails w artykule Sophos Firewall Health Check.

Jeśli WebAdmin jest niedostępny albo adres odbiorcy trzeba poprawić przez kontrolowany dostęp do CLI, w Main Menu interfejsu CLI należy otworzyć 2. System Configuration > 3. Set Email ID for system notification. System Configuration to opcja 2 w Main Menu, a nie podmenu Device Console (opcja 4). Jeśli wybrano już opcję 4, należy najpierw wrócić do Main Menu i tam wybrać opcję 2. Ta opcja zmienia wyłącznie adres e-mail administratora dla alertów systemowych. Nie konfiguruje serwera pocztowego, nadawcy, uwierzytelniania i TLS ani globalnego przełącznika i zdarzeń na Notification list.

Najpierw należy udokumentować poprzedni adres. Następnie potwierdzić zmianę przez y, wprowadzić nowy adres i sprawdzić adres wyświetlony przez SFOS pod kątem literówek. Enter powoduje powrót do menu. Potem wiadomość testowa i kontrolowane rzeczywiste zdarzenie muszą dotrzeć do nowego odbiorcy; samo potwierdzenie w konsoli nie dowodzi dostarczenia.

Przygotowanie wysyłania poczty

Przed rozpoczęciem konfiguracji należy uzgodnić z administratorem poczty serwer, port i metodę uwierzytelniania. Jeśli używana jest nazwa FQDN, taka jak smtp.example.net, firewall musi móc ją rozwiązać i osiągnąć serwer przez przewidzianą trasę. Ogólne połączenie z Internetem jest potrzebne tylko wtedy, gdy wybrany serwer pocztowy lub dostawca OAuth znajduje się w Internecie. Wewnętrzny przekaźnik SMTP może działać także bez bezpośredniego dostępu firewalla do Internetu.

Przed zmianą należy zapisać wybraną opcję serwera pocztowego, serwer, port, Authentication, Connection security, nadawcę, odbiorcę, interfejs zarządzający i wybrane zdarzenia. Jeśli zmiana obejmuje certyfikaty, należy również zapisać bieżący wybór w Administration > Notification settings lub Email > General settings, zależnie od konfiguracji. Trzeba też upewnić się, że wymagane dane logowania i tokeny OAuth są bezpiecznie dostępne w menedżerze haseł lub sekretów; nie należy umieszczać ich na niezabezpieczonych zrzutach ekranu. Te informacje umożliwią odtworzenie poprzedniej konfiguracji, jeśli nowa trasa pocztowa nie przejdzie testu dostarczenia.

Realistyczny przykład:

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: wewnętrzny interfejs zarządzający firewalla

Wszystkie wartości zawierające example.net należy zastąpić własną domeną i adresami zatwierdzonymi przez administratora poczty. Adres listy dystrybucyjnej jest zwykle lepszy od osobistej skrzynki: zakres odpowiedzialności można zmienić bez ponownej konfiguracji każdego firewalla.

Pole Management interface IP address nie określa, przez który interfejs połączenie SMTP opuszcza firewall. Wybrany adres IP jest dołączany do powiadomienia i pomaga zidentyfikować wysyłający firewall. Przy wielu lokalizacjach należy więc wybrać trwale zrozumiały adres IP do zarządzania; przy jednym firewallu może wystarczyć również None.

Interfejsy fizyczne, bridge i LAG pojawiają się na liście rozwijanej tylko wtedy, gdy mają przypisany adres IP. Jeśli interfejsu brakuje, ten warunek wyjaśnia jego nieobecność; nie należy przypisywać adresów IP ani zmieniać interfejsów lub routingu wyłącznie po to, aby dodać identyfikację do wiadomości.

Konfiguracja serwera pocztowego

Wybór Built-in lub External email server

Sophos Firewall może korzystać z opcji Built-in email server albo External email server. Wbudowana wysyłka jest praktyczna na prosty początek. W środowiskach produkcyjnych własny przekaźnik lub chmurowy serwer pocztowy jest często łatwiejszy do monitorowania, ponieważ uwierzytelnianie, śledzenie poczty, uprawnienia nadawców i błędy dostarczania są widoczne w jednym centralnym miejscu.

Dlatego zalecamy External email server, jeśli dostępna jest już niezawodnie obsługiwana usługa SMTP.

Dla wbudowanej wysyłki wystarczy ta krótka procedura:

W sekcji Administration > Notification settings aktywuj Built-in email server.
Wprowadź nadawcę, odbiorcę i opcjonalnie Management interface IP address.
Zapisz ustawienia i wyślij wiadomość testową.

W przypadku Built-in email server nie ma własnego systemu śledzenia przekaźnika, w którym administrator może sprawdzić przyjęcie i przekazanie wiadomości. Dlatego rzeczywiste dostarczenie należy skontrolować szczególnie uważnie. Jeśli wielokrotnie się nie powiedzie albo domena odbiorcy i wymagania bezpieczeństwa wymagają kontrolowanego toru SMTP, External email server jest łatwiejszym w utrzymaniu wariantem.

Konfiguracja External email server

Otwórz Administration > Notification settings.
Wybierz External email server.
Wprowadź adres IPv4 lub FQDN serwera pocztowego oraz wskazany port.
W sekcji Authentication wybierz odpowiednio do serwera None, Basic albo OAuth 2.0.
W sekcji Connection security ustaw szyfrowanie transportu wymagane przez serwer pocztowy.
Wprowadź nadawcę, odbiorcę i opcjonalnie Management interface IP address.
Zapisz ustawienia i uruchom funkcję wiadomości testowej.

Domyślnym portem w SFOS jest 25, ale nie jest on zaleceniem dla każdego środowiska. Decydujący jest listener własnego przekaźnika. Typowe wartości to 25 dla wewnętrznego przekaźnika dopuszczonego na podstawie źródłowego adresu IP, 587 dla uwierzytelnionego przesyłania z STARTTLS albo 465 dla bezpośredniego SSL/TLS. Port, uwierzytelnianie i tryb szyfrowania muszą jako zestaw pasować do serwera pocztowego.

None nie oznacza tego samego w obu polach wyboru: w sekcji Authentication wyłącza logowanie do serwera pocztowego. Może to być prawidłowe w przypadku wewnętrznego przekaźnika, który dopuszcza wyłącznie źródłowy adres IP firewalla. W sekcji Connection security None oznacza natomiast nieszyfrowaną transmisję SMTP. To ustawienie nie nadaje się do połączeń przez Internet i również wewnętrznie powinno być używane tylko wtedy, gdy model bezpieczeństwa wyraźnie na to pozwala.

W przypadku Basic firewall używa nazwy użytkownika i hasła. W nazwie użytkownika należy zachować wielkość liter. Przekaźnik musi obsługiwać używaną metodę logowania; komunikat o błędzie dotyczącym Authentication method wskazuje w szczególności na rozbieżność w obsłudze LOGIN lub PLAIN.

STARTTLS można łatwo źle zrozumieć: firewall dostosowuje się do możliwości serwera pocztowego. Jeśli serwer oferuje STARTTLS, połączenie jest szyfrowane; jeśli go nie oferuje, wiadomość może zostać przesłana bez szyfrowania. Jeśli szyfrowanie musi być wymuszone, należy użyć SSL/TLS z odpowiednim portem i listenerem serwera.

⚠️ Opcji Allow invalid certificate w sekcji Email > General settings nie należy aktywować jako szybkiego obejścia. Wygasły, niezaufany albo niezgodny z nazwą serwera certyfikat lepiej poprawić na serwerze pocztowym lub w łańcuchu zaufania.

Certyfikat używany przez SFOS zależy również od trybu poczty. Przy STARTTLS w MTA Mode firewall używa certyfikatu z sekcji Email > General settings. W Legacy Mode certyfikat dla STARTTLS można wybrać bezpośrednio w Administration > Notification settings; jeśli nic nie zostanie wybrane, SFOS także użyje certyfikatu z Email > General settings. Przy SSL/TLS używany jest certyfikat z sekcji Email > General settings. Dlatego certyfikatu nie należy zmieniać w oderwaniu od produkcyjnego przepływu poczty.

Gmail i Microsoft 365 z OAuth 2.0

W przypadku Gmaila i Microsoft 365 w SFOS 22 i 23 należy wybrać OAuth 2.0. W tym celu w sekcji Notification settings wprowadza się Provider, Client ID, Client secret i Refresh token. Pole Client secret jest opcjonalne dla Microsoft 365, jednak opisana tutaj procedura Microsoft 365 wyraźnie obejmuje utworzenie i użycie sekretu. Dlatego w tej procedurze również należy go skonfigurować.

W przypadku Gmaila w Google Cloud należy skonfigurować projekt i Gmail API, a także utworzyć klienta OAuth i Refresh Token. Poniższa procedura opisuje te kroki. Google i Microsoft zmieniają swoje portale i wymagania niezależnie od SFOS; dlatego przed konfiguracją w środowisku produkcyjnym należy sprawdzić aktualne wymagania dostawcy i uprawnienia konta przeznaczonego do wysyłania.

Konfiguracja Gmail OAuth 2.0 krok po kroku

Przed utworzeniem Refresh Token należy sprawdzić przeznaczone konto wysyłające, klienta OAuth, Redirect URI oraz opisany poniżej zakres Gmail z szerokimi uprawnieniami. W poniższej procedurze z User type: External wymagane jest również zatwierdzenie produkcyjnego użycia aplikacji OAuth. Publish App nie zastępuje wymaganej weryfikacji dostawcy ani zgody odpowiedzialnego administratora Google Workspace lub bezpieczeństwa. Jeśli publikacja nie jest dozwolona przez aktualne wymagania Google lub wewnętrzne zasady, nie należy omijać tych zabezpieczeń: zamiast tego do stałego alarmowania należy użyć zatwierdzonego przekaźnika SMTP.

Zalogować się w Google Cloud Console przy użyciu przeznaczonego do tego konta Google, utworzyć nowy projekt i go wybrać.
Otworzyć APIs & Services > Library, wyszukać Gmail API i włączyć API.
W sekcji APIs & Services > Credentials kliknąć Create credentials > OAuth client ID.
Jeśli najpierw wymagany jest ekran zgody, otworzyć Configure the OAuth consent screen > Get started. Wprowadzić nazwę aplikacji i adres e-mail, wybrać User type: External, dodać adres kontaktowy dewelopera i utworzyć konfigurację.
Wybrać Create OAuth client, ustawić Application type: Web application i nadać jednoznaczną nazwę.
W sekcji Authorized redirect URIs dodać dokładnie https://developers.google.com/oauthplayground.
Utworzyć klienta OAuth i natychmiast bezpiecznie zapisać Client ID oraz Client secret.
W sekcji Audience sprawdzić przeznaczone konto wysyłające i bieżący status publikacji. Dopóki aplikacja ma status Testing, dodać konto jako użytkownika testowego w Add users. Ta lista użytkowników testowych nie stanowi ograniczenia dostępu do aplikacji zewnętrznej po jej opublikowaniu.
Po uzyskaniu wymaganego zatwierdzenia wykonać Publish App i sprawdzić, czy Publishing status zmienił się z Testing na In production. Aplikacja zewnętrzna jest wtedy zasadniczo dostępna do autoryzacji również dla kont Google spoza listy użytkowników testowych; nadal trzeba przestrzegać obowiązujących zasad dotyczących kont i organizacji. Dopiero potem utworzyć Refresh Token. W tej procedurze Gmail token utworzony przed publikacją wygasa po siedmiu dniach; do stałej eksploatacji należy więc utworzyć nowy Refresh Token po publikacji zamiast nadal używać poprzedniego.
Otworzyć Google OAuth 2.0 Playground. Za pomocą ikony koła zębatego włączyć Use your own OAuth credentials, a następnie wprowadzić Client ID i Client secret.
W sekcji Step 1 Select & authorize APIs rozwinąć Gmail API v1, wybrać zakres https://mail.google.com i uruchomić Authorize APIs. Użyć przeznaczonego konta wysyłającego i przed udzieleniem zgody porównać wyświetlaną aplikację oraz jej uprawnienia z zatwierdzoną konfiguracją. W przypadku rozbieżności przerwać i sprawdzić konfigurację.
W sekcji Step 2 Exchange authorization code for tokens wymienić kod na tokeny i bezpiecznie skopiować Refresh token. Client secret, Authorization Code, Access token i Refresh token nie mogą trafiać do zgłoszeń, niezabezpieczonych zrzutów ekranu ani logów.
Na firewallu w sekcji Administration > Notification settings skonfigurować External email server, wybierając Authentication: OAuth 2.0 i Provider: Gmail. Wprowadzić Client ID, Client secret i Refresh token, zapisać oraz wysłać wiadomość testową. Potwierdzić rzeczywiste dostarczenie w docelowej skrzynce lub systemie śledzenia serwera pocztowego; samo zapisanie pól OAuth nie dowodzi działania toru pocztowego.

Google nie traktuje projektu OAuth z User type External i Publishing status Testing jako trwałej konfiguracji produkcyjnej: przy użyciu zakresu Gmail Refresh Token wygasa według dokumentacji Google OAuth 2.0 po siedmiu dniach. Używany tutaj zakres Gmail https://mail.google.com pozwala oprócz wysyłania również czytać, tworzyć i trwale usuwać wiadomości e-mail. Dlatego aplikacja OAuth, dane dostępowe i najlepiej dedykowane konto wysyłające muszą być chronione i utrzymywane tak samo jak hasło do serwera pocztowego.

W Microsoft 365 aplikacja wymaga delegowanych uprawnień SMTP.Send i offline_access; dla konta wysyłającego musi być aktywna funkcja Authenticated SMTP. Udokumentowana standardowa metoda wykorzystuje smtp.office365.com, port 587 i STARTTLS. Jeśli adres nadawcy różni się od zalogowanej skrzynki, konto potrzebuje dodatkowo uprawnienia Send As. Pełna procedura Entra znajduje się bezpośrednio poniżej.

Konfiguracja Microsoft 365 OAuth 2.0 krok po kroku

W Microsoft Entra admin center utworzyć New registration w sekcji Identity > Applications > App registrations.
Nadać jednoznaczną nazwę. Dla tej procedury wybrać Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant). W sekcji Redirect URI wybrać platformę Web, a następnie wprowadzić https://outlook.office365.com/ jako URI. Alternatywnie można użyć http://localhost/. W żądaniu autoryzacji i podczas wymiany kodu na tokeny należy użyć dokładnie tego samego URI co przy rejestracji; w przypadku localhost trzeba odpowiednio zmienić wartość redirect_uri w obu poniższych przykładach.
Zarejestrować aplikację i bezpiecznie zapisać Application (client) ID.
W sekcji API permissions > Add a permission skonfigurować delegowane uprawnienie SMTP dla zasobu Outlook/Exchange i udzielić wymaganej zgody. Microsoft dokumentuje w tym celu zakres https://outlook.office.com/SMTP.Send; dodatkowo należy zażądać offline_access, aby uzyskać Refresh Token. Istotne jest uprawnienie SMTP, a nie uprawnienie Graph, takie jak Mail.Send. Przed utworzeniem tokenu sprawdzić wybór zasobu i wyświetlane uprawnienia zgodnie z instrukcją Microsoft dotyczącą SMTP z OAuth. Jeśli brakuje właściwego uprawnienia, nie kontynuować z innym, pozornie podobnym.
W Microsoft 365 admin center dla konta wysyłającego sprawdzić opcję Authenticated SMTP w sekcji Users > Active users > Mail > Email apps > Manage email apps i, jeśli zasady bezpieczeństwa na to pozwalają, włączyć ją oraz zapisać ustawienia. Ten przełącznik skrzynki pocztowej nie jest rejestracją aplikacji w Entra admin center.
W sekcji Certificates & secrets > Client secrets > New client secret utworzyć sekret z monitorowaną datą wygaśnięcia. Natychmiast bezpiecznie skopiować wyświetlaną Value; po ponownym załadowaniu strony Entra już jej nie pokaże.
Otworzyć w przeglądarce poniższy adres URL. Zastąpić YOUR_CLIENT_ID identyfikatorem Application ID, a YOUR_RANDOM_STATE losową wartością wygenerowaną wyłącznie dla tej operacji; wartość redirect_uri musi odpowiadać rejestracji aplikacji. Poprawnie zakodować wartości parametrów w formacie URL. Wartość State musi wrócić w odpowiedzi bez zmian; stała wartość przykładowa nie zabezpiecza operacji. Instrukcja Microsoft dotycząca przepływu Authorization Code wyjaśnia weryfikację State i PKCE dla odpowiednich klientów.

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

Zalogować się przy użyciu przeznaczonego konta wysyłającego, porównać zwróconą wartość State z zapisaną wartością i dopiero po potwierdzeniu ich zgodności pobrać krótkotrwały kod autoryzacyjny z adresu przekierowania. W przypadku rozbieżności przerwać operację i rozpocząć ją od nowa.
Wysłać kod za pomocą klienta API jako application/x-www-form-urlencoded do punktu końcowego tokenu. Zastąpić wszystkie symbole zastępcze wartościami tej aplikacji. Poniższy blok przedstawia pola w wielu wierszach dla czytelności; w kliencie API należy wprowadzić je jako oddzielne pola formularza, aby spacje i znaki specjalne w kodzie, sekrecie i Redirect URI zostały poprawnie zakodowane. Nie jest to polecenie powłoki, które można skopiować bez zmian.

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

Natychmiast bezpiecznie zapisać zwrócony Refresh token. Kod autoryzacyjny, Client secret, Access token i Refresh token nie mogą trafiać do zgłoszeń, niezabezpieczonych zrzutów ekranu ani logów.
Na firewallu skonfigurować External email server w sekcji Administration > Notification settings, wybierając Authentication: OAuth 2.0 i Provider: Microsoft 365. Wprowadzić smtp.office365.com, port 587, STARTTLS, Client ID, Client secret i Refresh token, zapisać oraz wysłać wiadomość testową.

W tej procedurze generowania tokenu system z klientem API i firewall muszą korzystać z tej samej strefy czasowej. Przed rozpoczęciem należy sprawdzić czas systemowy i strefę czasową. Nie należy spontanicznie zmieniać strefy czasowej firewalla w środowisku produkcyjnym; wymagany po takiej zmianie restart należy zaplanować w oknie serwisowym.

Microsoft Security Defaults wyłącza SMTP AUTH. Nie należy wyłączać tego zabezpieczenia ogólnie w całym tenancie tylko po to, aby firewall mógł wysyłać wiadomości. Jeśli selektywne zezwolenie dla konta wysyłającego nie pasuje do modelu bezpieczeństwa, lepszym rozwiązaniem jest przeznaczony do tego wewnętrzny lub zewnętrzny przekaźnik.

⚠️ Znany błąd NC-166854 dotyczy OAuth Microsoft 365 dla Notifications w buildach SFOS 22.0.0.274, 22.0.0.323, 21.0.2.349 i 21.5.1.261. Nie wynika z tego ani że każdy inny build działa, ani że nadal nie jest dostępna poprawka. Przed uruchomieniem należy sprawdzić dokładny build SFOS oraz obowiązujący dla niego status błędu i poprawki, a także wymagać pomyślnego dostarczenia wiadomości testowej. Samo zapisanie pól Client ID, Secret i Token nie dowodzi jeszcze działania.

Jeśli wymieniony build jest objęty problemem, należy użyć obsługiwanego przekaźnika SMTP albo innego zweryfikowanego toru pocztowego do czasu wiarygodnego potwierdzenia poprawionej wersji firmware. Niebezpieczne wyjątki TLS lub niesprawdzone Basic Authentication nie są dobrym zamiennikiem działającego toru alarmowania.

Wybór zdarzeń na Notification list

Po pomyślnym teście poczty należy otworzyć System services > Notification list. Najpierw aktywuj tam Email notifications, następnie zaznacz pola w kolumnie Email dla potrzebnych zdarzeń i zapisz przyciskiem Save.

E-mail i SNMP to oddzielne kanały powiadamiania. Aby wysyłać pułapki, należy dodatkowo skonfigurować agenta SNMP oraz odpowiednie społeczności lub użytkowników w Administration > SNMP. Następnie na Notification list włączyć globalny przełącznik SNMP traps oraz dostępne pola wyboru zdarzeń dla SNMP i zapisać ustawienia. Wybór powiadomień e-mail nie włącza pułapek; dla każdego zdarzenia można wybrać e-mail, SNMP lub oba dostępne kanały. Konfigurację i sprawdzanie menedżera SNMP opisuje podlinkowany poniżej artykuł o SNMP.

Nie każdy firewall wymaga takiego samego wyboru. Rozsądny zestaw podstawowy powinien odpowiadać ryzykom i faktycznie używanym funkcjom:

Admin: nieudane logowania i zbyt wiele nieudanych prób logowania.
HA: odłączone monitorowane porty lub interfejsy, jeśli działa klaster HA.
Disk/Memory: ostrzeżenia o miejscu, aby zapełniony obszar raportów lub systemu nie został zauważony dopiero podczas okna serwisowego. Progi i konsekwencje wyjaśnia artykuł Sprawdzanie pamięci i raportów na Sophos Firewall.
Firmware: nowe wersje firmware gotowe do instalacji, pomyślnie zainstalowane firmware i nieudane instalacje, zgodnie z własnym procesem aktualizacji.
Tylko SFOS 23 – Firmware > Security updates: W System services > Notification list włączyć kolumnę Email dla Security updates. Nadal wymagane są globalny przełącznik Email notifications i działająca ścieżka SMTP. Powiadomienia SNMP nie są dostępne dla aktualizacji zabezpieczeń w postaci hotfixów; ograniczenie to nie dotyczy ogólnie wszystkich hotfixów ani wszystkich zdarzeń firmware. Natychmiastowe dostarczenie nie jest gwarantowane, a brak wiadomości nie dowodzi ani powodzenia, ani niepowodzenia. Zastosowane aktualizacje sprawdzić zgodnie z procedurą weryfikacji hotfixów w SFOS 23.
System: nieudane aktualizacje bazy danych WebCat, sygnatur IPS i definicji antywirusowych, uruchomienie lub ponowne uruchomienie systemu, wysokie obciążenie CPU i Gateway status.
IPS: można wybrać poziomy Critical, Major, Moderate, Minor i Warning. Alert wymaga zarejestrowania zdarzenia IPS przez firewall i odrzucenia pakietu. Na początek odpowiednie są zdarzenia krytyczne z określonym procesem triage.
Active threat response: zdarzenia Log i Drop dla MDR, NDR Essentials, Sophos X-Ops oraz źródeł danych o zagrożeniach innych dostawców wybiera się oddzielnie. Typy dopasowań i ograniczenia opisano w następnej sekcji.
RED: utrata połączenia, nieudana aktualizacja firmware, automatyczne cofnięcie autoryzacji urządzenia lub nowy Unlock Code. AP: punkt dostępowy offline lub nieudana aktualizacja firmware. Należy wybierać tylko powiadomienia dotyczące faktycznie używanych urządzeń i wyznaczyć odpowiedzialnego odbiorcę.
VPN: stan up lub down tunelu IPsec, failover/failback oraz zestawione lub rozłączone połączenia SSL VPN. Opisane poniżej warunki wyzwalania dla IPsec są węższe niż ta ogólna lista; wybór zdarzeń nie gwarantuje powiadomienia o każdej ręcznej zmianie stanu tunelu.
Virus: wybierać alerty dla HTTP, FTP, SMTP, POP3 i IMAP4 zgodnie z faktycznie używanymi funkcjami ochrony. Pole wyboru nie zastępuje odpowiedniego skanowania ani wykrywania zdarzeń.
Web - Instant alerts: świadomie wybrane kategorie internetowe. Powiadomienia te są wysyłane w stałych, niezmiennych pięciominutowych pakietach i wymagają oddzielnej aktywacji kategorii zgodnie z opisem w artykule Web Categories i Instant Alerts.

Aktywowanie wszystkich zdarzeń bez wyjątku szybko powoduje zmęczenie alarmami. Szczególnie powiadomienia VPN mogą być powtarzane mniej więcej co 60 sekund do czasu usunięcia przyczyny; przy wielu sieciach lokalnych i zdalnych może również powstać jedna wiadomość na każdą parę podsieci. Lepszy jest mały wybór z jasno określoną reakcją: kto otrzyma alert, jak pilny on jest i jaki powinien być pierwszy krok kontrolny?

Niektóre Default Notifications firewall wysyła automatycznie i nie pozwala ich wyłączyć: zmiany ról HA z Standalone, Primary lub Auxiliary, stan urządzenia HA faulty, stan hostów wirtualnych up/down oraz ponowne uruchomienie lub wyłączenie przez WebAdmin. Również dla tych wiadomości skonfigurowany tor pocztowy musi być osiągalny. Kategoria zdarzeń, której nie można wyłączyć, nie gwarantuje dostarczenia wiadomości do nieosiągalnej skrzynki.

Active threat response: rozróżnienie dopasowania i kanału

Dla każdego z poniższych typów dopasowań dostępne są Log event i Drop event:

Destination match for all traffic: adres docelowy odpowiada wpisowi w źródle danych o zagrożeniach.
Remote source match for inbound traffic: zdalny adres źródłowy ruchu przychodzącego odpowiada wpisowi.
Local source match for outbound traffic: lokalny adres źródłowy ruchu wychodzącego odpowiada wpisowi.

Sam alert Log nie potwierdza zablokowania ruchu. Z kolei zdarzenie Drop zależy od rzeczywistego dopasowania i odpowiedniej konfiguracji Active threat response; pole wyboru e-mail nie powoduje dopasowania ani nie tworzy nowej reguły ochrony.

Pomoc Sophos dotycząca powiadomień określa dopasowania lokalnych i zdalnych adresów źródłowych dla Sophos X-Ops jako nieobsługiwane. Istnieje jednak opisany w artykule NDR/ATR konflikt z macierzą ruchu SVG, szczególnie w przypadku dopasowania lokalnego adresu źródłowego. Opcja e-mail nie potwierdza więc ani określonego działania dopasowań X-Ops, ani rozstrzygnięcia tej sprzeczności; sporne przypadki należy wyjaśnić oddzielnie przed uwzględnieniem ich jako wymogu ochrony. Alerty Remote source match nie są przekazywane do centralnej usługi Sophos, ale ich logi są widoczne w Central Firewall Reporting (CFR). Nazwa centralnej usługi różni się między wersjami (Sophos Central lub Sophos Fusion); nie oznacza to rozszerzenia zakresu przekazywania alertów. Dlatego dla tych zdarzeń należy sprawdzić lokalny tor powiadomień e-mail i logów, zamiast polegać wyłącznie na centralnym widoku alertów.

Warunki wyzwalania i powtarzanie powiadomień

Zaznaczone pole nie oznacza, że każda krótka zmiana stanu wygeneruje e-mail. W SFOS 22.0 i 23.0 następujące zdarzenia mają te warunki:

Admin: Sign-in failed obejmuje nieprawidłowe dane logowania lub nieprawidłowe OTP (hasło jednorazowe). Too many failed sign-in attempts jest wyzwalane po osiągnięciu liczby nieudanych prób skonfigurowanej w Administration > Admin and user settings > Login security. Ten próg wyjaśnia alert; nie jest instrukcją celowego blokowania konta.
High CPU usage: Pierwszy wpis w logu powiadomień powstaje dopiero wtedy, gdy użycie CPU osiągnie 95% i utrzyma się nieprzerwanie na poziomie co najmniej 95% przez minimum 25 minut. Kolejne wpisy powstają co 25 minut, aż użycie spadnie poniżej 95%. Krótki skok CPU bez e-maila o zdarzeniu nie dowodzi więc błędu SMTP.
Gateway status: Wybór tego zdarzenia jest domyślnie włączony. Wysyłanie nadal wymaga aktywnego, oddzielnego przełącznika globalnego Email notifications.

W przypadku zdarzeń dyskowych użycie musi nieprzerwanie utrzymywać się na odpowiednim progu lub powyżej przez co najmniej 50 sekund. Następnie logi i powiadomienia są powtarzane z poniższą domyślną częstotliwością, aż użycie spadnie poniżej progu:

Obszar	Próg powiadomienia	Powtarzanie
Przestrzeń konfiguracji	≥80%	co 50 sekund
Przestrzeń sygnatur	≥90%	co 50 sekund
`/var`	≥80%	co 12 godzin

Dla /var niższy próg generuje już logi; powiadomienia zaczynają się dopiero przy wyższym progu 80%. Jeśli użycie przekroczy wyższy próg, a następnie spadnie poniżej niższego, powrót do normy zostanie zapisany w logu, ale nie zostanie wysłane powiadomienie o przywróceniu. Należy to odróżnić od ostrzeżeń i zatrzymania raportowania opisanych w podlinkowanym wyżej artykule o przestrzeni dyskowej; brak e-maila o przywróceniu nie jest tu błędem dostarczenia.

Dla IPsec udokumentowany zakres jest węższy niż dowolna zmiana Up/Down VPN: powiadomienia dotyczą wyłącznie tuneli host-to-host i site-to-site z opisanymi warunkami rozłączenia:

Dead peer detection (DPD).
Nieudane ponowne zestawienie połączenia po DPD.
IPsec Security Association (SA) wygasła i musi zostać ponownie zestawiona.
Ta lista obejmuje również ponowne zestawienie tunelu po utracie łączności bez interwencji administratora.

Jeśli w ustawieniach połączenia IPsec skonfigurowano opis, powiadomienie również go zawiera. Nie gwarantuje to powiadomień dla każdego ręcznego rozłączenia ani dla tuneli zdalnego dostępu lub SSL VPN.

Czasy CPU opisują generowanie logów powiadomień, a interwały dyskowe udokumentowane powtarzanie, nie gwarantowany czas dotarcia do skrzynki. Gdy brakuje e-maila, najpierw należy porównać warunek zdarzenia, czas wpisu w logu i śledzenie na serwerze pocztowym. Nie należy celowo przeciążać CPU lub dysku, powodować blokad logowania, przerw HA ani awarii produkcyjnego VPN wyłącznie w celu testu alertu.

Test wiadomości i rzeczywistego zdarzenia

Kontrola składa się z dwóch etapów.

1. Potwierdzenie dostarczenia SMTP wiadomością testową

Najpierw należy sprawdzić konfigurację poczty zapisaną w Administration > Notification settings i uruchomić funkcję wiadomości testowej dostępną w używanym buildzie SFOS. Ścieżka testu raportu to Reports > Show report settings > Report scheduling: wybrać raport, otworzyć Send test mail, wprowadzić adres odbiorcy testowego i kliknąć Send. Ten test raportu sprawdza transport poczty, a nie wybór zdarzeń; jego odbiorca nie jest automatycznie zapisanym odbiorcą alertów systemowych. Komunikat firewalla o powodzeniu nie wystarczy: w docelowej skrzynce, filtrze spamu lub systemie śledzenia serwera pocztowego musi być widoczne, że wiadomość została rzeczywiście przyjęta i dostarczona. Treść raportu i harmonogram należy sprawdzić oddzielnie, zgodnie z opisem w podlinkowanym poniżej artykule o raportach.

Należy przy tym sprawdzić:

Nadawca i odbiorca są prawidłowi.
Oczekiwany firewall można rozpoznać na podstawie tematu, treści lub adresu IP do zarządzania.
Wiadomość nie trafia na stałe do spamu ani kwarantanny.
Lista dystrybucyjna przyjmuje wiadomości od skonfigurowanego nadawcy.

2. Test pełnego łańcucha zdarzenia

Następnie należy w kontrolowany sposób wywołać wybrane zdarzenie. Odpowiednie przykłady to:

pojedyncze nieudane logowanie przy użyciu konta testowego, po sprawdzeniu blokad i progów logowania;
udokumentowane zdarzenie VPN na tunelu testowym wyraźnie przeznaczonym do tego celu, pod warunkiem że typ tunelu i warunek wyzwalania odpowiadają wybranemu powiadomieniu; sama ręczna zmiana stanu Up/Down tunelu IPsec nie jest wiarygodnym testem alertu;
Gateway status podczas zaplanowanego testu przełączania WAN.

Ponowne uruchamianie lub odłączanie produkcyjnej bramy, portu HA albo samego firewalla wyłącznie w celu testu wiadomości e-mail byłoby nieproporcjonalne. Lepszym testem jest już zaplanowany scenariusz konserwacji lub przełączania awaryjnego.

Dopiero gdy zdarzenie dotrze w oczekiwanym czasie do właściwego odbiorcy, potwierdzony jest cały łańcuch: wykrycie zdarzenia, wybór zdarzenia, globalny przełącznik poczty, transport SMTP i dostarczenie.

Systematyczne zawężanie błędów

Już wysłanie wiadomości testowej kończy się niepowodzeniem

API SFOS 22 rozróżnia kilka klas błędów:

Failed to connect lub SMTP server failed to respond: sprawdź rozwiązywanie FQDN, trasę, port, poprzedzający firewall i listener serwera pocztowego.
Password mismatch: sprawdź nazwę użytkownika, wielkość liter, hasło i ewentualnie zablokowane konto.
Authentication method mismatch: sprawdź, czy przekaźnik i SFOS wspólnie obsługują LOGIN lub PLAIN dla Basic Authentication.
STARTTLS not supported: port i Connection security nie pasują do listenera serwera.
Mail server refused to communicate: sprawdź zezwolenie przekaźnika, adres nadawcy, dozwolony źródłowy adres IP i logi serwera pocztowego.
Couldn’t generate the OAuth 2.0 access token: sprawdź Provider, Client ID, Secret, Refresh Token, uprawnienia i czas systemowy.

Z systemu administracyjnego korzystającego z porównywalnej trasy sieciowej można wstępnie sprawdzić DNS i STARTTLS bez zmian na serwerze pocztowym:

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

Zastąp smtp.example.net i 587 własnym serwerem i portem. nslookup potwierdza jedynie rozwiązywanie nazw w systemie administracyjnym. openssl s_client pokazuje osiągalność SMTP, uzgadnianie TLS i łańcuch certyfikatów, ale nie sprawdza ani trasy z perspektywy firewalla, ani jego logowania lub późniejszego dostarczenia.

W Log Viewer, a przy głębszej analizie również w cschelper.log, można skorelować czas testu z wiadomością e-mail wygenerowaną przez system. Dostęp do logów usług i rozróżnienie względem Advanced Shell opisano w artykule Usługi i logi Sophos Firewall. Logi MTA, takie jak smtpd_main.log, należą przede wszystkim do Mail Protection i nie są ogólnym logiem Notifications.

Wiadomość testowa dociera, ale brakuje powiadomień o zdarzeniach

W takim przypadku transport działa, a poszukiwania rozpoczynają się w sekcji System services > Notification list:

Czy Email notifications jest aktywne globalnie?
Czy konkretne zdarzenie jest wybrane w kolumnie Email?
Czy oczekiwane zdarzenie rzeczywiście wystąpiło i należy do właściwej kategorii?
Czy występuje znane opóźnienie lub grupowanie, na przykład w przypadku Web Instant Alerts?
Czy filtr spamu, kwarantanna lub system śledzenia serwera pocztowego pokazują przyjęcie albo odrzucenie?

W przypadku pojedynczego zdarzenia specjalnego należy dodatkowo sprawdzić warunek merytoryczny. Przykładowo alert IPS nie powstaje wyłącznie wskutek zaznaczenia pola, lecz dopiero wtedy, gdy odpowiednia reguła IPS zarejestruje zdarzenie i odrzuci pakiet. Powiadomienie VPN zależy od typu tunelu oraz jego rzeczywistego stanu Up/Down.

Gmail OAuth przestaje działać po zmianie hasła

W opisanej tutaj procedurze powiadomień Gmail z zakresem https://mail.google.com Refresh Token staje się nieważny, gdy zostanie zmienione hasło używanego konta Gmail do wysyłania. Firewall nie może wtedy uzyskać nowego Access Token za pomocą tego tokenu. Nie dotyczy to wszystkich tokenów OAuth Google ani Microsoft 365.

Sprawdzić, czy zmieniono hasło właśnie tego konta wysyłającego. Porównać klienta OAuth, konto, zatwierdzone uprawnienia i Publishing status: In production z udokumentowaną konfiguracją. Również token utworzony przed Publish App nie stanowi trwałej podstawy po siedmiu dniach; obie przyczyny należy sprawdzić oddzielnie.
Korzystając z aktualnego dostępu do konta i danych uwierzytelniających własnego klienta OAuth, ponownie przeprowadzić autoryzację Gmail i wymianę tokenów zgodnie z opisaną wyżej procedurą Playground. Przed udzieleniem zgody sprawdzić aplikację i żądane uprawnienia, a nowy Refresh Token bezpiecznie zapisać.
W Administration > Notification settings przy Provider: Gmail zastąpić nieważny Refresh token nowym i zapisać ustawienia. Client ID i Client secret muszą odpowiadać użytemu klientowi OAuth; bez powodu nie zmieniać ustawień SMTP, TLS, nadawcy, odbiorcy ani zdarzeń.
Wysłać wiadomość testową i potwierdzić jej rzeczywiste dostarczenie w docelowej skrzynce lub systemie śledzenia serwera pocztowego. Następnie sprawdzić wybrane zdarzenie wywołane w kontrolowany sposób, zgodnie z sekcją dotyczącą pełnego łańcucha zdarzenia.

Ponowne wprowadzenie starego tokenu nie przywraca jego ważności. Nie resetować hasła konta wyłącznie po to, aby odtworzyć poprzedni tor pocztowy. Jeśli wysyłanie nadal nie działa po ponownej autoryzacji, zapisać dokładny komunikat błędu, build SFOS i konfigurację dostawcy, bez sekretów ani tokenów, do dalszej analizy. Do czasu potwierdzenia przywrócenia działania korzystać z zatwierdzonego alternatywnego toru alarmowania lub udokumentowanego przekaźnika SMTP.

Microsoft 365 OAuth zapisuje się, ale nie wysyła

Najpierw porównaj wersję i build SFOS z NC-166854. Następnie sprawdź Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP dla konta wysyłającego oraz prawidłowy czas systemowy.

Jeśli wiadomość testowa nadal nie działa w buildzie, który nie jest wymieniony jako dotknięty, nie oznacza to automatycznie tego samego błędu. Dokładny komunikat, build SFOS i logi logowania dostawcy należy wtedy uwzględnić w dalszej analizie lub zgłoszeniu do pomocy technicznej.

Utrzymanie powiadomień

Jeśli po zmianie dostarczanie nie działa, należy najpierw przywrócić zapisaną konfigurację poczty: opcję serwera, serwer, port, Authentication, Connection security, nadawcę, odbiorcę i interfejs zarządzający, a także poprzedni wybór certyfikatu, jeśli został zmieniony. Wybór zdarzeń powinien pozostać bez zmian, jeśli nie był częścią modyfikacji. Po zapisaniu trzeba ponownie potwierdzić poprzedni tor alarmowania wiadomością testową oraz wybranym zdarzeniem wywołanym w kontrolowany sposób. Przywracanie jest zakończone dopiero wtedy, gdy obie wiadomości rzeczywiście dotrą.

Utrzymuj odbiorcę jako funkcjonalną listę dystrybucyjną z przypisanym właścicielem.
Po zmianach serwera pocztowego, DNS, routingu, certyfikatu, danych dostępowych, aplikacji OAuth lub firmware ponownie sprawdź wiadomość testową i rzeczywiste zdarzenie.
Testuj cały tor alarmowania co najmniej raz na kwartał, jeśli nie jest stale monitorowany przez centralny system.
Dokumentuj wygaśnięcie i rotację haseł, Client Secrets i Tokens.
Regularnie dostosowuj wybór zdarzeń do nowych funkcji i wyłączonych usług.
Dla każdego ważnego alertu określ pierwszy krok kontrolny i ścieżkę eskalacji.

Codzienna lista administratora Sophos Firewall zbiera sygnały stanu, bezpieczeństwa i administracyjne, które należy dodatkowo aktywnie kontrolować podczas eksploatacji.

E-mail jest dobrym bezpośrednim kanałem alarmowania, ale nie zastępuje centralnego przechowywania ani korelacji logów. Do dłuższej historii i analizy bezpieczeństwa nadaje się artykuł Wysyłanie Syslog z Sophos Firewall do SIEM. W zakresie klasycznego monitorowania stanu i pułapek odpowiednim uzupełnieniem jest Monitorowanie sprzętu przez SNMP.

Do analiz PDF wysyłanych codziennie lub co tydzień nie używa się Notification list, lecz oddzielnego harmonogramu raportu. Artykuł Planowanie i wysyłanie raportów Sophos Firewall e-mailem wyjaśnia wybór raportu, bookmark, test transportu i kontrolę treści.

Zmiana adresu odbiorcy przez CLI Main Menu > 2. System Configuration