Konfigurowanie ochrony sieci Web Sophos Firewall za pomocą zasad sieci Web

Ochrona sieci Web Sophos Firewall kontroluje, które strony internetowe, kategorie i treści internetowe mogą być dostępne dla użytkowników. W praktyce ochrona sieci Web nie jest po prostu jednym zaznaczeniem. Zasada sieci Web musi być fachowo zaplanowana, aktywowana w odpowiedniej regule zapory, a następnie przetestowana z rzeczywistym ruchem.

Wiele błędów wynika z tego, że zasada sieci Web istnieje, ale nie jest stosowana do żadnej aktywnej reguły zapory. Inne problemy związane są z HTTPS, inspekcją TLS, QUIC, rozpoznawaniem użytkowników, kolejnością reguł lub zbyt ogólnymi wyjątkami. Dlatego sensowny przebieg to: planowanie zasad, budowanie reguły, aktywacja, testowanie i monitorowanie w działaniu.

Który artykuł o ochronie sieci Web jest odpowiedni?

Ochrona sieci Web pokrywa się z regułami zapory, inspekcją TLS, QUIC, raportowaniem i wyjątkami. W zależności od zadania lepiej pasuje bardziej szczegółowy artykuł:

• Podstawowe konfigurowanie ochrony sieci Web i zasad sieci Web: Ten artykuł.
• Zrozumienie Single lub Dual Engine, błędów skanowania, limitów rozmiaru i rzeczywistego testu malware: Konfigurowanie i testowanie skanowania malware w Sophos Firewall.
• Analiza kategorii sieci Web, grup URL i alertów natychmiastowych: Wykorzystanie kategorii sieci Web Sophos Firewall i alertów natychmiastowych.
• Deszyfrowanie i sprawdzanie ruchu HTTPS: Wprowadzenie inspekcji TLS Sophos Firewall.
• Dystrybucja certyfikatu CA dla zarządzanych klientów: Dystrybucja certyfikatu CA Sophos Firewall dla inspekcji TLS.
• Klasyfikacja QUIC i HTTP/3 przy problemach z filtrowaniem sieci Web: Blokowanie protokołu QUIC i HTTP/3 w Sophos Firewall.
• Ustalanie, która reguła zapory i zasada faktycznie obowiązuje: Testowanie reguł Sophos Firewall za pomocą Log Viewer, Policy tester i Packet Capture.
• Dłuższa analiza zdarzeń sieci Web i bezpieczeństwa: Central Firewall Reporting lub Wysyłanie Syslog do SIEM.

W ten sposób analiza pozostaje czysta: najpierw musi być jasne, czy reguła zapory pasuje. Następnie sprawdza się zasadę sieci Web, kategorię, kontekst użytkownika, QUIC, inspekcję TLS i logowanie.

Co kontroluje ochrona sieci Web

Ochrona sieci Web składa się z kilku elementów. Nie każdy element musi być używany w każdym środowisku, ale zależności powinny być jasne.

• Zasada sieci Web: Zasady dotyczące dozwolonych, ostrzeganych, blokowanych lub opartych na kwotach dostępów do sieci Web.
• Kategorie sieci Web: Kategorie Sophos i własne kategorie dla stron internetowych.
• Grupy URL: Własne listy domen do precyzyjnych reguł zezwalania lub blokowania.
• Typy plików: Kontrola określonych typów pobierania lub plików.
• Filtry treści: Terminy lub wzorce do kontroli treści.
• Wyjątki: Precyzyjne wyjątki od zachowań sieci Web, TLS lub skanowania.
• Search engine enforcement: SafeSearch i ograniczenia YouTube.
• Advanced settings: ograniczenia domen logowania Google Apps i Microsoft Entra ID Tenant Restrictions.
• Logowanie i raportowanie: Śledzenie w Log Viewer, raportowanie, Central lub SIEM.

Ochrona sieci Web nie zastępuje solidnej bazy reguł zapory. Reguła zapory decyduje najpierw, jaki ruch z której strefy do której strefy docelowej jest dozwolony. Zasada sieci Web uzupełnia tę regułę o kontrolę sieci Web. Podstawy dotyczące kolejności reguł, źródła, celu, usług i profili bezpieczeństwa znajdują się w Zrozumienie i budowanie reguł Sophos Firewall.

Wymagania wstępne

Przed wdrożeniem należy wyjaśnić następujące kwestie:

• Ochrona sieci Web jest licencjonowana lub zawarta w używanym pakiecie.
• Sieci klientów objęte ochroną mają własne reguły zapory.
• Logowanie jest aktywne w odpowiednich regułach.
• DNS i czas na zaporze działają poprawnie.
• Rozpoznawanie użytkowników jest wyjaśnione, jeśli zasady mają obowiązywać dla użytkowników lub grup.
• Inspekcja TLS jest planowana, jeśli treści HTTPS mają być dokładniej sprawdzane.
• QUIC/HTTP/3 jest świadomie dozwolony lub blokowany.
• Istnieje grupa pilotażowa i ścieżka powrotna dla krytycznych stron biznesowych.

Szczególnie ważne jest rozdzielenie według grup docelowych. Zasada sieci Web dla zwykłych klientów, serwerów, gości, użytkowników VPN i systemów zarządzania nie powinna być taka sama. Serwery często potrzebują mniej kontroli przeglądania, ale bardziej rygorystycznych list celów i aktualizacji. Goście często potrzebują kategorii i ograniczeń przepustowości, ale nie dostępu do zasobów wewnętrznych.

Jeśli zasady sieci Web mają reagować na użytkowników lub grupy, rozpoznawanie użytkowników musi działać. AD SSO, Captive Portal, STAS, SATC lub inne metody nie powinny być odkrywane dopiero podczas wdrażania zasady sieci Web. W Log Viewer musi być widoczne, czy żądanie oceniono jako znanego użytkownika, grupę albo jako Anybody lub nieznanego użytkownika.

Kryteria użytkownika w pasującej regule zapory mają pierwszeństwo przed Users w zasadzie WWW; zasada może zawęzić zakres, ale nie doda użytkownika wykluczonego przez regułę.

Minimalna ścieżka skutecznej zasady

Utwórz zasadę w Web > Policies i włącz w niej co najmniej jedną precyzyjną decyzję Allow/Block.

Następnie edytuj rzeczywistą regułę w Rules and policies > Firewall rules, ustawiając Action: Accept, właściwe Source Zone i Source Network, Destination Zone i Destination Network oraz wymagane Services. Włącz Log firewall traffic i przypisz zasadę w Web filtering. Sprawdź jedynie, czy istniejący NAT odpowiada dotychczasowej ścieżce internetowej; nie twórz nowego zachowania NAT wyłącznie dla tej zasady. Przed zmianą zapisz Rule ID oraz wyniki tych samych świadomie dozwolonych i blokowanych żądań, a po zmianie powtórz je w rzeczywistym kontekście źródła i użytkownika. Odbierz zmianę dopiero, gdy Log Viewer pokaże oczekiwane Rule ID, zasadę oraz rzeczywiste wyniki Allow i Block.

Planowanie zasady sieci Web

Dobra zasada sieci Web nie zaczyna się w interfejsie, ale od kilku decyzji fachowych.

Definiowanie grup docelowych

Najpierw określa się, dla kogo zasada obowiązuje:

• Standardowi klienci w LAN
• Zarządzane notebooki przez VPN
• Sieć WLAN dla gości
• Sale szkoleniowe lub środowiska szkolne
• Serwery z wychodzącym dostępem HTTP/HTTPS
• Uprzywilejowane stanowiska administracyjne

Jeśli ta sama reguła zapory obejmuje kilka bardzo różnych grup, ochrona sieci Web staje się trudna do zrozumienia. Lepsze są oddzielne reguły i zasady, na przykład LAN_USERS_WEB, GUEST_WEB lub SERVER_UPDATES_WEB.

Ustalanie kategorii i grup URL

Kategoria highly objectionable criminal activity jest zawsze blokowana. Ani reguły zasad, ani wyjątki nie mogą zezwolić na tę kategorię; SFOS ukrywa też domenę w logach i raportach.

Kategorie sieci Web Sophos są dobre do szerokiej kontroli: złośliwe oprogramowanie, phishing, treści dla dorosłych, anonimizatory, streaming, media społecznościowe lub gry. Grupy URL są lepsze, gdy pojedyncze domeny mają być precyzyjnie dozwolone lub blokowane.

Typowe zastosowanie:

• Blokowanie znanych kategorii ryzyka: Kategoria sieci Web.
• Zezwalanie na określone domeny SaaS: Grupa URL.
• Obsługa pojedynczej błędnie sklasyfikowanej domeny: Grupa URL lub własna kategoria.
• Ograniczenie czasowe streamingu: Zasada sieci Web z harmonogramem lub kwotą.
• Strona ostrzegawcza zamiast twardego blokowania: Zasada sieci Web z akcją ostrzegawczą.

Grupy URL nie powinny stać się niesortowaną listą zbiorczą. Jeśli wiele domen jest wpisanych, lista potrzebuje właściciela, celu i daty przeglądu. Dla bardzo dużych lub dynamicznych list często bardziej sensowne są Sophos Firewall Threat Feeds lub inne elementy architektury.

Artykuł Tworzenie i bezpieczne używanie URL Groups wyjaśnia zależność między poprawnymi domenami, logiką OR, użyciem w Web Policy i wykluczeniami TLS.

Przy czystych dopasowaniach domenowych grupy URL są zwykle lepsze niż własne Web Categories. Sophos wskazuje, że grupy URL są wydajniejsze i mogą powodować mniej fałszywych trafień. Własne kategorie są przydatne, gdy domena ma dodatkowo występować w indywidualnej logice polityki obok standardowej kategorii Sophos.

