Skanowanie i testowanie POP3 oraz IMAP na Sophos Firewall

Sophos Firewall może skanować wiadomości podczas pobierania ich przez klientów za pomocą POP3, POP3S, IMAP i IMAPS. Dotyczy to zarówno trybu MTA, jak i Legacy; ścieżka menu do opcjonalnej polityki POP-IMAP jest inna. Sama polityka nie wystarcza: dopiero pasująca reguła zapory kieruje ruch pocztowy przez proxy i aktywuje skonfigurowane ustawienia skanowania oraz TLS.

Najważniejszym testem odbiorczym nie jest więc zielony przełącznik, lecz rzeczywiste pobranie wiadomości z planowanego klienta do planowanego serwera poczty. Firewall Rule ID, użyty port, łańcuch certyfikatów, wynegocjowana wersja TLS i warren.log muszą odpowiadać zaplanowanej ścieżce.

⚠️ Bez Scan email content w regule zapory, która faktycznie pasuje, SFOS nie stosuje ustawień ani polityk POP/IMAP. Sama polityka nie zapewnia ochrony.

Skanowanie POP/IMAP w ośmiu krokach

1. Udokumentować sieć klienta, serwer poczty, protokoły i faktycznie używane porty.
2. Wybrać jedno źródło pilotażowe i sprawdzić dotychczasowe pobieranie poczty.
3. Zaimportować w Certificates > Certificate authorities urząd CA, który wystawił certyfikat serwera poczty, jeśli nie jest jeszcze zaufany.
4. Ustawić POP/S and IMAP/S settings oraz POP and IMAP TLS configuration w Email > General settings.
5. Tylko w razie potrzeby utworzyć politykę POP-IMAP scan dla nadawców, odbiorców lub cech wiadomości: w Email > Policies and exceptions w trybie MTA albo w Email > Policies w trybie Legacy.
6. Utworzyć wąską, rejestrowaną regułę zapory dla klienta pilotażowego i serwera poczty oraz włączyć wymagane protokoły w Scan email content.
7. Sprawdzić pobieranie, połączenie TLS, Firewall Rule ID i warren.log za pomocą małej wiadomości testowej.
8. Dodać kolejnych klientów dopiero po teście pozytywnym i negatywnym oraz udokumentować drogę wycofania.

Co chroni proxy POP/IMAP

POP3 i IMAP służą do pobierania wiadomości ze skrzynki oraz zarządzania nimi. Nie są tym samym co SMTP, które przesyła wiadomości między nadawcą, MTA i serwerem poczty. Instrukcja trybu MTA opisuje więc MX, routing SMTP, relay, spool i kwarantannę SMTP; ta instrukcja koncentruje się na pobieraniu poczty przez klienta.

SFOS rozróżnia porty niezaszyfrowane lub podnoszone do TLS za pomocą STARTTLS od wariantów korzystających z TLS od początku:

• POP3: TCP 110, z opcjonalnym przejściem na TLS przez STARTTLS
• POP3S: TCP 995, TLS od początku połączenia
• IMAP: TCP 143, z opcjonalnym przejściem na TLS przez STARTTLS
• IMAPS: TCP 993, TLS od początku połączenia

W nowych projektach klienci poczty powinni korzystać z połączeń szyfrowanych. Wybór protokołu w SFOS nie zmienia jednak konfiguracji klienta. Jeśli klient używa innego portu lub omija zaplanowaną regułę, taki ruch nie jest automatycznie chroniony przez wybraną opcję standardową.

Skanowanie POP/IMAP wymaga ważnej licencji Email Protection. Nie zastępuje ochrony serwera poczty ani skanowania podczas nadejścia wiadomości przez SMTP. Szczególnie w przypadku usług pocztowych w chmurze trzeba najpierw potwierdzić, czy dostawca nadal zezwala na klasyczne pobieranie POP/IMAP i czy przezroczyste proxy jest zgodne z jego wymaganiami TLS i uwierzytelniania.

Ustalenie przykładu i granicy testu

Kontrolowany pilotaż zapobiega jednoczesnemu wpływowi błędnej konfiguracji certyfikatu lub reguły na wszystkich klientów poczty. W przykładzie użyto wartości dokumentacyjnych:

