Sophos Firewall: Bloquear países e IPs maliciosos

Assim que os serviços estão acessíveis pela internet, geralmente observa-se rapidamente tráfego indesejado: varreduras de portas, tentativas de login, redes de bots conhecidas ou acessos de países de onde não se espera usuários. No Sophos Firewall, é possível bloquear essas fontes em vários níveis.

Este artigo explica duas variantes típicas:

• Bloquear países ou redes de origem com uma regra de firewall
• Traduzir fontes indesejadas para o vazio com uma regra Black Hole DNAT

Além disso, recomendamos Sophos Firewall Threat Feeds, para que IPs, domínios ou URLs maliciosos conhecidos possam ser bloqueados automaticamente.

Orientação

Antes de bloquear fontes, deve ficar claro que tráfego está em causa: serviços publicados, serviços locais da firewall, tráfego de clientes de saída ou tráfego WAF. O método adequado depende exatamente disso.

Qual método usar e quando?

• Regra de Firewall com Drop: Bloqueia tráfego com base em Source Country, Source Network ou Source Host. Serve para bloqueios de países, redes individuais ou listas de IPs maliciosos mantidas manualmente.
• Black Hole DNAT: Redireciona tráfego indesejado para um IP interno inexistente. É útil quando o tráfego para serviços publicados deve ser interceptado cedo.
• WAF Blocked countries: Aplica-se a servidores web publicados via WAF. Os países são bloqueados diretamente na regra WAF.
• Local service ACL exception rule: Controla serviços locais da firewall, como WebAdmin, User Portal, VPN Portal ou SSH. Este é o ponto correto quando a própria firewall deve ser protegida.
• Threat Feeds: Usam listas dinâmicas de fontes maliciosas conhecidas. Servem para botnets, scanners, infraestrutura de malware e endereços IP de atacantes conhecidos.

A escolha do método depende de onde o tráfego é processado tecnicamente. Regras de firewall nem sempre se aplicam ao tráfego que vai para um endereço hospedado usado no WAF. Nesses casos, uma regra de país do WAF ou uma regra Black Hole DNAT pode ser mais adequada.

Entrada, saída ou firewall local

Antes de uma regra de bloqueio, deve-se esclarecer qual tipo de tráfego está em questão. Caso contrário, pode-se bloquear no lugar errado e depois se perguntar por que o ataque ainda é visível ou por que o tráfego legítimo falha.

• Entrada para servidor publicado: Redirecionamento de porta para RDP, HTTPS, SMTP ou aplicação própria. Ordem DNAT, regra WAF, regra de firewall, IPS e logging
• Entrada para a própria firewall: WebAdmin, User Portal, VPN Portal, SSH, Ping ou DNS na firewall. Device Access e Local Service ACL Exception Rules
• Saída de clientes internos: Clientes acessam destinos suspeitos na internet. Regra de firewall, Threat Feeds, Web Protection, DNS Protection e logging
• Servidor web via WAF: Aplicação web pública protegida por Web Server Protection. Regra WAF, países bloqueados, autenticação, MFA e logs WAF

Essa separação é importante porque uma regra de país em Rules and policies > Firewall rules não protege automaticamente todas as superfícies de ataque da firewall. Para servidores publicados, geralmente a cadeia NAT e WAF é prioritária. Para portais de administração, é importante primeiro verificar se o serviço local da firewall é acessível a partir da zona. Para tráfego de clientes de saída, Threat Feeds, Web Protection e DNS Protection são frequentemente as ferramentas mais adequadas.

Não confundir com Device Access

Country Blocking e Black Hole DNAT protegem principalmente o tráfego processado por regras de firewall ou NAT. Serviços locais do Sophos Firewall são um caso diferente. Isso inclui, por exemplo, WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping e, em parte, também serviços de acesso remoto.

Para esses serviços locais, Administration > Device access é o mais relevante. Lá, decide-se de quais zonas um serviço é acessível em princípio. Se o acesso deve ser permitido apenas para endereços IP de administradores específicos, países ou fontes de suporte, Local service ACL exception rules são o ponto de controle correto. O procedimento está em Configurar corretamente o Device Access no Sophos Firewall.

