Konfiguracja Mail Protection na Sophos Firewall w trybie Legacy

W Legacy mode Sophos Firewall działa jako przezroczyste proxy poczty. Wewnętrzny serwer pocztowy pozostaje właściwym endpointem SMTP; firewall przekazuje ruch przez istniejące reguły firewalla i NAT, jednocześnie sprawdzając go pod kątem spamu, malware, typów plików i dopasowań Data Control.

To zasadniczo różni się od MTA mode. Firewall nie staje się Mail Transfer Agentem, nie przejmuje dostarczania poczty dla chronionych domen i nie oferuje dla tej ścieżki MTA mail spool. Pomyślny test portu SMTP nie potwierdza więc ani skanowania proxy, ani zastosowania właściwej polityki.

⚠️ Zmiana SMTP Deployment Mode jest globalną zmianą ścieżki ochrony poczty. Przed przełączeniem należy udokumentować backup, istniejące polityki, reguły firewalla i NAT oraz przetestowaną ścieżkę powrotu. Problem z MTA nie jest powodem do nieplanowanego przejścia na Legacy mode.

Legacy mode w dziewięciu krokach

1. Udokumentować istniejącą przychodzącą i wychodzącą ścieżkę SMTP wraz z adresami IP, portami, NAT i Firewall Rule IDs.
2. Sprawdzić, czy przezroczyste proxy rzeczywiście pasuje lepiej niż MTA mode.
3. Zapewnić backup konfiguracji i niezależny dostęp administracyjny.
4. W Email > General settings wybrać Switch to legacy mode.
5. Ustalić SMTP hostname, limity rozmiaru, akcję dla zbyt dużych wiadomości, IP Reputation, limity DoS, porty i zachowanie TLS.
6. Utworzyć tylko potrzebne polityki SMTP malware i SMTP spam albo sprawdzić ich kolejność.
7. Ograniczyć przychodzące ścieżki DNAT i wychodzące ścieżki SNAT do właściwego serwera pocztowego.
8. W rzeczywiście dopasowanych regułach firewalla włączyć Scan SMTP lub Scan SMTPS.
9. Zweryfikować przychodzące i wychodzące wiadomości testowe na podstawie Rule ID, wyniku polityki, certyfikatu i logów proxy Legacy.

Wybór między Legacy mode a MTA mode

Legacy mode pasuje przede wszystkim do istniejących środowisk, w których wewnętrzny serwer pocztowy jest już bezpośrednio publikowany przez NAT i ta ścieżka ma zostać zachowana. SFOS działa przezroczyście pomiędzy zdalnym peerem a serwerem. Cel MX, przyjmowanie SMTP i logika dostarczania pozostają elementami istniejącego projektu serwera pocztowego.

MTA mode jest lepszym wyborem, gdy firewall ma sam przyjmować wiadomości, trasować je według chronionych domen, relayować i przechowywać w spoolu podczas tymczasowych błędów dostarczania. Mail logs i mail spool należą jednoznacznie do tego modelu działania. Kompletną konfigurację opisuje artykuł Konfiguracja Mail Protection w MTA mode.

Według pomocy SFOS 22 MTA mode nie jest dostępny na XGS 87/87w ani XGS 88/88w. Nie oznacza to jednak automatycznie, że Legacy mode jest dobrą architekturą poczty w chmurze. Microsoft 365, Google Workspace i nowoczesne usługi hostingowe stosują własne wymagania dotyczące TLS, uwierzytelniania i ochrony przed nadużyciami. Przed użyciem przezroczystego proxy trzeba potwierdzić jego obsługę.

W skrócie: MTA mode ma własny przepływ poczty. Legacy mode chroni już działającą ścieżkę SMTP. Pomieszanie tych modeli prowadzi do szukania w niewłaściwym logu, przy niewłaściwym celu NAT albo w nieistniejącym spoolu.

Przykładowa topologia i ścieżka powrotu

Poniższy przykład wykorzystuje wartości dokumentacyjne i przed wdrożeniem musi zostać dostosowany do rzeczywistego środowiska:

• wewnętrzny serwer pocztowy 10.20.30.25 w strefie DMZ
• publiczny adres SMTP 192.0.2.25 na ścieżce WAN
• przychodząca usługa SMTP TCP 25
• opcjonalny SMTPS na TCP 465, tylko jeśli peery i serwer rzeczywiście używają tego wariantu
• reguły firewalla SMTP_In_Legacy i SMTP_Out_Legacy

192.0.2.25 należy do zakresu TEST-NET i nie jest wartością produkcyjną. Przed zmianą należy wykonać zewnętrzny test przychodzący i test wychodzący ze znacznikiem czasu. Zapisać aktualnie dopasowane Rule IDs, publiczny adres źródłowy używany przez serwer wychodzący oraz łańcuch certyfikatów.

Ścieżka powrotu nie polega wyłącznie na ponownym przełączeniu trybu. Trzeba także móc przywrócić udokumentowany stan nowych opcji skanowania, kolejności polityk, DNAT, reflexive lub ręcznych reguł SNAT oraz testów tymczasowych.

Ustalenie globalnych ustawień poczty

Tam, gdzie MTA mode jest dostępny, pomoc wskazuje go jako tryb domyślny. W Email > General settings świadomie wybrać Switch to legacy mode po zabezpieczeniu udokumentowanej ścieżki powrotu. Sama zmiana trybu nie tworzy zweryfikowanej ścieżki pocztowej Legacy.

W Email > General settings pole SMTP hostname dotyczy tylko generowanych przez system powiadomień w ciągach HELO i banera SMTP; wartość domyślna to SMTP. Nie zastępuje ono produkcyjnego FQDN serwera poczty ani jego publicznego DNS. Po zmianie trzeba więc zweryfikować powiadomienie SFOS, a nie tylko zwykłą wiadomość wygenerowaną przez serwer.

Weryfikacja API XML: Dokumentacja SFOS 23 wymienia status operacji 506 dla Email Configuration, powiązany z Message.AVGeneralConfInvalidSmtpNtfyHostname. Jest to nierozwiązany klucz komunikatu, a nie angielski komunikat błędu ani kod statusu HTTP. Jeśli ten status pojawi się w rzeczywistej odpowiedzi API XML, sprawdzić przesłaną nazwę hosta dla powiadomień, odpowiedź operacji oraz zapisaną konfigurację, zanim zmiana zostanie uznana za udaną. Z klucza nie można wywnioskować konkretnych reguł walidacji. Dodatkowy wpis w dokumentacji nie dowodzi, że zachowanie wprowadzono w SFOS 23 ani że dotyczy ono REST.

Limit rozmiaru, akcja dla zbyt dużych wiadomości i ochrona DoS

W Email > General settings > SMTP settings opcja Don’t scan emails greater than określa maksymalny rozmiar wiadomości podlegającej skanowaniu. W ścieżce SMTP wartość 0 oznacza według pomocy SFOS 22 51,200 KB, a nie brak limitu. Dla większych wiadomości dostępne są Accept, Reject i Drop.

Accept dostarcza zbyt dużą wiadomość bez skanowania. Reject odrzuca ją i informuje nadawcę, natomiast Drop usuwa ją bez powiadomienia. Ten wybór jest świadomą decyzją dotyczącą ryzyka i eksploatacji. Nieprzetestowane Drop utrudnia diagnostykę; nieocenione Accept tworzy lukę w skanowaniu, którą trzeba udokumentować.

Verify sender’s IP reputation sprawdza adres IP nadawcy przed kryteriami spamu w polityce SMTP i odrzuca wiadomości z adresów IP o złej reputacji. Sześć pól SMTP DoS w SFOS 22 przyjmuje następujące zakresy:

• Maximum connections: od 1 do 20000 połączeń z serwerem poczty
• Maximum connections/host: od 1 do 10000 połączeń z jednego hosta
• Maximum emails/connection: od 1 do 1000 wiadomości na połączenie
• Maximum recipients/email: od 1 do 256 odbiorców na wiadomość
• Emails rate: od 1 do 20000 wiadomości z jednego hosta na minutę
• Connections rate: od 1 do 20000 połączeń z jednego hosta na sekundę

