Konfiguracja Sophos Firewall Mail Protection w trybie MTA

Sophos Firewall może nie tylko zezwalać na ruch email jako zwykłe połączenie firewall, ale w trybie MTA sam działać jako Mail Transfer Agent między Internetem a wewnętrznym serwerem pocztowym. Firewall przyjmuje połączenia SMTP, sprawdza wiadomości za pomocą Mail Protection, a następnie dostarcza je do zdefiniowanego serwera pocztowego.

Dzisiaj zalecamy Mail Protection na firewallu tylko dla świadomie zaplanowanych przypadków specjalnych, na przykład gdy lokalny Exchange lub inny wewnętrzny serwer pocztowy ma być chroniony bezpośrednio przez firewall. Dla Microsoft 365, Google Workspace i większości nowoczesnych środowisk poczty w chmurze Sophos Central Email jest zazwyczaj lepszym rozwiązaniem. Central Email znajduje się bliżej właściwej usługi pocztowej, czyściej integruje się ze skrzynkami cloud, zmniejsza złożoność reguł firewalla i unika wielu klasycznych tematów MTA, takich jak zmiany MX, lokalne spools, pytania o relay i analiza błędów na firewallu.

Kolejny praktyczny punkt: Email Protection na firewallu w porównaniu z Sophos Central Email od dłuższego czasu wygląda jak funkcja dla istniejących instalacji, która pozostaje istotna przede wszystkim dla istniejących serwerów pocztowych on-premises. Kto dzisiaj planuje nowe wdrożenie, powinien więc najpierw sprawdzić, czy cloud mail gateway nie jest czystszą architekturą.

To technicznie mocne rozwiązanie, ale podatne na błędy, jeśli DNS, rekord MX, TLS, relay, weryfikacja użytkowników, policies i logi nie są czysto zaplanowane. Błędnie skonfigurowany MTA może blokować legalne emaile, opóźniać mailflow albo w najgorszym przypadku zostać zrozumiany jako relay.

Ten artykuł wyjaśnia praktyczną konfigurację Sophos Firewall Mail Protection w trybie MTA. Nie zastępuje planowania Sophos Central Email. Dla wielu środowisk Microsoft 365 lub Google Workspace cloud mail gateway jest często bardziej odpowiedni. Jeśli jednak używany jest lokalny Exchange, hybrydowy serwer pocztowy albo świadomie firewallowy tor SMTP, potrzebny jest jasny plan operacyjny.

Kiedy Mail Protection na firewallu ma sens

Mail Protection na Sophos Firewall ma sens przede wszystkim wtedy, gdy ruch SMTP ma świadomie przechodzić przez firewall, a firewall ma robić więcej niż tylko przekazywać port 25.

Typowe scenariusze:

• Przychodzące emaile mają być najpierw przyjmowane i sprawdzane na firewallu.
• Wewnętrzny serwer pocztowy nie ma być bezpośrednio dostępny z Internetu.
• Sprawdzanie spamu, malware, typów plików lub treści ma działać przed dostarczeniem.
• Wychodzące emaile mają być wysyłane kontrolowanie przez firewall albo smarthost.
• Kwarantanna, mail spool i logi SMTP mają być możliwe do prześledzenia na firewallu.

Nie każda konfiguracja poczty powinna przechodzić przez firewall. Jeśli Sophos Central Email, Microsoft Defender for Office 365 albo inny cloud mail gateway obsługuje już cały mailflow, Mail Protection na firewallu nie powinno być dodatkowo wstawiane po drodze bez dokładnego udokumentowania przepływu poczty. Podwójne bramy szybko prowadzą do niejasnych odpowiedzialności za kwarantannę, nagłówki, SPF/DKIM/DMARC, TLS i troubleshooting.

Rozróżnienie trybu MTA, Legacy mode i SMTP Relay

W Sophos Firewall trzeba jasno oddzielić trzy rzeczy:

MTA mode jest normalnym trybem docelowym dla nowoczesnych scenariuszy firewall Mail Protection. Lokalna usługa SMTP Relay jest natomiast tematem Device Access. Powinna być osiągalna tylko z określonych sieci wewnętrznych. Zbyt szerokie dopuszczenie może sprzyjać nadużyciu relay. Utwardzanie usług lokalnych opisano w Zabezpieczanie dostępu do Sophos Firewall: poprawna konfiguracja Device Access.

Wymagania

