Entenda e configure com segurança as regras Sophos Firewall

Uma regra do Sophos Firewall determina que tráfego é permitido ou bloqueado entre zonas, redes, utilizadores e serviços. O importante não é ativar o maior número possível de opções, mas definir critérios de correspondência adequados, a ordem correta, funções de proteção apropriadas e um teste reproduzível.

O caminho do menu é:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Antes de Add firewall rule, selecione explicitamente IPv4 ou IPv6 na página das regras. Os exemplos seguintes não constituem uma autorização conjunta para ambas as famílias de protocolos.

Este artigo explica o formulário da regra de cima para baixo e utiliza sempre o exemplo LAN_to_WAN_Clients. Tópicos específicos como NAT, TLS Inspection ou IPS são explicados até ao ponto necessário para a regra de firewall; as instruções detalhadas estão ligadas diretamente no local relevante.

Planear antes de criar a regra

Delimitar corretamente a responsabilidade

As regras de firewall normais controlam o tráfego encaminhado que atravessa o firewall. Outras tarefas são configuradas noutros locais:

• Serviços locais do firewall: WebAdmin, User Portal, VPN Portal, SSH, DNS e SNMP são controlados através de Administration > Device access, Local Service ACL e da configuração do respetivo serviço. Para isso serve Device Access e Local Service ACL.
• Tráfego gerado pelo sistema: as ligações geradas pelo próprio firewall não precisam de uma regra de firewall normal. São relevantes a configuração do serviço, o routing, WAN Link Manager e, quando aplicável, SD-WAN para System Traffic.
• Tradução de endereços e portas: NAT traduz o tráfego, mas não o permite. A regra de firewall e a regra NAT têm de corresponder.
• Routing e caminho de retorno: uma regra de firewall correspondente não comprova que o routing, SD-WAN, VPN ou o caminho de retorno estejam corretos.
• Lógica web: as categorias web, os grupos de URL e as ações são definidos na Web Policy. A regra de firewall associa essa policy.
• Desencriptação HTTPS: uma SSL/TLS inspection rule desencripta o tráfego. Scan HTTP and decrypted HTTPS só analisa HTTPS que já tenha sido desencriptado.
• Identidade do utilizador: AD SSO, STAS, Captive Portal, Entra ID SSO ou RADIUS têm primeiro de associar o utilizador ao tráfego de forma fiável. Os dispositivos sem login podem ser configurados como Clientless Users quando têm um IP fixo e inequívoco; esta associação não é autenticação.

Os acessos de administração que passam através do firewall para servidores, switches ou hypervisors pertencem às regras de firewall normais. O acesso ao próprio firewall, por outro lado, pertence a Device Access.

Ordem, IPv4 e IPv6

O Sophos Firewall verifica as regras de cima para baixo. Uma regra só é aplicada quando todos os seus critérios positivos correspondem à ligação e nenhuma Exclusion correspondente a exclui. Quando a regra é aplicada, as regras seguintes deixam de ser avaliadas. Por isso, uma regra genérica LAN_to_WAN_Any acima de LAN_to_WAN_Restricted torna a regra específica ineficaz para o tráfego que abrange e não exclui.

Os critérios positivos incluem, entre outros, Source zone, Source network, horário, Destination zone, Destination network, Service e utilizador. Todos os critérios positivos configurados têm de corresponder à ligação. As Exclusions não são critérios positivos: se todos os critérios configurados de uma Exclusion corresponderem em conjunto, o SFOS ignora esta regra e continua a avaliar as regras seguintes.

As regras MTA, IPsec ou Hotspot criadas automaticamente podem aparecer no topo da lista. O Server Access Assistant também cria uma regra de firewall juntamente com DNAT, SNAT reflexivo e Loopback. Por isso, após assistentes, migrações ou alterações de VPN, a ordem deve ser verificada novamente. Num hotspot Sophos Firewall, esta verificação faz expressamente parte do procedimento de configuração; o Server Access Assistant é explicado no guia sobre DNAT para servidores publicados.

⚠️ Antes de criar a regra Drop com logging: Não se deve assumir que mantém o bloqueio HTTP/HTTPS existente: a documentação sobre Drop, autenticação, Web Exceptions e páginas de bloqueio é contraditória. Para qualquer tráfego web, antes da implementação em produção é necessário um esclarecimento escrito da Sophos para a versão SFOS, o build e o caminho de processamento exatos, ou uma verificação isolada e expressamente autorizada. Seguir as orientações de verificação, reversão e escalamento em Action e logging, mais abaixo.

Se o SFOS não encontrar uma regra correspondente, aplica-se no fim a regra implícita Drop-all com Firewall Rule ID #0. Não apresenta Usage Count nem gera uma entrada normal no registo de tráfego da firewall. Para tornar estes descartes visíveis no Log Viewer, Central Reporting ou syslog, cria-se no fim da base de regras uma regra Drop de âmbito limitado com Log firewall traffic ativado. Para isso, selecionam-se individualmente as Source e Destination zones efetivamente necessárias em vez da zona Any; caso contrário, a regra também pode abranger tráfego interno destinado a serviços locais. Os detalhes são explicados em Analisar pacotes descartados no Sophos Firewall.

Para uma regra de registo aprovada, selecione Add firewall rule > New firewall rule no conjunto de regras IPv4/IPv6 correto, um nome inequívoco, Rule position Bottom, Action Drop e Log firewall traffic. Selecione Source zones e Destination zones individualmente; defina Source networks and devices, Destination networks e Services de acordo com o âmbito aprovado e, em seguida, clique em Save. Antes disso, documente a ordem existente e a configuração de registo. As novas ligações de teste permitidas e deliberadamente não permitidas devem corresponder aos Rule IDs esperados, sem afetar os serviços locais. Em caso de desvios, desative a nova regra e restaure o estado anterior. O esclarecimento relativo ao tráfego Web em Action e logging continua a ser um pré-requisito, e não um teste concluído por estes passos.

As regras IPv4 e IPv6 são geridas separadamente. Uma regra IPv4 funcional não protege automaticamente o mesmo serviço através de IPv6. Em ambientes Dual Stack, os dois conjuntos de regras têm de ser planeados e testados de forma consciente.

Separar claramente as bases de regras

Antes da criação devem estar definidos Source, Destination, Services, Owner e o caso de teste. Riscos diferentes não devem ser combinados numa regra genérica:

• Internet para clientes: redes de clientes para a zona WAN, com uma Web Policy adequada, Application Control, IPS e logging.
• Internet para servidores: apenas os destinos necessários para atualizações, backups ou cloud; normalmente sem relação com utilizadores.
• Wi-Fi para convidados: zona Guest para a Internet, sem destinos internos e, se necessário, com limite de largura de banda.
• Administração: redes de administração definidas para servidores e infraestrutura, separadas do tráfego normal de clientes.
• Remote Access VPN: zona VPN para os destinos e serviços internos realmente necessários.
• Site-to-Site: redes locais e remotas com routing, NAT e caminho de retorno adequados.
• Sistemas publicados: WAN para DMZ ou zona de servidores com origem restrita, DNAT ou WAF, IPS, logging e patches atualizados.
• Acessos temporários: regra própria com ticket, Owner, data de expiração e remoção planeada.

Para a estrutura da rede, consulte Configurar zonas e interfaces do Sophos Firewall.

⚠️ Any pode ajudar num teste breve, mas raramente é uma boa configuração final. Depois, a regra deve ser limitada às Source, Destination e Services realmente necessários ou removida novamente.

Exemplo prático LAN_to_WAN_Clients

No exemplo, os clientes de uma LAN definida podem aceder à Internet. Servidores, convidados, VoIP e administração recebem regras próprias.

