Konfiguracja Sophos Firewall Mail Protection w MTA Mode

W MTA mode Sophos Firewall samodzielnie odbiera wiadomości, skanuje je i dostarcza do wewnętrznego serwera poczty lub kolejnego mail hop. Przepływ działa tylko wtedy, gdy rekord MX, automatyczna reguła MTA, SMTP route and scan Policy, relay, TLS i weryfikacja odbiorców są ze sobą zgodne.

Konfiguracja składa się z sześciu kroków: określenia przepływu i ścieżki awaryjnej, włączenia MTA mode, dodania domeny, utworzenia route and scan Policy, zabezpieczenia relay oraz zmiany rekordu MX. Następnie należy zweryfikować pocztę przychodzącą i wychodzącą za pomocą poleceń zewnętrznych, kwarantanny, spool i logów.

Kiedy warto użyć MTA mode

Mail Protection na zaporze sprawdza się głównie w świadomie zaprojektowanych środowiskach on-premises i hybrydowych, w których trzeba chronić lokalny Exchange lub inny serwer poczty. Dla Microsoft 365, Google Workspace i wielu środowisk wyłącznie chmurowych Sophos Email albo inna chmurowa brama pocztowa jest zwykle czytelniejszą architekturą. Dwie bramy w szeregu komplikują kwarantannę, nagłówki, TLS, SPF/DKIM/DMARC i diagnostykę.

Jeśli Exchange Online ma świadomie korzystać z MTA firewalla, Konfiguracja Sophos Firewall MTA z Microsoft 365 opisuje pełną ścieżkę EOP, relay, łącznik, MX i SPF.

Należy rozróżnić trzy funkcje Sophos Firewall:

• MTA mode: zapora odbiera, skanuje i routuje pocztę.
• Legacy mode: przezroczyste przetwarzanie proxy istniejącej ścieżki SMTP. Konfiguracja Mail Protection w Legacy mode opisuje NAT, reguły, polityki skanowania i weryfikację.
• SMTP Relay w Device Access: określa strefy, z których MTA jest osiągalny. Poczta przychodząca z Internetu wymaga WAN; relay wychodzący ogranicza się dodatkowo do konkretnych serwerów wewnętrznych.

Pobieranie istniejących wiadomości ze skrzynki przez POP3 lub IMAP jest osobnym zadaniem. Skanowanie i testowanie POP3 oraz IMAP na Sophos Firewall opisuje zaufanie TLS, opcjonalną politykę, regułę zapory i test odbiorczy.

Wymagane są ważna licencja Email Protection, działający routing i DNS, znany publiczny adres IP, wewnętrzny serwer z portem docelowym oraz zaplanowane strategie TLS, kwarantanny i wycofania zmiany. Według aktualnego zestawienia Sophos MTA mode nie jest dostępny na XGS 87/87w ani XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation i SXL2 Live Protection wymagają dostępu do Internetu. Routing poczty, skanowanie malware, filtrowanie MIME i SPX mogą nadal działać z odpowiednią licencją w środowisku airgap, ale aktywny MTA nie oznacza dostępności wszystkich kontroli ochronnych.

Kompleksowa konfiguracja MTA mode

1. Określenie przepływu i ścieżki awaryjnej

Dla poczty przychodzącej publiczny rekord MX wskazuje adres, na którym Sophos Firewall przyjmuje TCP 25. Zapora skanuje wiadomość i dostarcza ją do serwera wewnętrznego. Stara reguła DNAT nie może pozostawiać tego serwera bezpośrednio osiągalnego z Internetu bez kontroli, ponieważ pozwoliłoby to ominąć MTA. Publikowanie serwera przez DNAT wyjaśnia ogólną logikę DNAT.

Dla poczty wychodzącej tylko przewidziany serwer wysyła przez zaporę. Ścieżka, smarthost, PTR/rDNS, HELO, SPF, DKIM i DMARC muszą odpowiadać publicznej tożsamości nadawcy. Ogólna reguła LAN to WAN jest zbyt szeroka; baza reguł powinna jednoznacznie wskazywać dozwolonego nadawcę SMTP. Zasady Sophos Firewall opisują kolejność reguł.

Przed migracją należy udokumentować:

• bieżący rekord MX, priorytet i TTL;
• nowy publiczny adres zapory i wewnętrzny serwer docelowy;
• istniejące reguły DNAT i SMTP oraz konektory serwera;
• nadawców testowych dla obu kierunków;
• poprzedni MX lub ścieżkę poczty jako fallback;
• monitoring kolejki serwera, spool zapory i kwarantanny.

TTL należy obniżyć z wyprzedzeniem, jeśli może być potrzebne szybkie wycofanie. Zmiany produkcyjnego MX wykonuje się w oknie serwisowym.

2. Konfiguracja MTA mode i podstawowych ustawień SMTP

