Konfiguracja Direct Web Proxy na Sophos Firewall z plikiem PAC

W przypadku Direct Web Proxy przeglądarki i aplikacje obsługujące proxy świadomie wysyłają połączenia HTTP i HTTPS do Sophos Firewall. Różni się to od przezroczystego proxy internetowego i DPI Engine: klient zna cel proxy i zwykle łączy się z portem TCP 3128.

Direct Web Proxy sprawdza się, gdy ruch internetowy ma być centralnie sterowany za pomocą pliku PAC, uwierzytelniany dla poszczególnych użytkowników albo przetwarzany przez funkcje wymagające proxy internetowego. Nie jest jednak ogólną trasą internetową dla każdej aplikacji. Tą ścieżką przechodzi tylko ruch, który rzeczywiście korzysta z konfiguracji proxy.

⚠️ Klient z dostępem do proxy internetowego może tą ścieżką dotrzeć do lokalnych usług HTTP i HTTPS zapory, nawet jeśli WebAdmin, User Portal lub VPN Portal nie są włączone dla jego strefy w Device access. Dlatego proxy należy najpierw otworzyć tylko dla jednego klienta pilotażowego i jawnie wykonać negatywne testy tych celów administracyjnych.

Ta procedura dotyczy zarządzanego klienta pilotażowego IPv4. Dla klientów tylko IPv6 artykuł Konfiguracja NAT64 z Direct Web Proxy wyjaśnia oddzielną regułę IPv6 do proxy i regułę IPv4 do celu A-only.

Ustawienia w sekcji Web > General settings dotyczą SFOS 22.0 i 23.0. Przed wdrożeniem porównać pola w zainstalowanej kompilacji i wykonać poniższe testy klienta, polityki, TLS i ścieżki powrotnej.

Direct Web Proxy w dziesięciu krokach

1. Określić jeden zarządzany klient pilotażowy, jego stały adres IP i wymagane cele internetowe.
2. Udokumentować FQDN proxy, DNS, port nasłuchu i istniejące zależności od proxy.
3. W sekcji Web > General settings sprawdzić Web proxy listening port oraz dozwolone porty docelowe.
4. W sekcji Administration > Device access zezwolić na usługę Web proxy tylko dla pilota i planowanego adresu zapory.
5. Utworzyć osobną, logowaną regułę zapory ze źródłem pilotażowym, strefą docelową WAN, usługą TCP 3128 i wymaganą Web Policy.
6. Przygotować plik PAC ze świadomie określonymi wewnętrznymi celami DIRECT i bez internetowego fallbacku omijającego proxy.
7. Rozprowadzić adres URL PAC tylko do klienta pilotażowego i sprawdzić faktycznie wczytaną konfigurację proxy.
8. Przetestować jedno dozwolone i jedno zablokowane żądanie HTTP/HTTPS oraz sprawdzić oczekiwaną Firewall Rule ID.
9. Wykonać negatywne testy lokalnych portali zapory, deszyfrowania TLS, aplikacji bez obsługi proxy i awarii proxy.
10. Dopiero potem dodać kolejnych zarządzanych klientów oraz udokumentować wycofanie, właściciela i datę przeglądu.

Direct Web Proxy, proxy przezroczyste czy DPI?

Te trzy pojęcia opisują różne ścieżki ruchu:

• Direct Web Proxy: Klient jest jawnie skonfigurowany do korzystania z zapory i jej portu proxy. Przeglądarka, system operacyjny lub aplikacja wysyła żądanie do fw01.corp.example:3128.
• Przezroczyste proxy internetowe: Klient nie wie o proxy. Jeśli usługa jest włączona dla jego strefy, zapora przezroczyście przechwytuje HTTP na porcie 80 i HTTPS na porcie 443.
• DPI Engine: Zapora przetwarza trasowany ruch bez wymuszania klasycznego proxy internetowego i może sprawdzać HTTP lub TLS na dodatkowych portach zgodnie z regułami zapory i SSL/TLS inspection.

Opcja Use web proxy instead of DPI engine w regule zapory nie jest wymagana, aby jawnie skonfigurowany klient używał Direct Web Proxy. Ścieżka klienta wynika z konfiguracji proxy. Opcja określa, czy reguła ma używać proxy internetowego zamiast DPI Engine do filtrowania zwykłego ruchu internetowego na standardowych portach.

Pełny wybór trybu, wraz z funkcjami wyłącznie proxy, konfiguracją TLS i kontrolowaną migracją reguł, opisano w Prawidłowy wybór DPI Engine lub Web Proxy.

Sophos nadal wskazuje funkcje, które wymagają Proxy Mode, między innymi SafeSearch, YouTube Restrictions, ograniczenia domen Google Workspace, Pharming Protection, Web Cache i Parent Proxy. Artykuł Web Protection na Sophos Firewall wyjaśnia wybór polityki i ochrony.

Gdy Sophos Firewall ma wysyłać Web Requests do kolejnej instancji proxy, konfiguracja upstream proxy w WAN lub LAN/DMZ wyjaśnia osobną ścieżkę reguł, NAT i walidacji.

Direct Web Proxy zmienia również sposób obserwowania ruchu. Klient najpierw łączy się z zaporą, a następnie zapora tworzy połączenie z celem. Sophos dokumentuje zatem dwa istotne ograniczenia:

• IPS Policy działa między proxy a WAN, a nie między użytkownikiem a proxy.
• Traffic Shaping Policy nie działa dla ruchu Direct Proxy.

Jeśli aplikacja nie potrafi korzystać z jawnego proxy, nie można oczekiwać, że plik PAC przejmie jej połączenia. Taka aplikacja nadal wymaga zwykłej trasowanej ścieżki DPI, zapory lub oddzielnego proxy.

Przykład i wartości do zastąpienia

W artykule użyto małego środowiska pilotażowego:

• Klient pilotażowy: CLIENT-PROXY-01
• stały adres IP klienta: 10.20.30.50
• strefa klienta: LAN
• FQDN zapory i cel proxy: fw01.corp.example
• port Direct Web Proxy: 3128
• adres URL PAC: https://config.corp.example/proxy.pac
• wewnętrzna strefa DNS: .corp.example
• reguła zapory: LAN_DirectProxy_Pilot
• Web Policy: Web_Standard_Pilot

Adres 10.20.30.50 należy zastąpić stałym adresem IP, który zapora rzeczywiście widzi jako źródło klienta pilotażowego. DHCP powinien zapewniać rezerwację tego adresu. Za adresem nie może znajdować się NAT ukrywający inne urządzenia.

fw01.corp.example i config.corp.example to nazwy dokumentacyjne. Należy je zastąpić nazwami FQDN rozwiązywanymi wewnętrznie i objętymi właściwymi certyfikatami. FQDN proxy wskazuje planowany adres LAN lub adres zarządzający zapory. Adres URL PAC wskazuje kontrolowany wewnętrzny serwer WWW albo istniejącą ścieżkę zarządzania urządzeniami końcowymi, a nie przypadkową lokalizację publiczną.

Port 3128 jest domyślnym portem Direct Web Proxy. Jeśli używany jest inny Web proxy listening port, Device Access, reguła zapory, plik PAC, przeglądarka, SD-WAN Route i testy muszą zawierać ten sam port. Nazwę reguły lub polityki można wybrać dowolnie, ale powinna jasno wskazywać cel, źródło i status pilotażowy.

Przygotowanie dostępu do proxy i reguły ochrony

Określenie listenera i dozwolonych portów docelowych

W sekcji Web > General settings > Web proxy configuration należy sprawdzić podstawowe ustawienia proxy:

1. Web proxy listening port: w tym przykładzie 3128.
2. Allowed destination ports: tylko porty, z którymi klienci rzeczywiście muszą łączyć się przez proxy.
3. Minimum TLS version: wspólna minimalna wersja dla proxy internetowego i Captive Portal; zmiana wpływa na obie funkcje.

Dozwolone porty docelowe nie są portem listenera. Klient łączy się z portem 3128 zapory, ale za pomocą HTTP CONNECT może na przykład zażądać zewnętrznego celu na porcie 443. Niestandardowe porty docelowe należy dodawać dopiero po konkretnym teście aplikacji. Szeroka lista portów niepotrzebnie zmienia proxy w ogólny tunel.

Port Web proxy listening port przyjmuje żądania połączeń HTTP od klientów jawnie skonfigurowanych do korzystania z proxy. Ustawienie Allowed destination ports obowiązuje tylko wtedy, gdy ten port nasłuchu jest ustawiony; nie jest to ogólne zezwolenie na porty dla trasowanego ruchu DPI.

Przed zmianą portu należy przeszukać istniejące pliki PAC, GPO, polityki przeglądarek, hosty RDS, SD-WAN Routes i monitoring. Listener jest ustawieniem współdzielonym, a nie wartością przeznaczoną do zmiany tylko dla jednego pilota.

Device Console może osobno traktować minimalne wersje TLS dla Web Proxy i Captive Portal oraz zawiera dalsze globalne wartości limitów czasu, nagłówków Via, pętli proxy i kategoryzacji URL. Bezpieczne sprawdzanie ustawień HTTP Proxy opisuje udokumentowany stan bazowy, kontrolowany test i wycofanie bez mieszania konfiguracji z globalną optymalizacją.

Prawidłowe przyporządkowanie pól XML dotyczących nasłuchiwania i pamięci podręcznej

Przy automatyzacji tych ustawień należy odróżniać obiekty XML od nazw w interfejsie użytkownika. Opisy API dla SFOS 22.0 i 23.0 wymieniają WebFilterAdvancedSettings z następującymi polami:

• WebCaching: Enable lub Disable dla Enable web content cache; udokumentowana wartość domyślna to Disable. Działanie pozostaje ograniczone do ścieżki Web Proxy.
• WebProxyPort: port nasłuchiwania dla klientów korzystających z jawnego proxy, udokumentowana wartość domyślna to 3128, liczba całkowita od 1 do 65535. Nie jest to port serwera WWW, do którego kierowane jest żądanie.
• TrustedPorts z powtarzającymi się wpisami Port: dozwolone porty docelowe dla tego portu nasłuchiwania, odpowiadające Allowed destination ports. Zezwolenie obowiązuje tylko przy ustawionym porcie nasłuchiwania i nie zastępuje reguły zapory.
• WebProxyMinimumTLSVersion: wspólna minimalna wersja dla Web Proxy i Captive Portal. Strony API wymieniają TLS 1.0, TLS 1.1 i TLS 1.2 oraz TLS 1.1 jako wartość domyślną. Jest to udokumentowana lista wartości, a nie zalecenie stosowania przestarzałych wersji TLS ani potwierdzenie aktualnych wartości w każdej kompilacji.

