Compreender e configurar regras Sophos Firewall

As Firewall Rules são o núcleo da Sophos Firewall. Determinam que tráfego entre zonas, redes, utilizadores e serviços é permitido ou bloqueado, e que funções de protecção são aplicadas.

Este artigo explica uma Sophos Firewall Rule de cima para baixo: ordem, grupos, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR e análise de e-mail.

O caminho do menu é:

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

Navegação rápida

• Princípio básico e ordem
• Exemplo prático
• Área superior: estado, nome, acção e logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Verificar depois de guardar
• Erros comuns

Princípio básico e ordem

As Firewall Rules controlam tráfego entre zonas e redes. Podem permitir, descartar ou bloquear tráfego e aplicar Security Features adicionais.

A Sophos Firewall verifica as Firewall Rules de cima para baixo. Assim que uma regra corresponde, as regras seguintes deixam de ser verificadas. Portanto, não importa apenas o que está configurado na regra, mas também a sua posição na lista.

Uma regra só corresponde quando todos os critérios relevantes correspondem ao mesmo tempo:

A primeira regra correspondente ganha. Se uma regra geral LAN_to_WAN_Any estiver acima de uma regra mais específica LAN_to_WAN_Restricted, a regra específica nunca será atingida.

Exemplo prático

Neste exemplo cria-se uma regra limpa para clientes:

Objectivo: clientes da LAN interna podem aceder à Internet. Web Filtering, Application Control, IPS e logging devem estar activos. Servidores, convidados e redes de management recebem regras próprias e não são misturados nesta regra de clientes.

Este exemplo não é deliberadamente uma autorização geral Any. Na prática, redes de clientes, servidores, Wi-Fi de convidados, VoIP e management devem ser tratados separadamente.

Área superior: estado, nome, acção e logging

Rule status

Rule status activa ou desactiva a regra.

Uma nova regra está normalmente activa. Regras preparadas podem ficar desactivadas e ser ligadas mais tarde. Regras desactivadas devem ser revistas regularmente para que regras antigas de teste ou migração não fiquem na configuração.

Exemplo prático: uma nova regra para um servidor é preparada, mas só é activada durante a janela de manutenção.

Rule name

O nome deve mostrar imediatamente o que a regra faz.

Bons nomes:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Nomes como Rule1, Test, Allow ou Internet são menos úteis, porque mais tarde já não se reconhece a finalidade da regra.

Description

A descrição é importante para operação, suporte e auditorias. Deve indicar:

• porque existe a regra
• quem pediu a regra
• que restrições foram definidas conscientemente
• se existe um ticket, projecto ou data de expiração

Exemplo:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

O artigo Como documentar facilmente uma regra Sophos Firewall explica em mais detalhe como usar este campo correctamente e documentar Firewall Rules de forma rastreável.

Rule position

Rule position define onde a nova regra é inserida.

Regra base: específico antes de geral. Uma regra para um servidor individual ou uma aplicação específica costuma ficar acima de uma regra geral de Internet.

Rule group

Rule group é um agrupamento organizacional. O grupo não é uma fronteira de segurança nem um motor de policy separado. A firewall continua a verificar as regras individuais de cima para baixo.

Grupos úteis:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

Em ambientes pequenos, None pode ser suficiente. Em ambientes maiores, uma organização clara compensa cedo, porque a base de regras fica rapidamente difícil de ler.

Action

Action determina o que acontece ao tráfego correspondente.

Para regras normais de clientes ou servidores usa-se geralmente Accept. Para regras de bloqueio, Drop é mais silencioso; Reject é frequentemente mais conveniente no troubleshooting.

Log firewall traffic

Log firewall traffic deve estar activo em quase todas as regras importantes.

Sem logging, faltam depois informações importantes em Log viewer. Muitos casos de troubleshooting falham não por causa da regra em si, mas porque o logging não estava activo e não se vê que regra correspondeu realmente.

Importante: a firewall normalmente regista sessões quando uma ligação termina e é criado um evento Destroy. Nem todas as ligações aparecem exactamente no momento em que o cliente as inicia.

Para que os logs fiquem visíveis localmente, no Sophos Central ou via syslog, System services > Log settings também tem de estar configurado correctamente. Para retenção mais longa, Sophos Central Firewall Reporting ou um servidor syslog é útil. Mais informação: Activar Central Firewall Reporting.

Source

A secção Source define de onde vem o tráfego.

Source zones

Source zones é a zona de origem do tráfego.

Exemplos:

• LAN para redes internas de clientes
• VPN para utilizadores Remote Access
• DMZ para redes de servidores
• Guest para Wi-Fi de convidados
• WAN para tráfego de Internet de entrada

Exemplo prático: para uma regra de clientes para Internet selecciona-se LAN. Para uma regra DNAT do exterior para um servidor interno, a Firewall Rule associada usa normalmente WAN como Source zone.

