Saltar para o conteudo
Avanet

Entenda e configure com segurança as regras Sophos Firewall

Sophos Firewall

As regras de firewall estão no centro do Sophos Firewall. Estas regras determinam qual tráfego entre zonas, redes, usuários e serviços é permitido ou bloqueado e quais funções de proteção são aplicadas.

Este artigo explica uma regra Sophos Firewall de cima para baixo: Ordem, Grupos, Ação, Registro, Origem, Destino, Services, Correspondência de usuário, Exclusões, NAT, Filtragem da Web, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR e verificação de e-mail.

O caminho do menu é:

Rules and policies > Regras de firewall > Adicionar regra de firewall > Nova regra de firewall

Sophos Firewall Adicione regra de firewall com todas as opções, desde status da regra até recursos de segurança
Sophos Firewall - Adicionar regra de firewall: A regra é configurada de cima para baixo e posteriormente avaliada com base na ordem das regras.

A máscara de regras é dividida em diversas áreas: área de cabeçalho, origem, destino, Services, referência do usuário, link NAT e recursos de segurança. Na prática, é importante não ver a máscara como um conjunto de ganchos individuais. Uma regra só funciona corretamente se a origem, o destino, o serviço, a sequência, o registro e as funções de proteção ativadas corresponderem.

Antes de criá-la, também deve ficar claro se se trata de uma regra IPv4 ou IPv6. A visualização da regra é selecionada adequadamente no WebAdmin. Em ambientes de pilha dupla, o IPv4 e o IPv6 devem ser intencionalmente planejados e testados separadamente; uma regra IPv4 funcional não prova automaticamente que o IPv6 é igualmente seguro.

Qual artigo de política de rede se encaixa?

Regras de firewall, NAT, WAF, VLANs e roteamento estão intimamente interligados no Sophos Firewall. Portanto, é importante que os administradores escolham primeiro o tópico certo:

Essa separação evita a solução de problemas típica. Uma regra NAT não permite tráfego, uma regra de firewall não traduz um endereço e uma regra WAF não é igual ao encaminhamento de porta DNAT normal.

O que as regras de firewall controlam e o que não controlam

As regras de firewall controlam o tráfego que flui através do firewall. Mas estas regras não são o único ponto de controle em SFOS. Muitas soluções de problemas ocorrem porque você está procurando um comportamento na lista de regras do firewall, mesmo que outra área seja responsável.

  • Tráfego entre zonas, redes, utilizadores e serviços: Regras de firewall. É aqui que é decidido se o tráfego é permitido, rejeitado ou verificado com recursos de segurança.
  • WebAdmin, User Portal, VPN Portal, SSH, DNS ou SNMP para o próprio firewall: Device Access e Local Service ACL. Os serviços de firewall local não são tratados como tráfego normal de LAN para WAN ou WAN para DMZ.
  • Endereço ou porto tradução: Regras NAT. O NAT traduz o tráfego, mas não o permite automaticamente.
  • Seleção de rota, rota de retorno, caminhos SD-WAN e VPN: Roteamento, configuração SD-WAN, Route Precedence e VPN. Uma regra de firewall adequada não funciona bem.
  • Categorias da Web, grupos de URLs e políticas da Web: Filtragem Web e Política Web. A regra de firewall integra a política, mas a lógica da web real está na política da web.
  • Descriptografia HTTPS: Regras de inspeção SSL/TLS e distribuição de CA. Scan HTTP and decrypted HTTPS verifica apenas o tráfego que já está descriptografado.
  • Identidade do usuário: Autenticação, STAS, Portal Cativo, Entra ID SSO ou RADIUS. Uma regra de usuário só corresponde se o firewall puder atribuir o usuário ao tráfego.

Para serviços de gerenciamento e portal, Device Access e Local Service ACL é o artigo central. Se uma regra corresponder, mas a conexão ainda falhar, Regra Sophos Firewall não funciona: verificar causas e Testar regra de firewall com Log Viewer, Policy Test e Packet Capture ajudarão. Especialmente em redes IPv4/IPv6 mistas, você também deve verificar se uma aplicação via IPv6 ignora uma regra IPv4 mais rigorosa. Se o IPv6 não for utilizado ativamente, a estratégia do IPv6 ainda deve ser conscientemente documentada: desativar, bloquear, regular adequadamente ou introduzi-lo de forma controlada.

Princípio básico e sequência

As regras de firewall controlam o tráfego entre zonas e redes. As regras permitem, rejeitam ou bloqueiam o tráfego e podem aplicar recursos de segurança adicionais.

Sophos Firewall verifica as regras do firewall de cima a baixo. Assim que uma regra corresponder, as regras de firewall subsequentes não serão mais verificadas. O que é importante não é apenas o que está numa regra, mas também onde está na lista de regras.

Uma regra só se aplica se todos os critérios relevantes se aplicarem ao mesmo tempo:

  • Zona de origem: Sim. LAN.
  • Source networks and devices: Sim. net_LAN_Clients.
  • Cronograma: Sim. All the time.
  • Zona de destino: Sim. WAN.
  • Destination networks: Sim. Any ou um host FQDN.
  • Services: Sim. HTTP, HTTPS, DNS.
  • Correspondência de usuários: Somente se ativado. Grupo AD Internet-Users.
  • Exclusões: Se definida, a regra pode ser ignorada. Excluir servidor de backup.