• Rule name: LAN_to_WAN_Clients
• Description: Acesso à Internet para a rede de clientes. Webfilter, App Control e IPS ativos. Owner IT, Review 2026-12-01.
• Rule position: Bottom; depois, colocar abaixo das regras específicas de bloqueio e exceção
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: ativado
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS e apenas os serviços básicos efetivamente utilizados diretamente na Internet
• Web policy: Default Workplace Policy
• Block QUIC protocol: ativado
• IPS: policy de cliente adequada
• App control: Application Policy de cliente adequada
• Shape traffic: apenas quando existe um objetivo concreto de largura de banda
• DSCP marking: apenas quando os dispositivos a jusante processam a marcação

DNS e NTP só devem fazer parte desta regra LAN-to-WAN quando os clientes contactam diretamente resolvers ou servidores de tempo externos. Se utilizarem o firewall como serviço DNS ou de tempo, trata-se de tráfego local.

O teste de aceitação inclui um cliente definido, um destino concreto, a Firewall Rule ID esperada, a NAT Rule ID esperada e uma verificação no Log Viewer. Assim, não se verifica apenas se a aplicação funciona, mas também se é processada pelas regras previstas.

Configurar a regra de firewall

Secção do cabeçalho

Rule status, Rule name e Description

Rule status está ativado por predefinição numa regra nova. As regras preparadas podem permanecer desativadas até à janela de manutenção. As regras de teste ou migração desativadas de forma permanente devem ser revistas regularmente.

O nome deve indicar Source, Destination e finalidade, por exemplo:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

A Description documenta a finalidade, o Owner, o ticket, as restrições e, quando aplicável, a data de expiração. Rule1, Allow ou Internet pouco ajudam durante a operação posterior. O procedimento dedicado está em Documentar corretamente as regras do Sophos Firewall.

Rule position e Rule group

Ao criar a regra, Rule position oferece Top ou Bottom no SFOS 22. Depois, a regra pode ser movida na tabela ou posicionada de forma precisa com Move To. Top só deve ser selecionado quando uma regra específica tiver de ser aplicada deliberadamente antes das regras existentes.

Rule group melhora a visibilidade, mas não altera a lógica de correspondência. None é a predefinição. Com Automatic, o SFOS atribui a regra a um grupo existente com base no primeiro tipo de regra correspondente e nas zonas Source/Destination. O firewall continua a avaliar cada regra de cima para baixo. Um grupo não pode ficar vazio. A ajuda do SFOS 22 descreve separar uma regra com Detach antes de a mover para fora do grupo; em alternativa, move-se todo o grupo. Eliminar a última regra também elimina o grupo.

Na tabela do SFOS-22, mostre ou oculte os filtros com Enable filter / Disable filter, selecione o campo e o valor em Add filter e reponha-os com Reset filter. Com um filtro aplicado, é possível selecionar regras individuais, mas não grupos de regras. As regras ou os grupos podem ser ativados ou desativados com Enable / Disable; uma seleção mista de regras ativas e inativas impede esta ação. More options disponibiliza opções para editar, clonar, adicionar, eliminar, Detach, Reset data transfer count e ações de grupo. Para uma regra que ainda não pertença a um grupo, selecione Add to group > New group, atribua um nome ao grupo e defina o tipo de regra e as zonas de Source/Destination; em alternativa, selecione um grupo existente. Os grupos podem ser editados ou eliminados. A coluna # mostra a posição; use o Rule handle para arrastar a regra ou o grupo, ou introduza a posição de destino em Move To e confirme com Enter. Antes de qualquer deslocação, registe o estado anterior e, depois, verifique se os novos fluxos de teste correspondem ao Rule ID esperado. Uma regra clonada não é uma autorização automaticamente segura: verifique os critérios, o estado e a posição antes de a ativar.

A ajuda do SFOS 23 descreve outro procedimento: para uma pesquisa filtrada, clicar no campo de pesquisa, selecionar um critério sugerido e completar a pesquisa com as sugestões adicionais. Premir Enter para filtrar a tabela de regras. Para pesquisar pelo nome da regra, introduzi-lo diretamente no campo de pesquisa e premir Enter; remover filtros individuais com x. Em Show/Hide columns, selecionam-se as colunas visíveis, altera-se a sua ordem clicando e arrastando e fixam-se até três colunas para que sejam sempre apresentadas primeiro. Ativar ou desativar através de Status ou em lote com Turn on / Turn off; uma seleção mista de regras ativas e desativadas impede essa ação em lote. As regras desativadas aparecem esbatidas com o nome rasurado. Arrastar uma regra pelo menos uma posição para fora do grupo remove a sua pertença; colocá-la entre duas regras de outro grupo adiciona-a a esse grupo. View menu oferece Clone rule above/below, Add rule above/below, Move To e Edit group. Passar o cursor sobre Features permite distinguir o tipo User/Network e a ação da regra das ações de policy e dos limiares Heartbeat. Na tabela do SFOS 23, User significa Match known users selecionado e Network, não selecionado; os ícones de policy distinguem None, Accept, Drop e Reject, os de Heartbeat Green, Yellow e No restriction. Esta apresentação não comprova alterações no motor de tráfego.

Os símbolos são indicações de configuração, não resultados de testes: no SFOS 23, verifica-se em Features, e no SFOS 22, em Feature and service, se a análise Web/FTP/Mail e o Traffic Logging estão ativados ou desativados, se está selecionado Proxy-Filtering e se estão atribuídas políticas. Um proxy ativado aplica-se a 80/443; as restantes portas HTTP/TLS continuam a usar DPI. Web policy, App control, IPS e Shape traffic podem apresentar None; os símbolos de IPS e de controlo de tráfego indicam uma política atribuída, e os símbolos de Web e de aplicações indicam também a respetiva ação. No caso do Heartbeat, é necessário distinguir o estado mínimo Green ou Yellow de No restriction e verificar o estado separado de Block clients with no heartbeat. No restriction, por si só, não prova que esta opção adicional esteja desativada. As Exclusions ativadas também têm de ser consideradas na verificação de correspondência.

Para novas instalações, a documentação de ajuda do SFOS-22/23 refere uma regra LAN-to-WAN, bem como a regra MTA com Linked NAT criada automaticamente quando o modo MTA está ativado; nesse contexto, o MTA está ativo por predefinição. Isto não substitui a verificação da sua própria instalação. A regra implícita #0 não pode ser editada, eliminada ou movida e não é abrangida pelos filtros. Importa distinguir este caso de uma reposição de fábrica: ambas as versões da ajuda descrevem a remoção de todas as regras de firewall, após a qual fica apenas a regra Auto added firewall policy for MTA. Não se pode concluir daí que a autorização LAN-to-WAN seja automaticamente restaurada. Uma reposição não é um procedimento para limpar regras individuais; a cópia de segurança, o acesso administrativo independente e o plano de recuperação fazem parte do procedimento separado Repor o Sophos Firewall.

A visão geral de arranque Access rules and policies para SFOS 22/23 descreve também grupos de regras criados por predefinição com uma regra de firewall para descartar tráfego em direção a WAN, DMZ e zonas internas (LAN, Wi-Fi, VPN e DMZ). Trata-se de regras de firewall visíveis e agrupadas, não da regra implícita #0. No entanto, esta visão geral e as predefinições detalhadas de instalação e reposição acima referidas não comprovam um conjunto inicial de regras uniforme para todas as instalações. Por isso, verifique, na sua versão, compilação e instalação específicas do SFOS, em Rules and policies > Firewall rules, quais as regras e os grupos efetivamente presentes e ativados, que zonas de origem/destino e outros critérios de correspondência utilizam e em que posição se encontram. A mera presença de um grupo não comprova o isolamento: uma autorização anterior que corresponda ao tráfego pode já permiti-lo. Verifique a separação pretendida entre zonas com novas ligações de teste expressamente autorizadas e os Rule IDs esperados; para o tráfego web, continua a aplicar-se o conflito de documentação relativo a Drop descrito acima. Não deduza da visão geral de arranque nomes de grupos garantidos, condições de criação ou um efeito de bloqueio geral.