• klient pilotażowy 10.20.30.50 w strefie LAN
• serwer poczty mail.example.net
• adres docelowy 192.0.2.25
• używany protokół IMAPS na TCP 993
• reguła zapory Pilot_POP_IMAP_Scan

Należy zastąpić 10.20.30.50, mail.example.net i 192.0.2.25 wartościami rzeczywistymi. Adres docelowy należy do dokumentacyjnego zakresu TEST-NET i nie wolno go używać jako adresu serwera produkcyjnego. Pilotaż powinien korzystać z osobnej skrzynki testowej, a nie jedynego konta administratora.

Przed zmianą należy pobrać wiadomość i zapisać aktualnego wystawcę certyfikatu. Trzeba także zachować istniejącą regułę zapory, jej licznik oraz konfigurację klienta. Pozwoli to później odróżnić problem z routingiem, TLS, skanowaniem proxy lub serwerem poczty.

Przygotowanie TLS i limitów skanowania

CA i weryfikacja certyfikatu

W Certificates > Certificate authorities należy dodać urząd CA, który wystawił certyfikat serwera poczty, jeśli zapora jeszcze mu nie ufa. Pliki prywatnego CA mogą pochodzić wyłącznie z własnej infrastruktury PKI lub innego zweryfikowanego źródła. Importowanie certyfikatów na Sophos Firewall opisuje ogólny import i kontrolę łańcucha.

Następnie w Email > General settings > POP and IMAP TLS configuration należy wybrać w polu TLS certificate wcześniej zweryfikowany i zaimportowany urząd CA, który wystawił certyfikat serwera poczty. Allow invalid certificate pozostaje wyłączone. Wyłączenie weryfikacji nie naprawia nieprawidłowej, wygasłej lub niezaufanej strony zdalnej.

Należy zaznaczyć pole Disable legacy TLS protocols, aby zgodnie z pomocą SFOS wyłączyć protokoły starsze niż TLS 1.1. Nie dowodzi ono, że konkretna sesja używa TLS 1.2 lub TLS 1.3. Jeśli standard bezpieczeństwa wymaga co najmniej TLS 1.2, trzeba sprawdzić wynegocjowaną wersję na rzeczywistej ścieżce klienta. Jeśli użyta kombinacja nie spełnia tego wymagania, należy zatrzymać wdrożenie i rozważyć inną architekturę ochrony.

Ponieważ zapora przetwarza zaszyfrowany ruch pocztowy w celu skanowania, na kliencie może pojawić się ostrzeżenie o certyfikacie. Nowego ostrzeżenia nie należy ignorować. Trzeba sprawdzić prezentowaną nazwę, wystawcę, łańcuch i zaufanie klienta oraz usunąć przyczynę przed szerokim wdrożeniem.

Rozmiar wiadomości i nagłówki odbiorcy

W POP/S and IMAP/S settings opcja Don’t scan emails greater than ustala maksymalny rozmiar wiadomości do skanowania. Dla POP/IMAP wartość 0 nie oznacza braku limitu; według pomocy SFOS ustawia limit 10,240 KB. Większe wiadomości nie są skanowane. Limit powinien uwzględniać typowe załączniki, dostępną wydajność i zaakceptowane ryzyko resztkowe.

Recipient headers pomagają SFOS rozpoznawać odbiorców dla polityk POP/IMAP. Domyślnie zapora używa Delivered-To, Received i X-RCPT-TO. Dodatkowy nagłówek należy dodać tylko wtedy, gdy rzeczywisty serwer poczty ustawia go niezawodnie. Wymyślony lub później usuwany nagłówek prowadzi w przeciwnym razie do trudnych do wyjaśnienia dopasowań polityk.

Utworzenie opcjonalnej polityki POP-IMAP

Przy aktywnej subskrypcji Email Protection SFOS automatycznie stosuje domyślną politykę default-pop-av do ruchu POP3/S i IMAP/S. Usuwa ona załączniki zainfekowane wirusami i zastępuje treść wiadomości powiadomieniem. Podczas testów i diagnostyki należy uwzględnić tę automatyczną politykę bazową, zanim zachowanie zostanie przypisane własnej polityce.

