Bloquear corretamente QUIC e HTTP/3 no Sophos Firewall

QUIC é um protocolo de transporte moderno e cifrado sobre UDP; o HTTP/3 usa QUIC como transporte. Os termos estão, por isso, estreitamente ligados, mas não são sinónimos. Os navegadores e serviços web usam geralmente HTTP/3 sobre UDP 443. Para administradores, o ponto decisivo é que este caminho não corresponde ao HTTPS clássico sobre TCP.

No Sophos Firewall, isto é importante porque a documentação do SFOS 22 afirma que o filtro web não consegue analisar QUIC e que QUIC contorna o Web Filtering. Se uma regra de cliente tiver de impor uma Web Policy, verificação de malware ou inspeção TLS baseada em TCP, Block QUIC protocol é o método padrão documentado. A opção não espera por identificar um handshake QUIC: no âmbito da regra correspondente, descarta todos os pacotes UDP de saída destinados às portas 80 e 443.

Qual artigo de proteção web é adequado?

O QUIC geralmente não é o objetivo principal, mas sim um fator de interferência em cenários de proteção web, inspeção TLS ou troubleshooting. Dependendo da tarefa, faz sentido começar por outro artigo:

• Planear Web Policy, URL Groups, SafeSearch e filtro web em geral: Configurar proteção web no Sophos Firewall com políticas web.
• Operar categorias web e Instant Alerts: Utilizar categorias web e alertas instantâneos no Sophos Firewall.
• Desencriptar tráfego HTTPS e implementá-lo de forma controlada: Introduzir corretamente a inspeção TLS no Sophos Firewall.
• Verificar qual regra de firewall faz realmente match: Testar regra do Sophos Firewall com Log Viewer e Packet Capture.

Este artigo responde sobretudo à questão de quando e como bloquear QUIC ou HTTP/3 na regra de firewall adequada e depois validar corretamente o resultado.

O que o QUIC significa para o firewall

O HTTPS clássico funciona geralmente sobre TCP 443. Dependendo da regra, da Web Policy, da DPI Engine, do Web Proxy e da inspeção SSL/TLS, a firewall pode decidir se o tráfego é apenas permitido, categorizado, desencriptado, verificado ou bloqueado.

O HTTP/3 transfere este tráfego web para QUIC sobre UDP. Para a firewall, isto significa:

• O tráfego web não parece mais como o HTTPS clássico sobre TCP.
• O QUIC pode contornar o Web Filtering do SFOS e não pode ser analisado por este filtro web.
• A inspeção TLS não atua como no HTTPS normal sobre TCP.
• O troubleshooting torna-se mais difícil quando os navegadores alternam automaticamente entre TCP e QUIC.
• O Policy Tester, Log Viewer e Packet Capture devem ser conscientemente comparados com o protocolo e a porta.

A opção Block QUIC protocol descarta pacotes UDP de saída para as portas de destino 80 e 443 quando o tráfego cumpre os critérios da regra. Se o cliente usar outra regra, a opção não tem efeito. Como o bloqueio se baseia nas portas, também pode afetar aplicações que não usam QUIC mas usam UDP 80 ou 443. Os navegadores comuns tentam normalmente HTTPS sobre TCP quando o HTTP/3 falha, mas este fallback deve ser verificado para cada aplicação crítica.

Isto não desencripta automaticamente HTTPS. O bloqueio de QUIC apenas coloca o tráfego num caminho TCP mais controlável. Se depois Web Policy, Malware Scan, Application Control ou TLS Inspection se aplicam, isso depende do resto da configuração da regra e da inspeção.

Quando bloquear o QUIC

Em muitas redes produtivas de clientes, bloquear o QUIC faz sentido se uma ou mais destas afirmações se aplicarem:

• O filtro web deve funcionar de forma fiável.
• A verificação de malware para downloads web é importante.
• A inspeção TLS é usada para categorias ou grupos de utilizadores selecionados.
• O controlo de aplicações deve reconhecer melhor as aplicações web.
• Os acessos web devem ser rastreáveis no Log Viewer.
• A equipa de suporte e segurança deve conseguir realizar testes reproduzíveis.

