Konfiguracja Mail Protection na Sophos Firewall w trybie Legacy

W Legacy mode Sophos Firewall działa jako przezroczyste proxy poczty. Wewnętrzny serwer pocztowy pozostaje właściwym endpointem SMTP; firewall przekazuje ruch przez istniejące reguły firewalla i NAT, jednocześnie sprawdzając go pod kątem spamu, malware, typów plików i dopasowań Data Control.

To zasadniczo różni się od MTA mode. Firewall nie staje się Mail Transfer Agentem, nie przejmuje dostarczania poczty dla chronionych domen i nie oferuje dla tej ścieżki MTA mail spool. Pomyślny test portu SMTP nie potwierdza więc ani skanowania proxy, ani zastosowania właściwej polityki.

⚠️ Zmiana SMTP Deployment Mode jest globalną zmianą ścieżki ochrony poczty. Przed przełączeniem należy udokumentować backup, istniejące polityki, reguły firewalla i NAT oraz przetestowaną ścieżkę powrotu. Problem z MTA nie jest powodem do nieplanowanego przejścia na Legacy mode.

Legacy mode w dziewięciu krokach

1. Udokumentować istniejącą przychodzącą i wychodzącą ścieżkę SMTP wraz z adresami IP, portami, NAT i Firewall Rule IDs.
2. Sprawdzić, czy przezroczyste proxy rzeczywiście pasuje lepiej niż MTA mode.
3. Zapewnić backup konfiguracji i niezależny dostęp administracyjny.
4. W Email > General settings wybrać Switch to legacy mode.
5. Ustalić limit rozmiaru SMTP, akcję dla zbyt dużych wiadomości, IP Reputation, limity DoS i zachowanie TLS.
6. Utworzyć tylko potrzebne polityki SMTP malware i SMTP spam albo sprawdzić ich kolejność.
7. Ograniczyć przychodzące ścieżki DNAT i wychodzące ścieżki SNAT do właściwego serwera pocztowego.
8. W rzeczywiście dopasowanych regułach firewalla włączyć Scan SMTP lub Scan SMTPS.
9. Zweryfikować przychodzące i wychodzące wiadomości testowe na podstawie Rule ID, wyniku polityki, certyfikatu i logów proxy Legacy.

Wybór między Legacy mode a MTA mode

Legacy mode pasuje przede wszystkim do istniejących środowisk, w których wewnętrzny serwer pocztowy jest już bezpośrednio publikowany przez NAT i ta ścieżka ma zostać zachowana. SFOS działa przezroczyście pomiędzy zdalnym peerem a serwerem. Cel MX, przyjmowanie SMTP i logika dostarczania pozostają elementami istniejącego projektu serwera pocztowego.

MTA mode jest lepszym wyborem, gdy firewall ma sam przyjmować wiadomości, trasować je według chronionych domen, relayować i przechowywać w spoolu podczas tymczasowych błędów dostarczania. Mail logs i mail spool należą jednoznacznie do tego modelu działania. Kompletną konfigurację opisuje artykuł Konfiguracja Mail Protection w MTA mode.

Według pomocy SFOS 22 MTA mode nie jest dostępny na XGS 87/87w ani XGS 88/88w. Nie oznacza to jednak automatycznie, że Legacy mode jest dobrą architekturą poczty w chmurze. Microsoft 365, Google Workspace i nowoczesne usługi hostingowe stosują własne wymagania dotyczące TLS, uwierzytelniania i ochrony przed nadużyciami. Przed użyciem przezroczystego proxy trzeba potwierdzić jego obsługę.

W skrócie: MTA mode ma własny przepływ poczty. Legacy mode chroni już działającą ścieżkę SMTP. Pomieszanie tych modeli prowadzi do szukania w niewłaściwym logu, przy niewłaściwym celu NAT albo w nieistniejącym spoolu.

Przykładowa topologia i ścieżka powrotu

Poniższy przykład wykorzystuje wartości dokumentacyjne i przed wdrożeniem musi zostać dostosowany do rzeczywistego środowiska:

• wewnętrzny serwer pocztowy 10.20.30.25 w strefie DMZ
• publiczny adres SMTP 192.0.2.25 na ścieżce WAN
• przychodząca usługa SMTP TCP 25
• opcjonalny SMTPS na TCP 465, tylko jeśli peery i serwer rzeczywiście używają tego wariantu
• reguły firewalla SMTP_In_Legacy i SMTP_Out_Legacy

