Tworzenie i bezpieczne używanie URL Groups na Sophos Firewall

URL Group grupuje konkretne domeny, aby można było używać ich razem w Web Policy lub SSL/TLS inspection rule. Brzmi to prosto, ale ma ważną konsekwencję: każda zmiana w grupie wpływa na wszystkie reguły i zasady, które odwołują się do tego obiektu.

Bezpieczny proces nie zaczyna się więc od możliwie największej listy producenta. Najpierw ustala się rzeczywiście używane domeny na podstawie żądania, logu lub dokumentacji producenta. Następnie powstaje mała grupa o jasno określonym celu, właścicielu i planie testów.

URL Group w siedmiu krokach

1. Udokumentować klienta, którego dotyczy zmiana, rzeczywiste hosty docelowe oraz oczekiwaną decyzję: zezwolić, zablokować lub nie odszyfrowywać.
2. Sprawdzić, czy URL Group jest właściwym narzędziem. Przetwarza domeny, ale nie ścieżki URL, ciągi zapytań ani wyrażenia regularne.
3. W sekcji Web > URL groups > Add ustawić czytelną nazwę i zaakceptować każdą poprawną nazwę domeny przyciskiem Add.
4. Wybrać grupę jako Activity w Web Policy albo w polu Categories and websites w SSL/TLS inspection rule.
5. Sprawdzić kolejność reguł, stan, zakres źródłowy i logowanie. Sama grupa jeszcze niczego nie zezwala ani nie blokuje.
6. Za pomocą nowego połączenia przetestować oczekiwaną zgodność i celowo podobny brak zgodności.
7. Udokumentować listę domen, obiekty korzystające z grupy, właściciela, uzasadnienie, datę testu i rollback.

⚠️ Wiele domen w URL Group jest ocenianych za pomocą OR. Wystarczy jedna zgodność. W przypadku wykluczeń TLS wpis domeny obejmuje również jej subdomeny. Zbyt szeroka domena główna albo wysoko umieszczona reguła Allow może więc objąć znacznie więcej ruchu, niż planowano.

Co kontroluje URL Group, a czego nie

URL Group jest obiektem domenowym wielokrotnego użytku. Określa, które domeny należą do siebie. Reguła używająca obiektu decyduje następnie, co stanie się ze zgodnością.

Typowe zastosowania:

• mała biznesowa allowlist w Web Policy
• jawna blocklist dla znanych domen
• lista domen w regule Don't decrypt
• lokalna lista wykluczeń TLS dla potwierdzonych problemów z odszyfrowywaniem

URL Group nie jest jednak właściwym narzędziem do każdego przypadku webowego:

• Web category: szeroka klasyfikacja treści lub własna kategoria ze ścieżkami URL albo słowami kluczowymi
• Web Exception: dopasowanie oparte na regex i selektywne pomijanie kontroli webowych, skanowania lub certyfikatów
• FQDN Host: oparty na DNS obiekt sieciowy dla reguł firewalla, NAT lub routingu
• Threat Feed: dynamicznie utrzymywane listy IOC lub domen

Pełną logikę zasad opisuje artykuł Konfigurowanie Web Protection za pomocą Web Policies. Wybór między własną kategorią a listą domen przedstawiono w artykule Używanie web categories i Instant Alerts. Do dynamicznych list bezpieczeństwa służą Threat Feeds na Sophos Firewall.

Domena zamiast pełnego adresu URL

W polu Search/Add SFOS oczekuje poprawnej nazwy domeny. Protokół, ścieżka i zapytanie nie należą do tego pola.

Poprawne wartości przykładowe:

updates.vendor.example
cdn.vendor.example

Nieodpowiednie wartości:

https://updates.vendor.example/download/file.bin
*.vendor.example
^updates\.vendor\.example/

Końcówka .example jest zarezerwowana do celów dokumentacyjnych. W rzeczywistej konfiguracji przykłady zastępuje się domenami potwierdzonymi w logu, żądaniu lub dokumentacji producenta.

Jeśli wymagana jest konkretna ścieżka URL, parametr zapytania lub wyrażenie regularne, zależnie od celu właściwa będzie własna web category albo bezpiecznie ograniczona Web Exception. Listy domen nie rozszerza się pozornie wygodnym wzorcem wildcard.

Planowanie zakresu domen

Przykład wykorzystuje grupę Vendor update domains z dwoma oddzielnymi hostami:

• updates.vendor.example do pobierania aktualizacji
• cdn.vendor.example dla powiązanego endpointu treści

Domena główna vendor.example celowo nie jest używana jako skrót. Sophos jednoznacznie dokumentuje, że w dopasowaniu URL Groups w wykluczeniach TLS uwzględniane są subdomeny. Wpis vendor.example obejmowałby więc w tym procesie również login.vendor.example, telemetry.vendor.example i inne subdomeny.

Nawet węższy wpis może obejmować subdomeny. W dopasowaniu TLS updates.vendor.example może więc objąć również api.updates.vendor.example. Jeśli oczekiwany jest tylko jeden konkretny host, oprócz celu pozytywnego zawsze testuje się celowo podobny host jako cel negatywny.

Wiele wpisów w tej samej grupie nie stanowi listy obowiązkowej. Ze względu na logikę OR wystarczy zgodność jednej domeny. Jeśli usługa działa tylko wtedy, gdy dwa hosty są dostępne równocześnie, każdy host trzeba przetestować osobno. URL Group nie dowodzi zależności funkcjonalnej między nimi.

Tworzenie URL Group

1. Otworzyć Web > URL groups.
2. Wybrać Add.
3. Ustawić nazwę, na przykład Vendor update domains.
4. W polu Search/Add wpisać updates.vendor.example.
5. Wybrać Add i sprawdzić, czy wartość pojawiła się na liście.
6. W ten sam sposób dodać cdn.vendor.example.
7. Wybrać Save.
8. Ponownie otworzyć zapisaną grupę i sprawdzić nazwę oraz obie domeny.

Wybranie Add jest osobnym krokiem. Nazwa domeny, która pozostaje tylko w polu wprowadzania, nie jest jeszcze częścią grupy.

Aktualna pomoc SFOS 22 nie podaje stałej maksymalnej liczby domen w URL Group. Nie jest to obietnica nieograniczonej listy. Jeśli oczekiwane są setki wpisów, częste zmiany u producenta albo stale zmieniające się IOC, ręcznie utrzymywana URL Group jest zazwyczaj niewłaściwym modelem operacyjnym.

Używanie URL Group w Web Policy

URL Group uzyskuje działanie Allow, Warn, Block lub Quota dopiero za pośrednictwem reguły Web Policy.

1. Otworzyć Web > Policies.
2. Edytować daną policy lub utworzyć nową.
3. Wybrać Add rule.
4. W sekcji Users ustawić przewidziany zakres użytkowników lub grup.
5. W sekcji Activities usunąć ogólny wybór All web traffic i wybrać URL Group Vendor update domains.
6. Ustawić oczekiwane działanie dla HTTP i HTTPS, na przykład Allow lub Block.
7. Sprawdzić pozycję reguły, włączyć jej stan i zapisać policy.
8. W sekcji Rules and policies > Firewall rules sprawdzić, czy ta Web Policy jest wybrana w polu Web filtering w regule firewalla, która rzeczywiście pasuje.
9. Na czas odbioru włączyć Log firewall traffic.

Reguły Web Policy są oceniane od góry do dołu. Ogólna reguła Allow nad nową regułą URL Group może ukryć dopasowanie. Z kolei konkretna reguła Allow umieszczona zbyt wysoko może unieszkodliwić późniejsze reguły Block. Pozycja jest więc częścią decyzji bezpieczeństwa, a nie tylko kwestią prezentacji.

URL Group w Web Policy nie zastępuje reguły firewalla. Reguła firewalla najpierw zezwala na przepływ danych między strefami, a następnie przypisana Web Policy ocenia dostęp webowy. Artykuł Testowanie reguł za pomocą Log Viewer, Policy Tester i Packet Capture pokazuje, jaka reguła i jaka polityka są rzeczywiście stosowane.

Używanie URL Group jako wykluczenia TLS

W przypadku potwierdzonych problemów z Certificate Pinning lub innych problemów z odszyfrowywaniem ten sam typ obiektu można wykorzystać w SSL/TLS inspection rule z ustawieniem Action: Don’t decrypt. SFOS wydajnie porównuje domenę jako tekst za pomocą Server Name Indication, czyli SNI.

Istnieją dwa przejrzyste warianty.

Uzupełnienie Local TLS exclusion list

