Konfiguracja Sophos Firewall MTA z Microsoft 365

Sophos Firewall może działać w MTA mode jako osobna brama pocztowa przed Microsoft 365. Wiadomości przychodzące trafiają najpierw do firewalla, a następnie do Exchange Online Protection. Exchange Online wysyła wiadomości wychodzące przez łącznik z powrotem do firewalla, który je skanuje i przekazuje do Internetu.

Taka konstrukcja jest możliwa, ale nie zawsze stanowi najlepszą architekturę. Sophos Central Email, Microsoft Defender for Office 365 i lokalna Mail Protection częściowo się pokrywają. Przed zmianą trzeba ustalić, który system odpowiada za spam, malware, kwarantannę, TLS, DKIM i diagnostykę.

⚠️ Zbyt szeroka zgoda na relay może zmienić firewall w open relay. Przed zmianą rekordu MX należy zachować lokalną sesję administratora, dotychczasowy przepływ oraz przetestowaną ścieżkę powrotu. Przełączenie produkcyjne następuje dopiero, gdy nieautoryzowana próba relayu jest niezawodnie odrzucana.

Najpierw narysować dwukierunkowy przepływ

Ścieżka przychodząca to Internet → Sophos Firewall MTA → Exchange Online Protection → skrzynka Microsoft 365. Publiczny rekord MX wskazuje więc publiczny adres SMTP firewalla. Następnie polityka SMTP route and scan dostarcza wiadomość do celu Microsoft właściwego dla tenanta, na przykład example-com.mail.protection.outlook.com.

Ścieżka wychodząca to Exchange Online → łącznik Microsoft 365 → Sophos Firewall MTA → Internet. Firewall może przyjmować relay wyłącznie z aktualnych sieci Exchange Online Protection. HELO, certyfikat, publiczny adres źródłowy, PTR/rDNS, SPF, DKIM i DMARC muszą odpowiadać tej ścieżce.

Konfiguracja Mail Protection w MTA mode wyjaśnia podstawy MTA, pola polityk, kwarantannę i logi. Ten artykuł skupia się na połączeniu z Microsoft 365.

Wartości przykładowe i wymagania

Przykład wykorzystuje domenę example.com, FQDN firewalla mail.example.com, adres dokumentacyjny 192.0.2.25 i cel tenanta example-com.mail.protection.outlook.com. Należy je zastąpić rzeczywistą domeną, stałym adresem publicznym i właściwym celem Microsoft. 192.0.2.25 należy do TEST-NET i nie może być używany produkcyjnie.

TCP 25 musi działać z Internetu do firewalla, z firewalla do Microsoft 365 oraz z firewalla do zewnętrznych serwerów pocztowych. Potrzebne są także odpowiednia licencja Email Protection, obsługa MTA przez model, publicznie zaufany certyfikat, kontrolowany DNS oraz uprawnienia do Exchange Admin Center i autorytatywnego DNS.

Sieci Exchange Online Protection zmieniają się. Nie należy kopiować ich ze statycznego przykładu, lecz utrzymywać z aktualnej listy endpointów Microsoft 365, do której odsyła Sophos. Dla tego przepływu szczególnie istotne są endpointy SMTP na TCP 25. Obiekty hostów muszą mieć właściciela i harmonogram przeglądu.

Połączenie Microsoft 365 i SFOS w ośmiu krokach

1. Zapisać bieżący MX, SPF, łączniki, nagłówki, publiczny adres źródłowy i ścieżkę powrotu.
2. Przygotować MTA mode, automatyczną regułę MTA, certyfikat i skanowanie wychodzące na SFOS.
3. Utworzyć osobne obiekty IP host dla aktualnych zakresów EOP.
4. Zezwolić na SMTP Relay z WAN, ograniczyć Host-based relay do obiektów EOP i zablokować inne źródła.
5. Utworzyć politykę SMTP route and scan dla chronionej domeny i celu Microsoft tenanta.
6. Utworzyć w Exchange Online łącznik z Microsoft 365 do publicznego adresu firewalla.
7. Zmienić MX i SPF w oknie serwisowym.
8. Zweryfikować wiadomości przychodzące, wychodzące i odrzucone próby relayu przy użyciu nagłówków, Mail logs, spool i trace Microsoft.

Przygotowanie Sophos Firewall

MTA mode, reguła automatyczna i certyfikat