Słów kluczowych we własnych kategoriach należy używać bardzo ostrożnie. Keywords są sprawdzane względem całego URL, łącznie ze ścieżką i zapytaniem. Zezwolenie oparte na słowie kluczowym może więc zadziałać niezamierzenie, jeśli słowo pojawi się w parametrze zapytania na innej domenie. Dla decyzji Allow zwykle czystsze są konkretne domeny lub grupy URL; reguły keyword pasują raczej do wąskich przypadków blokowania.

Ostrożne ustawianie reguł zezwalania

Reguły zezwalania w zasadach sieci Web powinny być wąskie. Reguła zezwalania wysoko w hierarchii może unieważnić późniejsze reguły blokowania, ponieważ zasady sieci Web Sophos są oceniane od góry do dołu. Jest to szczególnie istotne, gdy grupa URL, reguła typu pliku lub wyjątek kategorii znajduje się powyżej innych reguł.

Praktyczne podejście:

Zezwolenie biznesowe umieszczone powyżej krytycznych reguł blokowania obowiązuje tylko w swoim ściśle określonym zakresie. Jeśli kategoria ryzyka ma pozostać blokowana bez wyjątków, jej reguła blokowania musi znajdować się powyżej wszystkich pasujących reguł Allow. Kolejność należy sprawdzić na dozwolonym celu biznesowym i zablokowanym celu w zakresie wyjątku; zezwolenie na domenę nie może przypadkowo zezwalać na każdy typ pliku ani każdą treść z tego celu.

• Reguły ostrzegawcze lub kwotowe dla szarych obszarów.
• Ogólnie dozwolony ruch sieci Web dopiero na końcu.

Tworzenie zasady sieci Web

Zasada sieci Web jest tworzona w następującym menu:

Web > Policies

Podstawowy przebieg:

1. Wybierz Add policy.
2. Nadaj nazwę opisową, na przykład LAN_USERS_STANDARD_WEB.
3. Dodaj reguły.
4. Sprawdź search engine enforcement, na przykład SafeSearch lub YouTube restrictions.
5. Ustaw policy quota status, jeśli używane są akcje Quota.
6. Sprawdź Advanced settings, zwłaszcza logging, reporting, duże pobrania, Google Apps oraz Microsoft Entra ID Tenant Restrictions.
7. Zapisz zasadę.

Regułę w ramach zasady sieci Web tworzy się przez Add rule. Zapora najpierw tworzy wyłączoną regułę domyślną, która blokuje HTTP dla Anybody. Następnie pola trzeba świadomie dostosować:

1. Otwórz Users i ustaw świadomie Anybody, konkretnych użytkowników lub grupy.
2. Otwórz Activities i wybierz All web traffic, User activities, Categories, URL Groups lub File types.
3. Dla treści wybierz oddzielną kartę Content filters, filtr, włącz and with content i pozostaw HTTPS jako Use action.
4. Ustaw Action dla HTTP: Allow, Warn, Block lub Quota.
5. Sprawdź akcję HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS lub Quota HTTPS.
6. Ustaw Constraints, jeśli reguła ma obowiązywać tylko według harmonogramu.
7. Sprawdź pozycję reguły w ramach zasady.
8. Włącz status reguły.
9. Zapisz zasadę.

W Users > Add new item należy odznaczyć Anybody, jeśli reguła ma dotyczyć tylko określonych użytkowników lub grup. W Activities > Add new item należy odznaczyć All web traffic przed wybraniem poszczególnych Activities. Każdy wybór należy zatwierdzić przyciskiem Apply selected items. W przeciwnym razie reguła pozostanie niepotrzebnie szeroka mimo dodania pojedynczych obiektów. Akcje HTTP noszą nazwy Allow HTTP, Warn HTTP, Block HTTP i Quota HTTP; Use action stosuje tę samą decyzję do HTTPS. W przypadku Content filters to powiązanie jest stałe i nie można go zastąpić inną akcją HTTPS.

Poprawne importowanie list filtrów treści

Content filters są zarządzane w Web > Content filters, a następnie wybierane w Activities w regule zasady sieci Web. W przypadku większych list terminów Sophos obsługuje prosty plik .txt. Plik może zawierać maksymalnie 2,000 wierszy, a każdy wpis może mieć najwyżej 80 znaków, łącznie ze spacjami i znakami interpunkcyjnymi.

Plik importu zawiera jeden termin w każdym wierszu, a każdy wiersz jest oceniany jako exact match. Nie należy umieszczać nagłówków, komentarzy, metadanych ani dodatkowych kolumn; użyj kodowania UTF-8.

Bezpieczny przebieg:

1. Oczyść terminy w edytorze tekstu i umieść dokładnie jeden wpis w każdym wierszu.
2. Zapisz plik jako .txt z kodowaniem UTF-8.
3. Zaimportuj listę w Web > Content filters i nadaj jej opisową nazwę.
4. W Activities otwórz Content filters, wybierz filtr, włącz and with content i zachowaj Use action.
5. Za pomocą klienta pilotażowego przetestuj jeden dozwolony termin i jeden celowo pasujący termin, a następnie sprawdź akcję w Log Viewer.

Jeśli import zostanie odrzucony lub poszczególne terminy nie zadziałają, najpierw sprawdź liczbę wierszy, długość znaków, kodowanie i niewidoczne znaki dodatkowe. Szeroka reguła Allow nad regułą Content filter nie może omijać listy.

Aby zaimportować filtr, należy wybrać Add content filter, podać nazwę, za pomocą Choose file wybrać na przykład blocked.txt i kliknąć Apply. Następnie w regule zasady sieci Web należy wyraźnie sprawdzić Block HTTP oraz Use action dla HTTPS, zatwierdzić wybór filtra przyciskiem Apply selected items, włączyć Status i zapisać zasadę. Sam import nie aktywuje blokady. Do pilotażu lepiej nadaje się osobna, przypisana zasada niż niekontrolowana zmiana współdzielonej Default Policy.

Tworzenie własnych typów plików internetowych

Sophos Firewall rozpoznaje File types na podstawie rozszerzenia pliku lub nagłówka MIME. Wbudowanych typów nie można edytować. Własny typ tworzy się w Web > File types > Add z odpowiedniego szablonu, dodając wymagane rozszerzenia bez początkowej kropki albo nagłówki MIME. Ten sam obiekt można następnie stosować w zasadach ochrony stron internetowych i poczty elektronicznej.

W oknie Add należy podać nazwę. Pole Template jest opcjonalne i wstawia typowe rozszerzenia oraz nagłówki MIME danej kategorii; wartości dla własnego typu można uzupełnić. Następnie trzeba zapisać obiekt przyciskiem Save. Rozszerzenia wpisuje się bez początkowej kropki: pdf jest poprawne, a .pdf nie. Typy wbudowane służą jako wzorce i nie można ich edytować; zmiany wymagają utworzenia własnego typu.

SFOS udostępnia wbudowane kategorie All executable files, 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. Widok szczegółów w Web > File types jest operacyjnym źródłem aktualnie zapisanych rozszerzeń i nagłówków MIME. Przykładowo Compressed files obejmuje między innymi 7z, gz, rar, tar.gz i zip, a Document files między innymi docx, xlsx, pptx, odt, rtf i pdf. Przed zezwoleniem na kategorię należy więc otworzyć konkretny typ wbudowany we własnej wersji SFOS i porównać go z rzeczywistym zastosowaniem, zamiast polegać wyłącznie na nazwie kategorii.

Nowy typ pliku sam w sobie nie wywołuje żadnego działania. Trzeba go wybrać w Activities > File types w odpowiedniej regule zasady sieci Web. Następnie należy sprawdzić akcję, stan i kolejność reguły oraz upewnić się, że zasada sieci Web nadal jest przypisana do reguły zapory, która rzeczywiście obsługuje ruch.

Walidacja obejmuje reprezentatywne pobranie oraz celowo podobny plik, który nie powinien zostać dopasowany. W Log Viewer sprawdza się zasadę sieci Web i akcję. Dopasowanie na podstawie rozszerzenia lub nagłówka MIME jest klasyfikacją zasad, a nie dowodem obecności malware ani wykonania analizy Zero-Day. W przypadku HTTPS wymagana widoczność zależy również od ścieżki TLS Inspection. Jeśli typ nie jest dopasowywany, należy najpierw porównać stan i kolejność reguły, faktycznie wybrany File Type, odpowiedź Content-Type serwera, widoczne rozszerzenie pliku oraz stan TLS Inspection. Błędny lub ogólny typ MIME zwracany przez serwer może sprawić, że wynik testu będzie inny, niż sugeruje nazwa pliku.

Zestawienie wbudowanych typów plików

Poniższe zestawienie przyporządkowuje udokumentowane rozszerzenia i nagłówki MIME do wbudowanych kategorii. Opisuje klasyfikację, a nie plik dozwolony lub bezpieczny. Przed zmianami należy porównać te wartości z własną instalacją. All executable files obejmuje dzięki dodatkowym nagłówkom MIME również pliki wykonywalne dla systemów Mac/Linux; Executable files jest ukierunkowane na Windows. Dynamic files generują dynamiczne treści internetowe, a Encoded files obejmują między innymi treści zaszyfrowane lub zakodowane binarnie. Kategorie mogą się nakładać: na przykład mdf występuje przy bazach danych i Disk Images, tar przy dokumentach, a tar.gz przy plikach skompresowanych. W szczególności application/octet-stream w Backup files jest ogólną wartością MIME, a nie wiarygodnym potwierdzeniem, że plik jest kopią zapasową.

All executable files

• Rozszerzenia: exe, cmd, bat, com.
• Nagłówki MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Rozszerzenia: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, 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, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

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/vnd.ms-officetheme.

Database files

• Rozszerzenia: accdb, db, mdsn, 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: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• Nagłówki MIME: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

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, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, 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/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, 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/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

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

Encoded files

• Rozszerzenia: bin, enc, hex, hqx, mim, mime, uue.
• Nagłówki MIME: application/mac-binary, application/macbinary, 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/x-dosexec.

Image files

• Rozszerzenia: bmp, gif, jpeg, jpg, pcx, png.
• Nagłówki MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

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

