Saltar para o conteudo
Avanet

Configurar Direct Web Proxy na Sophos Firewall com ficheiro PAC

Sophos Firewall

Com o Direct Web Proxy, os browsers e as aplicações compatíveis com proxy enviam deliberadamente as suas ligações HTTP e HTTPS para a Sophos Firewall. Este funcionamento é diferente do proxy web transparente e do DPI Engine: o cliente conhece o destino do proxy e liga-se normalmente à porta TCP 3128.

O Direct Web Proxy é útil quando o tráfego web deve ser controlado centralmente através de um ficheiro PAC, autenticado por utilizador ou processado com funcionalidades que exigem o proxy web. No entanto, não é um caminho geral para a Internet para todas as aplicações. Apenas o tráfego que utiliza efetivamente a configuração de proxy segue este caminho.

⚠️ Um cliente com acesso ao proxy web pode alcançar por este caminho serviços HTTP e HTTPS locais da firewall, mesmo que WebAdmin, User Portal ou VPN Portal não estejam ativados para a respetiva zona em Device access. Por isso, o proxy é inicialmente aberto apenas para um cliente-piloto e estes destinos de gestão são testados negativamente de forma explícita.

Este procedimento abrange um cliente-piloto IPv4 gerido. Para clientes só IPv6, configurar NAT64 com Direct Web Proxy explica a regra IPv6 separada para o proxy e a regra IPv4 para o destino A-only.

Direct Web Proxy em dez passos

  1. Definir um cliente-piloto gerido, o seu IP fixo e os destinos web necessários.
  2. Documentar o FQDN do proxy, DNS, porta de escuta e dependências de proxy existentes.
  3. Em Web > General settings, verificar Web proxy listening port e as portas de destino permitidas.
  4. Em Administration > Device access, permitir o serviço Web proxy apenas para o piloto e para o endereço previsto da firewall.
  5. Criar uma regra de firewall dedicada e com registo, com o piloto como origem, WAN como destino, serviço TCP 3128 e a Web Policy pretendida.
  6. Preparar um ficheiro PAC com destinos internos DIRECT deliberados e sem fallback de Internet que contorne o proxy.
  7. Distribuir o URL PAC apenas ao cliente-piloto e verificar a configuração de proxy efetivamente carregada.
  8. Testar um pedido HTTP/HTTPS permitido e outro bloqueado e verificar a Firewall Rule ID esperada.
  9. Testar negativamente os portais locais da firewall, a desencriptação TLS, as aplicações sem suporte de proxy e uma falha do proxy.
  10. Só depois adicionar mais clientes geridos e documentar o rollback, o responsável e a data de revisão.

Direct Web Proxy, proxy transparente ou DPI?

Os três termos descrevem caminhos de tráfego diferentes:

  • Direct Web Proxy: O cliente está configurado explicitamente para a firewall e a respetiva porta de proxy. O browser, o sistema operativo ou a aplicação envia o pedido para fw01.corp.example:3128.
  • Proxy web transparente: O cliente não tem conhecimento do proxy. Quando o serviço está ativo para a sua zona, a firewall interceta transparentemente HTTP na porta 80 e HTTPS na porta 443.
  • DPI Engine: A firewall processa tráfego encaminhado sem exigir um proxy web clássico e pode inspecionar HTTP ou TLS noutras portas de acordo com as regras de firewall e de SSL/TLS inspection.

A opção Use web proxy instead of DPI engine numa regra de firewall não é um requisito para que um cliente configurado explicitamente utilize o Direct Web Proxy. O caminho do cliente resulta da configuração de proxy. A opção determina se a regra utiliza o proxy web em vez do DPI Engine para filtrar o tráfego web normal nas portas habituais.

A escolha completa do modo, incluindo funções exclusivas do proxy, configuração TLS e migração controlada de regras, está em Escolher corretamente entre DPI Engine e Web Proxy.

A Sophos continua a indicar funcionalidades específicas que exigem Proxy Mode, incluindo SafeSearch, YouTube Restrictions, restrições de domínio do Google Workspace, Pharming Protection, Web Cache ou um Parent Proxy. Web Protection na Sophos Firewall explica a decisão de política e proteção.

