Implementar corretamente a inspeção TLS no Sophos Firewall

Uma grande parte do tráfego web atual é criptografada. Sem a inspeção TLS, o firewall muitas vezes só vê o IP de destino, SNI, informações de certificado e metadados, mas não o conteúdo real da conexão.

Isso é um problema de segurança: muitas funções de proteção não conseguem verificar o payload criptografado ou só o fazem de forma muito limitada. A verificação de malware, proteção web, análise de zero-day, verificação de conteúdo e partes da detecção de aplicações ou ameaças só se tornam realmente eficazes quando o firewall pode desencriptar, verificar e depois recriptografar o tráfego TLS. IPS e NDR também se beneficiam de uma maior visibilidade em texto claro. Sem desencriptação, muitos sinais ficam limitados a metadados, certificados, IPs, domínios ou informações de protocolo.

No entanto, a inspeção TLS não é um recurso que deve ser ativado para todos os usuários sem preparação. Pode interferir em aplicações, levantar questões de privacidade e aumentar a carga no firewall. Portanto, a inspeção TLS deve ser implementada de forma planejada, gradual e com uma estratégia clara de exceções.

Orientação

Começa-se por escolher o método de proteção ou configuração adequado ao caso real. Assim evitam-se regras demasiado amplas e troubleshooting duplicado.

Licença e Pré-requisitos

Para a inspeção TLS e a avaliação eficaz do tráfego desencriptado, são necessárias as licenças de proteção adequadas.

Os mais importantes são:

Web Protection: Inclui segurança web, controle web, controle de aplicações e proteção contra malware web.
Network Protection: Inclui, entre outros, IPS, Security Heartbeat e outras funções de proteção de rede.
Zero-Day Protection: Torna-se importante quando arquivos ou downloads precisam ser analisados adicionalmente por machine learning ou sandbox.

A Web Protection está incluída no pacote de licenças Standard Protection. Xstream Protection e Epic Protection também incluem Web Protection e outros módulos de proteção. Para a classificação dos pacotes, consulte Quais pacotes Sophos Firewall existem?; para a Base License, status de suporte e assinaturas, consulte Entendendo a Base License do Sophos Firewall.

Antes da implementação, deve-se verificar:

Firmware atual do Sophos Firewall está instalado.
Web Protection está licenciada.
Certificado CA do firewall está distribuído nos clientes.
Grupo de teste ou rede de teste está definido.
Rollback está documentado.
Processo de exceção está esclarecido.
Logging está ativado.

Se o certificado CA ainda não foi distribuído, o artigo Instalar o certificado CA do Sophos Firewall para escaneamento HTTPS pode ajudar.

⚠️ A inspeção TLS pode interferir em aplicações que usam pinagem de certificado ou realizam suas próprias verificações de certificado. A implementação deve sempre começar com um grupo de teste e não diretamente com todos os usuários.

DPI ou Web Proxy?

O Sophos Firewall pode implementar a desencriptação HTTPS em dois modos de operação:

Modo DPI: A regra do firewall usa o motor DPI. As regras de inspeção SSL/TLS em Rules and policies > SSL/TLS inspection rules decidem o que será desencriptado.
Modo Web Proxy: A regra do firewall usa o Web Proxy. A desencriptação HTTPS é então controlada pelas configurações do Web Proxy e pelas políticas web.

Para configurações modernas, o modo DPI é frequentemente usado. O importante é a regra do firewall:

Abra Rules and policies > Firewall rules.
Edite a regra LAN-to-WAN afetada.
Abra Security features > Web filtering.
Ative a política web apropriada.
Ative Scan HTTP and decrypted HTTPS.
Deixe Use web proxy instead of DPI engine desativado se as regras de inspeção SSL/TLS devem ser aplicadas.

Se Use web proxy instead of DPI engine estiver ativado, o tráfego web passa pelo Web Proxy. Nesse caso, para HTTP/HTTPS, aplicam-se configurações de desencriptação diferentes das regras de inspeção SSL/TLS baseadas em DPI. Antes da implementação, deve-se esclarecer se o ambiente usa Web Proxy ou DPI, caso contrário, as exceções serão procuradas no lugar errado.

Que tráfego deve ser desencriptado?

