Bezpieczne tworzenie i testowanie wyjątków poczty w Sophos Firewall

Wyjątek poczty w Sophos Firewall nie oznacza po prostu zezwolenia nadawcy. Pomija wybrane kontrole bezpieczeństwa dla określonej ścieżki SMTP. Właśnie dlatego może precyzyjnie rozwiązać potwierdzony fałszywy alarm, ale może też niezauważenie wyłączyć SPF, skanowanie złośliwego oprogramowania, Zero-Day Protection lub kontrole DKIM.

⚠️ Wyjątek należy utworzyć dopiero po odtworzeniu fałszywego alarmu. Pomijana jest tylko kontrola powodująca problem. Należy wybrać najwęższy wiarygodny warunek, ponieważ host źródłowy, nadawca i odbiorca są alternatywami, a nie wspólnym warunkiem AND. All checks ani szerokie symbole wieloznaczne nie są szybką standardową metodą obejścia.

Tworzenie wyjątku w siedmiu krokach

1. Zapisać czas testu, źródłowy adres IP SMTP, nadawcę koperty, odbiorcę, temat, Message-ID oraz dokładny powód odrzucenia.
2. Sprawdzić, czy problem powoduje DNS, routing, relay, TLS lub właściwa polityka poczty, a nie kontrola bezpieczeństwa.
3. W Email > Policies and exceptions > Add an exception wybrać wyłącznie kontrolę, której udział został potwierdzony.
4. Włączyć tylko najwęższy właściwy warunek w Sources or hosts, Sender addresses lub Recipient addresses.
5. Przeprowadzić test pozytywny równoważnej wiadomości i test negatywny co najmniej jednego wariantu spoza zakresu.
6. W Email > Mail logs porównać rezultat i Reason przed i po zmianie; inne zabezpieczenia testować oddzielnie nieszkodliwymi przypadkami.
7. Udokumentować właściciela, uzasadnienie i datę przeglądu; po usunięciu przyczyny skasować wyjątek.

Co faktycznie pomija wyjątek

SFOS grupuje możliwe do pominięcia kontrole według ich działania. Spam protection zawiera RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF i BATV. Malware protection obejmuje Malware oraz Zero-day protection. W Other znajdują się Data protection, File protection, Encryption, Banner addition, DKIM signing i DKIM verification.

Ten wybór nie jest listą udogodnień. Na przykład wyjątek dla SPF pozostawia aktywne pozostałe etapy ochrony przed spamem i złośliwym oprogramowaniem. Wyjątek dla Malware lub Zero-day protection usuwa natomiast kluczową kontrolę treści dla wszystkich wiadomości pasujących do zakresu. Encryption, DKIM signing lub DKIM verification zmieniają dodatkowo poufność i weryfikację integralności wychodzącego lub przychodzącego przepływu poczty.

Ten wyjątek należy do MTA mode. Polityka SMTP route and scan łączy routing z działaniami dla spamu, złośliwego oprogramowania, plików i danych. W legacy mode SFOS działa jako przezroczysty proxy i używa oddzielnych polityk SMTP malware scan oraz SMTP spam scan; obiekt wyjątku MTA nie jest tam właściwym ustawieniem. Zobacz Konfigurowanie Mail Protection w Sophos Firewall w trybie MTA i Konfigurowanie Mail Protection w trybie legacy.

Encryption oznacza tutaj szyfrowanie wiadomości przez politykę MTA, na przykład szyfrowanie SPX, a nie szyfrowanie transportu SMTP. Require TLS negotiation, walidację certyfikatu i Skip TLS negotiation ustawia się oddzielnie w Email > General settings > SMTP TLS configuration. Wyjątek poczty nie naprawia więc negocjacji TLS, routingu, relay ani reguł zapory.

Zrozumienie dopasowania przed zapisaniem

Trzy grupy zakresu nie tworzą warunku AND. Oficjalne API SFOS 22.0 nazywa je ForTheseSourceHost, ORTheseSenderAddresses i ORTheseRecipientAddresses. Przy kilku aktywnych grupach wystarczy dopasowanie hosta źródłowego lub nadawcy lub odbiorcy. IP, domena partnera i skrzynka pilota tworzą więc trzy drogi dopasowania, a nie węższą kombinację.

Ten obiekt nie oferuje AND między grupami; dwa wyjątki również poszerzyłyby zakres. Jeśli wymagane są dwa jednoczesne kryteria, trzeba usunąć przyczynę albo odseparować przepływ odpowiednią polityką lub trasą bramy.

Sources or hosts