Quando a Sophos Firewall tem de enviar Web Requests para outra instância proxy, configurar um upstream proxy em WAN ou LAN/DMZ explica o caminho separado de regras, NAT e validação.

O Direct Web Proxy também altera a forma como o tráfego é observado. O cliente liga-se primeiro à firewall e esta cria depois a ligação ao destino. Por isso, a Sophos documenta dois limites importantes:

  • Uma IPS Policy aplica-se entre o proxy e a WAN, não entre o utilizador e o proxy.
  • Uma Traffic Shaping Policy não se aplica ao tráfego Direct Proxy.

Se uma aplicação não conseguir trabalhar com um proxy explícito, não se deve esperar que um ficheiro PAC capture as suas ligações. Essa aplicação continua a necessitar de um caminho normal encaminhado por DPI, firewall ou proxy separado.

Exemplo e valores substituíveis

O artigo utiliza um pequeno piloto:

  • Cliente-piloto: CLIENT-PROXY-01
  • IP fixo do cliente: 10.20.30.50
  • zona do cliente: LAN
  • FQDN da firewall e destino do proxy: fw01.corp.example
  • porta do Direct Web Proxy: 3128
  • URL PAC: https://config.corp.example/proxy.pac
  • zona DNS interna: .corp.example
  • regra de firewall: LAN_DirectProxy_Pilot
  • Web Policy: Web_Standard_Pilot

Substitui-se 10.20.30.50 pelo IP fixo que a firewall vê efetivamente como origem do piloto. O DHCP deve fornecer uma reserva para esse endereço. Não pode existir NAT atrás do endereço que oculte outros dispositivos.

fw01.corp.example e config.corp.example são nomes de documentação. Devem ser substituídos por FQDN resolvíveis internamente e abrangidos pelos certificados adequados. O FQDN do proxy aponta para o endereço LAN ou de gestão previsto da firewall. O URL PAC aponta para um servidor web interno controlado ou para um caminho existente de gestão de endpoints, não para uma localização pública arbitrária.

A porta 3128 é a predefinição do Direct Web Proxy. Se for utilizada outra Web proxy listening port, Device Access, a regra de firewall, o ficheiro PAC, o browser, a SD-WAN Route e os testes devem conter a mesma porta. O nome da regra ou da política pode ser escolhido livremente, mas deve indicar claramente a finalidade, a origem e o estado de piloto.

Preparar o acesso ao proxy e a regra de proteção

Definir o listener e as portas de destino permitidas

Verificam-se os fundamentos do proxy em Web > General settings > Web proxy configuration:

  1. Web proxy listening port: 3128 neste exemplo.
  2. Allowed destination ports: apenas as portas às quais os clientes precisam realmente de se ligar através do proxy.
  3. Minimum TLS version: versão mínima comum ao proxy web e ao Captive Portal; uma alteração afeta ambas as funções.

As portas de destino permitidas não são o listener. O cliente liga-se à porta 3128 da firewall, mas pode utilizar HTTP CONNECT para solicitar, por exemplo, um destino externo na porta 443. Só se adicionam portas de destino não padrão após um teste específico da aplicação. Uma lista ampla transforma desnecessariamente o proxy num túnel genérico.

Antes de alterar a porta, devem ser pesquisados ficheiros PAC, GPO, políticas de browser, hosts RDS, SD-WAN Routes e monitorização existentes. O listener é uma definição partilhada, não um valor a alterar apenas para um piloto.

Limitar o Device Access ao piloto

O serviço Web proxy está ativado de fábrica para LAN e Wi-Fi. Uma exceção Accept adicional não restringe uma permissão ampla de zona que já esteja ativa. Para um verdadeiro acesso-piloto, a permissão ampla deve permanecer desativada ou ser primeiro substituída de forma controlada por exceções mais restritas.

