Criar e testar Web Exceptions do Sophos Firewall com segurança

Uma Web Exception é criada rapidamente, mas o seu efeito pode ser muito maior do que o esperado. Conforme a seleção, o Sophos Firewall ignora não só a desencriptação HTTPS, mas também a validação de certificados, a análise de malware e conteúdo, a análise Zero-Day ou todos os controlos da Web Policy.

A sequência segura consiste, por isso, em identificar primeiro o fluxo afetado e o controlo que realmente causa o problema, depois restringir a correspondência e só então ativar a exceção mínima necessária. Um teste positivo isolado não basta. No teste negativo, um destino semelhante não excluído deve continuar a ser verificado normalmente.

Este guia aplica-se ao SFOS 22.0. As etiquetas do WebAdmin permanecem deliberadamente em inglês para que possam ser encontradas diretamente na interface.

Web Exception em sete passos

1. Documentar o cliente afetado, host de destino, caminho URL, protocolo e hora.
2. Verificar se está a ser utilizado DPI Mode ou Web Proxy Mode e que regra de firewall e Web Policy se aplicam realmente.
3. Decidir se o problema é apenas a desencriptação TLS ou um controlo específico de Web Protection.
4. Em Web > Exceptions > Add an exception, definir critérios restritos de URL, categoria, origem ou destino.
5. Em Skip the selected checks or actions, selecionar apenas a opção mínima necessária.
6. Ativar a exceção e voltar a testar o mesmo fluxo com um novo processo do browser ou da aplicação.
7. Executar um teste negativo contra um destino semelhante não excluído e documentar correspondência, efeito, responsável e data de revisão.

⚠️ HTTPS decryption não é uma opção de compatibilidade inofensiva. Para o tráfego correspondente, também deixam de existir os controlos dependentes e a firewall permite certificados de servidor inválidos. Malware and content scanning ignora automaticamente também a análise Zero-Day. Por isso, uma exceção abrangente não deve ser o primeiro passo de troubleshooting.

Verificar os pré-requisitos do produto antes de escolher uma exceção

Para alguns produtos geridos, as permissões de portas e domínios são pré-requisitos da função em causa. Antes de escolher uma regra de firewall, TLS Exclusion ou Web Exception, confirmar com o responsável pelo produto a função, versão e caminho real da ligação. Registar no pedido de alteração os destinos, portas, protocolos, direções e exclusões de inspeção expressamente necessários, em vez de conceder acesso geral a todos os produtos Sophos.

• Wireless: A verificação prévia Wireless separa a rede de gestão, DNS, o serviço de hora e os destinos regionais da posterior configuração Wi-Fi.
• ZTNA: Identificar primeiro a implementação local ou na cloud no guia do gateway ZTNA; as direções de ligação e os requisitos de inspeção não são intercambiáveis.
• Registo de switches: A integração de switches cobre DNS, destinos de registo e verificações do caminho proxy/TLS.
• Endpoint, XDR e MDR: Os requisitos de rede e proxy distinguem plataformas, funções licenciadas e destinos específicos da instalação. Uma lista de domínios permitidos não é uma lista geral de exclusões de desencriptação.
• NDR e appliances de integração: O planeamento do appliance cobre requisitos de portas e domínios de saída; o procedimento operacional ajuda a verificar separadamente as funções NDR e Log Collector realmente alojadas.

O guia interno é um ponto de partida; antes da alteração, o responsável pelo produto deve confirmar os requisitos oficiais para a implementação concreta. A acessibilidade de rede e a omissão de inspeção continuam a ser decisões distintas. Se faltarem requisitos verificados ou as fontes se contradisserem, não alargar a exceção por tentativa: guardar as provas e esclarecer com os responsáveis pelo produto e pela firewall. Depois continuam a aplicar-se o piloto, os testes positivos e negativos, a revisão e o rollback deste guia.

Escolher Web Exception ou TLS Exclusion

Ambas as ferramentas podem impedir que o tráfego HTTPS seja desencriptado, mas não resolvem a mesma tarefa.

Uma SSL/TLS inspection rule com Action: Don’t decrypt é adequada quando, em DPI Mode, só se pretende excluir a desencriptação para destinos claramente identificados. Um URL Group na Local TLS exclusion list é especialmente eficiente porque a firewall compara como texto o Server Name Indication, ou SNI.

Criar e utilizar URL Groups de forma segura mostra como criar uma lista de domínios deste tipo, integrá-la numa regra Don't decrypt e testá-la com um destino negativo.

Uma Web Exception é adequada quando, adicionalmente ou em alternativa, se pretende ignorar um controlo de Web Protection:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

Em DPI Mode, uma Web Exception só se aplica se estiver ativa para o fluxo pelo menos uma Web Policy, Malware and content scanning ou ATP. Em Web Proxy Mode, a Web Exception pertence diretamente ao caminho de Web Protection baseado no proxy.

A SSL/TLS exclusion list utiliza nomes de domínio em texto simples e inclui os respetivos subdomínios, em vez de expressões regulares. As exclusões SSL/TLS podem ignorar os requisitos de certificados e protocolos, além da desencriptação. Por isso, não equivalem a uma Web Exception limitada a HTTPS certificate validation. Os domínios confirmados podem ser adicionados à Local TLS exclusion list no Control Center ou Log Viewer; em alternativa, edita-se o URL Group em Web > URL groups ou a SSL/TLS inspection rule. As categorias web também podem ser critérios de uma SSL/TLS inspection rule.