Action e logging

Action define o tratamento do tráfego correspondente:

• Accept: permite a ligação.
• Drop: está documentado como descarte sem notificação para tráfego não web. O comportamento HTTP/HTTPS não é garantido de forma geral devido ao conflito documental descrito abaixo.
• Reject: descarta a ligação e, no caso de TCP, envia um TCP Reset; para UDP e ICMP, a ajuda refere explicitamente uma mensagem ICMP de porta inacessível enviada à origem.
• Protect with web server protection: cria uma regra WAF. Esta opção só está disponível para IPv4 e requer Webserver Protection. A configuração pertence funcionalmente a Sophos Firewall WAF.

Ao selecionar Protect with web server protection, surge Preconfigured template. None significa que os detalhes do WAF têm de ser definidos manualmente. Os modelos documentados são Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 e Microsoft Sharepoint 2010 and 2013. Estes nomes históricos não constituem uma afirmação sobre o suporte ou a segurança atuais da respetiva versão de servidor. Antes de utilizar um modelo, este deve corresponder ao serviço efetivamente em funcionamento; a configuração subsequente do WAF e a respetiva validação continuam a ser necessárias.

⚠️ Conflito documental não resolvido sobre tráfego web: A ajuda do formulário de regras do SFOS 22/23 descreve, para Drop, a aceitação e análise de HTTP/HTTPS, a autenticação de utilizadores desconhecidos com Use web authentication for unknown users ativado, a autorização de pedidos permitidos por uma Web Exception correspondente e uma página de bloqueio HTML para os restantes pedidos. O guia de logging do tráfego descartado descreve, por outro lado, o descarte silencioso em geral e associa a página de bloqueio web a essa opção de autenticação. O comportamento HTTP/HTTPS deve ser confirmado no build SFOS utilizado. Não demonstram o descarte silencioso de todas as ligações web, uma página de bloqueio dependente apenas da opção de autenticação nem o bloqueio geral de todos os serviços.

Se for necessário um bloqueio garantido ou uma resposta específica, obter um esclarecimento escrito da Sophos para a versão SFOS, o build e o caminho de processamento exatos, ou verificar num ambiente de teste isolado e expressamente autorizado. Testar separadamente tráfego não web, HTTP e HTTPS; para tráfego web, incluir também utilizadores conhecidos/desconhecidos, autenticação ativada/desativada e presença/ausência de uma Web Exception correspondente. Usar apenas clientes, destinos e serviços de teste definidos, ativar Log firewall traffic e gerar novas ligações. Documentar build, posição da regra, Firewall Rule ID, utilizador, Action, definições web/TLS e resultados dos logs, Packet Capture e navegador. Um timeout, uma página de bloqueio ou o Policy Tester, por si só, não comprova o bloqueio pretendido. Perante acesso inesperado ou resultado incerto, não implementar em produção; reverter as alterações de teste e encaminhar as provas para Sophos Support. Reject fornece a resposta de protocolo descrita acima; não é aqui recomendado como substituto não verificado do controlo web.

Log firewall traffic deve estar ativado nas regras importantes. Os logs são guardados localmente na firewall por predefinição; verificar as definições locais e os destinos Syslog em System services > Log settings. O envio ao serviço cloud exige ainda ativar Sophos Central services na página Sophos Central. A ajuda do SFOS 22 chama ao destino Sophos Fusion (anteriormente Sophos Central), e a do SFOS 23 Sophos Central; o nome não substitui este requisito separado. Sem um evento Destroy, uma sessão pode terminar sem um registo de sessão final, por exemplo durante uma falha abrupta da ligação.

Para retenção mais longa, podem ser utilizados Central Firewall Reporting ou um servidor Syslog/SIEM. O logging não serve apenas para troubleshooting, mas também para a revisão: que Source atingem a regra, que Destination são utilizadas e o acesso continua adequado?

A mesma caixa de seleção é a fonte de dados para NetFlow v5 no Sophos Firewall: sem Log firewall traffic, o NetFlow não exporta as ligações dessa regra.

Source, Destination e Services

Na área Source, define-se a origem do tráfego:

• Source zones: por exemplo LAN, VPN, DMZ, Guest ou WAN.
• Source networks and devices: hosts individuais, redes, intervalos IP, grupos, FQDN Hosts ou objetos de país.
• During scheduled time: All the time, horário de trabalho ou uma janela de manutenção.

A zona, por si só, é geralmente demasiado abrangente. No exemplo de clientes, LAN é por isso combinada com net_LAN_Clients. Nas regras controladas por horário, a hora do firewall, o fuso horário e o Schedule têm de coincidir.

Configurar agendamentos para regras e políticas na Sophos Firewall mostra como criar e atribuir janelas recorrentes ou únicas e testá-las nos respetivos limites de mudança.

Em Destination and services encontram-se:

• Destination zones: por exemplo WAN, DMZ, LAN ou VPN.
• Destination networks: Any, um host, uma rede, um grupo, um objeto de país ou um FQDN Host.
• Services: definições de protocolo e porta como HTTP, HTTPS, DNS, NTP ou um Service personalizado.

O guia Utilizar corretamente hosts e serviços da Sophos Firewall explica como criar IP hosts, redes, intervalos, listas, Services e grupos e como os verificar antes de alterações.

Any pode ser aceitável numa regra geral de Internet para clientes. As regras para servidores, administração e VPN devem utilizar Destination e Services bastante mais restritos. Para destinos cloud dinâmicos, podem ajudar FQDN Hosts e Wildcard FQDN.

Regra baseada em MAC: esclarecer as limitações antes da tentativa de bloqueio

Um MAC host pode permitir uma associação adicional ao dispositivo no caso de clientes diretamente visíveis, por exemplo, quando o seu endereço DHCP muda. No entanto, um endereço MAC não é uma identidade forte: pode ser alterado ou imitado. O guia de origem descreve o MAC-Filtering como mais seguro e apresenta Block_MAC para IPv4 de LAN para WAN com Drop, registo, posição Top, grupo None, horário All the time, destino e Services Any. Esta combinação não constitui aqui uma garantia de bloqueio completo do acesso à Internet: o conflito HTTP/HTTPS/Web Exceptions documentado acima continua por esclarecer.

No guia, a filtragem de acesso à Internet baseada em MAC está limitada a dispositivos diretamente ligados à firewall. Se existir um router, outra firewall ou um switch de Layer-3 no percurso, o MAC original do cliente não fica automaticamente visível. Para este caso, o guia refere MAC binding para utilizadores locais; sem esclarecer a associação da identidade e o percurso efetivo dos pacotes, isto não garante filtragem MAC em tráfego encaminhado nem substitui a autenticação. Antes de uma tentativa, o MAC visível à entrada da firewall deve pertencer efetivamente ao cliente de teste.

Num piloto isolado e expressamente aprovado, bloqueia-se apenas um novo fluxo TCP IPv4 não Web para um servidor de teste WAN controlado:

1. Compare o MAC no cliente de teste com o MAC à entrada da firewall. Em Hosts and services > MAC host > Add, introduza o nome MAC_Host, Type MAC address e o MAC efetivamente verificado e, em seguida, clique em Save. 37:97:0E:AB:56:46 é o valor de exemplo inalterado do guia e não deve ser utilizado sem verificação.
2. Em Rules and policies > Firewall rules, selecione IPv4 e Add firewall rule > New firewall rule. Para Block_MAC, defina Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time e Destination zones WAN. Limite o destino ao servidor de teste controlado e Services ao serviço de teste TCP não Web aprovado, em vez de utilizar os valores Any originais. Antes disso, documente a ordem e o estado da configuração e, em seguida, clique em Save.
3. Gere um novo fluxo de teste, por exemplo, um fluxo TCP-iPerf3 aprovado, e verifique Block_MAC com o respetivo Rule ID no Log Viewer, bem como o fluxo de pacotes descartados. Outro cliente de controlo, não bloqueado, deve continuar a conseguir aceder ao destino de teste. Um timeout, por si só, não é suficiente.
4. Após o piloto, desative ou remova a regra de teste, restaure a ordem anterior e comprove, a partir do cliente original, um novo fluxo de teste permitido através do Rule ID esperado. Remova o MAC host de teste apenas se nenhuma outra configuração precisar dele.

Se não houver correspondência com a regra, verifique a visibilidade do MAC, a seleção de IPv4, Source, Schedule e a ordem, sem alargar a regra a todos os dispositivos. Em caso de acesso inesperado ou de falha do cliente de controlo, reverta a tentativa e esclareça os resultados com a versão e o Build exatos. HTTP, HTTPS, Web Exceptions, outras zonas/destinos/serviços e IPv6 não estão abrangidos por este piloto. Um bloqueio completo do acesso à Internet baseado em MAC só pode ser garantido após o esclarecimento e a verificação separados destes casos.

Utilizadores, Exclusions e Linked NAT

Match known users

Com Match known users, os utilizadores ou grupos passam a ser critérios de correspondência. Dependendo da configuração, ficam então disponíveis outros campos:

• Use web authentication for unknown users: redireciona utilizadores web desconhecidos para AD SSO ou Captive Portal. A autenticação e o acesso a partir da zona afetada têm de estar previamente configurados. Configurar e testar o Sophos Firewall Captive Portal mostra como interagem a autenticação, o Device Access, o requisito de DNS e a regra de utilizador.
• Users or groups: limita a regra às identidades selecionadas.
• Exclude this user activity from data accounting: exclui o tráfego destes utilizadores do registo individual do consumo de dados.

Neste contexto, desconhecido significa que o utilizador iniciou sessão no dispositivo, mas ainda não se autenticou na firewall. Configure AD SSO com Kerberos/NTLM ou Captive Portal em Authentication > Web authentication e o acesso a partir das zonas necessárias em Administration > Device access. Por predefinição, o tráfego correspondente é contabilizado no consumo de dados individual. Exclude this user activity from data accounting exclui-o dessa contabilização, por exemplo, quando estes utilizadores não devem estar sujeitos a um limite de dados; não constitui uma autorização adicional nem uma autenticação.

Uma regra de utilizador só funciona com uma associação fiável dos utilizadores. Abaixo dela não deve existir uma regra de fallback abrangente que permita o mesmo tráfego sem relação com utilizadores. Durante o teste de aceitação, o utilizador, o grupo e a Rule ID têm de corresponder no Log Viewer.

Add exclusion

Add exclusion exclui tráfego desta regra. O SFOS só ignora a regra quando todos os critérios de Exclusion configurados correspondem em conjunto e, em seguida, verifica a regra seguinte.

Estão disponíveis como critérios Source zones, Source networks and devices, Destination zones, Destination networks e Services.

Uma exceção útil seria um servidor de atualizações excluído de uma regra geral de clientes e abrangido por uma regra própria acima, com outras funções de proteção. Se as Exclusions se tornarem numerosas ou difíceis de compreender, uma regra específica separada é geralmente melhor.

O exemplo documentado relativo a países permite HTTPS a partir de países africanos para 172.16.16.0 e utiliza uma Exclusion apenas com Source zone WAN e um objeto de país selecionado como Source network. Esta regra só é ignorada se ambos os critérios corresponderem; o tráfego pode ser permitido por uma regra posterior ou chegar a #0. O endereço é um exemplo inalterado, não uma definição de rede completa com prefixo. Para um teste próprio, selecione um objeto de destino que exista efetivamente, documente a ordem das regras e verifique um fluxo de teste excluído e outro não excluído através dos Rule IDs. Uma Exclusion não é um bloqueio global.

Create linked NAT rule

Desassociar uma Linked NAT Rule na tabela NAT permite editá-la e faz com que seja avaliada pelos seus próprios critérios, independentemente da regra firewall original. Antes, documentar o âmbito e a ordem NAT; depois, verificar um novo fluxo de teste. Não é apenas uma mudança de nome.

Uma Linked NAT Rule é uma regra Source NAT aplicável apenas ao tráfego da regra de firewall associada. Na regra NAT podem ser definidos principalmente a Source traduzida e a Source Translation específica da interface.

Em muitas instalações já existe uma regra Default SNAT com MASQ. No entanto, isso depende do estado da configuração e da migração e tem de ser verificado na tabela de regras NAT concreta. Antes de adicionar uma Linked NAT Rule, deve verificar-se se uma regra existente já abrange corretamente o tráfego. Se corresponder uma regra NAT independente posicionada acima, esta prevalece sobre a Linked NAT Rule.

Com DNAT, o SFOS determina primeiro o destino traduzido e utiliza depois a respetiva zona para a correspondência da regra de firewall. Por isso, um port forwarding para um servidor na DMZ requer normalmente Destination zone DMZ na regra de firewall, embora o cliente contacte o endereço WAN público.

Perante uma NAT Rule ID inesperada, deve também verificar-se a ordem em Rules and policies > NAT rules. Depois de uma alteração NAT, é necessário criar uma nova ligação, porque as sessões existentes não são reavaliadas. NAT não permite tráfego por si só: a regra de firewall decide entre Allow e Drop; NAT traduz endereços ou portas. Os detalhes são explicados em Compreender NAT no Sophos Firewall.

Para tráfego de saída dos clientes, pode criar em conjunto a autorização na firewall e o Source NAT:

1. Em Rules and policies > Firewall rules, selecione a família de protocolos e abra Add firewall rule > New firewall rule. Defina o nome e a posição; no exemplo, utilize Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN e Destination networks Any. Network_LAN deve conter a sua própria rede de clientes, devidamente verificada. O guia apresenta Services Any; em produção, selecione apenas os serviços aprovados.
2. Selecione Create linked NAT rule, defina o nome e a posição da regra NAT e configure Translated source (SNAT) como MASQ. Guarde primeiro a Linked NAT Rule com Save e, em seguida, a regra de firewall com Save.
3. Verifique a regra de firewall na tabela de firewall e a regra SNAT associada na tabela NAT através do Firewall Rule ID e do nome. Primeiro é avaliada a regra de firewall e, depois, o Source NAT. Em Linked NAT, apenas a Source traduzida e a Source Translation específica da interface de saída podem ser alteradas; os restantes critérios, incluindo utilizadores/grupos, provêm da regra de firewall.

A representação de origem 10.145.16.10/24 é o valor de exemplo inalterado do guia, não um valor que deva ser copiado como endereço de rede sem verificação. MASQ utiliza o endereço IP da interface de saída efetivamente selecionada. Antes disso, verifique a rota adequada, a interface e as regras NAT colocadas acima. Um novo fluxo de teste deve mostrar o Firewall Rule ID, o NAT Rule ID e a Source traduzida esperados. Em caso de tradução incorreta, verifique a ordem e a saída; em caso de falha, reverta a nova configuração de firewall e de Linked NAT e restaure o estado anterior, incluindo a ordem, sem alterar outras regras NAT necessárias.

Selecionar as funções de proteção

Nem todas as opções estão disponíveis com a Base License. Antes do rollout, deve verificar-se em Administration > Licensing:

• Regras de firewall normais: Base License
• IPS e Security Heartbeat: Network Protection
• Web Security, Application Control e proteção web contra malware: Web Protection
• Sandboxing e análise de ficheiros: Zero-Day Protection
• Proteção de email: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection e Xstream Protection incluem Web Protection. O bundle Avanet Epic Protection também inclui Web Protection. A classificação completa está disponível em Comparar bundles de licenças Sophos Firewall.

Web Filtering

Web policy associa uma Web Policy com categorias, grupos de URL, utilizadores e ações. Sem uma Web Policy, este campo não oferece controlo web baseado em categorias. A policy é criada e testada em Web Protection.

Apply web category-based traffic shaping utiliza as definições de largura de banda das categorias web. A opção só é útil quando existem efetivamente limites ou garantias configurados nessas categorias.

Block QUIC protocol bloqueia, para a regra, o tráfego UDP de saída nas portas 80 e 443. O QUIC não pode ser analisado como tráfego HTTP/HTTPS normal e contorna o Web Filtering. O SFOS ativa a opção por predefinição quando se seleciona uma Web Policy ou a análise de malware. Consulte Bloquear QUIC e HTTP/3.

Scan HTTP and decrypted HTTPS verifica a existência de malware no tráfego HTTP e HTTPS já desencriptado, mas não ativa a desencriptação. No modo DPI, é necessária uma regra de inspeção SSL/TLS adequada em Rules and policies > SSL/TLS inspection rules; no modo de proxy Web, utiliza-se Decrypt HTTPS during web proxy filtering. Antes da implementação, verifique o percurso de processamento efetivamente utilizado e se os clientes confiam na CA de desencriptação.

Use Zero-day protection requer Scan HTTP and decrypted HTTPS e envia os ficheiros transferidos por HTTP/HTTPS para uma análise adicional de ameaças desconhecidas ou ainda não divulgadas. A funcionalidade requer Zero-Day Protection e pode causar um atraso consoante o tipo de ficheiro e a política; não ativa, por si só, a desencriptação de HTTPS.

Scan FTP for malware só é necessário se a regra permitir FTP. Em sistemas Legacy, a análise deve ser testada separadamente.

Use web proxy instead of DPI engine limita o Proxy Filtering às portas habituais 80 e 443. O Web Proxy é necessário, entre outros casos, para SafeSearch, restrições do YouTube, restrições de domínio do Google Workspace, Pharming Protection, Web Cache ou Parent Proxy. No modo DPI, as SSL/TLS inspection rules aplicam-se a HTTP e TLS em todas as portas.

Configurar um upstream proxy na Sophos Firewall descreve a cadeia adicional de regras e NAT para um parent proxy. Um proxy na WAN necessita de um caminho diferente de outro na LAN ou DMZ.

Um cliente Direct Web Proxy configurado explicitamente utiliza, por outro lado, o listener mesmo sem esta opção. Configurar o Direct Web Proxy com um ficheiro PAC explica a configuração completa com porta, Device Access, ficheiro PAC, regra e testes.

Decrypt HTTPS during web proxy filtering pertence ao modo Web Proxy. No modo DPI, a Decryption é controlada por SSL/TLS inspection rules. As Web Exceptions podem ignorar Decryption, análise de malware, Zero-Day Protection e Policy Checks e, por isso, devem ser estritamente limitadas e revistas regularmente.

Mesmo com Use web proxy instead of DPI engine ativado, o motor DPI continua a filtrar HTTP e SSL/TLS noutras portas; a opção diz respeito ao proxy para 80/443, não a todo o tráfego. A filtragem pelo Web Proxy numa bridge sem endereço IP é descrita na ajuda como um caso de descarte e não deve ser ativada sem verificação prévia. Decrypt HTTPS during web proxy filtering também desencripta no modo Direct Proxy configurado explicitamente no cliente. No modo DPI, as Web Policies, incluindo as Web Exceptions, só são aplicadas se estiver definida uma Web Policy, se a análise de malware/conteúdo estiver ativa ou se o ATP estiver ativo. Estas condições devem ser distinguidas do reconhecimento de Micro Apps baseado em URL descrito na secção Application Control, IPS e Traffic Shaping.

Processar apenas determinados destinos através do Web Proxy

Se pretender limitar SafeSearch, as restrições do YouTube ou os inícios de sessão do Google Workspace a determinados domínios, enquanto o restante tráfego utiliza a desencriptação DPI, crie uma regra própria colocada acima das restantes. Antes disso, verifique a licença de Web Protection, as definições Web globais adequadas, a confiança dos clientes na CA de desencriptação e a Web Policy pretendida. Os grupos FQDN determinam os destinos; não configuram, por si só, os domínios de contas permitidos nem as ações de filtragem.

1. Em Rules and policies > Firewall rules, selecione IPv4 ou IPv6, abra Add firewall rule > New firewall rule e defina o nome e a posição. Selecione Action Accept, a zona de origem efetivamente necessária e a rede de clientes aprovada. O guia de origem utiliza Any neste ponto; esta origem abrangente não é um requisito necessário para produção.
2. Defina Destination zones WAN, Destination networks com os grupos predefinidos SafeSearch enforcement, YouTube restrictions enforcement e Google app enforcement, bem como Services HTTP, HTTPS. Selecione apenas os grupos necessários para o caso de utilização pretendido.
3. Ative Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering. A Web Policy efetivamente aplicada deve corresponder à restrição pretendida. Ative Log firewall traffic para o piloto e guarde com Save.
4. Posicione a regra acima das regras DPI. Com novas ligações, verifique a restrição pretendida de SafeSearch/YouTube/contas, o Rule ID e os registos Web/TLS; teste também outro destino, que deve continuar a corresponder à regra DPI prevista e à SSL/TLS inspection rule prevista.

Se a restrição não for aplicada, verifique a posição da regra, a associação FQDN, a Web Policy e o QUIC; em caso de erros de certificado, verifique a confiança na CA e a configuração de desencriptação. Em caso de comportamento inesperado, desative a nova regra de proxy ou restaure os valores e a posição anteriores e, em seguida, volte a verificar o percurso DPI original. Não desative indiscriminadamente a proteção TLS nem a verificação de certificados.

Synchronized Security Heartbeat

As regras Heartbeat requerem:

• um firewall registado na mesma conta Sophos Fusion com Security Heartbeat ativado;
• um Sophos Endpoint gerido com licença Trial ou completa;
• Network Protection no firewall.

Para detetar Heartbeats em falta, as zonas afetadas têm de ser selecionadas em System > Sophos Fusion > Optional configurations > Missing heartbeat zones.

Com Minimum source HB permitted e Minimum destination HB permitted, exige-se um estado de integridade mínimo. Destination Heartbeat só é adequado para destinos internos, não para a zona WAN.

Para ambos os limiares, Green permite apenas Green; Yellow, Green ou Yellow; No restriction também permite Red e dispositivos sem Heartbeat. Verificar igualmente as opções separadas de bloqueio sem Heartbeat. O guia de Heartbeat em falta distingue entre perdido e nunca enviado; Synchronized User ID aborda o fim de sessão após perda ou suspensão/retoma e a validação de um novo início de sessão.

As opções Block clients with no heartbeat e Block request to destination with no heartbeat tratam os dispositivos sem Heartbeat. Por predefinição, um dispositivo que nunca tenha enviado um Heartbeat continua a ser permitido e só é bloqueado quando ambas as opções estão ativadas. Isto deve ser testado deliberadamente com dispositivos sem Sophos Endpoint.

Uma Web Exception que ignore Policy checks pode permitir pedidos web apesar de Block clients with no heartbeat. O procedimento prático de verificação está em Analisar alertas de Security Heartbeat em falta.

Application Control, IPS e Traffic Shaping

