Skonfiguruj Sophos Firewall Mail Protection w MTA Mode

Sophos Firewall może akceptować ruch SMTP w samym MTA Mode, sprawdzać go i przekazywać do wewnętrznego serwera pocztowego lub do następnego skoku pocztowego. Zapora sieciowa to zatem nie tylko wersja portu dla protokołu TCP 25, ale aktywny agent przesyłania poczty z routingiem, sprawdzaniem spamu i złośliwego oprogramowania, kwarantanną, buforowaniem i dziennikami poczty.

Obecnie polecamy Mail Protection na zaporze ogniowej, szczególnie w przypadku celowo zaplanowanych scenariuszy lokalnych lub hybrydowych, na przykład jeśli lokalny serwer Exchange lub inny wewnętrzny serwer pocztowy ma być chroniony bezpośrednio przez zaporę. W przypadku Microsoft 365, Google Workspace i wielu nowoczesnych środowisk poczty w chmurze Sophos Central Email lub inna brama poczty w chmurze jest zwykle czystszą architekturą, ponieważ MX, kwarantanna, nagłówki, TLS, SPF/DKIM/DMARC i obsługa są bliższe rzeczywistej usłudze pocztowej.

Jeśli Mail Protection jest użyte w MTA Mode, artykuł musi zawierać więcej niż tylko deklarację funkcji: rekord MX, automatyczna reguła MTA, trasa SMTP i zasady skanowania, zwalnianie przekaźników, TLS, weryfikacja użytkownika, buforowanie, kwarantanna i dzienniki muszą być zgodne. W przeciwnym razie zapora sieciowa może odrzucać prawidłowe wiadomości e-mail, opóźniać wysyłanie wiadomości e-mail lub w sposób niezamierzony stać się osiągalna jako przekaźnik.

Kiedy Mail Protection ma sens na zaporze

Mail Protection na Sophos Firewall jest szczególnie przydatne, jeśli ruch SMTP ma świadomie przechodzić przez zaporę, a zapora ma robić więcej niż tylko przekazywanie portu 25.

Typowe scenariusze:

• Przychodzące wiadomości e-mail powinny być najpierw akceptowane i sprawdzane w zaporze.
• Wewnętrzny serwer poczty nie powinien być dostępny bezpośrednio z Internetu.
• Spam, złośliwe oprogramowanie, typ pliku i zawartość powinny zostać sprawdzone przed dostawą.
• Wychodzące wiadomości e-mail powinny być wysyłane w sposób kontrolowany przez zaporę sieciową lub inteligentny host.
• Na zaporze powinno być możliwe śledzenie dzienników kwarantanny, buforowania poczty i SMTP.

Nie każda konfiguracja poczty powinna przebiegać przez zaporę. Jeśli Sophos Central Email, Microsoft Defender dla Office 365 lub inna bramka pocztowa w chmurze przejmuje już cały przepływ poczty, nie należy dodatkowo przełączać Mail Protection na zaporze sieciowej bez szczegółowego dokumentowania przepływu poczty. Zduplikowane bramy szybko prowadzą do niejasnych odpowiedzialności za kwarantannę, nagłówki, SPF/DKIM/DMARC, TLS i rozwiązywanie problemów.

Rozróżnij MTA Mode, Legacy Mode i SMTP Relay

Za pomocą Sophos Firewall musisz wyraźnie oddzielić trzy rzeczy:

• MTA Mode: Zapora sieciowa akceptuje, sprawdza i dostarcza pocztę elektroniczną. Odpowiada to przychodzącemu i wychodzącemu przepływowi poczty SMTP zgodnie z zasadami.
• Legacy Mode: Starsze przetwarzanie poczty oparte na proxy. Dotyczy istniejących środowisk, które są migrowane lub celowo nadal działają.
• SMTP Relay jako usługa lokalna: Systemy wewnętrzne przesyłają dane przez zaporę ogniową. Typowymi przykładami są drukarki, skanery, aplikacje lub systemy monitorowania.