A primeira regra correspondente vence. Se uma regra LAN_to_WAN_Any geral estiver acima de uma regra LAN_to_WAN_Restricted específica, a regra específica nunca será alcançada.

Planeje a base de regras antes de criar

Uma única regra de firewall pode ser criada rapidamente. O que é mais difícil é uma base de regras que ainda seja compreensível, testável e segura após dois anos. Portanto, antes de introduzir novas regras, você deve primeiro esclarecer a qual zona de segurança, grupo e lógica operacional a regra pertence.

Perguntas orientadoras úteis:

  • Que tipo de tráfego deveria realmente ser permitido?: Anote a origem, o destino e Services antes de criar.
  • O tráfego pertence à sua própria zona?: Separe conscientemente servidores, clientes, convidados, gerenciamento, VPN e DMZ.
  • Já existe uma regra específica?: Verifique as regras existentes em vez de criar uma segunda regra semelhante.
  • O NAT está envolvido?: Planeje regras de firewall e regras de NAT juntas, mas não as misture.
  • Como isso será verificado mais tarde?: Ative o registro em log e defina o tráfego de teste específico.
  • A liberação é temporária?: Documente a data de validade ou ingresso na descrição.

Para zonas e interfaces limpas, Sophos Firewall Configurar zonas e interfaces é adequado primeiro. Se uma regra existente não funcionar, a lista de verificação A regra Sophos Firewall não funciona: verificar as causas ajudará.

⚠️ Uma regra Any ampla geralmente é conveniente, mas raramente é uma boa configuração final. Pode ajudar a curto prazo nos testes. Deve então ser substituído ou removido novamente por fontes, destinos e serviços específicos.

Tipos de regras claramente separados

Uma boa base de regras separa visivelmente os diferentes riscos uns dos outros. O erro mais comum não é uma única opção incorreta, mas uma regra geral que abrange clientes, servidores, VPN, convidados e gerenciamento ao mesmo tempo. Isso funciona rapidamente no início, mas depois se torna difícil de testar e difícil de endurecer.

  • Cliente Internet: Fonte típica: Redes de clientes; Alvo típico: WAN; Em que prestar atenção?: Política da Web, Application Control, IPS, TLS Inspection, QUIC, Registro em log.
  • Servidor Internet: Fonte típica: Redes de servidores; Alvo típico: atualização definida, backup ou metas de nuvem; Em que prestar atenção?: mais rígidas que as regras do cliente, muitas vezes sem referência do usuário.
  • Convidado-WLAN: Fonte típica: Zona de Convidados; Alvo típico: WAN; Em que prestar atenção?: nenhum controle consciente de alvos internos, largura de banda e DNS.
  • Gestão: Fonte típica: Redes administrativas; Alvo típico: Firewall, servidores, switches, hipervisores; Em que prestar atenção?: não misture com as regras normais do cliente.
  • VPN Acesso Remoto: Fonte típica: VPN ou zona de acesso remoto própria; Alvo típico: zonas-alvo internas; Em que prestar atenção?: apenas destinos e serviços necessários, registrando na fase introdutória.
  • Site a site: Fonte típica: zonas VPN locais e remotas ou zonas XFRM; Alvo típico: Redes de parceiros ou locais; Em que prestar atenção?: Verifique roteamento, NAT, caminho de retorno e registro em conjunto.
  • Sistema Publicado: Fonte típica: WAN ou fontes definidas; Alvo típico: DMZ ou zona do servidor; Em que prestar atenção?: DNAT/WAF, IPS, registro, nível de patch e limitação de fonte.
  • Acesso temporário: Fonte típica: suporte definido ou origem do projeto; Alvo típico: alvo estreito; Em que prestar atenção?: Bilhete de documento, prazo de validade, proprietário e desmontagem.

Se duas conexões tiverem proprietários, funções de proteção ou ciclos de revisão diferentes, regras separadas geralmente são mais limpas. Caso seja necessário apenas um serviço adicional para o mesmo fim profissional, uma regra existente pode ser ampliada.

Exemplo prático fictício

Por exemplo, uma regra de cliente limpa é criada:

Alvo: Clientes do LAN interno têm permissão para acessar a Internet. Filtro da Web, Application Control, IPS e registro devem estar ativos. Servidores, convidados e redes de gerenciamento possuem regras próprias e não se misturam a esta regra de cliente.

  • Nome da regra: LAN_to_WAN_Clients. Limpar nome com origem e destino.
  • Descrição: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Mais tarde você saberá porque a regra existe.
  • Rule position: Sob regras específicas de bloco e servidor. Regras específicas deverão entrar em vigor primeiro.
  • Rule group: Internet Access. Melhor visão geral.
  • Ação: Accept. O tráfego é permitido.
  • Registrar tráfego de firewall: Habilitado. Solução de problemas do Log Viewer.
  • Source zones: LAN. O tráfego vem da zona LAN.
  • Source networks and devices: net_LAN_Clients. Nem todas as redes LAN, apenas clientes.
  • Durante o horário programado: All the time. O acesso à Internet deve ser permanente.
  • Destination zones: WAN. Alvo é a Internet.
  • Destination networks: Any. Principalmente prático para clientes na Internet.
  • Services: HTTP, HTTPS, DNS, NTP. Apenas serviços básicos necessários.
  • Web policy: Default Workplace Policy. Controlar o acesso à web com base em categorias.
  • Block QUIC protocol: Habilitado. A filtragem e a verificação da Web continuam eficazes.
  • IPS: Política do Cliente. Proteção contra exploração para tráfego de clientes de saída.
  • Controle de aplicativos: Política de aplicação do cliente. Bloqueie aplicativos indesejados.
  • Tráfego de forma: Opcional. Somente se a largura de banda for necessária.
  • DSCP marking: Vazio. Necessário apenas se os dispositivos downstream avaliarem o DSCP.