Plugin files

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

System files

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

Video files

• Rozszerzenia: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• Nagłówki MIME: 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, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

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

Przejrzyste łączenie User Activities

W Web > User activities > Add obiekt User activity łączy Web Categories, File types i URL Groups w aktywność wielokrotnego użytku. Elementy te są oceniane za pomocą OR; wystarczy jedno dopasowanie. Nazwa nie oznacza więc zalogowanego użytkownika, lecz zestaw kryteriów internetowych.

Następnie User Activity wybiera się w Activities w regule zasady sieci Web. Jest to przydatne, gdy ta sama kombinacja występuje w kilku zasadach. Podczas walidacji należy sprawdzić co najmniej jedno dopasowanie dla każdego zawartego typu obiektu oraz jeden podobny przypadek, który nie powinien pasować.

W oknie dialogowym należy nadać opisową nazwę, na przykład RISK_WEB_CONTENT, za pomocą Add new item wybrać wymagane kategorie, typy plików lub URL Groups i zapisać obiekt przyciskiem Save. Show: All pozwala w razie potrzeby ograniczyć wyświetlane typy obiektów. Przykładowo aktywność może łączyć kategorię Spyware/Malware z własną listą zablokowanych domen testowych: już spełnienie jednego z tych kryteriów uruchamia akcję blokowania w regule zasady. Do testów należy używać nieszkodliwych celów pod własną kontrolą, a nie otwierać rzeczywistej strony ze złośliwym oprogramowaniem.

Sprawdzanie kolejności reguł i migrowanych zasad

Reguły zasad sieci Web są oceniane od góry do dołu. Jeśli na przykład reguła Allow dla typu pliku .mdb znajduje się nad regułą blokowania kategorii, pobieranie plików .mdb z tej kategorii pozostaje dozwolone. W trybie DPI początkowe połączenie z kategorią może zostać dopuszczone, dopóki typ pliku nie zostanie rozpoznany; jeśli plik następnie nie pasuje, zapora odrzuca połączenie bez wyświetlania strony blokady. Jeżeli kategoria ma być zawsze blokowana, jej reguła musi znajdować się nad regułą Allow typu pliku.

Dla migrowanych starych zasad obowiązuje również twardy limit 128 reguł na zasadę. Jeśli źródło zawiera więcej reguł, SFOS używa tylko pierwszych 128. Sąsiadujące reguły dla User Activities, Categories, URL Groups, File types i Dynamic Categories należy więc świadomie połączyć w kombinowane Activities przed migracją lub po niej. Liczba i kolejność reguł oraz rzeczywiste testy Allow i Block są częścią walidacji migracji.

Cykliczne przedziały czasu tworzy się jako osobny harmonogram. Przebieg i różnicę względem reguły zapory sterowanej czasem opisano w artykule Konfiguracja harmonogramów reguł i zasad na Sophos Firewall.

Sama zasada sieci Web jeszcze nie działa. Zasada musi być następnie użyta w regule zapory. To jeden z najczęstszych błędów konfiguracyjnych.

Łączyć należy wyłącznie sąsiadujące reguły z takim samym przypisaniem użytkowników, akcjami HTTP/HTTPS i identycznymi warunkami czasowymi. Nie wolno utracić różnic dotyczących Content filters, Constraints ani kolejności. Przed połączeniem należy wykonać kopię starej zasady lub ją udokumentować oraz zapisać reprezentatywne przypadki dopasowania i braku dopasowania dla każdej Activity. Po połączeniu należy ponownie sprawdzić te decyzje; sama mniejsza liczba reguł nie dowodzi równoważnego poziomu ochrony.

Świadome konfigurowanie Advanced settings

Enable logging and reporting uwzględnia zasadę w logach i raportach; dodatkowo w pasującej regule zapory nadal wymagane jest Log firewall traffic. Prevent downloading of large files blokuje pobieranie plików przekraczających podany rozmiar. Próg należy dobrać do rzeczywiście potrzebnych pobrań biznesowych i sprawdzić na nieszkodliwych plikach poniżej oraz powyżej tej wartości; ta blokada pobierania nie jest tym samym co limit rozmiaru skanowania złośliwego oprogramowania.

Add X-Forwarded-For header to outgoing HTTP requests przekazuje do celu adres IP źródła pierwotnego żądania HTTP. Nie jest to opcja wymagana do filtrowania sieci Web. Należy ją włączać tylko w razie uzasadnionej potrzeby, ponieważ serwer docelowy otrzymuje w ten sposób dodatkowe informacje o kliencie; wcześniej należy ocenić przekazywanie adresów wewnętrznych i wymagania dotyczące ochrony danych. Na potrzeby pilotażu należy udokumentować dotychczasowe wartości, a w razie niepożądanych skutków wycofać dokładnie te zmiany.

Aktywacja zasady sieci Web w regule zapory

Reguła zapory znajduje się pod:

Rules and policies > Firewall rules

Dla normalnego ruchu internetowego klientów zazwyczaj odpowiedzialna jest reguła z LAN lub strefy klienta do WAN. Tam w sekcji Web filtering wybiera się odpowiednią zasadę sieci Web.

Punkty kontrolne w regule zapory:

• Strefa źródłowa i sieci źródłowe pasują do sieci klienta.
• Strefa docelowa to zazwyczaj WAN.
• Usługi zawierają HTTP/HTTPS lub pożądane usługi sieci Web.
• Log firewall traffic jest aktywne.
• W sekcji Web filtering ustawiona jest właściwa zasada sieci Web.
• Scan HTTP and decrypted HTTPS jest aktywne, jeśli ma działać skanowanie malware lub treści web.
• Use Zero-day protection ma sens tylko wtedy, gdy pliki są skanowane przez HTTP lub odszyfrowany HTTPS.
• Block QUIC protocol jest świadomie ustawione.
• Na przezroczystej ścieżce reguły zapory opcja Use web proxy instead of DPI engine jest włączona dla SafeSearch, YouTube Restrictions i ograniczeń Google Apps; dla innych funkcji oraz Direct Proxy tryb wybiera się świadomie według potrzeb.
• Inspekcja TLS jest planowana oddzielnie i nie mylona z zasadą sieci Web.

Sophos Firewall domyślnie ustawia Block QUIC protocol, gdy w regule wybrano zasadę sieci Web albo włączono Scan HTTP and decrypted HTTPS. Często ma to sens, ponieważ QUIC nie może być skanowany jak klasyczny ruch HTTPS. Mimo to opcję trzeba przetestować świadomie: przeglądarki, usługi Google, narzędzia współpracy i pojedyncze aplikacje SaaS mogą zmienić zachowanie po zablokowaniu QUIC.

Jeśli w tej samej regule zapory używany jest również Application Control, istnieje ważne nakładanie się funkcji: niektóre Micro Apps, na przykład przesyłanie lub pobieranie w Dropbox albo Gmail, są rozpoznawane przez szczegóły URL. W środowiskach DPI wymaga to odpowiedniej reguły SSL/TLS Inspection z deszyfrowaniem. Application Control może wtedy oceniać takie Micro Apps nawet wtedy, gdy sama zasada sieci Web nie jest głównym punktem decyzji.

Jeśli bardziej ogólna reguła znajduje się powyżej pożądanej reguły sieci Web, ruch nie osiąga zasady sieci Web. W takich przypadkach pomocne jest Testowanie reguł Sophos Firewall za pomocą Log Viewer i Packet Capture.

Klasyfikacja HTTPS, inspekcji TLS i QUIC

Duża część ruchu sieci Web to HTTPS. Bez inspekcji TLS zapora widzi mniej treści. Kategorie, SNI, certyfikaty, adresy IP docelowe, informacje o domenach i metadane pomagają, ale nie zastępują pełnej inspekcji treści.

DPI czy Web Proxy?

Przy ochronie sieci Web trzeba wcześnie zdecydować, czy dotknięta reguła zapory używa DPI Engine czy Web Proxy. Ta decyzja wpływa na to, które funkcje działają i które logi są później istotne.

• Tryb DPI: nowoczesny standard dla wielu reguł internetowych klientów. Inspekcja TLS działa przez reguły inspekcji SSL/TLS, kwoty nie są obsługiwane.
• Tryb Web Proxy: Środowiska z zachowaniem proxy lub kwotą polityki. Zachowanie proxy, kompatybilność przeglądarek/klientów i logi proxy należy świadomie sprawdzić.

W wielu instalacjach tryb DPI jest lepszym punktem wyjścia. Jeśli jednak potrzebne są limity czasowe przez Quota, sama reguła DPI nie wystarczy. Wtedy tryb Web Proxy musi być świadomie zaplanowany i przetestowany. Ta decyzja powinna zapaść przed wdrożeniem, ponieważ późniejsza zmiana może generować inne problemy, logi i doświadczenia użytkowników.

W przezroczystej regule zapory Transparent Web Proxy obsługuje tylko klasyczne porty 80 i 443. Na innych portach DPI Engine może sprawdzać ruch HTTP i SSL/TLS, jeśli pasują zarówno reguła zapory, jak i reguły SSL/TLS Inspection. Direct Proxy jest natomiast osobną, jawną ścieżką wybieraną przez klienta i nie musi wymagać opcji Use web proxy instead of DPI engine. Dlatego przy każdym teście należy zapisać, czy klient używa ścieżki przezroczystej, czy jawnej konfiguracji proxy.

Pełny wybór funkcji, migrację pilotażową i testy właściwe dla danego trybu opisano w artykule Prawidłowe porównanie DPI Engine i Web Proxy.

Artykuł Konfiguracja Direct Web Proxy z plikiem PAC wyjaśnia, jak połączyć listener, plik PAC, Device Access i działającą regułę proxy.

Klienci tylko IPv6 uzyskujący dostęp do celów WWW tylko IPv4 korzystają z osobnej ścieżki dwóch reguł. NAT64 z Direct Web Proxy oddziela Web Policy w regule IPv6 od Application Control i IPS w egressie IPv4.