Polityka POP-IMAP dodaje kryteria i ostrzeżenia dla użytkowników. W trybie MTA ścieżka to Email > Policies and exceptions > Add policy > POP-IMAP scan, a w trybie Legacy: Email > Policies > Add policy > POP-IMAP scan. Najpierw określa się nazwę oraz grupy nadawców i odbiorców. Następnie polityka może reagować między innymi na klasyfikację spamu, źródłowy adres IP lub sieć, rozmiar wiadomości albo nagłówek.

Dla nadawców i odbiorców wybiera się grupy adresów e-mail lub domen oraz dopasowanie dokładne albo według słowa kluczowego. Pojedyncze adresy testowe z dokładnym dopasowaniem pozwalają precyzyjnie ograniczyć pilotaż; grupy domen lub słowa kluczowe mogą poszerzyć planowany zakres. Rzeczywisty zakres sprawdza się za pomocą wiadomości pasujących i niepasujących, bez zakładania dodatkowych reguł dotyczących symboli wieloznacznych czy rozróżniania wielkości liter.

• Inbound email is: wybrać spam, probable spam, virus outbreak lub probable virus outbreak jako klasyfikację.
• Source IP/network address: podać adres IP lub adres sieci nadawcy.
• Message size: ustawić górny albo dolny limit rozmiaru wiadomości. To kryterium polityki nie zastępuje globalnego limitu Don’t scan emails greater than.
• Message header: wybrać nagłówek; dla Other wprowadzić jego szczegóły. Następnie wybrać dopasowanie dokładne lub według słowa kluczowego i podać porównywaną wartość słowa kluczowego.

Udokumentowane akcje to Accept i Prefix subject. Prefix subject dostarcza wiadomość i dodaje informację do tematu. Polityka nie jest więc ogólną regułą kwarantanny ani blokowania. Jeśli jako kryterium wybrano None, akcja dotyczy wszystkich wiadomości między wskazanymi nadawcami i odbiorcami. Przed zapisaniem trzeba świadomie sprawdzić ten zakres.

Nieszkodliwy przykład pilotażowy używa własnych grup adresów testowych z dokładnym dopasowaniem oraz kryterium Message header: Other, szczegóły Subject, dokładne dopasowanie, wartość słowa kluczowego Test email. Należy skonfigurować Prefix subject z dowolnie wybranym prefiksem Pilot i zapisać politykę. Dla pasującej wiadomości oczekuje się zmiany tematu z Test email na Pilot: Test email. Druga wiadomość między tymi samymi adresami testowymi z tematem Control email nie pasuje do kryterium nagłówka i nie powinna otrzymać tego prefiksu. Adresy i prefiks należy dostosować do własnego pilotażu; obie nowe wiadomości testuje się na tej samej planowanej ścieżce pobierania. Inne aktywne polityki nie mogą zniekształcać porównania.

Aby zmienić istniejącą politykę POP-IMAP scan, otworzyć Email > Policies and exceptions w trybie MTA albo Email > Policies w trybie Legacy. Wybrać Edit przy odpowiedniej polityce, zmienić wymagane ustawienia i zapisać politykę. Następnie ponownie sprawdzić pobieranie poczty i działanie polityki na zaplanowanej ścieżce klienta.

Dodatkową politykę można pominąć podczas pierwszego technicznego testu proxy. Dzięki temu widać, czy działa już podstawowy łańcuch TLS, reguły zapory i skanowania. Politykę należy dodać dopiero wtedy, gdy rzeczywiście potrzebna jest logika nadawcy, odbiorcy lub nagłówka.

Hierarchia XML i ograniczenia automatyzacji

Na potrzeby automatyzacji obiekt polityki nosi nazwę POPIMAPScanningPolicy. Poniższy opis przedstawia udokumentowaną strukturę dla SFOS 22/23, a nie przetestowane ani gotowe do wysłania żądanie POST. Zabezpieczenie dostępu do XML API opisuje bezpieczny dostęp i analizę odpowiedzi XML. Opcje skanowania w regule zapory, która faktycznie pasuje, pozostają wymagane także w przypadku polityki zarządzanej przez API.