Em Administration > Device access > Local service ACL exception rule > Add:

  1. Rule name: Allow_DirectProxy_Pilot
  2. Rule position: acima de uma exceção Drop correspondente
  3. IP version: IPv4
  4. Source zone: LAN
  5. Source Network / Host: CLIENT-PROXY-01 com 10.20.30.50
  6. Destination host: endereço específico da firewall para o qual fw01.corp.example resolve
  7. Services: Web proxy
  8. Action: Accept

Antes de desativar uma permissão ampla de zona, verifica-se se outros clientes ou serviços já utilizam o proxy direto ou transparente. O guia de Device Access e Local Service ACL explica em detalhe a ordem das regras, a matriz de zonas e as regras de exceção.

Ligar a Web Policy à regra de firewall

A Web Policy é preparada em Web > Policies. Contém as categorias, URL Groups, regras de utilizador ou grupo e ações pretendidas. Para o piloto, deve ser definido pelo menos um destino deliberadamente permitido e outro deliberadamente bloqueado.

Em seguida, cria-se uma regra IPv4 dedicada em Rules and policies > Firewall rules:

  • Rule name: LAN_DirectProxy_Pilot
  • Action: Accept
  • Log firewall traffic: ativado
  • Source zones: LAN
  • Source networks and devices: CLIENT-PROXY-01
  • Destination zones: WAN
  • Destination networks: Any ou um grupo de destinos planeado de forma mais restrita
  • Services: serviço TCP dedicado para 3128
  • Match known users: ativar apenas se o caminho de autenticação escolhido já tiver passado num teste positivo
  • Web filtering > Web policy: Web_Standard_Pilot
  • Block QUIC protocol: ativar se o tráfego web não puder contornar em paralelo a inspeção do proxy através de UDP 443; Controlar QUIC na Sophos Firewall explica o contexto
  • Scan HTTP and decrypted HTTPS: apenas com a licença adequada e um modelo de inspeção deliberado

Segundo a Sophos, Any também é possível como serviço para Direct Proxy, mas é mais amplo do que o necessário. Um serviço TCP dedicado ao listener efetivo torna o piloto mais compreensível. Depois de selecionar uma Web Policy e outras funcionalidades de proteção, verifica-se novamente toda a regra. Os fundamentos das regras de firewall explicam a ordem, o registo, a correspondência de utilizadores e os campos de proteção.

Um Linked NAT não é automaticamente necessário para este piloto. No entanto, o caminho de Internet criado pela firewall precisa de um gateway WAN adequado e da tradução de origem válida para o ambiente. O routing e o NAT são verificados separadamente.

Criar e distribuir o ficheiro PAC

Um exemplo PAC deliberadamente restrito

Um ficheiro PAC é JavaScript com a função FindProxyForURL. Este exemplo deixa passar diretamente apenas nomes internos curtos, a zona DNS interna e as redes privadas indicadas. Todos os outros destinos têm de utilizar o 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";
}

Adaptam-se .corp.example, as redes privadas e o FQDN do proxy ao próprio ambiente. Nem todas as redes RFC1918 precisam de ser alcançáveis internamente. Uma lista dos domínios e redes internos realmente necessários é mais clara.

O exemplo não chama deliberadamente dnsResolve() para nomes de host públicos. Estas funções PAC provocam resoluções DNS adicionais no cliente e podem atrasar o processamento; neste caso, o proxy resolve os nomes externos. Os nomes internos são classificados através das regras de domínio ou, quando o pedido contém diretamente um endereço IPv4, através de isInNet(). Se um ambiente exigir exceções mais complexas dependentes de DNS, estas são planeadas individualmente e testadas com os browsers utilizados.

O exemplo não contém deliberadamente DIRECT após a instrução do proxy. Um valor devolvido como PROXY fw01.corp.example:3128; DIRECT permite que o tráfego de Internet continue diretamente quando o proxy falha. Isto aumenta a disponibilidade, mas contorna a Web Policy, a autenticação do proxy e o registo do proxy. Não recomendamos este fallback fail-open para um caminho de segurança obrigatório.

As exceções internas DIRECT também são bypasses. Só são adicionadas quando o destino precisa realmente de ser alcançado diretamente e existe outro caminho de controlo. Domínios SaaS sensíveis, fornecedores de identidade ou wildcards gerais não devem ser adicionados preventivamente à lista de bypass.