Jeśli Sophos Firewall ma przekazywać Web Requests do parent proxy, konfiguracja upstream proxy w WAN lub LAN/DMZ prowadzi przez właściwą ścieżkę reguł i NAT dla każdej topologii.

Gdy wielu użytkowników RDS współdzieli ten sam adres IP serwera, Per-Connection AD SSO dla hostów wielu użytkowników może rozróżniać poszczególne połączenia HTTP i HTTPS przez proxy. Metoda nie obejmuje ruchu spoza proxy, dlatego trzeba ją świadomie rozgraniczyć względem SATC.

Inspekcja TLS

Jeśli pobieranie, skanowanie złośliwego oprogramowania, określone kategorie sieci Web lub kontrola treści mają być niezawodnie sprawdzane, inspekcja TLS musi być zaplanowana. Wymaga to zaufanego certyfikatu CA na klientach, odpowiednich reguł TLS, wyjątków i starannie zaplanowanego pilotażu.

Wdrożenie opisano w Stopniowe wdrażanie inspekcji TLS na Sophos Firewall. Do dystrybucji i walidacji certyfikatu CA pasuje Instalacja certyfikatu CA Sophos Firewall dla skanowania HTTPS.

QUIC i HTTP/3

Nowoczesne przeglądarki często używają QUIC lub HTTP/3 przez UDP 443. Może to zakłócać oczekiwania dotyczące filtrowania sieci Web, inspekcji TLS i skanowania, jeśli chce się faktycznie sprawdzać klasyczny ruch HTTPS przez TCP.

W wielu środowiskach korporacyjnych warto blokować QUIC w regułach internetowych klientów, aby przeglądarki wracały do HTTPS przez TCP. Szczegóły znajdują się w Blokowanie protokołu QUIC i HTTP/3 w Sophos Firewall.

SafeSearch, YouTube i ograniczenia Tenant

SafeSearch i YouTube znajdują się w Search engine enforcement, a Google Apps i Entra w Advanced settings.

Typowe opcje:

• Enforce SafeSearch dla Google, Yahoo i Bing.
• Enforce YouTube restrictions dla ograniczonych treści YouTube.
• Restrict login domains for Google Apps dla dozwolonych domen Google.
• Apply Microsoft Entra ID tenant restrictions dla kontroli tenantów w chmurze Microsoft.

Dokumentacja referencyjna interfejsu XML API dla SFOS 22/23 opisuje EnforceSafeSearch jako funkcję mającą zastosowanie tylko wtedy, gdy kategorie Adult Content, Nudity i Porn są zabronione w Web Policy. Sprawdź te decyzje w zasadach faktycznie przypisanych do ruchu; samo włączenie opcji oraz spełnienie wymagań dotyczących proxy i HTTPS scanning nie potwierdza spełnienia tego udokumentowanego warunku. To wymaganie API nie stanowi ogólnej gwarancji zachowania interfejsu lub działania wszystkich kompilacji. Jeśli pomoc zainstalowanej kompilacji podaje inne informacje, wyjaśnij różnicę, zanim zaczniesz polegać na SafeSearch.

Na przezroczystej ścieżce reguły zapory SafeSearch, YouTube Restrictions i Google Apps wymagają Use web proxy instead of DPI engine; jawny Direct Proxy może realizować te funkcje bez tej opcji reguły zapory. Bing i Yahoo przez HTTPS wymagają dodatkowo HTTPS scanning. Entra Tenant Restrictions należy traktować osobno, testować przy użyciu rzeczywistych logowań Microsoft i zachować odrębne zarządzanie tożsamością oraz aplikacjami chmurowymi w Microsoft 365 lub Google Workspace.

W Bing i Yahoo SafeSearch można wymusić na połączeniach HTTPS tylko wtedy, gdy HTTPS scanning jest aktywny w danej regule zapory. Ograniczenia logowania Google Apps dotyczą tylko domen hostowanych przez Google. Microsoft Entra ID Tenant Restrictions wymagają poprawnych wartości tenantów i powinny być testowane z rzeczywistymi logowaniami do chmury Microsoft, nie tylko z przykładowym URL.

W sekcji Apply Microsoft Entra ID tenant restrictions pole Restrict-Access-To-Tenants zawiera dozwolone tenanty jako listę nazw domen lub identyfikatorów domen oddzielonych przecinkami, o łącznej długości maksymalnie 256 znaków. Restrict-Access-Context zawiera identyfikator domeny tenanta, który określa ograniczenie, o długości maksymalnie 50 znaków. Wartości te należy pobrać z własnej administracji tenantami, a nie z cudzej przykładowej konfiguracji. Najpierw należy zachować istniejące wartości; następnie w pilotażu sprawdzić logowanie do dozwolonego i niedozwolonego tenanta, a w razie błędów przywrócić do poprzedniego stanu tylko zmienione wartości.

Kwoty i strony ostrzegawcze

Zasady sieci Web mogą nie tylko blokować lub zezwalać. Dzięki akcjom ostrzegawczym lub kwotowym można świadomie informować użytkowników lub zezwalać na dostęp czasowy.

Przykłady zastosowań:

• Użytkownicy mogą świadomie potwierdzić ostrzeżenie dla określonych szarych obszarów.
• Streaming lub zakupy są dozwolone tylko czasowo.
• Środowiska szkolne lub laboratoryjne zezwalają na określone kategorie tylko w określonych godzinach.

Ważne: kwoty polityki nie są obsługiwane w trybie DPI. Jeśli potrzebne są limity czasowe, należy użyć trybu Web Proxy. Decyzję tę trzeba podjąć na wczesnym etapie, ponieważ tryby DPI i Web Proxy mają różne właściwości i ograniczenia.

Allowed time quota ustawia się na poziomie zasady sieci Web i obowiązuje ona wszystkie reguły w tej zasadzie, które używają akcji Quota. Jeśli dwie kategorie wymagają różnych limitów czasu, oddzielne zasady sieci Web są czystsze niż jedna zasada z mieszanymi oczekiwaniami dotyczącymi kwot. Kwoty resetują się lokalnie o północy i nie można ustawić ich na zero.

Policy Quota nie dotyczy Content filters ani Dynamic Categories i nie działa w DPI. Zmiana nie zadziała przy nieważnej zasadzie, braku pozostałego czasu ani aktywnej sesji Quota. W takich przypadkach najpierw sprawdź stan zasady i sesję, zamiast wielokrotnie zmieniać limit.

Ta Policy Quota dotyczy kategorii WWW i nie jest opartym na użytkowniku limitem Surfing Quota. Tworzenie, przypisywanie i kontrola zużycia Surfing Quota i Network Traffic Quota odbywają się w osobnej procedurze.

Przy otwieraniu celu objętego akcją Quota najpierw pojawia się strona kwoty. Użytkownik wybiera czas nieprzekraczający dostępnego limitu i Proceed albo rezygnuje z dostępu za pomocą Return to previous page. Po zakończeniu wybranego okresu strona pojawia się ponownie; po wyczerpaniu limitu nie jest już oferowany pozostały czas. Policy Override może zamiast tego umożliwić dostęp tymczasowy; kwota wtedy nie obowiązuje. Dlatego uprawnienia do override nie wolno włączać jako dowolnej alternatywy dla wszystkich użytkowników.

Pasująca reguła inspekcji SSL/TLS z Action > Deny nadal blokuje dostęp; większa kwota ani reset nie rozwiązują tego konfliktu. Najpierw należy sprawdzić, czy blokada TLS jest zamierzona z punktu widzenia wymagań biznesowych. Tylko dla wyraźnie zatwierdzonego, wąsko ograniczonego przypadku należy zaplanować Web Exception pomijającą deszyfrowanie HTTPS. Usuwa ona również zależne od niego kontrole i może dopuścić nieprawidłowe certyfikaty serwera; nie należy stosować jej jako standardowej naprawy. Osobno należy sprawdzić dozwolony dostęp pilotażowy, utrzymanie blokady poza zakresem wyjątku oraz wycofanie zmiany przez wyłączenie pilotażowej Web Exception. Rzeczywisty zakres Web Exception muszą wyznaczać jej obsługiwane kryteria, na przykład źródłowy adres IP klienta pilotażowego wraz z potwierdzonym wzorcem nazwy hosta — nie grupa użytkownika objętego kwotą.

Sprawdzanie Policy Quota podczas pracy

W Web > Policy quota status SFOS pokazuje dla poszczególnych użytkowników czas pozostały w odpowiednich Web Policies w okresie 24 godzin. Wybranego użytkownika można tam zresetować przyciskiem Reset. Jest to celowa zmiana stanu, a nie przycisk diagnostyczny: najpierw dokumentuje się użytkownika, politykę, pozostały czas, powód i godzinę.

Ten reset dotyczy czasowej Policy Quota kategorii internetowej. Nie jest tym samym co Reset user accounting dla Surfing Quota lub Network Traffic Quota. Reset nie naprawia błędnej kolejności reguł ani braku identyfikacji użytkownika.

Dostosowanie stron ostrzeżeń i blokad

W Web > User notifications można skonfigurować własne obrazy oraz komunikaty blokady, override, quota i ostrzeżenia. Symbole zastępcze {category}, {user} i {url} wstawiają kategorię internetową, nazwę użytkownika i zablokowany URL. Preview sprawdza wygląd i tekst, ale nie potwierdza, że właściwa Web Policy i reguła firewalla pasują do produkcyjnego żądania.

Komunikat powinien krótko wyjaśniać, dlaczego dostęp został zablokowany lub objęty ostrzeżeniem i gdzie zgłosić uzasadnioną potrzebę biznesową. Nazwy użytkowników i adresy URL mogą zawierać wrażliwe informacje, dlatego strona nie powinna zawierać wewnętrznych tajemnic, haseł ani zbędnych danych kontaktowych.