Permitir QUIC pode ser uma decisão consciente numa Wi-Fi de convidados sem Web Filtering nem inspeção de conteúdo; documenta-se então que o filtro web do SFOS não analisa esse caminho UDP. Para redes geridas ou âmbito de conformidade, o bloqueio por regra costuma ser mais justificável. Servidores e aplicações especializadas são testados separadamente, pois nem todos os clientes QUIC garantem fallback para TCP.

Verificar configuração na regra de firewall

O local normal é a regra de firewall de saída, por exemplo LAN_to_WAN_Clients. No SFOS 22, a opção está em Security features > Web filtering > Block QUIC protocol.

Caminho do menu:

Rules and policies > Firewall rules

Procedimento:

Para um piloto, pode copiar-se a regra de Internet existente ou criar acima uma regra restrita. Um exemplo documentável usa Source zones: LAN, Source networks and devices: CLIENT-WEB-01 com 10.20.30.50, Destination zones: WAN, Destination networks: Any e os Services e Security Policies já necessários em produção. O IP e os nomes são substituídos por um cliente inequivocamente identificável; Destination, NAT e perfis de proteção mantêm-se inicialmente inalterados.

1. Abrir a regra de internet dos clientes afetada.
2. Aceder a Security features > Web filtering.
3. Ativar Log firewall traffic, para que os testes fiquem visíveis no Log Viewer.
4. Verificar a Web Policy prevista e Scan HTTP and decrypted HTTPS.
5. Manter Block QUIC protocol ativado ou ativá-lo conscientemente.
6. Ativar Scan HTTP and decrypted HTTPS apenas se também estiver claro como o HTTPS é desencriptado.
7. Em DPI Mode, verificar se Use web proxy instead of DPI engine não está ativo por engano.
8. Em Web Proxy Mode, verificar se Decrypt HTTPS during web proxy filtering e a distribuição da CA correspondem ao objetivo.
9. Guardar a regra.
10. Verificar o cliente de teste e controlar o Log Viewer.

O SFOS 22 seleciona Block QUIC protocol por predefinição quando se escolhe uma Web Policy ou se ativa Scan HTTP and decrypted HTTPS. É uma predefinição da interface para essa regra, não uma política global. Após migrações, cópias ou alterações da ordem, volta a verificar-se a regra que realmente corresponde.

Mais detalhes sobre as opções individuais de uma regra de firewall estão em Entender e configurar corretamente as regras do Sophos Firewall.

Não desativar o QUIC apenas pelo navegador

No passado, era comum desativar o QUIC diretamente no navegador ou através de Chrome Flags. Isto pode ajudar em testes, mas não é um conceito de segurança fiável:

• As definições do navegador mudam.
• Não apenas o Chrome pode usar QUIC ou HTTP/3.
• Utilizadores ou atualizações podem repor definições.
• Dispositivos BYOD, convidados e não geridos são difíceis de controlar desta forma.
• As políticas de segurança devem ser rastreáveis centralmente na firewall.

Para ambientes produtivos, a regra de firewall é o melhor local. Testes no navegador podem ser úteis como complemento quando se pretende delimitar um erro.

Enquadrar corretamente Application Control e regras UDP próprias

Além de Block QUIC protocol, existem outras formas de restringir o tráfego QUIC.

• Block QUIC protocol na regra de firewall: Caso padrão para filtro web e scanning. Limite: a configuração só se aplica ao tráfego que faz match nesta regra.
• Application Control: a deteção e o logging por assinaturas podem complementar o bloqueio. Em Applications > Application list, verifica-se se a versão atual dos patterns oferece uma entrada QUIC adequada; uma captura histórica não comprova o catálogo atual. Um Application Filter só atua depois de ser atribuído à regra correspondente em Other security features > Identify and control applications (App control).
• Regra de Drop própria para UDP 80/443: Bloqueio técnico muito claro. Limite: a regra tem de estar corretamente posicionada e limitada às redes de clientes.
• Configuração do navegador: Útil para testes curtos ou ambientes especiais geridos. Limite: não é robusta o suficiente como única política de firewall.

Se for usada uma regra de Drop própria, esta deve ficar acima das regras gerais de internet dos clientes e ser registada corretamente. Caso contrário, mais tarde não será possível perceber se o QUIC foi bloqueado conscientemente ou se o tráfego ficou preso noutro ponto.