Przed konfiguracją należy wyjaśnić te punkty:

• Sophos Firewall z ważną Email Protection albo odpowiednim bundle.
• Nie każdy model obsługuje MTA mode. XGS 87 i XGS 88 to appliance bez obsługi MTA mode.
• Publiczna strefa DNS i rekord MX są znane.
• Wewnętrzny serwer pocztowy, port docelowy i droga dostarczenia są udokumentowane.
• Publiczny adres IP lub adres WAN dla przychodzącego ruchu SMTP jest zdefiniowany.
• Firewall może routować do wewnętrznego serwera pocztowego i go osiągać.
• Wychodzący dostęp DNS firewalla działa.
• Pożądana strategia TLS i certyfikatów jest wyjaśniona.
• Proces kwarantanny i zwalniania jest organizacyjnie zdefiniowany.

Przed zmianami w mailflow należy zaplanować okno serwisowe. Test na produkcyjnych rekordach MX bez planu powrotu jest ryzykowny, ponieważ przychodzące emaile mogą zależnie od nadawcy szybko zostać opóźnione lub odrzucone.

Ustalenie architektury docelowej

Najpierw należy zdecydować, który kierunek ma przetwarzać firewall.

Przychodzący mailflow

W przychodzącym mailflow zewnętrzne rekordy MX wskazują na publiczny adres, pod którym Sophos Firewall przyjmuje SMTP. Firewall sprawdza wiadomość i przekazuje ją do wewnętrznego serwera pocztowego.

Typowy przebieg:

1. Zewnętrzny nadawca łączy się przez SMTP z publicznym adresem MX.
2. Sophos Firewall przyjmuje połączenie w MTA mode.
3. Mail Protection sprawdza nadawcę, odbiorcę, spam, malware, załączniki i policy.
4. Firewall dostarcza email do wewnętrznego serwera pocztowego.
5. Wewnętrzny serwer pocztowy dostarcza do skrzynki albo dalej przetwarza wiadomość.

Ważne jest, aby wewnętrzny serwer pocztowy nie pozostał dodatkowo niefiltrowanie osiągalny z Internetu. Jeśli równolegle reguła DNAT nadal wskazuje bezpośrednio na serwer pocztowy, część ruchu może ominąć Mail Protection. Dla normalnych publikacji serwerów właściwą podstawą jest Publikowanie serwera przez DNAT, ale w MTA mode sam firewall jest punktem przyjmowania SMTP.

Wychodzący mailflow

W wychodzącym mailflow wewnętrzny serwer pocztowy wysyła przez Sophos Firewall. Firewall może sprawdzać wiadomości, przekazywać je do smarthosta albo dostarczać bezpośrednio, zależnie od konfiguracji.

Wyjaśnić wcześniej:

• Czy publiczny adres IP firewalla może wysyłać emaile bezpośrednio?
• Czy SPF, DKIM i DMARC pasują do wybranej drogi wysyłki?
• Czy potrzebny jest smarthost providera?
• Czy wychodzący ruch SMTP musi być ograniczony do określonych systemów wewnętrznych?
• Gdzie monitorowane są odrzucone lub opóźnione wiadomości?

Dla wychodzącego ruchu mailowego należy użyć własnej, przejrzystej struktury reguł i policies. Ogólna reguła LAN to WAN bez jasnego ograniczenia jest dla serwerów pocztowych najczęściej zbyt szeroka. Podstawy kolejności reguł i profili bezpieczeństwa opisano w Zrozumieć i czysto budować reguły Sophos Firewall.

Przygotowanie zmiany MX i testów zewnętrznych

Zmiana Mail Protection staje się krytyczna dopiero wtedy, gdy zewnętrzni nadawcy naprawdę używają nowej drogi. Dlatego przed zmianą produkcyjną należy sprawdzić rekord MX, DNS TTL, zewnętrzną osiągalność i rollback.

Przed zmianą:

• Udokumentować aktualny rekord MX, priorytet i TTL.
• Wcześnie obniżyć DNS TTL, jeśli może być potrzebny szybki powrót.
• Jasno odróżnić starą drogę poczty i nowy adres Sophos Firewall.
• Zidentyfikować stare bezpośrednie reguły DNAT do serwera pocztowego.
• Zdefiniować odbiorców i nadawców testowych.
• Ustalić plan powrotu: stary MX, stara reguła DNAT albo tymczasowy smarthost.
• Przygotować monitoring spool, kwarantanny i kolejki serwera pocztowego.