O tráfego abrangido também difere: em DPI Mode, as Web Exceptions aplicam-se a ligações SSL/TLS em qualquer porta; em Web Proxy Mode, aplicam-se a SSL/TLS na porta 443. As SSL/TLS Exclusion Rules só se aplicam em DPI Mode, mas também são independentes da porta. Além de URL Groups, podem utilizar como critérios zonas, redes, endereços IP, serviços, utilizadores e grupos. As Web Exceptions oferecem padrões URL, Web categories e endereços ou intervalos IP de origem e destino.

Uma Web Exception ativa pode ignorar os controlos de proteção selecionados para os fluxos web correspondentes; isto não garante que qualquer bloqueio do sistema possa ser removido. Por isso, o seu âmbito não pode ser protegido colocando uma regra de Web Policy mais abaixo na ordem. Os critérios da própria exceção são decisivos; a ordem das regras de firewall, Web e SSL/TLS deve, ainda assim, ser verificada separadamente, porque determina que caminho de proteção processa inicialmente o fluxo.

Limite documentado e contradição por resolver: A Sophos descreve geralmente as exceções como independentes das policies e regras. Porém, o guia de categorias do SFOS 22.0 e 23.0 identifica expressamente highly objectionable criminal activity como sempre bloqueada: nenhuma policy ou exceção pode permitir estas páginas, e os nomes de domínio são ocultados intencionalmente em logs e relatórios. Estas afirmações divergentes não comprovam um bypass funcional. A abordagem segura continua a ser não contornar este bloqueio e, se necessário, esclarecer a contradição com o Sophos Support. Usar apenas destinos inofensivos e aprovados nos testes, nunca conteúdos proibidos.

A implementação planeada de DPI ou Web Proxy, Decryption Rules e distribuição da CA está em Implementar corretamente TLS Inspection. A lógica de filtragem é explicada em Configurar Web Protection com Web Policies.

Planear uma correspondência restrita e rastreável

Uma exceção não deve começar por um domínio arbitrário do fornecedor. Primeiro regista-se o request concreto no browser, no Log Viewer ou nos logs da aplicação. Depois decide-se se hostname, caminho, categoria, IP de origem ou IP de destino é o critério mais estável.

AND entre tipos, OR dentro de um tipo

O Sophos Firewall associa diferentes tipos de critérios com AND. Se forem definidos, por exemplo, padrões de URL e Source IP addresses, ambos os tipos têm de corresponder.

Vários valores dentro do mesmo tipo são avaliados com OR. Dois padrões de URL significam, portanto, que qualquer um pode ser suficiente. Dois Source IP addresses significam que qualquer uma das origens pode ser suficiente.

Esta lógica é importante no troubleshooting. Uma exceção pode parecer correta e ainda assim não se aplicar porque um tipo de critério adicional não corresponde ao fluxo real.

Ancorar a expressão regular com segurança

Em URL pattern matches são permitidas expressões regulares. Um padrão isolado como vendor.example não é adequado. Pode corresponder ao texto numa posição inesperada do URL e excluir demasiados pedidos.

Para o domínio de exemplo reservado updates.vendor.example, um padrão de host deliberadamente ancorado pode ter este aspeto:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

O valor é apenas um exemplo. vendor.example é um domínio reservado para documentação e deve ser substituído pelo host de destino real confirmado no log ou no request. O prefixo opcional permite subdomínios. Se apenas um host exato tiver de ser excluído, não se utiliza um wildcard de subdomínio desnecessário.

Os carateres não ASCII são indicados no padrão como Punycode. Depois de cada alteração da regex, o teste inclui uma correspondência esperada e pelo menos uma não correspondência deliberadamente semelhante.

Verificar pontos, limite do host e correspondências indesejadas no caminho

Numa regex, um ponto sem escape representa qualquer caráter. Por isso, os pontos de um nome de host fixo escrevem-se como \.. O ^ ancora a correspondência no início; o / final delimita o host face a nomes com um início semelhante, como updates.vendor.example.attacker.example. O Sophos Firewall aceita / e \/. Para um único host exato, o padrão mais restrito é:

^updates\.vendor\.example/

Os exemplos referem-se à representação de host/URL à qual estes padrões Sophos são aplicados, sem https:// no início. A ferramenta de teste deve utilizar a mesma representação. Se as portas ou a representação forem diferentes, não acrescentar .* por tentativa: esclarecer o valor efetivamente avaliado e o caminho de proteção. O limite HTTPS da secção seguinte mantém-se.

Para o padrão de host exato esperam-se os resultados seguintes. Com o padrão existente de subdomínio opcional, cdn.updates.vendor.example/file também é uma correspondência pretendida; os restantes casos negativos continuam sem corresponder.

Os dois últimos casos são particularmente importantes: a comparação pode abranger todo o URL, incluindo caminho e parâmetros de consulta. Um texto de domínio não ancorado pode, assim, acionar a exceção noutro host. O teste verifica apenas a correspondência; a omissão efetiva dos controlos de proteção é verificada mais tarde com um novo pedido e logs.