192.0.2.25 należy do zakresu TEST-NET i nie jest wartością produkcyjną. Przed zmianą należy wykonać zewnętrzny test przychodzący i test wychodzący ze znacznikiem czasu. Zapisać aktualnie dopasowane Rule IDs, publiczny adres źródłowy używany przez serwer wychodzący oraz łańcuch certyfikatów.

Ścieżka powrotu nie polega wyłącznie na ponownym przełączeniu trybu. Trzeba także móc przywrócić udokumentowany stan nowych opcji skanowania, kolejności polityk, DNAT, reflexive lub ręcznych reguł SNAT oraz testów tymczasowych.

Ustalenie globalnych ustawień SMTP

Limit rozmiaru, akcja dla zbyt dużych wiadomości i ochrona DoS

W Email > General settings > SMTP settings opcja Don’t scan emails greater than określa maksymalny rozmiar wiadomości podlegającej skanowaniu. W ścieżce SMTP wartość 0 oznacza według pomocy SFOS 22 51,200 KB, a nie brak limitu. Dla większych wiadomości dostępne są Accept, Reject i Drop.

Accept dostarcza zbyt dużą wiadomość bez skanowania. Reject odrzuca ją i informuje nadawcę, natomiast Drop usuwa ją bez powiadomienia. Ten wybór jest świadomą decyzją dotyczącą ryzyka i eksploatacji. Nieprzetestowane Drop utrudnia diagnostykę; nieocenione Accept tworzy lukę w skanowaniu, którą trzeba udokumentować.

Verify sender’s IP reputation sprawdza adres IP nadawcy przed kryteriami spamu w polityce SMTP. Wartości SMTP DoS ograniczają połączenia, wiadomości i odbiorców. Limity produkcyjne wynikają z rzeczywistego wolumenu poczty i baseline, a nie z ogólnego przykładu z internetu.

Bypass spam check for SMTP/S authenticated connections globalnie pomija kontrolę spamu dla połączeń, które serwer pocztowy rozpoznaje jako uwierzytelnione. Jest to dopuszczalne dopiero po sprawdzeniu uwierzytelniania, dozwolonych źródeł i ochrony tego przepływu przed nadużyciami. Pomyślne logowanie nie zastępuje ani skanowania malware, ani negatywnego testu z nieuwierzytelnionym połączeniem. Domeny wpisane w Spam check exceptions również stanowią globalne obejście i nie służą jako szybki zamiennik precyzyjnie ograniczonego wyjątku.

Globalny baner wiadomości oferuje tryby Inline, no conversion, MIME part i Off. Pojawia się tylko wtedy, gdy w dopasowanej regule firewalla jest aktywne skanowanie SMTP lub SMTPS. Ponieważ zmiana treści wiadomości może unieważnić istniejący podpis DKIM, rzeczywistą ścieżkę wychodzącą należy zweryfikować przez sprawdzenie nagłówków po stronie odbiorcy.

Nie przeceniać TLS z powodu jednego pola wyboru

W SMTP TLS configuration należy wybrać certyfikat CA lub serwera przeznaczony do skanowania. Allow invalid certificate pozostaje wyłączone. Według pomocy Disable legacy TLS protocols wyłącza tylko protokoły wcześniejsze niż TLS 1.1 i nie potwierdza konkretnej sesji TLS 1.2 ani TLS 1.3.

Sophos wskazuje również ważne ograniczenie Legacy: firewall nawiązuje połączenie TLS na podstawie adresu IP domeny, a nie nazwy domeny. Jeśli wiele domen współdzieli jeden adres IP, weryfikacja certyfikatu może się nie powieść. W takim przypadku Sophos zaleca inną ścieżkę ochrony, na przykład Sophos Email Security. Kontroli nie omija się przez Allow invalid certificate.

Require TLS negotiation wymusza TLS dla wybranych Remote Hosts lub sieci; Require sender email domains wymusza go dla domen nadawców. Jeśli połączenia TLS nie można zestawić, SFOS odrzuca odpowiednie wiadomości. Skip TLS negotiation świadomie dopuszcza nieszyfrowane połączenia SMTP do wybranych peerów i powinno występować wyłącznie w udokumentowanych wyjątkach.

Świadome stosowanie polityk skanowania

Po aktywacji subskrypcji Email Protection Sophos Firewall automatycznie stosuje w Legacy mode domyślną politykę default-smtp-av do ruchu SMTP. Własne polityki tworzy się w Email > Policies i są one przetwarzane w kolejności listy. Najpierw trzeba więc sprawdzić, która istniejąca polityka pasuje do konkretnego nadawcy i odbiorcy.

