Bezpieczne tworzenie i testowanie Web Exceptions na Sophos Firewall
Utworzenie Web Exception zajmuje chwilę, ale jej działanie może być znacznie szersze, niż oczekiwano. Zależnie od wyboru Sophos Firewall pomija nie tylko deszyfrowanie HTTPS, lecz także walidację certyfikatów, skanowanie malware i treści, analizę Zero-Day lub wszystkie kontrole Web Policy.
Bezpieczna kolejność polega więc na ustaleniu najpierw objętego problemem przepływu i kontroli, która rzeczywiście zakłóca działanie, następnie na zawężeniu dopasowania, a dopiero potem na włączeniu najmniejszego potrzebnego wyjątku. Sam test pozytywny nie wystarcza. W teście negatywnym podobny, niewyłączony cel musi nadal podlegać normalnej kontroli.
Ten przewodnik dotyczy SFOS 22.0. Etykiety WebAdmin celowo pozostają w języku angielskim, aby można je było bezpośrednio odnaleźć w interfejsie.
Web Exception w siedmiu krokach
- Udokumentować klienta, host docelowy, ścieżkę URL, protokół i czas zdarzenia.
- Sprawdzić, czy używany jest DPI Mode czy Web Proxy Mode oraz która reguła zapory i Web Policy faktycznie działają.
- Ustalić, czy przeszkadza wyłącznie deszyfrowanie TLS, czy konkretna kontrola Web Protection.
- W Web > Exceptions > Add an exception zdefiniować wąskie kryteria URL, kategorii, źródła lub celu.
- W Skip the selected checks or actions wybrać tylko najmniejszą niezbędną opcję.
- Włączyć wyjątek i ponownie przetestować ten sam przepływ w nowym procesie przeglądarki lub aplikacji.
- Wykonać test negatywny wobec podobnego, niewyłączonego celu oraz udokumentować dopasowanie, działanie, właściciela i datę przeglądu.
⚠️ HTTPS decryption nie jest niewinną opcją zgodności. Dla pasującego ruchu znikają także kontrole zależne od deszyfrowania, a firewall zezwala wtedy na nieprawidłowe certyfikaty serwera. Malware and content scanning automatycznie pomija również analizę Zero-Day. Szeroki wyjątek nie może więc być pierwszym krokiem diagnostycznym.
Sprawdzenie wymagań produktu przed wyborem wyjątku
W przypadku niektórych zarządzanych produktów zezwolenia na porty i domeny są warunkiem działania danej funkcji. Przed wyborem reguły zapory, TLS Exclusion lub Web Exception należy ustalić z właścicielem produktu funkcję, wersję i rzeczywistą ścieżkę połączenia. W zgłoszeniu zmiany zapisać wymagane cele, porty, protokoły, kierunki i wyraźnie wymagane wyłączenia inspekcji, zamiast przyznawać ogólny dostęp wszystkim produktom Sophos.
- Wireless: Kontrola wstępna Wireless oddziela sieć zarządzania, DNS, usługę czasu i cele regionalne od późniejszej konfiguracji Wi-Fi.
- ZTNA: Najpierw określić wdrożenie lokalne lub chmurowe w instrukcji bramy ZTNA; ich kierunki połączeń i wymagania inspekcji nie są zamienne.
- Rejestracja przełączników: Instrukcja wdrożenia przełącznika obejmuje DNS, cele rejestracji i kontrolę ścieżki proxy/TLS.
- Endpoint, XDR i MDR: Wymagania sieci i proxy rozróżniają platformy, licencjonowane funkcje i cele właściwe dla instalacji. Lista dozwolonych domen nie jest ogólną listą wyłączeń deszyfrowania.
- NDR i urządzenia integracyjne: Planowanie urządzenia opisuje wymagania portów i domen dla ruchu wychodzącego; instrukcja eksploatacji pomaga osobno sprawdzić rzeczywiście uruchomione funkcje NDR i Log Collector.
Wewnętrzna instrukcja jest punktem wyjścia; przed zmianą właściciel produktu musi potwierdzić wiążące wymagania konkretnego wdrożenia. Dostępność sieciowa i pomijanie inspekcji pozostają odrębnymi decyzjami. Jeśli brakuje zweryfikowanego zestawu wymagań lub źródła są sprzeczne, nie rozszerzać wyjątku na próbę: zachować dowody i wyjaśnić sprawę z właścicielami produktu i zapory. Następnie nadal obowiązują pilotaż, testy pozytywne i negatywne, przegląd oraz wycofanie zmiany opisane w tej instrukcji.
Wybór Web Exception lub TLS Exclusion
Oba narzędzia mogą zapobiec deszyfrowaniu ruchu HTTPS, ale rozwiązują inne zadania.
SSL/TLS inspection rule z Action: Don’t decrypt pasuje, gdy w DPI Mode trzeba wyłączyć tylko deszyfrowanie dla jasno określonych celów. URL Group w Local TLS exclusion list jest szczególnie wydajna, ponieważ firewall porównuje Server Name Indication, czyli SNI, jako tekst.
Artykuł Tworzenie i bezpieczne używanie URL Groups pokazuje, jak utworzyć taką listę domen, przypisać ją do reguły Don't decrypt i przetestować z celem negatywnym.
Web Exception pasuje, gdy dodatkowo lub zamiast deszyfrowania trzeba celowo pominąć kontrolę Web Protection:
- HTTPS decryption
- HTTPS certificate validation
- Malware and content scanning
- Zero-day protection
- Policy checks
W DPI Mode Web Exception działa tylko wtedy, gdy dla przepływu jest aktywna co najmniej jedna Web Policy, Malware and content scanning lub ATP. W Web Proxy Mode Web Exception należy bezpośrednio do ścieżki Web Protection opartej na proxy.
SSL/TLS exclusion list używa nazw domen zapisanych jawnym tekstem i obejmuje ich subdomeny, zamiast stosować wyrażenia regularne. Wyłączenia SSL/TLS mogą pomijać wymagania dotyczące certyfikatów i protokołów, a nie tylko deszyfrowanie. Nie są więc równoważne Web Exception ograniczonej do HTTPS certificate validation. Potwierdzone domeny można dodać do Local TLS exclusion list w Control Center lub Log Viewer; alternatywnie edytuje się URL Group w Web > URL groups lub SSL/TLS inspection rule. Kategorie web również mogą być kryteriami SSL/TLS inspection rule.
Różni się również objęty ruch: w DPI Mode Web Exceptions dotyczą połączeń SSL/TLS na dowolnym porcie, a w Web Proxy Mode połączeń SSL/TLS na porcie 443. SSL/TLS Exclusion Rules działają tylko w DPI Mode, ale także niezależnie od portu. Oprócz URL Groups mogą używać jako kryteriów stref, sieci, adresów IP, usług, użytkowników i grup. Web Exceptions oferują wzorce URL, Web categories oraz źródłowe i docelowe adresy lub zakresy IP.
Aktywna Web Exception może pomijać wybrane kontrole ochrony dla pasujących przepływów webowych; nie gwarantuje to możliwości zniesienia każdej blokady systemowej. Jej zakresu nie można więc zabezpieczyć, umieszczając regułę Web Policy później w kolejności. Decydują kryteria samego wyjątku; mimo to należy osobno sprawdzić kolejność reguł zapory, Web i SSL/TLS, ponieważ określa ona, która ścieżka ochrony początkowo przetwarza przepływ.
Udokumentowana granica i nierozstrzygnięta sprzeczność: Sophos ogólnie opisuje wyjątki jako niezależne od policy i reguł. Jednak instrukcja kategorii dla SFOS 22.0 i 23.0 wyraźnie wskazuje highly objectionable criminal activity jako zawsze blokowaną: żadna policy ani wyjątek nie mogą zezwalać na te strony, a nazwy domen są celowo ukrywane w logach i raportach. Te rozbieżne stwierdzenia nie dowodzą działającego obejścia. Bezpieczne postępowanie polega na nieobchodzeniu blokady i, w razie potrzeby, wyjaśnieniu sprzeczności z Sophos Support. Do testów używać wyłącznie nieszkodliwych, zatwierdzonych celów, nigdy zabronionych treści.
Planowaną konfigurację DPI lub Web Proxy, Decryption Rules i dystrybucji CA opisuje artykuł Prawidłowe wdrażanie TLS Inspection. Samą logikę filtrowania wyjaśnia Konfigurowanie Web Protection przy użyciu Web Policies.
Planowanie wąskiego i identyfikowalnego dopasowania
Wyjątku nie należy zaczynać od dowolnej domeny dostawcy. Najpierw trzeba zarejestrować konkretny request w przeglądarce, Log Viewer lub logach aplikacji. Następnie można zdecydować, czy najstabilniejszym kryterium jest hostname, ścieżka, kategoria, źródłowy adres IP czy docelowy adres IP.
AND między typami, OR wewnątrz typu
Sophos Firewall łączy różne typy kryteriów przez AND. Jeśli na przykład określono wzorce URL i Source IP addresses, oba typy muszą pasować.
Wiele wartości tego samego typu jest ocenianych przez OR. Dwa wzorce URL oznaczają więc, że może wystarczyć jeden z nich. Dwa Source IP addresses oznaczają, że może wystarczyć jedno z dwóch źródeł.
Ta logika ma znaczenie podczas diagnostyki. Wyjątek może wyglądać prawidłowo, ale nie działać, ponieważ dodatkowy typ kryterium nie pasuje do rzeczywistego przepływu.
Bezpieczne zakotwiczenie wyrażenia regularnego
W URL pattern matches można używać wyrażeń regularnych. Sam wzorzec, taki jak vendor.example, nie jest odpowiedni. Tekst może zostać dopasowany także w nieoczekiwanym miejscu adresu URL i wyłączyć zbyt wiele żądań.
Dla zarezerwowanej domeny przykładowej updates.vendor.example świadomie zakotwiczony wzorzec hosta może wyglądać tak:
^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/
Ta wartość jest tylko przykładem. vendor.example jest domeną zarezerwowaną do celów dokumentacyjnych i należy ją zastąpić rzeczywistym hostem docelowym potwierdzonym w logu lub żądaniu. Opcjonalny prefiks dopuszcza subdomeny. Jeśli trzeba wyłączyć dokładnie jeden host, nie stosuje się zbędnego wildcardu dla subdomen.
Znaki inne niż ASCII podaje się we wzorcu jako Punycode. Po każdej zmianie regex test musi obejmować oczekiwane dopasowanie i co najmniej jedno celowo podobne niedopasowanie.
Sprawdzenie kropek, granicy hosta i niepożądowanych dopasowań w ścieżce
W regex kropka bez znaku ucieczki oznacza dowolny znak. Kropki w stałej nazwie hosta zapisuje się więc jako \.. Znak ^ zakotwicza dopasowanie na początku; końcowy / wyznacza granicę hosta względem podobnie zaczynających się nazw, takich jak updates.vendor.example.attacker.example. Sophos Firewall akceptuje / i \/. Dla dokładnie jednego hosta węższy wzorzec to:
^updates\.vendor\.example/
Przykłady dotyczą zapisu hosta/URL, do którego stosowane są te wzorce Sophos, bez początkowego https://. Narzędzie testowe musi używać tego samego zapisu. Przy innych portach lub innym zapisie nie dodawać .* na próbę, lecz ustalić faktycznie ocenianą wartość i ścieżkę ochrony. Ograniczenie HTTPS opisane w następnym rozdziale nadal obowiązuje.
Dla wzorca dokładnego hosta oczekuje się następujących wyników. W istniejącym wzorcu z opcjonalną subdomeną także cdn.updates.vendor.example/file powinno zostać dopasowane; pozostałe przypadki negatywne nadal nie pasują.
| Wartość testowa | Dokładny host |
|---|---|
updates.vendor.example/file | Dopasowanie |
cdn.updates.vendor.example/file | Brak dopasowania |
updatesXvendorYexample/file | Brak dopasowania |
notupdates.vendor.example/file | Brak dopasowania |
updates.vendor.example.attacker.example/file | Brak dopasowania |
other.example/path/updates.vendor.example/file | Brak dopasowania |
other.example/?next=updates.vendor.example/file | Brak dopasowania |
Szczególnie ważne są ostatnie dwa przypadki: porównanie może obejmować cały URL, wraz ze ścieżką i parametrami zapytania. Niezakotwiczony tekst domeny może więc uruchomić wyjątek na obcym hoście. Test sprawdza tylko dopasowanie; faktyczne pomijanie kontroli ochrony zostanie później zweryfikowane nowym żądaniem i logami.
Lokalne testowanie długich ciągów bez dopasowania
Wiele niezakotwiczonych wzorców może wymagać dodatkowego wyszukiwania, zwłaszcza gdy deszyfrowanie HTTPS udostępnia pełny tekst URL. Nie można z tego wyprowadzić uniwersalnej liczby kroków ani zawsze stałego, liniowego lub wykładniczego czasu wykonania dla każdego wzorca. Zakotwiczenie nie zastępuje też sprawdzenia złożonych kwantyfikatorów. Nie używać ogólnego wildcardu .* dla nazw hostów.
Test z 1000 znakami uzupełnia krótkie przypadki. Na lokalnym komputerze administratora z Python 3 ten przykład tworzy całkowicie fikcyjny tekst URL z długą ścieżką i domeną docelową dopiero w parametrach zapytania. Sprawdza oba pokazane tu wzorce bez kontaktowania się z zaporą:
import re
from time import perf_counter
prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
r"^updates\.vendor\.example/",
r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
regex = re.compile(pattern)
start = perf_counter()
for _ in range(100):
assert regex.search(value) is None
print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)
Oczekiwane są dwa wyniki bez dopasowania. Dodatkowe przypadki syntetyczne powinny obejmować długie, niemal pasujące nazwy hostów i długie ścieżki; wzorce przed zmianą i po niej porównuje się na tych samych danych wejściowych. Przy podejrzanych, złożonych wzorcach użyć lokalnego narzędzia z limitem czasu i przerwać zawieszony test. Czasy Python i liczniki kroków innych silników regex nie są pomiarami SFOS ani obietnicą wydajności. Nie kopiować produkcyjnych URL, tokenów, nazw użytkowników ani danych klientów do zewnętrznych stron testujących regex; wystarczą dane fikcyjne.
Rozróżnienie hostname i ścieżki URL
Wyjątki dla HTTPS decryption i HTTPS certificate validation mogą oceniać hostname z kontekstu TLS. Wzorzec ukierunkowany wyłącznie na ścieżkę URL działa natomiast dla HTTPS tylko wtedy, gdy połączenie jest już deszyfrowane. W nieszyfrowanym HTTP ścieżka URL jest widoczna bez deszyfrowania TLS.
Wynika z tego ważne ograniczenie: wyjątek nie może jednocześnie wyłączyć deszyfrowania, a następnie niezawodnie użyć jako kryterium części widocznej wyłącznie w zaszyfrowanej ścieżce HTTP. Taki przypadek wymaga zakresu opartego na hoście albo innego projektu.
Tworzenie Web Exception
Przykład wyłącza z deszyfrowania HTTPS pojedynczego klienta pilotażowego dla potwierdzonego hosta dostawcy. Nie jest to uniwersalna reguła wyjątku.
- Otworzyć Web > Exceptions.
- Wybrać Add an exception.
- Ustawić opisową nazwę, na przykład
Vendor API no decrypt. - Włączyć URL pattern matches.
- Wprowadzić przetestowany i zakotwiczony wzorzec w Search/Add i zatwierdzić przez Add.
- Dla pilota włączyć również Source IP addresses, wpisać konkretny adres IP klienta i zatwierdzić przez Add.
- W Skip the selected checks or actions wybrać wyłącznie HTTPS decryption.
- Wybrać Save.
- Na liście włączyć przełącznik nowego wyjątku.
- Ponownie sprawdzić nazwę, Matching URLs, źródła i pomijaną kontrolę.
Źródłowy adres IP jest w przykładzie ustawiony celowo. Bez niego wyjątek natychmiast objąłby każdego klienta, którego żądanie pasuje do wzorca URL. Po udanym pilotażu zakres można w kontrolowany sposób rozszerzyć na źródła, które rzeczywiście tego wymagają.
Dla czystej TLS Exclusion obejmującej wiele celów URL Group w regule Don't decrypt jest zwykle łatwiejsza w utrzymaniu i wydajniejsza. Wiele FQDN Host Objects w źródle lub celu SSL/TLS inspection rule jest niekorzystne, ponieważ może powodować liczne zapytania DNS dla nowych połączeń TLS.
Przygotowanie nowego wyjątku dla hosta w Config Studio
Config Studio może utworzyć nowy Web Exception na podstawie nazwy domeny bez wcześniejszego importowania istniejącego wyjątku. Jest to osobna procedura; Bad regex i Apply Fix służą natomiast do opisanej dalej naprawy istniejących wpisów. Nowy wyjątek jest początkowo przygotowywany tylko lokalnie i trafia na firewall dopiero przez import TAR.
Najpierw zapisać w chronionym miejscu pełną kopię zapasową firewalla oraz niezmieniony eksport selektywny WebFilterException z tego samego firewalla. Sekcja Eksport WebFilterException i kontrola w Config Studio opisuje eksport Entities.xml, postępowanie z plikami i późniejsze pobieranie. W zgłoszeniu zmiany zapisać jeszcze nieużywaną nazwę, potwierdzony host docelowy, wymaganą opcję pomijania i planowany zakres klientów. Istniejąca nazwa nie jest bezpiecznym sposobem dodania kolejnego wpisu: import aktualizuje pasujące istniejące wyjątki. Zmieniona nazwa tworzy natomiast nowy wpis i nie usuwa starego.
- Otworzyć Config Studio przez podany niżej link dostępu, wybrać Configuration editor i przejść do Rules > Web exceptions.
- Wybrać Add i wpisać nową, unikalną nazwę, na przykład
Vendor API exact host no decrypt. - W Skip these checks włączyć tylko opcję niezbędną w danym przypadku. W przykładzie dotyczącym odszyfrowywania jest to Skip HTTPS decryption. Pozostałe opcje to Skip policy check, Skip cert validation, Skip malware scan i Skip zero-day protection. Opisane wyżej skutki dla ochrony obowiązują również przy tworzeniu wpisu w edytorze; nie wybierać kilku opcji na wszelki wypadek.
- W Match by URL/Domain wybrać zakres: Exact host only wyłącznie dla potwierdzonego hosta lub Domain + all subdomains, jeśli wszystkie jego subdomeny są wyraźnie wymagane i zatwierdzone. Dla
updates.vendor.examplew przykładzie pozostaje wybrane Exact host only;cdn.updates.vendor.examplenie ma być uwzględniony. - Wpisać potwierdzoną nazwę domeny w polu tekstowym, bez ścieżki URL, na przykład
updates.vendor.example. Zastąpić tę wartość dokumentacyjną rzeczywistym hostem docelowym. Wygenerowany regex i podgląd pojawiają się automatycznie; sprawdzić oba względem planowanego zakresu i opisanych wyżej przypadków pozytywnych i negatywnych. - Wybrać Add to URL Regex list. Wzorzec musi następnie pojawić się w URL Regex Patterns. Sama wartość widoczna w podglądzie nie jest jeszcze wpisem dodanym do listy.
- Opcjonalnie w URL Regex Patterns można przez + Add URL regex bezpośrednio dodać własny, wcześniej sprawdzony wzorzec. Nie jest to potrzebne przy tworzeniu na podstawie domeny; dodatkowe wzorce poszerzają możliwe dopasowanie ze względu na
OR. - Na koniec wybrać Add na dole formularza bocznego. Dopiero ten krok tworzy nowy wyjątek w edytorze.
Przed pobraniem porównać w Preview XML importu z zapisanym stanem początkowym i zgłoszeniem zmiany. Może zostać dodany tylko zatwierdzony nowy wyjątek; istniejące nazwy, kryteria, stany aktywacji i opcje pomijania nie mogą zmienić się przypadkowo. Zakres klientów także musi być prawidłowy: Exact host only ogranicza cel, nie źródła. Jeśli nie można wykazać, że wygenerowana konfiguracja zawiera wymagane źródło pilotażowe, nie importować jej; zamiast tego użyć opisanej wyżej procedury WebAdmin z Source IP addresses. Nie dodawać do XML niesprawdzonych dodatkowych pól.
Następnie wybrać Download > Download TAR i zapisać archiwum w chronionym miejscu. Sekcja Import, sprawdzenie działania i wycofanie zmiany opisuje komunikaty importu, porównanie stanu przed i po w Web > Exceptions, kontrolę aktywacji oraz nowe połączenia z testami pozytywnymi i negatywnymi. Podgląd XML ani udany import nie zastępują tego testu działania ochrony. Przy nieoczekiwanym wyniku wyłączyć nowy wpis w kontrolowany sposób i ponownie sprawdzić normalną ścieżkę ochrony. Ponowny import pierwotnego eksportu selektywnego nie usuwa automatycznie nowo utworzonego wyjątku; usunąć go w sposób ukierunkowany dopiero po wyjaśnieniu zależności. Nie naruszać przy tym istniejących wyjątków.
Wyłączenie kategorii zamiast pojedynczej domeny
Jeśli poufne dane finansowe nie powinny być deszyfrowane, odpowiednim kryterium może być kategoria Financial services. Wyjątek kategorii obejmuje jednak więcej celów niż pojedynczy host; klasyfikacja musi odpowiadać zamierzonemu zakresowi.
- W Web > Exceptions > Add an exception wpisać nazwę, na przykład
Financial services no decrypt. - Włączyć Web site categories, wybrać Add new item, a następnie Financial services.
- Zatwierdzić przez Apply selected items. Dla pilota ustawić także Source IP addresses z adresem IP klienta i Add.
- Wybrać tylko HTTPS decryption, następnie Save i włączyć przełącznik na liście.
- Przetestować zatwierdzoną usługę finansową i nieszkodliwy cel spoza kategorii, używając nowych połączeń. Ze względu na
ANDmuszą pasować zarówno źródło pilotażowe, jak i kategoria.
Pasujące połączenia HTTPS tracą deszyfrowanie oraz zależne od niego kontrole treści; obowiązuje także opisany wyżej skutek dotyczący certyfikatów. Nie oznacza to ogólnego zezwolenia na kategorię ani wyłączenia wszystkich pozostałych funkcji ochrony.
Wyjątek malware dla potwierdzonego hosta pobierania
Dostawca oceniony jako mało ryzykowny sam w sobie nie jest powodem do wyłączenia skanowania. Jeśli potrzebny jest uzasadniony wyjątek, zastosować powyższą procedurę z osobną nazwą, na przykład Vendor download scan exception, wzorcem potwierdzonego hosta i źródłem pilotażowym. Zamiast HTTPS decryption wybrać Malware and content scanning. Zero-day protection zostaje wybrane automatycznie; również starsze wyjątki pomijające skanowanie malware pomijają analizę Zero-Day. Następnie wybrać Save i włączyć przełącznik. Pasujące pobierania nie podlegają skanowaniu malware i treści ani analizie Zero-Day wraz z jej raportami. Nie wyłączać dodatkowo pozostałych kontroli. Sprawdzić zamierzoną ścieżkę ochrony przez nieszkodliwe, kontrolowane pobieranie z zatwierdzonego hosta i niewyłączony cel porównawczy; samo udane pobranie nie wystarcza.
Wprowadzanie innych kryteriów i zarządzanie istniejącymi wyjątkami
W Destination IP addresses wpisać potwierdzony adres IP witryny i nacisnąć Add, a nie adres IP klienta. W dozwolonych połączeniach kryterium celu z URL lub kategorią muszą pasować wszystkie wybrane typy. Wzorce URL używają znaków ASCII; umiędzynarodowione nazwy domen zapisuje się jako Punycode. Matching URLs w domyślnym wyjątku Apple Update może służyć jako przykład składni, a nie niezweryfikowany szablon zezwolenia.
Wykluczenie TLS: sprzeczne informacje o zakresie. Strony Add an exception dla SFOS 22.0 i 23.0 opisują ogólną logikę
ANDmiędzy typami kryteriów, ale Exclude a website from TLS inspection wyraźnie stwierdza, że wyjątków źródłowych i docelowych nie można łączyć. Dokładny zakres tego ograniczenia jest niejasny; ogólna logika dopasowania nie dowodzi, że takie połączenie jest dozwolone. Połączenie Source IP addresses i Destination IP addresses nie jest zatem procedurą o zweryfikowanej dopuszczalności. Przed włączeniem wykluczenia TLS potwierdzić faktyczną kompilację SFOS, ścieżkę DPI/proxy, konieczne pominięcie kontroli i wąski zakres hosta/kategorii. Zachować powyższe podejście łączące źródło pilotażowe z potwierdzoną nazwą hosta lub kategorią, bez dodawania kryterium docelowego IP. Cel wraz z potwierdzoną nazwą hosta/kategorią jest osobną opcją tylko wtedy, gdy zakres klientów został niezależnie ograniczony i zatwierdzony. Nie zastępować zamierzonego ograniczenia wyjątkiem opartym wyłącznie na źródle ani nie usuwać kryterium tylko po to, by uzyskać dopasowanie: rozszerza to pomijanie ochrony. Jeśli wymagane są ograniczenia zarówno źródłowego, jak i docelowego IP, zatrzymać się bez włączania lub rozszerzania wykluczenia i wraz z właścicielem zapory uzyskać od Sophos Support wyjaśnienie dla konkretnej kompilacji.
Domyślne wyjątki obsługują aktualizacje oprogramowania i inne ważne funkcje witryn. W Web > Exceptions przycisk Edit otwiera istniejący wyjątek, a Clone tworzy kopię. Przed jej włączeniem sprawdzić wszystkie przejęte kryteria i opcje pomijania. Web > General settings odpowiada za ogólną walidację certyfikatów HTTPS; pojedynczy wyjątek certyfikatu nie zastępuje tego ustawienia podstawowego.
Zrozumienie działania opcji pomijania
Przed zapisaniem musi być jasne, która ochrona zostaje utracona.
HTTPS decryption
Firewall nie deszyfruje pasującego ruchu HTTPS. Nie może więc wykonywać kontroli wymagających odszyfrowanej zawartości. Sophos dokumentuje także, że dla tego dopasowania dozwolony jest ruch z nieprawidłowym certyfikatem serwera.
Jeśli przeszkadza wyłącznie problem z certyfikatem, ta opcja jest często zbyt szeroka. Najpierw należy sprawdzić, czy HTTPS certificate validation jest bardziej precyzyjnym wyjątkiem.
HTTPS certificate validation
Firewall pomija kontrolę ważności certyfikatu serwera. Skonfigurowane deszyfrowanie może nadal działać. Ten wyjątek pasuje tylko do znanego celu ze świadomie zaakceptowanym problemem certyfikatu i wymaga bliskiej daty przeglądu.
Wygasły, nieprawidłowo nazwany lub niezaufany certyfikat należy w miarę możliwości naprawić w systemie docelowym. Dystrybucja właściwego Inspection CA rozwiązuje inny problem, który opisano w Dystrybucja certyfikatu CA dla TLS Inspection.
Malware and content scanning
Firewall pomija skanowanie malware i treści dla dopasowania. Automatycznie pomijane jest wtedy również Zero-day protection. Jeden wybór usuwa więc dwie warstwy ochrony ze ścieżki danych.
Przed utworzeniem tego wyjątku sprawdza się typ pliku, limit skanowania, szyfrowanie, działanie przy błędzie oraz faktycznie dopasowane pobieranie. Pełny przebieg testu zawiera artykuł Konfigurowanie i testowanie skanowania malware.
Zero-day protection
Analiza Zero-Day jest pomijana. Dla pasujących plików nie powstają raporty analizy, nawet jeśli klasyczne skanowanie malware zgłosi wykrycie. Ta opcja jest węższa niż całkowite pominięcie Malware and content scanning.
Policy checks
Kontrole Web Policy są pomijane dla pasującego żądania. Taki wyjątek może unieważnić kategorie, logikę użytkowników lub grup oraz inne decyzje policy. Powinien być używany wyłącznie przy jasno potwierdzonym problemie policy, a nie jako ogólne rozwiązanie dla zablokowanej witryny.
Nie uprawnia to do użycia Policy checks w celu zniesienia opisanej wyżej, udokumentowanej bezwzględnej blokady highly objectionable criminal activity.
Weryfikacja działania testami pozytywnymi i negatywnymi
Prawidłowe wczytanie strony dowodzi jedynie, że coś się zmieniło. Nie dowodzi jeszcze precyzji wyjątku.
- Zapisać czas, klienta pilotażowego, host docelowy i oczekiwane działanie.
- Zamknąć istniejącą sesję przeglądarki lub aplikacji i utworzyć nowe połączenie.
- Powtórzyć objęte problemem żądanie.
- W Log Viewer porównać źródłowy adres IP, host docelowy, Web Policy, Firewall Rule ID i Action.
- Dla wyjątku deszyfrowania porównać certyfikat serwera widoczny dla klienta ze stanem sprzed zmiany.
- Otworzyć podobny cel, który nie został wyłączony.
- Sprawdzić, czy ten cel nadal podlega normalnej Web Policy, Decryption Rule i łańcuchowi skanowania.
- Na krótko wyłączyć wyjątek i odtworzyć pierwotny błąd, jeśli jest to bezpieczne w oknie serwisowym.
- Ponownie włączyć wyjątek i jeszcze raz potwierdzić wynik.
Jeśli QUIC lub HTTP/3 omija oczekiwaną ścieżkę TLS przez TCP, test może być mylący. Granicę opisano w Prawidłowe blokowanie QUIC i HTTP/3. Log Viewer, Policy Tester i Packet Capture pokazują, która reguła i policy faktycznie pasują.
Policy tester otwiera się w Diagnostics > Tools, w sekcji Pop-out tools. Metoda Firewall, SSL/TLS, and web pomaga ustalić oczekiwaną regułę zapory, SSL/TLS inspection rule i Web Policy. Narzędzie testuje jednak ruch webowy tylko w Transparent Mode, dlatego nie odwzorowuje jawnego przepływu direct web proxy. Faktyczne zastosowanie Web Exception należy zawsze potwierdzić nowym żądaniem i rzeczywistymi logami.
Aby uzyskać dowód w logach, w regule zapory musi być aktywne Log firewall traffic; należy także włączyć Log connections w SSL/TLS inspection rule. W System services > Log settings odpowiednie typy logów muszą być aktywne dla Local reporting. Następnie w Log Viewer trzeba zawęzić widok do czasu testu i źródłowego adresu IP oraz porównać moduły Web filter i SSL/TLS inspection z Firewall Rule ID, policy i Action. Obsługę opisuje Prawidłowe używanie Sophos Firewall Log Viewer. Jeśli cały widok pozostaje pusty, należy przejść do Log Viewer nie aktualizuje się, zamiast rozszerzać wyjątek na podstawie przypuszczeń.
Systematyczne zawężanie błędów
Wyjątek nie działa
- Udokumentowana bezwzględna blokada kategorii nie jest błędem dopasowania. Celowo ukryta nazwa domeny nie oznacza tutaj usterki logowania. Kategorie web i Web Policies wyjaśniają tę granicę; nie próbować szerszego wyjątku ani testów z tymi treściami.
- Przełącznik w Web > Exceptions nie jest włączony.
- Dodatkowy typ kryterium nie pasuje z powodu logiki
AND. - Regex nie jest zakotwiczony na początku lub nie odwzorowuje rzeczywistego hostname.
- Dla wyjątku ścieżki HTTPS ruch nie jest deszyfrowany, więc ścieżka pozostaje niewidoczna.
- W DPI Mode dla przepływu nie jest aktywna Web Policy, Malware and content scanning ani ATP.
- Działa inna reguła zapory, Web Policy lub tryb niż oczekiwano.
- Istniejąca sesja przeglądarki lub aplikacji nie została utworzona ponownie.
Wyjątek działa zbyt szeroko
- Wzorzec zawiera niekontrolowany wildcard lub tylko luźny tekst root domain.
- Brakuje Source IP addresses lub innego zakresu pilotażowego.
- Wiele wzorców URL tego samego typu działa przez
ORszerzej, niż oczekiwano. - Wyłączono całą Web category zamiast konkretnego hosta.
- Aktywowano kilka opcji pomijania, chociaż problem powoduje tylko jedna kontrola.
Witryna działa, ale wpływ na ochronę jest niejasny
Wyjątku nie należy dalej rozszerzać. Najpierw wspólnie sprawdza się certyfikat w przeglądarce, logi Web i SSL/TLS Inspection, Firewall Rule ID, Web Policy oraz kontrolowane pobieranie. Bez tych dowodów wyjątek jest jedynie funkcjonalnym obejściem, a nie zaakceptowaną decyzją bezpieczeństwa.
Jeśli narzędzia WebAdmin nie pozwalają wyodrębnić przyczyny, Prawidłowe przypisywanie logów usług Sophos Firewall łączy logi DPI, proxy, malware i Zero-Day z objętą problemem ścieżką ochrony. Debug nie jest włączany jako pierwszy krok.
Wysokie użycie CPU i powolny dostęp do stron po zmianach regex
W Diagnostics > System graphs najpierw porównać czas i przebieg obciążenia z powolnymi żądaniami oraz ostatnimi zmianami wyjątków. W Web > Exceptions sprawdzić Selection criteria lub Matching URLs wszystkich aktywnych wyjątków: czy brakuje ^, kropek hosta ze znakiem ucieczki lub wyraźnej granicy hosta? Czy występują szerokie wildcardy lub liczne niezakotwiczone teksty domen?
Przy autoryzowanym dostępie do konsoli wykonać w Device Management > Advanced Shell poniższe polecenie tylko do odczytu. Pokazuje bieżące obciążenie procesów, ale nie zmienia konfiguracji; widok zamyka się klawiszem q.
top
Jeśli awarrenhttp lub snort zajmują czołowe miejsca pod względem użycia CPU, regex Web Exceptions mogą przyczyniać się do obciążenia. To wskazówka, nie dowód jedynej przyczyny: oba procesy wykonują inne kontrole. Analizować razem obciążenie, żądania i wzorce, wprowadzić tylko ograniczoną zmianę i ponownie zmierzyć obciążenie przy porównywalnym ruchu. Jeśli CPU pozostaje wysokie, dalej zawężać inne przyczyny w danej ścieżce ochrony; nie wyłączać zbiorczo inspekcji ani wszystkich wyjątków na potrzeby testu porównawczego.
Selektywna naprawa istniejących regex
Dla kilku wyjątków najczytelniejsza jest ścieżka Web > Exceptions > Edit. Najpierw zachować nazwy, stan włączenia, kryteria i opcje pomijania, a potem poprawić wyłącznie przetestowany wzorzec URL. Przy wielu wpisach można zamiast tego wyeksportować moduł WebFilterException. Eksport obejmuje wybrane konfiguracje Web Exceptions, nie automatycznie tylko jeden wadliwy wyjątek. Także niezmienione wpisy muszą zostać zachowane w porównaniu stanu przed zmianą i po niej.
Przed obydwoma wariantami importu bezpiecznie zachować aktualną kopię zapasową zapory i niezmieniony eksport selektywny. Przed importem ustalić drogę wycofania zmiany, okno serwisowe i dostęp administratora. Eksport selektywny nie zastępuje pełnej kopii zapasowej. Oryginał, kopię roboczą i zatwierdzony wynik przechowywać osobno; konfiguracje i wygenerowane raporty zawierają informacje wewnętrzne i mogą znajdować się tylko na zatwierdzonym komputerze administratora z chronionym dostępem.
Eksport WebFilterException i kontrola w Config Studio
- Na tej samej zaporze otworzyć Backup & firmware > Import export i wybrać Export selective configuration.
- Przez Add new item wyszukać
WebFilterExceptioni zatwierdzić przez Apply selected items. Nie zaznaczać Include dependent entity: inne obszary konfiguracji nie mają być edytowane równocześnie. - Przez Export lub Download zapisać archiwum
API-[timestamp].tar. Rozpakować kopię roboczą; zawieraEntities.xml. - Otworzyć Sophos Firewall Config Studio. Wybrać Configuration editor i Rules > Web exceptions, a następnie przez Import wczytać selektywny plik
Entities.xml. - W Config Analysis zwrócić uwagę na Bad regex. Otworzyć dany wpis przez Edit, sprawdzić propozycję przez Apply Fix i zatwierdzić przez Update. Nie zmieniać nazw; zmieniona nazwa sprawia, że import na zaporze tworzy nowy wyjątek zamiast aktualizować istniejący.
- Sprawdzić propozycję na przypadkach pozytywnych, negatywnych i długich ciągach bez dopasowania. Dla nowych wzorców hosta Exact host only i Domain + all subdomains rozróżniają pożądany zakres; naprawa nie może przypadkowo dopuścić subdomen. Automatyczna korekta nie zastępuje tej decyzji ani testu wpływu na ochronę.
- W Preview sprawdzić konfigurację importu i porównać ją z oryginałem: mają zmienić się wyłącznie zatwierdzone regex, nie nazwy, źródła, kryteria celu, włączenie ani opcje pomijania. Zapisać zatwierdzone archiwum przez Download > Download TAR.
Config Studio przetwarza dane konfiguracji w przeglądarce na urządzeniu końcowym; parsowanie, analiza i tworzenie raportów nie przesyłają tych danych na zewnątrz. Mimo to pliki lokalne, pobrane pliki i raporty HTML pozostają poufne. Nie przekazywać konfiguracji innym narzędziom analizy online. Edycja lub pobranie w Config Studio nie zmienia jeszcze niczego na zaporze.
Alternatywa: kontrolowana edycja Entities.xml
Bez Config Studio edytuje się tę samą selektywnie wyeksportowaną kopię roboczą w edytorze tekstu. Zmienić tylko objęte problemem wzorce URL; nie zastępować zbiorczo wszystkich kropek w pliku XML. Struktura XML, nazwy obiektów i pozostałe pola pozostają niezmienione. Przed spakowaniem sprawdzić poprawną budowę XML i pełny diff. Nie importować przy niejasnej składni lub nieoczekiwanych dodatkowych plikach.
Zachować dokładną nazwę Entities.xml i spakować pliki do nowego archiwum TAR o takiej samej strukturze jak oryginał, nie do ZIP i nie pod dodatkowym katalogiem. Jeśli oryginał zawiera inne pliki, nie odrzucać ich po cichu. Tej prostej procedury Web Exceptions nie wolno przenosić na inne moduły ani wrażliwe, współzależne obiekty.
Import, sprawdzenie działania i wycofanie zmiany
Import nadpisuje pasujące istniejące ustawienia. Pomyślne przesłanie archiwum nie dowodzi ani wąskiego dopasowania, ani niezmienionej ochrony. Najpierw zatwierdzić diff, a następnie importować w uzgodnionym oknie serwisowym.
W Backup & firmware > Import export > Import wybrać sprawdzony .tar przez Browse i uruchomić Import. Sprawdzić komunikaty importu pod kątem błędów; następnie w Web > Exceptions porównać nazwy i liczbę wpisów, stan włączenia, Matching URLs, kryteria i opcje pomijania ze stanem docelowym. Ustawienia bez pasującego wpisu importu pozostają; import nie usuwa automatycznie niepożądanych dodatkowych wyjątków.
Następnie utworzyć nowe połączenia, powtórzyć istniejące testy pozytywne i negatywne z logami, a przy naprawie wydajności porównać przebieg CPU i obciążenie procesów ze stanem bazowym. W razie błędów zatrzymać wdrożenie i w kontrolowany sposób wyłączyć dany wyjątek, jeśli skutki dla aplikacji są akceptowalne. W celu przywrócenia wybranych ustawień można zaimportować niezmieniony eksport selektywny z tej samej zapory; wcześniej wykluczyć zmiany wprowadzone w międzyczasie, bo również zostałyby nadpisane. Nie włączać ponownie bez sprawdzenia poprzedniego stanu, którego zakres okazał się zbyt szeroki. Odtworzenie pełnej kopii zapasowej pozostaje osobno zaplanowaną drogą awaryjną, nie pierwszym krokiem wycofania pojedynczej regex. Po każdym wycofaniu zmiany ponownie sprawdzić konfigurację i ścieżkę ochrony.
Planowanie WebFilterException przez XML API
Opisany wyżej selektywny import Entities.xml nie jest uniwersalną instrukcją korzystania z XML API. Dokumentacja referencyjna obiektów dla SFOS 22.0 i 23.0 opisuje Add Web Filter Exception / Update Web Filter Exception z obiektem WebFilterException. Poniższe zestawienia pomagają sprawdzić planowaną automatyzację; nie stanowią kompletnego żądania, gotowego do wysłania ani przetestowanego na zaporze. Dostęp, chronione dane uwierzytelniające, jawnie określona operacja, struktura żądania właściwa dla wersji i bezpieczna ocena odpowiedzi należą do centralnej procedury Bezpieczne korzystanie z XML API. Bez składni potwierdzonej dla konkretnej kompilacji nie wykonywać zapisu.
Rozróżnienie aktywacji, flag pomijania i DomainList
Enabled włącza wyjątek i dopuszcza wartości on lub off. Pięć flag pomijania również dopuszcza wartości on lub off, ale oznacza pomijanie kontroli, a nie jej włączenie: HttpsDecrypt dotyczy deszyfrowania HTTPS, VirusScan — skanowania malware, PolicyCheck — kontroli Web Policy, ZeroDayProtection — ochrony Zero-Day, a CertValidation — walidacji certyfikatów HTTPS. Wartość on we fladze pomijania oznacza zatem obejście ochrony. Opisane wyżej skutki dla ochrony nadal obowiązują, zwłaszcza automatyczne pomijanie Zero-Day przy pomijaniu skanowania malware. Z ustawionej flagi pomijania nie wnioskować, że wpis jest już aktywny lub pasuje do danego ruchu.
Dokumentacja referencyjna pokazuje w DomainList kryteria dopuszczające wiele wartości oraz osobne przełączniki na poziomie obiektu:
EnableSrcIPzSrcIp: sprawdzanie źródłowego adresu IP; tutaj należy wskazać klienta.EnableDstIPzDstIp: sprawdzanie docelowego adresu IP; tutaj należy wskazać adres witryny.EnableURLRegexzURLRegex: sprawdzanie wzorca URL, a nie lista domen z automatycznie uwzględnianymi subdomenami.EnableWebCatzWebCategory: sprawdzanie kategorii web.
Cztery przełączniki są skalarnymi wartościami yes/no, a nie on/off. Cztery kryteria są tablicami ciągów znaków dopuszczającymi wiele wartości; dla każdego wpisu SrcIp i DstIp dokumentacja referencyjna podaje limit 43 znaków. Samo wypełnienie tablicy nie zastępuje potwierdzonego przełącznika aktywacji. Zgodnie z logiką dopasowania różne włączone typy kryteriów muszą pasować przez AND, a wartości wewnątrz jednego typu — przez OR. Dodatkowe wzorce URL mogą więc poszerzyć dopasowanie. Opisane wyżej nierozstrzygnięte ograniczenie TLS dotyczące łączenia wyjątków dla źródłowego i docelowego IP nadal obowiązuje: obecność obu pól API nie dowodzi, że takie połączenie jest dozwolone. Nie tworzyć szerszego obejścia ochrony przez pominięcie kryterium.
Dla URLRegex nadal wymagane są zakotwiczenie na początku, kropki hosta ze znakami ucieczki, wyraźna granica hosta, ASCII/Punycode oraz testy pozytywne, negatywne i długich ciągów bez dopasowania. Wzorzec z dokumentacji referencyjnej API nie jest zatwierdzoną listą dozwolonych adresów i nie zastępuje ani tych testów, ani ograniczenia dotyczącego ścieżki HTTPS. Samo sprawdzenie składni XML nie dowodzi bezpiecznego dopasowania.
Name jest jedynym parametrem oznaczonym jako obowiązkowy: to skalarny ciąg znaków o długości najwyżej 60 znaków; niedozwolone są ^, ;, ', " i \. Opcjonalny NewName służy do zmiany nazwy i ma te same ograniczenia. Nie należy utożsamiać go z tworzeniem nowego wpisu przez zmianę nazwy podczas importu selektywnego. Desc jest opcjonalnym skalarnym ciągiem znaków o długości najwyżej 250 znaków; IsDefault oznacza wyjątek domyślny za pomocą skalarnej wartości yes/no i nie daje uprawnienia do modyfikowania obiektów domyślnych. Pozostałe parametry są opcjonalne, a ich kolumny wartości domyślnych są puste. Nie wynika z tego ani konkretna wartość domyślna, ani gwarancja zachowania pominiętych wartości podczas aktualizacji. Najpierw zabezpieczyć zapisany stan i ustalić pełny zakres porównania stanu docelowego z rzeczywistym.
Klasyfikowanie odpowiedzi według operacji, kodu i symbolu
Obie dokumentacje referencyjne obiektów zawierają dokładnie poniższe przyporządkowania. Nazwy operacji i symbole celowo pozostają niezmienione:
| Operacja | Kod XML | Symbol w dokumentacji referencyjnej |
|---|---|---|
| Add Web Filter Exception | 200 | Message.WebFilterExceptionAddSuccess |
| Add Web Filter Exception | 500 | Message.WebFilterExceptionAddFail |
| Add Web Filter Exception | 502 | Message.WebFilterExceptionRecordExist |
| Add Web Filter Exception | 522 | Message.WebExceptionsLimit |
| Update Web Filter Exception | 200 | Message.WebFilterExceptionUpdateSuccess |
| Update Web Filter Exception | 500 | Message.WebFilterExceptionUpdateFail |
Te kody XML nie są kodami statusu HTTP. Message.* pozostaje nierozwiniętym symbolem dokumentacji, a nie zweryfikowanym komunikatem zwracanym podczas działania ani jednoznaczną przyczyną błędu. W szczególności z Message.WebExceptionsLimit nie wolno wyprowadzać liczbowego limitu. Add i Update mają różne symbole powodzenia i błędu; przyporządkowań Add dla 502 i 522 nie przenosi się na Update.
Rzeczywistą odpowiedź wraz z operacją i kodem XML zachować w chronionym miejscu, również w przypadku przekroczenia limitu czasu lub niejasnego wyniku. Przed każdą ponowną próbą zapisu sprawdzić faktycznie zapisany wpis za pomocą zapytania tylko do odczytu, potwierdzonego dla konkretnej kompilacji, lub w Web > Exceptions: starą i ewentualnie nową nazwę, liczbę wpisów, stan włączenia, wszystkie kryteria i flagi pomijania. Nawet zgłoszone powodzenie nie zastępuje tego porównania. Jeśli wpis już istnieje, nie tworzyć go ponownie, nie zmieniać jego nazwy, nie nadpisywać go ani nie usuwać kryteriów w ciemno. Przy niejasnym lub częściowo zmienionym stanie zatrzymać się i wyjaśnić sytuację z właścicielem zapory na podstawie odpowiedzi, stanu poprzedniego i stanu docelowego. Po potwierdzonej zmianie utworzyć nowe połączenia i wykonać istniejące testy pozytywne i negatywne; dopiero one sprawdzają działanie ochrony. Centralna instrukcja API dodatkowo wyjaśnia ostrzeżenia, częściowe powodzenie i bezpieczne postępowanie bez ponawiania prób w ciemno.
Przegląd i rollback
Każda produkcyjna Web Exception zawiera co najmniej:
- uzasadnienie techniczne i ticket
- właściciela aplikacji i firewalla
- objęte hosty, ścieżki, źródła i grupy użytkowników
- dokładnie pomijane kontrole
- datę testów pozytywnych i negatywnych
- datę przeglądu lub wygaśnięcia
- udokumentowany stan poprzedni
W ramach rollbacku wyjątek najpierw się wyłącza, zamiast natychmiast go usuwać. Następnie ponownie testuje się pierwotny błąd, normalną ścieżkę ochrony i nieobjęte cele. Wyjątek można usunąć dopiero wtedy, gdy nie ma już zależności.
Wyjątki domyślne i dostawców nie są zmieniane bez kontroli. W przypadku własnego wyjątku musi pozostać jasne, dlaczego istnieje i kto ponownie oceni go później.
Operacyjna lista kontrolna
- Określono DPI Mode lub Web Proxy Mode.
- Potwierdzono faktycznie pasującą regułę zapory i Web Policy.
- Z rzeczywistego ruchu zarejestrowano hostname i, w razie potrzeby, ścieżkę URL.
- Regex zakotwiczono na początku i przetestowano wobec niedopasowań.
- Uwzględniono
ANDmiędzy typami kryteriów iORwewnątrz typu. - Wybrano tylko najmniejszą niezbędną opcję pomijania.
- Uwzględniono automatyczne pomijanie Zero-Day przy Malware and content scanning.
- Ograniczono źródło pilotażowe.
- Wykonano testy pozytywne i negatywne.
- Wspólnie sprawdzono Log Viewer, certyfikat i wpływ na ochronę.
- Udokumentowano właściciela, ticket, datę przeglądu i rollback.
Często zadawane pytania
Czy dla Certificate Pinning należy użyć Web Exception?
Dlaczego ścieżka URL nie działa razem z Skip HTTPS decryption?
Czy Web Exception może dotyczyć tylko jednego klienta pilotażowego?
AND, wzorzec celu i źródło pilotażowe muszą wtedy pasować jednocześnie.