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. Samo utworzenie polityki POP-IMAP 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ć w Email > Policies and exceptions politykę POP-IMAP scan dla nadawców, odbiorców lub cech wiadomości.
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 należy wybrać planowany TLS certificate w Email > General settings > POP and IMAP TLS configuration. Allow invalid certificate pozostaje wyłączone. Wyłączenie weryfikacji nie naprawia nieprawidłowej, wygasłej lub niezaufanej strony zdalnej.

Według pomocy SFOS opcja Disable legacy TLS protocols wyłącza protokoły starsze niż TLS 1.1. Nie dowodzi ona, ż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 Email > Policies and exceptions > Add a 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.

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.

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.

Utworzenie reguły zapory dla pobierania poczty

Regułę tworzy się w Rules and policies > Firewall rules. 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.

Wiarygodny test odbiorczy obejmuje też przypadek negatywny. Niedozwolony host pilotażowy lub niewybrany port nie może przypadkowo uzyskać takiego samego stanu ochrony przez inną szeroką regułę skanowania. Jeśli dostępny jest specjalnie przygotowany serwer testowy z nieprawidłowym łańcuchem certyfikatów, musi on odrzucić połączenie przy wyłączonym Allow invalid certificate; 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