Testar localmente entradas longas sem correspondência

Muitos padrões não ancorados podem exigir trabalho de pesquisa adicional, sobretudo quando a desencriptação HTTPS disponibiliza o texto completo do URL. Daí não se pode deduzir um número universal de passos nem um tempo de execução sempre constante, linear ou exponencial para todos os padrões. A ancoragem também não substitui a verificação de quantificadores complexos. Não utilizar um wildcard genérico .* para nomes de host.

Um teste de 1000 carateres complementa os casos curtos. Num computador local de administração com Python 3, este exemplo gera um texto de URL inteiramente fictício, com um caminho longo e o domínio de destino apenas nos parâmetros de consulta. Testa ambos os padrões aqui apresentados sem contactar uma firewall:

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Esperam-se dois resultados sem correspondência. Outros casos sintéticos devem abranger nomes de host longos quase correspondentes e caminhos longos; comparar os padrões anteriores e posteriores com as mesmas entradas. Para padrões complexos suspeitos, utilizar uma ferramenta local com limite de tempo e interromper um teste bloqueado. Os tempos de Python e os contadores de passos de outros motores regex não são medições SFOS nem promessas de desempenho. Não copiar URLs de produção, tokens, nomes de utilizador ou dados de clientes para sites externos de testes regex; dados fictícios são suficientes.

Distinguir hostname e caminho URL

As exceções para HTTPS decryption e HTTPS certificate validation podem avaliar o hostname a partir do contexto TLS. Um padrão que apenas aponta para um caminho URL, por outro lado, só funciona em HTTPS quando a ligação já está a ser desencriptada. Em HTTP não encriptado, o caminho URL é visível sem desencriptação TLS.

Isto cria um limite importante: uma exceção não pode desativar a desencriptação e depois utilizar de forma fiável como critério uma parte que só é visível no caminho HTTP encriptado. Este caso requer um âmbito baseado no host ou outro desenho.

Criar a Web Exception

O exemplo exclui da desencriptação HTTPS um único cliente piloto para um host de fornecedor confirmado. Não é uma regra de exceção universal.

1. Abrir Web > Exceptions.
2. Selecionar Add an exception.
3. Definir um nome descritivo, por exemplo Vendor API no decrypt.
4. Ativar URL pattern matches.
5. Introduzir o padrão testado e ancorado em Search/Add e confirmá-lo com Add.
6. Para o piloto, ativar também Source IP addresses, introduzir o IP concreto do cliente e confirmar com Add.
7. Em Skip the selected checks or actions, selecionar exclusivamente HTTPS decryption.
8. Selecionar Save.
9. Na lista, ativar o interruptor da nova exceção.
10. Voltar a verificar nome, Matching URLs, origens e controlo ignorado.

O IP de origem é definido deliberadamente no exemplo. Sem ele, a exceção aplicar-se-ia imediatamente a todos os clientes cujo request correspondesse ao padrão de URL. Depois de um piloto bem-sucedido, o âmbito pode ser alargado de forma controlada às origens que realmente necessitam da exceção.

Para uma TLS Exclusion pura em muitos destinos, um URL Group numa regra Don't decrypt é normalmente mais fácil de manter e eficiente. Muitos FQDN Host Objects na origem ou no destino de uma SSL/TLS inspection rule são desfavoráveis, pois podem causar muitas consultas DNS em novas ligações TLS.

Preparar uma nova exceção de host no Config Studio

O Config Studio pode criar uma nova Web Exception a partir de um nome de domínio sem importar primeiro uma exceção existente. É um procedimento distinto; Bad regex e Apply Fix servem, por sua vez, para reparar entradas existentes, como descrito mais adiante. A nova exceção é inicialmente preparada apenas localmente e só é aplicada à firewall através da importação TAR.

Antes de começar, guardar num local protegido uma cópia de segurança completa da firewall e uma exportação seletiva inalterada de WebFilterException da mesma firewall. A secção Exportar WebFilterException e verificá-lo com Config Studio explica a exportação de Entities.xml, o tratamento dos ficheiros e o download posterior. Registar no pedido de alteração um nome ainda não utilizado, o host de destino confirmado, a opção de exclusão necessária e o âmbito de clientes previsto. Um nome existente não é uma forma segura de acrescentar outra entrada: a importação atualiza as exceções existentes correspondentes. Um nome alterado cria, pelo contrário, uma nova entrada e não remove a antiga.