Não se deve desencriptar tudo cegamente. Uma boa inspeção TLS começa com objetivos claros.

Objetivos iniciais sensatos:

LAN > WAN: tráfego web clássico de usuários para a internet.
Wi-Fi > WAN: clientes geridos na rede Wi-Fi da empresa.
VPN > WAN: usuários de acesso remoto, quando o tráfego de internet deles passa pelo firewall.
LAN > DMZ: acessos internos a servidores próprios, quando a verificação de segurança é desejada e os certificados estão distribuídos corretamente.

Tratar com cautela:

Portais bancários, de saúde, governamentais e altamente sensíveis.
Gerenciadores de senhas e provedores de identidade.
Serviços de atualização de sistemas operacionais e fabricantes.
Aplicativos móveis e dispositivos Android.
Aplicações com pinagem de certificado.
Serviços de voz, vídeo e colaboração, se ficarem instáveis com a desencriptação.

Para publicações de servidores da internet para a DMZ, a inspeção TLS não é automaticamente a melhor solução. Para servidores web, frequentemente Proteção de Servidor Web / WAF ou um proxy reverso é mais adequado.

Considerar QUIC e Política Web

Se o tráfego web não for verificado como esperado, apesar da inspeção TLS, deve-se também verificar o QUIC ou HTTP/3. Muitos navegadores podem estabelecer conexões HTTPS via UDP 443. Dependendo do design da regra e da política web, o tráfego pode não seguir o caminho HTTPS clássico esperado via TCP 443.

Nas regras de internet do cliente, deve-se verificar conscientemente:

A política web apropriada está ativa?
Block QUIC protocol está ativo na regra de firewall correspondente?
Scan HTTP and decrypted HTTPS está configurado de acordo com a estratégia de desencriptação?
A regra usa DPI ou Web Proxy?
No Log Viewer, vê-se UDP 443, TCP 443, eventos de política web e eventos de inspeção SSL/TLS de forma consistente?

O procedimento para bloquear QUIC está em Bloquear corretamente o protocolo QUIC e HTTP/3 no Sophos Firewall. Para a própria política web, consulte Criar política de proteção web no Sophos Firewall.

Planear o rollout

TLS Inspection deve ser introduzida gradualmente para manter exceções, certificados de clientes e casos de suporte controláveis.

Estratégia de Implementação

Uma abordagem em etapas tem se mostrado eficaz:

Distribuir o certificado CA.
Preparar a política web e a regra do firewall.
Selecionar o perfil de desencriptação.
Definir um pequeno grupo de teste.
Ativar a regra de inspeção SSL/TLS apenas para este grupo.
Monitorar o Centro de Controle e o Log Viewer.
Analisar erros e documentar exceções de forma clara.
Expandir gradualmente para outros grupos de usuários.

Dessa forma, identifica-se cedo quais aplicações causam problemas, sem impactar toda a operação.

Planejar Fases de Implementação

Uma implementação de inspeção TLS deve ser planejada em fases. Isso mantém o processo controlável e permite separar problemas técnicos de problemas de aceitação ou aplicação.

Preparação: CA, política web, regra de firewall e grupo de teste estão prontos. Distribuição de CA, licença, logging, rollback
Piloto: poucos clientes geridos testam o dia a dia produtivo. Log Viewer, Widget do Dashboard, feedback dos usuários
Expansão: incluir outros grupos de usuários ou redes. Documentar exceções, observar desempenho
Operação: Inspeção TLS é verificada regularmente. Revisão de exclusões, relatórios, erros e novas aplicações

É importante que cada fase tenha um ponto de interrupção claro. Se uma aplicação crítica para o negócio falhar no piloto, não se deve imediatamente definir uma exceção global ampla. É melhor uma análise cuidadosa: qual domínio, qual cliente, qual regra, qual perfil de desencriptação e qual erro no Log Viewer estão envolvidos?

Definir Piloto, Responsável e Processo de Exceção

Antes da primeira implementação produtiva, deve-se esclarecer quem gerencia o grupo de teste, quem aprova exceções e como os erros são relatados. Caso contrário, a inspeção TLS rapidamente gera exceções desordenadas: domínios individuais são apressadamente definidos como Don't decrypt, sem que mais tarde se saiba por que a exceção existe.

Para a operação, esses pontos devem ser documentados:

Grupo piloto, redes afetadas e período.
Responsável pela política web, perfil de desencriptação e regras de inspeção SSL/TLS.
Processo para novas exceções com motivo, ticket e data de revisão.
Critérios para quando uma aplicação é excluída e quando a causa é primeiro verificada.
Local onde o Log Viewer, Widget do Dashboard e feedback dos usuários são coletados.
Rollback, caso aplicações críticas para o negócio sejam afetadas.

É especialmente importante separar entre exceção técnica e decisão de segurança permanente. Uma exceção temporária pode ser sensata para que um serviço volte a funcionar. No entanto, essa exceção deve ser reavaliada posteriormente, assim que a causa, o risco e a alternativa estiverem claros.

Testar o rollback antes do rollout

Um rollback não deve ser inventado apenas durante uma falha. Antes do piloto deve estar claro como retirar TLS Inspection para o grupo de teste sem desorganizar outras regras, Web Policies ou exceções.

Verificação prática de rollback:

Remover o grupo de teste: verificar se a SSL/TLS Inspection Rule deixa de fazer match para o cliente piloto.
Desativar a regra: controlar se o tráfego volta ao caminho esperado sem decryption.
Testar a exceção: uma regra Don't decrypt direcionada deve ficar acima da regra geral Decrypt e fazer match visível no Log Viewer.
Manter a Web Policy: o rollback da desencriptação não pode remover acidentalmente web filtering, malware scanning ou logging.
Documentar a prova: registar cliente de teste, domínio de destino, nome da regra, evento de log e hora.

Este teste é especialmente importante quando vários administradores trabalham em Web Policies, regras de firewall e SSL/TLS Inspection Rules. Um rollback limpo retira apenas o scope afetado e não deixa toda a cadeia de Web Protection cega.

Configuração

A configuração deve ser específica, testável e fácil de rever mais tarde.

Entender Perfis de Desencriptação

Um Perfil de Desencriptação define quão rigorosamente o firewall lida com conexões TLS. Os perfis podem ser encontrados em Profiles > Decryption profiles.

Um perfil de desencriptação responde, entre outras, a estas perguntas:

O que acontece com certificados inválidos ou não confiáveis?
Versões antigas de TLS são bloqueadas?
Cipher Suites inseguras são bloqueadas?
O que acontece com a compressão SSL?
O que acontece com cipher suites não reconhecidas?
O que acontece se o firewall não puder desencriptar uma conexão?
Qual CA é usada para a nova assinatura?

Para uma primeira implementação, um perfil mais compatível é sensato, como Maximum compatibility ou um perfil conservador próprio. Para regras de segurança produtivas, um perfil mais rigoroso como Block insecure SSL pode ser usado posteriormente.

Importante: O perfil de desencriptação é selecionado diretamente na regra de inspeção SSL/TLS. O perfil pode substituir as configurações globais de inspeção SSL/TLS para essa regra. Portanto, ao solucionar problemas, deve-se sempre verificar a regra específica e não apenas as configurações globais.

Criar Regra de Inspeção SSL/TLS

O caminho do menu é Rules and policies > SSL/TLS inspection rules.

Uma primeira regra deve ser o mais direcionada possível:

Ação: Decrypt
Perfil de desencriptação: perfil de teste conservador
Zonas de origem: LAN ou rede de teste
Redes e dispositivos de origem: grupo de teste ou sub-rede de teste
Zonas de destino: geralmente WAN
Redes de destino: inicialmente Any
Serviços: para começar, frequentemente Any, pois SSL/TLS também pode ser reconhecido em outras portas TCP
Websites / Categorias: opcionalmente restringir

As regras de inspeção SSL/TLS podem reconhecer conexões TLS também fora da porta HTTPS clássica. As regras são processadas de cima para baixo. Exceções específicas e regras piloto devem, portanto, estar acima das regras gerais de desencriptação, caso contrário, será difícil rastrear por que uma conexão foi desencriptada ou excluída.

Listas de Exclusão

Nem todo tráfego TLS deve ser desencriptado. A Sophos trabalha com regras de exclusão e listas de exclusão TLS.

Lista de Exclusão TLS Local