Dopuszczalna wartość nie musi być właściwa. Limity produkcyjne należy wyprowadzić z rzeczywistego wolumenu i baseline, aby prawidłowe szczyty wysyłki nie były traktowane jak DoS.

Bypass spam check for SMTP/S authenticated connections globalnie pomija kontrolę spamu dla połączeń, które serwer pocztowy rozpoznaje jako uwierzytelnione. Jest to dopuszczalne dopiero po sprawdzeniu uwierzytelniania, dozwolonych źródeł i ochrony tego przepływu przed nadużyciami. Pomyślne logowanie nie zastępuje ani skanowania malware, ani negatywnego testu z nieuwierzytelnionym połączeniem. Domeny wpisane w Spam check exceptions również stanowią globalne obejście i nie służą jako szybki zamiennik precyzyjnie ograniczonego wyjątku.

Globalny baner wiadomości oferuje tryby Inline, no conversion, MIME part i Off. Inline, no conversion dodaje tekst bezpośrednio do wiadomości wychodzących; MIME part dodaje osobną część MIME. Off nie dodaje banera. W Email banner wpisywać wyłącznie tekst, na przykład krótką informację o poufności. Baner wymaga skanowania SMTP lub SMTPS w dopasowanej regule firewalla. U odbiorcy sprawdzić wiadomość tekstową i HTML pod kątem treści, struktury MIME i wyglądu. Ponieważ zmiana treści może unieważnić istniejący podpis DKIM, sprawdzić również nagłówki na rzeczywistej ścieżce wychodzącej.

Osobne planowanie POP/IMAP i portów

POP/IMAP ma osobny wybór CA TLS certificate w POP and IMAP TLS configuration. Pozostawić Allow invalid certificate wyłączone, aby odrzucać nieprawidłowe certyfikaty serwera; również tutaj Disable legacy TLS protocols blokuje tylko protokoły starsze niż TLS 1.1. Ustawienia SMTP nie zastępują tej konfiguracji. Pełną ścieżkę pobierania opisuje Skanowanie poczty POP/IMAP, a administrację CA i certyfikatami — Zarządzanie certyfikatami.

Legacy mode obejmuje również przezroczyste skanowanie POP3/S i IMAP/S. W POP/S and IMAP/S settings wartość 0 pola Don’t scan emails greater than oznacza 10,240 KB. Recipient headers określa nagłówki, w których SFOS szuka odbiorców używanych przez polityki POP/IMAP; domyślne to Delivered-To, Received i X-RCPT-TO. Należy je zmieniać tylko wtedy, gdy uzasadnia to przechwycony nagłówek wiadomości używanego serwera.

Udokumentowane porty standardowe to SMTP 25, SMTPS 465, POP3 z STARTTLS 110, POP3S 995, IMAP z STARTTLS 143 i IMAPS 993. SFOS może też skanować pocztę na innych portach; pomoc wymienia wprost port 587. Port alternatywny musi być usługą w odpowiedniej regule firewalla i odpowiadać faktycznie włączonemu protokołowi skanowania. Sama zmiana portu nie zamienia TLS implicit w STARTTLS ani odwrotnie.

Polityka POP-IMAP scan może łączyć grupy nadawców i odbiorców z kryteriami takimi jak klasyfikacja wiadomości przychodzącej, źródłowy adres IP, rozmiar wiadomości lub nagłówek. Dostępne są tylko akcje Accept i Prefix subject. Sama polityka nie aktywuje proxy: w Scan email content odpowiedniej reguły firewalla trzeba również wybrać faktycznie używany protokół POP3, POP3S, IMAP lub IMAPS.

Nie przeceniać TLS z powodu jednego pola wyboru

W SMTP TLS configuration należy wybrać certyfikat CA lub serwera przeznaczony do skanowania. Allow invalid certificate pozostaje wyłączone. Według pomocy Disable legacy TLS protocols wyłącza tylko protokoły wcześniejsze niż TLS 1.1 i nie potwierdza konkretnej sesji TLS 1.2 ani TLS 1.3.

Sophos wskazuje również ważne ograniczenie Legacy: firewall nawiązuje połączenie TLS na podstawie adresu IP domeny, a nie nazwy domeny. Jeśli wiele domen współdzieli jeden adres IP, weryfikacja certyfikatu może się nie powieść. W takim przypadku Sophos zaleca inną ścieżkę ochrony, na przykład Sophos Email Security. Kontroli nie omija się przez Allow invalid certificate.

Require TLS negotiation wymusza TLS dla wybranych Remote Hosts lub sieci; Require sender email domains wymusza go dla domen nadawców. Jeśli połączenia TLS nie można zestawić, SFOS odrzuca odpowiednie wiadomości. Skip TLS negotiation świadomie dopuszcza nieszyfrowane połączenia SMTP do wybranych peerów i powinno występować wyłącznie w udokumentowanych wyjątkach. Według pomocy każde pole przyjmuje do 512 wpisów hostów; przed użyciem szerokich list należy wykluczyć nakładanie się list wymuszeń i pominięć.

Świadome stosowanie polityk skanowania

Bez ważnej subskrypcji Email Protection ruch pocztowy może nadal być dozwolony, ale nie jest objęty Email Protection. Dostępność nie potwierdza więc licencji ani skanowania. Ustawienia globalne są przetwarzane przed politykami SMTP i POP-IMAP. W Email > General settings > SMTP settings włączyć reputację IP w Legacy mode przez Verify sender’s IP reputation i zapisać przez Apply; opcja MTA nazywa się Reject based on IP reputation. Globalny baner poczty wychodzącej obsługuje tylko tekst.

Po aktywacji subskrypcji Email Protection Sophos Firewall automatycznie stosuje w Legacy mode domyślną politykę default-smtp-av do ruchu SMTP. Własne polityki tworzy się w Email > Policies i są one przetwarzane w kolejności listy. Najpierw trzeba więc sprawdzić, która istniejąca polityka pasuje do konkretnego nadawcy i odbiorcy.

Nowe polityki SMTP w trybie Legacy tworzyć w Email > Policies > Add policy, wybierając SMTP malware scan lub SMTP spam scan. Aby zmienić istniejącą politykę, w Email > Policies wybrać Edit przy odpowiedniej polityce, zmienić wymagane ustawienia i zapisać politykę. Następnie ponownie sprawdzić kolejność polityk oraz powtórzyć test pozytywny i negatywny.

W Email > General settings > Malware protection wybiera się globalnie silnik podstawowy Sophos albo Avira. Wybranie Avira powoduje, że SFOS wyłącza Zero-day Protection w politykach SMTP z Single antivirus. Przed zmianą silnika należy zinwentaryzować wszystkie takie polityki, a po zmianie ponownie je zweryfikować.

SMTP malware scan

Zmieniać kolejność polityk przez przeciąganie wpisów na liście. Zapisać poprzednią pozycję i powtórzyć oba testy: wąska polityka pilotażowa nie może pozostawać za szerszą polityką, która już pasuje.

Podczas tworzenia podać jednoznaczną nazwę oraz grupy adresów email lub domen nadawców i odbiorców. W Block file types wybrać załączniki do blokowania; Ctrl+Shift umożliwia wybór wielu typów. MIME whitelist zezwala na wybrane nagłówki MIME, a pozostałe typy plików są blokowane zgodnie z pomocą. Takie zezwolenie na typy plików nie omija antywirusa. Natomiast Disable oznacza wprost, że wiadomości nie są skanowane.

Delivery option for recipient dotyczy załączników zainfekowanych, chronionych i podejrzanych:

• Don’t deliver: nie wysyła odbiorcy ani wiadomości, ani powiadomienia.
• Deliver original: wysyła odbiorcy oryginalną wiadomość; nie oczyszcza jej.
• Remove and deliver: usuwa zainfekowany załącznik, powiadamia o usunięciu i dostarcza wiadomość. Ta akcja nie dotyczy typów określonych w Block file types; nie pozwala to wnioskować o innej akcji dostarczania dla zablokowanych typów.

