Implementar corretamente a inspeção TLS no Sophos Firewall

Com a inspeção TLS, o Sophos Firewall encerra a conexão criptografada do cliente e estabelece uma segunda conexão com o servidor de destino. Ele pode inspecionar o texto simples entre os dois. O firewall assina novamente para o cliente um certificado de servidor originalmente confiável com sua própria CA (Autoridade de Certificação). Se o cliente não confiar nesta CA, ele exibirá um aviso de certificado ou encerrará a conexão.

Isso torna possível inspecionar o conteúdo descriptografado, incluindo verificação de malware e de conteúdo. Sem descriptografia, os recursos de proteção podem ser limitados, dependendo do módulo, a informações como endereço IP, domínio, SNI, certificado ou metadados de protocolo. Isso não justifica uma implementação inicial ampla: a fixação de certificados, a privacidade, a compatibilidade de aplicativos e a carga adicional do firewall devem ser abordadas antes da implementação.

A versão resumida e segura é: determinar se deve usar o caminho DPI ou Web Proxy, distribuir a CA de nova assinatura para um pequeno grupo, documentar o estado atual, criar uma regra de descriptografia com escopo restrito, executar um teste positivo e um negativo e só então expandir o escopo.

Decida antes do piloto

Licença, CA e responsabilidades

As regras de inspeção SSL/TLS e os grupos de URL usados ​​nelas são aplicados com o Base License. Web Protection não é um pré-requisito geral para inspeção TLS. É necessário quando categorias da web são usadas como critérios de regra ou quando os recursos de proteção da web correspondentes são necessários. Malware, Zero-Day e outras inspeções exigem a assinatura relevante. Quais pacotes do Sophos Firewall estão disponíveis? e Compreendendo a licença básica do Sophos Firewall explicam as diferenças.

Esclareça o seguinte antes de criar a primeira regra:

• Documentar a versão do SFOS em uso, a licença disponível e o caminho de inspeção pretendido.
• Definir um grupo piloto gerenciado e uma janela de tempo clara. O exemplo abaixo usa o cliente 10.20.30.50 da rede de teste 10.20.30.0/24; substitua esses valores por seus próprios objetos.
• Obtenha a aprovação das partes interessadas responsáveis ​​pela privacidade para o escopo, registro, retenção e notificação do usuário.
• Faça backup do estado inicial exato da regra de firewall, regras TLS, perfil de descriptografia, CA e quaisquer configurações globais. Registre o caminho completo de correspondência anterior ao piloto, a regra que corresponderá após a desativação do piloto (incluindo qualquer regra Decrypt mais abrangente abaixo dela) e cada alteração exclusiva do piloto nas regras de firewall, no modo DPI/proxy, na Política da Web e nas configurações globais. Defina as etapas exatas e autorizadas de restauração antes da ativação.
• Nomeie o proprietário, critérios de anulação, processo de exceção e caminho de reversão.

A CA de nova assinatura deve estar no armazenamento confiável dos sistemas operacionais ou navegadores afetados. Como alternativa, use uma autoridade de certificação corporativa subordinada. Uma CA publicamente confiável não está disponível para essa finalidade porque o firewall assina novamente certificados para domínios de terceiros. Com uma CA externa, tanto a CA raiz quanto a subordinada devem ser importadas; se a CA de assinatura contiver uma seção EKU, ela deverá permitir TLS Web Server Authentication. Instalar certificado CA do Sophos Firewall para verificação HTTPS descreve a distribuição, enquanto Configurar uma CA subordinada para inspeção TLS do Sophos Firewall cobre o método CA corporativo.

⚠️ Não comece com todos os usuários. Dispositivos sem armazenamento confiável gerenciável, BYOD e aplicativos que usam fixação de certificado devem inicialmente permanecer em um escopo separado. Uma exceção restaura a conexão, mas remove seu conteúdo da descriptografia.

Mantenha o DPI e o Web Proxy separados

SFOS usa DPI engine por padrão. Nesse caminho, o firewall processa primeiro a Regra de Firewall e depois as Regras de Inspeção SSL/TLS. A Regra de Inspeção por si só não permite tráfego: mesmo Services: Any significa apenas que o tráfego TLS já permitido pela Regra de Firewall em qualquer porta TCP é elegível para esta Regra de Inspeção.

Para o caminho DPI, abra Rules and policies > Firewall rules, edite a regra LAN para WAN relevante e verifique Security features > Web filtering:

1. Deixe Use web proxy instead of DPI engine desativado.
2. Selecione uma Política Web somente se a proteção planejada assim o exigir; não é um pré-requisito para a regra de descriptografia.
3. Scan HTTP and decrypted HTTPS permite a verificação de malware para HTTP e HTTPS que já foram descriptografados. A opção por si só não permite a descriptografia HTTPS.

Em Web Proxy Mode, o proxy lida com a descriptografia HTTPS. Decrypt HTTPS during web proxy filtering é a configuração relevante no caminho do proxy. As regras de DPI em Rules and policies > SSL/TLS inspection rules não se aplicam a conexões descriptografadas pelo Web Proxy. Com o proxy transparente, as portas 80 e 443 passam pelo proxy enquanto o SSL/TLS em outras portas ainda pode ser tratado pelo caminho DPI; com o Proxy Explícito, o Web Proxy executa a descriptografia.

As CAs também são separadas: o DPI usa a CA das configurações SSL/TLS ou do perfil de descriptografia selecionado. O Web Proxy usa a CA de Web > General settings. Ao mudar de modo, verifique não só as regras, mas também a CA efetivamente apresentada. Escolha o mecanismo DPI ou o proxy da Web corretamente explica as diferenças com mais detalhes.