Source networks and devices

Source networks and devices restringe a origem.

Objectos possíveis:

• hosts individuais
• redes
• IP ranges
• grupos de hosts
• FQDN Hosts
• objectos de país

No início, Any parece cómodo, mas é frequentemente demasiado amplo. Uma rede de clientes concreta, um grupo de hosts ou um objecto de rede claramente nomeado é melhor.

Exemplo prático: em vez de Any na Source usa-se net_LAN_Clients. Servidores, impressoras, convidados e equipamentos de management recebem regras próprias.

During scheduled time

During scheduled time define quando a regra se aplica.

Valores típicos:

• All the time
• horário laboral
• janelas de manutenção
• acessos temporários

Schedules são úteis quando um acesso só deve ser permitido em determinadas horas. No troubleshooting, deve-se sempre verificar se a hora da firewall, o fuso horário e o schedule coincidem.

Exemplo prático: um acesso externo de manutenção a um servidor só é permitido durante uma janela definida.

Destination and services

A secção Destination and services define para onde o tráfego pode ir e que portas ou protocolos são permitidos.

Destination zones

Destination zones é a zona de destino.

Exemplos:

• WAN para acesso à Internet
• DMZ para servidores numa DMZ
• LAN para destinos internos
• VPN para utilizadores remotos ou túneis Site-to-Site

Exemplo prático: para tráfego de clientes para Internet usa-se WAN. Para acesso de clientes a um servidor interno pode usar-se Server ou DMZ, se estas zonas existirem.

Destination networks

Destination networks restringe o destino.

Para regras de Internet de clientes, Any é muitas vezes um ponto de partida prático. Para servidores, redes de management ou acessos VPN, os destinos devem ser muito mais limitados.

Exemplos:

• Any para acesso geral à Internet
• FQDN Host como updates.vendor.com
• objecto host de um servidor interno
• objecto de rede de um site remoto via VPN
• objecto de país para regras Geo-IP

Exemplo prático: um servidor de backup só pode aceder aos destinos cloud backup do fabricante, não a Any.

Services

Services são definições de protocolo e porta.

Exemplos:

• HTTP para TCP 80
• HTTPS para TCP 443
• DNS para TCP/UDP 53
• NTP para UDP 123
• serviços próprios como Synology_5555

Os Services devem ser escolhidos de forma tão restrita quanto possível. Any só faz sentido se todos os protocolos tiverem mesmo de ser permitidos ou se forem usados outros controlos de forma consciente.

Exemplo prático: para clientes web normais, um grupo com HTTP, HTTPS, DNS e NTP costuma ser suficiente. Para acesso a um servidor a partir da Internet, permite-se apenas o serviço realmente publicado.

Match known users

Com Match known users, a identidade do utilizador passa a fazer parte do matching. A regra deixa de se aplicar apenas a endereços IP e passa a aplicar-se a utilizadores ou grupos conhecidos.

Isto é útil quando:

• Web Policies devem aplicar-se por grupo AD
• o reporting deve ser baseado em utilizadores
• grupos diferentes precisam de permissões Internet diferentes
• MFA, Captive Portal ou SSO já estão bem configurados

Armadilha: se a autenticação não funcionar correctamente, a regra pode não corresponder. O tráfego passa então para uma regra mais geral abaixo ou é descartado pela regra drop-all.

Para testes iniciais, é muitas vezes melhor começar sem User Matching e adicionar critérios de utilizador mais tarde.

Add exclusion

Com Add exclusion, tráfego pode ser excluído de uma regra. A firewall só salta esta regra se todos os critérios de exclusion definidos corresponderem, e depois verifica a regra seguinte.

Exclusions podem conter Source zones, Source networks and devices, Destination zones, Destination networks e Services.

Exemplo prático: uma regra geral de Internet para clientes usa Web Filtering. Um servidor de updates específico deve usar uma regra própria com Security Features diferentes. Esse servidor pode ser excluído da regra geral.

Exclusions são poderosas, mas tornam as regras mais difíceis de ler. Se uma regra tem muitas excepções, uma regra específica separada é normalmente mais compreensível.

Create linked NAT rule

Com Create linked NAT rule, uma regra Source NAT pode ser criada directamente a partir da Firewall Rule. Esta Linked NAT Rule aparece depois na tabela NAT.

Para principiantes parece cómodo, mas na prática regras NAT autónomas são geralmente mais claras. Se uma regra NAT genérica já cobre o mesmo tráfego correctamente, não se deve criar uma Linked NAT Rule adicional.

Para uma regra normal de cliente para Internet, a regra SNAT predefinida com MASQ costuma ser suficiente, desde que esteja activa e adequada à base de regras.