Chronione załączniki pozostają nieskanowane; domyślnie odbiorca jest powiadamiany, chyba że skonfigurowano inaczej. Zapisać przez Save i sprawdzić rzeczywiste wyniki dostarczania oraz powiadomień przy użyciu nieszkodliwych przypadków pozytywnych i negatywnych.

Polityka SMTP malware scan steruje blokowanymi typami plików, wyjątkami MIME, skanowaniem antywirusowym i akcjami dostarczania. Przy Single antivirus wybrany silnik dotyczy według pomocy tylko wiadomości przychodzących; wychodzące są skanowane przez oba silniki. Dual antivirus uruchamia kolejno silnik podstawowy i pomocniczy.

Akcja Quarantine jest łączona z akcjami dla odbiorcy i administratora. Don’t deliver, Deliver original i Remove and deliver mają bardzo różne skutki. Chronionego lub nieskanowalnego załącznika nie wolno automatycznie utożsamiać z malware. Każda akcja wymaga zatem wiadomości testowej, oczekiwanego stanu po stronie odbiorcy i udokumentowanej ścieżki zwolnienia.

Quarantine nie oznacza automatycznie, że odbiorca nie otrzyma żadnej wiadomości; nadal decyduje Delivery option for recipient. Według Sophos Notify sender działa tylko razem z Don’t deliver. Chronione załączniki nie są skanowane, ale mogą nadal wywołać powiadomienie. W Delivery option for administrator opcja Don’t deliver oznacza brak powiadomienia administratorów; Send original wysyła im oryginalną wiadomość. Może ona zawierać niebezpieczne lub nieskanowane załączniki i nie zastępuje bezpiecznego powiadomienia. Osobno sprawdzić wyniki dla nadawcy, odbiorcy, administratora i kwarantanny.

⚠️ Remove attachment w Delivery option for administrator jest wyłączone z tej instrukcji: etykieta wskazuje na akcję administratora, ale opis mówi o wiadomości bez załącznika do odbiorcy oraz powiadomieniu administratorów o usunięciu. Nie ustala to bezpiecznego przypisania dostarczania. Nie włączać tej opcji jako nowej konfiguracji produkcyjnej. W izolowanym pilotażu zainfekowanych załączników używać Don’t deliver dla odbiorców i administratorów, osobno monitorować kwarantannę i sprawdzać wyniki nieszkodliwymi wzorcami testowymi. Istniejące Remove attachment zmieniać dopiero po udokumentowanym wyjaśnieniu z Sophos Support i kontrolowanej weryfikacji; nie zakładać czystego wyniku ani automatycznego oczyszczania.

Ograniczony pilotaż zamiast niesprawdzonej polityki przykładowej

Dla serwera 10.20.30.25 początkowo ograniczyć jednoznacznie nazwaną politykę do grupy odbiorców testowych w przykładowej domenie example.net; zastąpić domenę i grupę własnymi kontrolowanymi wartościami. Jeśli domeny nie ma w książce adresowej, dodać ją przez Create new. W Block file types wybrać na przykład Executable files, ustawić Dual antivirus i Quarantine, a akcje odbiorcy i administratora zaplanować oddzielnie jak powyżej. Zezwolenie MIME dodawać tylko z uzasadnionej potrzeby. Chroniony załącznik pozostaje nieskanowany; nie kopiować bezrefleksyjnie Send original dla takich załączników z przykładu.

Przykładowy limit skanowania 2048 KB należy do Don’t scan emails greater than w globalnych ustawieniach SMTP, nie do polityki pilotażowej i nie jest stałą wartością domyślną produktu. Ogranicza skanowanie do małych wiadomości. Przed jego przyjęciem zaplanować akcję dla zbyt dużych wiadomości i test tuż powyżej limitu na podstawie rzeczywistego wolumenu; inaczej Accept tworzy lukę w skanowaniu, a Reject i Drop powodują problemy z dostarczaniem. Własne polityki spamu SMTP i POP/IMAP są opcjonalnymi dodatkami według potrzeb, a nie warunkiem utworzenia samej ścieżki NAT.

SMTP spam scan

Podać nazwę i grupy adresów email lub domen nadawców i odbiorców. Świadomie wybrać dla tych grup dopasowanie dokładne lub według słowa kluczowego: wyszukiwanie słowa kluczowego nie może niezamierzenie poszerzać zakresu. Nie zakładać nieudokumentowanej składni regex, symboli wieloznacznych ani reguł AND/OR.

• Inbound email is i Outbound email is: osobno wybrać kierunek; kryteria to spam, probable spam, virus outbreak lub probable virus outbreak.
• Source IP/network address i Destination IP/network address: podać wymagany adres IP lub sieć nadawcy albo odbiorcy.
• Sender remote blacklist: wybrać odpowiednią grupę RBL dla nadawcy.
• Message size: ustawić górny lub dolny limit; nie mylić go z globalnym limitem zbyt dużych wiadomości.
• Message header: wybrać nagłówek; dla Other podać szczegóły, wybrać dopasowanie dokładne lub według słowa kluczowego i podać wartość słowa kluczowego.

Reject odrzuca wiadomość i informuje nadawcę. Accept ją dostarcza. Prefix subject dodaje prefiks do tematu i również dostarcza wiadomość; na przykład Probable spam oznacza kontrolowany test. Drop usuwa bez powiadamiania nadawcy; Quarantine zachowuje wiadomość w kwarantannie. Wybór szablonu SPX jest udokumentowany dla Accept i Prefix subject, wyłącznie dla wiadomości wychodzących. Nie potwierdza to obsługi SPX przez inne akcje ani automatycznego szyfrowania każdej zaakceptowanej wiadomości. Zapisać przez Save i osobno sprawdzić dopasowanie oraz akcję.

Polityka SMTP spam scan może dopasowywać klasyfikację spamu, źródło lub cel, RBL, rozmiar wiadomości, nagłówki albo Data Control List. W zależności od ścieżki dostępne są akcje Reject, Accept, Change recipient, Prefix subject, Drop i Quarantine.

Kryterium Data control list oraz przypisanie SPX w tej polityce dotyczą wyłącznie wiadomości wychodzących. None stosuje natomiast wybraną akcję do wszystkich wiadomości pomiędzy określonymi grupami nadawców i odbiorców. Change recipient nie dostarcza dodatkowo do pierwotnego odbiorcy, lecz zastępuje go skonfigurowanym adresem docelowym. Te trzy zakresy należy sprawdzić na pozytywnym i negatywnym przypadku odbiorcy przed umieszczeniem polityki w kolejności produkcyjnej.

Przygotowanie własnych typów plików i Data Control

Kategorie typów plików poczty to Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files i Web files. To klasyfikacje według rozszerzeń lub nagłówków MIME, a nie oceny bezpieczeństwa. Na przykład Executable files zawiera exe, cmd, bat i com; pdf występuje w Document files i Page layout files, a application/octet-stream w wielu kategoriach. Nie traktować kategorii jako wzajemnie wykluczających się ani nie zezwalać szeroko na ogólny nagłówek MIME, aby rozwiązać problem jednego załącznika. Szczegółowy wewnętrzny wykaz opisuje Web Protection; przed wyborem szablonu lub utworzeniem wąskiego własnego typu sprawdzić wartości w instalacji docelowej.

CCL mogą wykrywać wzorce takie jak numery kart kredytowych lub ubezpieczenia społecznego, adresy pocztowe i adresy email. Do testów pilotażowych używać danych syntetycznych, nigdy rzeczywistych danych osobowych. Wybrać wyłącznie wzorce odpowiednie dla celu i regionu; dopasowanie nie dowodzi autentyczności danych ani ich klasyfikacji prawnej.

