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.

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.

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 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.

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.

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 e introduzir o IP concreto do cliente.
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.

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.

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.

Delimitar erros sistematicamente

A exceção não se aplica

• 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.

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