A lista de exclusão TLS local é a lista de exceções local do firewall. Esta lista está vazia por padrão e pode ser preenchida por meio de solução de problemas no Centro de Controle ou Log Viewer.

Também pode ser editada manualmente:

Web > URL groups > Local TLS exclusion list

Esta lista é útil para domínios que causam problemas no próprio ambiente, por exemplo, devido a pinagem de certificado ou aplicações de cliente especiais.

Lista de Exclusão TLS Gerida

A lista de exclusão TLS gerida contém exceções mantidas pela Sophos para serviços problemáticos conhecidos. Esta lista é atualizada por meio de atualizações de firmware.

Exemplos típicos são serviços onde a inspeção TLS comprovadamente causa problemas ou não é tecnicamente viável.

Regras de Exclusão Próprias

Além disso, podem ser criadas regras de inspeção SSL/TLS próprias com Action > Don’t decrypt. Estas devem estar diretamente abaixo da regra de exclusão padrão e conter apenas o tráfego que realmente não deve ser desencriptado.

Critérios possíveis:

Categorias web
Grupos de URL
Usuários e grupos
Redes de origem e destino
Endereços IP
Serviços

As exceções devem ser documentadas: domínio, motivo, usuários afetados, data e data de revisão.

Controlo e análise

Após a ativação, o dashboard e o Log Viewer mostram se o tráfego é realmente desencriptado ou excluído.

No Centro de Controle, há um widget para Inspeção SSL/TLS. Este widget é muito útil para monitorar a implementação e erros.

Ele mostra, entre outros:

Percentual de sessões SSL/TLS desencriptadas.
Percentual de sessões SSL/TLS não desencriptadas.
Outro tráfego.
Erros dos últimos dias.
Principais websites ou usuários com problemas.
Pico de desencriptação e limite de desencriptação.

Sophos Firewall - Widget de Inspeção SSL/TLS com tráfego desencriptado e não desencriptado — Sophos Firewall - Centro de Controle > Widget de Inspeção SSL/TLS

Se muitos erros aparecerem no widget, não se deve desativar imediatamente toda a inspeção TLS. É melhor usar Fix errors para verificar especificamente os destinos afetados e criar exceções limpas, se necessário.

Avaliar Log Viewer

No Log Viewer, pode-se selecionar o filtro inspeção SSL/TLS. Lá, vê-se o que aconteceu com conexões individuais.

Sophos Firewall - Log Viewer com eventos de inspeção SSL/TLS — Sophos Firewall - Log Viewer > inspeção SSL/TLS

As cores ajudam na primeira avaliação:

Vermelho: Erro. A conexão não pôde ser desencriptada ou processada corretamente. Deve-se verificar erros de certificado, cipher suites, versões TLS ou aplicações incompatíveis.
Verde: Não desencriptar. A conexão não foi desencriptada intencionalmente, por exemplo, devido a uma regra de exclusão ou uma lista de exclusão TLS.
Azul: Desencriptar. A conexão foi desencriptada e depois recriptografada e encaminhada.

No log, também se vê o perfil de desencriptação, IP de origem, IP de destino, usuário, categoria e domínio de destino. Isso permite verificar se a regra correta foi aplicada e se uma exceção realmente se aplica.

Testes

Após ativar a inspeção TLS, deve-se verificar:

O certificado CA da Sophos está sendo usado no navegador?
Aplicações de negócios importantes funcionam?
Existem erros TLS no Log Viewer?
Eventos de malware ou política web são reconhecidos corretamente?
O tráfego é exibido como desencriptado no widget do Centro de Controle?
O desempenho do firewall permanece dentro do esperado?
Existem reclamações de usuários de teste?

Para a solução de problemas, são especialmente úteis o Log Viewer, Policy Test, visualização de certificados no navegador, Packet Capture e o widget de inspeção SSL/TLS.

Troubleshooting e operação

Problemas de TLS Inspection resolvem-se normalmente com exceções claras, rollback controlado e revisão regular.

Erros Típicos