Este exemplo deliberadamente não é um ingresso gratuito Any. Na prática, redes de clientes, redes de servidores, redes de convidados, VoIP e gerenciamento devem ser consideradas separadamente. Para o primeiro teste produtivo, este exemplo deve incluir um breve caso de teste: cliente definido, endereço de destino específico, Rule ID esperado, NAT esperado Rule ID e uma olhada em Log Viewer ou Central/Syslog. Sem esta etapa de aprovação, não está claro se a regra realmente processa a conexão esperada.

Área do cabeçalho: Status, Nome, Ação e Registro

Status da regra

Status da regra ativa ou desativa a regra.

Uma nova regra geralmente está ativa. Para regras preparadas você pode desativar o status e ativar a regra somente mais tarde. As regras desativadas devem ser verificadas regularmente para que nenhuma regra antiga de teste ou migração permaneça na configuração.

Exemplo prático: Uma nova regra para um servidor é preparada mas só é ativada na janela de manutenção.

Nome da regra

O nome deve deixar claro 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 você não pode mais saber qual tarefa a regra possui.

Descrição

A descrição é importante para operações, suporte e auditorias. Deveria dizer:

  • por que a regra existe
  • quem solicitou a regra
  • quais restrições foram deliberadamente definidas
  • se existe um ticket, projeto ou data de validade

Exemplo:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

Como usar esse campo corretamente e documentar regras de firewall de maneira compreensível é descrito com mais detalhes no artigo Sophos Firewall documentando regras de maneira sensata.

Rule position

Rule position especifica onde a nova regra será inserida.

  • Top: Apenas para regras muito específicas, regras de bloqueio ou testes.
  • Bottom: Frequentemente útil para novas regras padrão.
  • Above rule: Se uma regra tiver especificamente de entrar em vigor antes de uma regra existente.
  • Below rule: Se uma regra deve seguir especificamente uma regra existente.

Regra básica: específico antes do geral. Uma regra para um servidor individual ou um aplicativo específico geralmente é superior a uma regra geral da Internet.

Rule group

Rule group é um agrupamento organizacional. O grupo em si não é um limite de segurança ou o seu próprio mecanismo político. O firewall continua verificando cada regra de cima para baixo.

Exemplos de grupos úteis incluem:

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

Em ambientes pequenos, None pode ser suficiente. Em ambientes maiores, vale a pena agrupar claramente desde o início, caso contrário a base de regras rapidamente se tornará confusa.

Ação

Ação determina o que acontece com o tráfego correspondente.

  • Accept: O tráfego é permitido. Regras normais de permissão.
  • Drop: O tráfego é descartado silenciosamente. Regras de bloqueio onde o cliente não deve receber resposta.
  • Reject: O tráfego é rejeitado e o cliente recebe uma resposta. Solução de problemas ou regras de bloqueio interno.
  • Protect with web server protection: A proteção WAF é aplicada. Proteção de servidor Web, não para regras normais de LAN para WAN.

Para regras normais de cliente ou servidor você normalmente usa Accept. Para regras de bloqueio, Drop é mais silencioso, Reject costuma ser mais agradável para solução de problemas.

Registrar tráfego de firewall

Registre o tráfego do firewall quase sempre deve ser ativado para regras importantes.

Sem o registro, informações importantes desaparecerão posteriormente no Visualizador de registros. Muitos casos de solução de problemas falham não por causa da regra em si, mas porque não houve registro e não é possível ver qual regra realmente foi aplicada.

Importante: O firewall normalmente registra sessões de firewall quando uma conexão é encerrada e ocorre um evento Destroy. Nem toda conexão aparece no exato momento em que o cliente a inicia.

Para que os logs fiquem visíveis localmente, em Sophos Central ou via Syslog, System services > Log settings também deve ser configurado adequadamente. Para armazenamento mais longo, o Relatório de Firewall Sophos Central ou um servidor Syslog faz sentido. Mais sobre isso: Ativar relatórios do Firewall Central e Enviar Sophos Firewall Syslog com segurança para SIEM.

Para regras produtivas, o registro em log não deve ser visto apenas como um gancho para solução de problemas. É também a base para revisões: a regra ainda é utilizada, a que fontes se aplica, quais os objetivos que são realmente abordados e se a regra é demasiado ampla.

Fonte, Zona e Programação