W przypadku obrazów należy włączyć Use custom images i wybrać odpowiednie obrazy. W przypadku tekstów należy włączyć odpowiednio Use custom block message, Use custom override message, Use custom quota message lub Use custom warn message i wpisać tekst. Należy otworzyć odpowiedni link Preview, a następnie sprawdzić właściwy typ komunikatu za pomocą rzeczywistego żądania pilotażowego. W obrazach testowych nie wolno używać rzeczywistych danych klientów.

Bezpieczne ograniczenie Policy Overrides

Użytkownik, któremu administrator przyznał już uprawnienia, tworzy sesję w User Portal w następujący sposób:

1. Otworzyć My policy overrides > Add i nadać sesji opisową nazwę.
2. Zachować podany kod dostępu lub wygenerować nowy za pomocą Generate access code. Własny kod utworzony ręcznie jest dozwolony tylko po jawnym przyznaniu odpowiedniego uprawnienia.
3. Wybrać potrzebne dozwolone witryny i kategorie internetowe; nie można zezwolić na dostęp do celów wykluczonych przez administratora z overrides.
4. W Restricted to time periods wybrać istniejący harmonogram z listy. W tym miejscu wybiera się harmonogram, a nie wpisuje dowolny przedział czasu jako tekst.
5. Zapisać przyciskiem Apply. Następnie przy pasującym zablokowanym żądaniu wpisać kod dostępu w polu kodu na stronie blokady.

Za pomocą Status użytkownik włącza lub wyłącza tę sesję override. Nie jest to zarządzanie administracyjne przez View overrides: administrator może niezależnie włączyć, wyłączyć lub usunąć sesję utworzoną przez użytkownika. Bez przyznanych uprawnień ta procedura użytkownika nie jest dostępna; nadal obowiązuje ograniczenie do AD Main Group i indywidualnych użytkowników.

Policy Overrides to inne narzędzie niż kwoty. Po włączeniu Enable policy override uprawnieni użytkownicy mogą w User Portal utworzyć tymczasowy dostęp do normalnie blokowanych stron. Authorized users and groups ogranicza osoby uprawnione, a Blocked websites and categories definiuje cele, których nigdy nie można obejść. Allow manual access code entry włącza się tylko wtedy, gdy kody tworzone przez użytkowników pasują do procesu zatwierdzania.

W Web > General settings > Policy overrides najpierw udokumentować poprzedni stan i uprawnionych użytkowników. Uprawniony użytkownik określa w User Portal strony lub kategorie, ograniczony przedział czasu i kod dostępu dla override. Przy żądaniu pasującego zablokowanego celu strona blokady zawiera dodatkowe pole na ten kod. Gdy Allow manual access code entry jest włączone, wskazani użytkownicy mogą tworzyć własne kody; gdy opcja jest wyłączona, muszą korzystać z kodów generowanych. Nie należy mylić tej decyzji z wpisywaniem już ważnego kodu na stronie blokady.

View overrides pozwala wyświetlać, włączać, wyłączać i usuwać istniejące overrides. W ramach odbioru uprawniony użytkownik testowy powinien otworzyć pasujący cel w określonym przedziale czasu z ważnym kodem; bez kodu, poza tym przedziałem i dla celu, którego nigdy nie wolno udostępnić przez override, nadal musi działać normalna blokada. W Log Viewer porównać użytkownika, Rule ID, politykę WWW, akcję i czas. W HTTPS strona blokady musi dać się wyświetlić; samo przerwanie połączenia nie zapewnia pola na kod.

Przy wycofaniu wyłączyć pilotażowy override przez View overrides i nowym żądaniem sprawdzić pierwotną blokadę. Dopiero potem usunąć niepotrzebny override i przywrócić wyłącznie globalne wartości zmienione w pilotażu do udokumentowanego stanu poprzedniego. Nie usuwać zbiorczo istniejących overrides innych użytkowników.

Dla użytkowników AD funkcja My policy overrides uwzględnia tylko grupę główną i poszczególnych użytkowników, a nie inne członkostwa w grupach. Pasująca reguła inspekcji SSL/TLS z Action > Deny nadal ma pierwszeństwo. Jeśli zatwierdzony override musi w takiej sytuacji działać, planuje się wąsko ograniczoną Web Exception pomijającą deszyfrowanie HTTPS i osobno testuje przypadek negatywny; reguła TLS nie jest ogólnie osłabiana. Uprawnienie do override nie ogranicza Web Exception; zdefiniuj jej własny zakres obejmujący źródłowy adres IP oraz nazwę hosta lub kategorię i przeprowadź testy negatywne tego zakresu zgodnie z opisem poniżej.

Web Exceptions i wyjątki TLS

Pominięcie HTTPS decryption usuwa zależne kontrole i dopuszcza nieważne certyfikaty serwera; Malware and content scanning automatycznie pomija Zero-day protection. Konkretny wzorzec nazwy hosta może zostać dopasowany już w kontekście TLS, natomiast sama ścieżka URL jest widoczna tylko w HTTP lub w już odszyfrowanym HTTPS. URL Group nie jest kryterium Web Exception.

Web Exceptions są silnym narzędziem i dlatego są niebezpieczne jako szybka naprawa. Wyjątek pod Web > Exceptions może pomijać kontrole ochrony dla pasującego ruchu niezależnie od aktualnie obowiązującej zasady sieci Web. W zależności od wyboru pomijane są HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection lub Policy checks.

W środowiskach DPI obowiązuje ważne ograniczenie: Web Exceptions działają tylko wtedy, gdy ustawiona jest zasada sieci Web, aktywne jest Malware and content scanning albo aktywny jest ATP. SSL/TLS Exclusion Rules są natomiast właściwym miejscem, gdy chodzi wyłącznie o niewykonywanie deszyfrowania określonych połączeń TLS. Różnica operacyjna jest istotna:

• SSL/TLS Exclusion Rule: celowo wyłącza połączenia TLS z deszyfrowania, zwykle z powodu Certificate Pinning lub niezgodności.
• Web Exception: może pominąć kontrole zasady sieci Web, skanowanie malware, analizę Zero-Day lub walidację certyfikatów.
• URL Group in Web Policy: steruje Allow, Warn, Block lub Quota w normalnej logice zasady.

W przypadku Web Exceptions unikaj domen głównych i zbyt szerokich wzorców wyrażeń regularnych URL: sam wzorzec, taki jak example.com, może również pasować do tekstu w ścieżce lub zapytaniu innej domeny. Konkretne wzorce nazw hostów mogą być dopasowywane w kontekście TLS; ścieżki występujące wyłącznie w URL są widoczne tylko w HTTP lub już odszyfrowanym HTTPS. Obsługiwane kryteria Web Exception to wzorce wyrażeń regularnych URL, kategorie sieci Web, źródłowe adresy IP i docelowe adresy IP — nie użytkownicy, grupy użytkowników ani URL Groups.

Aby zezwolić na dostęp biznesowy wyłącznie określonej grupie użytkowników, użyj pasującej reguły zapory i Users w Web Policy; aby wykluczyć deszyfrowanie w trybie DPI w zakresie określonym przez tożsamość, użyj odpowiedniej reguły inspekcji SSL/TLS z Don’t decrypt i jawnie określonymi kryteriami użytkowników lub grup. Te kryteria tożsamości nie stają się kryteriami osobno stosowanej Web Exception i same w sobie nie ograniczają zakresu pomijania przez nią kontroli.

W pilotażu Web Exception połącz konkretne Source IP addresses klientów z potwierdzonym wzorcem nazwy hosta lub uzasadnioną kategorią sieci Web. Przetestuj zarówno niezatwierdzone źródło, jak i cel poza rzeczywistym zakresem dopasowania; adres IP nie jest tożsamością użytkownika. Nie wnioskuj z ogólnej logiki AND, że wyjątki oparte na źródłowych i docelowych adresach IP można łączyć w celu wykluczenia TLS: zachowane wytyczne dotyczące wykluczenia TLS mówią, że nie można ich łączyć, a dokładny zakres tego ograniczenia jest niejasny. Jeśli wymagane są oba ograniczenia IP, przerwij procedurę bez włączania ani rozszerzania wyjątku i uzyskaj wyjaśnienie dotyczące konkretnej kompilacji. Procedurę i ograniczenia dopasowania opisano w artykule Bezpieczne tworzenie i testowanie Web Exceptions.

Wyjątki łączą różne kryteria przez AND. W ramach jednego typu kryterium, na przykład kilku URL Patterns, obowiązuje natomiast OR. Jest to praktyczne, ale podatne na błędy: wyjątek z URL Pattern i Source IP działa tylko wtedy, gdy pasują oba elementy. Wyjątek z wieloma URL Patterns może natomiast działać znacznie szerzej niż oczekiwano.

Szczególną ostrożność należy zachować przy Policy checks. Jeśli Web Exception pomija Policy checks, może pośrednio osłabiać także inne decyzje reguł. W połączeniu z Synchronized Security Heartbeat taki wyjątek może sprawić, że żądania web nie będą blokowane zgodnie z oczekiwaniem, mimo że kontrole Heartbeat są ustawione w regule zapory.

Selektywna automatyzacja Web Protection przez XML API

XML API jest przydatne, gdy te same sprawdzone obiekty webowe trzeba utrzymywać na wielu zaporach. Nie zastępuje ani przypisania Web Policy do rzeczywiście odpowiedniej reguły zapory, ani weryfikacji ruchu. Przed zapisem należy zabezpieczyć bieżący zestaw obiektów, jego referencje i poprzednią politykę. Dostęp, budowę żądania, wersję API, status XML i Audit Trail opisano w sekcji Bezpieczna konfiguracja dostępu do XML API i analiza odpowiedzi. Poniższe relacje między obiektami nie stanowią kompletnego żądania gotowego do wykonania. W przypadku wyraźnie wskazanych sprzeczności między źródłami należy najpierw sprawdzić API help zainstalowanej kompilacji i nie wykonywać zapisu bez jednoznacznego wyjaśnienia.

Najpierw obiekty, potem polityka i przypisanie