Distribuir o ficheiro PAC de forma controlada

  1. Alojar o ficheiro PAC num endpoint HTTPS interno com um certificado fidedigno.
  2. Garantir que https://config.corp.example/proxy.pac pode ser obtido sem um proxy já funcional.
  3. Atribuir o URL PAC apenas ao piloto através de GPO, MDM ou uma política de browser gerida.
  4. Documentar previamente uma configuração manual de proxy existente e outras definições PAC ou WPAD.
  5. Reiniciar totalmente o browser e as aplicações afetadas.
  6. Verificar qual URL PAC foi efetivamente carregado na política do browser ou do sistema operativo.
  7. Bloquear de forma controlada o acesso direto à Internet fora do caminho do proxy para o piloto ou, pelo menos, testá-lo como bypass.

A deteção automática WPAD não é necessária para este procedimento. Um URL PAC explícito e gerido é mais fácil de identificar e reverter. Neste modelo, o SFOS fornece o listener; a distribuição, alojamento e controlo de versões do ficheiro PAC continuam a ser tarefas da gestão de clientes e do servidor web.

Testar o Direct Web Proxy

Verificar o listener e a aplicação do PAC

Estas verificações apenas de leitura são úteis num cliente-piloto Windows:

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

O DNS tem de devolver o endereço previsto da firewall e o teste TCP tem de alcançar o listener. Um teste de porta bem-sucedido ainda não comprova a Web Policy, a autenticação, a desencriptação TLS ou a ligação à Internet.

Em seguida, verifica-se no browser a política de proxy ou PAC efetivamente aplicada. Uma definição local antiga, um segundo perfil de gestão ou conteúdo PAC em cache pode substituir a configuração esperada.

Validar o tráfego permitido e bloqueado

  1. Abrir uma nova janela privada do browser.
  2. Abrir um destino HTTP ou HTTPS deliberadamente permitido.
  3. Abrir um destino deliberadamente bloqueado por Web_Standard_Pilot.
  4. No Log viewer, verificar a hora, origem, utilizador, Web Policy, ação e Firewall Rule ID.
  5. Para HTTPS, registar se a ligação foi desencriptada ou deliberadamente deixada sem desencriptação.
  6. Em Diagnostics > Packet capture, restringir a captura à origem 10.20.30.50, porta do proxy e destino, se necessário.
  7. Testar uma aplicação sem suporte de proxy e confirmar que não é avaliada incorretamente como tráfego de proxy.
  8. Atribuir temporariamente ao cliente-piloto uma cópia PAC de teste com uma porta de proxy deliberadamente não utilizada e verificar se o tráfego de Internet falha como planeado em vez de contornar o proxy. Depois, restaurar a versão PAC de produção.

O sucesso não significa apenas que um website abre. O pedido tem de utilizar a Rule ID e a Web Policy esperadas, o teste de bloqueio tem de bloquear realmente e uma falha do proxy tem de corresponder ao modelo fail-closed escolhido.

Verificar se os serviços de gestão ficam expostos

A partir do cliente-piloto, testam-se os endereços HTTP e HTTPS conhecidos da firewall, em especial:

  • WebAdmin
  • User Portal
  • VPN Portal
  • Captive Portal
  • outros serviços HTTP/HTTPS locais no endereço da firewall utilizado

O objetivo não é forçar um início de sessão bem-sucedido. O teste determina se o serviço fica acessível através do proxy. Se um serviço local não permitido pelo modelo de segurança estiver visível, deve interromper-se o rollout. O Device Access não consegue bloquear posteriormente, por portal de destino, estes pedidos HTTP/HTTPS gerados internamente pelo proxy.

Separar autenticação, TLS, SD-WAN e HA

A identidade do utilizador é um componente separado

O Direct Web Proxy pode ser utilizado com ou sem identidade do utilizador. Dependendo do ambiente, os clientes normais podem utilizar AD SSO, STAS, Captive Portal ou outro método suportado. A configuração do proxy, por si só, não autentica ninguém.