Nadać własnemu typowi pliku nazwę i zapisać obiekt przez Save przed zmianą polityki. Osobna ścieżka tworzenia w MTA to Email > Policies and exceptions > File type > Add; nie zastępuje ona ścieżki Legacy. Typy plików są również używane w politykach web; ich konfigurację opisuje Web Protection. Także Data Control List powinna mieć jednoznaczną nazwę; po wyborze CCL wybrać Save.

W Legacy mode własne typy plików tworzy się w Email > Policies > File type > Add na podstawie szablonu, rozszerzeń albo typów MIME. Rozszerzenia wpisuje się bez kropki na początku, a edytować można tylko własne typy. Nowy typ nie jest automatycznie dodawany do istniejących polityk. Należy otworzyć odpowiednią politykę skanowania, dodać typ pliku i ponownie ją zapisać. Pozytywny test załącznika oraz podobny test negatywny pokazują, czy rzeczywiście działa przewidziana akcja.

Data Control List tworzy się w Email > Data control list > Add z potrzebnych Content Control Lists. Filtry Type i Region pomagają wybrać tylko odpowiednie wzorce danych finansowych, tożsamości lub innych danych wrażliwych. Dopasowanie listy nie określa jeszcze akcji; jest ona definiowana w powiązanej polityce skanowania. Mała lista pilotażowa z pozytywnym i negatywnym testem treści jest bezpieczniejsza niż szeroki zbiór niesprawdzonych CCL.

W Legacy mode w tej polityce można wybrać SPX dla wiadomości wychodzących. Model haseł, portal i weryfikacja stanowią jednak odrębny proces bezpieczeństwa; opisuje go artykuł Konfiguracja szyfrowania wiadomości SPX. Do pierwszego podstawowego testu proxy nie dodaje się Data Control List ani przypisania SPX.

Potwierdzonej błędnej klasyfikacji nie należy korygować przez wyłączenie polityki o szerokim zakresie działania. W trybie Legacy należy precyzyjnie dostosować odpowiednią politykę SMTP malware scan lub SMTP spam scan; jej działanie muszą potwierdzić test pozytywny i test negatywny poza zamierzonym zakresem. Artykuł Bezpieczne tworzenie i testowanie wyjątków poczty opisuje natomiast wyłącznie obiekt wyjątku w trybie MTA: źródło, nadawca lub odbiorca są alternatywnymi warunkami wyzwalającymi (OR), a nie warunkiem AND wymagającym dokładnego połączenia wszystkich trzech cech. Ten obiekt wyjątku MTA nie jest elementem sterującym w trybie Legacy.

Udokumentowane przypisania typów plików

Ten wykaz zachowuje przypisania kategorii poczty; nie jest listą dozwolonych plików ani dowodem obecności malware. Przed zmianami sprawdzić wartości w instalacji docelowej. Techniczne tokeny MIME pozostają niezmienione, także nietypowe udokumentowane zapisy, takie jak text/x-script.phyton; nie dowodzi to zgodności ze standardami ani nie definiuje nowej własnej reguły MIME.

Audio files

• Rozszerzenia: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
• Nagłówki MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv.

Backup files

• Rozszerzenia: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• Nagłówki MIME: application/octet-stream.

Compressed files

• Rozszerzenia: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• Nagłówki MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Rozszerzenia: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• Nagłówki MIME: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

• Rozszerzenia: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• Nagłówki MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Rozszerzenia: as, asc, c, cbl, cc, class, cp, cpp, cs, csproj, dev, dtd, f, fs, fsproj, fsx, ftl, gem, h, hpp, ise, ism, java, m, ocx, pas, pod, pro, py, r, rb, sh, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj.
• Nagłówki MIME: text/plain, text/x-c, application/java, application/java-byte-code, application/x-java-class, text/xml, text/x-fortran, text/x-h, text/x-java-source, text/x-m, application/octet-stream, text/pascal, text/x-script.phyton, application/x-bsh, application/x-sh, application/x-shar, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl.

Disk image files

• Rozszerzenia: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• Nagłówki MIME: application/x-cdlink.

Document files

• Rozszerzenia: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, thmx, aw, bld, blg, bvp, cdd, cdf, contact, csv, dat, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, mw, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vcf, vdb, vxml, windowslivecontact, wlmp, xfd, xml, xsl, xslt, lit, log, lst, odt, opml, pages, rtf, sig, tex, txt, wpd, wps, pdf.
• Nagłówki MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/octet-stream, application/vnd.ms-project, application/x-project, application/vnd.ms-officetheme, application/cdf, application/x-cdf, application/x-netcdf, text/comma-separated-values, text/csv, application/csv, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/tab-separated-values, text/x-vcard, application/xml, text/xml, application/x-ms-reader, text/plain, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf.

Dynamic files

• Rozszerzenia: pl, jsp, asp, php, cgi, shtml.
• Nagłówki MIME: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

• Rozszerzenia: bin, enc, hex, hqx, mim, mime, uue.
• Nagłówki MIME: application/mac-binary, application/macbinary, application/octet-stream, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Rozszerzenia: exe, cmd, bat, com.
• Nagłówki MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Rozszerzenia: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• Nagłówki MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

• Rozszerzenia: idml, indd, inx, isd, mdi, pct, pdf, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• Nagłówki MIME: image/x-pict, application/pdf, application/x-mspublisher, application/octet-stream, application/vnd.ms-xpsdocument.

Plugin files

• Rozszerzenia: 8bi, arx, crx, plugin, vst, xll.
• Nagłówki MIME: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

• Rozszerzenia: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, ico, key, lnk, msp, prf, profile, scf, scr, sys.
• Nagłówki MIME: application/vnd.ms-cab-compressed, application/octet-stream, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp, image/x-icon.

Video files

• Rozszerzenia: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
• Nagłówki MIME: application/octet-stream, application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash.

Web files

• Rozszerzenia: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• Nagłówki MIME: application/atom+xml.

Korzystanie z opcjonalnego journalingu poczty z uwzględnieniem ochrony danych

Nadać wpisowi journalingu jednoznaczną nazwę i zapisać wybór odbiorców oraz cel journalu przez Save przed poniższymi testami.

W Email > General settings > Email journaling > Add SFOS może wysyłać kopie przychodzących wiadomości SMTP/S dla wybranych odbiorców lub grup adresów na osobny adres journalingu. Wybór Any obejmuje wszystkie wiadomości przychodzące. Funkcja dotyczy wyłącznie SMTP/S i nie rejestruje ruchu POP ani IMAP.

Journaling tworzy dodatkową kopię wiadomości. Nie jest automatycznie archiwum odpornym na manipulacje i nie dowodzi spełnienia ustawowych obowiązków przechowywania. Przed włączeniem należy określić cel, uprawnionych odbiorców, dostęp do skrzynki journalingu, szyfrowanie, okres przechowywania, wymagane miejsce oraz odpowiedzialnego właściciela.

Do pierwszego testu wybiera się jedną skrzynkę testową zamiast Any. Wiadomość przychodząca do tej skrzynki musi pojawić się w zwykłym miejscu docelowym oraz w skrzynce journalingu; wiadomość do odbiorcy spoza wyboru nie może tworzyć kopii. Adres journalingu nie może uruchamiać przepływu, który odsyła kopię do SFOS i tworzy pętlę.

Wybór odbiorców rozszerza się dopiero po teście pozytywnym i negatywnym. W ramach rollbacku usuwa się wpis journalingu lub przywraca udokumentowany stan poprzedni. Dostarczone wcześniej kopie pozostają w skrzynce journalingu i podlegają jej własnym zasadom przechowywania.

Bezpieczne przyporządkowanie obiektów poczty Legacy w API XML

Dokumentacja referencyjna API XML dla SFOS 22 i 23 opisuje odrębne obiekty poczty Legacy. Ścieżka menu z MTA Mode, płaska tabela parametrów ani przykład z alternatywami rozdzielonymi ukośnikami nie stanowią żądania gotowego do skopiowania. Dostęp do API, transport, statusy operacji, nierozwiązane klucze komunikatów i kontrolę po zapisie opisuje Zabezpieczenie dostępu do API XML. Poniższe przyporządkowania pomagają odczytać istniejącą konfigurację; nie stanowią deklaracji przetestowania wywołania zapisującego i nie dotyczą automatycznie REST ani Central API.