Este caminho de inspeção de saída não se destina a servidores Web publicados na Internet. Web Server Protection/WAF ou um proxy reverso geralmente é a arquitetura mais adequada. As regras de inspeção SSL/TLS se aplicam ao tráfego de saída, portanto, apenas zonas internas podem ser selecionadas como Source zones. Elas detectam TLS em qualquer porta TCP, mas não são aplicadas em UDP.

Contradição documental sobre a direção: O guia de criação de regras menciona conexões de entrada e saída, mas depois limita explicitamente Source zones às zonas internas e ao tráfego de saída. A formulação geral não comprova suporte à inspeção de entrada pela WAN. Esta implementação permanece no caminho dos clientes internos descrito aqui; conexões de entrada para servidores exigem esclarecimento do Sophos Support para a build utilizada antes de qualquer alteração.

Routing, DNS e acesso autorizado à Internet já devem funcionar antes do teste de descriptografia. Em Rules and policies > NAT rules, verifique a regra SNAT que realmente corresponde; numa arquitetura IPv4 típica, pode ser Default SNAT IPv4 com Translated source (SNAT): MASQ. Não substitua uma regra funcional por outra regra NAT ampla. IPv6 e redes encaminhadas exigem uma decisão de arquitetura própria, não automaticamente MASQ. A regra de firewall do piloto precisa de Action: Accept e do âmbito autorizado de origem, destino e serviços.

Para o proxy, verifique também HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols e Block invalid certificates em Web > General settings > HTTPS decryption and scanning. Para Direct Proxy, permita o listener configurado em Web > General settings > Web proxy configuration e Administration > Device access > Other services > Web proxy apenas aos clientes ou zonas necessários. O proxy transparente precisa dos serviços HTTP/HTTPS; Direct Proxy também precisa da porta configurada do listener. O artigo DPI/proxy já ligado descreve o procedimento completo e a proteção dos serviços Web locais do firewall.

Exemplo de compatibilidade desatualizado: O guia de configuração conservado para SFOS 22/23 pede TLS 1.1 no exemplo de proxy, enquanto a documentação dos perfis considera inseguras as versões anteriores a TLS 1.2. TLS 1.1 não é, portanto, adotado como requisito da implementação. Mantenha protocolos seguros; se uma aplicação antiga precisar de uma exceção, esclareça primeiro versão, caminho afetado, risco e âmbito restrito com o responsável pelo firewall. Reduzir TLS globalmente não é uma solução para o piloto.

Gerenciar QUIC de forma deliberada

QUIC, ou HTTP/3, usa UDP. Block QUIC protocol em uma regra de firewall descarta pacotes UDP de saída para as portas 80 e 443 dentro do escopo dessa regra, normalmente levando os clientes com uma alternativa TCP utilizável a tentar novamente por TCP; clientes sem essa alternativa podem perder a conectividade. O SFOS seleciona a opção por padrão assim que uma Política da Web é selecionada na regra ou Scan HTTP and decrypted HTTPS é habilitado. Isso é por regra, não global, portanto verifique a regra de firewall que realmente corresponde. Essa opção não abrange UDP em outras portas. Verifique uma conexão TCP real, o funcionamento da aplicação e a correspondência com o caminho de inspeção pretendido; bloquear UDP, por si só, não comprova nenhum desses pontos.

Este filtro da web não pode verificar o QUIC. Isso não significa que todos os outros controles de firewall sejam ignorados, mas o TCP TLS esperado e o caminho do filtro da web não se aplicam. Bloqueando corretamente QUIC e HTTP/3 no Sophos Firewall mostra o teste de regra; Criando uma Política de Proteção Web do Sophos Firewall abrange a Política Web.

Selecione o escopo por propósito e risco

O ponto de partida usual é o tráfego de usuário gerenciado de LAN para WAN. Uma rede sem fio corporativa separada pode seguir como Wi-Fi > WAN. Para acesso remoto, VPN > WAN só é relevante quando o tráfego de Internet dos usuários realmente atravessa o firewall através de um túnel completo. Inclua conexões internas de LAN para DMZ somente quando a inspeção de conteúdo tiver um benefício claro e o cliente confiar na CA de nova assinatura, enquanto o firewall valida a cadeia original de certificados do servidor. Servidores de destino comuns não precisam ter essa CA de inspeção instalada. Avalie separadamente a compatibilidade com TLS mútuo (mTLS).

A compatibilidade técnica e a permissão para descriptografar são decisões separadas. Portais bancários, de saúde e governamentais, gerenciadores de senhas, provedores de identidade, atualizações de sistemas operacionais e de fornecedores e serviços de voz, vídeo e colaboração exigem uma avaliação funcional e de privacidade antes da inclusão. A fixação ou uma falha piloto não justifica uma exceção geral para uma categoria inteira: primeiro identifique a origem, o domínio e a aplicação realmente necessários.

Configure um piloto completo

Para um piloto que pode ser testado diretamente, usamos estes valores de exemplo:

• Cliente piloto: 10.20.30.50 da rede de teste documentada 10.20.30.0/24
• Regra de firewall: LAN to WAN - TLS pilot
• Regra de inspeção SSL/TLS: TLS decrypt pilot client
• Zona de origem: LAN, Zona de destino: WAN
• Redes e serviços de destino: Any
• Ação: Decrypt
• Perfil de descriptografia: inicialmente Block insecure SSL ou um perfil piloto derivado dele
• Registro: Log connections habilitado para o piloto