Na área Origem você define de onde vem o tráfego.

Source zones

Source zones é a zona de onde vem o tráfego.

Exemplos:

  • LAN para redes internas de clientes
  • VPN para usuários de acesso remoto
  • DMZ para redes de servidores
  • Guest para convidados-WLAN
  • WAN para tráfego de entrada da Internet

Exemplo prático: LAN é selecionado para uma regra de Internet de clientes para Internet. Para uma regra DNAT externa para um servidor interno, WAN geralmente é usado como zona de origem na regra de firewall associada.

Source networks and devices

Source networks and devices restringe a fonte com mais precisão.

Os objetos possíveis são, por exemplo:

  • anfitriões individuais
  • Redes
  • intervalos de IP
  • Grupos de hosts
  • anfitriões FQDN
  • Objetos do país

Para começar, Any parece confortável, mas geralmente é muito largo. Uma rede de cliente específica, um grupo de hosts ou um objeto de rede claramente nomeado é melhor.

Exemplo prático: Em vez de Any na fonte, utilize net_LAN_Clients. Servidores, impressoras, convidados e dispositivos de gerenciamento têm suas próprias regras.

Durante o horário agendado

Durante o horário agendado determina quando a regra se aplica.

Valores típicos:

  • All the time
  • Horário de trabalho
  • Janela de manutenção
  • lançamentos temporários

Os horários são úteis se o acesso só for permitido em determinados horários. Ao solucionar problemas, você sempre deve verificar se o horário, o fuso horário e a programação do firewall estão realmente corretos.

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

Destino e serviços

Na área Destino e serviços você define onde o tráfego é permitido e quais portas ou protocolos são permitidos.

Destination zones

Destination zones é a zona de destino.

Exemplos:

  • WAN para acesso à Internet
  • DMZ para servidores em um DMZ
  • LAN para alvos internos
  • VPN para usuários remotos ou rotas site a site

Exemplo prático: WAN é usado para tráfego de internet do cliente. Server ou DMZ podem ser usados ​​para clientes acessarem um servidor interno se essas zonas forem criadas adequadamente.

Destination networks

Destination networks restringe o alvo com mais precisão. Para regras de Internet do cliente, Any costuma ser um começo viável. Para servidores, redes de gerenciamento ou acesso VPN, os alvos devem ser significativamente mais limitados.

Exemplos:

  • Any para acesso geral à Internet
  • Host FQDN como updates.vendor.com
  • Objeto host de um servidor interno
  • Objeto de rede de uma estação remota via VPN
  • Objeto país para regras Geo-IP

Exemplo prático: Um servidor de backup só pode ir para os destinos de backup na nuvem do fabricante, e não para 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
  • possuir Services como Synology_5555

Services deve ser escolhido da forma mais restrita possível. Any só faz sentido se todos os protocolos realmente precisarem ser permitidos ou se você trabalhar conscientemente com outros controles.

Exemplo prático: Para clientes web normais, um grupo com HTTP, HTTPS, DNS e NTP geralmente é suficiente. Somente o serviço efetivamente publicado é permitido para acesso ao servidor pela Internet.

Match known users

Com Match known users, a identidade do usuário passa a fazer parte da correspondência. A regra não se aplica mais apenas a endereços IP, mas a usuários ou grupos conhecidos.

Isso faz sentido se:

  • As políticas da Web devem ser aplicadas por grupo AD
  • Os relatórios devem ser relacionados ao usuário
  • diferentes grupos de usuários obtêm diferentes direitos de internet
  • MFA, Portal Cativo ou SSO já estão configurados corretamente

Obstáculo: se a autenticação não funcionar corretamente, a regra pode não corresponder. Em seguida, o tráfego cai para uma regra mais geral abaixo ou é descartado pela regra drop-all.

Para testes iniciais, geralmente é melhor começar sem correspondência de usuário e adicionar critérios de usuário posteriormente.

Se a correspondência de usuários for usada, não deverá haver uma regra de fallback ampla que permita o mesmo tráfego sem referência do usuário. Caso contrário, a regra do usuário parecerá limpa, mas os usuários desconhecidos ainda terão a regra geral. Quando aceito, o Log Viewer deverá, portanto, mostrar o usuário, grupo e Rule ID.

Adicionar exclusão

Com Adicionar exclusão o tráfego pode ser excluído de uma regra. O firewall só ignora esta regra se todos os critérios de exclusão definidos corresponderem e então verifica a próxima regra.

As exclusões podem incluir Source zones, Source networks and devices, Destination zones, Destination networks e Services.

Exemplo prático: Uma regra geral de Internet para clientes utiliza filtros web. No entanto, um servidor de atualização específico deve executar sua própria regra com outros recursos de segurança. Então você pode excluir este servidor da regra geral.

As exclusões são poderosas, mas tornam as regras mais difíceis de ler. Se uma regra contém muitas exceções, uma regra específica separada geralmente é mais compreensível.

Create linked NAT rule

Com Create linked NAT rule uma regra NAT de origem pode ser criada diretamente a partir da regra de firewall. Essa regra NAT vinculada aparece na tabela de regras NAT.