Local TLS exclusion list jest wbudowaną URL Group i domyślnie jest pusta. Należy do stałej domyślnej reguły wykluczeń na samej górze tabeli reguł SSL/TLS.

Ścieżka ręczna:

Web > URL groups > Local TLS exclusion list

Ten wariant pasuje do lokalnie potwierdzonego wykluczenia domeny, które ma obowiązywać niezależnie od węższej własnej reguły źródłowej lub użytkownika. Domeny można też dodawać do tej listy za pomocą funkcji rozwiązywania problemów w Control Center lub Log Viewer. Każdą nową domenę dokumentuje się i testuje jako produkcyjny wyjątek bezpieczeństwa.

Managed TLS exclusion list służy innemu celowi. Sophos utrzymuje w niej znane niezgodne domeny i może aktualizować listę wraz z aktualizacjami firmware. Własne domeny operacyjne nie zastępują świadomie zaplanowanej lokalnej reguły w tym obiekcie zarządzanym przez producenta.

Tworzenie własnej reguły Don’t decrypt

Jeśli wykluczenie ma być ograniczone do określonych źródeł, użytkowników, usług lub stref docelowych, własna reguła jest łatwiejsza do kontroli:

1. Otworzyć Rules and policies > SSL/TLS inspection rules.
2. Wybrać Add.
3. Ustawić nazwę, na przykład Vendor updates no decrypt.
4. Wybrać Action: Don’t decrypt.
5. Włączyć Log connections.
6. Ograniczyć Source zones, Source networks, Users, Destination zones i Services do wymaganego zakresu.
7. W polu Categories and websites wybrać URL Group Vendor update domains.
8. Umieścić regułę bezpośrednio pod domyślnymi wykluczeniami i nad ogólnymi regułami Decrypt.
9. Zapisać i przetestować za pomocą nowego połączenia.

SSL/TLS inspection rules działają niezależnie od reguł firewalla. Poprawnie pasująca reguła firewalla nie dowodzi więc, że działa oczekiwana reguła TLS. Z kolei Don’t decrypt wyłącza tylko odszyfrowywanie w tym procesie. Nie jest to ogólne zezwolenie na dowolny ruch sieciowy.

URL Groups są wydajniejsze dla tego dopasowania SNI niż wiele FQDN Host Objects w źródle lub miejscu docelowym reguły TLS. FQDN Host Objects rozwiązują nazwy przez DNS i pełnią inną funkcję. Różnice wyjaśnia artykuł Tworzenie i bezpieczne używanie FQDN Hosts.

Jeśli połączenie TLS nie zawiera użytecznego SNI, domeny nie można w ten sposób rozpoznać. Nie należy wtedy rozszerzać grupy domeną główną. Najpierw trzeba sprawdzić docelowy adres IP, certyfikat, Packet Capture i rzeczywisty przepływ aplikacji.

Weryfikacja dopasowania testem pozytywnym i negatywnym

Pomyślne załadowanie strony dowodzi tylko, że usługa jest dostępna. Nie dowodzi ani poprawnej reguły Web Policy, ani oczekiwanego wykluczenia TLS.

Test Web Policy

1. Zanotować klienta pilotażowego, użytkownika, czas i oczekiwane działanie.
2. Całkowicie zamknąć sesję przeglądarki lub aplikacji i uruchomić ją ponownie.
3. Otworzyć updates.vendor.example albo rzeczywistą domenę pozytywną.
4. W Log Viewer sprawdzić Source, User, Domain, Firewall Rule ID, Web Policy i Action.
5. Przetestować login.vendor.example albo rzeczywisty host, którego celowo nie dodano.
6. Potwierdzić, że host negatywny jest nadal oceniany przez normalną następną regułę policy.
7. Jeśli potrzebne są dwie wartości grupy, przetestować każdy host osobno.

Jeśli przeglądarka używa QUIC albo HTTP/3, oczekiwany webowy przepływ TCP może wyglądać inaczej. Najpierw należy odróżnić test od QUIC i HTTP/3.

Test wykluczenia TLS

1. Nawiązać nowe połączenie TLS z hostem pozytywnym.
2. W logu SSL/TLS sprawdzić pasującą regułę i stan bez odszyfrowywania.
3. Porównać certyfikat widoczny dla klienta ze stanem przy normalnej regule odszyfrowywania.
4. Otworzyć podobny host negatywny, którego nie ma w grupie.
5. Potwierdzić, że host nadal jest obsługiwany przez oczekiwaną regułę Decrypt.
6. Udokumentować zakres źródłowy, SNI i pozycję reguły.