Importante: NAT não permite tráfego por si só. NAT traduz endereços ou portas. Se o tráfego é permitido continua a ser decidido pela Firewall Rule correspondente.

Mais informação: Compreender NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

Na secção Web filtering configuram-se Web Policy, malware scan e comportamento do filtro web.

Web policy

Web policy controla acessos web através de categorias, utilizadores, grupos, URL groups e regras.

Exemplo prático: para clientes usa-se uma Web Policy que bloqueia malware, phishing, adult content e categorias de risco, mas permite aplicações de negócio.

Se nenhuma Web Policy estiver definida, não há filtragem web por categorias através desta opção.

Apply web category-based traffic shaping

Esta opção aplica Traffic Shaping com base em categorias web. Só é útil quando são usadas regras Traffic Shaping ou Web Category Policies correspondentes.

Exemplo prático: categorias de streaming são limitadas, enquanto aplicações de negócio mantêm prioridade.

Block QUIC protocol

QUIC usa UDP 80 e UDP 443. Muitos browsers usam QUIC para serviços Google e outras aplicações web modernas.

Se Web Filtering ou Malware Scan em tráfego web for importante, Block QUIC protocol deve ficar activo em muitos ambientes. Os browsers normalmente voltam para HTTPS normal sobre TCP, que é mais fácil de controlar e inspeccionar.

Scan HTTP and decrypted HTTPS

Esta opção analisa HTTP e HTTPS já decifrado à procura de malware.

Importante: esta opção não decifra HTTPS automaticamente. Para inspeccionar HTTPS de facto, são necessárias SSL/TLS inspection rules adequadas em Rules and policies > SSL/TLS inspection rules.

Exemplo prático: se TLS Inspection estiver activa para LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS pode analisar ficheiros descarregados em tráfego HTTPS decifrado.

Mais informação: Implementar TLS Inspection na Sophos Firewall passo a passo.

Use Zero-day protection

Use Zero-day protection envia downloads suspeitos para Sophos Zero-Day Protection para análise adicional. É útil para regras de clientes e servidores em que downloads da Internet devem ser verificados.

A função requer uma licença adequada e pode causar atrasos dependendo do tipo de ficheiro e da policy.

Scan FTP for malware

Esta opção analisa tráfego FTP à procura de malware. Só é relevante se FTP for realmente usado e os serviços correspondentes estiverem permitidos na regra.

Em ambientes modernos, FTP é menos comum, mas ainda aparece em sistemas legacy, controlos industriais ou mecanismos de update antigos.

Use web proxy instead of DPI engine

A Sophos Firewall pode inspeccionar tráfego web através do DPI engine ou do Web Proxy.

Para setups modernos, DPI é normalmente a melhor opção predefinida, porque tráfego HTTP e SSL/TLS pode ser processado em todas as portas. O Web Proxy continua útil quando são necessárias funções proxy específicas, como SafeSearch enforcement, restrições YouTube, limitação Google app domain, Pharming Protection, Web Cache ou Parent Proxy.

Se Use web proxy instead of DPI engine não estiver activo, a regra trabalha em modo DPI.

Decrypt HTTPS during web proxy filtering

Esta opção pertence ao modo Web Proxy. Só é relevante se Use web proxy instead of DPI engine estiver activo e HTTPS tiver de ser decifrado em modo proxy.

Em modo DPI, HTTPS decryption não é controlado aqui, mas através de SSL/TLS inspection rules.

Synchronized Security Heartbeat

Com Configure Synchronized Security Heartbeat, o estado Sophos Endpoint pode ser incluído na Firewall Rule.

Opções típicas:

• definir estado mínimo para dispositivos de origem
• bloquear clientes sem Heartbeat
• definir estado mínimo para dispositivos de destino
• bloquear pedidos para destinos sem Heartbeat

É poderoso, mas só é útil se Sophos Endpoint, Sophos Central e Security Heartbeat estiverem bem configurados.

Exemplo prático: clientes com Security Heartbeat vermelho deixam de poder aceder a servidores ou à Internet.

Para uma primeira regra de clientes, Heartbeat não deve ser activado às cegas, caso contrário podem ser bloqueados dispositivos que não conseguem enviar Heartbeat.

Other security features

Identify and control applications (App control)

Com Identify and control applications (App control) selecciona-se uma Application Filter Policy.

Permite detectar e controlar aplicações como:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control requer uma licença adequada. Na prática, esta função está incluída nos Sophos Firewall Bundles com Web Protection, por exemplo Standard Protection, Xstream Protection ou Epic Protection.

Para detecção de aplicações em tráfego cifrado, TLS Inspection é muitas vezes decisiva. Sem decryption, a firewall vê, dependendo do serviço, apenas hostnames, SNI, informações de certificado ou IPs, e não o conteúdo completo.

Apply application-based traffic shaping policy