Se a alteração exigir uma regra de bloqueio separada, cria-se por exemplo QUIC_UDP_80_443 em Hosts and services > Services > Add com Type of service: UDP e Destination port: 80,443. O valor predefinido Source port: 1:65535 permanece inalterado. A regra acima do Allow geral usa Action: Drop, Source zones: LAN, o objeto piloto em Source networks and devices, Destination zones: WAN, Destination networks: Any, este Service e Log firewall traffic. Nome, Source scope e posição são adaptados; os portos UDP mantêm-se restritos e o possível impacto não QUIC é validado separadamente.

Application Control não substitui de forma equivalente a opção documentada baseada em portas quando se pretende impor o caminho TCP do filtro web. As assinaturas mudam com as atualizações dos patterns e as micro apps baseadas em URL exigem que a DPI Engine veja o URL desencriptado. Por isso, correlacionam-se os logs Application, Firewall, Web e SSL/TLS Inspection.

Relação com a inspeção TLS

Block QUIC protocol não é um substituto para a inspeção TLS. A configuração apenas garante que os navegadores, para tráfego correspondente, não continuem a comunicar por QUIC, mas normalmente regressem a HTTPS sobre TCP.

Só então surge a questão real do TLS:

• Existe uma regra de inspeção SSL/TLS adequada?
• O certificado CA está distribuído nos clientes?
• O tráfego é desencriptado ou conscientemente não desencriptado?
• Scan HTTP and decrypted HTTPS está ativo na regra de firewall?
• Existem exceções para aplicações com Certificate Pinning?

Se os conteúdos HTTPS devem ser verificados, é necessário um rollout TLS planeado. Os detalhes estão em Introduzir corretamente a inspeção TLS no Sophos Firewall.

O modo de operação da regra é importante. Em DPI Mode, aplicam-se as SSL/TLS Inspection Rules em Rules and policies > SSL/TLS inspection rules. Em Web Proxy Mode, a HTTPS Decryption é controlada através das definições do Web Proxy e da opção Decrypt HTTPS during web proxy filtering. Quando estes dois modelos são misturados, o QUIC rapidamente parece ser o problema principal, embora a arquitetura de inspeção é que esteja pouco clara.

Escolher corretamente entre DPI Engine e Web Proxy explica a decisão funcional e de migração entre estes caminhos de tráfego.

Demonstrar o efeito com testes positivo e negativo

O simples facto de o site estar acessível não comprova o fallback. A validação separa três questões: a regra prevista descartou UDP 443, foi depois estabelecida uma nova ligação TCP e a decisão Web ou TLS esperada foi aplicada nesse caminho?

Procedimento de teste prático:

1. Registar o estado anterior, Rule ID, IP do cliente, destino e hora. Confirmar primeiro que o destino gera uma tentativa UDP 443; caso contrário, o teste nada demonstra sobre QUIC.
2. Ativar Log firewall traffic e, opcionalmente, repor o Usage Counter da regra piloto.
3. Em Diagnostics > Packet capture, clicar em Configure e introduzir host 10.20.30.50 and proto UDP and dst port 443 em Enter BPF string, substituindo o IP. Iniciar a captura, fechar e reabrir totalmente o navegador e aceder ao destino preparado.
4. Em Diagnostics > Packet capture > Display filter, filtrar por Source IP, Destination port: 443, Reason: Firewall e Rule ID esperada. Um pacote UDP com estado Violation nessa regra é a prova positiva; a simples ausência de UDP não é.
5. Alterar o filtro para host 10.20.30.50 and proto TCP and dst port 443 e criar uma nova ligação. O handshake TCP e a Rule ID esperada comprovam o caminho.
6. Em Log viewer > Firewall, correlacionar hora, Source IP, destino, Rule ID, protocolo e porta. As sessões aparecem frequentemente no Connection Destroy event; uma ligação aberta também é verificada em Current activities > Live connections.
7. Para Web Protection, efetuar no mesmo âmbito um pedido permitido e outro bloqueado pela Web Policy. Para TLS Inspection, verificar ainda SSL/TLS inspection, a Decryption Rule e o emissor do certificado visível. Scan HTTP and decrypted HTTPS não comprova por si só a desencriptação.
8. Como teste negativo, retirar temporariamente o cliente do âmbito ou repor o estado anterior de Block QUIC protocol, criar uma sessão e confirmar que UDP 443 reaparece no caminho previsto. Depois repõe-se o estado aprovado.

Para testes de regras, a instrução Testar regra do Sophos Firewall com Log Viewer e Packet Capture é adequada.