SMTP malware scan

Polityka SMTP malware scan steruje blokowanymi typami plików, wyjątkami MIME, skanowaniem antywirusowym i akcjami dostarczania. Przy Single antivirus wybrany silnik dotyczy według pomocy tylko wiadomości przychodzących; wychodzące są skanowane przez oba silniki. Dual antivirus uruchamia kolejno silnik podstawowy i pomocniczy.

Akcja Quarantine jest łączona z akcjami dla odbiorcy i administratora. Don’t deliver, Deliver original i Remove and deliver mają bardzo różne skutki. Chronionego lub nieskanowalnego załącznika nie wolno automatycznie utożsamiać z malware. Każda akcja wymaga zatem wiadomości testowej, oczekiwanego stanu po stronie odbiorcy i udokumentowanej ścieżki zwolnienia.

Quarantine nie oznacza automatycznie, że odbiorca nie otrzyma żadnej wiadomości; nadal decyduje Delivery option for recipient. Według Sophos Notify sender działa tylko razem z Don’t deliver. Chronione załączniki nie są skanowane, ale mogą nadal wywołać powiadomienie. Oddzielna akcja administratora określa, czy administratorzy nie otrzymają kopii, otrzymają oryginał czy wiadomość bez załącznika. Tych czterech wyników nie należy wywodzić z jednego udanego testu.

SMTP spam scan

Polityka SMTP spam scan może dopasowywać klasyfikację spamu, źródło lub cel, RBL, rozmiar wiadomości, nagłówki albo Data Control List. W zależności od ścieżki dostępne są akcje Reject, Accept, Change recipient, Prefix subject, Drop i Quarantine.

Kryterium Data control list oraz przypisanie SPX w tej polityce dotyczą wyłącznie wiadomości wychodzących. None stosuje natomiast wybraną akcję do wszystkich wiadomości pomiędzy określonymi grupami nadawców i odbiorców. Change recipient nie dostarcza dodatkowo do pierwotnego odbiorcy, lecz zastępuje go skonfigurowanym adresem docelowym. Te trzy zakresy należy sprawdzić na pozytywnym i negatywnym przypadku odbiorcy przed umieszczeniem polityki w kolejności produkcyjnej.

Przygotowanie własnych typów plików i Data Control

W Legacy mode własne typy plików tworzy się w Email > Policies > File type > Add na podstawie szablonu, rozszerzeń albo typów MIME. Rozszerzenia wpisuje się bez kropki na początku, a edytować można tylko własne typy. Nowy typ nie jest automatycznie dodawany do istniejących policy. Należy otworzyć odpowiednią scan policy, dodać typ pliku i ponownie ją zapisać. Pozytywny test załącznika oraz podobny test negatywny pokazują, czy rzeczywiście działa przewidziana akcja.

Data Control List tworzy się w Email > Data control list > Add z potrzebnych Content Control Lists. Filtry Type i Region pomagają wybrać tylko odpowiednie wzorce danych finansowych, tożsamości lub innych danych wrażliwych. Dopasowanie listy nie określa jeszcze akcji; jest ona definiowana w powiązanej scan policy. Mała lista pilotażowa z pozytywnym i negatywnym testem treści jest bezpieczniejsza niż szeroki zbiór niesprawdzonych CCL.

W Legacy mode w tej polityce można wybrać SPX dla wiadomości wychodzących. Model haseł, portal i weryfikacja stanowią jednak odrębny proces bezpieczeństwa; opisuje go artykuł Konfiguracja szyfrowania wiadomości SPX. Do pierwszego podstawowego testu proxy nie dodaje się Data Control List ani przypisania SPX.

Potwierdzonej błędnej klasyfikacji nie należy korygować przez wyłączenie szerokiej polityki. Bezpieczne tworzenie i testowanie wyjątków poczty wyjaśnia, jak pomijać pojedyncze kontrole dla dokładnej kombinacji źródła, nadawcy i odbiorcy, a następnie testować ruch, który nie powinien być dopasowany.

Korzystanie z opcjonalnego journalingu poczty z uwzględnieniem ochrony danych

W Email > General settings > Email journaling > Add SFOS może wysyłać kopie przychodzących wiadomości SMTP/S dla wybranych odbiorców lub grup adresów na osobny adres journalingu. Wybór Any obejmuje wszystkie wiadomości przychodzące. Funkcja dotyczy wyłącznie SMTP/S i nie rejestruje ruchu POP ani IMAP.