Udokumentowany przykład rozróżnia trzy poziomy:

• POPIMAPScanningPolicy/Name określa politykę, którą należy zarządzać. Natomiast POPIMAPScanningPolicy/After/Name określa inną politykę, po której jest ona umieszczana w przykładzie. Nie należy mylić nazwy docelowej z odniesieniem określającym kolejność. Przykład potwierdza tę strukturę umiejscowienia, ale nie ogólną kolejność oceny ani zachowanie przy brakującym odniesieniu lub pominięciu After.
• W POPIMAPScanningPolicy/EmailAddress znajdują się SenderEmail, SenderAction, RecipientEmail i RecipientAction. Wartości adresów i operatory dopasowania należą zatem do wspólnego węzła nadrzędnego EmailAddress, a nie bezpośrednio do obiektu polityki. Opis parametrów traktuje obie wartości adresów jako pojedyncze ciągi znaków; wybór grup w interfejsie nie oznacza istnienia dodatkowego węzła listy w XML.
• FilterCriteria, Action, To i MatchIs znajdują się w przykładzie bezpośrednio pod POPIMAPScanningPolicy, poza EmailAddress i After. To zawiera tutaj prefiks tematu dla akcji dodawania prefiksu, a nie adres odbiorcy. W zależności od kryterium MatchIs określa klasyfikację przychodzących wiadomości e-mail lub porównywaną wartość nagłówka.

Tabela parametrów oznacza Name, SenderEmail, SenderAction, RecipientEmail, RecipientAction, FilterCriteria i Action jako obowiązkowe. Podaje dla Name maksymalnie 255 znaków, dla To maksymalnie 300 i dla MatchIs maksymalnie 750 znaków. Limity te opisują pola, a nie dopuszczalny zakres polityki; na przykład wartość adresu Any pokazana w przykładzie nie jest odpowiednim ustawieniem dla wąskiego pilotażu.

Dodatkowe parametry właściwe dla poszczególnych kryteriów to Address dla źródłowego adresu IP lub sieci (tablica ciągów znaków, wiele wartości), MessageSizeOperator z MessageSize (liczba całkowita) oraz MessageHeaderString (maksymalnie 765 znaków) z MessageHeaderOperator do porównywania nagłówków. Tabela parametrów wymienia te pola, ale przedstawiony przykład dla przychodzących wiadomości e-mail ich nie zawiera. Nie jest więc kompletnym szablonem XML dla filtrów źródłowego IP, rozmiaru ani nagłówków; nie należy na jego podstawie wnioskować o brakujących węzłach nadrzędnych, jednostkach rozmiaru ani zależnościach określających obowiązkowość pól.

⚠️ Dopuszczalne wartości są w opisie parametrów częściowo podane wyłącznie jako nierozwiązane symbole, takie jak $POPIMAP{SENDER_MATCHTYPE_CONTAINS}, $POPIMAP{RULETYPE_INBOUND_EMAIL} i $POPIMAP{POP_IMAP_ACTION_PREFIX_SUBJECT}. Symbole te nie są potwierdzonymi wartościami dosłownymi dla żądania POST. Przykład pokazuje wprawdzie Contains, InboundEmailIs i Prefix Subject, ale nie zapewnia pełnego mapowania wszystkich stałych. Dla MessageHeaderOperator kolumna wartości domyślnej podaje nawet GreaterThan, podczas gdy opis przewiduje Contains/Equals. Nie należy rozstrzygać tej sprzeczności przez zgadywanie operatora ani wysyłać etykiet interfejsu czy nazw symboli jako wartości API bez ich weryfikacji.

Dopóki konkretne wartości i wymagana struktura filtra dla używanej kompilacji nie zostaną wyjaśnione, konfiguracja przez opisany wyżej interfejs pozostaje bezpieczną, udokumentowaną drogą. Przed późniejszą zatwierdzoną zmianą przez API należy zachować nazwy, kolejność, zakres adresów, kryterium i akcję; następnie ponownie odczytać zapisany stan lub sprawdzić go w interfejsie oraz ponownie pobrać parę pasującej i niepasującej wiadomości testowej. Dokumentacja referencyjna wymienia dla Add i Edit wartości statusu XML 200, 500 i 502, ale nie podaje komunikatów wyjaśniających. Sam sukces HTTP nie potwierdza więc ani zapisanej polityki, ani jej działania. W ramach tego opisu nie wykonano żadnego wywołania zapisującego na urządzeniu.