Identify and control applications (App control) associa uma Application Filter Policy. Application Control requer Web Protection. Para Micro Apps baseadas em URL dentro de tráfego encriptado, como uploads e downloads de ficheiros no Dropbox ou Gmail, é necessária uma SSL/TLS inspection rule de desencriptação adequada. Filtros, logs e False Positives são explicados em Configurar Application Control.

A análise de malware e conteúdo utiliza Web > General settings. Selecionar filtragem web proxy exige primeiro uma Web Policy ou Scan HTTP and decrypted HTTPS. Uma Application Filter Policy para Micro Apps baseadas em URL continua a aplicar-se no caminho DPI com desencriptação mesmo com Web policy None e com ambas as funções desativadas: a análise de malware e o ATP. Isto não elimina as condições próprias de Web Exceptions em DPI. Os guias detalhados abordam proxy num bridge sem IP e desencriptação HTTPS com Direct Web Proxy.

Apply application-based traffic shaping policy utiliza a policy de largura de banda atribuída a uma aplicação ou categoria em Applications > Traffic shaping default. Os Application Objects destinam-se, por outro lado, às rotas SD-WAN. Uma Rules Policy selecionada através de Shape traffic modela todo o tráfego da regra de firewall. A ajuda atual do formulário da regra não descreve a prioridade entre uma Application Policy e uma Rules Policy. Para um design compreensível, deve utilizar-se apenas uma variante por caso de utilização e testar qualquer combinação necessária no build SFOS utilizado. No entanto, com Match known users ativado, aplica-se a Traffic Shaping Policy do utilizador; se o utilizador não tiver uma policy, aplica-se a policy do respetivo grupo.

Detect and prevent exploits (IPS) associa uma IPS Policy. O IPS requer Network Protection ou uma licença Trial válida e tem de estar ativado globalmente em Intrusion prevention > IPS policies. O tráfego de clientes, servidores, webservers e VoIP requer policies diferentes e testadas. O rollout seguro está descrito em Configurar e testar o IPS.

Shape traffic atribui uma Traffic Shaping Policy a toda a regra, por exemplo para VoIP, reuniões, backups ou convidados. As garantias e os limites têm de corresponder à largura de banda WAN disponível. Mais informações: Configurar Application Traffic Shaping.

DSCP marking marca apenas os pacotes IPv4 e IPv6 de saída que correspondem a esta regra. Ao fazê-lo, substitui uma marcação DSCP já presente no tráfego de entrada. Os pacotes de resposta e o tráfego gerado pelo sistema não são marcados pela regra de firewall. A marcação, por si só, não atribui prioridade nem classifica o tráfego; todos os switches, routers e dispositivos WAN envolvidos têm de processar os valores DSCP selecionados de forma consistente.

Um teste QoS limitado usa um cliente definido, um destino de teste autorizado e ICMP com AF31 = 26. Confirmar a correspondência da regra e verificar a marcação com Packet Capture na saída WAN e a resposta separadamente. CS0 = 0 é a resposta do exemplo documentado, não uma garantia para marcações de qualquer destino. Não criar uma autorização ampla com Any; remover depois a regra de teste. Testar uma regra Sophos Firewall explica a captura.

A seleção DSCP deve corresponder à conceção de QoS de todo o percurso: EF descreve Expedited Forwarding para baixa latência e baixas perdas em serviços em tempo real; AF descreve Assured Forwarding com descarte em caso de sobrecarga; CS destina-se à compatibilidade com IP-Precedence. Estes são conceitos de classes, não uma qualidade de serviço garantida apenas pela marcação. Os valores documentados são:

O exemplo ICMP original utiliza 8.8.8.8, Source zone LAN, Destination zone WAN, origem e destino Any, bem como AF31. Para uma verificação própria, substitua estes elementos por objetos concretos de cliente e de destino aprovados; nem este endereço público nem uma autorização abrangente são necessários. Antes do teste, registe o valor DSCP anterior, restaure-o após o teste e verifique com novos pacotes. Se a priorização esperada não ocorrer, é necessário investigar separadamente a correspondência com a regra, a marcação efetiva à saída e o tratamento QoS pelos dispositivos a jusante.

NDR Active threat intelligence

Scan with NDR Active threat intelligence verifica o tráfego com assinaturas NDR selecionadas. A ação está definida de forma fixa como Log threats: a função deteta e regista eventos, mas não bloqueia o tráfego.

Os pré-requisitos são:

• Xstream Protection Bundle;
• ativação global de NDR Active threat intelligence;
• logging de IPS ativado;
• seleção da opção em cada regra de firewall relevante.

São suportados XGS Appliances e deployments virtuais, de software e cloud comuns, mas não XGS 87, 87w, 88 e 88w. XDR ou MDR e a transferência para o Sophos Fusion são opcionais para uma análise avançada.

Scan email content

Em Scan email content podem ser selecionados IMAP, IMAPS, POP3, POP3S, SMTP e SMTPS. A proteção requer Email Protection. Se as portas standard estiverem em falta em Services, podem ser adicionadas através de Add ports.

O tráfego de email não deve ficar escondido numa regra geral de Internet para clientes. Uma regra de email própria torna mais claros Source, Destination, protocolos, logging e funções de proteção.

Para um servidor SMTP existente publicado através de DNAT, Configurar o Mail Protection em Legacy mode liga as regras de entrada e saída a NAT, política de análise, TLS e aos logs do proxy Legacy.

Para consultar o email por POP3 ou IMAP, a caixa de seleção isolada não basta: confiança da CA, limites globais de análise, política POP-IMAP opcional e correspondência real da regra têm de funcionar em conjunto. Analisar e testar POP3 e IMAP na Sophos Firewall apresenta o procedimento completo de piloto e validação.

Preparar regras de firewall através da XML API

Os objetos XML FirewallRule e FirewallRuleGroup são adequados para alterações rastreáveis de regras e manutenção de grupos. Não substituem o planeamento dos acessos nem os testes de aceitação com novas ligações de teste. O acesso protegido, HTTP POST para APIController, as operações XML explícitas, a verificação TLS, o armazenamento de segredos e a avaliação do estado XML em vez do sucesso HTTP são explicados em Proteger o acesso à XML API. Primeiro, uma consulta de leitura inofensiva tem de funcionar a partir do host de automação previsto, com uma conta de permissões restritas.

Manter o tipo de regra, a estrutura hierárquica e a ordem

Na referência SFOS-22/23, Name, Position e PolicyType são campos obrigatórios para Add/Edit. Name é uma cadeia de caracteres UTF-8 com um máximo de 60 caracteres, sem vírgulas. Em FirewallRule, PolicyType seleciona, com Network, o bloco NetworkPolicy ou, com User, o bloco UserPolicy. Não misture estes ramos nem envie ambos sem os verificar. HTTPBased e HTTPBasedPolicy pertencem à configuração WAF, e a associação à autenticação pertence à autenticação WAF. As ações dos caminhos WAF não são uma tradução numérica das ações de rede.

IPFamily permite IPv4 ou IPv6; a tabela indica IPv4 como predefinição. Status permite Enable ou Disable, mas indica ON como predefinição. Para regras preparadas, defina deliberadamente o estado como Disable e verifique a família de protocolos guardada, em vez de assumir que as predefinições da documentação são valores seguros para o payload. Segundo a tabela de parâmetros, Position permite Bottom, Top, After ou Before; o exemplo apresenta estes valores em minúsculas. Por isso, confirme a grafia e a operação completa em API help do build instalado. After/Name e Before/Name identificam a regra de referência existente; a referência limita estas tags a pedidos Set. Section distingue Central_TOP, Local e Central_Bottom: esclareça quem é responsável e qual o método de gestão antes de tentar uma escrita local; não contorne uma restrição central através de outra secção.