Przejrzysty przypadek automatyzacji obejmuje własną URL Group dla celów biznesowych, własny File Type dla pobieranych plików oraz User Activity łączącą te kryteria. Najpierw należy odczytać lub utworzyć te obiekty z ich rzeczywistymi nazwami, następnie ustawić odwołania reguł polityki do tych obiektów, a na końcu w kontrolowany sposób przypisać Web Policy do istniejącej, rzeczywiście odpowiedniej reguły zapory. Sam nowy obiekt jeszcze nie zezwala na ruch ani go nie blokuje.

• URL Group: WebFilterURLGroup zawiera Name i powtarzające się wpisy URL w URLlist. Pisownia URLlist nie jest taka sama jak URLList zewnętrznej Web Category. IsDefault oznacza wbudowaną URL Group; według dokumentacji referencyjnej pole jest tylko do odczytu, a jego zmiany są ignorowane podczas aktualizacji. Nie przekształca ono własnego obiektu w edytowalny obiekt domyślny. W kwestii odpowiednich wartości domen i zarządzania w UI nadal miarodajna jest procedura dla URL Group.
• File Type: FileType łączy FileExtensionList z powtarzającymi się wartościami FileExtension oraz MIMEHeaderList z powtarzającymi się wartościami MIMEHeader. Komentarz w przykładzie XML opisuje Template w taki sposób, że rozszerzenia i nagłówki MIME szablonu są przejmowane, a osobno podane wpisy są dodatkowo wstawiane. Dlatego po zapisie należy sprawdzić całą efektywną listę, a nie tylko dodane wartości. Przykład pokazuje Blank, jednak tabela parametrów nie objaśnia Template; nie należy na tej podstawie wyprowadzać uniwersalnej listy dopuszczalnych szablonów. Rozszerzenia pozostają bez początkowej kropki, na przykład pdf.
• User Activity: UserActivity używa Name dla istniejącej nazwy, a NewName dla zamierzonej zmiany nazwy. W CategoryList znajdują się obiekty Category z Type i ID. W przykładzie oznaczenia typów web category, file type i url group są oddzielone od ID będącego nazwą obiektu. Nie należy używać określenia typu jako identyfikatora obiektu ani wymyślać identyfikatora liczbowego. Przykład podaje tag opisu Desc, natomiast tabela — Description; prawidłowy tag należy potwierdzić dla konkretnej kompilacji. Połączenie kryteriów Activity operatorem OR pozostaje oddzielone od późniejszej akcji HTTP/HTTPS.

W przypadku błędu File Type szczególnie istotne są następujące odpowiedzi XML: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type lub Edit File Type 503 / Message.FileTypeSameDetailRecordExists oraz 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Są to niezmienione symbole z dokumentacji referencyjnej, a nie rozwinięte teksty komunikatów ani kody HTTP. Przy 202 należy odczytać starą i nową nazwę oraz referencje w politykach; przy 503 porównać już istniejące wartości szczegółowe, a przy 505 sprawdzić rozszerzenia i nagłówki MIME. Nie należy po prostu tworzyć drugiego obiektu pod inną nazwą.

Własne kategorie: oddzielenie zawartości, klasyfikacji i przepustowości

WebFilterCategory rozróżnia za pomocą ConfigureCategory dwa sposoby wprowadzania danych: Local używa DomainList/Domain i KeywordList/Keyword; External używa URLList/URL dla zewnętrznej listy kategorii. URL zewnętrznej listy nie jest automatycznie wartością domeny biznesowej, na którą należy zezwolić. Pochodzenie, aktualizacja i zawartość zewnętrznej listy muszą być możliwe do prześledzenia. Nie należy bez weryfikacji łączyć obu sposobów w jednym żądaniu.

Classification klasyfikuje kategorię, ale nie decyduje o Allow lub Block. Opis częściowo podaje inne oznaczenia niż tabela wartości wyliczeniowych; ta wymienia Productive, Unproductive, Acceptable i Objectionable. Również ConfigureCategory nie jest w pełni spójne: przykład pokazuje Local/External, a tabela dodatkowo 0. Nie należy przesyłać ani przetłumaczonych nazw klasyfikacji, ani 0 jako niezweryfikowanego zamiennika. QoSPolicy odwołuje się do polityki przepustowości, a nie do akcji Web Policy; wybór i działanie są sprawdzane w procedurze Traffic Shaping. Dopiero odpowiednia reguła Web Policy przekłada kategorię na decyzję o dostępie.

Tabela kategorii wymaga dokładnej kontroli szczegółów po operacji:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded i Update Category 201 / Message.WFCCategoryDetailCannotUpdated: Nie należy traktować wszystkich odpowiedzi XML 2xx jako potwierdzenia pełnego zapisania wartości domen, słów kluczowych lub list. Należy osobno odczytać nagłówek obiektu i każdy wymagany zestaw danych szczegółowych. Add Category 202, podobnie jak 200, odwołuje się do Message.WFCAddSuccess; wspólna nazwa symbolu nie wyjaśnia różnicy między kodami.
• Add Category 522 / Message.WFCMaxFiveURL i 523 / Message.WFCMaxFiveKeyword, ale Update Category 503 / Message.WFCMaxFiveURL i 504 / Message.WFCMaxFiveKeyword: Należy analizować operację i kod łącznie. Same nazwy symboli nie dowodzą uniwersalnego, aktualnego limitu pięciu wpisów; faktycznie dopuszczalny zakres należy ustalić na podstawie pomocy dla danej kompilacji.
• Delete WebFilter Category 201 / Message.WFCRelationExists i 203 / Message.WFCSomeCategoryCannotDeleted: Przed usunięciem lub ponowną próbą należy sprawdzić referencje i pozostałe kategorie. Nie należy przyjmować ogólnego sukcesu usunięcia dla wyboru obejmującego wiele kategorii.

Wszystkie symbole Message.* celowo pozostają tutaj nierozwinięte. Przed ponowną próbą należy zabezpieczyć faktycznie zapisany stan i odpowiedź; w szczególności nie należy bez sprawdzenia powtarzać częściowo zastosowanej zmiany kategorii.

Content Condition Lists: Key to nie Name

Obiekt ContentConditionList zawiera widoczną nazwę Name, oddzielny identyfikator Key oraz ContentList z powtarzającymi się wartościami ContentString. Dokumentacja referencyjna wymaga Name i Key; dla Delete Content Condition List selektorem jest wyraźnie Key. Dlatego podczas odczytu i dokumentowania należy zachować obie wartości i nigdy nie używać wyświetlanej nazwy jako klucza usuwania bez weryfikacji.

Tabela API określa ContentString jako surowe wartości wyrażeń regularnych i informuje, że duplikaty nie są ignorowane. Natomiast opisany powyżej import w UI to lista tekstowa z jednym Exact Match w każdym wierszu. Nie wykazano zatem, że import w UI i lista wyrażeń regularnych API mają identyczny format wejściowy. Przed zmianą sposobu wprowadzania danych należy wyjaśnić semantykę na podstawie pomocy dla danej kompilacji oraz przetestować nieszkodliwe przypadki dopasowania i braku dopasowania; istniejącej listy tekstowej nie należy bez weryfikacji przesyłać jako danych wyrażeń regularnych.

Szczególnie zwracają uwagę sprzeczne przypisania operacji i komunikatów w dokumentacji referencyjnej:

Te wiersze dowodzą sprzeczności w dokumentacji, a nie tego, że Update usuwa lub Delete aktualizuje. Należy sprawdzić operację, Key, odpowiedź i faktycznie istniejącą zawartość. Bez jednoznacznego wyjaśnienia dla danej kompilacji nie należy na tej podstawie wyprowadzać żadnej operacji destrukcyjnej ani uruchamiać automatycznej ponownej próby na podstawie nazwy symbolu.

WebFilterPolicy: zachowanie kolejności i selektorów

WebFilterPolicy przechowuje reguły w RuleList/Rule. Każda reguła odwołuje się w CategoryList/Category do nazwy obiektu ID i selektora type. Przykład polityki używa WebCategory, URLGroup, UserActivity, DynamicCategory i FileType; tokeny te różnią się od oznaczeń typów w przykładzie User Activity, a tag type jest tam zapisany małymi literami. Pisownię, typ obiektu i istniejącą nazwę należy przejąć z odczytanego obiektu lub pomocy dla danej kompilacji, zamiast serializować etykiety UI lub wymyślone identyfikatory.

HTTPAction i HTTPSAction są oddzielnymi decyzjami; FollowHTTPAction opisuje ich powiązanie. Przykład API podaje Deny, Allow, Warn, Log i Quota. Te przykładowe wartości nie potwierdzają, że wszystkie są dostępne do wyboru w każdej kompilacji, a Deny nie można po prostu zastąpić słowem Block z UI. PolicyRuleEnabled steruje aktywacją reguły, Schedule — wskazanym harmonogramem, a UserList/User — zakresem użytkowników. CCLRuleEnabled i CCLList/CCL wiążą filtry treści z regułą; przykład odwołuje się tam do nazwy CCL, podczas gdy usunięcie CCL wymaga jej Key. Zachowanie Content Filter dla HTTPS musi nadal odpowiadać powiązaniu w UI objaśnionemu powyżej. Podczas aktualizacji należy zachować kolejność, zakres użytkowników, harmonogram, filtry treści i Default Action oraz porównać całą zapisaną politykę. Brak pola nie pozwala zakładać, że zostanie ono na pewno zachowane lub usunięte.

Dla poniższych danych wejściowych dokumentacja referencyjna nie dostarcza spójnego, wykonywalnego szablonu:

• DefaultAction: Tabela podaje maksymalnie jeden znak, ale jednocześnie dopuszcza Allow i Deny. Nie należy skracać wartości do jednego znaku ani wymyślać zastępczego kodowania liczbowego. EnableReporting pokazuje w przykładzie Enable/Disable, podczas gdy tabela dopuszcza tylko Enable; wyłączenie nie jest zatem potwierdzone bez sprawdzenia kompilacji.
• DownloadFileSizeRestriction: Komentarz XML podaje od 1 do 1536 MB, a tabela parametrów od 0 do 1536. Znaczenie 0 pozostaje więc niejasne; nie należy traktować tej wartości ani jako braku ograniczenia, ani jako prawidłowego aktywnego limitu. Przełącznik DownloadFileSizeRestrictionEnabled i limit należy ustalić łącznie na podstawie pomocy dla danej kompilacji oraz sprawdzić za pomocą nieszkodliwych plików po obu stronach potwierdzonej granicy. QuotaLimit w tabeli API ma zakres od 1 do 1440; zachowanie interfejsu trzeba potwierdzić dla danej kompilacji. DPI nadal nie obsługuje Policy Quota.
• Tenant Controls: Office365Enabled, Office365TenantsList i Office365DirectoryId należą do ograniczeń dotyczących tenantów Microsoft. Dla listy tabela API podaje 4096 znaków, natomiast pomoc UI dla Restrict-Access-To-Tenants — 256; nie należy utożsamiać tych limitów ani wyprowadzać dłuższej wartości do użytku produkcyjnego na podstawie informacji z API. Przykładowa wartość dla Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, zawiera znaki inne niż szesnastkowe i nie jest prawidłowym przykładem wartości GUID. Nie należy jej po cichu poprawiać, lecz użyć rzeczywistego identyfikatora katalogu z własnego panelu zarządzania tenantem oraz przetestować logowania do dozwolonych i niedozwolonych tenantów. Należy potwierdzić mapowanie pól UI, długości i semantykę w zainstalowanej kompilacji.

Add Policy 522 / Message.WebPoliciesLimit dotyczy limitu polityk; nie należy na tej podstawie wyprowadzać limitu reguł lub kategorii. Update Policy 503 / Message.WFPQuotaLimitInvalid wymaga sprawdzenia wartości wejściowej Quota. Dokumentacja referencyjna wymienia dodatkowo Update Policy from API jako oddzielną nazwę operacji; jej wiersze odpowiedzi nie zawierają tego wpisu 503. Nie dowodzi to, że ta ścieżka akceptuje każdą wartość Quota. Przed ponownym zapisem należy sprawdzić status, zapisaną politykę i rzeczywisty efekt.

Nie należy łączyć globalnych opcji ochrony z powiadomieniami

WebFilterSettings to obszar globalnych ustawień filtrowania WWW, a nie pojedyncza WebFilterPolicy. Zawiera między innymi PharmingProtection, Scanning, BlockUnscannableContent i PUAWhitelist z powtarzającymi się nazwami PUA. Wpis PUA to świadomie zatwierdzony wyjątek, a nie niezbędny krok przy tworzeniu nowej Web Policy. Wybór skanera i jego działanie pozostają przedmiotem podlinkowanej procedury skanowania w poszukiwaniu złośliwego oprogramowania; dostosowanie komunikatu nie jest powodem, by przy okazji zmieniać globalne opcje ochrony lub listę PUA.

WebFilterProtectionSettings to kolejny, odrębny kontrakt skanera/ochrony z polami takimi jak ScanMode i FileSizeThreshold. Podobnie nazwane pola ochrony nie czynią go synonimem WebFilterSettings ani WebFilterNotificationSettings; nie należy wymieniać payloadów między tymi obiektami. W przypadku samego tekstu powiadomienia nie należy dopisywać opcji skanera, rozmiaru ani certyfikatów. Również w przypadku tego obiektu ochrony obowiązujący kontrakt musi pochodzić z pomocy dla danej kompilacji, a nie z przykładowych wartości przejętych bez weryfikacji.

Również tutaj przykład jest sprzeczny z tabelą: BlockUnscannableContent pokazuje Enable/Disable, natomiast tabela dopuszcza Allow i Block (Best Protection). Nie należy ujednolicać tych wartości wyliczeniowych ani zgadywać ich na podstawie nazwy pola. Przed każdą zmianą należy zabezpieczyć dotychczasowe zachowanie i wyjaśnić dokładny kontrakt API dla danej kompilacji.

WebFilterNotificationSettings dotyczy natomiast powiadomień użytkowników. OverrideDefaultDeniedMessage jest powiązane z DefaultDeniedMessage, a OverrideDefaultWarnedMessage z DefaultWarnedMessage; teksty niestandardowe są świadomie wybierane tylko za pomocą odpowiedniego Override. Dodatkowe pola Override/Quota znajdują się w tabeli, ale częściowo brakuje ich w przykładzie: OverrideDefaultOverrideMessage/DefaultOverrideMessage i OverrideDefaultQuotaMessage/DefaultQuotaMessage. Przełączniki Override/Quota podają jako dopuszczalne wartości 0/1, ale jednocześnie Enable jako wartość domyślną. To kolejna sprzeczność między źródłami, a nie powód, by kodować wszystkie flagi tak samo. W przypadku samej zmiany tekstu należy zmienić wyłącznie przewidziane pola tekstowe/Override zgodnie z potwierdzonym kontraktem API danej kompilacji i sprawdzić odpowiednią stronę w pilotażu.

DeniedMessageImage wybiera Default lub Custom. Przykład wiąże TopImageFile i BottomImageFile z nazwą pliku z żądania multipart; tabela opisuje jpg/jpeg. Jednak w przypadku User Notifications tabela nazywa górny parametr Top Image, podczas gdy przykład używa TopImageFile. Informacje te nie wystarczają do pewnego skonstruowania nazw części, Content-Disposition, punktu końcowego przesyłania lub przypisania plików. Najpierw należy wyjaśnić przesyłanie plików na podstawie pomocy dla danej kompilacji lub oficjalnej kolekcji potwierdzonej do tego celu. Bez potwierdzonego kontraktu przesyłania nie należy wykonywać automatycznej zmiany obrazów. Podobne pola komunikatów i obrazów w WebFilterSettings nie sprawiają, że oba obiekty są zamienne.

DefaultWebFilterNotificationSettings jest jeszcze innym, oddzielnym obiektem: udostępnia nazwane domyślne teksty komunikatów, na przykład WebsiteBlocked. Sensownym, wąskim przypadkiem użycia jest zatwierdzona informacja z właściwymi danymi kontaktowymi wsparcia. W tym celu należy zabezpieczyć dokładnie ten oryginalny tekst, którego dotyczy zmiana, zmienić tylko potwierdzony klucz komunikatu, sprawdzić odpowiedni podgląd i rzeczywistą stronę w pilotażu, a w razie potrzeby przywrócić dokładnie ten tekst. Tekst komunikatu nie jest ani zezwoleniem na dostęp, ani dowodem wykrycia złośliwego oprogramowania lub zagrożenia Zero-Day.

Ponowny odczyt i odbiór każdej zmiany automatyzacyjnej

Po każdej operacji zapisu należy ponownie odczytać dokładnie wskazany obiekt przez API lub w WebAdmin: porównać nazwy/klucze, efektywne listy, referencje, kolejność w polityce, aktywację i rzeczywiste przypisanie do zapory. Następnie należy wykonać te same dozwolone i blokowane żądania pilotażowe co przed zmianą oraz skorelować Rule ID, użytkownika, Web Policy i akcję w Log Viewer. Sam sukces HTTP, kod XML 2xx lub nierozwinięty symbol Message.* nie wystarcza. W przypadku częściowej zmiany lub niejasnej odpowiedzi należy najpierw zabezpieczyć stan faktyczny i Audit Trail, a następnie przeprowadzić celowaną korektę; bez ponawiania Add/Delete w ciemno. Wycofywane są wyłącznie udokumentowane własne zmiany, a nie inne istniejące polityki, ustawienia Override lub globalne wartości ochrony.

Testowanie ochrony sieci Web

Po zapisaniu nie należy tylko sprawdzać, czy zasada istnieje. Kluczowe jest, czy działa dla rzeczywistego ruchu.

1. Użycie Policy Tester

Dokładna ścieżka to Diagnostics > Tools > Pop-out tools > Policy tester. Tryb Firewall, SSL/TLS, and web testuje połączoną ścieżkę przezroczystą, a Web policy only izoluje decyzję zasady sieci Web. Test obejmuje wyłącznie przezroczysty dostęp do sieci Web, nie uwzględnia tras SD-WAN i nie przyjmuje Source Networks z adresami MAC. Jeśli protokół nie zostanie podany, używa HTTP; jeśli nie zostanie podany port, używa standardowego portu wybranego protokołu.

Przed zmianą uruchom oba odpowiednie tryby jako punkt odniesienia i zapisz wynik oraz oczekiwane Rule ID, a po zmianie powtórz identyczne testy. Policy Tester pozostaje testem wstępnym i nie zastępuje rzeczywistych prób Allow i Block z klienta pilotażowego, ponieważ NAT, inspekcja TLS, QUIC, routing lub jawna ścieżka Direct Proxy mogą inaczej obsłużyć rzeczywisty przepływ.

2. Test rzeczywisty z klientem pilotażowym

Z klientem pilotażowym sprawdź:

• dozwolona strona biznesowa
• zablokowana kategoria
• ostrzegana kategoria
• URL Group Allow
• URL Group Block
• strona HTTPS z i bez inspekcji TLS
• pobieranie nieszkodliwego typu pliku testowego
• zachowanie z aktywnym lub zablokowanym QUIC

3. Sprawdzenie Log Viewer

W Log Viewer powinno być widoczne:

• która reguła zapory została trafiona
• który użytkownik został rozpoznany, jeśli to istotne
• która kategoria sieci Web lub grupa URL była zaangażowana
• czy HTTPS, inspekcja TLS lub skanowanie złośliwego oprogramowania były zaangażowane
• czy akcja była dozwolona, ostrzegana czy zablokowana
• czy zadziałał Web Exception lub TLS Exclusion
• czy pobieranie zostało potraktowane inaczej z powodu rozmiaru, błędu skanowania malware lub analizy Zero-Day