⚠️ Uma regra de bloqueio de país não substitui uma configuração adequada de Device Access. Se WebAdmin, User Portal, VPN Portal ou SSH estiverem amplamente acessíveis, a própria firewall continua sendo uma superfície de ataque. Country Blocking pode reduzir o risco, mas não substitui o fortalecimento básico do acesso.

Para serviços locais especialmente sensíveis, WAN não deve ser ativado de forma ampla em Local service ACL. É melhor usar uma exception rule que permita apenas as fontes esperadas ou bloqueie países indesejados. Para WebAdmin, um IP fixo de administrador ou uma VPN de gestão costuma ser mais limpo do que um filtro de países, porque Geo-IP não é uma verificação real de identidade.

Planear regras de bloqueio

As regras de bloqueio devem ser planeadas para não interromper tráfego legítimo por engano.

Bloquear países com uma regra de firewall

Para bloqueio geral de países, pode-se criar uma regra de firewall com Drop.

Caminho do menu:

Rules and policies > Firewall rules

Campos recomendados:

• Rule name: Nome descritivo, por exemplo, BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Action: Drop
• Source zones: Any
• Source networks and devices: País, grupo de países, lista de IPs ou grupo de hosts
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any ou um serviço definido

Para o bloqueio de países, é importante que as zonas de origem e destino não sejam definidas de forma muito restritiva. Se apenas WAN for inserido como zona de origem, a regra pode não se aplicar a todos os caminhos de tráfego relevantes.

Países e grupos de países são usados como objetos em Hosts and services. Para vários países, uma Country host group é mais clara do que muitos países individuais diretamente em cada regra. Listas de IPs maliciosos pertencem a objetos IP host ou IP host group adequados. É preciso conhecer os limites: listas IP host não foram feitas para feeds dinâmicos arbitrariamente grandes. Para infraestrutura de atacantes que muda continuamente, Threat Feeds são mais fáceis de manter.

O bloqueio de países também deve ser entendido como um controle de melhor esforço. Dados de Geo-IP podem estar incorretos, usuários podem viajar, atacantes podem usar proxies ou sistemas comprometidos em países permitidos, e serviços em nuvem utilizam infraestrutura distribuída globalmente. Portanto, uma regra de país nunca deve ser a única medida de proteção.

Quando não bloquear de forma muito ampla

Uma regra de bloqueio é rapidamente criada, mas pode gerar efeitos colaterais difíceis de rastrear mais tarde. Deve-se ter especial cuidado quando aplicações produtivas dependem de plataformas externas, CDNs, provedores de pagamento, serviços em nuvem, provedores de monitoramento ou parceiros de suporte.

Antes de um bloqueio amplo de países ou IPs, deve-se esclarecer:

• Existem usuários, parceiros ou prestadores de serviços nos países afetados?
• Uma aplicação utiliza infraestrutura de nuvem ou CDN com endereços de origem variáveis?
• Atualizações, webhooks, monitoramento, backups ou acessos de suporte são acionados por serviços externos?
• Existe uma maneira de apenas registrar ou testar a regra por um tempo limitado primeiro?
• Está claro quem verifica falsos positivos e como uma exceção é liberada?

Para serviços de internet com autenticação real de usuários, regras de países são frequentemente apenas uma medida adicional. MFA, regras de firewall restritas, sistemas de destino atualizados, IPS, proteção WAF, logging e Threat Feeds permanecem mais importantes do que uma lista de bloqueio o mais longa possível.

Planejar Allowlist antes de Blocklist

Para serviços críticos, uma Allowlist é frequentemente mais limpa do que uma Blocklist cada vez mais longa. Se um serviço só precisa ser acessível por parceiros fixos, filiais, sistemas de monitoramento ou locais de administração, deve-se primeiro permitir essas fontes e bloquear o restante. Isso reduz o esforço de manutenção e evita que se tenha que bloquear reativamente cada novo IP de scanner individualmente.

Uma Allowlist é especialmente adequada para:

• Acessos de administração a serviços de gerenciamento publicados
• Interfaces B2B com endereços IP de parceiros conhecidos
• Monitoramento, backup, webhooks ou endpoints de API com sistemas de origem fixos
• Acessos de suporte temporários com ticket, data de expiração e revisão