1. Abrir o Config Studio através do link de acesso mais abaixo, selecionar Configuration editor e ir a Rules > Web exceptions.
2. Selecionar Add e introduzir o novo nome único, por exemplo Vendor API exact host no decrypt.
3. Em Skip these checks, ativar apenas a opção necessária para o caso em questão. Para o exemplo de desencriptação, é Skip HTTPS decryption. As restantes opções chamam-se Skip policy check, Skip cert validation, Skip malware scan e Skip zero-day protection. As consequências para a proteção descritas acima também se aplicam à criação no editor; não selecionar várias opções por precaução.
4. Em Match by URL/Domain, escolher o âmbito: Exact host only apenas para o host confirmado, ou Domain + all subdomains se todos os seus subdomínios forem expressamente necessários e aprovados. Para updates.vendor.example, o exemplo mantém Exact host only selecionado; cdn.updates.vendor.example não deve ser incluído.
5. Introduzir o nome de domínio confirmado no campo de texto, sem caminho URL, por exemplo updates.vendor.example. Substituir este valor de documentação pelo host de destino real. A regex gerada e a pré-visualização aparecem automaticamente; verificar ambas face ao âmbito previsto e aos casos positivos e negativos descritos acima.
6. Selecionar Add to URL Regex list. O padrão deve aparecer depois em URL Regex Patterns. Um valor visível na pré-visualização ainda não é uma entrada acrescentada à lista.
7. Opcionalmente, em URL Regex Patterns, usar + Add URL regex para acrescentar diretamente um padrão próprio já verificado. Não é necessário para a criação a partir de um domínio; padrões adicionais alargam as correspondências possíveis devido a OR.
8. Por fim, selecionar Add na parte inferior do formulário lateral. Só assim é criada a nova exceção no editor.

Antes do download, comparar em Preview o XML de importação com o estado anterior guardado e o pedido de alteração. Só pode ser acrescentada a nova exceção aprovada; nomes, critérios, estados de ativação e opções de exclusão existentes não devem mudar inadvertidamente. O âmbito de clientes também deve estar correto: Exact host only limita o destino, não as origens. Se não for possível demonstrar que a configuração gerada contém uma origem piloto necessária, não importar; usar antes o procedimento WebAdmin descrito acima com Source IP addresses. Não acrescentar campos adicionais não verificados ao XML.

Selecionar depois Download > Download TAR e guardar o arquivo num local protegido. A secção Importar, verificar o efeito e reverter cobre as mensagens de importação, a comparação antes/depois em Web > Exceptions, a verificação da ativação e novas ligações com testes positivos e negativos. A pré-visualização XML ou uma importação bem-sucedida não substitui este teste do efeito na proteção. Perante um resultado inesperado, desativar a nova entrada de forma controlada e voltar a verificar o percurso normal de proteção. Reimportar a exportação seletiva original não remove automaticamente a exceção recém-criada; removê-la de forma específica apenas depois de esclarecer as dependências. As exceções existentes devem permanecer intactas.

Excluir uma categoria em vez de um único domínio

Se os dados financeiros confidenciais não devem ser desencriptados, a categoria Financial services pode ser o critério adequado. Contudo, uma exceção de categoria abrange mais destinos do que um único host; a classificação deve corresponder ao âmbito previsto.

1. Em Web > Exceptions > Add an exception, introduzir um nome como Financial services no decrypt.
2. Ativar Web site categories, selecionar Add new item e escolher Financial services.
3. Confirmar com Apply selected items. Para o piloto, definir também Source IP addresses com o IP do cliente e Add.
4. Selecionar apenas HTTPS decryption, escolher Save e ativar o interruptor na lista.
5. Testar um serviço financeiro aprovado e um destino inofensivo fora da categoria com novas ligações. Devido a AND, têm de corresponder tanto a origem piloto como a categoria.

As ligações HTTPS correspondentes perdem a desencriptação e os controlos de conteúdo que dela dependem; também se aplica a consequência sobre certificados descrita acima. Isto não concede autorização geral à categoria nem significa que todas as outras funções de proteção sejam desativadas.

Exceção de malware para um host de download confirmado

Um fornecedor considerado de baixo risco não é, por si só, motivo para desativar a análise. Se for necessária uma exceção justificada, utilizar o procedimento acima com um nome próprio, como Vendor download scan exception, o padrão do host confirmado e a origem piloto. Selecionar Malware and content scanning em vez de HTTPS decryption. Zero-day protection é selecionado automaticamente; as exceções antigas que ignoram a análise de malware também ignoram a análise Zero-Day. Depois, escolher Save e ativar o interruptor. Os downloads correspondentes ficam sem análise de malware e conteúdo nem análise Zero-Day, incluindo os respetivos relatórios. Não desmarcar adicionalmente os outros controlos. Verificar o caminho de proteção previsto com um download inofensivo e controlado do host aprovado e um destino de comparação não excluído; um download bem-sucedido, por si só, não basta.

Introduzir outros critérios e gerir exceções existentes

Preencher Destination IP addresses com o IP confirmado do site e selecionar Add, não com o IP do cliente. Nas combinações permitidas do critério de destino com URL ou categoria, todos os tipos selecionados têm de corresponder. Os padrões URL utilizam carateres ASCII; os nomes de domínio internacionalizados são escritos em Punycode. Matching URLs na exceção predefinida Apple Update pode servir como exemplo de sintaxe, não como modelo de autorização não verificado.