Osobny obiekt WebProxy również zawiera WebProxyPort i TrustedPorts/Port. W nim WebProxyPort jest udokumentowany jako pole obowiązkowe, natomiast w WebFilterAdvancedSettings jako opcjonalne. Dla WebProxy opis podaje wartości portów docelowych od 1 do 65535 oraz znak *; nie wynika z tego zalecenie zezwalania za pomocą symbolu wieloznacznego. Te dwa obiekty nie są wymiennymi, kompletnymi szablonami konfiguracji.

Zmiana portu nasłuchiwania może odciąć istniejących klientów od proxy i nie jest ogólnym sposobem zwiększania przepustowości. Przed zmianą należy zabezpieczyć rzeczywisty stan, ustawienia PAC i przeglądarek oraz zależności dotyczące reguł i routingu; po dokładnie jednej zmianie sprawdzić nowe dozwolone i blokowane żądania proxy, a w razie regresji przywrócić zapisaną wartość wraz z zależnymi ustawieniami klientów. Przyporządkowanie XML nie jest wykonywalnym żądaniem API: przed automatyzacją należy wyjaśnić dla zainstalowanej kompilacji kwestię brakujących pól, zachowania przy zastępowaniu istniejących list i konkretnej składni żądania.

Osobna decyzja o buforowaniu treści WWW

W sekcji Web > General settings > Web content caching opcja Enable web content cache przechowuje kopię niedawno odwiedzanych treści, aby ograniczyć zużycie pasma i poprawić wydajność. SFOS stosuje to ustawienie wyłącznie z serwerem proxy WWW; nie dodaje ono pamięci podręcznej do ścieżki DPI.

Pozostaw pamięć podręczną w udokumentowanym stanie bazowym, jeśli pilotaż proxy nie ma mierzalnego celu dotyczącego pasma lub wydajności. W razie jej włączenia najpierw zapisz poprzedni stan, następnie powtórz z klienta pilotażowego to samo reprezentatywne żądanie statyczne i porównaj logi proxy oraz transfer WAN, potwierdzając nadal oczekiwane Rule ID i zasadę sieci Web. Dynamiczne lub uwierzytelniane aplikacje biznesowe wymagają również negatywnego testu funkcjonalnego; krótszy czas ładowania sam w sobie nie dowodzi działania pamięci podręcznej.

Aby wycofać zmianę, przywróć poprzedni stan Enable web content cache i powtórz testy żądania oraz zasady. Cofnięta zostanie wyłącznie ta zmiana konfiguracji, bez modyfikowania skanowania, TLS, Policy Overrides ani projektu PAC.

Zrozumienie Pharming Protection

W Web > General settings > Malware and content scanning opcja Enable pharming protection chroni ścieżkę proxy przed pharmingiem: użytkownicy są przekierowywani z prawidłowej domeny na oszukańczą stronę o łudząco podobnym wyglądzie. SFOS ponawia zapytanie DNS przed nawiązaniem połączenia, aby przeciwdziałać domain name poisoning. To funkcja ochrony proxy, a nie konfiguracja usługi DNS ani dowód, że każda odpowiedź DNS jest wiarygodna.

Przed zmianą należy udokumentować poprzednią wartość i objętych nią klientów proxy. W pilotażu sprawdzić te same dozwolone i blokowane cele oraz aplikacje krytyczne dla działalności, używając nowych połączeń i porównując Rule ID, politykę WWW oraz błędy w Log Viewer. Samo poprawne otwarcie strony nie dowodzi, że powstrzymano atak pharmingowy. W razie regresji przywrócić udokumentowany stan poprzedni; nie zmieniać jednocześnie resolverów, PAC i polityki WWW.

Ograniczenie Device Access do klienta pilotażowego

Usługa Web proxy jest fabrycznie włączona dla LAN i Wi-Fi. Dodatkowy wyjątek Accept nie ogranicza już aktywnego szerokiego zezwolenia strefowego. Aby uzyskać rzeczywisty dostęp pilotażowy, szerokie zezwolenie musi pozostać wyłączone lub zostać najpierw kontrolowanie zastąpione węższymi wyjątkami.

W sekcji Administration > Device access > Local service ACL exception rule > Add:

1. Rule name: Allow_DirectProxy_Pilot
2. Rule position: powyżej pasującego wyjątku Drop
3. IP version: IPv4
4. Source zone: LAN
5. Source Network / Host: CLIENT-PROXY-01 z adresem 10.20.30.50
6. Destination host: konkretny adres zapory, na który rozwiązuje się fw01.corp.example
7. Services: Web proxy
8. Action: Accept

Przed wyłączeniem szerokiego zezwolenia strefowego należy sprawdzić, czy inni klienci lub usługi nie korzystają już z proxy bezpośredniego albo przezroczystego. Przewodnik po Device Access i Local Service ACL szczegółowo objaśnia kolejność reguł, macierz stref i reguły wyjątków.

Połączenie Web Policy z regułą zapory

Web Policy przygotowuje się w sekcji Web > Policies. Zawiera ona wymagane kategorie, URL Groups, reguły użytkowników lub grup i działania. Dla pilota należy zdefiniować co najmniej jeden świadomie dozwolony i jeden świadomie blokowany cel.