Para RDS ou outros hosts multiutilizador nos quais várias pessoas partilham o mesmo IP de origem, Per-Connection AD SSO é o procedimento especializado adequado. Cada ligação de proxy HTTP/HTTPS é autenticada separadamente; o tráfego fora do proxy não recebe esta identidade do utilizador.

A desencriptação HTTPS exige uma CA fidedigna

Scan HTTP and decrypted HTTPS não ativa a desencriptação. No modo de proxy web, também se utiliza Decrypt HTTPS during web proxy filtering. A CA distribuída aos clientes tem de corresponder exatamente à CA selecionada em Web > General settings > HTTPS decryption and scanning.

O rollout seguro é descrito em Implementar corretamente TLS Inspection. Distribuir o certificado CA da Sophos Firewall explica a distribuição e verificação da CA de nova assinatura. Certificate Pinning, trust stores próprios e aplicações com comportamento TLS invulgar exigem testes específicos em vez de uma exceção ampla.

Testar SD-WAN e HA separadamente

Uma SD-WAN Route com os serviços HTTP e HTTPS não corresponde ao tráfego Direct Proxy em 3128. Utiliza-se a porta efetiva do proxy ou, deliberadamente, Any. Source Network e Incoming Interface não correspondem aos reply packets neste caso especial. O caminho de retorno do proxy também precisa de pelo menos um gateway WAN ou uma rota estática adequada. A explicação completa encontra-se em Configurar e testar SD-WAN Routes.

Em HA não se deve prometer a continuação sem interrupções das sessões de proxy ou autenticação existentes. Após um failover controlado, cria-se uma nova ligação do browser e verificam-se novamente o ficheiro PAC, a Rule ID, a política e a desencriptação. Cada nó armazena os registos do tráfego que processou, pelo que a análise deve considerar o nó que processava o tráfego no momento do evento.

Resolver problemas de forma sistemática

A porta do proxy não está acessível

Verificar a resposta DNS, o endereço da firewall, o listener, a zona do cliente e Web proxy em Device Access. Numa exceção ACL, a origem, Destination host, serviço, ação e posição têm de corresponder. Um ping bem-sucedido não comprova o listener TCP; Test-NetConnection é a verificação preliminar mais específica.

O browser acede diretamente à Internet

Verificar o URL PAC efetivo, o conteúdo do ficheiro carregado, as exceções locais do browser e outros perfis GPO ou MDM. Um fallback DIRECT após PROXY cria deliberadamente um bypass quando o proxy não está acessível. As aplicações com uma stack de rede própria também podem ignorar as definições de proxy do sistema.

O proxy devolve o erro 407 ou pede credenciais

Trata-se de um problema de autenticação, não de uma falha do listener. Verificar o método de autenticação, a deteção de utilizadores, a importação de grupos, o suporte do browser e, quando aplicável, FQDN/SPN. A regra não deve ser alargada preventivamente para Any apenas para evitar o pedido de credenciais.

O website abre, mas a Web Policy não se aplica

Verificar em conjunto a regra de firewall, a ordem, a origem, o serviço 3128, a Web Policy selecionada e a Rule ID. Um pedido de proxy bem-sucedido pode ter correspondido a outra regra ou a uma regra mais ampla. O teste controlado de regras combina Policy Test, Log Viewer e Packet Capture.

HTTPS apresenta erros de certificado

Verificar se a desencriptação está ativa, qual CA o proxy web utiliza e se essa CA exata está no trust store do cliente. Se apenas aplicações específicas falharem, analisar Certificate Pinning, um trust store próprio, a versão TLS e uma exceção tão restrita quanto possível.

Uma aplicação ou porta de destino específica não funciona

Primeiro, determinar se a aplicação suporta um proxy explícito. Depois, verificar Allowed destination ports, bypasses PAC, DNS e comportamento TLS. Adicionar uma porta de destino não padrão apenas para a aplicação específica e validá-la com um pedido real.

A SD-WAN Route ou o caminho WAN é inesperado

Verificar a correspondência do serviço com a porta do proxy, a Rule ID, o gateway WAN, a rota estática e Route Precedence. Source Network e Incoming Interface não são critérios de correspondência fiáveis para reply packets do proxy. Não se deve alterar globalmente Route Precedence como primeira medida.