W Email > General settings wybrać w razie potrzeby Switch to MTA mode. Sophos Firewall tworzy regułę Any-to-Any Auto added firewall policy for MTA dla SMTP i SMTPS. Nie wolno jej edytować i powinna pozostać na początku listy. Przejście do Legacy mode usuwa ją, a powrót tworzy ponownie.

Następnie ustawić:

1. W SMTP hostname wpisać nazwę domeny, na przykład example.com, a nie hostname serwera wewnętrznego. Wartość pojawia się w HELO i bannerze SMTP powiadomień systemowych.

   Sprawdzić odpowiedź API XML: Dokumentacja SFOS 23 podaje status 506 z Message.AVGeneralConfInvalidSmtpNtfyHostname dla operacji Email Configuration w API XML. Jest to status operacji, a nie kod statusu HTTP. Klucz nie został rozwinięty do treści komunikatu i nie jest angielskim komunikatem błędu; nie pozwala ustalić konkretnych reguł walidacji. Jeśli pojawi się taka odpowiedź, sprawdzić przesłaną wartość nazwy hosta dla powiadomień, rzeczywistą odpowiedź operacji i zapisaną konfigurację przed uznaniem zmiany za udaną. Dodatkowy wiersz w dokumentacji nie dowodzi, że takie zachowanie podczas działania wprowadzono po raz pierwszy w SFOS 23.

2. Włączyć Reject based on IP reputation, aby odrzucać nadawców o złej reputacji.

3. W SMTP TLS configuration wybrać publicznie zaufany certyfikat, a Allow invalid certificate dopuszczać tylko dla udokumentowanych wyjątków.

4. Włączyć Disable legacy TLS protocols, o ile udokumentowane stare systemy tego nie wykluczają. Opcja wyłącza protokoły starsze niż TLS 1.1, lecz nie wymusza wyłącznie aktualnych wersji TLS.

5. Włączyć Scan outgoing mails, jeśli wiadomości wychodzące także mają być skanowane.

Z Require TLS negotiation należy postępować ostrożnie: jeśli SFOS nie zestawi wymaganego TLS, usuwa pocztę do danego celu lub z określonej domeny nadawcy. Pomoc SFOS 22/23 ostrzega, że połączenie i weryfikacja SMTP TLS używają adresu IP domeny zamiast jej nazwy; wiele domen na jednym IP może więc powodować błędy certyfikatu. To ostrzeżenie dokumentacji, a nie dowód algorytmu dopasowywania certyfikatów we wdrożonym buildzie.

Skip TLS negotiation wybiera zdalne hosty pocztowe lub sieci dla nieszyfrowanych połączeń SMTP; udokumentowany limit to 512 wpisów hostów. Nie jest to rozwiązanie problemu błędnego certyfikatu. Allow invalid certificate jest wyjątkiem od weryfikacji partnera TLS, a nie przejściem na tekst jawny. Nie zakładać pierwszeństwa przy nakładaniu się list Require i Skip ani przejścia na tekst jawny po niepowodzeniu wymaganego TLS. Wyjątki ograniczać i dokumentować, a przed ich zmianą sprawdzić rzeczywisty wynik połączenia i weryfikacji certyfikatu we wdrożonym buildzie.

Ustalenie globalnych limitów SMTP przed politykami

Ustawienia w Email > General settings dotyczą wszystkich wiadomości i są przetwarzane przed politykami SMTP oraz POP-IMAP. Reject based on IP reputation nie jest więc akcją pojedynczej polityki: SFOS sprawdza adres IP nadawcy przed kontrolami spamu polityki SMTP. Blocked senders również działa globalnie, ale blokuje tylko pocztę przychodzącą.

W SMTP settings opcja Don’t scan emails greater than określa maksymalny rozmiar wiadomości dla globalnego skanowania SMTP. 0 oznacza 51,200 KB, a nie brak limitu. Dla większych wiadomości dostępne są Accept, Reject i Drop. Accept dostarcza bez skanowania, Reject odrzuca i informuje nadawcę, a Drop usuwa bez powiadomienia. Wybór należy udokumentować jako świadomą lukę w skanowaniu lub decyzję o dostarczeniu oraz przetestować wiadomością tuż poniżej i powyżej limitu.

Ustawienia SMTP DoS settings ograniczają równoczesne połączenia, liczbę wiadomości na połączenie, odbiorców na wiadomość oraz tempo wiadomości i połączeń. SFOS ustala maksymalną liczbę połączeń na podstawie pamięci RAM i procesora. Udokumentowane wartości domyślne to 1000 wiadomości na połączenie i 100 odbiorców na wiadomość. Własne wartości należy wyprowadzić z rzeczywistego wolumenu poczty; zbyt niski limit może potraktować prawidłowe listy dystrybucyjne lub skanery jak atak.