MTA Mode to normalny tryb docelowy w nowoczesnych scenariuszach ochrony poczty za pomocą zapory ogniowej. Natomiast usługa lokalna SMTP Relay to temat dotyczący dostępu do urządzenia. Powinien być dostępny tylko z określonych sieci wewnętrznych. Zbyt szerokie zwolnienie może zachęcać do nadużywania przekaźników. Wzmacnianie usług lokalnych opisano w Sophos Firewall Zabezpieczenie dostępu: Device Access poprawnie skonfigurowane.

Wymagania wstępne

Przed konfiguracją należy wyjaśnić następujące kwestie:

• Sophos Firewall z ważną ochroną poczty e-mail lub odpowiednim pakietem.
• Nie każdy model obsługuje MTA Mode. XGS 87/87w i XGS 88/88w to urządzenia nie obsługujące trybu MTA.
• Znana jest publiczna strefa DNS i rekord MX.
• Wewnętrzny serwer poczty, port docelowy i trasa dostawy są udokumentowane.
• Zdefiniowano publiczny adres IP lub adres WAN dla przychodzącego ruchu SMTP.
• Zapora może kierować i docierać do wewnętrznego serwera poczty.
• Dostęp wychodzący DNS zapory sieciowej działa.
• Wyjaśniono pożądaną strategię TLS i certyfikatów.
• Proces kwarantanny i zwalniania jest zdefiniowany organizacyjnie.

Przed wprowadzeniem zmian w przepływie poczty należy zaplanować okres konserwacji. Testowanie na produktywnych rekordach MX bez planu awaryjnego jest ryzykowne, ponieważ przychodzące e-maile są szybko opóźniane lub odrzucane, w zależności od nadawcy.

Ustaw architekturę docelową

Najpierw powinieneś zdecydować, w jakim kierunku zapora powinna przetwarzać dane.

Przepływ poczty przychodzącej

W przepływie poczty przychodzącej zewnętrzne rekordy MX wskazują adres publiczny, za pośrednictwem którego Sophos Firewall akceptuje SMTP. Zapora sieciowa sprawdza wiadomość i przekazuje ją do wewnętrznego serwera pocztowego.

Typowy przepływ:

1. Zewnętrzny nadawca łączy się z publicznym adresem MX poprzez SMTP.
2. Sophos Firewall akceptuje połączenie w MTA Mode.
3. Mail Protection sprawdza nadawcę, odbiorcę, spam, złośliwe oprogramowanie, załączniki i zasady.
4. Zapora dostarcza pocztę e-mail do wewnętrznego serwera poczty.
5. Wewnętrzny serwer poczty dostarcza wiadomość do skrzynki pocztowej lub dalej ją przetwarza.

Ważne jest, aby wewnętrzny serwer poczty nie pozostawał dostępny z Internetu w stanie niefiltrowanym. Jeśli reguła DNAT wskazuje jednocześnie bezpośrednio na serwer pocztowy, część ruchu może ominąć Mail Protection. W przypadku normalnego publikowania serwerów odpowiednią podstawą jest publikowanie serwera za pośrednictwem DNAT, ale w przypadku MTA Mode zapora sieciowa sama w sobie jest punktem akceptacji SMTP.

Przepływ poczty wychodzącej

W przypadku przepływu poczty wychodzącej wewnętrzny serwer poczty wysyła za pośrednictwem Sophos Firewall. Zapora sieciowa może sprawdzać wiadomości, przekazywać je do inteligentnego hosta lub dostarczać bezpośrednio, w zależności od konfiguracji.

Wyjaśnij wcześniej:

• Czy publiczny adres IP zapory sieciowej umożliwia bezpośrednie wysyłanie wiadomości e-mail?
• Czy SPF, DKIM i DMARC są prawidłowe dla wybranej metody dostawy?
• Czy wymagany jest inteligentny host dostawcy?
• Czy wychodzący ruch SMTP musi być ograniczony do określonych systemów wewnętrznych?
• Gdzie monitorowane są wiadomości odrzucone lub opóźnione?

Dla ruchu poczty wychodzącej należy stosować oddzielną, zrozumiałą strukturę reguł i zasad. Ogólna zasada LAN to WAN bez wyraźnych ograniczeń jest zwykle zbyt surowa dla serwerów pocztowych. Podstawy sekwencji reguł i profili zabezpieczeń można znaleźć w Sophos Firewall Zrozumienie reguł i ich przejrzyste budowanie.

Przygotuj konwersję MX i testy zewnętrzne

