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

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. Assim que todos os critérios de uma regra correspondem, 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.

Uma regra pode corresponder, entre outros critérios, a Source zone, Source network, horário, Destination zone, Destination network, Service, utilizador e Exclusions. Todos os critérios configurados têm de corresponder à ligação.

As regras MTA, IPsec ou Hotspot criadas automaticamente podem aparecer no topo da lista. 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. 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; o tráfego descartado é registado como evento.

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.

Action e logging

Action define o tratamento do tráfego correspondente:

• Accept: permite a ligação.
• Drop: normalmente descarta-a sem resposta. Se Use web authentication for unknown users estiver ativado, o SFOS pode apresentar uma página de bloqueio para tráfego web.
• Reject: descarta-a e envia um Reset para TCP ou uma resposta ICMP adequada para UDP e ICMP.
• 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.

Drop é adequado para descartar silenciosamente; Reject fornece mais depressa uma resposta reconhecível durante testes internos ou troubleshooting.

Log firewall traffic deve estar ativado nas regras importantes. Além disso, os destinos locais, Sophos Central ou Syslog adequados têm de estar ativados em System services > Log settings. 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 conexõ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.

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.

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.

Create linked NAT rule

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.

A configuração de fábrica inclui normalmente uma regra Default SNAT com MASQ. Antes de adicionar uma Linked NAT Rule, deve verificar-se se essa regra 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.

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 presença de malware em HTTP e HTTPS já desencriptado. A opção não ativa a desencriptação. Para isso, é necessária uma SSL/TLS inspection rule adequada em Rules and policies > SSL/TLS inspection rules.

Use Zero-day protection envia downloads suspeitos para análise adicional após a análise de malware. A função requer Zero-Day Protection e, dependendo do tipo de ficheiro e da policy, pode causar um atraso.

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.

Synchronized Security Heartbeat

As regras Heartbeat requerem:

• um firewall registado na mesma conta Sophos Central 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 Central > 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.

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.

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 Sophos não documenta de forma uniforme a prioridade ao combinar Application Policy e 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.

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 os pacotes para switches, routers ou dispositivos WAN a jusante. A marcação, por si só, não dá prioridade a nada; todos os dispositivos envolvidos têm de tratar os valores DSCP selecionados de forma consistente.

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 dispositivos XGS 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 Central são opcionais para uma análise avançada no Central.

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.

Testar e operar a regra

Teste de aceitação após guardar

Depois de guardar, 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.

Para Policy Test, Log Viewer e Packet Capture, existe o procedimento específico 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.

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. O estado Unused apenas indica que não foi encontrado tráfego correspondente nas últimas 24 horas. Ambos os 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.

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 Central, 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.