Isto parece conveniente para iniciantes, mas na prática as regras NAT independentes são geralmente mais claras. Se uma regra NAT genérica já abrange o mesmo tráfego, você não deverá criar uma regra NAT vinculada adicional.

Para uma regra normal de cliente para Internet, a regra SNAT padrão com MASQ geralmente é suficiente, desde que esteja ativa e se ajuste corretamente à base de regras. Importante: o NAT não permite tráfego por si só. NAT traduz endereços ou portas. A regra de firewall apropriada ainda decide se o tráfego é permitido.

Mais sobre isso: Compreendendo o NAT em Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Filtragem da Web

Na área Filtragem da Web, são configurados a política da Web, a verificação de malware e o comportamento do filtro da Web.

Web policy

Web policy controla o acesso à web por meio de categorias, usuários, grupos, grupos de URLs e regras.

Exemplo prático: Uma política web é usada para clientes que bloqueia malware, phishing, conteúdo adulto e categorias de risco, mas permite aplicações empresariais.

Se nenhuma política da web for definida, a filtragem da web baseada em categorias não ocorrerá por meio desta opção.

Como planejar categorias, grupos de URLs, políticas da web e alertas instantâneos juntos é descrito em Sophos Firewall Usando categorias da web e alertas instantâneos.

Aplicar modelagem de tráfego baseada em categorias da web

Esta opção aplica modelagem de tráfego com base em categorias da web. Só faz sentido se forem usadas regras de modelagem de tráfego ou políticas de categoria da web apropriadas.

Exemplo prático: as categorias de streaming são limitadas, as aplicações empresariais continuam a ser preferidas.

Block QUIC protocol

QUIC usa UDP 80 e UDP 443. Muitos navegadores usam QUIC para serviços do Google e outros aplicativos da web modernos.

Se a filtragem da Web ou a verificação de malware para tráfego da Web for importante, Block QUIC protocol deverá ser deixado ativado em muitos ambientes. Os navegadores geralmente voltam ao HTTPS normal sobre TCP, que é mais fácil de controlar e verificar.

Mais sobre isso: Sophos Firewall Bloquear QUIC e HTTP/3 corretamente.

Scan HTTP and decrypted HTTPS

Esta opção verifica HTTP e HTTPS já descriptografado em busca de malware.

Importante: esta opção não descriptografa HTTPS automaticamente. Para que o HTTPS seja realmente verificado, são necessárias regras de inspeção SSL/TLS apropriadas em Rules and policies > Regras de inspeção SSL/TLS.

Exemplo prático: se TLS Inspection estiver ativo para LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS poderá verificar arquivos baixados no tráfego HTTPS descriptografado.

Mais sobre isso: Implementar TLS Inspection para Sophos Firewall gradualmente.

Use proteção de dia zero

Usar proteção de dia zero envia downloads suspeitos para o Sophos Zero-Day Protection para análise adicional. Isto é útil para regras de cliente e servidor que desejam verificar downloads da Internet.

A função requer uma licença adequada e pode causar atrasos dependendo do tipo de arquivo e da política.

Verificar FTP em busca de malware

Esta opção verifica o tráfego FTP em busca de malware. Só é relevante se o FTP for realmente usado e o Services correspondente geralmente for permitido.

O FTP tornou-se menos comum em ambientes modernos, mas ainda ocorre em sistemas legados, controles de máquinas ou mecanismos de atualização mais antigos.

Use proxy da web em vez de DPI engine

Sophos Firewall pode verificar o tráfego da web via DPI engine ou via Web Proxy.

Para configurações modernas, DPI geralmente é a melhor escolha padrão porque pode lidar com tráfego HTTP e SSL/TLS em todas as portas. O proxy da web ainda é útil se forem necessárias funções especiais de proxy, por exemplo, aplicação do SafeSearch, restrições do YouTube, restrições de domínio de aplicativos do Google, proteção pharming, cache da web ou proxy pai.

Se Usar proxy da web em vez de DPI engine não estiver ativado, a regra funcionará no modo DPI.

Descriptografar HTTPS durante a filtragem de proxy da web

Esta opção pertence ao modo proxy da web. Só é relevante se Use web proxy em vez de DPI engine estiver ativado e o HTTPS for descriptografado no modo proxy.

No modo DPI, a descriptografia HTTPS não é controlada aqui, mas sim por meio de regras de inspeção SSL/TLS.

Synchronized Security Batimento cardíaco

Com Configurar Synchronized Security Heartbeat o status Sophos Endpoint pode ser incluído na regra de firewall.

Opções típicas:

  • Defina o status mínimo para dispositivos de origem
  • Bloquear clientes sem batimentos cardíacos
  • Defina o status mínimo para dispositivos de destino
  • Bloquear solicitações para destinos sem pulsação

Isso é forte, mas só faz sentido se Sophos Endpoint, Sophos Central e Security Heartbeat estiverem configurados corretamente.

Exemplo prático: Clientes com Security Heartbeat vermelho não têm mais permissão para acessar servidores ou não têm mais acesso à Internet.

Para uma primeira regra de cliente, você não deve ativar a pulsação cegamente; caso contrário, poderá bloquear dispositivos que não conseguem enviar uma pulsação.