Przydatne testy zewnętrzne z systemu poza własną siecią:

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

Polecenia nie zastępują pełnego testu mailflow, ale szybko pokazują, czy DNS, port 25 i STARTTLS są zasadniczo osiągalne. example.com i mail.example.com trzeba zastąpić prawdziwą domeną i prawdziwym hostem pocztowym.

Po przełączeniu należy natychmiast wysłać przychodzący email testowy i udokumentować całą ścieżkę:

• Połączenie widoczne w Log Viewer?
• Wpis obecny w smtpd_main.log?
• Weryfikacja odbiorcy udana?
• Dostarczenie do wewnętrznego serwera pocztowego wykonane?
• Wiadomość dotarła do skrzynki?
• Brak równoległego bezpośredniego dostarczenia z pominięciem MTA?

Jeśli firewall przyjmuje emaile, ale ich nie dostarcza, nie należy od razu cofać MX. Najpierw trzeba wyjaśnić, czy to problem wewnętrznego routingu, DNS, TLS albo serwera pocztowego. Jeśli jednak zewnętrzni nadawcy nie mogą zestawić połączenia z firewallem albo legalne emaile są szeroko odrzucane, szybki powrót do poprzedniej drogi poczty jest często rozsądniejszy niż dłuższe eksperymenty w produkcyjnej ścieżce MX.

Aktywacja MTA mode

Podstawowe ustawienia znajdują się w Sophos Firewall pod:

Email > General settings

Tam wybierany jest tryb email. Dla tej instrukcji istotny jest MTA mode. Po zmianie należy sprawdzić, czy istniejące policies, obiekty hostów i domeny mail nadal pasują do pożądanego działania.

W istniejących środowiskach nie należy po prostu przełączać między Legacy mode i MTA mode bez testowania mailflow. Przetwarzanie, logi i logika policy różnią się. Przed migracją należy udokumentować aktualną konfigurację firewalla, rekordy MX, konektory serwera pocztowego i ustawienia relay.

Konfiguracja routingu SMTP i domen

Dla przychodzących emaili firewall musi wiedzieć, które domeny ma przyjmować i dokąd ma je dostarczać.

Typowy przebieg:

1. Pod Email > Policies and exceptions albo w obszarach Mail Protection zaplanować dotknięte domeny i serwery docelowe.
2. Wpisać domenę mail, na przykład example.com.
3. Zdefiniować wewnętrzny serwer pocztowy albo obiekt hosta jako cel dostarczenia.
4. Sprawdzić, czy firewall osiąga serwer pocztowy na porcie docelowym.
5. Sprawdzić wymagania TLS i certyfikaty.
6. Wysłać email testowy z zewnątrz do znanego odbiorcy.

Dla wewnętrznych serwerów pocztowych DNS jest szczególnie ważny. Firewall musi poprawnie rozwiązywać cele wewnętrzne, a zewnętrzni nadawcy muszą osiągać publiczny wpis MX. Jeśli wewnętrzne rozwiązywanie DNS odgrywa rolę, pomaga Konfiguracja DNS Request Routes na Sophos Firewall.

Planowanie policies dla spamu, malware i załączników

Mail Protection jest tak dobre, jak policies, które faktycznie działają. Policy nie powinna być tylko utworzona, ale nazwana z jasnym celem.

Ważne pytania dotyczące policy:

• Jakie domeny albo grupy odbiorców są dotknięte?
• Czy przetwarzany jest przychodzący, wychodzący czy dwukierunkowy ruch mailowy?
• Co dzieje się ze spamem, malware, podejrzanymi załącznikami albo niechcianymi typami plików?
• Czy emaile są blokowane, kierowane do kwarantanny, dostarczane albo oznaczane nagłówkami?
• Kto może sprawdzać kwarantannę i zwalniać emaile?
• Jakie procesy false positive istnieją?

Jeśli używana jest Zero-Day Protection, podejrzane załączniki email mogą być dodatkowo analizowane. Granice, raporty i decyzja o zwolnieniu są wyjaśnione w Zrozumieć i obsługiwać Sophos Firewall Zero-Day Protection.

Zabezpieczenie relay i Device Access

Częstym błędem jest pomylenie mailflow MTA z otwartym SMTP Relay. Firewall nie może być używany jako relay z dowolnych sieci.

Sprawdzić:

• Pod Administration > Device access SMTP Relay jest osiągalny tylko z wymaganych stref wewnętrznych.
• Jeśli używane są ACL Exception Rules, źródła są wąsko zdefiniowane.
• Tylko zdefiniowane wewnętrzne serwery pocztowe, skanery lub serwery aplikacyjne mogą relayować przez firewall.
• Z WAN, sieci gościnnych i stref untrusted SMTP Relay nie jest ogólnie udostępniony.
• Logging jest aktywny, aby nadużycia lub błędne konfiguracje były widoczne.

Jeśli drukarki, skanery lub aplikacje muszą wysyłać emaile, należy udokumentować dla nich własną wewnętrzną drogę relay. Takie systemy nie powinny rozmawiać bezpośrednio z dowolnymi zewnętrznymi celami SMTP, jeśli środowisko może tego uniknąć.

Testowanie mailflow

Po konfiguracji pojedyncza udana wysyłka nie wystarczy. Należy wykonać kilka testów i udokumentować wyniki.

Test przychodzący

Sprawdzić co najmniej:

• Zewnętrzny rekord MX wskazuje oczekiwany adres.
• Port 25 jest osiągalny z zewnątrz.
• Firewall przyjmuje połączenie w MTA mode.
• Email jest przekazywany do wewnętrznego serwera pocztowego.
• Odbiorca istnieje i otrzymuje wiadomość.
• Test spamu lub malware jest obsługiwany zgodnie z oczekiwaniem.
• Wpis kwarantanny lub logu jest możliwy do prześledzenia.

Test wychodzący

Sprawdzić co najmniej:

• Wewnętrzny serwer pocztowy wysyła oczekiwaną trasą.
• Reguła firewalla i mail policy działają.
• SPF, DKIM i DMARC pasują do drogi wysyłki.
• Serwer docelowy akceptuje wiadomość.
• Bounces lub komunikaty Deferred są monitorowane.
• Żadne inne systemy wewnętrzne nie wysyłają nieplanowanie bezpośrednio na zewnątrz.

Sprawdzanie logów

Do szybkiej kontroli wizualnej pomaga Log Viewer. Do głębszej analizy ważne są pliki logów mail. Przyporządkowanie znajduje się w Sophos Firewall Troubleshooting: usługi i logi.

Istotne pliki logów:

Przy pilnym troubleshooting należy zanotować czas testu, zebrać nadawcę, odbiorcę, temat, źródłowy IP i Message-ID, a następnie skorelować Log Viewer i pliki logów według czasu.

Kwarantanna, spool i pamięć

Mail Protection tworzy dane lokalne. Zależnie od wolumenu wiadomości trafiają do kwarantanny, spool albo obszarów tymczasowych. Przez to miejsce na dysku, stan SSD i plan recovery stają się ważniejsze niż przy czystej regule firewalla.

Praktyczne pytania operacyjne:

• Kto sprawdza kwarantannę i jak często?
• Jak zwalniane są false positives?
• Kiedy wiadomość jest usuwana zamiast zwalniana?
• Jak wykrywany jest rosnący mail spool?
• Czy istnieje monitoring miejsca na dysku i System Health?
• Czy po firmware updates planowany jest krótki test mailflow?

Dla tematów pamięci i reporting pasują Porządkowanie pamięci i raportów Sophos Firewall oraz Sprawdzanie Sophos Firewall SSD Health. W środowiskach HA należy dodatkowo uwzględnić, że kwarantanna mail i przetworzone dane mailowe mogą być danymi operacyjnymi przypisanymi do węzła. Podstawy HA opisano w Warianty klastrów HA Sophos Firewall.

Troubleshooting

Zewnętrzne emaile nie dochodzą

Najpierw sprawdzić DNS i osiągalność: rekord MX, publiczny IP, port 25, pozostałości NAT, MTA mode i właściwą domenę mail. Następnie w Log Viewer i w smtpd_main.log sprawdzić, czy połączenie dociera do firewalla. Jeśli nie widać żadnego połączenia, problem prawdopodobnie leży przed Mail Protection.

Firewall przyjmuje emaile, ale ich nie dostarcza

Wtedy bardziej prawdopodobne są wewnętrzny serwer pocztowy, routing, DNS, port docelowy, TLS, weryfikacja odbiorcy lub policy. Sprawdza się, czy firewall może osiągnąć serwer pocztowy i czy serwer akceptuje połączenie. Reject logs i logi serwera pocztowego należy oceniać razem w czasie.

