Criar e utilizar URL Groups de forma segura na Sophos Firewall

Um URL Group agrupa domínios concretos para que possam ser utilizados em conjunto numa Web Policy ou numa SSL/TLS inspection rule. Parece simples, mas tem uma consequência importante: cada alteração ao grupo afeta todas as regras e políticas que referenciam este objeto.

Por isso, o processo seguro não começa com a maior lista possível do fabricante. Primeiro, são registados os domínios realmente utilizados com base num pedido, num log ou na documentação do fabricante. Em seguida, cria-se um pequeno grupo com objetivo, responsável e plano de testes claros.

URL Group em sete passos

1. Documentar o cliente afetado, os hosts de destino reais e a decisão pretendida: permitir, bloquear ou não desencriptar.
2. Confirmar que um URL Group é realmente adequado. Este processa domínios, mas não caminhos de URL, strings de consulta ou expressões regulares.
3. Em Web > URL groups > Add, definir um nome descritivo e aceitar cada nome de domínio válido com Add.
4. Selecionar o grupo como Activity numa Web Policy ou em Categories and websites numa SSL/TLS inspection rule.
5. Verificar a ordem das regras, o estado, o âmbito de origem e o logging. Um grupo por si só ainda não permite nem bloqueia nada.
6. Com uma nova ligação, testar uma correspondência esperada e uma não correspondência deliberadamente semelhante.
7. Documentar a lista de domínios, os consumidores, o responsável, a justificação, a data do teste e o rollback.

⚠️ Vários domínios dentro de um URL Group são avaliados com OR. Basta uma única correspondência. Nas exclusões TLS, uma entrada de domínio também inclui os respetivos subdomínios. Um domínio raiz demasiado amplo ou uma regra Allow posicionada muito acima podem, por isso, abranger significativamente mais tráfego do que o previsto.

O que um URL Group controla e o que não controla

Um URL Group é um objeto de domínio reutilizável. Descreve quais os domínios que pertencem ao mesmo conjunto. A regra que utiliza o objeto decide depois o que acontece à correspondência.

Utilizações típicas:

• uma pequena allowlist empresarial numa Web Policy
• uma blocklist explícita para domínios conhecidos
• uma lista de domínios numa regra Don't decrypt
• a lista local de exclusões TLS para problemas de desencriptação confirmados

No entanto, um URL Group não é a ferramenta certa para todos os casos web:

• Web category: classificação ampla de conteúdos ou categoria própria com caminhos de URL ou palavras-chave
• Web Exception: correspondência baseada em regex e omissão específica de verificações web, de análise ou de certificados
• FQDN Host: objeto de rede baseado em DNS para regras de firewall, NAT ou routing
• Threat Feed: listas de IOC ou de domínios mantidas dinamicamente

Configurar Web Protection com Web Policies explica toda a lógica das políticas. A escolha entre uma categoria própria e uma lista de domínios é abordada em Utilizar web categories e Instant Alerts. Para listas de segurança dinâmicas, são adequados os Threat Feeds da Sophos Firewall.

Domínio em vez de URL completo

Em Search/Add, o SFOS espera um nome de domínio válido. O protocolo, o caminho e a consulta não pertencem a este campo.

Valores de exemplo válidos:

updates.vendor.example
cdn.vendor.example

Valores inadequados:

https://updates.vendor.example/download/file.bin
*.vendor.example
^updates\.vendor\.example/

A terminação .example está reservada para documentação. Na configuração real, os exemplos são substituídos pelos domínios confirmados no log, no pedido ou na documentação do fabricante.

Se for necessário um caminho de URL específico, um parâmetro de consulta ou uma expressão regular, consoante o objetivo é adequada uma web category própria ou uma Web Exception limitada de forma segura. A lista de domínios não é ampliada com um padrão wildcard aparentemente prático.

Planear o âmbito dos domínios

O exemplo utiliza o grupo Vendor update domains com dois hosts separados:

• updates.vendor.example para o download da atualização
• cdn.vendor.example para o respetivo endpoint de conteúdo

O domínio raiz vendor.example não é deliberadamente utilizado como abreviatura. A Sophos documenta expressamente que os subdomínios são incluídos na correspondência de URL Groups em exclusões TLS. Por isso, uma entrada vendor.example também incluiria neste caminho login.vendor.example, telemetry.vendor.example e outros subdomínios.

Mesmo uma entrada mais restrita pode incluir subdomínios. Na correspondência TLS, updates.vendor.example pode, por isso, abranger também api.updates.vendor.example. Se apenas for esperado um host específico, além do destino positivo é sempre testado como destino negativo um host deliberadamente semelhante.

Várias entradas no mesmo grupo não constituem uma lista obrigatória. Devido à lógica OR, uma correspondência de domínio é suficiente. Se um serviço só funcionar quando dois hosts estiverem acessíveis em conjunto, cada host deve ser testado separadamente. O URL Group não comprova uma dependência funcional entre eles.

Criar um URL Group