Faltam registos ou mostram pouca informação

Verificar Log firewall traffic na regra e os destinos locais, Central ou Syslog em System services > Log settings. awarrenhttp.log é relevante para o proxy web e access_server.log para a autenticação. Serviços e ficheiros de registo da Sophos Firewall explica a classificação e a recolha segura.

Rollback e operação

O rollback é preparado antes do piloto:

  1. Documentar a definição anterior de proxy, PAC, GPO ou MDM.
  2. Atribuir nomes inequívocos à regra-piloto e à exceção Local Service ACL.
  3. Testar o caminho direto DPI ou de firewall anterior como via de retorno.
  4. Remover a atribuição PAC do cliente-piloto ou restaurar a versão anterior.
  5. Reiniciar totalmente o browser e as aplicações.
  6. Desativar a regra-piloto e testar um fluxo web direto real através da via de retorno.
  7. Remover a exceção ACL do piloto e repor as permissões temporárias amplas da zona Web proxy no estado anterior.
  8. Verificar dados live e de registo e documentar a partir de que momento já não se espera tráfego de proxy.

Em operação, o ficheiro PAC tem um histórico de versões, um responsável e uma data de revisão. Cada nova exceção DIRECT é uma exceção de política e deve ser justificada, testada e novamente revista tal como uma exceção de firewall ou web. O listener, as portas de destino permitidas e as permissões amplas de zona também fazem parte da revisão regular.

Lista de verificação

  • Direct Proxy é o modelo adequado para os browsers e aplicações afetados.
  • O cliente-piloto IPv4 e o IP de origem fixo estão documentados.
  • O FQDN do proxy, o URL PAC e os certificados resolvem corretamente.
  • O listener e as portas de destino permitidas são tão restritos quanto possível.
  • A permissão ampla da zona do proxy web foi verificada e substituída quando necessário.
  • A exceção Local Service ACL limita a origem e o endereço de destino da firewall.
  • A regra de firewall utiliza a porta do proxy, registo e a Web Policy esperada.
  • O ficheiro PAC contém apenas exceções internas DIRECT justificadas.
  • Não está ativo inadvertidamente um fallback de Internet que contorne o proxy.
  • O tráfego real permitido e bloqueado corresponde à Rule ID esperada.
  • Os serviços HTTP/HTTPS locais da firewall foram testados negativamente.
  • Autenticação, desencriptação TLS, QUIC e aplicações sem proxy foram avaliados separadamente.
  • O comportamento de SD-WAN e HA foi testado quando estas funções são utilizadas.
  • Rollback, responsável, controlo de versões e data de revisão estão documentados.

Perguntas frequentes

É necessário ativar Use web proxy instead of DPI engine para o Direct Web Proxy?

Não. Um cliente configurado explicitamente utiliza o Direct Web Proxy através do listener definido mesmo sem esta opção. A opção controla se uma regra de firewall filtra o tráfego web normal nas portas habituais com o proxy web em vez do DPI Engine.

O ficheiro PAC deve utilizar DIRECT como fallback quando o proxy falha?

Normalmente não para um caminho de segurança obrigatório. PROXY ...; DIRECT mantém o acesso à Internet, mas contorna a Web Policy, a autenticação do proxy e o registo do proxy quando este falha. Os destinos internos podem permanecer deliberadamente diretos; um fallback de Internet exige uma decisão de risco documentada.

Porque é necessária uma exceção Local Service ACL além da regra de firewall?

O listener do proxy é um serviço local da firewall e é controlado através de Device Access ou Local Service ACL. A regra de firewall define depois o fluxo de tráfego permitido e a Web Policy. As duas camadas resolvem tarefas diferentes.

O Direct Web Proxy consegue controlar todas as aplicações?

Não. Apenas captura ligações HTTP e HTTPS de clientes e aplicações que utilizam o proxy explícito. DNS, UDP, RDP, SMB e aplicações com uma stack de rede própria ou sem capacidade de proxy precisam de outro caminho controlado.