W Advanced SMTP settings SFOS może odrzucać nieprawidłowe HELO lub brak RDNS, a po włączeniu Do strict RDNS checks nazwę hosta, która nie rozwiązuje się z powrotem do źródłowego adresu IP. Tych kontroli nie należy wprowadzać równocześnie z szerokim wyjątkiem. Najpierw trzeba zarejestrować w logu rzeczywiste ścieżki partnerów, newsletterów i aplikacji, a następnie przetestować je osobno.

Banner wychodzący może używać Inline, no conversion, opcji MIME part albo Off. Skanowanie SMTP lub SMTPS musi być aktywne w pasującej regule zapory. Ponieważ banner zmienia body i może unieważnić istniejący podpis DKIM, podpis należy dodać po tej zmianie albo wyraźnie potwierdzić u odbiorcy, że planowany podpis pozostaje prawidłowy.

3. Dodanie domeny jako Address Group

1. Otworzyć Email > Address group > Add.
2. Ustawić Group type na Email address/domain, a Type na Manual.
3. Dodać chronioną domenę, na przykład example.com.
4. Zapisać grupę.

Podczas tworzenia grupy przed zapisaniem podać także czytelną Name. Istniejącą grupę edytować przez Edit w Email > Address group; import pliku rozpocząć przez Import. RBL (IPv4) przyjmuje adresy IPv4, a RBL (IPv6) adresy IPv6. Email address/domain obsługuje wpisy ręczne albo import CSV/tekstu. Dopasowanie RBL używa IP nawiązującego połączenie i akcji wskazanej w policy SMTP; nadal obowiązuje osobno udokumentowane odrzucanie SPF/RBL. Zachować domyślne nazwy Premium RBL services i Standard RBL services, chyba że wyraźnie zaplanowana zmiana wymaga inaczej.

Address Groups nie ograniczają się do domen pocztowych. Group type może mieć wartość Email address/domain, RBL IPv4 albo RBL IPv6. Ten sam adres może należeć do kilku grup, co pozwala tworzyć oddzielne cele policy bez kopiowania lub zmiany nazwy wpisu.

W przypadku większych list SFOS może zaimportować plik CSV lub tekstowy zawierający maksymalnie 400 adresów albo domen. Nieprawidłowe i zduplikowane wpisy są pomijane. Po imporcie należy sprawdzić liczbę wpisów i kilka przykładów, zanim grupa zostanie przypisana do policy produkcyjnej.

Nowe SMTP route and scan Policies planuje się dla domen, nie pojedynczych adresów odbiorców. Zmigrowane pojedyncze adresy mogą nadal działać, ale nie można ich dodawać ani edytować w aktualnych zasadach.

4. Utworzenie SMTP route and scan Policy

Otworzyć Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Nadać czytelną nazwę, na przykład Inbound example.com to Exchange.
2. W Protected domain wybrać Address Group.
3. Wybrać Route by:
   • Static host: stały adres IP serwera; przy awarii zapora próbuje kolejnego hosta z listy.
   • DNS host: nazwa DNS, na przykład mailserver.example.com; wiele rekordów A jest używanych między dostawami, a niedostępne serwery są pomijane.
   • MX: dostawa na podstawie rekordu MX.
4. Dla Static host wybrać serwer w Host list. W razie potrzeby utworzyć IP host w Hosts and services > IP host.
5. Ustawić Global action na Accept dla świadomie chronionych domen. Reject odrzuciłoby wszystkie wiadomości przychodzące i wychodzące związane z tymi domenami i powiadomiło nadawcę.
6. Włączyć Spam protection i Malware protection zgodnie z założeniami operacyjnymi.
7. File protection i Data protection włączyć dopiero po poznaniu wpływu na załączniki, duże wiadomości, SPX i DKIM.
8. Zapisać zasadę.

Aby zmienić istniejącą politykę SMTP route and scan, w Email > Policies and exceptions wybrać Edit przy odpowiedniej polityce, zmienić wymagane ustawienia i zapisać politykę. Następnie ponownie sprawdzić dopasowanie polityki i dostarczenie za pomocą kontrolowanej wiadomości testowej.

Przy Route by MX rekord MX rozwiązany przez zaporę nie może wskazywać tej samej zapory, bo powstanie pętla routingu. Zapora musi poprawnie rozwiązywać cele wewnętrzne; przy split DNS pomagają DNS Request Routes.

Opcja Route inbound mail through gateway jest potrzebna tylko w szczególnych projektach, np. dla serwerów w strefie WAN, zastosowania pierwotnej reguły do celów LAN/DMZ lub wyboru konkretnej bramy przy wielu łączach. Nie należy jej włączać bez konkretnej potrzeby routingu.

5. Zabezpieczenie dostępu przychodzącego i relay wychodzącego

W Administration > Device access zezwolić na SMTP Relay ze wszystkich stref, które muszą osiągać MTA. Poczta z Internetu wymaga WAN; wychodząca dodatkowo strefy serwera wewnętrznego, zwykle LAN lub DMZ. Następnie w Email > Relay settings > Host-based relay ograniczyć dostęp do konkretnych serwerów, skanerów lub aplikacji.