Następnie w sekcji Rules and policies > Firewall rules należy utworzyć osobną regułę IPv4:

• Rule name: LAN_DirectProxy_Pilot
• Action: Accept
• Log firewall traffic: włączone
• Source zones: LAN
• Source networks and devices: CLIENT-PROXY-01
• Destination zones: WAN
• Destination networks: Any lub węziej zaplanowana grupa celów
• Services: osobna usługa TCP dla 3128
• Match known users: włączyć tylko wtedy, gdy wybrana ścieżka uwierzytelniania przeszła już pozytywny test
• Use web authentication for unknown users: włączyć tylko wtedy, gdy nieznani użytkownicy mają logować się przez AD SSO lub Captive Portal, a odpowiednia usługa jest dostępna z LAN w Device access
• Web filtering > Web policy: Web_Standard_Pilot
• Scan HTTP and decrypted HTTPS: tylko z właściwą licencją i świadomie zaplanowanym skanowaniem

Według Sophos jako usługi dla Direct Proxy można także użyć Any, ale jest to zakres szerszy niż potrzebny. Osobna usługa TCP dla rzeczywistego listenera zwiększa czytelność pilota. Po wybraniu Web Policy i innych funkcji ochrony należy ponownie sprawdzić całą regułę. Podstawy reguł zapory wyjaśniają kolejność, logowanie, dopasowanie użytkowników i pola ochrony.

Dla Direct Proxy pole Destination zones musi mieć wartość WAN lub Any, aby SFOS przekazał żądanie do komponentu web proxy. Dotyczy to również sytuacji, gdy żądany serwer WWW faktycznie znajduje się w LAN lub DMZ. Natomiast Destination networks może zawierać rzeczywisty cel WWW albo Any.

Block QUIC protocol w tej konkretnej regule nie zapewnia niezawodnej kontroli obejścia: reguła ograniczona do TCP 3128 nie dopasuje bezpośredniego ruchu UDP 443. Dlatego bezpośredni dostęp pilota do Internetu należy zablokować lub kontrolować osobną regułą, której kryteria dopasują ten ruch. Jeśli bezpośredni dostęp WWW pozostaje dozwolony, QUIC należy blokować w tamtej regule. Artykuł Kontrolowanie QUIC na Sophos Firewall objaśnia ten mechanizm.

Linked NAT nie jest automatycznie potrzebny dla tego pilota. Ścieżka internetowa tworzona przez zaporę wymaga jednak odpowiedniej bramy WAN i tłumaczenia źródłowego właściwego dla środowiska. Routing i NAT sprawdza się oddzielnie.

Wybór Web Policy nie zastępuje skanowania pod kątem złośliwego oprogramowania. Scan HTTP and decrypted HTTPS działa tylko na ścieżce ruchu faktycznie dopasowanej do reguły; w przypadku HTTPS wymagane jest dodatkowo deszyfrowanie. Wspólne ustawienia silnika skanowania, Web proxy scanning mode, aplikacji PUA, treści niemożliwych do przeskanowania, rozmiarów plików i multimediów opisano w artykule Konfiguracja i testowanie skanowania pod kątem złośliwego oprogramowania. Zbyt duży pobierany plik może pozostać nieprzeskanowany. FTP ma własne opcje reguł i rozmiarów i nie jest konfigurowany w ramach tej instrukcji PAC dla HTTP/HTTPS. Także przy skanowaniu wsadowym pozostaje w mocy wskazane wyżej ograniczenie Direct Proxy: Traffic Shaping Policy nie działa na tej ścieżce.

Oddzielenie pól ochrony XML od połączenia proxy

WebFilterProtectionSettings opisuje ogólne ustawienia ochrony WWW, a nie port nasłuchiwania. Nazwa AntiVirusHTTPsConfiguration jest ponadto wymieniana jako osobna encja eksportu. Podobieństwo nazw nie dowodzi ani identyczności pól, ani wymienności obiektów XML; bez potwierdzonego przyporządkowania dla zainstalowanej kompilacji jedna nazwa nie jest zastępowana drugą.

Przy przyporządkowywaniu istniejących funkcji ochrony w interfejsie użytkownika szczególnie istotne są następujące pola:

• ScanMode z wartościami RealTime lub BatchMode odnosi się do Web proxy scanning mode, a nie do wyboru między DPI a proxy. DPI pozostaje w trybie czasu rzeczywistego.
• Scanning, BlockUnscannableContent, AudioVideoFileScanning i PharmingProtection dotyczą silnika skanowania, treści, których nie można przeskanować, multimediów i pharmingu. PUADetection oraz lista PUAWhitelist z wpisami PUA dotyczą zapobiegania pobieraniu PUA i jawnie dozwolonych PUA.
• HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate i NoHttpsNotification dotyczą urzędu certyfikacji proxy, nieznanych protokołów SSL, nieprawidłowych certyfikatów i powiadomień HTTPS. Block invalid certificates i AllowInvalidCertificate opisują przeciwne działania: „blokowania” nie wolno bezrefleksyjnie odwzorowywać jako „zezwalania”. Również NoHttpsNotification bez weryfikacji kompilacji nie stanowi jednoznacznego odwzorowania dwóch opcji powiadomień w interfejsie użytkownika.
• FileSizeThreshold dotyczy HTTP(S), a FTPFileSizeThreshold osobno FTP. Tabele API podają w obu przypadkach KB, wartość domyślną 1024 i zakres od 1 do 1572864; opis interfejsu użytkownika podaje natomiast MB dla obu pól rozmiaru. Pliki przekraczające ustawiony limit nie są skanowane. Dlatego nie należy kopiować wartości liczbowej bez zmian między interfejsem użytkownika a XML; najpierw trzeba potwierdzić jednostkę i faktycznie obowiązującą wartość dla dokładnie tej ścieżki konfiguracji.