W Email > General settings włączyć MTA mode. SFOS tworzy Auto added firewall policy for MTA dla SMTP i SMTPS. Reguły nie należy edytować i zgodnie z zaleceniem Sophos powinna pozostać na górze. Jeśli brakuje jej mimo aktywnego MTA mode, nie tworzyć zamiennika Any-to-Any; najpierw sprawdzić tryb, konfigurację i ścieżkę wsparcia.

W SMTP settings ustawić SMTP hostname na planowaną nazwę domeny. W SMTP TLS configuration wybrać publicznie zaufany certyfikat i pozostawić Allow invalid certificate wyłączone. Scan outgoing mails musi być aktywne, jeśli skanowane są również wiadomości z Exchange Online.

Zezwolenie na relay ze źródeł EOP

W Hosts and services > IP host utworzyć czytelnie nazwany obiekt dla każdego aktualnego zakresu IPv4 EOP, na przykład z prefiksem O365_EOP_. Nie łączyć zakresów w większą sieć. Po zmianie listy Microsoft sieci dodaje się lub usuwa kontrolowanym change’em i ponownie testuje.

W Administration > Device access włączyć SMTP Relay dla WAN. Sam przełącznik strefy jest zbyt szeroki, dlatego ogranicza się go w Email > Relay settings > Host-based relay:

• Allow relay from hosts/networks: wyłącznie utrzymywane obiekty EOP;
• Block relay from hosts/networks: Any.

Sophos ocenia pasujący wpis Allow przed nakładającym się Block. Dlatego lista Allow nie może zawierać szerokich sieci operatora, chmury ani Any. Upstream host steruje oddzielną relacją docelową i nie zastępuje tej kontroli źródła.

Dla zwykłej poczty przychodzącej z Internetu procedura Sophos ustawia natomiast Upstream host > Allow relay from hosts/networks na Any. Pozwala to zewnętrznym hostom SMTP dostarczać do chronionych domen i nie jest tą samą zgodą co wychodzący Host-based relay. Jeśli przed SFOS działa już określona zewnętrzna brama pocztowa, lista Upstream zostaje ograniczona do jej rzeczywistych sieci źródłowych.

Polityka route and scan dla dostarczania do Microsoft

W Email > Address group utworzyć chronioną domenę jako Email address/domain. Następnie w Email > Policies and exceptions > Add a policy > SMTP route and scan dodać politykę zawierającą:

• Address Group w Protected domain;
• Global action: Accept;
• Route by: DNS host oraz cel Microsoft właściwy dla tenanta;
• świadomie wybrane ustawienia ochrony spamu, malware, plików i danych.

Host routingu nie jest publicznym rekordem MX example.com, gdy wskazuje on już firewall. W przeciwnym razie firewall dostarcza do samego siebie i tworzy pętlę. Rzeczywisty cel Microsoft należy zapisać przed zmianą MX i sprawdzić jego poprawne rozwiązywanie przez SFOS.

Utworzenie łącznika Exchange Online

W Exchange Admin Center utworzyć w Mail flow > Connectors łącznik From: Office 365 i To: Partner organization. Aby cały ruch wychodzący przechodził przez SFOS, warunek docelowy obejmuje wszystkie domeny odbiorców (*). Celowo ograniczony podzbiór musi odpowiadać udokumentowanemu projektowi. Smarthostem jest publiczny adres IP lub FQDN mail.example.com firewalla.

Dla łącznika wymagać TLS. Pomoc Sophos pokazuje także zgodną opcję akceptującą dowolny certyfikat cyfrowy, w tym samopodpisany. W produkcji bardziej niezawodny jest publicznie zaufany certyfikat o tożsamości zgodnej z FQDN, sprawdzony realnym testem łącznika.

Walidacja łącznika może nie udać się przed zmianą DNS. Nie zastępuje zatem późniejszego testu end-to-end ani negatywnego testu relayu. Po zapisaniu Microsoft Message Trace musi potwierdzić, że ruch wychodzący rzeczywiście używa planowanego łącznika i firewalla.

Kontrolowana zmiana MX i SPF

Publiczny MX wskazuje mail.example.com dopiero po przygotowaniu polityki, relayu EOP, wewnętrznego celu Microsoft i łącznika. TTL obniża się przed oknem serwisowym. Stary cel MX pozostaje dostępny dla udokumentowanego rollbacku, lecz nie równolegle, jeśli nadawcy mogliby losowo omijać nowy tor ochrony.