Szerokie uprawnienia hostów lub sieci tworzą ryzyko open relay. Drukarki i aplikacje wysyłające pocztę należy dokumentować jako konkretne obiekty hostów. Zabezpieczanie dostępu do Sophos Firewall wyjaśnia Device Access.

Listy Allow i Block nie działają zgodnie z zasadą, że Block ma zawsze pierwszeństwo. Jeśli ten sam host lub sieć występuje na obu listach Host-based relay albo Upstream host, SFOS zezwala na relay. Przed aktywacją należy usunąć takie nakładanie i wykonać test negatywny ze źródła bez uprawnień.

Dozwolony host nie omija też skanowania poczty. Jeśli SFOS nie może przeskanować źródłowego adresu IP dopuszczonego do host-based relay, odrzuca go. Zezwolenie na relay nie potwierdza więc ani skutecznego skanowania treści, ani dostarczenia; oba elementy sprawdza się rzeczywistą wiadomością testową i logami MTA.

SMTP route and scan Policy nie obsługuje SMTP AUTH. Dla urządzeń niezawodną metodą jest więc Host-based relay. Istnieją osobne Authenticated relay settings dla użytkowników i grup, lecz według Sophos nie obsługują one zgodnego z RFC standardu SMTP Authentication, więc trzeba sprawdzić zgodność klienta. Czym innym jest logowanie zapory do upstream smarthost, gdzie SFOS obsługuje PLAIN i LOGIN. Jako smarthost nie wolno podawać adresu interfejsu tej samej zapory, ponieważ tworzy to pętlę routingu.

Wiele interfejsów WAN lub adresów IP aliasów

MTA sam tworzy wychodzące połączenie SMTP. Jeśli możliwych jest kilka publicznych adresów nadawcy, zwykła reguła klienta nie wystarczy. Sophos rozróżnia trzy przypadki: przy jednym interfejsie WAN i wielu adresach IP aliasów tworzy się regułę SNAT z wybranym publicznym Translated source. Przy wielu interfejsach WAN bez aliasu tworzy się trasę SD-WAN dla SMTP, SMTP(S) i SMTPS_465. Gdy występują zarówno liczne interfejsy WAN, jak i aliasy, łączy się SNAT z trasą SD-WAN.

Reguła SNAT pozostawia cel i usługę bez zmian, używa zaplanowanego łącza WAN jako interfejsu wyjściowego i tłumaczy na MASQ lub wybrany adres IP aliasu. Trasa SD-WAN używa grupy internetowej jako celu, trzech usług SMTP, planowanej bramy głównej i opcjonalnej bramy zapasowej. Brama zapasowa ma sens tylko wtedy, gdy rzeczywiście dopuszcza wychodzący TCP 25, a jej publiczny adres również uwzględniono w rekordzie SPF domeny pocztowej.

W tym oficjalnym przebiegu dla wielu łączy WAN Sophos wymaga kolejności static, vpn, sdwan_policyroute i włącza SD-WAN dla ruchu generowanego przez system. Polecenia należy wykonać w Device Console (opcja 4 menu CLI), nie w Advanced Shell. Najpierw odczytać obie wartości początkowe, wprowadzić zmiany, a następnie ponownie je sprawdzić:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

Kolejność tras działa globalnie i nie jest odizolowanym przełącznikiem poczty. Przed zmianą trzeba udokumentować wszystkie nakładające się ścieżki statyczne, VPN i SD-WAN oraz obie odczytane wartości. Przy wycofaniu należy odtworzyć pełną poprzednią kolejność za pomocą system route_precedence set ... i przywrócić system-generate-traffic do początkowego stanu enable albo disable. Następnie sprawdza się nie tylko liczniki SMTP, lecz także rzeczywiście użyty adres źródłowy, dostarczenie, wynik SPF i awarię bramy głównej. Sprawdzanie routingu SD-WAN dla ruchu generowanego przez system opisuje ogólną bezpieczną procedurę i wycofanie.

6. Zmiana rekordu MX

Publiczny MX zmienić na adres zapory dopiero po przygotowaniu reguły MTA, domeny, policy, relay i wewnętrznej ścieżki dostawy. Natychmiast wysłać zewnętrzną wiadomość testową i sprawdzić ją w Log Viewer lub Mail logs, na serwerze wewnętrznym i w skrzynce.

Jeśli zewnętrzni nadawcy nie osiągają zapory lub wiele prawidłowych wiadomości jest odrzucanych, przywrócić udokumentowaną poprzednią ścieżkę. Z powodu pamięci podręcznej DNS wycofanie nie zadziała natychmiast wszędzie. Dlatego starą i nową ścieżkę należy równolegle utrzymywać i monitorować co najmniej do czasu wygaśnięcia najdłuższego wcześniej obowiązującego TTL. Jeśli zapora przyjmuje, lecz nie dostarcza, najpierw sprawdzić routing, DNS, TLS, recipient verification i logi serwera.