Strony API są sprzeczne w odniesieniu do niektórych przełączników: przykład używa Enable/Disable, a tabele podają częściowo on/off lub nierozwiązane wewnętrzne symbole zastępcze, na przykład dla DenyUnknownProtocol i PUADetection. Również BlockUnscannableContent ma w przykładzie inne wartości niż w tabeli. Dlatego nie wyprowadza się tutaj gotowego do skopiowania żądania konfiguracji ochrony. Udokumentowane wartości domyślne, w tym zezwolenie na nieprawidłowe certyfikaty w tabeli API, nie są ani zaleceniem wdrożeniowym, ani zamiennikiem zabezpieczonego stanu rzeczywistego. Faktyczna decyzja dotycząca ochrony i testy pozostają częścią procedury skanowania pod kątem złośliwego oprogramowania opisanej w podlinkowanym materiale; przed automatyzacją należy wyjaśnić schemat, jednostki i wartości przełączników. Opisane wyżej warunki wstępne dotyczące reguł i HTTPS nadal obowiązują.

Tworzenie i dystrybucja pliku PAC

Świadomie ograniczony przykład PAC

Plik PAC jest kodem JavaScript z funkcją FindProxyForURL. Ten przykład pozwala na bezpośredni ruch tylko dla krótkich nazw wewnętrznych, wewnętrznej strefy DNS i wskazanych sieci prywatnych. Wszystkie pozostałe cele muszą używać proxy:

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) || host === "corp.example" ||
      dnsDomainIs(host, ".corp.example")) {
    return "DIRECT";
  }

  var isIPv4Literal = /^\d{1,3}(\.\d{1,3}){3}$/.test(host);
  if (isIPv4Literal && (
      isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "172.16.0.0", "255.240.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0"))) {
    return "DIRECT";
  }

  return "PROXY fw01.corp.example:3128";
}

Należy dostosować corp.example, .corp.example, sieci prywatne i FQDN proxy do własnego środowiska. Osobne porównanie z corp.example obejmuje samą domenę, a dnsDomainIs(host, ".corp.example") jej subdomeny. Nie każda sieć RFC1918 musi być dostępna wewnętrznie. Lepszym rozwiązaniem jest lista rzeczywiście potrzebnych wewnętrznych domen i sieci.

Przykład celowo nie wywołuje dnsResolve() dla publicznych nazw hostów. Takie funkcje PAC powodują dodatkowe zapytania DNS na kliencie i mogą opóźniać przetwarzanie; w tym rozwiązaniu nazwy zewnętrzne rozwiązuje proxy. Nazwy wewnętrzne są klasyfikowane za pomocą reguł domen lub, gdy żądanie zawiera bezpośredni adres IPv4, za pomocą isInNet(). Jeżeli środowisko wymaga bardziej złożonych wyjątków zależnych od DNS, należy zaplanować je osobno i przetestować w używanych przeglądarkach.

Przykład celowo nie zawiera DIRECT po instrukcji proxy. Wartość zwracana taka jak PROXY fw01.corp.example:3128; DIRECT pozwala ruchowi internetowemu przejść bezpośrednio w razie awarii proxy. Zwiększa to dostępność, ale jednocześnie omija Web Policy, uwierzytelnianie proxy i logowanie proxy. Nie zalecamy takiego fallbacku fail-open dla obowiązkowej ścieżki bezpieczeństwa.

Wewnętrzne wyjątki DIRECT również stanowią obejście. Należy je dodawać tylko wtedy, gdy cel naprawdę musi być osiągalny bezpośrednio i istnieje inna ścieżka kontroli. Wrażliwych domen SaaS, dostawców tożsamości ani ogólnych symboli wieloznacznych nie należy zapobiegawczo dodawać do listy obejść.

Kontrolowane wdrażanie pliku PAC

1. Umieścić plik PAC na wewnętrznym punkcie końcowym HTTPS z zaufanym certyfikatem.
2. Zapewnić możliwość pobrania https://config.corp.example/proxy.pac bez już działającego proxy.
3. Przypisać adres URL PAC tylko do pilota za pomocą GPO, MDM lub zarządzanej polityki przeglądarki.
4. Wcześniej udokumentować istniejącą ręczną konfigurację proxy i inne ustawienia PAC lub WPAD.
5. Całkowicie ponownie uruchomić przeglądarkę i objęte testem aplikacje.
6. Sprawdzić, który adres URL PAC został faktycznie wczytany przez politykę przeglądarki lub systemu operacyjnego.
7. Kontrolowanie zablokować bezpośredni dostęp do Internetu poza ścieżką proxy dla pilota lub co najmniej przetestować go jako obejście.

Autowykrywanie WPAD nie jest potrzebne w tej procedurze. Jawny, zarządzany adres URL PAC łatwiej przypisać i wycofać. W tym modelu SFOS udostępnia listener; dystrybucja, hosting i wersjonowanie pliku PAC pozostają zadaniami zarządzania klientami i serwerem WWW.