Zmiana w zakresie ochrony poczty staje się krytyczna dopiero wtedy, gdy nadawcy zewnętrzni rzeczywiście korzystają z nowej metody. Dlatego powinieneś sprawdzić rekord MX, DNS-TTL, dostępność zewnętrzną i wycofanie zmian przed produktywną zmianą.

Przed zmianą:

• Udokumentuj bieżący rekord MX, priorytet i TTL.
• DNS-TTL zmniejsza się wcześnie, gdy może być konieczne szybkie przywrócenie.
• Wyraźnie rozróżnij starą ścieżkę poczty od nowego adresu zapory sieciowej Sophos.
• Zidentyfikuj stare bezpośrednie reguły DNAT na serwerze pocztowym.
• Zdefiniuj odbiorcę testu i nadawcę testu.
• Ustaw plan awaryjny: stary MX, stara reguła DNAT lub tymczasowy inteligentny host.
• Przygotuj monitorowanie buforu, kwarantanny i kolejki serwera poczty.

Przydatne kontrole zewnętrzne z System spoza własnej 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 przepływu poczty, ale szybko pokazują, czy DNS, port 25 i STARTTLS są ogólnie dostępne. example.com i mail.example.com należy zastąpić prawdziwym hostem domeny i poczty.

Po przełączeniu należy natychmiast wysłać przychodzącą wiadomość testową i udokumentować całą ścieżkę:

• Połączenie widoczne w Log Viewer?
• Wpis w smtpd_main.log istnieje?
• Sprawdzenie odbiornika powiodło się?
• Nastąpiło dostarczenie do wewnętrznego serwera poczty?
• Wiadomość dotarła do skrzynki odbiorczej?
• Brak równoległej bezpośredniej dostawy poza MTA?

Jeśli zapora akceptuje wiadomości e-mail, ale ich nie dostarcza, nie należy natychmiast resetować modułu MX. Najpierw wyjaśnij, czy jest to problem z routingiem wewnętrznym, DNS, TLS lub serwerem pocztowym. Jeśli jednak zewnętrzni nadawcy nie mogą nawiązać połączenia z zaporą sieciową lub prawidłowe wiadomości e-mail są powszechnie odrzucane, szybki powrót do poprzedniej ścieżki e-mail często ma większy sens niż długotrwałe eksperymentowanie z produktywną ścieżką MX.

Aktywuj MTA Mode

Podstawowe ustawienia znajdują się w:

Email > General settings

Ta instrukcja wymaga, aby tryb MTA był aktywny. Jeśli zapora sieciowa nadal działa w Legacy Mode, przełączenie odbywa się za pomocą Przełącz do trybu MTA.

Po włączeniu Sophos Firewall automatycznie tworzy regułę zapory dla SMTP/SMTPS o nazwie Automatycznie dodano politykę zapory dla MTA. Reguła ta powinna pozostać widoczna i wysoko w bazie reguł. Reguły MTA nie można traktować jak zwykłej reguły LAN-to-WAN ani przypadkowo przesuwać w dół, w przeciwnym razie przychodzący ruch SMTP nie będzie już trafiał na oczekiwaną ścieżkę MTA.

Następnie sprawdzane są ustawienia podstawowe:

1. Ustaw nazwę hosta SMTP w Ustawienia SMTP. Jest to nazwa hosta używana przez zaporę w kontekstach HELO i banerach dla wiadomości generowanych przez system. Nie wprowadzaj na ślepo nazwy wewnętrznego serwera poczty, jeśli nazwa poczty publicznej jest inna.
2. Włącz opcję Odrzuć na podstawie reputacji IP, jeśli przychodzące połączenia SMTP mają być odrzucane ze względu na złą reputację nadawcy.
3. W obszarze Konfiguracja SMTP TLS wybierz odpowiedni publicznie zaufany certyfikat, jeśli protokół SMTP TLS powinien być prawidłowo prezentowany przez zaporę ogniową.
4. Aktywuj Wyłącz starsze protokoły TLS, chyba że istnieją celowo udokumentowane starsze systemy.
5. Aktywuj opcję Skanuj pocztę wychodzącą, jeśli wiadomości wychodzące z serwera pocztowego powinny być również sprawdzane przez zaporę ogniową.

