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.

Web Exception w siedmiu krokach

1. Udokumentować klienta, host docelowy, ścieżkę URL, protokół i czas zdarzenia.
2. Sprawdzić, czy używany jest DPI Mode czy Web Proxy Mode oraz która reguła zapory i Web Policy faktycznie działają.
3. Ustalić, czy przeszkadza wyłącznie deszyfrowanie TLS, czy konkretna kontrola Web Protection.
4. W Web > Exceptions > Add an exception zdefiniować wąskie kryteria URL, kategorii, źródła lub celu.
5. W Skip the selected checks or actions wybrać tylko najmniejszą niezbędną opcję.
6. Włączyć wyjątek i ponownie przetestować ten sam przepływ w nowym procesie przeglądarki lub aplikacji.
7. 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.

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.

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.

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.

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.

1. Otworzyć Web > Exceptions.
2. Wybrać Add an exception.
3. Ustawić opisową nazwę, na przykład Vendor API no decrypt.
4. Włączyć URL pattern matches.
5. Wprowadzić przetestowany i zakotwiczony wzorzec w Search/Add i zatwierdzić przez Add.
6. Dla pilota włączyć również Source IP addresses i wpisać konkretny adres IP klienta.
7. W Skip the selected checks or actions wybrać wyłącznie HTTPS decryption.
8. Wybrać Save.
9. Na liście włączyć przełącznik nowego wyjątku.
10. 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.

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.

Weryfikacja działania testami pozytywnymi i negatywnymi

Prawidłowe wczytanie strony dowodzi jedynie, że coś się zmieniło. Nie dowodzi jeszcze precyzji wyjątku.

1. Zapisać czas, klienta pilotażowego, host docelowy i oczekiwane działanie.
2. Zamknąć istniejącą sesję przeglądarki lub aplikacji i utworzyć nowe połączenie.
3. Powtórzyć objęte problemem żądanie.
4. W Log Viewer porównać źródłowy adres IP, host docelowy, Web Policy, Firewall Rule ID i Action.
5. Dla wyjątku deszyfrowania porównać certyfikat serwera widoczny dla klienta ze stanem sprzed zmiany.
6. Otworzyć podobny cel, który nie został wyłączony.
7. Sprawdzić, czy ten cel nadal podlega normalnej Web Policy, Decryption Rule i łańcuchowi skanowania.
8. Na krótko wyłączyć wyjątek i odtworzyć pierwotny błąd, jeśli jest to bezpieczne w oknie serwisowym.
9. 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ą.

Systematyczne zawężanie błędów

Wyjątek nie działa

• 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 OR szerzej, 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.

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 AND między typami kryteriów i OR wewną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