Erros comuns

• Bloqueio de QUIC ativado apenas numa regra antiga ou errada: O tráfego atual do cliente passa por outra regra.
• A regra está abaixo de uma regra Allow mais geral: QUIC é permitido antes.
• Logging está desativado: No Log Viewer não se vê o que acontece.
• Sessão existente do navegador continua a ser usada: Reiniciar o navegador ou usar um perfil de teste antes de avaliar os logs.
• Apenas o Chrome foi ajustado localmente: Outros navegadores ou dispositivos continuam a usar QUIC.
• Espera-se TLS Inspection, mas esta não está configurada: Os conteúdos HTTPS não são desencriptados apesar do bloqueio de QUIC.
• Scan HTTP and decrypted HTTPS é mal interpretado: A opção verifica apenas HTTPS já desencriptado.
• DPI Mode e Web Proxy Mode são misturados: A configuração procurada pode então estar noutro local.
• UDP 443 é bloqueado globalmente: Aplicações especiais podem ser afetadas de forma inesperada.

Troubleshooting e versões do SFOS 22

Se o filtro web ou o scanning não funcionarem como esperado, deve-se verificar esta sequência:

1. Qual regra de firewall faz realmente match no tráfego do cliente?
2. Block QUIC protocol está ativo exatamente nesta regra?
3. O cliente usa UDP 443 ou TCP 443?
4. Log firewall traffic está ativado?
5. Uma regra mais específica está acima?
6. Existe uma política de controlo de aplicações que trata o QUIC de forma diferente?
7. Existe uma regra de inspeção SSL/TLS se o conteúdo HTTPS deve ser verificado?
8. Está a ser usado DPI Mode ou Web Proxy Mode?
9. O Packet Capture mostra pacotes UDP 443 de saída apesar do bloqueio esperado?

Se a captura ainda mostrar pacotes Forwarded, verificam-se primeiro Rule ID, objeto Source, caminho IPv4/IPv6, Services e ordem das regras. O pacote pode corresponder a outra regra; selecionar uma regra que não corresponde não cria um bloqueio global. Se não existir qualquer tentativa UDP, usa-se outro destino compatível com HTTP/3 antes de atribuir uma falha à firewall.

Se a Web Policy não atuar após o fallback para TCP, QUIC não é automaticamente a causa. Para regras com vários utilizadores ou grupos, a build também importa: as Release Notes oficiais indicam em SFOS 22.0 MR1 Build 490 o fix NC-176376 para regras Web Policy com mais de um grupo ou utilizador que deixaram de funcionar após a atualização para 22.0 GA. Verificam-se build, Rule ID e contexto do utilizador antes de alterar QUIC ou TLS; qualquer atualização segue o processo normal de backup e change.

Se a regra não fizer match, o problema principal não é o QUIC, mas sim a ordem das regras, Source Zone, Source Network, Destination, Service ou Exclusion. Para isso, ajuda Verificar causas de regra de firewall não correspondente.

Checklist operacional

• Regra de internet do cliente afetada identificada claramente.
• Política web, verificação de malware ou inspeção TLS verificada exatamente nesta regra.
• Block QUIC protocol ativado conscientemente ou desativado com justificativa.
• DPI Mode ou Web Proxy Mode decidido conscientemente.
• Ordem das regras e regras de permissão mais gerais verificadas.
• Log firewall traffic ativo.
• Teste realizado com navegador e site de destino real.
• Log Viewer verificado para UDP 443, TCP 443, ID da regra e eventos web.
• Para inspeção TLS, logs de inspeção SSL/TLS verificados adicionalmente.
• Exceções ou regras UDP próprias documentadas.
• O suporte técnico sabe que, após o bloqueio de QUIC, os sites normalmente devem continuar a funcionar.

Rollback

Antes do piloto, registam-se estado e posição da regra, Block QUIC protocol, Web Policy, Application Filter, logging, NAT e modo TLS/proxy. Para voltar atrás, desativa-se a regra piloto ou repõe-se exatamente o estado anterior das opções e políticas. Fecham-se navegador e sessões e uma nova ligação deve mostrar a Rule ID e o comportamento UDP/TCP anteriores. Só depois se removem objetos exclusivos do piloto; não se eliminam Services, filtros ou regras NAT partilhados.

Perguntas Frequentes