1. Abrir Web > URL groups.
2. Selecionar Add.
3. Definir um nome, por exemplo Vendor update domains.
4. Introduzir updates.vendor.example em Search/Add.
5. Selecionar Add e confirmar que o valor aparece na lista.
6. Adicionar cdn.vendor.example da mesma forma.
7. Selecionar Save.
8. Voltar a abrir o grupo guardado e verificar o nome e ambos os domínios.

Selecionar Add é um passo separado. Um nome de domínio que permaneça apenas no campo de introdução ainda não faz parte do grupo.

A ajuda atual do SFOS 22 não especifica um número máximo fixo de domínios por URL Group. Isto não garante uma lista ilimitada. Se forem esperadas centenas de entradas, alterações frequentes do fabricante ou IOC em constante mudança, um URL Group mantido manualmente é normalmente o modelo operacional errado.

Utilizar um URL Group numa Web Policy

Um URL Group só obtém um efeito Allow, Warn, Block ou Quota através de uma regra de Web Policy.

1. Abrir Web > Policies.
2. Editar a política afetada ou criar uma nova.
3. Selecionar Add rule.
4. Em Users, definir o âmbito de utilizadores ou grupos pretendido.
5. Em Activities, desmarcar a seleção geral All web traffic e selecionar o URL Group Vendor update domains.
6. Definir a ação pretendida para HTTP e HTTPS, por exemplo Allow ou Block.
7. Verificar a posição da regra, ativar o respetivo estado e guardar a política.
8. Em Rules and policies > Firewall rules, confirmar que esta Web Policy está selecionada em Web filtering na regra de firewall que efetivamente corresponde.
9. Ativar Log firewall traffic para a validação.

As regras de uma Web Policy são avaliadas de cima para baixo. Uma regra Allow geral acima da nova regra de URL Group pode ocultar a correspondência. Inversamente, uma regra Allow específica posicionada demasiado acima pode tornar ineficazes regras Block posteriores. Por isso, a posição faz parte da decisão de segurança e não é apenas uma questão de apresentação.

Um URL Group numa Web Policy não substitui uma regra de firewall. A regra de firewall permite primeiro o fluxo de dados entre as zonas e, em seguida, a Web Policy atribuída avalia o acesso web. Testar regras com Log Viewer, Policy Tester e Packet Capture mostra que regra e que política se aplicam realmente.

Utilizar um URL Group como exclusão TLS

Para problemas confirmados de Certificate Pinning ou outros problemas de desencriptação, o mesmo tipo de objeto pode ser utilizado numa SSL/TLS inspection rule com Action: Don’t decrypt. O SFOS compara eficientemente o domínio como texto através de Server Name Indication, ou SNI.

Existem duas variantes claras.

Complementar a Local TLS exclusion list

A Local TLS exclusion list é um URL Group integrado e está vazio por predefinição. Pertence à regra de exclusão predefinida permanente no topo da tabela de regras SSL/TLS.

O caminho manual é:

Web > URL groups > Local TLS exclusion list

Esta variante é adequada para uma exclusão de domínio confirmada localmente que deva ser aplicada independentemente de uma regra própria mais restrita por origem ou utilizador. Também podem ser adicionados domínios a esta lista através das funções de resolução de problemas do Control Center ou do Log Viewer. Cada novo domínio é, por isso, documentado e testado como uma exceção de segurança em produção.

A Managed TLS exclusion list tem outra função. A Sophos mantém nela domínios incompatíveis conhecidos e pode atualizar a lista através de atualizações de firmware. Os domínios operacionais próprios não substituem uma regra local deliberada neste objeto gerido pelo fabricante.

Criar uma regra Don’t decrypt própria

Se a exclusão tiver de ser limitada a origens, utilizadores, serviços ou zonas de destino específicos, uma regra própria é mais fácil de auditar:

1. Abrir Rules and policies > SSL/TLS inspection rules.
2. Selecionar Add.
3. Definir um nome, por exemplo Vendor updates no decrypt.
4. Selecionar Action: Don’t decrypt.
5. Ativar Log connections.
6. Limitar Source zones, Source networks, Users, Destination zones e Services ao âmbito necessário.
7. Em Categories and websites, selecionar o URL Group Vendor update domains.
8. Posicionar a regra diretamente abaixo das exclusões predefinidas e acima das regras Decrypt gerais.
9. Guardar e testar com uma nova ligação.

As SSL/TLS inspection rules funcionam independentemente das regras de firewall. Por isso, uma regra de firewall que corresponda corretamente não comprova que a regra TLS pretendida é aplicada. Inversamente, Don’t decrypt apenas exclui a desencriptação deste caminho. Não é uma autorização geral para tráfego de rede arbitrário.

As URL Groups são mais eficientes para esta correspondência SNI do que muitos FQDN Host Objects na origem ou no destino de uma regra TLS. Os FQDN Host Objects são resolvidos através de DNS e cumprem outra função. Criar e utilizar FQDN Hosts de forma segura explica as diferenças.

Se a ligação TLS não contiver um SNI utilizável, o domínio não pode ser reconhecido desta forma. O grupo não deve ser ampliado com um domínio raiz. Primeiro, são verificados o IP de destino, o certificado, o Packet Capture e o fluxo real da aplicação.