10.20.30.0/24, o IP do host e os nomes dos objetos são exemplos. A fonte de produção deve ser estreita o suficiente para identificar um cliente de forma inequívoca. Any para Destino e Serviço facilita a observação de TLS fora do TCP 443 durante o piloto; ela não amplia o que a regra de firewall anterior permite. Se a inspeção for permitida apenas para um grupo de destino específico, adicione um grupo de URLs ou outro critério de destino apropriado.

Selecione um perfil de descriptografia

Em Profiles > Decryption profiles, três perfis padrão não editáveis ​​estão disponíveis:

• Maximum compatibility maximiza a compatibilidade e não restringe cifras.
• Block insecure SSL bloqueia cifras fracas e permite tráfego que não pode ser descriptografado.
• Strict compliance aplica requisitos rigorosos, incluindo requisitos baseados em PCI DSS.

Maximum compatibility pode ajudar a isolar temporariamente um cliente problemático, mas suas verificações relaxadas o tornam inadequado como critério de aceitação de produção. Para o piloto, Block insecure SSL ou um perfil deliberadamente derivado dele é o ponto de partida mais transparente. Tolerar versões TLS antigas ou chaves RSA com menos de 2048 bits apenas para um servidor legado nomeado e em uma regra com escopo restrito.

Rejeição de conexões legadas com Decrypt: Com Action: Decrypt, o Sophos Firewall ainda rejeita conexões que usam SSL 2.0 and SSL 3.0, SSL compression ou Unrecognized cipher suites, mesmo que o perfil selecione Allow without decryption para elas. Uma permissão para conexões legadas explicitamente aprovada e com escopo restrito exige tanto Allow without decryption nos campos relevantes do perfil quanto Action: Don’t decrypt; a permissão no perfil, por si só, é insuficiente.

Um perfil personalizado pode substituir as configurações globais de SSL/TLS. As opções de nova assinatura da CA são Use CAs defined in SSL/TLS settings, Re-sign RSA with e Re-sign EC with. Para tráfego que não pode ser descriptografado, as opções são Use SSL/TLS settings default, Allow without decryption, Drop e Reject. A referência padrão global não se aplica a Unrecognized cipher suites; este caso deve ser avaliado explicitamente no perfil. Dependendo da configuração, erros de certificado, tamanho mínimo de RSA, versões TLS e cifras bloqueadas usam Drop, Reject ou Reject and notify como Block action.

A inspeção não torna confiável um certificado de servidor autoassinado ou com uma cadeia incompleta. Em vez de excluí-lo apressadamente, primeiro verifique o nome do host, o certificado original e a cadeia completa.

Para um original autoassinado, o firewall substitui a chave e assina com essa chave, não como CA confiável: o cliente continua a ver um certificado autoassinado. Se faltar a cadeia completa até uma CA confiável para o firewall, é utilizado um certificado gerado pelo sistema cujo CN explica o problema. Um aviso não indica, portanto, automaticamente uma falha na distribuição da CA.

Crie um perfil personalizado em Profiles > Decryption profiles > Add, com nome e descrição, ou clone um perfil adequado; guarde-o e atribua-o à regra de inspeção. Certificados originais RSA e EC podem frequentemente utilizar a mesma CA de assinatura. Se uma aplicação exigir um tipo de chave específico, selecione a CA correspondente em Re-sign RSA with ou Re-sign EC with. Descarregue cada CA efetivamente utilizada com o botão junto à seleção; se forem utilizadas duas CA diferentes, os clientes devem confiar em ambas.

Antes de guardar, avalie Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version e Cipher algorithms to block. TLS inferior a 1.2 e RSA inferior a 2048 bits não são valores predefinidos seguros. Maximum supported permite a versão máxima suportada do protocolo. A verificação Revoked exige uma CRL importada (Certificate Revocation List); selecionar a caixa não comprova, por si só, que a verificação de revogação funciona. Uma Web Exception para HTTPS decryption pode permitir conexões correspondentes com certificados inválidos: não é apenas uma correção de pinning.

Os erros de certificado incluem Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch e Invalid for other reasons. Name mismatch compara o nome do servidor em Client Hello com os nomes no certificado. Ao escolher algoritmos bloqueados, avalie separadamente a troca de chaves, a autenticação, as cifras de dados e os algoritmos hash. A compressão SSL antes da cifragem tem vulnerabilidades conhecidas; cifras desconhecidas não podem ser descriptografadas.

As definições globais estão em Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. TLS 1.3 decryption oferece Decrypt as 1.3 e Downgrade to TLS 1.2 and decrypt. A segunda opção afeta todas as regras de inspeção SSL/TLS; não reduza TLS globalmente para um piloto normal.

When SSL/TLS connections exceed limit determina o comportamento quando se esgota a capacidade de descriptografia: Allow without decryption mantém a acessibilidade, mas elimina a inspeção do conteúdo; Drop descarta silenciosamente e Reject envia um reset. É uma decisão explícita entre disponibilidade e proteção para o piloto, não apenas um valor de desempenho. Reject and notify tenta mostrar uma página de bloqueio HTTPS com o motivo do erro, sem a garantir; impede a transferência de dados para o servidor.

Com o TLS 1.3, erros de certificado, o tamanho mínimo do RSA, um downgrade global e Reject and notify se comportam conforme documentado apenas com Action: Decrypt. Com Don’t decrypt ou Deny, Reject é usado para esse tratamento de perfil. Um downgrade global para o TLS 1.2 apresenta um risco de segurança e não é uma correção geral de compatibilidade.

Crie a regra e verifique sua ordem