Świadomy wybór ochrony

Korzystanie z własnych typów plików i Data Control Lists

W MTA mode własny typ pliku tworzy się w Email > Policies and exceptions > File type > Add na podstawie szablonu, rozszerzeń plików albo typów MIME. Rozszerzenia wpisuje się bez kropki na początku. Edytować można tylko własne typy. Nowy typ nie jest też automatycznie dodawany do istniejących policy: trzeba otworzyć konkretną SMTP route and scan Policy, dodać go w File protection i ponownie zapisać policy. Pozytywny test załącznika oraz podobny test negatywny potwierdzają dopasowanie lepiej niż sama nazwa obiektu.

W File protection > Block file types opcja All blokuje wiadomości z załącznikami; nie oznacza skanowania wszystkich załączników. None zezwala na załączniki w ramach tego filtra plików, ale nie omija kontroli malware, spamu, Data Protection ani innych kontroli. Pomoc policy podaje, że wybrane nagłówki MIME wypełniają MIME whitelist, zezwalając na te typy i blokując pozostałe. Nagłówki MIME i rozszerzenia nie dowodzą nieszkodliwej zawartości. Sprawdzić dozwolone i blokowane załączniki we wdrożonym buildzie przed zastosowaniem szczegółowej konfiguracji whitelist.

Data Control List składa się z Content Control Lists, czyli CCL, dla zdefiniowanych typów treści, takich jak dane finansowe lub osobowe. Podczas dodawania w Email > Data control list > Add należy filtrować CCL według Type i Region oraz wybrać tylko rzeczywiście potrzebne wpisy. Akcja jest definiowana dopiero w powiązanej policy. Kontrolowane dopasowanie i podobna treść bez dopasowania pozwalają sprawdzić, czy match i akcja współdziałają bez zbędnych false positives.

Spam protection to więcej niż akcja dla spamu. Błędy SPF i RBL są odrzucane bezpośrednio i nie podlegają zwykłym akcjom dla spam lub probable spam. Greylisting celowo tymczasowo odrzuca wiadomość i wymaga ponownej próby serwera nadawcy.

Dla Reject based on BATV należy najpierw skonfigurować wspólny BATV secret w Email > General settings > Advanced SMTP settings. Na wielu własnych systemach MX używa się tego samego secret. SFOS łączy go ze znacznikiem czasu i adresem nadawcy, tworząc podpis Return-Path, który wygasa po siedmiu dniach. Dlatego błąd BATV należy porównać z secret, czasem systemowym, ścieżką nadawcy i wiekiem podpisu, zamiast ukrywać go za szerokim wyjątkiem bez terminu.

Recipient verification blokuje wiadomości do nieznanych odbiorców:

• With callout: pyta serwer docelowy. Jeśli jest chwilowo niedostępny, SFOS po określonym czasie akceptuje odbiorców zamiast trwale blokować cały przepływ.
• In Active Directory: sprawdza przez Simple, SSL lub STARTTLS z timeoutem 30 sekund. Podać serwer AD, Bind DN i Base DN. Bind DN to pełna nazwa wyróżniająca, w tym CN skonfigurowanej tożsamości bind; Base DN jest punktem początkowym wyszukiwania w katalogu. Użyć wartości właściwych dla własnego katalogu. Przykład administratora w pomocy nie dowodzi konieczności uprawnień Domain Admin. Wybrać transport zgodny z wdrożoną polityką zaufania i bezpieczeństwa; sama etykieta SSL lub STARTTLS nie dowodzi poprawnej weryfikacji certyfikatu.

Malware Protection może używać jednego lub dwóch skanów antywirusowych. Dla Zero-Day Protection przy jednym skanie Sophos musi być silnikiem głównym. Sophos Firewall Zero-Day Protection wyjaśnia ograniczenia i decyzje o zwolnieniu.

Według pomocy policy SFOS 22/23 Single antivirus wybiera silnik główny tylko dla poczty przychodzącej; poczta wychodząca korzysta z obu silników. Dual antivirus skanuje najpierw silnikiem głównym, potem pomocniczym. Silnik główny, Sophos lub Avira, wybiera się globalnie w Email > General settings. Wybór Avira wyłącza Zero-day protection w policy SMTP z pojedynczym skanowaniem antywirusowym; Sophos musi być główny, aby używać Zero-Day Protection z jednym skanem. Pomoc ustawień ogólnych opisuje pojedynczy skan jako użycie wyłącznie silnika głównego, bez rozróżnienia kierunku z tabeli policy. Ta różnica dokumentacji nie dowodzi rzeczywistego użycia silników: sprawdzić build, policy, kierunek poczty i stan ochrony przed zmianą i po niej. Zapisać wcześniejsze ustawienia; przywrócenie wyboru silnika nie dowodzi ponownego włączenia Zero-day protection.