Przed zmianą zabezpieczyć backup, aktualną zawartość obiektu, odwołujące się do niego polityki oraz kolejność. Konkretne żądanie i sprzeczne wartości pól wyjaśnić na podstawie pomocy API dla zainstalowanej kompilacji lub z Sophos Support. Następnie osobno sprawdzić zapisane obiekty i rzeczywisty wpływ na pocztę. Oznaczenie pola jako wymaganego w tabeli nie określa, czy pominięcie innych pól zachowuje ich dotychczasowe wartości. Nie potwierdza też sposobu opróżniania, zastępowania ani scalania list, ani atomowości zmian.

EmailConfiguration: pole należy rozpatrywać w kontekście protokołu i TLS

W EmailConfiguration pola o takich samych nazwach są rozróżniane przez elementy nadrzędne:

• GeneralSettings/EmailSignature i GeneralSettings/EmailBannerMode dotyczą banera wiadomości wychodzących. Tabela API podaje wartości trybu inline_plain, mimepart i off; przykład zawiera natomiast alternatywy zbliżone do etykiet UI. Nie traktować tych tekstów jako identycznych wartości API bez weryfikacji. EmailSignature jest ciągiem znaków o długości według tabeli API nie większej niż 2000 znaków.
• SMTPSSettings/DontScanEmailsGreaterThan to limit skanowania SMTP w KB; SMTPSSettings/ActionForOversizeEmails określa odrębną akcję Accept, Reject lub Drop. BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings i sześć limitów DoS również znajdują się w SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan to inny całkowitoliczbowy limit w KB. POPIMAPSettings/RecipientHeaders/Header jest listą ciągów znaków nagłówków służących do rozpoznawania odbiorców, a nie listą odbiorców SMTP.
• SMTPTLSConfiguration i POPSIMAPTLSConfiguration zawierają własne pola TLSCertificate, AllowInvalidCertificate i DisableTLS1. Certyfikat SMTP nie zastępuje certyfikatu POP/IMAP. RequireTLSWithHost, RequireTLSWithSenderDomain i SkipTLSHosts należą do kontekstu SMTP TLS; są odrębnymi listami ciągów znaków, a nie wspólnym wyjątkiem włączania i wyłączania. Nie mylić limitu UI wynoszącego 512 wpisów hostów z podaną w tabeli API maksymalną długością 512 znaków.

Rozróżniać tabelę API, przykład i dokumentację referencyjną UI: Tabela API podaje 1024 jako wartość domyślną obu limitów skanowania. Dla MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate i ConnectionsRate podaje kolejno 5000, 100, 100, 100, 1000 i 100. Przykład używa natomiast 1000 dla MaximumEmailsConnection; omówiony powyżej przykład UI z wartością 2048 KB również nie jest wartością domyślną. Znaczenie 0 pozostaje zgodne z opisaną powyżej dokumentacją referencyjną UI dla danego protokołu, a nie z wywnioskowanym z przykładu API ustawieniem bez limitu.

Tabela API dopuszcza dla MaximumRecepientsEmail wartości od 1 do 512, podczas gdy dokumentacja referencyjna UI podaje dla Maximum recipients/email zakres od 1 do 256. Pisownia API MaximumRecepientsEmail pozostaje niezmieniona; nie wyprowadzać z niej ani poprawionej nazwy pola, ani pewności, że 512 jest prawidłową wartością w UI. Pozostałe pięć zakresów DoS odpowiada podanym powyżej zakresom UI. Rozstrzygające pozostają zapisany stan i pomoc dla kompilacji docelowej.

Dalsze sprzeczności wykluczają bezrefleksyjne przejęcie przykładu: dla VerifySendersIPReputation tabela podaje on/off i wymienia Disable jako wartość domyślną, podczas gdy przykład pokazuje Enable. Przy SMTPSDosSettings typ danych INTEGER występuje obok wartości domyślnej Disable w tabeli i wartości Enable w przykładzie. Według tabeli BypassSpamCheck ma wartość domyślną Disable, ale przykład go włącza. Oba konteksty TLS w przykładzie dopuszczają nieprawidłowe certyfikaty. Nie przejmować tych niebezpiecznych ustawień przykładowych ani nie konstruować ze sprzecznych informacji rzekomo prawidłowego payloadu; opisane powyżej bezpieczne decyzje dotyczące TLS i pomijania kontroli pozostają w mocy.

Dla operacji Email Configuration udokumentowano 200 z Message.AVGeneralConfUpdateSuccess, 500 z Message.AVGeneralConfUpdateFail i 505 z Message.ASConfigSubOperationFail. SFOS 23 dodaje omówione już powyżej powiązanie 506 z Message.AVGeneralConfInvalidSmtpNtfyHostname. Są to statusy operacji i nierozwiązane klucze, a nie kody HTTP ani potwierdzone teksty komunikatów zwracanych podczas działania. Zwłaszcza po 505 najpierw ponownie odczytać ustawienia SMTP, POP/IMAP i TLS; nie zakładać ani pełnego rollbacku, ani pełnego zapisu i nie powtarzać wywołania bez sprawdzenia.

Skanowanie malware SMTP: niezależne traktowanie odbiorców i administratorów

Obiekt nazywa się AntiVirusMailSMTPScanningRules. Name określa politykę, a After/Name wskazane w przykładzie odwołanie do poprzednika. SenderList/Sender i ReceiverList/Receiver są odrębnymi listami; BlockFileTypes/FileType jest listą blokowanych typów plików. Tabela API wymienia również WhiteList jako listę MIME, ale nie pokazuje odpowiedniego zagnieżdżenia w przykładzie. Nie wymyślać na tej podstawie dodatkowego nadrzędnego węzła XML.

Dla Scanning tabela API podaje Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) i Disable, z wartością domyślną Disable. Przykładowe Disable/Disable nie jest ani pełnym zestawem wartości wyliczeniowych, ani użyteczną wartością dla zamierzonego skanowania antywirusowego. Quarantine i NotifySender są niezależnymi przełącznikami o wartościach Enable/Disable; według tabeli API w obu przypadkach wartością domyślną jest Disable. Te wartości tabelaryczne nie zastępują ani istniejącej polityki domyślnej, ani dowodu aktualnego stanu skanowania.

Dla załączników zainfekowanych, podejrzanych i chronionych dostępne są każdorazowo dwie niezależnie wybierane akcje:

• Odbiorcy: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment z wartościami Don'tDeliver, DeliverOriginal lub RemoveAndDeliver.
• Administratorzy: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment z wartościami Don'tDeliver, SendOriginal lub RemoveAttachment.

Tabela API podaje Don'tDeliver jako wartość domyślną wszystkich sześciu pól akcji. Nie jest to równoznaczne z opisem UI dotyczącym domyślnego powiadamiania o chronionych załącznikach i nie potwierdza aktualnego stanu dostarczania. Decydujące pozostają omówione powyżej skutki i ograniczenia: DeliverOriginal lub SendOriginal mogą przekazywać nieskanowane lub niebezpieczne załączniki; kwarantanna nie dowodzi wstrzymania dostarczenia do odbiorcy. Niewyjaśniona opcja administratora RemoveAttachment pozostaje wyłączona z tej instrukcji, nawet jeśli API wymienia ją jako wartość. Osobno kontrolować wyniki dla nadawcy, odbiorcy, administratora i kwarantanny.

AntiSpamRules: nie łączyć dopasowania, kolejności i akcji

W AntiSpamRules pole Name identyfikuje regułę. After/Name jest przedstawionym w przykładzie odwołaniem określającym jej pozycję po innej regule. Przed Add, Edit lub Order zabezpieczyć rzeczywistą kolejność i nazwę wskazywanej reguły; dokumentacja nie opisuje przez to automatycznie składni dla pierwszej pozycji ani nieistniejących poprzedników.