Utworzenie reguły zapory dla pobierania poczty

Regułę tworzy się w Rules and policies > Firewall rules. W trybie MTA można również uzupełnić automatycznie utworzoną regułę zapory MTA; w jasno ograniczonym pilotażu łatwiej jednak ocenić osobną, wąską regułę. W trybie Legacy tworzy się nową regułę zapory. Powinna zawierać wyłącznie planowaną sieć klienta lub host pilotażowy, cel serwera poczty i faktycznie potrzebne porty pocztowe. Ogólna reguła z LAN do WAN z wieloma funkcjami bezpieczeństwa utrudnia test odbiorczy.

Dla przykładu Pilot_POP_IMAP_Scan pasują następujące wartości:

• Source zones: LAN
• Source networks and devices: host 10.20.30.50
• Destination zones: strefa ścieżki do serwera poczty, zwykle WAN dla serwera zewnętrznego
• Destination networks: obiekt hosta dla 192.0.2.25 lub rzeczywistego serwera poczty
• Services: IMAPS
• Log firewall traffic: włączone

W Scan email content należy włączyć Scan IMAPS. Jeśli środowisko faktycznie używa dodatkowych protokołów, należy również wybrać Scan IMAP, Scan POP3 lub Scan POP3S. Add ports dodaje odpowiednie usługi; następnie muszą one być widoczne w Services w regule.

Regułę należy umieścić nad bardziej ogólną regułą, która już pasuje do tego samego klienta i serwera poczty. Po zapisaniu decydująca jest rzeczywista Firewall Rule ID w Log Viewer, a nie oczekiwane położenie w tabeli reguł. Bezpieczna konfiguracja reguł Sophos Firewall opisuje budowę, kolejność i weryfikację Rule ID.

Test całej ścieżki

Najpierw należy umieścić małą, nieszkodliwą wiadomość w prywatnej skrzynce testowej. Klient pilotażowy pobiera ją przez planowany FQDN i port. W Log Viewer źródłowy IP, docelowy IP, usługa, akcja i Firewall Rule ID muszą odpowiadać nowej regule. Wzrost licznika innej reguły jest warunkiem zatrzymania.

Do weryfikacji certyfikatu i TLS można na przykład uruchomić z klienta w tej samej sieci następujące połączenia tylko do odczytu:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Należy testować wyłącznie protokoły rzeczywiście oferowane przez serwer poczty. mail.example.net trzeba zastąpić prawdziwym FQDN. Wynik potwierdza certyfikat, łańcuch i parametry TLS, ale nie udane logowanie ani skanowanie treści. Po sprawdzeniu interaktywne połączenie kończy się za pomocą Ctrl+C.

Następnie należy powtórzyć pobieranie za pomocą rzeczywistego klienta poczty. Do analizy proxy służy warren.log; Log Viewer i Packet Capture pokazują dodatkowo dopasowanie reguły i ścieżkę sieciową. Razem zapisuje się czas, IP klienta, IP serwera, port i temat testowy. Usługi i logi Sophos Firewall klasyfikują plik dziennika i opisują bezpieczny dostęp.

Pobieranie, Firewall Rule ID, parametry TLS i korelacja z warren.log potwierdzają łącznie planowaną ścieżkę pobierania i TLS, a nie skuteczność antywirusa. Jeśli skonfigurowano własną politykę Prefix subject, należy dodatkowo przetestować opisaną wyżej parę wiadomości: Pilot: Test email dla pasującej wiadomości i brak prefiksu Pilot dla Control email. Trzeba udokumentować faktycznie dostarczone tematy; nawet poprawny prefiks potwierdza tylko akcję polityki, a nie skuteczność antywirusa. Przy rozbieżnościach należy sprawdzić grupy, typ dopasowania, nagłówki i inne aktywne polityki, a następnie ponownie przetestować obie wiadomości.