Outros recursos de segurança

Identificar e controlar aplicativos (controle de aplicativos)

Uma política de filtro de aplicativos é selecionada por meio de Identificar e controlar aplicativos (controle de aplicativos).

Isto permite que aplicações sejam reconhecidas e controladas, por exemplo:

  • Visualizador de equipe
  • Portão
  • Mensageiros
  • Transmissão
  • Armazenamento em nuvem
  • Ferramentas de controle remoto

Application Control requer uma licença adequada. Na prática, esse recurso está incluído nos pacotes Sophos Firewall com Web Protection, por exemplo Standard Protection, Xstream Protection ou Epic Protection.

TLS Inspection costuma ser crucial para detecção de aplicativos em tráfego criptografado. Sem descriptografia, dependendo do serviço, o firewall vê apenas nomes de host, SNI, informações de certificados ou IPs e não o conteúdo completo.

O processo personalizado para filtros, vinculação de regras, registros e verificação de falsos positivos está disponível em Sophos Firewall Configuração e teste de Application Control.

Apply application-based traffic shaping policy

Esta opção aplica a modelagem de tráfego definida na Política de Aplicativo ou no Objeto de Aplicativo.

Exemplo prático: o Microsoft Teams deve ser reconhecido e priorizado com uma política específica de modelagem de tráfego. Em seguida, a política Application Control apropriada deve ser selecionada e a política de modelagem de tráfego baseada em aplicativo deve ser aplicada.

Se você já definiu uma política de modelagem de tráfego explícita no campo Forma tráfego, deverá ser claramente documentado qual política deve ter precedência e por quê.

Detecte e evite explorações (IPS)

Uma política IPS é selecionada em Detectar e prevenir explorações (IPS).

O IPS verifica o tráfego em busca de padrões de ataque e explorações conhecidos. Uma política diferente é usada para o tráfego de clientes para a Internet e para o tráfego de servidores ou serviços publicados.

Exemplos práticos:

  • Regra do cliente LAN_to_WAN: Cliente ou LAN para política IPS WAN
  • Regra DNAT para servidor web: servidor ou política IPS de servidor web
  • Regra VoIP: teste com cuidado porque perfis IPS agressivos podem atrapalhar o VoIP

O IPS não deveria ser ativado apenas em todos os lugares com as políticas mais severas. Uma política IPS muito ampla ou incorreta pode interromper o tráfego legítimo ou criar carga desnecessária.

O artigo dedicado Sophos Firewall Configure o IPS e teste-o com segurança explica a ativação global, o status da licença, a seleção de políticas, o registro em log e a análise de falsos positivos com mais detalhes.

Moldar o tráfego

Com Shape Traffic, uma política de modelagem de tráfego pode ser aplicada diretamente à regra. Isto é relevante para:

  • VoIP
  • Reuniões on-line
  • Tráfego de backup
  • Convidado WLAN
  • rotas WAN lentas

Exemplo prático: o convidado WLAN obtém uma política de limite para não atrapalhar o tráfego comercial.

Mais sobre isso: Configurar Application Traffic Shaping em Sophos Firewall.

DSCP marking

DSCP marking marca pacotes para qualidade de serviço em dispositivos de rede downstream.

Isso só faz sentido se switches, roteadores ou dispositivos WAN também avaliarem esses valores DSCP. O Sophos Firewall pode marcar, mas o restante da rede deve tratar essas marcas de forma consistente.

Exemplo prático: O tráfego VoIP recebe uma marcação DSCP para que os switches e roteadores WAN tratem esse tráfego preferencialmente.

Digitalize com NDR Inteligência ativa contra ameaças

Verificar com NDR A inteligência ativa contra ameaças usa a inteligência contra ameaças Sophos NDR para avaliar adicionalmente o tráfego de rede.

Esta opção só será ú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 básica, mas pode ser uma adição valiosa em redes mais monitoradas.

Digitalize o conteúdo do e-mail

A área Verificar conteúdo de e-mail refere-se a protocolos de e-mail.

Opções possíveis:

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

Se você ativar protocolos lá, as portas padrão apropriadas também deverão ser incluídas no Services da regra ou adicionadas por meio de Adicionar portas.

Esta área geralmente não é relevante para regras normais do cliente web. Você deve planejá-lo conscientemente para servidores de e-mail ou tráfego de e-mail de clientes.

Exemplo prático: Um servidor de correio interno pode enviar SMTP externamente. Uma regra de servidor separada é então criada, o registro em log é ativado e a verificação de e-mail é verificada para corresponder à arquitetura de e-mail.

Verifique depois de salvar

Após salvar, você deve testar a regra e não apenas assumir que tudo funciona corretamente.

Para verificar:

  1. A regra está na posição correta?
  2. O Log de tráfego do firewall está ativo?
  3. Quando as regras mudaram, o contador de visitas foi reiniciado ou um novo teste claro foi criado?
  4. A regra corresponde no Visualizador de registros?
  5. O firewall esperado Rule ID aparece?
  6. A regra NAT desejada se aplica?
  7. O DNS funciona?
  8. Os filtros web, IPS, Application Control e TLS Inspection são aplicados conforme o esperado?
  9. Há alguma queda inesperada ou erro de SSL/TLS?