Wiele emaili pozostaje w spool

Rosnący spool często wskazuje na problemy z dostarczeniem: wewnętrzny serwer pocztowy nieosiągalny, wymaganie TLS nie pasuje, rozwiązywanie DNS nie działa albo serwer docelowy odrzuca wiadomość. W takim przypadku nie wystarczy ponownie dostarczać pojedynczych wiadomości, lecz trzeba szukać przyczyny w ścieżce routingu i SMTP.

Łatwo przeoczyć ważny przypadek kolejności reguł: jeśli automatycznie lub ręcznie utworzona reguła firewalla znajduje się powyżej reguły MTA i matchuje ruch SMTP, właściwa reguła MTA nie jest już oceniana. Wtedy emaile mogą zostawać w mail spool, mimo że DNS, port 25 i serwer pocztowy zasadniczo wyglądają poprawnie.

Sprawdzić:

1. Otworzyć Rules and policies > Firewall rules.
2. Sprawdzić reguły powyżej reguły MTA lub SMTP.
3. Skontrolować nowe automatycznie utworzone reguły, reguły IPsec, reguły hotspot albo reguły ręcznie ustawione na Top.
4. Ponownie wykonać test SMTP i porównać Log Viewer, mail spool oraz smtpd_main.log.

Reguły nie wolno ślepo przesuwać w dół, jeśli spełnia inne produkcyjne cele. Decydujące jest, czy nieoczekiwanie przechwytuje ruch SMTP przed regułą MTA.

Brak digestu kwarantanny dla adresów alias

Jeśli użytkownicy używają adresów alias, ustawień kwarantanny nie należy sprawdzać tylko dla podstawowego adresu email. Według Sophos ustawienia kwarantanny domyślnie nie są automatycznie stosowane do adresów alias. Jeśli brakuje maili digest lub zwolnień dla odbiorców alias, adresy alias trzeba uwzględnić razem z adresem podstawowym w kontekście kwarantanny lub użytkownika.

Legalny nadawca jest rozpoznawany jako spam

Na false positives nie należy od razu odpowiadać szerokimi wyjątkami. Najpierw sprawdzić domenę nadawcy, SPF/DKIM/DMARC, nagłówki, reputację, policy match i dotkniętych odbiorców. Jeśli wyjątek jest potrzebny, powinien być wąsko ograniczony i udokumentowany z datą przeglądu.

Systemy wewnętrzne nie mogą relayować

Sprawdzić, czy SMTP Relay pod Administration > Device access jest dozwolony z właściwej strefy i czy źródło pasuje do ACL. Następnie sprawdzić logi mail. Jeśli skaner albo aplikacja ma relayować, źródło powinno być udokumentowane jako obiekt hosta, a nie niepotrzebnie udostępniana cała sieć.

Po firmware update poczta działa inaczej

Po firmware updates należy sprawdzić MTA mode, policies, certyfikaty, mail spool, kwarantannę i istotne logi. Dla większych aktualizacji pasuje dodatkowo Sprawdzić Sophos Firewall przed upgrade do SFOS 22.

Lista kontrolna eksploatacji

• Licencja Mail Protection i obsługa appliance sprawdzone.
• MTA mode świadomie wybrany i udokumentowany.
• Rekord MX, publiczny IP i wewnętrzny serwer docelowy są poprawne.
• Zmiana MX, testy zewnętrzne i rollback są przygotowane.
• Żadna równoległa niefiltrowana reguła DNAT nie omija MTA.
• Przychodzące i wychodzące policies są zrozumiale nazwane.
• Kolejność reguł firewalla nie uniemożliwia działania reguły MTA.
• SMTP Relay jest dozwolony tylko z określonych źródeł wewnętrznych.
• Proces kwarantanny i false positives jest ustalony.
• Adresy alias są uwzględnione w procesie kwarantanny i digest.
• Mail spool, miejsce na dysku i System Health są monitorowane.
• Logi są przechowywane lokalnie, w Sophos Central albo przez Syslog wystarczająco długo.
• Po firmware updates wykonywany jest test mailflow.

Dla dłuższego przechowywania i korelacji z innymi zdarzeniami bezpieczeństwa należy sprawdzić Central Firewall Reporting albo Wysyłanie Sophos Firewall Syslog do SIEM.

FAQ