Uma Blocklist é mais adequada quando um serviço precisa permanecer publicamente acessível, mas fontes suspeitas devem ser reduzidas. A regra deve ser operada com logging, data de revisão e exceções claras. Para servidores web publicados via WAF, Sophos Firewall WAF: Publicar servidores web com segurança é relevante, pois lá países, autenticação e proteção de servidores web são controlados mais próximos da aplicação publicada.

Tratar filtros de país WAF separadamente

Em Web Server Protection, a regra WAF tem campos próprios para Allowed client networks, Blocked client networks, Blocked countries e Block IP addresses of unknown country-origin. Estas configurações pertencem à aplicação web publicada e não são o mesmo que uma regra normal de firewall Drop.

Isso é prático porque o filtro de países fica ligado diretamente à publicação WAF. Ao mesmo tempo, é preciso cuidado: Block IP addresses of unknown country-origin pode excluir usuários legítimos se o endereço IP deles não puder ser atribuído claramente. Antes de ativar, deve-se verificar o próprio IP externo com a GeoIP2 Databases Demo. Esta opção só deve ser ativada quando o efeito tiver sido testado e for conhecido no processo de suporte.

Para regras WAF, filtros de países são apenas um componente. Autenticação, MFA, certificado, Web Server Protection, assinaturas IPS/WAF, logging e um servidor backend atualizado continuam mais importantes do que uma longa lista de países bloqueados.

Black Hole DNAT e Threat Feeds

Em serviços publicados, pode ser útil interceptar fontes indesejadas antes da regra DNAT produtiva. Para infraestrutura dinâmica de atacantes, Threat Feeds também ajudam.

Black Hole DNAT para fontes indesejadas

Uma regra Black Hole DNAT traduz o tráfego para um destino que não existe na rede. O tráfego, portanto, cai no vazio e não atinge o serviço real.

Isso é especialmente útil quando um serviço é publicado via DNAT e deseja-se interceptar certas fontes antes do redirecionamento de porta real.

Black Hole DNAT deve ser usado de forma direcionada. É especialmente adequado para tráfego para serviços publicados, onde uma regra DNAT normal está abaixo. Para tráfego de clientes de saída geral, serviços locais da firewall ou servidores web publicados via WAF, geralmente uma regra de firewall, Device Access ou uma configuração WAF é o melhor ponto de controle.

Na regra NAT, é importante não confundir a vista original do atacante com o destino fictício traduzido. A regra deve ficar em Rules and policies > NAT rules acima da regra DNAT de produção. Original source contém a lista de IPs bloqueados, o país ou o grupo de países. Original destination é o endereço WAN público ou o objeto de host WAN que o atacante está a contactar. Translated destination é o host fictício não encaminhado. Neste padrão, a tradução de origem e de serviço normalmente permanece em Original.

Depois de guardar, deve-se verificar no Log Viewer se a NAT Rule ID esperada é atingida. Se a regra DNAT normal continuar a corresponder, a regra Black Hole está demasiado abaixo, a source não corresponde, ou o serviço ou destination contactado não corresponde ao tráfego de teste.

A regra Black Hole DNAT continua precisando de uma regra de firewall adequada ou de um caminho de log para que o acerto permaneça rastreável. NAT apenas traduz, não é uma autorização de acesso independente. Se depois ninguém souber por que o host fictício existe ou qual fonte é interceptada, essa técnica rapidamente vira legado.

Exemplo:

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: Lista de IPs maliciosos, país ou grupo de países
• Original destination: IP WAN público ou objeto de host WAN
• Original service: Any ou o serviço publicado
• Translated source (SNAT): Original
• Translated destination (DNAT): Host fictício que não existe
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

O host fictício deve usar um endereço IP que não exista na própria rede e não seja roteado. É importante que essa regra esteja acima das regras DNAT reais. As regras NAT são processadas de cima para baixo. Se a regra DNAT normal corresponder primeiro, a regra Black Hole DNAT será aplicada tarde demais.