SFOS akceptuje jako źródła adresy IP, zakresy IP, listy IP, sieci lub nazwy FQDN. Nazwy FQDN z symbolami wieloznacznymi nie są obsługiwane w wyjątkach hostów poczty. Dlatego *.example.net nie jest prawidłowym zamiennikiem zaobserwowanego adresu źródłowego SMTP. Dla localhost wyjątek nie jest potrzebny, ponieważ SFOS domyślnie nie skanuje lokalnych wiadomości e-mail.

W przypadku usług poczty chmurowej lub rozproszonych bram pojedynczy adres IP może być zbyt wąski, a cała sieć dostawcy zdecydowanie zbyt szeroka. Należy używać wyłącznie opublikowanego obiektu źródłowego, który rzeczywiście zaobserwowano we własnym przepływie poczty. Jeśli inni klienci współdzielą adresy IP dostawcy, nawet ten obiekt może być zbyt szeroki. Nie należy pomijać kontroli bezpieczeństwa wyłącznie na podstawie tej sieci.

Nadawca i odbiorca

Dla Sender addresses i Recipient addresses dozwolony jest adres, taki jak sender@example.net, albo symbol *@example.net. Druga grupa nie jest węższym ograniczeniem, ponieważ łączy się przez OR. Nadawca nie jest niezależnym dowodem zaufania przy wyjątku SPF lub DKIM; wyjątek odbiorcy obejmuje pasujące wiadomości od wszystkich nadawców.

BATV ma nietypową regułę specjalną: aby pominąć kontrolę BATV dla wiadomości danego nadawcy, jego adres trzeba wpisać zarówno w Sender addresses, jak i w Recipient addresses. Brak jednego z pól oznacza, że wyjątek dla tego przypadku BATV jest niekompletny.

Tworzenie wąskiego wyjątku

Przykład dotyczy potwierdzonego fałszywego alarmu SPF z dedykowanej bramy partnera. 203.0.113.25 jest adresem dokumentacyjnym do zastąpienia publicznym IP z Mail logs. Przykład jest właściwy tylko wtedy, gdy IP należy wyłącznie do zaufanej bramy; dla współdzielonego przekaźnika chmurowego obejście byłoby zbyt szerokie.

1. Otworzyć Email > Policies and exceptions > Add an exception.
2. Wprowadzić łatwą do prześledzenia nazwę, na przykład FP-SPF-partner-example-review-2026-09-30.
3. Wśród pomijanych kontroli wybrać wyłącznie SPF.
4. W Sources or hosts wpisać host 203.0.113.25.
5. Pozostawić Sender addresses i Recipient addresses wyłączone lub puste, ponieważ dodają dopasowania OR.
6. Zapisać bez dodawania kolejnych hostów lub kontroli.

Nazwa celowo zawiera przyczynę i datę przeglądu. Nie zastępuje jednak dokumentacji w zmianie lub zgłoszeniu. Nazwa nie wymusza technicznie daty wygaśnięcia; właściciel musi faktycznie przeprowadzić przegląd.

Przeprowadzenie testów pozytywnych i negatywnych

Partner ponownie wysyła tę samą kontrolowaną wiadomość, która nie powinna już kończyć się Reason SPF. W Email > Mail logs można filtrować według czasu, nadawcy, odbiorcy lub tematu oraz Result i Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification i BATV mają oddzielne filtry Reason. Do głębszej korelacji służą smtpd_main.log i przy odrzuceniach smtpd_reject.log; Usługi i logi Sophos Firewall opisuje ich rolę.

Następnie wykonuje się test negatywny przez kontrolowaną, niewyłączoną ścieżkę SMTP. Nie może on pomijać udokumentowanej kontroli wskutek tego wyjątku. Przy wyjątku tylko dla hosta inni nadawcy lub odbiorcy korzystający z tego IP nie są testami negatywnymi: pasują do tej samej gałęzi OR. Nieszkodliwy plik może osobno sprawdzić Malware i File Protection; nie używa się prawdziwego złośliwego oprogramowania.

Samo dostarczenie nie potwierdza zakresu. Oficjalna dokumentacja Mail logs opisuje Reason i status dostarczenia, ale nie pole “matched exception” ani listę pominiętych kontroli. Należy łącznie ocenić Reason przed/po, konfigurację oraz oddzielne przypadki pozytywne i negatywne. Dostarczenia nie należy przedstawiać jako dowodu wykonania wszystkich pozostałych zabezpieczeń.

Rozpoznawanie ryzykownych wyjątków