Aby świadomie przetestować rollback, podczas okna serwisowego należy przywrócić udokumentowany wcześniejszy stan reguły webowej lub TLS korzystającej z grupy. Host pozytywny powinien wtedy ponownie wykazać poprzednie zachowanie. Dopiero taka próba kontrolna zmienia działający workaround w powtarzalny odbiór.

Systematyczne zawężanie błędów

URL Group nie działa w Web Policy

• Wartość domeny wprowadzono, ale nie zatwierdzono przyciskiem Add.
• URL Group nie jest wybrana w sekcji Activities aktywnej reguły policy.
• All web traffic lub inna wcześniejsza reguła pasuje jako pierwsza.
• Reguła policy jest wyłączona.
• Web Policy nie jest wybrana w regule firewalla, która rzeczywiście pasuje.
• Rzeczywiste żądanie używa nieudokumentowanego hosta przekierowania, logowania, API lub CDN.
• Istniejące połączenie przeglądarki albo QUIC nie zostało nawiązane ponownie.

Wykluczenie TLS nie działa

• URL Group nie jest wybrana w polu Categories and websites oczekiwanej reguły.
• Reguła Don't decrypt znajduje się pod regułą Decrypt, która już pasuje.
• Source, User, Zone, Service lub inne kryterium reguły nie pasuje.
• Połączenie nie przesyła użytecznego SNI.
• Rzeczywisty host TLS różni się od adresu URL widocznego w przeglądarce.
• Po zmianie nadal używano istniejącej sesji TLS.

URL Group działa zbyt szeroko

• Wprowadzono domenę główną zamiast rzeczywiście potrzebnych hostów.
• Wpis obejmuje dodatkowe subdomeny w dopasowaniu TLS.
• Grupa jest używana przez wiele policies lub reguł TLS.
• Reguła Allow jest umieszczona zbyt wysoko albo dotyczy zbyt wielu użytkowników.
• Local TLS exclusion list ma szersze działanie niż własna reguła ograniczona według źródła.

W takiej sytuacji nie należy dodawać kolejnej domeny. Najpierw trzeba sprawdzić wszystkie zastosowania grupy, rzeczywistą kolejność reguł i test negatywny.

Bezpieczne zarządzanie zmianami i rollbackiem

Przed każdą zmianą produkcyjnej URL Group należy zapisać:

• poprzednią listę domen
• odwołujące się Web Policies i SSL/TLS inspection rules
• właściciela i uzasadnienie biznesowe
• użytkowników, źródła i usługi, których dotyczy zmiana
• pozytywne i negatywne przypadki testowe
• datę przeglądu lub wygaśnięcia

Wspólnej grupy nie rozszerza się po cichu z powodu pojedynczego incydentu. Jeśli webowa allowlist i wykluczenie TLS mają różnych właścicieli lub cykle życia, oddzielne URL Groups są bardziej przejrzyste, nawet gdy część domen jest identyczna.

Podczas rollbacku najpierw przywraca się stan reguły lub policy korzystającej z grupy albo usuwa tylko nowo dodaną domenę. Całą grupę usuwa się dopiero wtedy, gdy żadna inna policy ani reguła już od niej nie zależy. Następnie ponownie sprawdza się nowe połączenia z hostami pozytywnym i negatywnym oraz logi.

Operacyjna lista kontrolna

• Potwierdzono, że URL Group jest właściwym narzędziem.
• Dodano wyłącznie poprawne domeny, bez protokołów, ścieżek, wildcard ani regex.
• Świadomie ograniczono działanie domeny głównej i subdomen.
• Uwzględniono logikę OR między wieloma domenami.
• Udokumentowano nazwę grupy, właściciela, cel i datę przeglądu.
• Jednoznacznie określono Web Policy lub SSL/TLS inspection rule korzystającą z grupy.
• Sprawdzono stan, pozycję, zakres źródłowy i logowanie reguły.
• Wybrano Web Policy w odpowiedniej regule firewalla.
• Dla wykluczenia TLS potwierdzono SNI i regułę Don't decrypt.
• Przeprowadzono testy pozytywne i negatywne z nowymi połączeniami.
• Zapisano odwołania i poprzedni stan na potrzeby rollbacku.

Częste pytania