RecipientList/Action wraz z RecipientEmail oraz SenderEmailList/Action wraz z SenderEmail sterują oddzielnie dopasowaniem odbiorcy i nadawcy. Tabela API podaje dla obu akcji dopasowania Equals lub Contains, z wartością domyślną Contains w tabeli. Nie są one akcją dostarczania. MarkSpamIf zawiera natomiast Condition oraz odpowiednie dla niego OtherHeader, Operator i MatchIs. Rozmiar wiadomości wymaga porównania rozmiaru; nagłówek — dopasowania tekstu; klasyfikacja — wartości klasyfikacji. Płaski wiersz tabeli opisuje MatchIs jako całkowitoliczbowy rozmiar wiadomości, ale przykład używa Spam. Nie wnioskować z tego, że każdy typ warunku jest liczbowy. Wartość tabelaryczna 4 i różne nazwy warunków w przykładzie nie stanowią podstawy do wymyślenia przyporządkowania nagłówków ani wartości wyliczeniowych.

SMTPAction/Action i SMTPAction/ActionParameter określają akcję SMTP i jej dodatkową wartość; SMTPAction/Quarantine jest od nich niezależne. POPIMAPAction/Action i POPIMAPAction/ActionParameter należą do ścieżki pobierania, dla której przykład pokazuje tylko Accept i Prefix Subject. Nie przenosić akcji SMTP na POP/IMAP. Przy Change recipient parametr określa zastępczy cel dostarczenia, a nie dodatkowy adres journalingu. Opisane powyżej ograniczenia dotyczące wychodzącego Data Control i SPX pozostają w mocy.

Również tutaj przykład i tabela są sprzeczne: dla Quarantine przykład pokazuje Enable/Disable, a tabela dopuszcza 0 i Enable. Tabela akcji SMTP wymienia ponadto Accept With SPX; nie wyprowadzać tej pisowni API z etykiety UI ani ze zwykłego Accept. Przed wywołaniem zapisującym wyjaśnić konkretną wartość zależną od warunku, zamiast wysyłać przykładowe alternatywy rozdzielone ukośnikami.

Dla Order SMTP Scanning Policy podano 200 z Message.SpamRuleUpdateRuleOrderSuccess oraz zarówno 500, jak i 505 z Message.SpamRuleUpdateRuleOrderFail. Ten sam klucz oznacza więc dwa wiersze statusu; nie wyjaśnia ich przyczyny. Dla Add SMTP Scanning Policy udokumentowano 502 z Message.SpamRuleRecordExists. Przed ponownym Add lub Order sprawdzić istniejącą nazwę, zawartość i zapisaną kolejność; centralna kontrola bezpieczeństwa API oraz pozytywny i negatywny test polityki obowiązują również tutaj.

DataControlList: sygnatury nie są jeszcze akcją dostarczania

Obiekt Legacy DataControlList zawiera Name i Signatures/Signature, czyli listę nazw sygnatur CCL. Płaska tabela używa dla nich nazw name i signaturename; nie jest to powód do niejawnego zmieniania nazw tagów XML pokazanych w przykładzie. Tabela określa nazwę jako wymagany ciąg znaków o maksymalnej długości 255 znaków, a sygnatury jako opcjonalną listę ciągów znaków. Rzeczywistą nazwę sygnatury pobrać z dostępnego we własnym środowisku wyboru CCL, a nie kopiować z przykładu krajów. Akcja nadal wynika dopiero z powiązanej polityki. Nie używać innego obiektu MTADataControlList zamiast tego obiektu Legacy.

Dla Add Data Control List i Update Data Control List obie dokumentacje referencyjne wymieniają 502 z Message.DLPAddSameName oraz 545 z Message.MTAModeDisableCheck. 545 jest udokumentowanym powiązaniem statusu i klucza, a nie zweryfikowanym stwierdzeniem, że Legacy Mode zabrania tej funkcji lub że wymagana jest zmiana trybu. Nie przełączać zatem trybu w celu usunięcia błędu. Przed ponownym Add lub Update sprawdzić zapisaną listę i odwołania do niej oraz wyjaśnić rzeczywistą odpowiedź na podstawie pomocy dla zainstalowanej kompilacji lub z Sophos Support.

AVASAddressGroup: dokładnie jedna gałąź zależna od typu

AVASAddressGroup jest grupą adresową Legacy dla tych reguł poczty, a nie obiektem, którego równoważność potwierdza ścieżka menu MTA. Name identyfikuje grupę; tabela API podaje maksymalnie 50 znaków, a dla opcjonalnego Description maksymalnie 255. Tabela GroupType wymienia RBLIPv4, RBLIPv6, IPAddress i EmailAddressOrDomain, natomiast przykład podaje ogólnie RBL. Nie normalizować niejawnie tych zapisów.

Komentarz w przykładzie wymaga dokładnie jednej gałęzi pasującej do typu: RBLList/RBLName lub RBLFile, IPAddressList/IPAddressNetwork lub IPAddressFile, bądź EmailAddressList/EmailAddressDomain lub EmailAddressFile. Wpisy list są ciągami znaków; tabela dopuszcza wiele wartości i wskazuje ignorowanie duplikatów. Przykład pokazuje alternatywy razem, ale nie nakazuje wysyłania wszystkich list i plików. W grupach adresów email lub domen EmailImportType rozróżnia wartości Manual i Import. Tabela podaje dla EmailAddressFile formaty csv i txt, ale sprzecznie opisuje pole jako wprowadzanie ręczne; przykład odwołuje się do nazwy pliku żądania multipart. Żadna z tych informacji nie potwierdza ani pełnego sposobu powiązania danych multipart, ani bezpiecznego wywołania importu. Przed importem wyjaśnić te szczegóły dla konkretnej kompilacji.

Dla Add Address Group udokumentowano 502 z Message.AddrGrpRecordExists, 541 z Message.AddrGrpImportFailed, 542 z Message.AddrGrpEmptyFile1 i 543 z Message.AddrGrpSomeEmailNotImported. Z nierozwiązanych kluczy nie wyprowadzać ani informacji o faktycznie zaimportowanych wpisach, ani wniosku o pełnym rollbacku. Przed kolejnym importem porównać zapisanych członków grupy z zamierzoną listą.

Dla Delete Address Group statusy 504, 505 i 506 mają ten sam klucz Message.AddrGrpForeignKeyExists; 507 jest powiązany z Message.AddrGrpEmailArcKeyExists. Klucze nie pozwalają jednoznacznie rozróżnić poszczególnych obiektów odwołujących się do grupy. Przed usunięciem zinwentaryzować polityki i odwołania journalingu, przeanalizować dokładną odpowiedź operacji i następnie sprawdzić, czy grupa nadal istnieje. Nie usuwać bez sprawdzenia powiązanej polityki ochrony, aby wymusić wywołanie usuwające.

TrustedDomain, journaling i wybór silnika mają różne zakresy działania

AntiSpamTrustedDomain/DomainList/DomainName jest listą ciągów znaków domen. Add i Delete używają DomainName jako identyfikatora wpisów listy. Opis API mówi o pomijaniu skanowania poczty z zaufanych domen, ale nie określa dokładnie, które skanery są pomijane. UI opisuje Spam check exceptions jako pomijanie kontroli spamu. Nie rozszerzać tych dwóch stwierdzeń ani do gwarancji dotyczącej wszystkich skanów, ani do potwierdzonej dokładnej równoważności API i UI. Zarządzać domenami tylko w ściśle ograniczonym zakresie i z udokumentowanym celem; przed Add lub Delete i po nich sprawdzić listę oraz oczekiwane działanie ochrony. Nie wymyślać brakującego pełnego żądania XML na podstawie strony Delete.