Limit polityki Drop message greater than w File protection nie jest tym samym co globalne zachowanie dla zbyt dużych wiadomości: w tym miejscu większe wiadomości są usuwane. SFOS sprawdza także widoczną treść i treść formatów pakietowych, takich jak docx, xlsx, pptx, odt, ods, odp i odg. Pozytywny test wyłącznie z nieopakowanym plikiem tekstowym nie potwierdza więc, jak te same informacje zostaną potraktowane w dokumencie Office.

Po włączeniu DKIM verification SFOS rozróżnia niezgodność skrótu, nieprawidłowy podpis lub niedostępny klucz publiczny oraz brak podpisu DKIM. Dla każdego wyniku można wybrać Accept, Quarantine lub Reject. Według Sophos wiadomości podpisane DKIM z RSA-SHA1 lub kluczem o długości poza zakresem od 1024 do 4096 bitów trafiają do kwarantanny. Tę kontrolę poczty przychodzącej należy testować oddzielnie od podpisywania wychodzącego.

Przy poczcie wychodzącej ważna jest kolejność przetwarzania. Szyfrowanie SPX, prefiksy tematu, File lub Data Protection i bannery wychodzące mogą zmienić header lub body po dodaniu podpisu DKIM. Weryfikacja DKIM u odbiorcy wtedy zawiedzie. Trzeba ustalić, czy podpisuje serwer wewnętrzny, Sophos Firewall czy późniejsza brama.

Podpisywanie wychodzących wiadomości przez DKIM na firewallu

Jeżeli podpisywać ma Sophos Firewall, dla każdej domeny nadawcy dodać podpis w Email > General settings > DKIM signing > Add. Domain to FQDN domeny pocztowej, a Key selector to dokładnie ten selektor, który następnie zostanie opublikowany w publicznym DNS. Nazwa taka jak fw01 lub zurich ułatwia zrozumienie późniejszej rotacji kluczy, ale nie jest funkcją bezpieczeństwa.

SFOS wymaga prywatnego klucza RSA o długości od 1024 do 2048 bitów między -----BEGIN RSA PRIVATE KEY----- i -----END RSA PRIVATE KEY-----. Dla nowych konfiguracji rozsądnym wyborem jest 2048 bitów. Nie należy używać RSA-SHA1. Według Sophos firewall nie akceptuje klucza 1024-bitowego wygenerowanego przez PuTTYgen, dlatego również tam trzeba wybrać 2048 bitów. Klucz prywatny należy przechowywać wyłącznie na firewallu i nigdy nie umieszczać go w DNS, zgłoszeniach ani publicznej dokumentacji.

Po zapisaniu u autorytatywnego dostawcy DNS opublikować rekord TXT DKIM selektora z kluczem publicznym. Dopiero gdy rekord jest rozwiązywany z zewnątrz, wysłać nową wiadomość testową przez przewidzianą wychodzącą ścieżkę MTA. Otrzymany nagłówek musi zawierać oczekiwany selektor i domenę, a weryfikacja DKIM u odbiorcy musi się udać. Jeśli brakuje podpisu, sprawdzić domenę nadawcy, dopasowanie policy i Scan outgoing mails. Jeśli weryfikacja nie powiedzie się, najpierw porównać rekord DNS, selektor, użyty klucz oraz późniejsze zmiany wykonywane przez SPX, bannery, File Protection lub Data Protection.

Konfiguracja i testowanie szyfrowania poczty SPX wyjaśnia współdziałanie szablonu, priorytetu wyzwalaczy, modelu hasła i Reply Portal.

Walidacja przepływu poczty

Poniższe polecenia wykonać z systemu poza własną siecią:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Zastąpić example.com i mail.example.com rzeczywistymi wartościami. Polecenia testują DNS, TCP 25 i STARTTLS, ale nie uprawnienie relay ani pełne dostarczenie. openssl s_client pozostaje interaktywny po handshake; zakończyć go Ctrl+C.

Przetestować co najmniej:

• wiadomość zewnętrzną do prawidłowego odbiorcy;
• przy włączonej Recipient verification wiadomość zewnętrzną do nieprawidłowego odbiorcy;
• wiadomość wychodzącą przez właściwy serwer;
• test spamu lub malware zgodny z policy;
• STARTTLS i prezentowany łańcuch certyfikatów;
• działanie kwarantanny i dostawę po zwolnieniu;
• zablokowaną próbę relay z niedozwolonego źródła;
• brak dostawy omijającej MTA przez starą regułę DNAT.

