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 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. Należy użyć obowiązkowego wpisu Exchange Online dla *.mail.protection.outlook.com i *.mx.microsoft na TCP 25 (ID endpointu 10 w instancji Worldwide), a nie znacznie większego zbioru wszystkich adresów Exchange Online. Inna instancja chmury Microsoft wymaga właściwej dla niej listy. 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 SMTP z tego wpisu Microsoft, na przykład z prefiksem O365_EOP_. Nie łączyć zakresów w większą sieć. Jeśli SMTP jest publikowany lub routowany przez IPv6, trzeba objąć kontrolą również wymienione zakresy IPv6; w przeciwnym razie należy wykluczyć niezamierzoną ścieżkę IPv6 omijającą kontrolę IPv4. Po zmianie listy Microsoft sieci dodaje się lub usuwa w ramach kontrolowanej zmiany 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 oddzielnie określa sieci, z których przyjmowane są wiadomości przychodzące do chronionych domen; uprawnienie to nie daje tym źródłom nieograniczonego relayu wychodzącego.

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 otworzyć Mail flow > Connectors > Add a connector i wybrać Connection from: Office 365 oraz Connection to: Partner organization. W sekcji Use of connector wybrać Only when email messages are sent to these domains i wpisać *, aby cały ruch wychodzący kierować przez SFOS. Celowo ograniczona lista domen musi odpowiadać udokumentowanemu projektowi. W sekcji Routing wybrać Route email through these smart hosts i użyć publicznego adresu IP lub FQDN mail.example.com firewalla. Pola te są zgodne z aktualną procedurą Sophos dla Microsoft 365.

W sekcji Security restrictions włączyć Always use Transport Layer Security (TLS) to secure the connection (recommended). Następnie procedura Sophos wybiera Any digital certificate, including self-signed certificates. Ten wybór wymusza TLS, ale nie sprawdza zaufanego urzędu certyfikacji ani nazwy. W środowisku produkcyjnym należy postępować zgodnie z dokumentacją łączników Microsoft: wybrać Issued by a trusted certificate authority (CA) i wymagać również nazwy podmiotu lub SAN mail.example.com. Nazwę tę trzeba zastąpić rzeczywistym FQDN firewalla i zweryfikować 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ć każde źródło, które rzeczywiście wysyła do Internetu. Sophos pokazuje prosty przykład v=spf1 include:spf.protection.outlook.com mx -all: mx autoryzuje adresy hostów MX, natomiast include:spf.protection.outlook.com pozostaje potrzebne, jeśli Exchange Online wysyła dla tej domeny również bezpośrednio do Internetu. Jeśli cała poczta zewnętrzna bez wyjątku wychodzi przez SFOS, nie należy z przyzwyczajenia autoryzować nieużywanej bezpośredniej ścieżki Microsoft. Istniejącego rekordu nie wolno zastępować bez analizy; najpierw trzeba zinwentaryzować inne usługi wysyłające, subdomeny, łańcuchy include oraz udokumentowany przez Microsoft limit SPF wynoszący dziesięć mechanizmów wywołujących zapytania DNS. Następnie prawdziwe nagłówki powinny potwierdzić powodzenie SPF dla ostatniego zaobserwowanego adresu IP nadawcy oraz zachowanie zgodności DKIM i DMARC.

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

Rollback przywraca udokumentowany stan poprzedni, a nie domyślne wartości ustalone na podstawie przypuszczeń. Najpierw należy dokładnie odtworzyć poprzedni stan aktywacji, zakres, routing i ustawienia TLS łącznika Exchange Online; wyłącza się go tylko wtedy, gdy utworzono go na potrzeby tej zmiany. Następnie trzeba przywrócić zapisane cele i priorytety MX oraz pełną poprzednią wartość TXT SPF. Autorytatywny DNS i kilka publicznych resolverów muszą zwracać stare wartości.

Politykę pilotażową, obiekty EOP i wpisy relayu należy zachować do czasu, gdy testy przychodzące i wychodzące znów będą działać po starej ścieżce i upłynie poprzedni TTL DNS. Następnie usuwa się tylko elementy utworzone na potrzeby tej zmiany; istniejące wcześniej lub współdzielone obiekty pozostają bez zmian.

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