W istniejących środowiskach nie należy po prostu przełączać się między Legacy Mode i MTA Mode bez testowania przepływu poczty. Przetwarzanie, dzienniki i logika polityki różnią się. Przed migracją należy udokumentować bieżącą konfigurację zapory sieciowej, rekordy MX, złącza serwera pocztowego i ustawienia przekaźnika.

Skonfiguruj routing i domeny SMTP

W przypadku przychodzących wiadomości e-mail zapora musi wiedzieć, które domeny akceptować i gdzie je dostarczać.

Utwórz grupę adresową dla domen pocztowych

Najpierw tworzona jest grupa adresów dla chronionych domen pocztowych:

1. Otwórz Email > Address group.
2. Kliknij Add.
3. Sprawdź Typ grupy dla Adres e-mail/domena.
4. Pozostaw Typ opcję Ręcznie, jeśli domeny są utrzymywane ręcznie.
5. Wpisz domenę w Adres e-mail/domena, na przykład example.com i dodaj ją.
6. Kliknij Save.

Dotyczy to domen, a nie indywidualnych adresów odbiorców. W zależności od konfiguracji można nadal używać pojedynczych istniejących lub przeniesionych adresów e-mail, ale nie można ich już planować jako nowych wpisów w bieżących zasadach trasowania i skanowania SMTP. Aby osiągnąć czysty stan docelowy, należy zatem popracować nad domenami i sprawdzić odpowiednie adresaty.

Utwórz politykę trasowania i skanowania SMTP

Rzeczywista polityka MTA jest tworzona w następującej ścieżce:

Email > Policies and exceptions > Add a policy > SMTP route and scan

Typowy przepływ wiadomości e-mail przychodzących do wewnętrznego serwera poczty:

1. Ustaw opisową nazwę, na przykład Inbound example.com to Exchange.
2. Wybierz wcześniej utworzoną grupę adresową w obszarze Domena chroniona.
3. Ustaw Trasa według:
   • Host statyczny: Dla stałych adresów IP wewnętrznego serwera poczty.
   • DNS host: Dla nazwy DNS, takiej jak mailserver.example.com.
   • MX: Jeśli zapora sieciowa powinna dostarczać dane w oparciu o rekordy MX.
4. W polu Host statyczny wybierz wewnętrzny serwer poczty w obszarze Lista hostów. W razie potrzeby hosty IP są tworzone pod Hosts and services > IP host.
5. Ustaw Akcję globalną na Accept, jeśli domena ma zostać zaakceptowana i sprawdzona pod kątem zasad.
6. Aktywuj Ochronę przed spamem i świadomie decyduj, czy spam ma być ostrzegany, poddawany kwarantannie, usuwany czy dostarczany bez działania.
7. Włącz Ochronę przed złośliwym oprogramowaniem. W przypadku Zero-Day Protection z pojedynczym skanowaniem antywirusowym, Sophos musi być używany jako silnik podstawowy.
8. Włącz Ochronę plików i Ochronę danych tylko wtedy, gdy znany jest wpływ na załączniki, duże wiadomości, SPX i DKIM.
9. Kliknij Save.

Jeśli istnieje kilka wewnętrznych serwerów pocztowych, ważny jest typ routingu. Host statyczny przełącza na następny host, jeśli pierwszy host jest nieosiągalny. W przypadku hosta DNS z wieloma rekordami A dostawa może zostać rozdzielona. Jest to praktyczne, ale musi pasować do projektu serwera pocztowego, certyfikatów TLS i analizy błędów.

DNS jest szczególnie ważny w przypadku wewnętrznych serwerów pocztowych. Zapora sieciowa musi być w stanie poprawnie rozpoznać wewnętrzne miejsca docelowe, a nadawcy zewnętrzni muszą dotrzeć do publicznego rekordu MX. Jeśli wewnętrzna rozdzielczość DNS odgrywa rolę, pomaga DNS skonfigurowanie tras żądań na Sophos Firewall.

Zaplanuj zasady dotyczące spamu, złośliwego oprogramowania i załączników

Mail Protection jest tak dobry, jak zasady, które faktycznie działają. Politykę należy nie tylko stworzyć, ale także nazwać i mieć jasny cel.