Zapisywać wyłącznie zaobserwowane wyniki odbioru: prawidłowa wiadomość testowa musi mieć w Mail logs stan Delivered i dać się prześledzić po Message-ID do skrzynki docelowej. Przy włączonej recipient verification nieprawidłowy odbiorca musi zostać odrzucony; gdy weryfikacja jest wyłączona, odrzucenie nie jest oczekiwanym wynikiem tego testu negatywnego. Niedozwolona próba relay nie może utworzyć wiadomości, a zwolnienie z kwarantanny musi pokazać późniejsze dostarczenie dla tego samego Message-ID.

Do pierwszej kontroli służą Email > Mail logs, Email > Mail spool, Email > SMTP quarantine i Log Viewer. Do głębszej analizy zapisać czas testu, nadawcę, odbiorcę, temat, źródłowy IP i Message-ID oraz skorelować:

• MTA: smtpd_main.log
• odrzucenia: smtpd_reject.log
• błędy skanowania: smtpd_error.log
• wewnętrzne błędy MTA: smtpd_panic.log
• anti-spam: sasi.log
• legacy SMTP proxy: awarrensmtp.log
• POP/IMAP proxy: warren.log

Usługi i logi Sophos Firewall wyjaśniają przypisanie i dostęp przez Advanced Shell.

W Mail logs pole Result oznacza stan dostarczenia, a Reason opisuje powód skanowania lub policy. Rejected oznacza, że SFOS odrzucił wiadomość i powiadomił nadawcę. Dropped odrzuca ją bez powiadomienia, a Bounced pojawia się po kilku nieudanych próbach dostarczenia. Tych stanów nie należy utożsamiać, ponieważ powodują inne odpowiedzi i ścieżki diagnostyczne. Pozostałe wyniki to Delivered, Quarantined i ręczne Deleted; powody można filtrować między innymi według Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM i BATV.

Obsługa kwarantanny i Mail spool

W Email > SMTP quarantine filtrować według okresu, nadawcy, odbiorcy, tematu i przyczyny:

• Release: dostarczyć wiadomość.
• Delete: usunąć wiadomość.
• Release and report: zwolnić i zgłosić SophosLabs tylko false positive oznaczone jako Spam lub Probable spam.

Wiadomości z wirusami lub uznane za złośliwe przez Zero-Day Protection nie mogą zostać zwolnione. Usuwanie wpisów Zero-Day Protection wymaga prawa zapisu w profilu administratora. Po zapełnieniu kwarantanny starsze wiadomości są usuwane.

Digest kwarantanny otrzymują tylko użytkownicy, którzy co najmniej raz uwierzytelnili się na zaporze. Domyślnie SFOS nie stosuje ustawień digestu do aliasów; trzeba je przypisać wraz z adresem podstawowym w Email > Quarantine settings > Change user’s quarantine digest settings albo w obiekcie użytkownika. Digest może wtedy obejmować spam do adresów podstawowych i aliasów. Wiadomości do aliasów nadal nie pojawiają się w samym User Portal.

Konfiguracja i testowanie raportu kwarantanny Sophos Firewall opisuje konfigurację, przypisanie użytkowników, link zwalniania i pełny test funkcjonalny.

Email > Mail spool zawiera wiadomości niedostarczone lub zakończone błędem. SFOS ponawia dostawę przez trzy dni i odrzuca wiadomości po kolejnych czterech; odrzucone pozostają w Mail logs. Rosnący spool sygnalizuje więc problem z routingiem, DNS, TLS, policy lub serwerem, a nie powód do wielokrotnego Retry bez diagnozy.

Filtr statusu rozróżnia Queued, Failed, SPX blocked, Zero-day protection i Error. SPX blocked oczekuje, aż odbiorca utworzy hasło; Zero-day protection oczekuje na analizę. Pobierać lub usuwać można tylko wiadomości w error queue. Usuwanie lub ponowne wysyłanie wiadomości Zero-Day Protection wymaga od profilu administratora praw odczytu i zapisu do Zero-Day Protection Activity. Jeśli przycisku brakuje, najpierw należy sprawdzić status i profil, zamiast obchodzić ograniczenie restartem usługi.

Kwarantanna i spool zajmują lokalny storage. Monitorować wolne miejsce, stan SSD i System Health; zobacz Czyszczenie storage i reports oraz Kontrola SSD Health. W HA logi i reports są oddzielne dla każdego node i nie synchronizują się, dlatego sprawdzić oba. Klastry HA Sophos Firewall opisują podstawy.

Troubleshooting

Poczta zewnętrzna nie dociera

Sprawdzić MX, A/AAAA, publiczny IP, TCP 25 i SMTP Relay z WAN. Następnie potwierdzić MTA mode, zgodność chronionej domeny z policy oraz brak starej reguły DNAT lub reguły o wyższym priorytecie zmieniającej ścieżkę. Brak połączenia w smtpd_main.log wskazuje problem przed Mail Protection.

Zapora przyjmuje, ale nie dostarcza

Sprawdzić serwer wewnętrzny, route, DNS, port, TLS i recipient verification. Static host, DNS host i MX mają różne ścieżki rozwiązywania i failover. Skorelować logi reject i error zapory z logami serwera.