Em Rules and policies > SSL/TLS inspection rules > Add, configure os campos conforme a seguir:

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, portanto, a regra piloto precede as regras gerais de descriptografia personalizadas
3. Action: Decrypt
4. Log connections: habilitado para monitoramento piloto
5. Decryption profile: o perfil piloto selecionado
6. Source zones: LAN
7. Objeto de host Source networks and devices: para 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: vazio ou limitado ao escopo de destino aprovado

Log connections é opcional e não é necessário para que a regra funcione. No entanto, é útil para um piloto com tempo limitado porque o handshake e o fechamento da conexão podem ser rastreados. A retenção deve seguir a política de privacidade e operações acordada.

A tabela é avaliada de cima para baixo e o processamento é interrompido na primeira correspondência. Todos os critérios configurados devem corresponder simultaneamente. A regra padrão fixa Exclusions by website or category permanece na parte superior e não pode ser precedida pela seleção de Rule position: Top. Coloque exceções Don't decrypt personalizadas imediatamente abaixo dele, seguidas por regras piloto específicas e, finalmente, regras de descriptografia mais amplas.

Os critérios de usuário e grupo serão confiáveis ​​somente se o SFOS conhecer o contexto do usuário para a conexão. Se isso não for garantido, comece com um host ou objeto de rede inequívoco e adicione critérios de identidade somente após um teste de correspondência separado.

Depois de Save, volte a verificar o estado e a posição da regra na tabela. More options permite editar, clonar, inserir junto a uma regra e eliminar; Rule handle altera a ordem. Os filtros Source, Destination e Rule ID ajudam na comparação; Reset filter repõe a tabela completa. Action: Deny impede o estabelecimento da conexão e não equivale a Don’t decrypt. Categories and websites é identificado através do SNI no handshake TLS. As instalações novas ativam as regras de inspeção SSL/TLS por predefinição, mas o estado real continua a ser uma verificação prévia.

Distinguir a configuração TLS através da XML API

Em implementações automatizadas, a Inspection Rule, as definições globais de DPI e a configuração de scanning HTTP/HTTPS são três objetos distintos. A seleção de uma CA não ativa a regra-piloto nem o scanning na Firewall Rule. Os mapeamentos seguintes explicam os campos da API do SFOS 22/23. Antes de qualquer operação de escrita, a operação explícita e o payload completo são confirmados em API help do build instalado. A autorização da origem, a conta, a verificação TLS, os segredos e a distinção entre sucesso HTTP e estado XML são explicados em Restringir o acesso à XML API de forma segura e verificar as respostas.

Inspection Rule: identidade, hierarquia e ordem

O objeto chama-se SSLTLSInspectionRule. O seu campo direto Name identifica a regra; no exemplo, NewName é o nome editado para uma alteração de nome, não o nome da regra de referência para uma deslocação. Para o nome da regra, estão documentados um máximo de 60 caracteres, UTF-8 e a ausência de vírgulas; Description está limitado a 255 caracteres. IsDefault é só de leitura e não é utilizado para tornar uma regra-piloto própria na regra predefinida.

Os campos de correspondência permanecem sob os respetivos nós-pai, mesmo quando a tabela de parâmetros apresenta várias vezes o mesmo nome de nó-filho:

• SourceZones > Zone e SourceNetworks > Network: zona de origem interna e objeto de host piloto aprovado.
• DestinationZones > Zone e DestinationNetworks > Network: zona de destino e objetos de destino autorizados.
• Identity > Members: utilizadores ou grupos de origem, apenas com correspondência de identidade verificada.
• Services > Service: objetos de serviço para o âmbito aprovado.
• Websites > Activity > Name e Websites > Activity > Type: nome e tipo do critério de website; o exemplo indica Web Category e URL Group.
• MoveTo > Name e MoveTo > OrderBy: regra de referência e posição relativa; OrderBy utiliza Before ou After.

Zone, Network, Service e as atividades de websites podem ocorrer várias vezes. Um campo Name ou Network sem o nó-pai correto não representa a mesma finalidade. Os nomes dos objetos são retirados da configuração existente; o âmbito e o perfil não são substituídos por campos ausentes ou valores predefinidos não verificados.

Position utiliza Top ou Bottom e serve apenas para a colocação inicial durante ADD. Quando não é especificado, o exemplo indica Bottom; para UPDATE ou APIImport, Position não é necessário e não é aqui adotado como mecanismo de deslocação. O campo opcional MoveTo é aplicado durante ADD depois de Position. Quem definir ambos tem, por isso, de verificar a posição relativa resultante, não apenas o valor Top inicial. A exclusão predefinida fixa permanece no topo; a ordem acima descrita das exceções aprovadas, das regras-piloto e das regras de desencriptação mais abrangentes continua a aplicar-se.

Os campos diretos Enable, LogConnections, DecryptAction e DecryptionProfile têm funções distintas: estado da regra, registo, decisão de desencriptação e atribuição do perfil. Para Enable, a tabela indica Yes, No, t, f; para LogConnections, indica Enable, Disable, t, f. DecryptAction utiliza exatamente Decrypt, Do not decrypt ou Deny. Por isso, o rótulo da interface Don’t decrypt não é um valor XML que possa ser utilizado sem verificação. O perfil escolhido é atribuído em DecryptionProfile com o seu nome real; uma origem estritamente delimitada e o âmbito completo e aprovado de destinos/serviços continuam a ser obrigatórios, mesmo com automatização.

As linhas de estado XML específicas do objeto distinguem a operação e o símbolo:

Message.* permanece aqui um identificador de documentação não resolvido, não um texto garantido em tempo de execução nem uma causa definitiva de erro. Antes de cada nova tentativa, a resposta expurgada de dados sensíveis é comparada com o estado efetivamente guardado: nome original ou novo da regra, estado, critérios completos, DecryptionProfile e posição relativa às outras regras. Mesmo uma linha 200 não substitui esta comparação nem o teste com novas ligações. Se o estado não for claro, parar e esclarecer, em vez de criar uma segunda regra ou uma regra mais abrangente através de um novo ADD ou de outra posição.

Definições globais de DPI: a CA não é um interruptor de ativação/desativação

Sob SSLTLSInspectionSettings, RSACA e ECCA são campos diretos para a seleção da CA de reassinatura dos certificados de servidor RSA e EC, respetivamente. Referenciam objetos de CA, não caminhos de ficheiros nem valores de ativação. O perfil pode sobrepor-se à seleção da CA para a sua regra. Antes de uma alteração, são, por isso, verificados em conjunto o perfil, a CA efetivamente apresentada, a confiança dos clientes e a cadeia de CA raiz/subordinadas; quando são utilizadas CAs diferentes, os clientes têm de confiar em ambas.

Distintos destes são os campos globais diretos SSLTLSEngine e SSLTLSInspection, cada um com Enabled ou Disabled. O primeiro controla a TLS engine e o segundo a SSL/TLS Inspection global, não o estado de uma regra-piloto individual. Desativar a Inspection impede a aplicação das regras e a apresentação de detalhes de ligação/desencriptação no Control Center e no Log viewer. Desativar a Engine retira adicionalmente do percurso a aplicação da política Web de DPI a HTTPS; a desencriptação HTTPS por proxy não é afetada. Nenhuma destas ações constitui uma reversão normal do piloto.

TLS13Decryption também se encontra diretamente sob SSLTLSInspectionSettings e utiliza Decrypt as 1.3 ou Downgrade to TLS 1.2 and decrypt. Seleciona o tratamento global de TLS 1.3, não a CA de assinatura nem a ação de uma regra individual. Uma redução da versão afeta todas as Inspection Rules e não é introduzida como correção de compatibilidade para um único cliente. Os limites já explicados para TLS 1.3 e Action: Decrypt continuam a ser determinantes.

Os restantes campos diretos SSLv2SSLv3, SSLCompression e SSLConnectionsExceeded utilizam, cada um, Allow without decryption, Drop ou Reject. Dizem respeito a situações diferentes e não são equiparados a DecryptAction. Após uma alteração autorizada, são verificados os valores globais guardados, as sobreposições dos perfis e o percurso real do piloto. Apenas as alterações documentadas decorrentes do piloto são repostas no seu estado anterior exato, sem desativação indiscriminada dos controlos.

Scanning HTTP/HTTPS: respeitar o respetivo nó-pai

O objeto separado AntiVirusHTTPsConfiguration contém diretamente ScanMode, FileSizeThreshold, AudioVideoFileScanning e PUADetection. Por sua vez, no nó-filho HTTPSConfigurations encontram-se HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate e NoHttpsNotification. Assim, HTTPSScanningCA pertence à configuração HTTP/HTTPS do percurso por proxy, não a RSACA ou ECCA das definições de DPI. Estes campos não substituem a correspondência da regra de DPI nem Decrypt HTTPS during web proxy filtering na Firewall Rule adequada. O contexto do scanning é explicado em Enquadrar o scanning de malware na Sophos Firewall.

ScanMode indica RealTime e BatchMode. FileSizeThreshold é especificado em KB; a tabela indica de 1 a 1572864, um máximo de 7 algarismos e o valor predefinido 1024. Os ficheiros acima do limiar não são analisados; o valor predefinido documentado não é uma recomendação para todos os ambientes.

Contradição de valores não resolvida: Para AudioVideoFileScanning, o exemplo XML apresenta Enable/Disable, enquanto a tabela de parâmetros indica on/off e o valor predefinido Disable. Daqui não se deduzem aliases intercambiáveis. Também para DenyUnknownProtocol e AllowInvalidCertificate, o exemplo apresenta Enable/Disable, enquanto a tabela indica apenas on e on/off, respetivamente; para PUADetection, são apresentados aí valores simbólicos. Antes de uma alteração automatizada, API help ou o Support têm de confirmar os valores válidos para o objeto e o build. Sem esse esclarecimento, não executar o pedido de escrita afetado; não flexibilizar os controlos de certificados para viabilizar uma importação.

Após uma alteração aprovada, a seleção da CA e os controlos guardados em Web > General settings, o percurso proxy/DPI que efetivamente corresponde e o emissor visível do certificado são comparados com o estado anterior. Só depois são realizados os testes funcionais, positivos e negativos de exceção. Uma configuração de scanning formalmente aceite não comprova a desencriptação nem um scanning de malware eficaz.

Mantenha as exceções restritas

A regra padrão Exclusions by website or category utiliza Don’t decrypt com Maximum compatibility e permanece na primeira posição. A Local TLS exclusion list está vazia por padrão; a Managed TLS exclusion list contém sites incompatíveis conhecidos e é mantida por meio de atualizações de firmware.

Edite a lista local em:

Web > URL groups > Local TLS exclusion list

Grupos de URL ou correspondências SNI são mais eficientes para exceções de domínio do que muitos hosts FQDN. De acordo com a Sophos, por exemplo, 200 hosts FQDN causam 200 consultas para cada nova ligação SSL/TLS. A restrição de combinar exceções de origem e destino deve ser distinguida da correspondência normal das regras. Criar e usar grupos de URL com segurança explica o escopo do domínio, curingas e testes negativos.