O artigo Testando a regra de firewall com Log Viewer, Policy Test e Packet Capture ajuda para uma verificação limpa.

Ao fazer mudanças produtivas, uma pequena comparação entre antes e depois faz sentido:

  • Existe um ponto de backup ou restauração: O desmantelamento continua possível se a regra produzir efeitos colaterais.
  • Trilha de auditoria ou ticket de alteração anotado: mais tarde ficará claro quem fez a mudança e quando.
  • Caso de teste definido previamente: O sucesso não é julgado apenas pelo sentimento.
  • Apenas uma alteração por teste: Causa e efeito permanecem compreensíveis.
  • Log Viewer ou registros centrais verificados: os reais Rule ID e NAT ID são visíveis.
  • Decisão de desmantelamento documentada: regras de teste temporárias não permanecem permanentemente ativas.

Se você tiver vários firewalls ou grupos gerenciados centralmente, verifique também se a alteração atingiu o dispositivo ou grupo correto. Para Sophos Central, a Fila de tarefas de gerenciamento de firewall ajuda; alterações locais podem ser rastreadas com Registros de trilha de auditoria.

Operação regular e revisão

Uma regra de firewall não está pronta apenas porque foi salva. Boas regras têm um propósito claro, são registradas, podem ser testadas e podem ser verificadas novamente mais tarde. Especialmente em ambientes maduros, muitos riscos surgem não de uma única regra incorreta, mas de antigas exceções, regras que são muito amplas ou regras sem dono.

Uma rotina simples vale a pena para revisões regulares:

  • A regra ainda será feita?: As regras não utilizadas muitas vezes podem ser desativadas e removidas posteriormente.
  • A fonte ainda está correta?: Redes de clientes, redes de servidores e áreas VPN mudam com o tempo.
  • Any ainda se justifica?: Fontes amplas, objetivos ou Services devem ser deliberadamente documentados.
  • O registro está ativo e útil?: Sem registros, as análises e auditorias subsequentes são significativamente mais fracas.
  • NAT, filtro web, IPS e TLS Inspection ainda cabem?: Os recursos de segurança podem funcionar de maneira diferente após atualizações, alterações de aplicativos ou alterações de certificados.
  • Existe uma data de validade?: Caso contrário, as regras temporárias de projeto ou apoio permanecem permanentemente ativas.

Para regras críticas, você também deve documentar quem é o responsável técnico. Isto é particularmente importante para serviços publicados, regras VPN, acesso de gerenciamento, compartilhamentos e regras do provedor de serviços com Any em Services ou destino.

Nova regra, alterar ou desativar regra existente?

Nem toda nova solicitação precisa imediatamente de uma nova regra de firewall. Muitas regras semelhantes tornam a lista confusa, mas regras muito resumidas rapidamente se tornam muito amplas. Uma decisão simples ajuda antes de salvar algo no WebAdmin:

  • Mesma origem, mesmo destino, mesma finalidade, apenas um serviço adicional: Estender regra existente. A regra permanece tecnicamente coerente e mais fácil de testar.
  • Mesmas redes, mas requisitos de proteção diferentes, registros diferentes ou proprietários diferentes: Crie sua própria regra. Filtros Web, IPS, TLS Inspection, NDR ou registro podem ser verificados separadamente.
  • Prestador de serviços temporário ou acesso de suporte: Crie sua própria regra temporária. O proprietário, o ticket, a data de validade e a janela de teste permanecem claramente visíveis.
  • Servidores, convidados, VoIP, IoT ou gerenciamento são afetados: Verifique sua própria regra ou zona. Diferentes riscos não devem desaparecer em uma regra de Internet do cliente.
  • Uma regra não é clara ou é antiga: Primeiro desative e observe. A exclusão direta elimina a capacidade de verificar ocorrências, logs e dependências de maneira controlada.
  • Uma regra é certamente supérflua após uma revisão: Remover após backup e documentação. O conjunto de regras torna-se menor sem quebrar dependências que funcionam cegamente.

Para mudanças operacionais normais, este processo é robusto:1. Anote a finalidade, o proprietário, o ticket e o tráfego esperado. 2. Verifique as regras existentes para a mesma origem, destino, serviço e Rule group. 3. Decida se uma regra existente será estendida ou se sua própria regra será mais limpa. 4. Para mudanças produtivas, planeje backup, trilha de auditoria e caso de teste. 5. Após salvar Log Viewer, Rule ID, verifique a decisão NAT e os recursos de segurança afetados.

Se a decisão falhar principalmente devido à falta de documentação, as regras Sophos Firewall devem ser documentadas de forma significativa devem ser acompanhadas primeiro. Se não estiver claro se uma regra existente ainda é necessária, um teste controlado com Testar regra de firewall com Log Viewer, Policy Test e Packet Capture ajuda.

Organize os contadores de sucesso corretamente

Os contadores de visitas ajudam na limpeza, mas não são uma prova completa. Uma regra de emergência raramente usada ainda pode ser importante. Por outro lado, uma regra ampla pode ter muitos acertos, embora permita muitos.