No bloco de policy selecionado, a origem e o destino permanecem separados: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network e Services/Service contêm referências que podem ser repetidas. Schedule referencia um horário existente. As tabelas limitam as referências a redes e serviços a 60 caracteres; não documentam um número máximo conjunto para todos os critérios. Os mesmos elementos superiores podem aparecer em Exclusions, onde significam exceções a esta regra, não autorizações adicionais. Antes da escrita, consulte as zonas, os hosts, os serviços e os horários efetivamente existentes e verifique a correspondência pretendida, incluindo as regras seguintes.

Em UserPolicy, MatchIdentity, ShowCaptivePortal e Identity/Member acrescentam a associação ao utilizador. Para Member, estão documentadas várias referências a utilizadores/grupos com um máximo de 256 caracteres. A associação de identidade e a autenticação web têm de funcionar separadamente. DataAccounting só está descrito com a correspondência de identidade ativada e exclui o tráfego dos utilizadores da contabilização de dados; não autentica. Aqui, o exemplo e a tabela contradizem-se: o exemplo apresenta Include/Exclude, e a tabela Enable/Disable. Também WebCategoryBaseQoSPolicy e ApplicationBaseQoSPolicy apresentam Apply/Revoke no exemplo, enquanto a tabela descreve uma cadeia de caracteres. Não traduza automaticamente estes valores nem os trate como intercambiáveis. Se o valor concreto para o objeto e o build continuar por esclarecer, interrompa o pedido de escrita e esclareça a questão com a Sophos.

Action no ramo Network/User permite Accept, Drop ou Reject; a tabela indica Drop como predefinição. Continua a ser necessária uma ação explícita, e o conflito explicado acima sobre o tratamento HTTP/HTTPS de Drop também se aplica às alterações pela API. LogTraffic permite Enable/Disable, com a predefinição documentada Disable; escolha deliberadamente o logging para os testes de aceitação. SkipLocalDestined diz respeito ao tráfego destinado ao IP da appliance e não substitui Device Access. As referências a policies, como WebFilter, ApplicationControl, IntrusionPrevention e TrafficShapingPolicy, têm de corresponder à proteção planeada anteriormente. A análise, o proxy, a desencriptação, Zero-Day e Heartbeat continuam a ser controlos distintos, com os pré-requisitos explicados acima. Em particular, predefinições como OFF, NULL ou NoRestriction contradizem parcialmente os valores de entrada indicados; nem essas indicações nem os elementos vazios dos exemplos comprovam o efeito de omitir, esvaziar ou atualizar no build concreto.

Ao transferir opções de proteção existentes, é necessário verificar o domínio de valores de cada campo: ProxyMode indica, além de Enable/Disable, também true/false; NDRActiveThreatIntelligence indica apenas true/false. Os limiares MinimumSourceHBPermitted e MinimumDestinationHBPermitted permitem GREEN, YELLOW e No Restriction, enquanto a coluna de predefinição apresenta NoRestriction. Estes valores de entrada são diferentes dos utilizados nas opções separadas de Heartbeat, não uma tradução automática das designações da GUI. Os seletores associados ao utilizador WebFilterInternetScheme e ApplicationControlInternetScheme indicam Enable/Disable, mas apresentam a predefinição 0; não devem ser confundidos com um nome de política. Os comentários XML associam WebCategoryBaseQoSPolicy a um WebFilter selecionado e ApplicationBaseQoSPolicy a um Application Filter selecionado. Para Traffic Shaping, a tabela indica TrafficShappingPolicy/TrafficShapingPolicy, mas o exemplo XML apresenta TrafficShapingPolicy: não se deve deduzir que as tags são intercambiáveis nem que ambas são aceites. DSCPMarking está documentado como uma cadeia de caracteres; a serialização do valor da GUI tem de ser adequada ao build. Compare cada opção de proteção afetada antes e depois da alteração; não normalize valores de entrada desconhecidos nem deixe que uma opção de proteção se perca silenciosamente.

A pertença a um grupo não é uma decisão de segurança

FirewallRuleGroup agrupa regras existentes através de SecurityPolicyList/SecurityPolicy. SourceZones/Zone e DestinationZones/Zone são elementos superiores separados para a atribuição ao grupo, não novos critérios de correspondência das regras individuais. O Policytype do grupo, com «t» minúsculo, difere do PolicyType de uma regra. Os seletores de grupo documentados são User/network rule, Network rule, User rule, WAF rule e Any; não deduza estes valores a partir do tipo de regra nem normalize a sua grafia.

O nome do grupo é obrigatório, sem vírgulas, em UTF-8 e com um máximo de 150 caracteres; Description é opcional, com um máximo de 255 caracteres. Para SecurityPolicy, a referência indica um máximo de 60 caracteres por nome de regra, sem vírgulas e até 200 valores. Trata-se de um limite documentado de membros, não de uma garantia de capacidade testada. Para um grupo Internet Access, consulte primeiro os nomes das regras existentes, selecione apenas os membros aprovados e atribua a origem e o destino separadamente. O exemplo do fabricante, com dois-pontos e uma seleção de todos os tipos separados por vírgulas, não é um payload executável.

Antes de atualizar um grupo, guarde a pertença ao grupo, as posições das regras e os respetivos estados. Depois, volte a comparar as mesmas regras no WebAdmin e através de uma consulta de leitura autorizada. A descrição «Add/Remove» de SecurityPolicy não define uma alteração incremental segura da lista nem a semântica de substituição. Se o tratamento de listas omitidas ou vazias não estiver esclarecido, não efetue a escrita. Segundo a ajuda da GUI, um grupo não pode existir vazio; remover a última regra também pode remover o grupo. O agrupamento melhora a organização, mas não cria isolamento nem prioridade: os critérios de correspondência e a ordem efetiva de cada regra continuam a ser decisivos.

Distinguir as respostas por operação e voltar a consultar o estado

As correspondências seguintes são concordantes nas referências SFOS-22/23. Os identificadores Message.* continuam a ser símbolos da documentação cujo significado não foi resolvido, não mensagens de execução garantidas, traduções ou causas inequívocas. O mesmo código pode ter significados diferentes consoante a operação. Em particular, estes são códigos de estado XML, não códigos de estado HTTP.

Para criar e editar regras Network/User, são relevantes as seguintes diferenças:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: verifique o nome antigo e o novo, as referências e o tipo de regra guardado; não assuma simplesmente um sucesso completo.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: compare a regra existente e a pretendida com base no estado consultado; não substitua automaticamente.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. Não deduza daí uma causa de erro comum nem um limite numérico de utilizadores.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: verifique em conjunto as zonas de destino e a configuração de Destination Heartbeat.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: compare o nome existente e o tipo de regra; não tente contornar o problema por tentativa através de uma mudança de nome ou de tipo.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: esclareça a responsabilidade de gestão e o procedimento autorizado para alterações.

As respostas específicas de WAF apresentadas em ambas as referências pertencem ao guia WAF; não aplique os respetivos conflitos de portas, redirecionamentos e Protected Servers às regras Network/User.

Também para grupos, registe a operação: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. A referência de Edit utiliza efetivamente os mesmos símbolos de Add. Antes de uma nova tentativa, consulte o nome do grupo guardado, os membros e ambas as listas de zonas; não deduza dos nomes dos símbolos que Edit executa uma operação de criação.

Na eliminação, aplica-se Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. A tabela Delete marca Name como opcional e descreve-o, de forma contraditória, como referência para Before/After. Não deduza daí uma eliminação geral sem nome. Antes de Remove, verifique o alvo exato, as dependências, a pertença a grupos, Linked NAT, a responsabilidade de gestão e o payload confirmado em API help. Para regras antigas pouco claras, a desativação controlada com uma janela de observação continua a ser o primeiro passo mais seguro.