Journaling tworzy dodatkową kopię wiadomości. Nie jest automatycznie archiwum odpornym na manipulacje i nie dowodzi spełnienia ustawowych obowiązków przechowywania. Przed włączeniem należy określić cel, uprawnionych odbiorców, dostęp do skrzynki journalingu, szyfrowanie, okres przechowywania, wymagane miejsce oraz odpowiedzialnego właściciela.

Do pierwszego testu wybiera się jedną skrzynkę testową zamiast Any. Wiadomość przychodząca do tej skrzynki musi pojawić się w zwykłym miejscu docelowym oraz w skrzynce journalingu; wiadomość do odbiorcy spoza wyboru nie może tworzyć kopii. Adres journalingu nie może uruchamiać przepływu, który odsyła kopię do SFOS i tworzy pętlę.

Wybór odbiorców rozszerza się dopiero po teście pozytywnym i negatywnym. W ramach rollbacku usuwa się wpis journalingu lub przywraca udokumentowany stan poprzedni. Dostarczone wcześniej kopie pozostają w skrzynce journalingu i podlegają jej własnym zasadom przechowywania.

Połączenie NAT i reguł firewalla

Publikacja przychodzącej ścieżki SMTP

Dla poczty przychodzącej reguła DNAT tłumaczy publiczny adres WAN na wewnętrzny serwer pocztowy. Original Source jest ograniczany tak ściśle, jak pozwala projekt poczty; Original Destination to przewidziany adres publiczny; Translated Destination to 10.20.30.25 lub właściwy serwer pocztowy. Original service i translated service pozostają ograniczone do faktycznie udostępnianych portów SMTP.

Reguła reflexive tworzy również SNAT dla kierunku przeciwnego. Należy ją wybrać tylko wtedy, gdy dokładnie ta publiczna tożsamość źródłowa jest przeznaczona dla ścieżki wychodzącej. Wiele łączy WAN, smarthosty lub odmienne trasy operatorów wymagają własnego projektu routingu i SNAT. Ogólną kolejność oraz strefę docelową po NAT opisuje artykuł Publikacja serwera przez DNAT.

Użycie dwóch precyzyjnych reguł firewalla

Podczas weryfikacji osobne reguły są bardziej czytelne niż jedna dwukierunkowa reguła z wieloma strefami i obiektami Any:

• Przychodząca: z WAN do strefy wewnętrznego serwera pocztowego, host docelowy 10.20.30.25, tylko wymagane usługi SMTP, włączone logowanie
• Wychodząca: strefa i host wewnętrznego serwera pocztowego do WAN lub konkretnego smarthosta, tylko wymagane usługi SMTP, włączone logowanie

W Scan email content w obu wymaganych kierunkach należy włączyć Scan SMTP, a Scan SMTPS tylko wtedy, gdy SMTPS jest rzeczywiście używany. Zaznaczone pole nie dodaje automatycznie brakującej usługi do poprawnego projektu zabezpieczeń. Usługa, NAT, listener serwera i opcja skanowania muszą opisywać tę samą ścieżkę portu.

Reguły należy umieścić nad bardziej ogólnymi regułami, które już pasują do tego samego ruchu. Po zapisaniu decydująca jest zarejestrowana Firewall Rule ID. Strukturę reguł, strefę NAT i kolejność opisuje artykuł Bezpieczna konfiguracja reguł Sophos Firewall.

Weryfikacja przepływu poczty i skanowania proxy

Najpierw należy wysłać małą zewnętrzną wiadomość do skrzynki testowej. Następnie wewnętrzny serwer pocztowy wysyła drugą wiadomość do kontrolowanego odbiorcy zewnętrznego. Oba testy otrzymują unikalne tematy i znaczniki czasu UTC.

Dla STARTTLS na porcie 25 i bezpośredniego połączenia TLS na porcie 465 mogą pomóc następujące kontrole tylko do odczytu z autoryzowanego systemu testowego:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

mail.example.net należy zastąpić rzeczywistym FQDN i testować tylko faktycznie oferowane porty. OpenSSL potwierdza osiągalność, łańcuch certyfikatów i wynegocjowane parametry TLS. Nie potwierdza pomyślnego dostarczenia poczty ani skanowania malware, spamu lub Data Control.

W Log Viewer źródło, cel, usługa, akcja i Firewall Rule ID muszą odpowiadać nowym regułom. Dla proxy Legacy SMTP/S należy skorelować awarrensmtp.log i awarrenmta.log z tym samym czasem. Pliki logów opisano w artykule Usługi i logi Sophos Firewall.