Para revisões, você deve sempre combinar contadores de ocorrências com Log Viewer, descrição da regra e caso de uso real. Se uma regra não for clara, ela não deverá ser excluída imediatamente. Um processo controlado é melhor: esclarecer a finalidade, ativar o log, definir janelas de teste, informar as partes interessadas e só então desativá-lo ou removê-lo.

Torne as alterações rastreáveis

Um backup deve estar disponível antes de mudanças importantes nas regras. O Audit Trail e o Config Studio ajudam a verificar as diferenças de maneira compreensível. O processo prático está em Sophos Firewall Verificar registros de trilha de auditoria e Sophos Firewall Usar o Config Studio.

Se muitas regras forem ajustadas, você não deve apenas comparar a configuração, mas também executar casos de teste reais. Uma regra pode ser sintaticamente correta e ainda permitir tráfego incorreto, usar o caminho NAT errado ou interromper um aplicativo por meio de IPS, filtragem da Web ou TLS Inspection.

Erros típicos

A regra está muito abaixo: Uma regra mais geral acima corresponde ao tráfego primeiro.

A fonte é muito ampla: Any funciona, mas torna as regras pouco claras e aumenta a superfície de ataque.

O destino é muito amplo: Servidores ou redes de gerenciamento raramente devem ter permissão para acessar a Internet com Any.

Services são muito largos: Any permite significativamente mais do que o necessário. Services específicos ou grupos de serviço são melhores.

O registro não está ativo: As informações mais importantes estão faltando no Log Viewer.

IPv6 foi esquecido: O IPv4 é devidamente regulamentado, mas o IPv6 segue outras regras ou permanece aberto inconscientemente.

Rule group certamente está confuso: Um grupo de regras apenas melhora a visão geral. Um grupo de regras não é seu próprio limite de segurança e não altera a lógica de avaliação.

HTTPS não é verificado: Scan HTTP and decrypted HTTPS está ativo, mas não há regra de inspeção ou descriptografia SSL/TLS apropriada.

O filtro da Web não funciona: Nenhuma política da Web definida, usuário errado, zona de origem errada ou QUIC não bloqueado.

A correspondência de usuários não funciona: Autenticação, SSO AD, portal cativo ou mapeamento de usuários não funcionam corretamente.

NAT ausente: A regra de firewall permite tráfego, mas SNAT/MASQ não cabe.

O recurso de segurança não corresponde ao tráfego: Uma política IPS, opção de proxy ou opção de verificação de e-mail incorretas podem interromper o tráfego legítimo. Se após esses pontos ainda não estiver claro por que o tráfego está sendo executado de maneira diferente do esperado, você deverá realizar testes estruturados adicionais com Log Viewer, testador de política e Packet Capture. O procedimento apropriado está em Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.

Perguntas frequentes

Em que ordem o Sophos Firewall verifica as regras do firewall?

Sophos Firewall verifica as regras de cima para baixo. A primeira regra correspondente vence. Portanto, regras específicas, regras de bloqueio e casos especiais devem vir antes das regras gerais.

Você deve usar Any nas regras de firewall do Sophos?

Any pode ser útil para testes ou regras muito gerais da Internet, mas deve ser deliberadamente justificado. Para servidores, gerenciamento, VPN, acesso de provedores de serviços e redes críticas, fontes concretas, alvos e Services são significativamente melhores.

Você precisa de suas próprias regras de firewall Sophos para IPv6?

Sim. As regras IPv4 e IPv6 são tratadas separadamente. Em ambientes dual-stack, o IPv6 deve ser deliberadamente permitido, bloqueado ou introduzido de forma controlada. Caso contrário, uma base de regras IPv4 devidamente reforçada pode ser contornada pelo tráfego IPv6 ignorado.

Por que não consigo ver uma conexão permitida no visualizador de log?

Muitas vezes, Tráfego de firewall de log geralmente não está ativo ou o tipo de log apropriado não está ativado para logs locais, Sophos Central ou Syslog em System services > Log settings. Além disso, algumas sessões só aparecem como entrada de log quando a conexão termina.

Uma regra de firewall substitui uma regra NAT?

Não. A regra do firewall decide se o tráfego é permitido ou bloqueado. NAT traduz endereços ou portas. Para acesso à Internet, DNAT e VPN, a regra de firewall e a regra NAT devem corresponder.

As regras de firewall também controlam WebAdmin, SSH ou VPN Portal?

Não é como o normal no trânsito. O acesso aos serviços de firewall locais é controlado principalmente por Device Access e Local Service ACL. As regras normais de firewall são responsáveis ​​pelo tráfego através do firewall.

Como você testa de forma limpa uma regra do Sophos Firewall?

Primeiro defina um caso de teste concreto: origem, destino, serviço, regra esperada e decisão NAT esperada. Em seguida, use Log Viewer, testador de política e, se necessário, Packet Capture. Para casos complexos, você deve redefinir os contadores de ocorrências ou usar uma janela de teste limpa.

As regras de firewall pouco claras devem ser excluídas imediatamente?

Não. Regras produtivas pouco claras devem primeiro ser documentadas, registradas e desativadas de maneira controlada. Somente quando a finalidade, o proprietário, os acessos e os registros forem verificados é que a remoção faz sentido.