Ważne pytania dotyczące zasad:

• Których domen lub grup odbiorców dotyczy problem?
• Czy przetwarzany jest ruch pocztowy przychodzący, wychodzący lub dwukierunkowy?
• Co się stanie, jeśli pojawi się spam, złośliwe oprogramowanie, podejrzane załączniki lub niechciane typy plików?
• Czy wiadomości e-mail są blokowane, poddawane kwarantannie, dostarczane lub oznaczane nagłówkami?
• Czy należy stosować weryfikację odbiorcy poprzez objaśnienie czy Active Directory?
• Kto może sprawdzać wiadomości e-mail w kwarantannie i zwalniać je?
• Jakie są procesy fałszywie pozytywne?

Jeśli chodzi o ochronę przed spamem, SPF, RBL, Greylisting, BATV i weryfikacja odbiorcy nie powinny być traktowane jako zwykłe pola wyboru. Trafienia RBL lub SPF nie są przetwarzane jak zwykłe działania spamowe, ale mogą od razu odrzucić wiadomości. Weryfikacja odbiorców zmniejsza rozproszenie wsteczne i liczbę nieprawidłowych odbiorców, ale sama może stać się źródłem błędów w przypadku problemów z AD, TLS lub serwerem pocztowym.

DKIM jest szczególnie wrażliwy na wiadomości wychodzące. Szyfrowanie SPX, prefiksy tematów, blokowane typy plików, ochrona danych lub baner wychodzący mogą zmieniać nagłówki lub treść. Może to spowodować uszkodzenie skrótu DKIM w MTA odbiorcy. Jeśli podpisy wychodzące są ważne, należy zdecydować, czy podpisywanie ma nastąpić na serwerze pocztowym, na Sophos Firewall, czy na późniejszej bramce.

Jeśli używany jest Zero-Day Protection, można dodatkowo analizować podejrzane załączniki do wiadomości e-mail. Limity, raporty i decyzje o wydaniu wyjaśniono w artykule Sophos Firewall Zero-Day Protection zrozumienie i działanie.

Bezpieczny przekaźnik i Device Access

Częstym błędem jest pomylenie przepływu poczty MTA z otwartym SMTP Relay. Zapora sieciowa nie może być używana jako przekaźnik z jakiejkolwiek sieci.

W przypadku przychodzących wiadomości e-mail SMTP musi zawsze być akceptowany po stronie WAN, aby zewnętrzne serwery pocztowe mogły dostarczyć domenę. Jednakże w przypadku wychodzących wiadomości e-mail musi być jasne, które hosty wewnętrzne mogą przekazywać dane przez zaporę sieciową.

Sprawdź:

• Pod Administration > Device access, SMTP Relay jest aktywowane tylko w naprawdę wymaganych strefach.
• Kiedy używane jest ACL Exception Rules, źródła są wąsko zdefiniowane.
• W Email > Relay settings jako dozwolone źródła przekaźnika opartego na hoście wpisane są tylko zdefiniowane serwery pocztowe, skanery lub serwery aplikacji.
• Strefy, sieci gościnne i niezaufane sieci, które nie są wymagane, nie mogą przekazywać danych po całej płycie.
• Jeśli usługi w chmurze, takie jak Exchange Online Protection, mają być dostarczane lub przekazywane przez zaporę sieciową, należy bardzo precyzyjnie zachować dozwolone zakresy źródeł. Szerokie akcje Any stanowią ryzyko otwartego przekaźnika.
• Rejestrowanie jest aktywne, co pozwala wykryć niewłaściwe użycie lub błędną konfigurację.

Jeśli drukarki, skanery lub aplikacje muszą wysyłać wiadomości e-mail, należy udokumentować oddzielną wewnętrzną ścieżkę przekazywania. Takie systemy nie powinny komunikować się bezpośrednio z żadnymi zewnętrznymi miejscami docelowymi SMTP, jeśli środowisko może tego uniknąć.

Testuj przepływ poczty

Po konfiguracji pojedyncze pomyślne wysłanie nie wystarczy. Należy przeprowadzić kilka testów i udokumentować wyniki.

Przetestuj dokładnie

Sprawdź co najmniej:

• Zewnętrzny rekord MX wskazuje oczekiwany adres.
• Dostęp do portu 25 można uzyskać z zewnątrz.
• Zapora akceptuje połączenie w MTA Mode.
• Wiadomość e-mail jest przekazywana do wewnętrznego serwera poczty.
• Odbiorca istnieje i odbiera wiadomość.
• Test spamu lub złośliwego oprogramowania jest obsługiwany zgodnie z oczekiwaniami.
• Można prześledzić wpisy dotyczące kwarantanny lub dziennika.

Test wychodzący

Sprawdź co najmniej:

• Wewnętrzny serwer poczty wysyła oczekiwaną trasą.
• Obowiązuje reguła zapory sieciowej i zasady dotyczące poczty.
• SPF, DKIM i DMARC odpowiadają trasie wysyłki.
• Serwer docelowy akceptuje wiadomość.
• Monitorowane są wiadomości odsyłane i odroczone.
• Żaden inny system wewnętrzny nie wysyła danych bezpośrednio na zewnątrz bez planowania.

Sprawdź dzienniki

Log Viewer pomaga w szybkiej kontroli wizualnej. Pliki dziennika poczty są ważne dla głębszej analizy. Zadanie znajduje się w Sophos Firewall Rozwiązywanie problemów: Services i logi.

Odpowiednie pliki dziennika:

• SMTP MTA: smtpd_main.log.
• Błąd SMTP: smtpd_error.log, smtpd_panic.log i smtpd_reject.log.
• Antyspam: sasi.log.
• Starsza wersja SMTP/MTA: awarrensmtp.log, awarrenmta.log i awarrenmta_debug.log.
• Proxy POP/IMAP: warren.log.

Podczas rozwiązywania pilnych problemów należy zanotować czas testu, zebrać nadawcę, odbiorcę, temat, źródłowy adres IP i identyfikator wiadomości, a następnie powiązać Log Viewer i rejestrować pliki na czas.

Kwarantanna, buforowanie i przechowywanie

Mail Protection tworzy dane lokalne. W zależności od objętości wiadomości trafiają do kwarantanny, bufora lub obszarów tymczasowych. Dzięki temu miejsce na dysku, stan dysku SSD i plan odzyskiwania są bardziej istotne niż w przypadku czystej reguły zapory sieciowej.

Praktyczne zagadnienia operacyjne:

• Kto i jak często sprawdza kwarantannę?
• W jaki sposób uwalniane są fałszywe alarmy?
• Kiedy wiadomość jest usuwana zamiast publikowana?
• Jak wykryć rosnącą pulę poczty?
• Czy monitorowana jest przestrzeń dyskowa i stan System?
• Czy po aktualizacji oprogramowania sprzętowego zaplanowano krótki test przepływu poczty?

W przypadku tematów dotyczących przechowywania i raportowania odpowiednie są Sophos Firewall Oczyść pamięć i raporty i Sophos Firewall Sprawdź stan dysku SSD. W środowiskach HA należy również zauważyć, że dane dotyczące kwarantanny poczty i przetworzone dane pocztowe mogą być danymi operacyjnymi związanymi z węzłami. Podstawy HA są dostępne w Sophos Firewall wariantach klastrów HA.

Sprawdź kwarantannę bezpośrednio w WebAdmin

Gdy zapora sieciowa jest zarządzana poprzez Sophos Central, dostęp poprzez Centralę jest wygodny. W przypadku Mail Protection nadal powinieneś wiedzieć, gdzie lokalnie znajduje się kwarantanna i jak ją sprawdzić bezpośrednio na zaporze.

Ścieżka lokalna to:

Email > SMTP quarantine

Tam możesz filtrować wiadomości poddane kwarantannie według okresu, nadawcy, odbiorcy, tematu i powodu kwarantanny. Trzy działania są szczególnie istotne dla operacji:

• Usuń: Usuń wiadomość z kwarantanny.
• Zwolnienie: Zwolnij wiadomość do odbiorcy.
• Zwolnij i zgłoś: Zwolnij i zgłoś fałszywe alarmy do SophosLabs.