O host fictício não deve ser escolhido aleatoriamente. É sensato usar um endereço de uma rede interna, não utilizada, de documentação ou fictícia, que não seja roteada e não seja planejada para sistemas reais posteriormente. A regra deve descrever claramente por que esse host existe, para que não seja acidentalmente excluído ou usado em produção.

Por que a ordem é crucial

Nas regras NAT, a primeira regra correspondente vence. Uma regra Black Hole DNAT deve, portanto, estar muito acima, geralmente no topo da tabela de regras NAT.

Ordem de exemplo:

1. Black Hole DNAT para lista de IPs maliciosos e países bloqueados
2. Regras DNAT específicas para serviços publicados
3. Regras SNAT especiais
4. Regra MASQ geral para tráfego de saída

Nas regras de firewall, aplica-se o mesmo princípio: regras de bloqueio específicas estão acima das regras de permissão gerais. Caso contrário, pode acontecer que o tráfego já tenha sido permitido antes que a regra de drop seja verificada.

Não deixar a fonte desnecessariamente em Any

Para serviços publicados, deve-se restringir a fonte tanto quanto possível.

Fontes sensatas podem ser:

• Endereços IP públicos individuais
• Redes de parceiros ou filiais
• Países de onde se espera o acesso
• Hosts FQDN ou Grupos de Hosts DNS, se apropriado
• Grupos de Hosts mantidos com endereços IP de administradores permitidos

Any só é sensato se o serviço realmente precisar ser acessível mundialmente. Nesse caso, medidas de proteção adicionais devem ser ativadas: logging, IPS, MFA onde possível, autenticação forte, sistemas de destino atualizados e Threat Feeds.

IPv6 deve ser planejado separadamente. Uma regra de país IPv4 não prova que a mesma aplicação também esteja protegida via IPv6. Em ambientes dual-stack, são necessárias regras IPv6 adequadas, logging e um caminho de teste. Se IPv6 não for usado em produção, deve ser conscientemente desativado, bloqueado ou introduzido com documentação.

Usar Threat Feeds adicionalmente

Listas manuais e regras de países são estáticas. No entanto, a infraestrutura de atacantes muda constantemente. Por isso, recomendamos adicionalmente Sophos Firewall Threat Feeds.

Threat Feeds ajudam especialmente com:

• Endereços IP de scanners conhecidos
• Redes de bots
• Infraestrutura de malware
• Hosts comprometidos
• Listas de IPs maliciosos mantidas dinamicamente

Assim, não é necessário manter manualmente cada IP individual. A firewall pode bloquear fontes ruins conhecidas antes que elas alcancem o serviço publicado.

Testes e operação

Depois da alteração, deve-se verificar conscientemente contadores, logs e caminhos de acesso esperados.

Operação e revisão de listas de bloqueio

Listas de bloqueio só são úteis se permanecerem rastreáveis em operação. Uma regra de país ou lista de IPs maliciosos não deve simplesmente crescer indefinidamente sem que alguém verifique os acertos, exceções e efeitos colaterais.

Para cada lista de bloqueio manual, deve ser documentado:

• Por que a fonte foi bloqueada
• Se é um bloqueio temporário ou permanente
• Quem mantém a lista
• Quando a regra será revisada novamente
• Quais serviços ou regras DNAT são afetados
• Como um falso positivo é liberado

Especialmente em redes de nuvem, CDN, hospedagem ou suporte, deve-se ter cuidado. Um único endereço IP pode pertencer a outro cliente mais tarde, um intervalo de CDN pode conter serviços legítimos, e um prestador de serviços externo pode mudar seu IP de saída. Se um acesso legítimo for bloqueado, a regra inteira não deve ser desativada imediatamente. É melhor uma exceção restrita com motivo, ticket e data de revisão.

Para servidores publicados, deve-se verificar adicionalmente se a lista de bloqueio realmente se aplica antes da regra DNAT produtiva. A verificação operacional em Publicar servidor via DNAT no Sophos Firewall ajuda a avaliar serviços publicados, regras NAT e logging em conjunto. Se as fontes bloqueadas passarem por uma regra de firewall, Testar regra de firewall com Log Viewer, Policy Test e Packet Capture é o caminho de teste adequado.

