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.

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.

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.

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
• Web filtering > Web policy: Web_Standard_Pilot
• Block QUIC protocol: włączyć, jeśli ruch internetowy nie może równolegle omijać inspekcji proxy przez UDP 443; artykuł Kontrolowanie QUIC na Sophos Firewall objaśnia ten mechanizm
• 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.

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.

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) || 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, sieci prywatne i FQDN proxy do własnego środowiska. 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.

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. W zależności od środowiska zwykli klienci mogą korzystać z AD SSO, STAS, Captive Portal lub innej obsługiwanej metody. 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.

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.
• Plik PAC zawiera tylko uzasadnione wewnętrzne wyjątki DIRECT.
• Internetowy fallback omijający proxy nie jest aktywny bez wiedzy administratora.
• 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