Esta opção aplica Traffic Shaping definido na Application Policy ou no Application Object.

Exemplo prático: Microsoft Teams deve ser detectado e priorizado com uma determinada Traffic Shaping Policy. A Application Control Policy correcta tem de estar seleccionada e a application-based traffic shaping policy tem de ser aplicada.

Se em Shape traffic já estiver definida uma Traffic Shaping Policy explícita, deve ficar documentado que policy tem prioridade e porquê.

Detect and prevent exploits (IPS)

Em Detect and prevent exploits (IPS) selecciona-se uma IPS Policy.

IPS verifica tráfego contra padrões de ataque e exploits conhecidos. Tráfego de clientes para a Internet usa uma policy diferente de tráfego de servidores ou serviços publicados.

Exemplos práticos:

• regra de clientes LAN_to_WAN: IPS policy de clientes ou LAN-to-WAN
• regra DNAT para webserver: IPS policy de servidor ou webserver
• regra VoIP: testar cuidadosamente, porque perfis IPS agressivos podem afectar VoIP

IPS não deve ser activado simplesmente em todo o lado com a policy mais rigorosa. Uma IPS Policy demasiado ampla ou errada pode quebrar tráfego legítimo ou gerar carga desnecessária.

Shape traffic

Com Shape traffic, uma Traffic Shaping Policy pode ser aplicada directamente à regra.

É relevante para:

• VoIP
• videoconferência
• tráfego de backup
• Wi-Fi de convidados
• ligações WAN lentas

Exemplo prático: o Wi-Fi de convidados recebe uma limit policy para não prejudicar o tráfego de negócio.

Mais informação: Configurar Application Traffic Shaping na Sophos Firewall.

DSCP marking

DSCP marking marca pacotes para Quality of Service em equipamentos de rede a jusante.

Só é útil se switches, routers ou equipamentos WAN também avaliarem estes valores DSCP. A Sophos Firewall pode marcar, mas o resto da rede tem de tratar essas marcações de forma consistente.

Exemplo prático: o tráfego VoIP recebe uma marcação DSCP para que switches e routers WAN o tratem com prioridade.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence usa Sophos NDR Threat Intelligence para avaliação adicional do tráfego de rede.

Esta opção só é útil se o ambiente usar os componentes Sophos Central e NDR necessários. Em muitos ambientes não é a primeira opção para uma regra base, mas pode ser um complemento valioso em redes mais monitorizadas.

Scan email content

A secção Scan email content diz respeito aos protocolos de e-mail.

Opções possíveis:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Se protocolos forem activados aqui, as portas standard correspondentes também têm de estar incluídas nos Services da regra ou adicionadas através de Add ports.

Para regras web normais de clientes, esta secção muitas vezes não é relevante. Para mail servers ou tráfego mail de clientes, deve ser planeada conscientemente.

Exemplo prático: um mail server interno pode enviar SMTP para fora. Cria-se uma regra de servidor separada, activa-se logging e verifica-se o e-mail scanning de acordo com a arquitectura de mail.

Verificar depois de guardar

Depois de guardar, deve-se testar a regra em vez de assumir que tudo funciona correctamente.

Verificar:

1. A regra está na posição correcta?
2. Log firewall traffic está activo?
3. A regra corresponde no Log viewer?
4. A Firewall Rule ID esperada é apresentada?
5. A regra NAT esperada aplica-se?
6. DNS funciona?
7. Web Filtering, IPS, Application Control e TLS Inspection são aplicados como esperado?
8. Existem drops ou erros SSL/TLS inesperados?

Para uma verificação limpa: Testar Firewall Rules com Log Viewer, Policy Test e Packet Capture.

Erros comuns

A regra está demasiado abaixo: uma regra mais geral acima corresponde primeiro ao tráfego.

Source é demasiado ampla: Any pode funcionar, mas torna as regras pouco claras e aumenta a superfície de ataque.

Destination é demasiado ampla: servidores ou redes de management raramente devem aceder à Internet com Any.

Services é demasiado amplo: Any permite muito mais do que o necessário. Serviços concretos ou grupos de serviços são melhores.

Logging não está activo: faltam então as informações mais importantes no Log Viewer.

HTTPS não é analisado: Scan HTTP and decrypted HTTPS está activo, mas não existe uma SSL/TLS inspection rule adequada ou não há decryption.

Web Filtering não se aplica: nenhuma Web Policy definida, utilizador errado, Source zone errada ou QUIC não bloqueado.

User Matching não se aplica: autenticação, AD SSO, Captive Portal ou associação de utilizadores não funcionam correctamente.

NAT falta: a Firewall Rule permite o tráfego, mas SNAT/MASQ não corresponde.

Security Feature não se adequa ao tráfego: uma IPS Policy errada, opção proxy ou opção de e-mail scanning pode quebrar tráfego legítimo.