Exclusão TLS: indicações contraditórias sobre o âmbito. As páginas Add an exception de SFOS 22.0 e 23.0 descrevem a lógica geral AND entre tipos de critérios, mas Exclude a website from TLS inspection afirma expressamente que não se podem combinar exceções de origem e destino. O âmbito exato dessa restrição não é claro; a lógica geral de correspondência não demonstra que a combinação seja permitida. Combinar Source IP addresses e Destination IP addresses não é, por isso, um procedimento cuja admissibilidade esteja verificada. Antes de ativar uma exclusão TLS, confirmar a compilação real de SFOS, o percurso DPI/proxy, a omissão de controlo necessária e o âmbito restrito de host/categoria. Manter a abordagem acima com a origem piloto e o nome de host ou a categoria confirmados, sem acrescentar um critério de IP de destino. Destino mais nome de host/categoria confirmados só é uma opção separada se o âmbito dos clientes estiver limitado de forma independente e aprovado. Não substituir a restrição prevista por uma exceção apenas de origem nem remover um critério simplesmente para obter uma correspondência: isso alarga a omissão das proteções. Se forem necessárias restrições tanto de IP de origem como de destino, parar sem ativar nem alargar a exclusão e obter junto do Sophos Support uma clarificação para a compilação específica com o responsável pela firewall.

As exceções predefinidas suportam atualizações de software e outras funções importantes dos sites. Em Web > Exceptions, Edit abre uma exceção existente e Clone cria uma cópia. Verificar todos os critérios e opções de exclusão herdados antes de a ativar. Web > General settings controla a validação geral dos certificados HTTPS; uma exceção de certificado individual não substitui essa configuração de base.

Compreender o efeito das opções de exclusão

Antes de guardar, deve ser claro que proteção se perde.

HTTPS decryption

A firewall não desencripta o tráfego HTTPS correspondente. Assim, também não pode executar controlos que necessitam de conteúdo desencriptado. A Sophos documenta ainda que o tráfego com um certificado de servidor inválido é permitido para esta correspondência.

Se apenas uma particularidade do certificado causar o problema, esta opção é muitas vezes demasiado ampla. Primeiro verifica-se se HTTPS certificate validation é a exceção mais precisa.

HTTPS certificate validation

A firewall ignora a verificação de validade do certificado do servidor. A desencriptação configurada pode continuar. Esta exceção só é adequada para um destino conhecido com um problema de certificado conscientemente aceite e requer uma data de revisão próxima.

Sempre que possível, um certificado expirado, com nome incorreto ou não confiável deve ser corrigido no sistema de destino. A distribuição da Inspection CA correta resolve outro problema e é explicada em Distribuir o certificado CA para TLS Inspection.

Malware and content scanning

A firewall ignora a análise de malware e conteúdo para a correspondência. Isto também ignora automaticamente Zero-day protection. Uma única seleção remove, portanto, duas camadas de proteção do caminho de dados.

Antes desta exceção, verificam-se o tipo de ficheiro, limite de análise, encriptação, ação em caso de erro e o download que corresponde realmente. O fluxo completo está em Configurar e testar a análise de malware.

Zero-day protection

A análise Zero-Day é ignorada. Não são criados relatórios de análise para os ficheiros correspondentes, mesmo que a análise clássica de malware apresente uma deteção. Esta opção é mais restrita do que ignorar completamente Malware and content scanning.

Policy checks

As verificações da Web Policy são ignoradas para o request correspondente. Uma exceção deste tipo pode tornar ineficazes categorias, lógica de utilizadores ou grupos e outras decisões de policy. Só deve ser utilizada para um problema de policy claramente comprovado, não como solução geral para um site bloqueado.

Isto não autoriza a usar Policy checks para remover o bloqueio absoluto documentado de highly objectionable criminal activity descrito acima.

Verificar o efeito com testes positivos e negativos

O carregamento bem-sucedido de uma página apenas prova que algo mudou. Ainda não prova que a exceção é precisa.

1. Registar hora, cliente piloto, host de destino e efeito esperado.
2. Fechar a sessão existente do browser ou aplicação e criar uma nova ligação.
3. Repetir o request afetado.
4. No Log Viewer, comparar IP de origem, host de destino, Web Policy, Firewall Rule ID e Action.
5. Numa exceção de desencriptação, comparar o certificado do servidor visível para o cliente com o estado anterior à alteração.
6. Abrir um destino semelhante que não tenha sido excluído.
7. Verificar que este destino continua abrangido pela Web Policy, Decryption Rule e cadeia de análise normais.
8. Desativar brevemente a exceção e reproduzir o erro original, se isso for seguro dentro da janela de manutenção.
9. Voltar a ativar a exceção e confirmar novamente o resultado.

Se QUIC ou HTTP/3 evitar o caminho TLS sobre TCP esperado, o teste pode ser enganador. A delimitação está em Bloquear corretamente QUIC e HTTP/3. Log Viewer, Policy Tester e Packet Capture mostram que regra e policy correspondem realmente.

O Policy tester abre-se em Diagnostics > Tools, na secção Pop-out tools. O método Firewall, SSL/TLS, and web ajuda a identificar a regra de firewall, a SSL/TLS inspection rule e a Web Policy esperadas. Contudo, só testa tráfego web em Transparent Mode, pelo que não representa um fluxo direct web proxy explícito. A aplicação efetiva da Web Exception deve ser sempre confirmada com um novo request e logs reais.