SPF musi autoryzować Exchange Online i publiczną tożsamość nadawczą firewalla. Sophos pokazuje prosty przykład v=spf1 include:spf.protection.outlook.com mx -all. Nie należy ślepo zastępować istniejącego rekordu: najpierw zinwentaryzować inne systemy wysyłające, subdomeny, łańcuchy include i limit zapytań DNS. DKIM i DMARC ponownie sprawdza się w prawdziwych nagłówkach.

Weryfikacja całej ścieżki

Z zewnętrznego systemu testowego pomagają następujące odczyty:

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

Nazwy przykładowe zastępuje się rzeczywistymi. DNS, TCP i TLS nie dowodzą dostarczenia. Należy przetestować co najmniej wiadomość zewnętrzną do Microsoft 365, wychodzącą z Microsoft 365, nieprawidłowego odbiorcę oraz próbę relayu z niedozwolonego adresu źródłowego.

Na SFOS skorelować Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log i smtpd_error.log z tym samym czasem. Po stronie Microsoft Message Trace i stan łącznika pokazują, czy EOP przyjął lub wysłał wiadomość. Usługi i logi Sophos Firewall opisują pliki logów.

Ograniczanie błędów według objawu

Poczta zewnętrzna nie dociera do Microsoft 365

Najpierw sprawdzić MX, publiczny adres, TCP 25, SMTP Relay z WAN, automatyczną regułę MTA i Mail logs. Jeśli SFOS przyjmuje, ale nie dostarcza, sprawdzić DNS celu tenanta, politykę route and scan, TLS i spool.

Poczta wychodząca omija firewall

Sprawdzić zakres i priorytet łącznika oraz Message Trace w Exchange Admin Center. Dopiero gdy trace pokazuje firewall jako smarthost, ocenić dopasowanie relayu SFOS, politykę i publiczny adres źródłowy. Przy wielu WAN skorzystać z odpowiedniej sekcji Mail Protection w MTA mode.

Relay jest odrzucany lub byłby dozwolony zbyt szeroko

Porównać rzeczywisty adres źródłowy EOP z aktualną listą Microsoft i obiektami SFOS. Dozwolona sieć EOP musi znajdować się w Allow relay from hosts/networks; pozostałe źródła trafiają do Block relay from hosts/networks: Any. Szeroka zgoda dla chmury lub WAN nie jest naprawą.

TLS lub walidacja łącznika nie działa

Oddzielnie sprawdzić FQDN, publiczny DNS, nazwę certyfikatu, pełny łańcuch, ważność i STARTTLS. Udany openssl s_client potwierdza endpoint firewalla, ale nie zakres łącznika ani pełne dostarczenie. Allow invalid certificate nie jest trwałym obejściem.

Powstaje pętla pocztowa

Porównać publiczny MX z celem polityki SMTP route and scan. Jeśli oba wskazują mail.example.com, ustawić w polityce cel Microsoft tenanta. Do czasu jednoznacznego routingu przywrócić udokumentowaną starą ścieżkę.

Bezpieczny rollback

Najpierw wyłączyć łącznik Exchange Online lub przywrócić jego poprzedni stan. Następnie przywrócić MX i SPF oraz sprawdzić ich publiczne rozwiązywanie. Politykę pilotażową, obiekty EOP i wpisy relayu usuwa się z SFOS dopiero po poprawnym działaniu testów przychodzących i wychodzących po starej ścieżce.

Nie usuwać bez sprawdzenia wiadomości ze spoolu ani kwarantanny. Są częścią udokumentowanej zmiany i wymagają oceny nadawcy, odbiorcy oraz zamierzonej ścieżki dostarczenia.

Lista kontrolna eksploatacji

• Odpowiedzialność SFOS, Microsoft 365 i innych bram została ustalona.
• Poprzedni MX, SPF, łącznik i przepływ są udokumentowane jako powrót.
• Obiekty EOP pochodzą z aktualnej listy Microsoft i mają właściciela.
• SMTP Relay działa tylko przez precyzyjne wpisy Host-based relay; nieautoryzowane źródła są odrzucane.
• Polityka route and scan wskazuje cel Microsoft tenanta, a nie publiczny MX.
• Łącznik, certyfikat, DNS, MX, SPF, DKIM i DMARC zweryfikowano prawdziwymi wiadomościami.
• Testy przychodzący, wychodzący, nieprawidłowego odbiorcy i nieautoryzowanego relayu zakończyły się powodzeniem.
• Mail logs, spool, kwarantannę i Microsoft Message Trace można skorelować czasowo.
• Sieci EOP i wygaśnięcie certyfikatu są regularnie przeglądane.

FAQ