Wiele wiadomości pozostaje w spool

Najpierw sprawdzić Email > Mail spool i logi MTA. Częstą przyczyną jest reguła nad automatyczną regułą MTA, która już dopasowuje SMTP. W Rules and policies > Firewall rules sprawdzić nowe reguły w pozycji Top, automatyczne reguły IPsec lub hotspot i inne nakładanie. Nie przesuwać reguł bez analizy; liczy się rzeczywisty match SMTP.

Dopiero po potwierdzeniu, że przyczyną jest nowa nakładająca się reguła, przesunąć ją w Rules and policies > Firewall rules na tyle niżej, aby przewidziana reguła SMTP była ponownie oceniana. Następnie ponownie sprawdzić dostarczenie i spool za pomocą kontrolowanej wiadomości; inne wymagane połączenia muszą nadal korzystać z przewidzianych dla nich reguł.

NC-177930 naprawiono w SFOS 22.0 MR2: wiadomości pozostawały w spool po awarii mailpoller. Na starszej wersji należy uwzględnić firmware w diagnozie. Użyć kontroli aktualizacji do SFOS 22, aby wybrać build docelowy, przygotować zmianę i ponownie przetestować przepływ poczty.

Sophos Fusion zgłasza Invalid API request

W SFOS 22.0 MR1 Release i Delete mogły zawieść, gdy zaporę otwarto przez Sophos Fusion (dawniej Sophos Central). Objaw Invalid API request jest rejestrowany jako NC-182056, a NC-181904 oznacza poprawkę nieudanego zwalniania przez Sophos Fusion. Bezpieczne obejście to bezpośrednie logowanie do lokalnego WebAdmin i akcja w Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 naprawia problem. Jeśli błąd trwa, osobno sprawdzić profil administratora, dostęp do Sophos Fusion i uprawnienia lokalne. Przy aktualizacji zastosować pełny proces zatwierdzania, przygotowania, weryfikacji i troubleshootingu opisany w Aktualizacja firmware Sophos Firewall: przygotowanie i najlepsze praktyki.

Nie można włączyć Reject based on RBL

NC-144563 to problem ograniczony do SFOS 20.0.2 MR2 Build 378: jeśli zmieniono nazwy domyślnych grup RBL w Email > Address group, nie można włączyć opcji Reject based on RBL podczas tworzenia polityki SMTP route and scan. W istniejącej polityce po wyłączeniu tej opcji nie można jej ponownie włączyć. Nie udokumentowano wersji z poprawką.

Domyślne grupy nazywają się Premium RBL services oraz Standard RBL services. Najpierw udokumentować dokładny build i aktualne nazwy grup. Jeśli oba warunki są spełnione, przywrócić oryginalne nazwy domyślnych RBL, ponownie otworzyć politykę i sprawdzić opcję. Nie mylić niestandardowych RBL z tymi dwiema grupami systemowymi.

W innych buildach albo przy niezmienionych nazwach domyślnych wyszarzona opcja nie potwierdza NC-144563. Osobno sprawdzić typ polityki, Spam protection, licencję Email Protection oraz pozostałą konfigurację.

Prawidłowy nadawca jest uznawany za spam

Sprawdzić domenę nadawcy, SPF/DKIM/DMARC, nagłówki, reputację, policy match i odbiorców. Dopiero potem utworzyć wąski wyjątek z datą przeglądu. Bezpieczne tworzenie i testowanie wyjątków poczty opisuje pełny proces określania zakresu, testowania i wycofywania zmian.

Systemy wewnętrzne nie mogą używać relay

Sprawdzić strefę źródłową w Administration > Device access, host w Email > Relay settings > Host-based relay i logi MTA. Jeśli skaner oczekuje standardowego SMTP AUTH, Host-based relay jest zwykle pewniejszy. Osobny, niezgodny z RFC Authenticated relay trzeba przetestować z konkretnym klientem.

Operacyjna lista kontrolna

• Sprawdzono licencję, obsługę modelu, DNS i wymagane usługi internetowe.
• Udokumentowano MX, TTL, publiczną i wewnętrzną ścieżkę oraz fallback.
• Automatyczna reguła MTA jest niezmieniona i na początku.
• Żadna stara reguła DNAT nie omija Mail Protection.
• Przetestowano Address Group, cel routingu i policy match.
• Rozdzielono przychodzący SMTP Relay z WAN i wychodzące uprawnienia hostów.
• Zrozumiano wpływ SPF/RBL, recipient verification, TLS, DKIM, SPX i bannerów.
• Wykonano zewnętrzne testy pozytywne i negatywne.
• Monitorowane są kwarantanna, spool, storage i logi.
• Mailflow jest ponownie testowany po aktualizacjach firmware.

Do dłuższej retencji i korelacji użyć Central Firewall Reporting lub wysyłania logów Sophos Firewall do SIEM.

FAQ