Przejdz do tresci
Avanet

Konfiguracja i test powiadomień e-mail Sophos Firewall

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.

Szybka procedura:

  1. Skonfiguruj serwer pocztowy, port, uwierzytelnianie, szyfrowanie, nadawcę i odbiorcę w sekcji Administration > Notification settings.
  2. Wyślij wiadomość testową i potwierdź jej dostarczenie w docelowej skrzynce lub systemie śledzenia serwera pocztowego.
  3. W sekcji System services > Notification list aktywuj globalny przełącznik Email notifications.
  4. Wybierz tylko te zdarzenia, na które odpowiedzialny odbiorca może zareagować.
  5. 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.

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.

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.

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:

  1. W sekcji Administration > Notification settings aktywuj Built-in email server.
  2. Wprowadź nadawcę, odbiorcę i opcjonalnie Management interface IP address.
  3. 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

  1. Otwórz Administration > Notification settings.
  2. Wybierz External email server.
  3. Wprowadź adres IPv4 lub FQDN serwera pocztowego oraz wskazany port.
  4. W sekcji Authentication wybierz odpowiednio do serwera None, Basic albo OAuth 2.0.
  5. W sekcji Connection security ustaw szyfrowanie transportu wymagane przez serwer pocztowy.
  6. Wprowadź nadawcę, odbiorcę i opcjonalnie Management interface IP address.
  7. 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. Według Sophos nazwa użytkownika rozróżnia 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.

Jeśli firewall korzysta z Mail Protection w MTA Mode, certyfikat używany do wysyłania poczty zależy dodatkowo od konfiguracji w sekcji Email > General settings. Dlatego nie należy wprowadzać takiej zmiany w oderwaniu od produkcyjnego przepływu poczty.

Gmail i Microsoft 365 z OAuth 2.0

W przypadku Gmaila i Microsoft 365 aktualna pomoc SFOS 22 wymaga OAuth 2.0. W tym celu w sekcji Notification settings wprowadza się Provider, Client ID, Client secret i Refresh token. Ogólna pomoc Sophos określa Client secret dla Microsoft 365 jako opcjonalny, jednak udokumentowana przez Sophos procedura Microsoft 365 wyraźnie go tworzy i używa. 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. Aktualne kroki Sophos opisuje na stronie Configure OAuth 2.0 on Gmail.

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 przez Sophos 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. Aktualne kroki w Entra opisano na stronie Configure OAuth 2.0 on Microsoft 365.

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.

⚠️ Sophos nadal wymienia NC-166854 w aktualnej Known Issues list: OAuth Microsoft 365 dla Notifications nie działa w podanych tam buildach 22.0.0.274, 22.0.0.323, 21.0.2.349 i 21.5.1.261. Nie wskazano wersji z poprawką. Dlatego należy sprawdzić dokładny build SFOS i 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.

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, a przede wszystkim nieudane instalacje, zgodnie z własnym procesem aktualizacji.
  • System: nieudane aktualizacje sygnatur lub baz danych, uruchomienie systemu, wysokie obciążenie CPU i Gateway status.
  • IPS i Active threat response: na początku zdarzenia krytyczne lub blokujące, jeśli istnieje dla nich proces triage.
  • RED, AP i VPN: tylko dla faktycznie używanych urządzeń i ważnych połączeń.
  • Web - Instant alerts: świadomie wybrane kategorie internetowe. Powiadomienia te są wysyłane w 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ć. Należą do nich określone zmiany roli i stanu HA, stan hostów wirtualnych oraz ponowne uruchomienie lub wyłączenie przez WebAdmin. Również dla tych wiadomości skonfigurowany tor pocztowy musi być osiągalny.

Test wiadomości i rzeczywistego zdarzenia

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

1. Potwierdzenie dostarczenia SMTP wiadomością testową

Wyślij wiadomość testową w sekcji Administration > Notification settings. 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.

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;
  • zmiana Up/Down tunelu testowego VPN przeznaczonego specjalnie do tego celu;
  • 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

Wiadomość testowa już się nie udaje

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:

  1. Czy Email notifications jest aktywne globalnie?
  2. Czy konkretne zdarzenie jest wybrane w kolumnie Email?
  3. Czy oczekiwane zdarzenie rzeczywiście wystąpiło i należy do właściwej kategorii?
  4. Czy występuje znane opóźnienie lub grupowanie, na przykład w przypadku Web Instant Alerts?
  5. 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 i odrzuci zdarzenie. Powiadomienie VPN zależy od typu tunelu oraz jego rzeczywistego stanu Up/Down.

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ń

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

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. Klasyczne monitorowanie stanu i pułapek uzupełnia Monitorowanie sprzętu przez SNMP.