W przypadku Syslog lub SIEM sam URL i action nie wystarczają. Do wiarygodnej analizy potrzebne są również Firewall Rule ID, użytkownik, kategoria, zasada sieci Web, metoda HTTP, status, wynik skanowania, wskazanie wyjątku i odniesienie SSL/TLS. Jeśli tych pól brakuje w SIEM albo są źle normalizowane, ochrona sieci Web w raportach szybko wygląda mniej jasno niż rzeczywiście działa na zaporze.

Dla głębszego rozwiązywania problemów istotne są również pliki dziennika. Przypisanie znajduje się w Rozwiązywanie problemów z Sophos Firewall: Usługi i logi.

Alerty natychmiastowe i raportowanie

Jeśli określone kategorie mają być nie tylko blokowane, ale także aktywnie zgłaszane, alerty natychmiastowe mogą być przydatne. Jest to szczególnie użyteczne w szkołach, ściśle regulowanych środowiskach lub obszarach z jasną polityką korzystania z Internetu.

Trzy ścieżki analizy odpowiadają na różne pytania:

• Szybki e-mail przy kilku wrażliwych kategoriach sieci Web: Alerty natychmiastowe.
• Powtarzające się raporty, trendy i analizy użytkowników lub kategorii: Central Firewall Reporting.
• Dłuższe przechowywanie, korelacja z innymi systemami lub procesy SOC: Syslog lub SIEM.

Przed alertami natychmiastowymi powinno być jasne, kto otrzymuje powiadomienie, które kategorie naprawdę wywołują reakcję, jak traktowane są fałszywe alarmy i kiedy przeglądana jest lista kategorii. Szeroka lista alertów bez właściciela szybko generuje szum e-mailowy, ale nie poprawia bezpieczeństwa.

Do technicznej aktywacji i triage pasuje Wykorzystanie kategorii sieci Web Sophos Firewall i alertów natychmiastowych. Dla długoterminowych analiz warto sprawdzić Central Firewall Reporting lub Wysyłanie Syslog do SIEM Sophos Firewall.

Zarządzanie zmianami i wyjątkami w działaniu

Ochrona sieci Web zmienia się w działaniu na bieżąco. Pojawiają się nowe usługi SaaS, pojedyncze domeny są błędnie klasyfikowane, działy potrzebują tymczasowego dostępu, a zachowanie przeglądarek się zmienia. Bez jasnego przebiegu szybko powstają szerokie wyjątki, których później nikt nie potrafi wyjaśnić.

Dla każdej zmiany należy przynajmniej zanotować:

• Kto potrzebuje dostępu? zapobiega globalnym wyjątkom dla kilku użytkowników.
• Jaka domena, kategoria lub typ pliku jest dotknięty? oddziela grupę URL, kategorię sieci Web i typ pliku czysto.
• Czy wyjątek jest tymczasowy, czy stały? Termin przeglądu zapobiega pozostawieniu tymczasowego zezwolenia na stałe bez kontroli.
• Która reguła zapory i zasada sieci Web są dotknięte? zapobiega zmianom w niewłaściwej regule.
• Jak będzie testowane? czyni sukces widocznym w Log Viewer.

Sprawdzony mały przebieg zmian:

1. Zarejestruj żądanie z użytkownikiem, URL, czasem, powodem biznesowym i zrzutem ekranu lub komunikatem o błędzie.
2. W Log Viewer sprawdź, która reguła zapory, zasada sieci Web, kategoria i akcja zadziałały.
3. Zdecyduj, czy kategoria jest zasadniczo błędna, czy dostęp ma być dozwolony tylko do pojedynczej domeny, czy żądanie ma być odrzucone.
4. Jeśli konieczne jest zezwolenie na dostęp biznesowy, zachowaj jego wąski zakres w pasującej regule zapory i Web Policy: konkretna URL Group zamiast całej kategorii oraz jawnie wskazani Users zamiast całej sieci LAN. Jeśli zamiast tego potrzebna jest Web Exception, użyj jej własnych obsługiwanych kryteriów URL, kategorii lub IP; grupa użytkowników ani URL Group nie jest kryterium Web Exception.
5. Sprawdź zmianę w regule testowej lub grupie pilotażowej.
6. Po zapisaniu przeprowadź test rzeczywisty i udokumentuj Log Viewer, kategorię, ID reguły i kontekst użytkownika.
7. Ustaw datę przeglądu, szczególnie dla tymczasowych wyjątków biznesowych.

Tymczasowe wyjątki powinny być jasno nazwane, na przykład TMP_ALLOW_vendor-portal_until_2026-07-31. Trwałe wyjątki biznesowe również potrzebują właściciela. Jeśli nikt nie jest odpowiedzialny za wyjątek, nie powinien on pozostawać trwale w zasadzie.

Jeśli wiele pojedynczych domen powstaje dla tej samej usługi, problemem często nie jest zasada sieci Web, ale architektura usługi. Wtedy warto sprawdzić, czy lepiej pasuje własna reguła zapory, własna zasada sieci Web, starannie utrzymana grupa URL lub inny punkt kontrolny. Dla dynamicznych list IOC lub blokad wyjątki w zasadach sieci Web są zazwyczaj niewłaściwym miejscem; lepiej pasują Sophos Firewall Threat Feeds.

Wycofanie i awaryjne zezwolenie

Zmiana zasady sieci Web może natychmiast wpłynąć na produktywną pracę. Dlatego przed większymi zmianami należy ustalić, jak przywrócić stary stan.

Praktyczne opcje wycofania:

• zduplikuj lub udokumentuj dotkniętą zasadę sieci Web przed zmianą
• najpierw przetestuj zmianę w regule pilotażowej lub małej grupie użytkowników
• nie usuwaj od razu starej reguły zapory lub starej zasady sieci Web
• zdefiniuj okno czasowe, użytkowników testowych i kryterium powrotu
• po zapisaniu sprawdź Log Viewer, ID reguły i decyzję kategorii

W przypadku nagłych blokad nie wstawiaj odruchowo szerokiej reguły Allow na początku listy. Wybierz raczej wąskie, ograniczone czasowo zezwolenie na dostęp biznesowy w pasującej regule zapory i Web Policy, z konkretną URL Group, jawnie wskazanymi Users i datą przeglądu. Nie jest to Web Exception ograniczona do grupy użytkowników. Każde konieczne pominięcie inspekcji wymaga własnych zatwierdzonych, obsługiwanych kryteriów dopasowania oraz osobnych testów pozytywnych i negatywnych. Następnie ponownie oceń tymczasowe zezwolenie.

Typowe błędy

Zasada sieci Web nie działa

Najczęściej zasada nie jest aktywowana w odpowiedniej regule zapory, reguła nie jest trafiona, reguła wyżej pozwala na ruch lub kontekst użytkownika nie pasuje. Najpierw sprawdź Log Viewer i ID reguły.

HTTPS nie jest blokowany zgodnie z oczekiwaniami

Bez inspekcji TLS zapora widzi mniej szczegółów. W zależności od celu decyzja dotycząca domeny lub kategorii może działać, podczas gdy inspekcja treści, typy plików lub określone funkcje wyszukiwania są ograniczone.

Jeśli połączenie nie jest deszyfrowane, zapora nadal może używać informacji SNI lub domenowych do decyzji polityki. Strony blokady, strony ostrzegawcze, typy plików, Content Filters, skanowanie malware i analiza Zero-Day wymagają jednak większej widoczności. Dlatego w Log Viewer należy sprawdzić nie tylko akcję zasady sieci Web, ale także status SSL/TLS Inspection.

QUIC omija oczekiwania

Jeśli przeglądarki używają UDP 443, ruch może być przetwarzany inaczej niż klasyczny HTTPS przez TCP. W regułach klientów należy świadomie zdecydować, czy QUIC jest blokowany.

Reguła zezwalania jest zbyt wysoko

Szeroka reguła zezwalania na początku zasady sieci Web może unieważnić późniejsze reguły blokowania. Kolejność reguł w ramach zasady sieci Web jest równie ważna jak kolejność reguł na liście reguł zapory.

Zbyt wiele wyjątków

Wyjątki szybko rozwiązują pojedynczy problem, ale mogą osłabić ochronę. Każdy wyjątek potrzebuje celu, właściciela i daty przeglądu. Jeśli powstaje wiele wyjątków, często struktura zasady jest błędna lub aplikacja biznesowa potrzebuje własnej reguły.

Szczególnie ryzykowne są Web Exceptions, które pomijają Policy checks albo Malware and content scanning. Jeśli problemem jest tylko HTTPS decryption, SSL/TLS Exclusion jest zwykle węższe i bardziej zrozumiałe.

Raportowanie nic nie pokazuje

Wtedy należy sprawdzić logowanie, raportowanie, wybór reguły zapory, zasady lub przekazywanie logów. Zasada bez logowania jest trudna do oceny w działaniu.

Lista kontrolna operacyjna

• Sprawdzono status licencji ochrony sieci Web.
• Oddzielnie oceniono ruch klientów, serwerów, gości i VPN.
• Utworzono zasadę sieci Web z opisową nazwą.
• Świadomie zaplanowano krytyczne kategorie i grupy URL.
• Sprawdzono kolejność reguł w ramach zasady sieci Web.
• Aktywowano zasadę sieci Web w odpowiedniej regule zapory.
• Log firewall traffic, logowanie zasady sieci Web i Reporting są aktywne.
• Reguły zasady sieci Web są włączone i we właściwej kolejności.
• Sprawdzono inspekcję TLS i certyfikat CA dla grupy pilotażowej.
• Zdefiniowano strategię QUIC.
• Web Exceptions i TLS Exclusions są udokumentowane oddzielnie.
• Przeprowadzono testy Policy Tester i rzeczywiste.
• Skontrolowano Log Viewer i raportowanie.
• Zdefiniowano proces zmian dla wyjątków w zasadach sieci Web.
• Tymczasowe wyjątki oznaczone datą wygaśnięcia.
• Udokumentowano wyjątki z właścicielem i datą przeglądu.

FAQ