Verificar a correspondência com testes positivos e negativos

O carregamento bem-sucedido de uma página apenas comprova que o serviço está acessível. Não comprova nem a regra de Web Policy correta nem a exclusão TLS pretendida.

Teste da Web Policy

1. Registar o cliente piloto, o utilizador, a hora e a ação esperada.
2. Fechar completamente a sessão do browser ou da aplicação e reiniciá-la.
3. Abrir updates.vendor.example ou o domínio positivo real.
4. No Log Viewer, verificar Source, User, Domain, Firewall Rule ID, Web Policy e Action.
5. Testar login.vendor.example ou um host real que tenha sido deliberadamente excluído.
6. Confirmar que o host negativo continua a ser avaliado pela regra de política normal seguinte.
7. Se forem necessários dois valores do grupo, testar cada host individualmente.

Se o browser utilizar QUIC ou HTTP/3, o caminho web TCP esperado pode ser diferente. Primeiro, o teste é distinguido de QUIC e HTTP/3.

Teste da exclusão TLS

1. Estabelecer uma nova ligação TLS ao host positivo.
2. No log SSL/TLS, verificar a regra correspondente e o estado de não desencriptação.
3. Comparar o certificado visível para o cliente com o estado da regra de desencriptação normal.
4. Abrir um host negativo semelhante que não esteja no grupo.
5. Confirmar que este host continua a ser processado pela regra Decrypt esperada.
6. Documentar o âmbito de origem, o SNI e a posição da regra.

Para um teste de rollback deliberado, durante uma janela de manutenção é reposto o estado anterior documentado da regra web ou TLS que utiliza o grupo. O host positivo deve então voltar a apresentar o comportamento anterior. Só esta contraprova transforma um workaround funcional numa validação reproduzível.

Delimitar os erros sistematicamente

O URL Group não é aplicado na Web Policy

• O domínio foi introduzido, mas não foi aceite com Add.
• O URL Group não está selecionado em Activities na regra de política ativa.
• All web traffic ou outra regra anterior corresponde primeiro.
• A regra de política está desativada.
• A Web Policy não está selecionada na regra de firewall que efetivamente corresponde.
• O pedido real utiliza um host de redirecionamento, login, API ou CDN não documentado.
• Uma ligação existente do browser ou de QUIC não foi restabelecida.

A exclusão TLS não é aplicada

• O URL Group não está selecionado em Categories and websites na regra esperada.
• A regra Don't decrypt está abaixo de uma regra Decrypt que já corresponde.
• Source, User, Zone, Service ou outro critério da regra não corresponde.
• A ligação não envia um SNI utilizável.
• O host TLS real é diferente do URL visível no browser.
• A sessão TLS existente continuou a ser utilizada após a alteração.

O URL Group é aplicado de forma demasiado ampla

• Foi introduzido um domínio raiz em vez dos hosts realmente necessários.
• Uma entrada inclui subdomínios adicionais na correspondência TLS.
• O grupo é utilizado por várias políticas ou regras TLS.
• Uma regra Allow está posicionada demasiado acima ou aplica-se a demasiados utilizadores.
• A Local TLS exclusion list tem um efeito mais amplo do que uma regra própria limitada por origem.

Nesse caso, não se adiciona outro domínio. Primeiro, são verificadas todas as utilizações do grupo, a ordem real das regras e o teste negativo.

Operar alterações e rollback de forma segura

Antes de cada alteração a um URL Group em produção, são registados:

• a lista de domínios anterior
• as Web Policies e SSL/TLS inspection rules que a referenciam
• o responsável e a justificação técnica
• os utilizadores, origens e serviços afetados
• os casos de teste positivos e negativos
• a data de revisão ou expiração

Um grupo partilhado não é ampliado silenciosamente devido a um único incidente. Se uma web allowlist e uma exclusão TLS tiverem responsáveis ou ciclos de vida diferentes, URL Groups separados são mais claros, mesmo que alguns domínios sejam idênticos.

Para o rollback, primeiro é reposto o estado da regra ou política que utiliza o grupo, ou apenas é removido o domínio adicionado recentemente. O grupo completo só é eliminado quando nenhuma outra política ou regra depender dele. Em seguida, voltam a ser verificadas novas ligações para os hosts positivo e negativo, bem como os logs.

Lista de verificação operacional

• URL Group confirmado como a ferramenta adequada.
• Apenas domínios válidos adicionados, sem protocolos, caminhos, wildcards ou regex.
• Efeito do domínio raiz e dos subdomínios deliberadamente limitado.
• Lógica OR entre vários domínios considerada.
• Nome do grupo, responsável, objetivo e data de revisão documentados.
• Web Policy ou SSL/TLS inspection rule consumidora claramente identificada.
• Estado, posição, âmbito de origem e logging da regra verificados.
• Web Policy selecionada na regra de firewall correta.
• Para uma exclusão TLS, SNI e regra Don't decrypt confirmados.
• Testes positivos e negativos realizados com novas ligações.
• Referências e estado anterior guardados para o rollback.

Perguntas frequentes