Uma regra de inspeção SSL/TLS personalizada com Action: Don’t decrypt deve registrar o domínio, a fonte afetada, o motivo, o ticket, o proprietário e a data de revisão. Don’t decrypt não é um desvio incondicional: as restrições do perfil de descriptografia selecionado ainda se aplicam. Para permitir SSL 2/3, compactação ou cifras desconhecidas para um caso legado explicitamente aprovado, use um perfil com Allow without decryption junto com Action: Don’t decrypt. Esta combinação não pertence a uma regra ampla da Internet.

Exclusões SSL/TLS e exceções da Web resolvem problemas diferentes. Uma exceção TLS controla a descriptografia em qualquer porta TCP no modo DPI. Uma exceção da Web altera as verificações selecionadas da política da Web; no modo proxy, afeta o caminho do proxy relevante. Antes de fazer uma alteração, determine se a descriptografia ou apenas uma verificação da web deve ser excluída. Criar e testar exceções da Web com segurança mostra o fluxo de trabalho de seleção e regex.

Âmbito de exceção pouco claro: O guia de exclusão de sites diz que as exceções de origem e destino não podem ser combinadas; o guia das regras disponibiliza ambos os campos de correspondência. Isto não comprova que uma Web Exception com IP de origem e destino combinados seja permitida. Mantenha a restrição da origem do piloto com um hostname confirmado ou um URL Group. Se ambos os critérios de exceção IP também forem obrigatórios, não ative nem alargue a exclusão antes de obter esclarecimento de Support específico para a build. Não remova um critério apenas para obter uma correspondência.

Para um caso antigo expressamente aprovado, crie um perfil como Allow_non-decryptable_profile em Profiles > Decryption profiles > Add. Defina Allow without decryption apenas nos campos necessários: SSL 2.0 and SSL 3.0, SSL compression ou Unrecognized cipher suites. Em Rules and policies > SSL/TLS inspection rules > Add, atribua o perfil a uma regra Don’t decrypt restrita, com a origem do piloto, um âmbito de origem interno, o destino apropriado e um alvo conhecido. Isto reduz a proteção para um caso antigo justificado, não autoriza genericamente estes protocolos.

Sem SNI utilizável, um URL Group ou regex de domínio não identifica o alvo. Depois de verificar o fluxo real, pode ser adequado um IP Host restrito em Destination networks; um FQDN Host continua a ser uma alternativa baseada em DNS com os custos descritos. Para regex, um início ancorado ^ e um teste negativo são importantes; wildcards amplos também podem tornar o processamento mais lento. A ligação Web Exceptions acima explica a sintaxe segura completa e a diferença relativamente às listas de domínios.

Compatibilidade com Android num âmbito restrito

Algumas conexões Android usam fixação de certificado. A verificação de conectividade, Play Store ou atualizações podem falhar na descriptografia. O fluxo de trabalho documentado pela Sophos usa uma VLAN isolada ou rede sem fio e um grupo de hosts FQDN contendo:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• o domínio local do Google, por exemplo *.google.ch na Suíça

Crie o grupo em Hosts and services > FQDN host group > Add. Em Hosts and services > FQDN host > Add, crie um host por domínio e atribua-o diretamente ao grupo. Crie uma nova rede sem fios Sophos em Wireless > Wireless networks > Add e o seu objeto de rede em Hosts and services > IP host > Add, com IP version: IPv4, Type: Network, o endereço e a máscara da sua rede. Para uma VLAN ou rede sem fios isolada já existente, utilize o objeto adequado em vez de criar uma rede sem necessidade confirmada. Confirme a zona de entrada real atribuída a essa interface ou VLAN; Wi-Fi é o exemplo de rede sem fios Sophos, não um requisito para todas as redes de dispositivos móveis.

A documentação geral recomenda uma exceção para todos os dispositivos Android; o procedimento concreto limita-a aos destinos Google numa rede móvel isolada. Esta implementação segue o procedimento mais restrito com testes positivos e negativos, não um bypass global para todas as conexões Android. Mudar para Web Proxy é uma decisão arquitetural distinta, não uma correção automaticamente equivalente do pinning.

Acima da regra geral de descriptografia, adicione uma regra de inspeção SSL/TLS com Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone definida como a zona de entrada real da rede móvel (por exemplo, Wi-Fi, LAN ou uma zona personalizada configurada), a rede do dispositivo móvel como Source networks and devices, WAN como Destination zone e o grupo do Google como Destination networks. Fica abaixo da exclusão padrão fixa, mas acima da regra geral de descriptografia. Mantenha a rede móvel isolada de recursos internos confidenciais.

Aceite a alteração usando um dispositivo piloto Android: execute a verificação de conectividade, teste o acesso pelo browser, descarregue uma aplicação de teste aprovada do Google Play e atualize uma aplicação instalada através do Google Play. Cada operação tem de ser concluída com êxito. No Log viewer, apenas os destinos esperados do Google podem corresponder à exceção; outro destino HTTPS da mesma VLAN ainda deve usar a regra de descriptografia pretendida. Confirme a zona de origem e o objeto de origem reais, a correspondência com a exceção do Google e a correspondência com a regra de descriptografia pretendida para esses fluxos reais. Use um dispositivo piloto gerenciado cujo navegador ou aplicativo específico de teste confie na CA de inspeção; verifique o funcionamento bem-sucedido e as evidências no certificado e nos logs para o destino descriptografado. Mantenha fora do escopo de Decrypt os clientes ou aplicativos cuja confiança na CA de inspeção não possa ser gerenciada. Este teste negativo impede a aceitação de uma exceção que funciona, mas é muito ampla. Criar exceções da Web e exclusões de TLS com segurança aborda outros métodos e limitações de SNI.