Test ścieżki obejmuje także przypadek negatywny. Dla niedozwolonego hosta pilotażowego lub niewybranego portu należy wcześniej określić oczekiwaną obsługę przez reguły, a następnie sprawdzić rzeczywistą Rule ID i opcje skanowania. Nieumyślnie szeroką drugą regułę skanowania trzeba poprawić; celowo zaplanowana alternatywna ochrona nie jest błędem. Test nie wymaga ani globalnego braku ochrony, ani blokowania wszystkiego. Jeśli dostępny jest specjalnie przygotowany serwer testowy z nieprawidłowym łańcuchem certyfikatów, próba połączenia lub pobrania musi zakończyć się niepowodzeniem wskutek weryfikacji tego łańcucha przy wyłączonym Allow invalid certificate na zaporze; na potrzeby tego testu nie należy tworzyć błędu certyfikatu na serwerze produkcyjnym.

Ograniczanie błędów według objawu

Pobieranie działa, ale proxy nie skanuje

Najpierw trzeba sprawdzić Firewall Rule ID. Jeśli pasuje wyższa lub bardziej ogólna reguła, należy poprawić kolejność, źródło, cel i usługę. Jeśli pasuje planowana reguła, odpowiednia opcja Scan IMAP/IMAPS/POP3/POP3S oraz port muszą być aktywne w Services. Sama polityka POP-IMAP nie aktywuje proxy.

Klient poczty zgłasza błąd certyfikatu po aktywacji

Należy zapisać prezentowany FQDN, wystawcę, ważność i pełny łańcuch. Następnie sprawdza się CA wybrany w POP and IMAP TLS configuration oraz zaufanie klienta. Nie należy włączać Allow invalid certificate jako trwałego obejścia. Jeśli nadal nie wiadomo, jaki certyfikat prezentuje proxy lub serwer, należy wycofać pilotaż przed objęciem kolejnych klientów.

STARTTLS działa, ale POP3S lub IMAPS nie

Porty i tryby połączenia trzeba sprawdzić oddzielnie. POP3 na 110 i IMAP na 143 przechodzą na sesję szyfrowaną dopiero przez STARTTLS; POP3S na 995 i IMAPS na 993 rozpoczynają od TLS. Klient poczty, listener serwera, usługa zapory i włączona opcja skanowania muszą używać tego samego wariantu.

Duża wiadomość jest dostarczana, ale nie skanowana

Należy porównać Don’t scan emails greater than z rzeczywistym rozmiarem wiadomości. Także 0 ogranicza skanowanie POP/IMAP do 10,240 KB. Nie należy bez namysłu zwiększać limitu dla jednego testu bez oceny wpływu na wydajność i zaakceptowane ryzyko.

Brakuje prefiksu tematu

Należy sprawdzić grupy nadawców i odbiorców, typ dopasowania, kryterium i Recipient headers. Wiadomość mogła zostać technicznie przeskanowana, mimo że opcjonalna polityka nie pasowała. Dlatego działanie proxy i akcję polityki ocenia się osobno.

Eksploatacja i wycofanie

Po udanym pilotażu kolejnych klientów dodaje się stopniowo. Podczas wdrożenia monitoruje się liczniki reguł, warren.log, błędy TLS i zgłoszenia do pomocy technicznej. Zmiany certyfikatu serwera poczty, FQDN, portu lub profilu klienta powinny później przechodzić ten sam proces zmiany, ponieważ modyfikują zweryfikowaną ścieżkę.

Aby wycofać zmianę, najpierw usuwa się pilota z wąskiej reguły lub wyłącza odpowiednią opcję skanowania. Następnie trzeba potwierdzić, że pierwotne pobieranie poczty znów działa i pasuje oczekiwana poprzednia reguła. Zaimportowany urząd CA lub globalne ustawienie POP/IMAP usuwa się tylko wtedy, gdy nie korzysta z niego żadna inna usługa. Wiadomości, logi ani certyfikaty nie są usuwane jako standardowy krok wycofania.

FAQ