Para obter provas nos logs, Log firewall traffic deve estar ativo na regra de firewall; Log connections também deve ser ativado na SSL/TLS inspection rule. Em System services > Log settings, os tipos de log relevantes devem estar ativos para Local reporting. Depois, restringe-se o Log Viewer à hora do teste e ao IP de origem e comparam-se os módulos Web filter e SSL/TLS inspection com Firewall Rule ID, policy e Action. Utilizar corretamente o Sophos Firewall Log Viewer explica os controlos. Se toda a vista continuar vazia, segue-se Log Viewer não está a atualizar, em vez de alargar a exceção com base numa suspeita.

Delimitar erros sistematicamente

A exceção não se aplica

• O bloqueio absoluto documentado de uma categoria não é um erro de correspondência. Um domínio ocultado intencionalmente não é aqui uma falha de logging. As categorias web e Web Policies explicam o limite; não tentar uma exceção mais ampla nem testes contra estes conteúdos.
• O interruptor em Web > Exceptions não está ativo.
• Um tipo de critério adicional não corresponde devido à lógica AND.
• A regex não está ancorada no início ou não representa o hostname real.
• Numa exceção de caminho HTTPS, o tráfego não é desencriptado, pelo que o caminho não é visível.
• Em DPI Mode, não está ativa para o fluxo nenhuma Web Policy, Malware and content scanning nem ATP.
• Aplica-se outra regra de firewall, Web Policy ou modo de funcionamento diferente do esperado.
• A sessão existente do browser ou da aplicação não foi recriada.

A exceção aplica-se de forma demasiado ampla

• O padrão contém um wildcard não controlado ou apenas texto isolado de root domain.
• Faltam Source IP addresses ou outro âmbito piloto.
• Vários padrões de URL dentro do mesmo tipo funcionam de forma mais ampla do que o esperado devido a OR.
• Foi excluída uma Web category inteira em vez do host específico.
• Foram ativadas várias opções de exclusão, embora apenas um controlo cause o problema.

O site funciona, mas o efeito na proteção não é claro

A exceção não é alargada. Primeiro comparam-se o certificado do browser, os logs de Web e SSL/TLS Inspection, o Firewall Rule ID, a Web Policy e um download controlado. Sem estas provas, a exceção é apenas um workaround funcional, ainda não uma decisão de segurança aceite.

Se as ferramentas do WebAdmin não isolarem a causa, Associar corretamente os logs de serviço do Sophos Firewall relaciona os logs de DPI, proxy, malware e Zero-Day com o caminho de proteção afetado. O debug não é ativado como primeiro passo.

CPU elevada e acesso web lento após alterações de regex

Em Diagnostics > System graphs, comparar primeiro os horários e a evolução da carga com os pedidos lentos e as últimas alterações às exceções. Em Web > Exceptions, verificar Selection criteria ou Matching URLs de todas as exceções ativas: faltam ^, pontos do host com escape ou um limite claro do host? Existem wildcards abrangentes ou muitos textos de domínio não ancorados?

Com acesso autorizado à consola, executar o seguinte comando de apenas leitura em Device Management > Advanced Shell. Mostra a carga atual dos processos, mas não altera a configuração; sair da vista com q.

top

Se awarrenhttp ou snort estiverem no topo da utilização de CPU, as regex de Web Exceptions podem contribuir para a carga. É um indício, não uma prova de que sejam a única causa: ambos os processos executam outros controlos. Investigar conjuntamente carga, pedidos e padrões, efetuar apenas uma alteração limitada e voltar a medir com uma carga de tráfego comparável. Se a CPU continuar elevada, continuar a delimitar outras causas no caminho de proteção afetado; não desativar indiscriminadamente a inspeção ou todas as exceções como teste comparativo.

Reparar seletivamente regex existentes

Para poucas exceções, Web > Exceptions > Edit é o caminho mais claro. Guardar primeiro nomes, estado de ativação, critérios e opções de exclusão; depois corrigir apenas o padrão URL testado. Para muitas entradas, pode exportar-se o módulo WebFilterException. Esta exportação abrange as configurações de Web Exceptions selecionadas, não automaticamente apenas a exceção defeituosa. As entradas inalteradas também devem ser preservadas na comparação antes/depois.

Antes de ambas as variantes de importação, guardar em segurança um backup atual da firewall e uma exportação seletiva inalterada. Definir a via de reversão, a janela de manutenção e o acesso de administração antes de importar. Uma exportação seletiva não substitui um backup completo. Guardar separadamente o ficheiro original, a cópia de trabalho e o resultado aprovado; as configurações e os relatórios gerados contêm detalhes internos e devem permanecer apenas num computador de administração autorizado e com acesso protegido.

Exportar WebFilterException e verificá-lo com Config Studio