Após cada resposta, e também após um timeout ou uma interrupção da ligação, consulte primeiro o estado efetivamente guardado antes de repetir o pedido: o nome, o tipo, o estado, a família de protocolos, a posição, os critérios, Exclusions, as referências de proteção e a pertença a grupos têm de corresponder ao estado pretendido aprovado. Em Remove, verifique também se falta exatamente a regra visada e se as regras necessárias e o NAT permanecem inalterados. Um resultado desconhecido pode já incluir uma alteração. Não repita cegamente, não execute um Upsert automático nem alargue o âmbito para Any; em caso de desvios, interrompa o procedimento, guarde a resposta expurgada de dados sensíveis e o Audit Trail e utilize o procedimento de reversão confirmado. Só depois se seguem os novos fluxos de teste permitidos e deliberadamente não permitidos descritos abaixo.

Testar e operar a regra

Teste de aceitação após guardar

Depois da configuração, guarda-se a regra com Save. A regra só está concluída quando o caso de teste definido produz os resultados esperados:

Em cada teste deve efetuar-se apenas uma alteração, para que a causa e o efeito possam ser associados.

1. Verificar a posição da regra e Rule group.
2. Verificar Log firewall traffic e os destinos em System services > Log settings.
3. Criar exatamente uma ligação de teste com um cliente, uma Destination e um Service definidos.
4. Verificar Firewall Rule ID, Rule name, utilizador e Action no Log Viewer.
5. Verificar NAT Rule ID e os endereços traduzidos.
6. Verificar DNS e routing separadamente.
7. Verificar Web Policy, Application Control, IPS e TLS Inspection com base na ação esperada.
8. Procurar Drops inesperados, erros SSL/TLS ou problemas de desempenho.
9. Remover a regra de teste ou limitá-la aos objetos de produção.

O Policy Tester simula a seleção de regras, mas não gera um fluxo real de pacotes nem confirma o routing ou o caminho de retorno. Por isso, o procedimento completo para Policy Test, Log Viewer e Packet Capture está disponível em Testar uma regra do Sophos Firewall.

Nova regra, regra existente ou desativação

Uma regra existente pode ser expandida quando Source, Destination, finalidade, Owner e requisitos de proteção permanecem iguais. Uma regra própria é preferível quando logging, data de expiração, Security Features, responsáveis ou ciclo de revisão são diferentes.

O acesso temporário de suporte, servidores, convidados, VoIP, IoT e administração não deve desaparecer numa regra geral de clientes. No caso de regras antigas pouco claras, a desativação controlada é normalmente mais segura do que a eliminação imediata:

1. Esclarecer a finalidade, o Owner e as dependências.
2. Definir o logging e a janela de teste.
3. Informar as equipas afetadas.
4. Desativar a regra e executar os testes definidos.
5. Removê-la apenas após um período de observação verificável.

Uma regra de emergência raramente utilizada pode ser importante. Por outro lado, uma regra genérica utilizada com frequência não é automaticamente segura.

Reverter uma alteração de regra

Antes de uma alteração, deve registar-se a posição atual e todos os campos afetados ou exportar um estado de configuração rastreável. Uma regra existente não deve ser reformulada para outra finalidade: uma regra nova, inicialmente desativada, oferece um caminho de reversão mais claro e mantém inalterada a autorização anterior.

Se o teste de aceitação falhar, desativa-se a nova regra ou, no caso de uma regra editada, restauram-se os valores anteriores e a posição original. Em seguida, criam-se novamente tanto o fluxo de teste permitido como um fluxo deliberadamente não permitido e verifica-se no Log Viewer a Firewall Rule ID esperada. Se a alteração afetar o caminho de administração, tem de ser mantido um acesso administrativo independente durante todo o procedimento.

Contador de dados, revisão e registo de alterações

Reset data transfer count repõe o contador de dados transferidos de uma regra. Não é um contador de sessões ou correspondências. Na ajuda do SFOS 22, a Sophos documenta Unused de forma diferente em dois locais: a ajuda da tabela de regras indica 24 horas sem tráfego correspondente, enquanto o widget Active firewall rules do Control Center indica 12 horas e uma verificação diária. Por isso, o estado não constitui um critério fiável para eliminar uma regra. New e Changed permanecem durante 24 horas após a criação ou alteração, e uma regra pode ter vários estados em simultâneo. Na ajuda do SFOS 23, tabela e widget indicam ambos 12 horas para Unused.

Os períodos podem sobrepor-se: uma regra criada às 10:00 mantém o estado New até às 10:00 do dia seguinte. Uma alteração às 11:00 atribui o estado Changed até às 11:00 do dia seguinte; entre as 11:00 e as 10:00 seguintes, a regra apresenta ambos os estados. Um estado Unused identificado na verificação diária às 12:00 mantém-se até à verificação seguinte. Se a regra for desativada às 13:00, pode apresentar simultaneamente Changed e Disabled até às 13:00 do dia seguinte e, depois, apenas Disabled. Estes exemplos da documentação não substituem a verificação da utilização efetiva nem uma decisão de eliminação. Antes de Reset data transfer count, documente o valor atual: a reposição não restaura um valor anterior do contador nem altera as permissões da regra.

Active firewall rules apresenta as regras por tipo e estado, bem como o tráfego correspondente em bytes nas últimas 24 horas. O mosaico distingue WAF (Webserver Protection), User (com utilizadores ou grupos) e Network (sem estes critérios). Scanned designa o número total de regras no gráfico, não o número de regras sujeitas a análise de malware. Disabled significa que a regra está configurada, mas desativada; uma regra desativada pode estar também no estado Changed. Ao passar o cursor, pode consultar o volume de dados; um clique no número ou no estado abre a tabela de regras com o filtro correspondente.

O widget do Control Center é visível para todos os administradores, independentemente dos respetivos direitos. A sua visibilidade não comprova, por isso, o acesso de escrita à página de regras. Estes indicadores devem ser avaliados juntamente com os logs, a descrição da regra e o caso de utilização. Para analisar os dados transferidos, também pode utilizar-se Reports > Dashboards > Traffic dashboard > Allowed policies. Se uma regra esperada não aparecer na tabela, deve repor-se primeiro o filtro ativo; a ajuda do SFOS 22 também limita as ações de grupo numa vista filtrada.

As revisões regulares verificam pelo menos:

• Source, Destination e Services;
• objetos Any restantes;
• Owner, ticket e data de expiração;
• logging e utilização efetiva;
• NAT, Web Policy, IPS, TLS Inspection e outras funções de proteção;
• regras desativadas, temporárias e criadas automaticamente.

Antes de alterações maiores, deve existir um backup. Audit Trail Logs e Config Studio mostram as alterações de configuração; em grupos geridos pelo Sophos Fusion, a Firewall Management Task Queue confirma se a alteração chegou ao appliance correto. O Firewall Health Check complementa a revisão regular de segurança.

Erros típicos

• A regra esperada não é aplicada ou aparece Rule ID #0: verificar a ordem, IPv4/IPv6 e todos os critérios Source, Destination, Service, utilizador e Exclusion.
• A Firewall Rule ID está correta, mas NAT Rule ID ou o caminho do pacote não: verificar a ordem NAT, o routing, SD-WAN e o caminho de retorno.
• A regra é aplicada, mas a proteção não funciona ou a aplicação falha: verificar separadamente a licença, a ativação global, o logging, Web Policy, QUIC, TLS Inspection, IPS e Traffic Shaping Policy.

Se Rule ID, NAT ID ou o caminho do pacote forem inesperados, A regra do Sophos Firewall não é aplicada ajuda na análise estruturada da causa.