Osobno przetestować niedostępność PAC: brak DIRECT w skrypcie nie zapobiega automatycznemu dostępowi bezpośredniemu, jeśli przeglądarka w ogóle nie może wczytać pliku PAC. Zależnie od konfiguracji proxy Chrome może wtedy przejść na dostęp bezpośredni. Dlatego podczas pilotażu należy także przetestować niedostępny adres URL PAC, sprawdzić faktycznie stosowaną zarządzaną konfigurację proxy i kontrolować bezpośredni dostęp do Internetu przez zaporę. Następnie przywrócić prawidłowy adres URL PAC.

Testowanie Direct Web Proxy

Sprawdzenie listenera i zastosowania PAC

Na pilotażowym kliencie Windows przydatne są następujące kontrole tylko do odczytu:

Resolve-DnsName fw01.corp.example
Test-NetConnection fw01.corp.example -Port 3128

DNS musi zwrócić planowany adres zapory, a test TCP musi dotrzeć do listenera. Pomyślny test portu nie potwierdza jeszcze Web Policy, uwierzytelniania, deszyfrowania TLS ani połączenia internetowego.

Następnie w przeglądarce należy sprawdzić faktycznie zastosowaną politykę proxy lub PAC. Stare ustawienie lokalne, drugi profil zarządzania lub zawartość PAC w pamięci podręcznej mogą zastąpić oczekiwaną konfigurację.

Weryfikacja ruchu dozwolonego i zablokowanego

1. Otworzyć nowe prywatne okno przeglądarki.
2. Otworzyć świadomie dozwolony cel HTTP lub HTTPS.
3. Otworzyć cel świadomie blokowany przez Web_Standard_Pilot.
4. W Log viewer sprawdzić czas, źródło, użytkownika, Web Policy, działanie i Firewall Rule ID.
5. W przypadku HTTPS odnotować, czy połączenie zostało odszyfrowane, czy świadomie pozostawione bez deszyfrowania.
6. W sekcji Diagnostics > Packet capture w razie potrzeby zawęzić przechwytywanie do źródła 10.20.30.50, portu proxy i celu.
7. Przetestować aplikację bez obsługi proxy i potwierdzić, że nie jest błędnie oceniana jako ruch proxy.
8. Tymczasowo przypisać klientowi pilotażowemu kopię testową PAC z celowo nieużywanym portem proxy i sprawdzić, czy ruch internetowy zgodnie z planem nie działa zamiast omijać proxy. Następnie przywrócić produkcyjną wersję PAC.

Sukces nie oznacza jedynie, że strona się wczytała. Żądanie musi użyć oczekiwanej Rule ID i Web Policy, test blokowania musi rzeczywiście zablokować ruch, a awaria proxy musi odpowiadać wybranemu projektowi fail-closed.

Sprawdzenie, czy usługi administracyjne nie są eksponowane

Z klienta pilotażowego należy sprawdzić znane adresy HTTP i HTTPS zapory, szczególnie:

• WebAdmin
• User Portal
• VPN Portal
• Captive Portal
• inne lokalne usługi HTTP/HTTPS na używanym adresie zapory

Celem nie jest wymuszenie udanego logowania. Test określa, czy usługa w ogóle staje się osiągalna przez proxy. Jeżeli widoczna jest lokalna usługa niedozwolona w projekcie bezpieczeństwa, należy przerwać wdrożenie. Device Access nie może później zablokować dla poszczególnych portali docelowych tych żądań HTTP/HTTPS generowanych wewnętrznie przez proxy.

Oddzielenie uwierzytelniania, TLS, SD-WAN i HA

Tożsamość użytkownika jest oddzielnym elementem

Direct Web Proxy można stosować z tożsamością użytkownika lub bez niej. Użytkowników już rozpoznanych przez STAS lub inną metodę bezklientową można dopasować za pomocą Match known users. Aby aktywnie uwierzytelniać nieznanych użytkowników, reguła zazwyczaj wymaga również Use web authentication for unknown users; w Authentication > Web authentication wybiera się AD SSO lub Captive Portal. Odpowiednie usługi muszą być dozwolone dla strefy klienta w Administration > Device access. Sama konfiguracja proxy nikogo nie uwierzytelnia.

Dla RDS lub innych hostów wieloużytkownikowych, na których kilka osób współdzieli ten sam źródłowy adres IP, właściwą procedurą specjalistyczną jest Per-Connection AD SSO. Każde połączenie proxy HTTP/HTTPS jest wówczas uwierzytelniane osobno; ruch poza proxy nie otrzymuje tej tożsamości użytkownika.

Deszyfrowanie HTTPS wymaga zaufanego urzędu CA

Scan HTTP and decrypted HTTPS nie włącza deszyfrowania. W trybie proxy internetowego należy dodatkowo użyć Decrypt HTTPS during web proxy filtering. Urząd CA wdrożony na klientach musi dokładnie odpowiadać CA wybranemu w Web > General settings > HTTPS decryption and scanning.

Bezpieczne wdrożenie opisano w artykule Prawidłowe wdrażanie TLS Inspection. Artykuł Dystrybucja certyfikatu CA Sophos Firewall wyjaśnia wdrożenie i weryfikację urzędu ponownego podpisywania. Certificate Pinning, oddzielne magazyny zaufania i aplikacje o nietypowym zachowaniu TLS wymagają ukierunkowanych testów zamiast szerokiego wyjątku.