Comprovar o funcionamento

Uma simulação de política, um cliente real e os logs respondem a diferentes questões. Combine-os para obter um teste de aceitação confiável.

Em Diagnostics > Tools > Pop-out tools > Policy tester, selecione Firewall, SSL/TLS, and web e defina o IP de origem, destino ou URL, protocolo e, se necessário, a porta. Sem um protocolo, a ferramenta testa o HTTP usando a porta padrão específica do protocolo. O testador de políticas simula tráfego transparente da web; ele não modela rotas SD-WAN e as regras com endereços MAC em Source networks and devices não correspondem lá. Web policy only testa apenas a Política da Web. O resultado é, portanto, uma previsão, não uma prova do caminho real dos dados.

Execute quatro testes direcionados no cliente:

1. Antes da mudança, registre o domínio de destino, o emissor do certificado, o tempo de resposta e se o aplicativo de negócios funciona.
2. Abra um destino positivo aprovado e verifique o caminho de inspeção escolhido. Para DPI, o navegador deve mostrar a CA de nova assinatura selecionada para DPI como emissor, e Log viewer deve corresponder à regra de descriptografia e ao perfil de descriptografia esperados. Para Web Proxy, verifique a CA selecionada em Web > General settings > HTTPS scanning certificate authority (CA), a regra de firewall que realmente corresponde com Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering, e as evidências correspondentes nos logs de proxy/web de que a solicitação foi bem-sucedida. Não exija correspondência com uma regra/perfil de DPI nem uma entrada no widget de DPI para uma conexão descriptografada pelo proxy.
3. Abra um destino deliberadamente excluído. Deve corresponder à regra Don't decrypt esperada; o navegador não deve mostrar um certificado assinado novamente pelo firewall.
4. Um segundo destino não excluído do mesmo escopo de cliente ainda deve ser descriptografado. Este é o teste negativo da exceção.

Se uma Política da Web fizer parte do design, bloqueie também uma categoria de teste ou URL de teste especificamente aprovado para essa finalidade. Executar um teste de malware apenas com um objeto de teste de fornecedor inofensivo e um resultado esperado predefinido. Antes e depois do piloto, compare a carga de CPU e memória, o tempo de resposta e os erros do usuário na mesma janela de tempo.

Interpretar corretamente Control Center e Log viewer

O widget do Centro de Controle é denominado SSL/TLS connections. Seus detalhes são atualizados a cada cinco minutos. As sessões cobrem as últimas 24 horas e os erros os últimos 7 dias; Failed é redefinido à meia-noite. Os dados detalhados não incluem conexões Web Proxy. Decryption peak aparece apenas próximo ou acima do pico e Decryption limit apenas próximo ao limite específico do dispositivo. Portanto, não existe um limite universal para todos os aparelhos.

Abra Log viewer no canto superior direito e selecione o módulo SSL/TLS inspection. Uma conexão TLS é registrada após a conclusão do handshake e quando ele é fechado. Ação, regra, perfil de descriptografia, origem, destino, domínio e o motivo do erro são importantes; as cores por si só não são um critério de aceitação confiável. Em Manage > Exclude, você pode adicionar domínios ou subdomínios à lista de exclusão TLS local e categorias à exclusão padrão. Exclude não está disponível para IDs de erro 19004 e 19005.

Um evento Don't decrypt prova apenas que a conexão não foi descriptografada. Somente a Regra, a correspondência de lista e o teste negativo mostram se a exceção é justificada e suficientemente restrita.

Solucione problemas e reverta com segurança

Quando ocorrer um incidente, limite inicialmente o caso a um cliente, um domínio, um momento específico, uma regra de firewall e uma regra de inspeção SSL/TLS.

• Se o navegador exibir um aviso de certificado, compare o emissor visível com a CA usada pelo DPI real ou pelo caminho do proxy. Em seguida, verifique o armazenamento confiável do cliente, a cadeia raiz/subordinada e o nome do host.
• Se faltarem eventos SSL/TLS, verifique primeiro a correspondência da regra de firewall e o modo. Em seguida, confirme se Rules and policies > SSL/TLS inspection rules e Advanced settings > SSL/TLS engine > Enabled estão ativos.
• Se o tráfego for permitido, mas não descriptografado, pesquise de cima para baixo a exclusão padrão fixa, a lista gerenciada/local ou uma regra Don't decrypt personalizada. Em seguida, repita o teste negativo.
• Se o filtro da web não se aplicar, verifique a regra de firewall real para sua política da web, Scan HTTP and decrypted HTTPS, Block QUIC protocol e modo DPI/proxy. A presença de uma Política da Web não prova a descriptografia.
• Se apenas um aplicativo falhar, use o motivo do erro, a versão do TLS, a cifra, a cadeia de certificados e a fixação para orientar a próxima decisão. Mantenha qualquer exceção temporária restrita e estabeleça uma data de revisão.
• Se a carga aumentar, reduza o escopo do piloto e compare a mesma janela de tempo antes e depois da mudança. Avalie avisos de pico ou limite para o aparelho específico.

Desative o SSL/TLS engine apenas brevemente para solução de problemas. Enquanto desativado, nenhuma regra de inspeção SSL/TLS se aplica e o mecanismo DPI não aplica a política da Web do firewall a HTTPS; A descriptografia HTTPS do proxy da Web permanece inalterada. Desabilitá-la não é, portanto, um substituto equivalente e de baixo risco para desabilitar especificamente a regra piloto.