Ważne: wiadomości zainfekowanych wirusami i wiadomości sklasyfikowanych jako złośliwe przez Zero-Day Protection nie można łatwo udostępniać. Wpisy ochrony zero-day również wymagają odpowiednich uprawnień, jeśli mają zostać usunięte. Kiedy kwarantanna się zapełni, starsze e-maile zostaną usunięte. Jest to kolejny powód, aby nie sprawdzać kwarantanny i przechowywania, dopóki nie pojawią się skargi.

Istnieje ważny, specjalny przypadek dotyczący SFOS 22.0 MR1: Jeśli zarządzasz zaporą sieciową poprzez Sophos Central, akcje kwarantanny takie jak Zwolnij lub Usuń za pomocą Invalid API request mogą zakończyć się niepowodzeniem. Nie oznacza to automatycznie, że przepływ poczty, sama kwarantanna lub polityka MTA są złamane. Praktycznym rozwiązaniem jest zalogowanie się bezpośrednio do lokalnego WebAdmin zapory sieciowej i zwolnienie lub usunięcie tam wiadomości pod adresem Email > SMTP quarantine.

Po aktualizacji do SFOS 22.0 MR2 lub nowszej, powinieneś ponownie przetestować proces: poddać nieszkodliwą wiadomość testową kwarantannie, wykonać akcję zaplanowaną drogą administracyjną, a następnie sprawdzić Log Viewer, poddać kwarantannie i skrzynkę pocztową odbiorcy. Dzięki temu wiadomo, czy problem rzeczywiście został rozwiązany, czy też w grę wchodzą dodatkowe role, dostęp centralny lub uprawnienia lokalne.

Rozwiązywanie problemów

Zewnętrzne wiadomości e-mail nie docierają

Najpierw DNS i sprawdź dostępność: rekord MX, publiczny adres IP, port 25, starsze NAT, MTA Mode i odpowiedzialna domena pocztowa. Następnie sprawdź Log Viewer i smtpd_main.log, czy połączenie dociera do zapory ogniowej. Jeśli nie widać żadnego połączenia, problem prawdopodobnie tkwi w Mail Protection.

Zapora akceptuje wiadomości e-mail, ale ich nie dostarcza

W takim przypadku bardziej prawdopodobny jest wewnętrzny serwer poczty, routing, DNS, port docelowy, TLS, kontrola odbiorcy lub zasady. Sprawdzasz, czy zapora sieciowa może dotrzeć do serwera pocztowego i czy serwer pocztowy akceptuje połączenie. Dzienniki odrzuceń i dzienniki serwera pocztowego należy oceniać łącznie.

Wiele wiadomości e-mail pozostaje w kolejce

Rosnąca wartość buforu często wskazuje na problemy z dostarczaniem: wewnętrzny serwer poczty jest nieosiągalny, żądanie TLS nie pasuje, rozdzielczość DNS nie powiedzie się lub serwer docelowy odrzuca wiadomość. W takim przypadku nie wystarczy ponownie dostarczyć pojedyncze wiadomości, ale poszukać przyczyny w routingu i ścieżce SMTP.

Łatwo przeoczyć ważny przypadek kolejności reguł: jeśli automatycznie lub ręcznie utworzona reguła zapory sieciowej znajduje się powyżej reguły MTA i odpowiada ruchowi SMTP, rzeczywista reguła MTA nie jest już oceniana. Wtedy e-maile mogą utknąć w buforze poczty, mimo że DNS, port 25 i serwer pocztowy w zasadzie wyglądają poprawnie.

Sprawdź:

1. Otwórz Rules and policies > Firewall rules.
2. Sprawdź reguły powyżej reguły MTA lub SMTP.
3. Kontroluj nowe, automatycznie generowane reguły, reguły IPsec, reguły hotspotów lub reguły ręcznie ustawione na Top.
4. Uruchom ponownie test SMTP i porównaj Log Viewer, bufor poczty i smtpd_main.log.

Nie można ślepo przenieść reguły w dół, jeśli służy ona innym celom produkcyjnym. Liczy się to, czy nieoczekiwanie przechwytuje ruch SMTP przed regułą MTA.

Brak podsumowania kwarantanny dla aliasów adresów