Już jeden szeroki symbol wieloznaczny domeny lub duża sieć źródłowa może usunąć ochronę znacznej części przepływu poczty. Wprowadzenie obu nie zawęża zakresu, lecz dodaje dopasowania OR. Szczególnie wyjątki dla Malware, Zero-Day Protection, Data protection i File protection wymagają udokumentowanej decyzji o ryzyku oraz bardzo małego, niezależnie wiarygodnego zakresu. Przy nieznanym jeszcze błędzie skanowania nie należy zapobiegawczo wyłączać całej grupy.

Również pozornie funkcjonalne opcje mają znaczenie dla bezpieczeństwa. Pominięcie Encryption może wysłać poufną treść bez ochrony. Bez DKIM signing brakuje planowanego podpisu wychodzącego, a bez DKIM verification nie jest oceniane przychodzące potwierdzenie tożsamości. Wyjątek Banner może usunąć wymagany tekst lub oznaczenie. Takie zmiany należy uzgodnić z właścicielem poczty i zgodności.

Zawężanie błędów według objawu

Wiadomość nadal jest odrzucana

Najpierw należy ocenić nowy wpis w logu, a nie starą wiadomość testową. Rzeczywisty źródłowy adres IP, nadawca koperty, odbiorca i Reason muszą odpowiadać zakresowi oraz wybranej kontroli. Nazwa FQDN z symbolem wieloznacznym w Sources or hosts nie działa. Jeśli wiadomość jest odrzucana z powodu RBL, IP reputation, RDNS/HELO lub innej kontroli, wyjątek ograniczony do SPF nie rozwiązuje tego odrębnego powodu.

Wyjątek obejmuje zbyt wiele wiadomości

Trzy grupy należy osobno porównać z przepływem. Każda aktywna grupa OR zwiększa zbiór dopasowań. Ograniczyć wyjątek do jednej wiarygodnej grupy z najmniejszą liczbą wartości i powtórzyć test negatywny.

Wiadomość przechodzi kontrolę, ale nie jest dostarczana

Wyjątek steruje kontrolami bezpieczeństwa, a nie MX, trasą wewnętrzną, relay, TLS SMTP czy docelowym serwerem poczty. Mail logs i spool pokazują, czy po skanowaniu wiadomość nadal kończy się niepowodzeniem z powodu DNS, routingu, polityki lub dostarczenia. Przy błędzie TLS należy sprawdzić certyfikat, Require TLS negotiation i drugą stronę; Encryption w wyjątku ani szerszy zakres nie rozwiązują problemu.

Wyjątek BATV nie działa

Sprawdzić, czy identyczny adres nadawcy znajduje się w Sender addresses i Recipient addresses. Następnie ponownie porównać konkretny Reason BATV i pozostałe pola zakresu. Drugi, szerszy wyjątek nie zastępuje brakującego pola BATV.

Eksploatacja i wycofanie zmian

Każdy wyjątek otrzymuje właściciela, potwierdzony powód fałszywego alarmu i datę przeglądu. Zmiany należy porównać z audit trail; Śledzenie zmian konfiguracji w Sophos Firewall opisuje odpowiedni dowód. Rzeczywisty przepływ poczty pozostaje dodatkowo widoczny w Mail logs i plikach MTA.

Przed zmianą zapisać nazwę, kontrole, wartości zakresu i poprzedni Reason. Aby zachować stan, usunąć tylko nowy wyjątek, pozostawiając polityki i inne wyjątki bez zmian. Ponownie sprawdzić pierwotny błąd i wiadomość kontrolną; przy nierozwiązanej przyczynie najpierw zaplanować okno serwisowe lub węższą korektę.

Lista kontrolna

• Dostępny jest odtwarzalny fałszywy alarm i dokładny Reason.
• Udokumentowano źródłowy adres IP, nadawcę koperty, odbiorcę i Message-ID.
• Pomijana jest tylko kontrola powodująca problem.
• Preferowana jest jedna właściwa grupa zakresu; dodatkowe grupy poszerzają dopasowanie przez OR.
• Nazwy FQDN z symbolami wieloznacznymi nie są używane jako wyjątki hostów.
• Wyjątek BATV zawiera adres nadawcy w obu polach adresowych.
• Testy pozytywne i negatywne wraz z Reason przed i po zmianie potwierdzają zamierzony efekt.
• Pozostałe kontrole spamu, złośliwego oprogramowania, plików, danych i DKIM pozostają aktywne.
• Udokumentowano właściciela, uzasadnienie, datę przeglądu i wycofanie zmian.

FAQ