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 Central Email albo inna chmurowa brama pocztowa jest zwykle czytelniejszą architekturą. Dwie bramy w szeregu komplikują kwarantannę, nagłówki, TLS, SPF/DKIM/DMARC i diagnostykę.

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

• MTA mode: zapora odbiera, skanuje i routuje pocztę.
• Legacy mode: starsze przezroczyste przetwarzanie proxy dla istniejących wdrożeń.
• 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.

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.
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. Zapora sprawdza SMTP TLS na podstawie adresu IP domeny, nie jej nazwy, dlatego wiele domen na jednym IP może powodować błędy certyfikatu.

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

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 a 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.
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ę.

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.

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.

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ę. Jeśli zapora przyjmuje, lecz nie dostarcza, najpierw sprawdzić routing, DNS, TLS, recipient verification i logi serwera.

Świadomy wybór ochrony

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.

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.

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.

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.

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

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.

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. Aliasy trzeba sprawdzić osobno; wiadomości do aliasów nie pojawiają się w User Portal.

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.

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.

SFOS 22.0 MR2 naprawia także NC-177930, w którym wiadomości pozostawały w spool po crashu mailpoller. Na starszej wersji uwzględnić firmware w diagnozie.

Central zgłasza Invalid API request

W SFOS 22.0 MR1 Release i Delete mogły zawieść, gdy zaporę otwarto przez Sophos Central. Bezpieczne obejście to bezpośrednie logowanie do lokalnego WebAdmin i akcja w Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 naprawił problem. Jeśli błąd trwa, osobno sprawdzić profil administratora, dostęp Central i uprawnienia lokalne.

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

Sophos opisuje pod identyfikatorem NC-144563 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ć. Aktualna Known Issues List nie wskazuje 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.

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