Gdy użytkownicy korzystają z adresów aliasowych, ustawienia kwarantanny należy sprawdzać nie tylko dla podstawowego adresu e-mail. Według Sophos domyślnie ustawienia kwarantanny nie są automatycznie stosowane do aliasów. Jeśli brakuje e-maili z podsumowaniem lub komunikatów dla aliasów odbiorców, adresy aliasów należy wziąć pod uwagę razem z adresem głównym w kontekście kwarantanny lub użytkownika.

Raporty działań kwarantanny Nieprawidłowe żądanie API

Jeśli Zwolnienie lub Usunięcie nie powiedzie się z Invalid API request na zaporze otwartej przez Sophos Central, sprawdź najpierw wersję SFOS. W przypadku SFOS 22.0 MR1 dokładnie ten proces może zostać zakłócony.

Następnym krokiem nie jest przebudowywanie zasad poczty. Najpierw przejdź bezpośrednio do lokalnego WebAdmin zapory sieciowej i edytuj wiadomość w Email > SMTP quarantine. Następnie udokumentuj:

1. SFOS wersja i kompilacja.
2. Czy akcja została wykonana poprzez Sophos Central, czy bezpośrednio w WebAdmin.
3. Nadawca, odbiorca, temat i powód kwarantanny.
4. Wynik po teście bezpośrednio WebAdmin.
5. Czy aktualizacja do SFOS 22.0 MR2 lub nowszej jest planowana lub już zainstalowana.

Prawidłowy nadawca został wykryty jako spam

Na fałszywe alarmy nie należy natychmiast reagować, z wyjątkiem szerokich wyjątków. Najpierw sprawdź domenę nadawcy, SPF/DKIM/DMARC, nagłówki, reputację, zgodność z zasadami i odbiorców, których to dotyczy. Jeżeli konieczny jest wyjątek, powinien on być ściśle ograniczony i udokumentowany datą przeglądu.

Systemy wewnętrzne nie mogą przekazywać danych

Sprawdź, czy SMTP Relay jest dozwolone w ramach Administration > Device access z właściwej strefy i czy źródło odpowiada liście ACL. Następnie sprawdź dzienniki poczty. Jeśli skaner lub aplikacja ma przekazywać dane, źródło powinno być udokumentowane jako obiekt hosta, a nie niepotrzebnie zwalniana cała sieć.

Poczta działa inaczej po aktualizacji oprogramowania sprzętowego

Po aktualizacji oprogramowania sprzętowego należy sprawdzić MTA Mode, zasady, certyfikaty, bufor poczty, kwarantannę i odpowiednie dzienniki. W przypadku większych aktualizacji pasuje również Sophos Firewall przed SFOS 22 Sprawdź aktualizację.

Operacyjna lista kontrolna

• Mail Protection Sprawdzono obsługę licencji i urządzeń.
• MTA Mode celowo wybrany i udokumentowany.
• Rekord MX, publiczny adres IP i wewnętrzny serwer docelowy są prawidłowe.
• Przygotowano konwersję MX, testy zewnętrzne i wycofywanie zmian.
• Żadna równoległa, niefiltrowana reguła DNAT nie omija MTA.
• Zasady przychodzące i wychodzące są wyraźnie nazwane.
• Grupa adresowa chronionych domen jest utrzymywana w porządku.
• Kolejność reguł zapory nie uniemożliwia zastosowania reguły MTA.
• TLS, DKIM, Banner, SPX i Data Protection są sprawdzane pod kątem skutków ubocznych.
• SMTP Relay jest dozwolone tylko ze zdefiniowanych źródeł wewnętrznych.
• Ustawiono procesy kwarantanny i fałszywie pozytywne.
• Aliasy adresów są uwzględniane w procesie kwarantanny i podsumowania.
• Bezpośredni dostęp WebAdmin do zwolnień z kwarantanny jest znany, jeśli działania centralne nie powiodą się.
• Bufor poczty, przestrzeń dyskowa i stan System są monitorowane.
• Dzienniki są przechowywane lokalnie, w Sophos Central lub za pośrednictwem Syslog przez wystarczający okres czasu.
• Po aktualizacji oprogramowania sprzętowego przeprowadzany jest test przepływu poczty.

W celu dłuższego przechowywania i korelacji z innymi zdarzeniami związanymi z bezpieczeństwem rozważ Centralne raportowanie zapory lub Sophos Firewall Syslog wyślij do SIEM.

Często zadawane pytania