Navegador mostra aviso de certificado: CA ausente no Trust Store ou CA errada sendo usada. Distribuição de CA, cadeia de certificados no navegador, reinício do cliente
Log Viewer não mostra eventos de inspeção SSL/TLS: modo errado, nenhuma regra correspondente ou motor SSL/TLS não ativo. Regra de firewall, DPI/Web Proxy, regra de inspeção SSL/TLS
Tráfego é permitido, mas não desencriptado: Regra Don't decrypt, exclusão gerida ou ordem de regras errada. Verificar regras de inspeção SSL/TLS de cima para baixo
Filtro web não funciona como esperado: Política web ausente, QUIC ativo ou Scan HTTP and decrypted HTTPS mal compreendido. Regra de firewall correspondente, QUIC, log de política web
Aplicações individuais falham: Pinagem de certificado, versão TLS antiga, cipher suite incompatível ou verificação de certificado própria. Log Viewer, perfil de desencriptação, exceção direcionada
Muitos erros no widget do Dashboard: implementação muito ampla ou perfil de desencriptação inadequado. Reduzir grupo piloto, classificar erros por domínio e categoria
Desempenho cai após ativação: escopo muito amplo, downloads grandes ou muitas sessões simultâneas. Verificar escopo de desencriptação, carga do firewall e principais usuários
Exceção não funciona: Exceção está abaixo de uma regra de desencriptação mais geral. Verificar ordem das regras e critérios correspondentes

Em casos incertos, não se deve alterar várias coisas ao mesmo tempo. É melhor um caso de teste restrito: um cliente, um domínio de destino, uma regra de firewall, um perfil de desencriptação e um momento claro no Log Viewer.

Rollback

Caso ocorram interrupções, deve ser possível um rollback claro:

Desativar a regra de inspeção SSL/TLS.
Remover o grupo de teste da regra.
Suavizar o perfil de desencriptação.
Adicionar exceção para domínio ou aplicação afetada.
Reconfigurar a regra do firewall para Web Proxy, se isso for desejado conscientemente.

As regras de inspeção SSL/TLS e o motor SSL/TLS devem estar visivelmente ativos para que o Centro de Controle e o Log Viewer mostrem os detalhes. Se a inspeção SSL/TLS for desativada para fins de solução de problemas, deve-se reativá-la posteriormente e documentar brevemente o estado.

Recomendações de Operação

A inspeção TLS não é um projeto de um clique. Quando implementada corretamente, oferece muito mais visibilidade e melhora a eficácia da proteção web, verificação de malware, IPS, NDR e funções de zero-day.

Para ambientes produtivos, recomendamos:

Primeiro LAN-to-WAN para um pequeno grupo de teste.
Distribuir o certificado CA corretamente.
Escolher conscientemente o modo DPI/Web Proxy.
Não começar com perfis de desencriptação muito agressivos.
Monitorar diariamente o Log Viewer e o Dashboard.
Documentar exceções e revisá-las regularmente.
Expandir apenas após testes bem-sucedidos.
Manter o rollback testado para o grupo piloto e as exceções.

FAQ

Deve-se ativar a inspeção TLS imediatamente para todos os usuários?

Não. A inspeção TLS deve começar com um grupo de teste. Somente quando a distribuição de CA, política web, perfil de desencriptação, exceções, logs e aplicações de negócios forem verificadas, deve-se expandir o escopo.

Por que a inspeção TLS não funciona apesar do certificado CA instalado?

O certificado CA apenas garante que os clientes confiem na CA do firewall. Além disso, a regra do firewall, política web, regra de inspeção SSL/TLS, perfil de desencriptação e ordem das regras devem estar corretos.

Qual é a diferença entre o modo DPI e o modo Web Proxy?

No modo DPI, as regras de inspeção SSL/TLS se aplicam ao tráfego da regra do firewall. No modo Web Proxy, o tráfego web passa pelo proxy e a desencriptação é controlada de forma diferente. Portanto, deve-se verificar conscientemente o modo da regra de firewall afetada.

Quando é necessária uma exceção TLS?

Uma exceção é sensata quando uma aplicação não pode ser desencriptada corretamente devido a pinagem de certificado, verificação de certificado própria ou incompatibilidade técnica. A exceção deve ser documentada e revisada posteriormente.

O QUIC deve ser bloqueado para a inspeção TLS?

Em redes de clientes geridos, isso geralmente é sensato se o filtro web, verificação de malware ou inspeção TLS devem funcionar de forma confiável. O QUIC via UDP 443 pode, caso contrário, contornar o caminho HTTPS clássico esperado via TCP 443.