W sekcji HTTPS scanning certificate authority (CA) można pobrać publiczny certyfikat faktycznie wybranego urzędu CA proxy za pomocą ikony pobierania obok listy wyboru. Ten wybór dotyczy Web Proxy; na ścieżce DPI urząd CA określa się w Decryption profiles lub SSL/TLS inspection settings. Zaufanie klienta do urzędu Signing CA nie jest tym samym co weryfikacja oryginalnego certyfikatu serwera. Znaczenie opcji Block unrecognized SSL protocols, Block invalid certificates oraz ściśle ograniczonych wyjątków w Web > Exceptions wyjaśnia przewodnik po trybach DPI i Web Proxy.

Sprawdzanie blokad HTTPS bez zwykłego deszyfrowania

Web Policy może działać również dla celów HTTPS, które zwykle nie są deszyfrowane, wykorzystując informacje o domenie przesyłane jawnie podczas początkowego uzgadniania TLS. Zachowanie powiadomień wybiera się w Web > General settings > HTTPS decryption and scanning > Block undecrypted connections:

• Decrypt connection and show block page: SFOS deszyfruje połączenie, aby wyświetlić stronę HTML z przyczyną blokady. W przypadku stron blokady, ostrzeżenia, limitu lub błędu klient musi ufać Signing CA; w przeciwnym razie zamiast wyjaśnienia może pojawić się ostrzeżenie o certyfikacie. Nie oznacza to zwykłego deszyfrowania i sprawdzania całej dozwolonej treści HTTPS.
• Drop connection without the block page: SFOS kończy połączenie podczas uzgadniania SSL/TLS. Przeglądarka pokazuje błąd połączenia, ale nie przyczynę blokady. Nie dowodzi to awarii listenera ani WAN.

Przed zmianą zapisać poprzednią wartość: to ustawienie współdzielone, nieograniczone do klienta pilotażowego. Przez jawne proxy sprawdzić celowo blokowaną domenę HTTPS, która zwykle nie jest deszyfrowana, oraz dozwolony cel; porównać Rule ID, Web Policy, akcję i wynik przeglądarki w Log Viewer. Sprawdzić również narzędzia aktualizacyjne i inne klienty niebędące przeglądarkami pod kątem błędów certyfikatu, błędów połączenia i pętli ponownych prób. W razie pogorszenia działania przywrócić poprzednią wartość powiadomienia i powtórzyć oba żądania zamiast globalnie osłabiać Web Policy.

Jeśli potrzebne są czasowo ograniczone Policy overrides, należy zarządzać ich uprawnieniami, celami, dla których nigdy nie wolno uchylać polityki, kodami dostępu i wycofaniem niezależnie od pliku PAC. Strona blokady może wyświetlać pole kodu; Drop connection without the block page nie udostępnia takiego pola. Dopasowana reguła SSL/TLS Inspection z Action > Deny nadal blokuje ruch. Pełną procedurę, wraz z ograniczeniem dotyczącym grup podstawowych AD i ściśle ograniczonym wyjątkiem dla wyraźnie zatwierdzonego przypadku, opisano w artykule Web Protection z Policy Overrides. Obejście przez PAC z użyciem DIRECT nie jest autoryzowanym Policy Override.

Oddzielne testy SD-WAN i HA

SD-WAN Route z usługami HTTP i HTTPS nie dopasuje ruchu Direct Proxy na porcie 3128. Należy użyć faktycznego portu proxy albo świadomie Any. Source Network i Incoming Interface nie dopasowują reply packets w tym szczególnym przypadku. Ścieżka powrotna proxy wymaga ponadto co najmniej jednej bramy WAN lub odpowiedniej trasy statycznej. Pełne objaśnienie znajduje się w artykule Konfiguracja i testowanie SD-WAN Routes.

W środowisku HA nie należy obiecywać nieprzerwanej kontynuacji istniejących sesji proxy ani uwierzytelniania. Po kontrolowanym failoverze należy utworzyć nowe połączenie przeglądarki i ponownie sprawdzić plik PAC, Rule ID, politykę i deszyfrowanie. Każdy węzeł przechowuje logi ruchu, który sam przetworzył, dlatego podczas analizy istotny jest węzeł obsługujący ruch w chwili zdarzenia.

Systematyczne rozwiązywanie problemów

Port proxy jest nieosiągalny

Sprawdzić odpowiedź DNS, adres zapory, listener, strefę klienta i Web proxy w Device Access. W przypadku wyjątku ACL muszą pasować źródło, Destination host, usługa, działanie i pozycja. Pomyślny ping nie potwierdza listenera TCP; Test-NetConnection jest dokładniejszą kontrolą wstępną.

Przeglądarka łączy się bezpośrednio z Internetem

Sprawdzić efektywny adres URL PAC, treść wczytanego pliku, lokalne wyjątki przeglądarki i dodatkowe profile GPO lub MDM. Fallback DIRECT po PROXY celowo tworzy obejście, gdy proxy jest nieosiągalne. Aplikacje z własnym stosem sieciowym również mogą ignorować systemowe ustawienia proxy.

Proxy zwraca błąd 407 lub żąda poświadczeń