1. Na mesma firewall, abrir Backup & firmware > Import export e selecionar Export selective configuration.
2. Procurar WebFilterException através de Add new item e confirmar com Apply selected items. Não selecionar Include dependent entity: não devem ser editadas outras áreas de configuração em simultâneo.
3. Guardar o arquivo API-[timestamp].tar com Export ou Download. Extrair uma cópia de trabalho; contém Entities.xml.
4. Abrir Sophos Firewall Config Studio. Selecionar Configuration editor e Rules > Web exceptions, depois carregar a Entities.xml seletiva através de Import.
5. Em Config Analysis, procurar Bad regex. Abrir a entrada afetada com Edit, rever a proposta através de Apply Fix e confirmar com Update. Não alterar nomes; um nome alterado faz com que a importação na firewall crie uma nova exceção em vez de atualizar a existente.
6. Verificar a proposta com casos positivos, negativos e entradas longas sem correspondência. Para novos padrões de host, Exact host only e Domain + all subdomains distinguem o âmbito pretendido; a reparação não deve permitir subdomínios por acidente. Uma correção automática não substitui esta decisão nem o teste do efeito na proteção.
7. Em Preview, verificar a configuração a importar e compará-la com o original: só devem mudar as regex aprovadas, não nomes, origens, critérios de destino, ativação ou opções de exclusão. Guardar o arquivo aprovado através de Download > Download TAR.

O Config Studio processa os dados de configuração no browser do equipamento; o parsing, a análise e a geração de relatórios não carregam estes dados para o exterior. Ainda assim, os ficheiros locais, downloads e relatórios HTML permanecem confidenciais. Não transferir configurações para outras ferramentas de análise online. Editar ou descarregar no Config Studio ainda não altera nada na firewall.

Alternativa: editar Entities.xml de forma controlada

Sem Config Studio, editar a mesma cópia de trabalho exportada seletivamente num editor de texto. Alterar apenas os padrões URL afetados; não substituir indiscriminadamente todos os pontos do ficheiro XML. A estrutura XML, os nomes dos objetos e os outros campos permanecem inalterados. Antes de criar o arquivo, verificar se o XML está bem formado e rever o diff completo. Não importar se a sintaxe não for clara ou surgirem ficheiros adicionais inesperados.

Manter exatamente o nome Entities.xml e colocar os ficheiros num novo arquivo TAR com a mesma estrutura do original, não em ZIP nem dentro de uma pasta adicional. Se o original contiver outros ficheiros, não os descartar silenciosamente. Este procedimento simples de Web Exceptions não deve ser aplicado a outros módulos ou a objetos sensíveis e interdependentes.

Importar, verificar o efeito e reverter

A importação substitui as definições existentes correspondentes. Um arquivo carregado com sucesso não comprova uma correspondência restrita nem uma proteção inalterada. Aprovar primeiro o diff e importar depois na janela de manutenção acordada.

Em Backup & firmware > Import export > Import, selecionar o .tar verificado com Browse e executar Import. Verificar se as mensagens de importação apresentam erros; depois, em Web > Exceptions, comparar nomes e número de entradas, estado de ativação, Matching URLs, critérios e opções de exclusão com o estado pretendido. As definições sem uma entrada de importação correspondente permanecem; a importação não elimina automaticamente exceções adicionais indesejadas.

Depois, criar novas ligações, repetir os testes positivos e negativos existentes com logs e, numa reparação de desempenho, comparar a evolução da CPU e a carga dos processos com a referência inicial. Em caso de erros, parar a implementação e desativar a exceção afetada de forma controlada se o impacto na aplicação for aceitável. Para uma reposição direcionada, pode importar-se a exportação seletiva inalterada da mesma firewall; excluir primeiro alterações intermédias, pois também seriam substituídas. Não reativar sem verificação um estado anterior comprovadamente demasiado abrangente. A reposição de um backup completo continua a ser uma via de emergência planeada separadamente, não o primeiro passo de reversão para uma regex individual. Após cada reversão, voltar a verificar a configuração e o caminho de proteção.

Planear WebFilterException através da XML API

A importação seletiva de Entities.xml descrita acima não é uma receita geral para a XML API. As referências de objetos para SFOS 22.0 e 23.0 descrevem Add Web Filter Exception / Update Web Filter Exception com o objeto WebFilterException. As correspondências seguintes ajudam a verificar uma automação planeada; não constituem um request completo, pronto a enviar ou testado numa firewall. O acesso, as credenciais protegidas, a operação explícita, a estrutura envolvente do request específica da versão e a avaliação segura da resposta fazem parte do procedimento central em Utilizar a XML API com segurança. Sem sintaxe confirmada para a compilação específica, não se efetuam operações de escrita.

Distinguir ativação, flags de exclusão e DomainList

Enabled ativa a exceção e aceita on ou off. As cinco flags de exclusão também aceitam on ou off, mas representam a omissão de um controlo, não a sua ativação: HttpsDecrypt para a desencriptação HTTPS, VirusScan para a análise de malware, PolicyCheck para as verificações da Web Policy, ZeroDayProtection para a proteção Zero-Day e CertValidation para a validação de certificados HTTPS. Assim, on numa flag de exclusão significa que a proteção é ignorada. As consequências para a proteção explicadas acima continuam a aplicar-se, em particular a exclusão automática de Zero-Day quando se ignora a análise de malware. Não concluir, a partir de uma flag de exclusão definida, que uma entrada já está ativa ou corresponde ao fluxo.

A referência apresenta critérios repetíveis em DomainList e interruptores separados no objeto:

• EnableSrcIP com SrcIp: verificação do IP de origem; é aqui que se define o cliente.
• EnableDstIP com DstIp: verificação do IP de destino; é aqui que se define o endereço do site.
• EnableURLRegex com URLRegex: verificação de padrões URL, não uma lista de domínios com subdomínios incluídos automaticamente.
• EnableWebCat com WebCategory: verificação da categoria web.

Os quatro interruptores são valores escalares yes/no, não on/off. Os quatro critérios são arrays de strings que admitem vários valores; para cada entrada de SrcIp e DstIp, a referência indica um máximo de 43 carateres. Um array apenas preenchido não substitui um interruptor de ativação confirmado. De acordo com a lógica de correspondência, os diferentes tipos de critérios ativados têm de corresponder com AND, e os valores dentro de um tipo com OR. Por isso, padrões URL adicionais podem alargar a correspondência. A restrição TLS por esclarecer, documentada acima, para exceções que combinam IP de origem e de destino mantém-se: a existência de ambos os campos na API não comprova que a combinação seja permitida. Não criar uma exclusão mais abrangente por omissão de um critério.

Para URLRegex, continuam a ser necessários a ancoragem no início, os pontos do host com escape, um limite claro do host, ASCII/Punycode e testes positivos, negativos e com entradas longas sem correspondência. O padrão da referência da API não é uma lista de permissões aprovada e não substitui estes testes nem o limite relativo ao caminho HTTPS. A verificação da sintaxe XML, por si só, não comprova uma correspondência segura.

Name é o único parâmetro assinalado como obrigatório: uma string escalar com um máximo de 60 carateres; não são permitidos ^, ;, ', " e \. O parâmetro opcional NewName serve para renomear e tem os mesmos limites. Não equivale à criação de uma nova entrada através de um nome alterado na importação seletiva. Desc é uma string escalar opcional com um máximo de 250 carateres; IsDefault identifica uma exceção predefinida através de um valor escalar yes/no e não constitui autorização para alterar objetos predefinidos. Os restantes parâmetros são opcionais e as respetivas colunas de valores predefinidos estão vazias. Daí não decorre um valor predefinido concreto nem uma garantia de que os valores omitidos sejam preservados numa atualização. Guardar previamente o estado armazenado e definir a comparação completa entre o estado pretendido e o estado real.

Classificar respostas por operação, código e símbolo

Ambas as referências de objetos contêm exatamente estas correspondências. As designações das operações e os símbolos permanecem deliberadamente inalterados:

Estes códigos XML não são códigos de estado HTTP. Message.* continua a ser um símbolo de documentação não resolvido, não uma mensagem verificada em tempo de execução nem uma causa de erro inequívoca. Em particular, não se pode deduzir um limite máximo numérico de Message.WebExceptionsLimit. Add e Update têm símbolos de sucesso/erro diferentes; as correspondências de Add para 502 e 522 não são aplicadas a Update.

Guardar de forma protegida a resposta real com a operação e o código XML, mesmo em caso de timeout ou de resultado pouco claro. Antes de cada nova tentativa de escrita, verificar a entrada efetivamente armazenada através de uma consulta de leitura confirmada para a compilação específica ou em Web > Exceptions: nome antigo e, quando aplicável, novo nome, número de entradas, ativação, todos os critérios e flags de exclusão. Mesmo uma indicação de sucesso não substitui esta comparação. Se uma entrada já existir, não voltar a criá-la, renomeá-la, substituí-la ou remover critérios às cegas. Perante um estado pouco claro ou parcialmente alterado, parar e esclarecer com o responsável pela firewall, com base na resposta, no estado anterior e no estado pretendido. Após uma alteração confirmada, criar novas ligações e executar os testes positivos e negativos existentes; só estes verificam o efeito na proteção. O guia central da API explica ainda os avisos, os sucessos parciais e o procedimento seguro sem novas tentativas às cegas.

Revisão e rollback

Cada Web Exception de produção contém pelo menos:

• justificação técnica e ticket
• responsável pela aplicação e pela firewall
• hosts, caminhos, origens e grupos de utilizadores afetados
• controlos exatos ignorados
• data dos testes positivos e negativos
• data de revisão ou expiração
• estado anterior documentado

No rollback, a exceção é primeiro desativada, em vez de ser eliminada de imediato. Depois voltam a testar-se o erro original, o caminho de proteção normal e os destinos não afetados. A exceção só é removida quando já não existe qualquer dependência.

As exceções predefinidas e do fornecedor não são alteradas sem controlo. Numa exceção própria deve permanecer claro por que existe e quem a voltará a avaliar mais tarde.

Checklist operacional

• DPI Mode ou Web Proxy Mode identificado.
• Regra de firewall e Web Policy que correspondem realmente confirmadas.
• Hostname e, quando aplicável, caminho URL capturados do tráfego real.
• Regex ancorada no início e testada contra não correspondências.
• Considerados AND entre tipos de critérios e OR dentro de um tipo.
• Selecionada apenas a opção mínima necessária.
• Considerada a exclusão automática de Zero-Day com Malware and content scanning.
• Origem piloto limitada.
• Testes positivos e negativos realizados.
• Log Viewer, certificado e efeito na proteção verificados em conjunto.
• Responsável, ticket, data de revisão e rollback documentados.

Perguntas frequentes