AntiSpamEmailArchiver tworzy natomiast kopie: Name określa nazwę wpisu, RecipientList/Recipient ogranicza pierwotnych odbiorców, a SendCopyOfEmailTo jest odrębnym adresem dla kopii. Według tabeli API nazwa, odbiorcy i adres kopii są wymagane; nazwa i adres kopii mogą mieć maksymalnie 50 znaków. Wiersz odbiorcy opisano jako skalarny ciąg znaków, natomiast przykład pokazuje go w nadrzędnym węźle listy. Nie rozstrzygać tej rozbieżności przez samodzielnie wymyślony payload obejmujący wszystkich odbiorców. Opisany powyżej pilotaż z jedną skrzynką, wraz z ochroną danych, zabezpieczeniem przed pętlami i testem negatywnym, obowiązuje również przy automatyzacji; zmiana odbiorcy nie jest zmianą adresu kopii.

MalwareProtection/PrimaryAntiVirusEngine jest z kolei globalnym skalarnym selektorem silnika, a nie filtrem odbiorców ani pojedynczą polityką skanowania. Tabela API podaje Sophos jako wartość domyślną; przykład Sophos/Avira pokazuje alternatywy, a nie łączną wartość do wysłania. Nadal należy sprawdzić omówiony powyżej wpływ Avira na Zero-day Protection w politykach SMTP z Single antivirus. Po zmianie skontrolować globalnie zapisaną wartość i wszystkie objęte nią polityki; odrębne ścieżki dokumentacji nie tworzą niezależnych konfiguracji silników.

Połączenie NAT i reguł firewalla

Publikacja przychodzącej ścieżki SMTP

W Rules and policies > NAT rules wybrać właściwą rodzinę IP i otworzyć Add NAT rule. W Hosts and services > IP host musi istnieć obiekt wewnętrznego serwera, aby był dostępny w Translated destination (DNAT). W prostym przykładzie przychodzącym Translated source (SNAT) i Translated service (PAT) pozostają Original; w Original service wybrać tylko używane usługi SMTP, na przykład SMTP i SMTP[S]. Sprawdzić wszystkie pola przed Save. Translacja celu NAT nie jest równoważna z osobno kwalifikowanym poniżej polem firewalla Destination networks.

Dla poczty przychodzącej reguła DNAT tłumaczy publiczny adres WAN na wewnętrzny serwer pocztowy. Original Source jest ograniczany tak ściśle, jak pozwala projekt poczty; Original Destination to przewidziany adres publiczny; Translated Destination to 10.20.30.25 lub właściwy serwer pocztowy. Original service i translated service pozostają ograniczone do faktycznie udostępnianych portów SMTP.

Reguła reflexive tworzy również SNAT dla kierunku przeciwnego. Należy ją wybrać tylko wtedy, gdy dokładnie ta publiczna tożsamość źródłowa jest przeznaczona dla ścieżki wychodzącej. Wiele łączy WAN, smarthosty lub odmienne trasy operatorów wymagają własnego projektu routingu i SNAT. Ogólną kolejność oraz strefę docelową po NAT opisuje artykuł Publikacja serwera przez DNAT.

Użycie dwóch precyzyjnych reguł firewalla

Aby utworzyć regułę w Rules and policies > Firewall rules, wybrać rzeczywistą rodzinę protokołu IPv4 lub IPv6 i otworzyć Add firewall rule > New firewall rule. Podać nazwę i wymagane pola, a następnie zapisać przez Save. Nie używać przykładowych adresów IPv4 z tego artykułu w regule IPv6.

⚠️ Opisy Destination networks są sprzeczne: przykład poczty Legacy wskazuje serwer wewnętrzny, a ogólna procedura DNAT opiera dopasowanie firewalla na pierwotnym publicznym adresie docelowym. Instrukcja nie rozstrzyga konkretnego przypadku proxy przez zgadywanie. Udokumentować już potwierdzone dopasowanie reguły przychodzącej i zachować je w pilotażu. Nie wyprowadzać nowej reguły produkcyjnej z żadnego przypisania ani nie zmieniać celu na podstawie domysłów. Nową ścieżkę wyjaśnić przed zatwierdzeniem z Sophos Support lub poprzez odpowiednią kontrolowaną weryfikację, potwierdzając Rule ID, trafienie DNAT i przechwycenia przed translacją oraz po niej. Wariant wychodzącego SNAT nie rozstrzyga tej sprzeczności.

Podczas weryfikacji osobne reguły są bardziej czytelne niż jedna dwukierunkowa reguła z wieloma strefami i obiektami Any:

• Przychodząca: z WAN do strefy wewnętrznego serwera pocztowego, punkt końcowy SMTP 10.20.30.25, tylko wymagane usługi SMTP, włączone logowanie. Ten punkt końcowy nie jest zalecaną wartością nierozstrzygniętego pola Destination networks.
• Wychodząca: strefa i host wewnętrznego serwera pocztowego do WAN lub konkretnego smarthosta, tylko wymagane usługi SMTP, włączone logowanie

W Scan email content należy aktywować Scan SMTP w obu potrzebnych kierunkach, a Scan SMTPS tylko wtedy, gdy SMTPS jest rzeczywiście używany. Jeśli standardowego portu wybranego protokołu brakuje w Services, SFOS oferuje Add ports. Dla portu niestandardowego trzeba świadomie zdefiniować odpowiednią usługę. Usługa, NAT, listener serwera i opcja skanowania muszą opisywać tę samą ścieżkę; Add ports nie zastępuje tej kontroli.

Reguły należy umieścić nad bardziej ogólnymi regułami, które już pasują do tego samego ruchu. Po zapisaniu decydująca jest zarejestrowana Firewall Rule ID. Strukturę reguł, strefę NAT i kolejność opisuje artykuł Bezpieczna konfiguracja reguł Sophos Firewall.

Opcjonalnie: inny publiczny adres źródłowy dla ruchu wychodzącego

Ta konfiguracja dotyczy przekazywanego ruchu SMTP z serwera wewnętrznego, a nie wiadomości MTA generowanych przez system. Jest przydatna, gdy potrzebna jest inna przydzielona publiczna tożsamość zamiast adresu MASQ interfejsu WAN. Przydział operatora, routing, SPF, RDNS i autoryzacja operatora muszą odpowiadać tej tożsamości; SNAT nie zmienia tych warunków.

1. W Network > Interfaces > Add interface > Add alias wybrać rzeczywisty fizyczny interfejs WAN, IP version IPv4 i przydzielony adres z właściwą wartością IPv4/Netmask; Save. Ścieżkę operatora, Device Access i kontrole aliasu opisuje Konfiguracja aliasu IP.
2. W Hosts and services > IP host > Add utworzyć nazwany host dla tego samego publicznego adresu: IP family IPv4, Type IP, IP address przydzielony adres; Save. Sam obiekt hosta nie przypisuje adresu do interfejsu.
3. W Rules and policies > NAT rules > New NAT rule ograniczyć Original source do rzeczywistego wewnętrznego serwera pocztowego, a Translated source (SNAT) ustawić na publiczny host IP. Ograniczyć Original destination do wymaganych celów pocztowych lub smarthosta, a Original service do wymaganych usług SMTP. Translated destination (DNAT) i Translated service (PAT) pozostają Original. Inbound interface i Outbound interface muszą odpowiadać rzeczywistej ścieżce serwer–WAN. Zapisać przez Save i umieścić nad innymi pasującymi regułami SNAT; osobno sprawdzić kolejność NAT i firewalla. Podstawy NAT wyjaśniają pierwszą pasującą regułę. Any, Top, Port1 i Port2 w przykładach nie są wartościami obowiązkowymi.
4. W Rules and policies > Firewall rules > Add firewall rule > New firewall rule utworzyć odpowiednią wychodzącą regułę IPv4 lub sprawdzić istniejącą zawężoną regułę: Action Accept, rzeczywista strefa i host serwera jako źródło, WAN i wymagane cele, tylko wymagane usługi SMTP, Log firewall traffic włączone. Wybrać Scan SMTP i, jeśli potrzebne, Scan SMTPS jak powyżej; Save i sprawdzić kolejność firewalla niezależnie od NAT.
5. Utworzyć nowe połączenie SMTP do kontrolowanego odbiorcy zewnętrznego. Sprawdzić łącznie Firewall Rule ID, NAT Rule ID, przetłumaczony źródłowy IP w przechwyceniu lub u odbiorcy zewnętrznego oraz rzeczywiste dostarczenie. Istniejąca sesja lub test portu SMTP nie wystarczą. Sprawdzić też przypadek negatywny ze źródłem poza zakresem lub niedozwoloną usługą.