Następnie wykonuje się test negatywny. Nieprzewidziane źródło, niedozwolony port lub wiadomość testowa bez kryterium polityki nie mogą przypadkowo otrzymać tej samej ścieżki ochrony. W testach produkcyjnych nie używa się prawdziwego malware; do weryfikacji skanowania służą uznane nieszkodliwe wzorce testowe i kontrolowana skrzynka.

Ograniczanie błędów według objawu

SMTP działa, ale polityka nie jest stosowana

Najpierw należy sprawdzić Firewall Rule ID. Jeśli dopasowana jest inna reguła, trzeba poprawić kolejność, źródło, cel, cel NAT i usługę. Jeśli pasuje oczekiwana reguła, Scan SMTP lub Scan SMTPS, kolejność polityk oraz grupy nadawców i odbiorców muszą odpowiadać testowi. Sama polityka nie aktywuje przezroczystego proxy.

Poczta przychodząca nie dociera do serwera

Oddzielnie sprawdzić publiczny adres docelowy, trafienie DNAT, translated destination, strefę docelową, listener serwera i ścieżkę powrotną. Otwarte połączenie TCP do firewalla nie dowodzi, że DNAT i reguła firewalla docierają do serwera wewnętrznego. Packet Capture i Rule ID muszą pokazywać wejście i przekazanie.

Poczta wychodząca używa niewłaściwego publicznego adresu IP

Sprawdzić SNAT, regułę reflexive, gateway WAN, trasę SD-WAN i zachowanie reply packets. Proxy Legacy nie wybiera automatycznie publicznego adresu źródłowego wymaganego przez SPF, RDNS lub autoryzację operatora. Przed globalną zmianą Route Precedence trzeba potwierdzić konkretną ścieżkę.

TLS przestaje działać po włączeniu skanowania

Należy zapisać FQDN, docelowy adres IP, certyfikat, wystawcę, łańcuch i wynegocjowaną wersję. Przy wielu domenach na jednym adresie IP przyczyną może być udokumentowana kontrola certyfikatu oparta na IP. Allow invalid certificate nie jest włączane jako szybkie rozwiązanie.

Wiadomość zniknęła, a w MTA mail spool nic nie ma

Nie jest to użyteczne kryterium powodzenia w Legacy mode, ponieważ mail spool i specyficzne dla MTA mail logs należą do MTA mode. Istotny łańcuch obejmuje tu regułę firewalla, NAT, logi serwera SMTP, Log Viewer, awarrensmtp.log i awarrenmta.log. Wiadomości w kwarantannie sprawdza się osobno w Email > SMTP quarantine.

Bezpieczny rollback

W ramach rollbacku najpierw przywraca się reguły pilotażowe i opcje skanowania do udokumentowanego stanu poprzedniego. Następnie usuwa się nowe przypisania polityk lub przywraca ich kolejność. Tymczasowe zmiany DNAT, SNAT lub certyfikatów usuwa się tylko wtedy, gdy nie zależy od nich żadna inna usługa.

Dopiero potem przywraca się SMTP Deployment Mode, jeśli zmiana obejmowała to przełączenie. Pierwotny przychodzący i wychodzący przepływ poczty musi ponownie działać z oczekiwanymi Rule IDs, adresami publicznymi i logami serwera. Wiadomości, zawartość kwarantanny ani logi proxy nie są usuwane jako standardowy rollback.

Lista kontrolna eksploatacji

• Przezroczyste proxy wybrano świadomie, a wymagania MTA zostały wykluczone.
• Backup, dostęp administracyjny i pierwotne Rule IDs są udokumentowane.
• Limit rozmiaru SMTP, akcja dla zbyt dużych wiadomości, IP Reputation i limity DoS są uzasadnione.
• Certyfikat, wyjątki TLS i dotknięte domeny zostały sprawdzone.
• DNAT, SNAT, strefa docelowa i rzeczywiste porty serwera są zgodne.
• Reguły firewalla dla ruchu przychodzącego i wychodzącego są precyzyjne, logowane i faktycznie dopasowane.
• Polityki domyślne i własne mają możliwą do prześledzenia kolejność.
• Opcjonalny journaling jest ograniczony do wymaganych odbiorców i ma udokumentowany cel ochrony oraz przechowywania danych.
• Testy pozytywny, negatywny, TLS i dostarczania zakończyły się powodzeniem.
• Logi proxy Legacy i serwera pocztowego można skorelować czasowo.
• Właściciel, data przeglądu i pełna ścieżka powrotu są zapisane.

FAQ