Uma revisão sensata não consiste apenas em olhar para a regra. Deve-se verificar no Log Viewer se a regra ainda está sendo acionada, quais fontes são afetadas e se os acertos correspondem ao risco esperado. Para avaliação a longo prazo, Central Firewall Reporting ou Enviar Syslog do Sophos Firewall para SIEM são melhores do que logs locais sozinhos.

Procedimento de teste após a alteração

Após uma nova regra de bloqueio, não deve-se apenas verificar se o acesso indesejado desaparece. É importante também verificar se o tráfego desejado continua funcionando e se a firewall registra o acerto de forma rastreável.

Procedimento prático:

1. Criar regra com nome descritivo, logging e descrição detalhada.
2. Se possível, testar primeiro com uma pequena lista de fontes ou um único país.
3. Verificar o bloqueio esperado de uma fonte externa apropriada.
4. No Log Viewer, filtrar por Source, Destination, Service, Firewall Rule ID e NAT Rule ID.
5. Testar um acesso legítimo de uma fonte permitida.
6. Para servidores publicados, verificar se a regra DNAT produtiva ainda se aplica a fontes permitidas.
7. Documentar a data de revisão e o responsável pela regra.

Se não for possível um teste limpo de fora, a alteração deve ser monitorada pelo menos com Log Viewer, Packet Capture e uma janela de manutenção restrita. Uma regra de bloqueio sem acertos visíveis e sem responsável é difícil de distinguir de um legado após alguns meses.

Troubleshooting

Se o resultado esperado não aparecer, verifica-se passo a passo o logging, o rule matching e o comportamento das policies.

Erros típicos

• Black Hole DNAT está abaixo da regra DNAT normal: A regra DNAT normal corresponde primeiro, a regra de bloqueio não se aplica
• Destino fictício existe na rede: Tráfego cai inesperadamente em um sistema real
• Fonte é mantida de forma diferente na regra NAT e na regra de firewall: Regras tornam-se difíceis de rastrear e divergem
• Country Blocking é usado como única medida de proteção: Bots de países permitidos ainda podem atacar
• WAF e DNAT são misturados: Uma regra de firewall Drop não protege automaticamente cada publicação WAF. Verificar WAF Blocked countries separadamente.
• Serviços locais da firewall são protegidos com regras normais de firewall: Para WebAdmin, User Portal, VPN Portal e SSH, verificar primeiro Device Access e Local Service ACL.
• IPv6 é esquecido: Uma regra IPv4 não bloqueia um caminho IPv6.
• Bloqueios temporários de IP nunca são revisados: Entradas antigas bloqueiam acessos legítimos mais tarde ou criam complexidade desnecessária
• Intervalos de nuvem ou CDN são bloqueados de forma muito ampla: Aplicações de negócios, atualizações ou prestadores de serviços externos podem falhar
• Logging está desativado: No Log Viewer, não está claro qual regra foi aplicada

Resolução de problemas

Se uma regra de bloqueio não se aplicar, deve-se verificar nesta ordem:

1. A regra NAT ou de firewall está realmente acima das regras de permissão?
2. O IP de origem corresponde à lista de IPs maliciosos ou ao país escolhido?
3. O tráfego é processado por uma regra WAF, regra DNAT ou regra de firewall?
4. O logging está ativo na regra de firewall afetada?
5. O Log Viewer mostra a Firewall Rule ID ou NAT Rule ID esperada?
6. O tráfego é visível em Diagnostics > Packet capture?
7. Existe uma exceção mais recente, grupo de hosts ou exclusão de Threat Feed que influencia o bloqueio esperado?
8. Um bloqueio temporário após um incidente foi deixado permanentemente?

Para a análise, também ajudam Regra de firewall não se aplica: verificar ordem, correspondência e logs, Usar a ferramenta Packet Capture no WebAdmin e Entender NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Se o tráfego bloqueado realmente pertencer a um servidor publicado, a regra DNAT produtiva deve ser verificada adicionalmente: A regra Black Hole DNAT está realmente acima, o mesmo endereço de destino público é atingido e o serviço é idêntico ou escolhido de forma mais ampla de propósito? Para a publicação completa, Publicar servidor via DNAT no Sophos Firewall é adequado.

FAQ