Przy wycofaniu najpierw przywrócić udokumentowane reguły i ich kolejność, potem sprawdzić poprzedni źródłowy IP i dostarczenie przez nowe połączenie. Usunąć alias i host IP tylko wtedy, gdy żaden inny serwis z nich nie korzysta.

Weryfikacja przepływu poczty i skanowania proxy

W wychodzącej regule firewalla During scheduled time określa, kiedy reguła obowiązuje. Świadomie wybrać All the time dla stale dostępnego serwera. Ograniczony harmonogram może zmienić dopasowanie poza swoim oknem; również wtedy sprawdzić Rule ID i przepływ poczty. Nie jest to harmonogram reguły SNAT. Reguła firewalla automatycznie tworzona przy włączeniu MTA dotyczy innego przepływu i nie zastępuje tej reguły serwera Legacy; dla niej używać instrukcji MTA.

Najpierw należy wysłać małą zewnętrzną wiadomość do skrzynki testowej. Następnie wewnętrzny serwer pocztowy wysyła drugą wiadomość do kontrolowanego odbiorcy zewnętrznego. Oba testy otrzymują unikalne tematy i znaczniki czasu UTC.

Dla STARTTLS na porcie 25 i bezpośredniego połączenia TLS na porcie 465 mogą pomóc następujące kontrole tylko do odczytu z autoryzowanego systemu testowego:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Zastąp mail.example.net rzeczywistym FQDN i testuj tylko faktycznie oferowane porty. Te polecenia OpenSSL wyświetlają przedstawiony łańcuch certyfikatów i wynegocjowane parametry TLS; sprawdź wszelkie błędy weryfikacji certyfikatów. Nie weryfikują one jawnie oczekiwanej nazwy hosta i mogą kontynuować działanie mimo błędów weryfikacji, więc samo połączenie nie jest dowodem pomyślnego uwierzytelnienia certyfikatu. Nie potwierdzają ani pomyślnego dostarczenia poczty, ani skanowania malware, spamu lub Data Control.

W Log Viewer źródło, cel, usługa, akcja i Firewall Rule ID muszą odpowiadać nowym regułom. Dla proxy Legacy SMTP/S należy skorelować awarrensmtp.log i awarrenmta.log z tym samym czasem. Pliki logów opisano w artykule Usługi i logi Sophos Firewall.

Następnie wykonaj oddzielne testy negatywne dotyczące zakresu reguły zapory i dopasowania do polityki wiadomości. Źródło lub usługa spoza zakresu pilotażu nie mogą pasować do pilotażowej reguły zapory i muszą podlegać udokumentowanemu wynikowi zezwolenia lub blokowania; inna autoryzowana reguła może nadal zapewniać ochronę. Wiadomość testowa bez kryterium polityki pilotażowej nie może pasować do tej polityki ani podlegać jej określonemu działaniu, ale musi nadal podlegać wszelkiemu mającemu zastosowanie skanowaniu domyślnemu lub innemu. Dla każdego przypadku zapisz oczekiwane Firewall Rule ID, politykę i wynik dostarczenia, a następnie porównaj je z zaobserwowanym wynikiem. Nie używaj prawdziwego malware w testach produkcyjnych; do weryfikacji skanowania używaj uznanych nieszkodliwych wzorców testowych i kontrolowanej skrzynki pocztowej.

Rozwiązywanie problemów według objawów

SMTP działa, ale polityka nie jest stosowana

Najpierw należy sprawdzić Firewall Rule ID. Jeśli dopasowana jest inna reguła, trzeba poprawić kolejność, źródło, cel, cel NAT i usługę. Jeśli pasuje oczekiwana reguła, Scan SMTP lub Scan SMTPS, kolejność polityk oraz grupy nadawców i odbiorców muszą odpowiadać testowi. Sama polityka nie aktywuje przezroczystego proxy.

Poczta przychodząca nie dociera do serwera

Oddzielnie sprawdzić publiczny adres docelowy, trafienie DNAT, translated destination, strefę docelową, listener serwera i ścieżkę powrotną. Otwarte połączenie TCP do firewalla nie dowodzi, że DNAT i reguła firewalla docierają do serwera wewnętrznego. Packet Capture i Rule ID muszą pokazywać wejście i przekazanie.

Poczta wychodząca używa niewłaściwego publicznego adresu IP

Sprawdzić SNAT, regułę reflexive, gateway WAN, trasę SD-WAN i zachowanie reply packets. Proxy Legacy nie wybiera automatycznie publicznego adresu źródłowego wymaganego przez SPF, RDNS lub autoryzację operatora. Przed globalną zmianą Route Precedence trzeba potwierdzić konkretną ścieżkę.

TLS przestaje działać po włączeniu skanowania

Należy zapisać FQDN, docelowy adres IP, certyfikat, wystawcę, łańcuch i wynegocjowaną wersję. Przy wielu domenach na jednym adresie IP przyczyną może być udokumentowana kontrola certyfikatu oparta na IP. Allow invalid certificate nie jest włączane jako szybkie rozwiązanie.

Wiadomość zniknęła, a w MTA mail spool nic nie ma

Nie jest to użyteczne kryterium powodzenia w Legacy mode, ponieważ mail spool i specyficzne dla MTA mail logs należą do MTA mode. Istotny łańcuch obejmuje tu regułę firewalla, NAT, logi serwera SMTP, Log Viewer, awarrensmtp.log i awarrenmta.log. Wiadomości w kwarantannie sprawdza się osobno w Email > SMTP quarantine.

Bezpieczny rollback

W ramach rollbacku najpierw przywraca się reguły pilotażowe i opcje skanowania do udokumentowanego stanu poprzedniego. Następnie usuwa się nowe przypisania polityk lub przywraca ich kolejność. Tymczasowe zmiany DNAT, SNAT lub certyfikatów usuwa się tylko wtedy, gdy nie zależy od nich żadna inna usługa.

Dopiero potem przywraca się SMTP Deployment Mode, jeśli zmiana obejmowała to przełączenie. Pierwotny przychodzący i wychodzący przepływ poczty musi ponownie działać z oczekiwanymi Rule IDs, adresami publicznymi i logami serwera. Wiadomości, zawartość kwarantanny ani logi proxy nie są usuwane jako standardowy rollback.

Lista kontrolna eksploatacji

• Przezroczyste proxy wybrano świadomie, a wymagania MTA zostały wykluczone.
• Backup, dostęp administracyjny i pierwotne Rule IDs są udokumentowane.
• SMTP hostname, limity SMTP i POP/IMAP, akcja dla zbyt dużych wiadomości, IP Reputation i limity DoS są uzasadnione.
• Używane porty standardowe lub alternatywne oraz POP/IMAP recipient headers odpowiadają rzeczywistej ścieżce serwera.
• Sprawdzono silnik podstawowy i jego wpływ na Zero-day Protection w politykach Single antivirus.
• Certyfikat, wyjątki TLS i dotknięte domeny zostały sprawdzone.
• DNAT, SNAT, strefa docelowa i rzeczywiste porty serwera są zgodne.
• Reguły firewalla dla ruchu przychodzącego i wychodzącego są precyzyjne, logowane i faktycznie dopasowane.
• Polityki domyślne i własne mają możliwą do prześledzenia kolejność.
• Opcjonalny journaling jest ograniczony do wymaganych odbiorców i ma udokumentowany cel ochrony oraz przechowywania danych.
• Testy pozytywny, negatywny, TLS i dostarczania zakończyły się powodzeniem.
• Logi proxy Legacy i serwera pocztowego można skorelować czasowo.
• Właściciel, data przeglądu i pełna ścieżka powrotu są zapisane.

FAQ