Jest to problem z uwierzytelnianiem, a nie błąd listenera. Sprawdzić metodę uwierzytelniania, rozpoznawanie użytkowników, import grup, obsługę przez przeglądarkę i w razie potrzeby FQDN/SPN. Nie należy zapobiegawczo rozszerzać reguły do Any tylko po to, aby usunąć monit o poświadczenia.

Witryna się wczytuje, ale Web Policy nie działa

Należy wspólnie sprawdzić regułę zapory, kolejność, źródło, usługę 3128, wybraną Web Policy i Rule ID. Pomyślne żądanie proxy mogło trafić do innej lub szerszej reguły. Kontrolowany test reguły łączy Policy Test, Log Viewer i Packet Capture.

HTTPS wyświetla błędy certyfikatu

Sprawdzić, czy deszyfrowanie jest aktywne, jakiego CA używa proxy internetowe i czy dokładnie ten CA znajduje się w magazynie zaufania klienta. Jeśli nie działają tylko pojedyncze aplikacje, należy zbadać Certificate Pinning, oddzielny magazyn zaufania, wersję TLS oraz możliwie wąski wyjątek.

Nie działa konkretna aplikacja lub port docelowy

Najpierw ustalić, czy aplikacja obsługuje jawne proxy. Następnie sprawdzić Allowed destination ports, obejścia PAC, DNS i zachowanie TLS. Niestandardowy port docelowy dodawać tylko dla konkretnej aplikacji i zatwierdzić go rzeczywistym żądaniem.

SD-WAN Route lub ścieżka WAN jest nieoczekiwana

Sprawdzić dopasowanie usługi do portu proxy, Rule ID, bramę WAN, trasę statyczną i Route Precedence. Source Network i Incoming Interface nie są wiarygodnymi kryteriami dopasowania reply packets proxy. Nie należy w pierwszej kolejności wykonywać globalnej zmiany Route Precedence.

Brakuje logów lub zawierają zbyt mało informacji

Sprawdzić Log firewall traffic w regule oraz lokalne, Central lub Syslog cele w System services > Log settings. Dla proxy internetowego istotny jest awarrenhttp.log, a dla uwierzytelniania access_server.log. Artykuł Usługi i pliki logów Sophos Firewall wyjaśnia ich klasyfikację i bezpieczne gromadzenie.

Wycofanie i eksploatacja

Wycofanie należy przygotować przed pilotażem:

1. Udokumentować poprzednie ustawienia proxy, PAC, GPO lub MDM.
2. Nadać jednoznaczne nazwy regule pilotażowej i wyjątkowi Local Service ACL.
3. Przetestować poprzednią bezpośrednią ścieżkę DPI lub zapory jako trasę awaryjną.
4. Usunąć przypisanie PAC z klienta pilotażowego lub przywrócić poprzednią wersję.
5. Całkowicie ponownie uruchomić przeglądarkę i aplikacje.
6. Wyłączyć regułę pilotażową i przetestować rzeczywisty bezpośredni przepływ internetowy trasą awaryjną.
7. Usunąć pilotażowy wyjątek ACL i przywrócić tymczasowe szerokie zezwolenia strefowe Web proxy do poprzedniego stanu.
8. Sprawdzić dane bieżące i logi oraz udokumentować moment, od którego ruch proxy nie jest już oczekiwany.

W trakcie eksploatacji plik PAC ma historię wersji, właściciela i datę przeglądu. Każdy nowy wyjątek DIRECT jest wyjątkiem od polityki i powinien być uzasadniony, przetestowany i ponownie oceniany podobnie jak wyjątek zapory lub proxy. Listener, dozwolone porty docelowe i szerokie zezwolenia strefowe również powinny podlegać regularnym przeglądom.

Lista kontrolna

• Direct Proxy jest właściwym modelem dla objętych nim przeglądarek i aplikacji.
• Klient pilotażowy IPv4 i stały źródłowy adres IP są udokumentowane.
• FQDN proxy, adres URL PAC i certyfikaty są prawidłowo rozwiązywane.
• Listener i dozwolone porty docelowe są możliwie ograniczone.
• Szerokie zezwolenie strefowe proxy internetowego zostało sprawdzone i w razie potrzeby zastąpione.
• Wyjątek Local Service ACL ogranicza źródło i docelowy adres zapory.
• Reguła zapory wykorzystuje port proxy, logowanie i oczekiwaną Web Policy.
• Dopasowanie użytkowników i uwierzytelnianie internetowe skonfigurowano oddzielnie i pomyślnie przetestowano.
• Plik PAC zawiera tylko uzasadnione wewnętrzne wyjątki DIRECT.
• Internetowy fallback omijający proxy nie jest aktywny bez wiedzy administratora.
• Bezpośredni egress, w tym QUIC, jest świadomie blokowany lub kontrolowany poza regułą TCP 3128.
• Rzeczywisty ruch dozwolony i blokowany trafia do oczekiwanej Rule ID.
• Lokalne usługi HTTP/HTTPS zapory zostały poddane testom negatywnym.
• Uwierzytelnianie, deszyfrowanie TLS, QUIC i aplikacje poza proxy oceniono oddzielnie.
• Zachowanie SD-WAN i HA przetestowano, jeśli te funkcje są używane.
• Wycofanie, właściciel, wersjonowanie i data przeglądu są udokumentowane.

Często zadawane pytania