Teste IPS independente de porta apenas com um estado inicial conhecido

Por padrão, o SFOS verifica o tráfego descriptografado em relação às assinaturas IPS em cada porta TCP. Para um falso positivo reproduzível, documente o ID da assinatura, a origem, o destino, a porta TCP, a regra de firewall, a regra de inspeção e a build do SFOS. Prefira uma exceção de assinatura restrita com Action: Allow packet na Política IPS realmente em uso; Configurar e testar o Sophos Firewall IPS descreve esse método.

Um possível sintoma de um problema com a inspeção independente da porta são as correspondências repetidas da mesma assinatura IPS no mesmo sítio Web. A repetição, por si só, não prova um falso positivo. Verifica-se a correspondência exata da Signature ID e do destino nos registos, confirma-se o fluxo de trabalho legítimo afetado e avalia-se o risco antes de aprovar uma exceção de assinatura de âmbito restrito e reversível.

A inspeção mais abrangente de potenciais ameaças pode aumentar a carga e reduzir ligeiramente o débito do tráfego HTTPS decifrado em comparação com versões anteriores do Sophos Firewall. Trata-se de um possível efeito associado à versão, não de uma redução garantida nem de uma prova de regressão da build atualmente utilizada. Para contextualizar os resultados, comparam-se o débito, a carga de CPU e memória e o tempo de resposta sob uma carga de tráfego comparável na mesma janela temporal; uma única comparação não substitui a análise das causas.

Uma comparação global no Console do dispositivo será permitida somente se o valor atual exato, on ou off, já for conhecido do registro de alteração ou de uma configuração com backup confiável. A documentação oficial do SFOS 22 não oferece pré-verificação somente leitura para esta opção. Se o estado inicial for desconhecido, não realize o teste.

Somente com um estado inicial documentado de on você pode definir o seguinte para uma comparação preparada:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

O segundo comando aqui restaura apenas o estado inicial conhecido de on. Se o estado inicial for off, não o habilite cegamente; retenha off ou restaure-o exatamente após qualquer alteração autorizada. Essa configuração global afeta todo o firewall e pode reduzir ligeiramente o rendimento ou, com off, restringir o escopo da inspeção. Documente o resultado e o intervalo de tempo sem tratar isso apenas como prova de uma causa geral.

Executar o rollback numa ordem definida

Uma reversão restaura o estado inicial documentado em vez de introduzir uma nova arquitetura:

1. Antes de desativar TLS decrypt pilot client, verifique a regra registrada que passará a corresponder e o plano de restauração aprovado: uma regra Decrypt mais abrangente abaixo dela pode assumir o tráfego. Desative a regra piloto e restaure as alterações documentadas e exclusivas do piloto nas regras de firewall, no modo DPI/proxy, na Política da Web e nas configurações globais, na ordem preparada, sem alterações simultâneas não relacionadas.
2. Estabeleça novas conexões a partir do cliente piloto e verifique o caminho inicial de correspondência registrado, o emissor do certificado, os logs e o funcionamento da aplicação. Não presuma que as sessões existentes serão reavaliadas imediatamente. Se uma regra Decrypt inferior assumir o tráfego ou a restauração falhar, interrompa a limpeza: a reversão não está concluída. Identifique a correspondência real e restaure apenas a ordem das regras, os critérios e as configurações autorizados necessários para reproduzir o estado inicial; depois, repita essas verificações com novas conexões.
3. Somente se o caminho inicial não era descriptografado e o plano de recuperação aprovado exigir isso, use uma regra Don't decrypt com limite de tempo e escopo restrito para a origem piloto e os destinos necessários, posicionada antes da regra Decrypt inferior que corresponde indevidamente, mas abaixo das exclusões aprovadas aplicáveis. Execute os testes positivo e negativo dessa regra; não improvise um desvio amplo nem substitua um percurso anteriormente verificado por outro que não tenha sido verificado.
4. Remova as exceções temporárias, objetos de teste e a confiança/configurações de CA exclusivas do piloto somente após verificar a restauração e obter aprovação para a remoção. Mantenha a confiança na CA ainda necessária para o caminho ativo até que essas verificações sejam bem-sucedidas; não remova CAs compartilhadas sem verificar as dependências.
5. Registre o ID da regra, o cliente, o destino, a CA visível, o evento de log, a hora e as configurações restauradas no registro de alteração.

A Política da Web pode permanecer configurada, mas sem a Descriptografia ela não poderá verificar a carga HTTPS criptografada. Reverter para Web Proxy somente se esse for o estado inicial verificado. Não desative todo o mecanismo SSL/TLS como reversão padrão porque isso interrompe todas as regras DPI TLS e a aplicação da Política Web DPI para HTTPS.

Interrompa a implementação assim que um aplicativo crítico para os negócios falhar, avisos de certificado aparecerem fora do grupo piloto, o escopo corresponder de forma mais ampla do que o esperado ou a carga e os erros excederem os limites predefinidos. Expanda o grupo Origem gradualmente somente depois que o teste positivo, o teste negativo de exceção, os aplicativos de negócios, os logs, o feedback do usuário e o perfil de carga atenderem aos critérios acordados durante o período acordado.

Durante a operação, revise exclusões, erros de TLS, novos aplicativos, carga e feedback do usuário em um cronograma definido. Mantenha as exceções temporárias apenas enquanto o proprietário, o motivo e a data da revisão permanecerem válidos; caso contrário, remova-os após um novo teste positivo e negativo.

PERGUNTAS FREQUENTES