Verificar Spoof Protection e DoS Settings na Sophos Firewall

Spoof Protection e DoS Settings estão entre as funções clássicas de endurecimento de um Sophos Firewall. Os recursos reduzem pacotes simples, barulhentos ou obviamente incorretos antes que se tornem ruídos desnecessários em logs, regras ou serviços publicados. Ao mesmo tempo, essas configurações não são uma proteção mágica contra todo tipo de ataque.

O artigo classifica as funções como proteção básica cuidadosa: primeiro entenda o design da rede e os caminhos de retorno, depois ative, teste e verifique os logs. A distinção é particularmente importante: essas funções complementam regras de firewall bem definidas, IPS, Threat Feeds, WAF e registro. Eles não substituem esses blocos de construção.

Explicado resumidamente

Spoof Protection verifica se pacotes com um endereço de origem plausível chegam na interface esperada. Por exemplo, se um pacote com um endereço de origem interno aparecer vindo da Internet, isso é suspeito na maioria dos designs. DoS Settings, por outro lado, responde a certos padrões de inundação ou ataque de conexão, por exemplo, quantidades perceptíveis de tráfego SYN, UDP ou ICMP.

No SFOS 22 e no SFOS 23, o caminho no WebAdmin é:

Intrusion prevention > DoS & spoof protection

As definições desta página afetam o processamento de pacotes. Antes de selecionar Apply ou Save, registe os valores atuais e defina como reverter a alteração.

O que as funções fazem

• Spoof Protection: descarta pacotes com um IP de origem implausível, reduz tentativas simples de spoofing e torna mais visíveis os pacotes encaminhados incorretamente. No entanto, a função não substitui um planeamento adequado das zonas, interfaces e encaminhamento.
• DoS Settings: limitam padrões simples de flooding e tornam mais cedo percetíveis os ataques de grande volume ou as configurações incorretas. No entanto, a função não substitui a proteção DDoS do fornecedor, uma WAF nem uma infraestrutura a montante devidamente dimensionada.

Na prática, essas funções são particularmente interessantes como proteção básica. O benefício é reduzir o absurdo óbvio. Em ataques DDoS volumétricos reais, a conexão com a Internet geralmente já está lotada antes que o firewall possa responder de forma significativa. Nesse caso, é necessária proteção do fornecedor, scrubbing upstream ou outra arquitetura.

Não misturar tipos de proteção

No mesmo ecrã existem vários mecanismos que, durante a operação, respondem a perguntas diferentes.

• Enable spoof prevention: ativa Spoof Prevention para zonas selecionadas. Zonas ou caminhos de retorno mal compreendidos podem afetar tráfego legítimo.
• Trusted MAC e pares IP-MAC: endereços MAC ou combinações IP-MAC conhecidos são tratados como confiáveis. Com dispositivos móveis, mudanças de DHCP ou virtualização, isto pode aumentar o trabalho de manutenção.
• DoS settings: definem limites e flags para SYN-, UDP-, TCP- ou ICMP/ICMPv6-flooding. Valores demasiado restritos perturbam picos de carga legítimos, scans, monitoring ou VoIP.
• DoS bypass rule: exclui determinado tráfego das DoS Settings no WebAdmin. Exceções amplas enfraquecem esta proteção. Para a interação com políticas CLI, consultar as ressalvas de versão na secção CLI.

Esta distinção é importante porque um erro após a ativação não é automaticamente um problema de uma regra de firewall. Por vezes, o limite DoS é demasiado agressivo, um binding IP-MAC deixou de corresponder ou Spoof Protection revela um problema real de routing ou VLAN.

Quando Spoof Protection faz sentido

Spoof Protection se adapta particularmente bem a redes claramente segmentadas nas quais redes de origem, interfaces e rotas são claramente planejadas. Quanto mais clara for a estrutura da rede, mais fácil será avaliar se um endereço de origem em uma interface é plausível.

Aplicações úteis:

• Internet WAN na qual nenhuma fonte RFC1918 interna deve aparecer.
• DMZ ou zonas de servidor com redes de origem e destino claras.
• Zonas de clientes, convidados ou IoT nas quais não devem surgir outras redes internas como origem.
• Locais onde o roteamento, VLANs e zonas estão claramente documentados.
• Ambientes em que os descartes de pacotes precisam de poder ser analisados posteriormente com Packet Capture e logs.

As coisas ficam mais difíceis com roteamento assimétrico, redes de trânsito complexas, caminhos de migração temporários, VLANs documentados incorretamente ou vários firewalls no mesmo caminho de dados. Um fluxo de dados legítimo pode parecer falsificação, embora o design de roteamento ou o caminho de retorno sejam, na verdade, impuros.

Verifique antes da ativação

Spoof Protection e DoS Settings não devem ser ativados cegamente em um ambiente de produção. Deve ficar claro de antemão quais redes e serviços são afetados.

Pontos de verificação importantes:

1. Documentar zonas, interfaces, VLANs, bridges e LAGs.
2. Verifique rotas estáticas, rotas SD-WAN, rotas VPN e caminhos assimétricos.
3. Identifique serviços publicados via DNAT ou WAF.
4. Observe serviços críticos como VoIP, monitoramento, backup, varreduras, VPN e conexões de site.
5. Prepare o registro e a avaliação central se os eventos precisarem ser rastreados posteriormente.
6. Define janela de manutenção ou área piloto para primeira ativação.
7. Verifique as DoS bypass rules, entradas Trusted MAC e bindings IP-MAC existentes.
8. Registe o tipo de inspeção spoof e as zonas selecionadas, Restrict unknown IP on trusted MAC, todas as flags Apply, Packet Rate, Burst Rate, exceções e bindings existentes. Estes valores serão necessários para reverter a alteração.

Se as regras normais do firewall forem difíceis de entender, a regra e o status do roteamento devem ser limpos primeiro. Para conexões de teste individuais, Testar regra de firewall com Log Viewer, Teste de política e Packet Capture é um começo melhor.

Ativar Spoof Protection com cuidado

Uma abordagem passo a passo faz sentido para Spoof Protection. Você deve proteger primeiro as áreas mais limpas, e não todas as zonas especiais imediatamente.

Processo prático:

1. Salve a configuração atual ou pelo menos documente as configurações afetadas.
2. Em Intrusion prevention > DoS & spoof protection, selecione Enable spoof prevention, o tipo de inspeção necessário e, inicialmente, apenas zonas bem documentadas.
3. Selecione Apply.
4. Execute conexões de teste planejadas: acesso à Internet, VPN, serviços publicados, servidores centrais, monitoramento.
5. Verificar no Log Viewer e no Packet Capture se existem pacotes descartados inesperadamente.
6. Não contornar de imediato descartes anómalos de tráfego legítimo com exceções abrangentes; verificar primeiro o encaminhamento, a Source-IP e a Interface.

Um erro frequente é tratar Spoof Protection como uma mera caixa de verificação de segurança. Na realidade, a função verifica um pressuposto sobre a conceção da rede. Se esse pressuposto não estiver correto, isso não significa necessariamente que Spoof Protection esteja errada. Muitas vezes, uma interface, uma rota, uma VLAN ou um caminho de retorno não estão configurados como se esperava.

Compreender corretamente IP, MAC e pares IP-MAC

A Sophos distingue vários tipos de verificação. IP spoofing descarta tráfego quando o IP de origem não corresponde à tabela de encaminhamento ou o pacote não provém de uma sub-rede diretamente ligada. MAC filter descarta pacotes cujo endereço MAC não está registado como Trusted MAC; para isso, é necessário ter pelo menos uma Trusted MAC Address configurada. O filtro MAC não é aplicado a pacotes DHCP. IP-MAC pair filter verifica se a combinação de endereço IP e endereço MAC recebida corresponde a um par conhecido.

Isto é útil em redes estáticas e claramente controladas, mas em ambientes dinâmicos pode criar rapidamente esforço de manutenção. DHCP, roaming Wi-Fi, máquinas virtuais, hypervisors, clusters, NAC, docking stations ou substituição de dispositivos podem criar alterações MAC/IP legítimas. Nessas redes, convém observar primeiro e criar bindings apenas onde a realidade operacional seja suficientemente estável.

Exemplo com um Core Switch: o switch assegura o encaminhamento inter-VLAN e utiliza a Sophos Firewall como Default Gateway. Um cliente na VLAN 1 com 10.10.10.5 envia um pedido à Internet que chega à interface LAN da firewall. O facto de o switch conhecer as VLANs não torna as respetivas sub-redes diretamente ligadas à firewall. Antes da ativação, verificar na firewall a rota para 10.10.10.5 e as sub-redes diretamente ligadas. Se as condições de IP-Spoofing documentadas não forem cumpridas, o pedido pode ser descartado apesar de o endereço do cliente ser legítimo. Um teste de acesso à WAN, por si só, não substitui esta verificação do caminho interno.

Para saber como verificar a tabela local de vizinhos e criar deliberadamente uma associação estática entre IP, MAC e interface, consultar Verificar a cache de vizinhos ARP e NDP.

É importante distinguir os casos: se não estiver configurada nenhuma Trusted MAC, o IP-MAC pair filter ativo permite todo o tráfego nesta verificação. Uma lista Trusted MAC vazia não equivale a um pacote que não corresponde a um binding IP-MAC configurado. Com entradas presentes, a filtragem depende dos bindings e de Restrict unknown IP on trusted MAC; a ausência de um par correspondente não implica sempre um bloqueio independentemente desta opção. A proteção exige bindings mantidos e testados.

A opção Restrict unknown IP on trusted MAC é particularmente restritiva: com IP-MAC pair filter ativado nas zonas selecionadas, a Sophos descreve, para esta opção selecionada, o descarte de pacotes provenientes de uma Trusted MAC sem associação a um IP, quando o IP é desconhecido. «Desconhecido» significa aqui: sem entrada correspondente na tabela de encaminhamento ou sem origem numa sub-rede diretamente ligada. Isto representa um ganho de segurança em redes controladas, mas pode constituir um obstáculo com DHCP, migrações e alterações temporárias de IP.

Para a opção não selecionada, a ajuda geral do SFOS 22 e do SFOS 23 descreve que são permitidas uma Trusted MAC com qualquer IP e uma Trusted MAC sem associação a um IP. Em contrapartida, as instruções separadas de Add afirmam, de forma genérica, que, quando existe uma associação, apenas é aceite um par IP-MAC correspondente. Estas afirmações não devem ser combinadas numa garantia de bloqueio incondicional. Verificar em conjunto o tipo de verificação, a zona, a associação e a caixa de verificação, e testar, na build instalada, os casos permitidos necessários e os casos divergentes; se o efeito não for claro, esclarecer com o Sophos Support antes da utilização em produção.

Uma entrada Trusted MAC individual é criada em Intrusion prevention > DoS & spoof protection, na secção Spoof protection trusted MAC, através de Add. Depois de introduzir o endereço MAC, seleciona-se Static e indicam-se um ou mais endereços IPv4 ou IPv6 separados por vírgulas, ou seleciona-se DHCP para associar automaticamente os endereços atribuídos. Após Save, deve testar-se um caso IP-MAC correspondente e outro deliberadamente diferente; uma entrada visível, por si só, ainda não confirma que o filtro esteja a ser aplicado.

O SFOS 23 documenta opções de pesquisa e filtragem na lista Trusted MAC para encontrar uma entrada a manter. Esta vista da lista não altera a filtragem de pacotes nem implica que o SFOS 22 não disponha destes controlos.

Importar Trusted MACs de forma controlada

É possível importar várias Trusted MACs em Intrusion prevention > DoS & spoof protection através de um ficheiro .csv ou .txt. Na secção Spoof protection trusted MAC, selecionar Import, escolher o ficheiro com Browse e carregá-lo com Upload file. O endereço MAC e IP Association têm de ser indicados em cada linha. A primeira linha tem de conter exatamente MAC Address,IP Association,IP Address. Os valores permitidos para IP Association são Static, DHCP, DHCPv6 e None. Com Static, podem ser indicados, por MAC, no máximo 16 endereços IP separados por vírgulas; nas outras três associações, o campo IP fica vazio.

O exemplo de formato seguinte mostra associações estáticas IPv4 e IPv6, bem como as três associações sem campo IP:

MAC Address,IP Association,IP Address
02:00:00:00:00:01,Static,192.0.2.10,192.0.2.11
02:00:00:00:00:02,Static,2001:db8::10,2001:db8::11
02:00:00:00:00:03,DHCP
02:00:00:00:00:04,DHCPv6
02:00:00:00:00:05,None

Os endereços MAC e IP são valores fictícios de exemplo, não dispositivos a autorizar. Substituir cada linha pelo MAC real do dispositivo e pela associação escolhida deliberadamente. Static é adequado para endereços fixos conhecidos; DHCP e DHCPv6, respetivamente, para a associação automática através da concessão DHCP; None não contém uma associação a um IP e, por isso, não substitui a verificação de pares estáticos.

Durante a importação, a firewall descarta toda a entrada se esta contiver um endereço MAC inválido, uma IP Association inválida ou um endereço IP inválido. É necessário distinguir este caso dos valores IP introduzidos apesar de DHCP, DHCPv6 ou None: esses valores IP são descartados; isto não implica automaticamente que toda a entrada MAC seja removida. Por isso, importar primeiro poucas linhas de teste-piloto, verificar depois as associações visíveis e testar um caso IP-MAC permitido e outro deliberadamente incorreto. Um carregamento bem-sucedido ainda não prova que a lógica de filtragem pretendida está a ser aplicada.

Planear DoS Settings

DoS Settings deve se adequar ao ambiente. Raramente faz sentido adotar valores de outro exemplo sem verificar. Um site com poucos usuários, VoIP e um pequeno WAN se comporta de maneira diferente de um data center, uma rede escolar ou um site com varreduras e monitoramento regulares.

Antes de adaptar, responda a estas perguntas:

• Quais serviços públicos estão expostos?
• Existem picos de carga, varreduras, monitoramento ou verificações de integridade legítimos?
• VoIP, VPN, WAF, DNAT ou transferências de arquivos grandes são usadas?
• Para que protocolos deve ativar a flag Apply, para que a firewall descarte e registe efetivamente as ultrapassagens do limite?
• Quem verifica os logs após a ativação?

DoS Settings pode ajudar a limitar padrões simples de inundação. No entanto, limites demasiado rigorosos também podem afetar o tráfego legítimo. Deve-se ter cuidado especial com VoIP, sistemas de monitoramento, tarefas de backup, verificações de vulnerabilidades e serviços publicados muito utilizados.

Os tipos de flood dizem respeito a cargas diferentes: SYN flood gera muitas ligações TCP semiabertas; o servidor responde com SYN-ACK, mas não recebe uma resposta final. TCP flood refere-se, em geral, a uma taxa elevada de pacotes TCP. UDP flood pode sobrecarregar o host de destino com verificações de portas e respostas ICMP relativas a portas não utilizadas. ICMP/ICMPv6 flood envolve muitos Echo Requests e pode consumir largura de banda. Num DDoS, a carga provém de vários dispositivos de forma distribuída; por isso, um limite individual por Source não responde à mesma questão que um limite por Destination.

No formulário, são também relevantes as seguintes flags:

• Dropped source routed packets: descarta pacotes cuja rota é definida pelo remetente. Desta forma, limita-se esta possibilidade de manipulação do encaminhamento.
• Disable ICMP/ICMPv6 redirect packet: não aceita redirecionamentos ICMP ou ICMPv6, respetivamente. Os routers a jusante também podem enviar legitimamente estas mensagens para indicar uma rota melhor ou ativa; por isso, a opção altera um pressuposto de encaminhamento, e não apenas a deteção de ataques.
• ARP hardening: permite ARP Replies apenas quando o IP de origem e o IP de destino se encontram na mesma sub-rede. A Sophos descreve esta função como proteção contra ARP Flood e ARP Poisoning.

Estas opções constituem medidas de reforço de segurança de base úteis, pois podem reduzir manipulações do comportamento de encaminhamento ou de ARP. Ainda assim, devem ser testadas após a ativação, sobretudo em redes com routers a jusante, segmentos mais antigos ou arquiteturas de Layer-2 invulgares.

Para os limites no WebAdmin, dois conceitos são importantes:

• Packet rate: número de pacotes que um host pode enviar ou receber por minuto antes de o tráfego ser descartado.
• Burst rate: número de pacotes inicialmente permitidos sem verificação de Packet Rate. Depois disso, podem ser tolerados picos curtos ocasionais acima de Packet Rate, mas não excedências frequentes ou prolongadas.

A Apply flag decide se o limite configurado é realmente aplicado ao protocolo correspondente. Valores demasiado altos fazem pouco. Valores demasiado baixos bloqueiam picos legítimos. Por isso, os valores devem ser alinhados com o tráfego real, serviços publicados e janelas de manutenção conhecidas.

Para obter uma referência fiável, registe primeiro os picos normais e as cargas excecionais planeadas. Em seguida, escolha o valor de cada protocolo com base no pico legítimo medido e na capacidade do serviço protegido; a Sophos não fornece um valor universal de produção. Depois de cada alteração, execute um teste de carga definido e compare Traffic dropped. Este contador acumula desde o último reinício da firewall, pelo que também deve registar a hora do teste e o valor inicial.

Ler corretamente o estado DoS

Em Intrusion prevention > DoS attacks, o SFOS mostra em tempo real a Source ou Destination à qual está a ser aplicado um limite e quantos pacotes foram descartados. Clicar no tipo de ataque para abrir os detalhes; a ligação de estado em DoS & spoof protection também conduz a esta vista. Após uma deteção, a limitação aplica-se inicialmente durante dez segundos. Se o ataque tiver terminado nesse momento, a limitação é removida. Se continuar, a firewall reinicia este contador de forma contínua a cada dez segundos e mantém a limitação. Um novo ataque da mesma Source ou à mesma Destination reinicia novamente o contador e volta a ativar a limitação. Quando o ataque termina, os dados desaparecem após 30 segundos. Por isso, um estado vazio não prova que não tenha ocorrido anteriormente um evento DoS; para uma análise retrospetiva, são necessários os eventos registados.

Os limites do WebAdmin aplicam-se por Source ou Destination, não como um total global de todos os hosts. Um exemplo meramente explicativo com Burst rate 100: os primeiros 100 pacotes são inicialmente permitidos sem verificação da Packet rate; depois, a taxa é comparada. Abaixo da taxa configurada, o tráfego é aceite; acima dela, pode ser descartado. 100 não é um valor recomendado para produção.

Não equiparar a sequência do exemplo ao temporizador de estado: a ajuda geral do SFOS 22 e do SFOS 23 designa esta sequência como uma tentativa de ARP-Flood e descreve mais descartes de pacotes e registos quando o pacote seguinte da mesma Source chega no prazo de 30 segundos. Descreve a permissão do tráfego quando tiver decorrido mais tempo desde o pacote anterior, mas exclui expressamente a inclusão automática na Allow List apenas por terem passado 30 segundos sem tráfego. Em contrapartida, a ajuda separada sobre o estado DoS descreve a limitação contínua de dez segundos explicada acima. Estes não são tempos universais fiáveis de permissão ou espera para todos os tipos de flood. Não concluir que o tráfego é permitido apenas com base num temporizador: avaliar em conjunto o tipo de ataque, o estado em tempo real, os registos e um fluxo de teste legítimo claramente delimitado; esclarecer comportamentos não compreendidos com o Sophos Support.

Utilizar assinaturas DDoS apenas em modelos suportados

A Sophos disponibiliza assinaturas DDoS apenas em XGS 5500 e firewalls de maior capacidade. Num modelo suportado, o procedimento é o seguinte:

1. Em Intrusion prevention > IPS policies > Add, criar uma política IPS própria com um nome inequívoco à escolha e guardá-la com Save.
2. Nessa política já guardada, selecionar Edit, depois Add e introduzir um nome inequívoco para a regra.
3. Selecionar Select all, introduzir ddos em Smart filter e premir Enter para aplicar. Definir deliberadamente Action como Drop packet.
4. Guardar primeiro a regra com Save e depois a política que a contém com o segundo Save.
5. Em Rules and policies > Firewall rules, atribuir a política à regra de firewall que realmente processa o tráfego pretendido; verificar separadamente a atribuição e a proteção efetiva, conforme o procedimento-piloto de IPS. Sem essa atribuição, a política não produz efeito.

Estas assinaturas complementam os limites DoS locais, mas não substituem a proteção DDoS do fornecedor. Se a ligação à internet já estiver saturada, a firewall não consegue resolver o estrangulamento antes da ligação WAN. Por isso, modelo, licença, correspondência da regra e teste controlado devem ser verificados separadamente.

Regras CLI com system dos-config

Através da Device Console, é possível criar políticas DoS próprias e as regras correspondentes. Isto é necessário, entre outros casos, para IP Flood, porque este tipo não pode ser configurado no WebAdmin. As unidades são diferentes: o WebAdmin utiliza pacotes por minuto, enquanto system dos-config utiliza pacotes por segundo (pps).

Após o login por SSH, selecionar 4. Device Console no menu principal. Os comandos devem ser executados no prompt console>, não na Advanced Shell.

Primeiro, cria-se a política com o tipo de ataque, o limite e o método de contagem. Depois, a regra define o tráfego ao qual se aplica. O exemplo SYN documentado prevê a política TestSYN e a regra TestRuleSYN para Source 198.51.100.50, com 1000 pps por Source.

Verificar a ajuda da versão de destino antes de criar objetos: a ajuda publicada para SFOS 22 e SFOS 23 usa rule_name para add dos-rule nos blocos de sintaxe e opções, mas rule-name nos exemplos. Não está confirmado que as duas formas sejam intercambiáveis. Consultar primeiro a ajuda de system dos-config na Device Console da versão instalada e verificar o token de adição aceite e os parâmetros. Se a dúvida persistir, não criar nenhuma regra e pedir esclarecimentos à Sophos Support. O comando completo de adição de regra é deliberadamente omitido como modelo para copiar e colar. Criar também a política seguinte apenas após esta verificação; por si só, ainda não associa o tráfego de exemplo. Este exemplo não é apresentado como testado com sucesso.

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src

1000 pps é um exemplo de sintaxe e não uma recomendação para uma rede de produção. Para uma regra própria, é necessário adaptar conscientemente pelo menos os seguintes elementos:

• SYN-Flood: em alternativa, UDP-Flood, ICMP-Flood ou IP-Flood, disponível apenas aqui
• per-src: limite por Source; em alternativa, per-dst por Destination ou global para todo o tráfego correspondente
• as condições efetivamente necessárias para Source, Destination, Zone, Interface e protocolo
• o limite com base numa baseline medida e na capacidade do serviço protegido

O modo de contagem global não se aplica aos contadores em Intrusion prevention > DoS attacks. Estes contadores da interface não demonstram, portanto, um limite CLI agregado globalmente. Verificar a configuração com show e avaliar a aplicação da proteção separadamente, com um fluxo de teste claramente definido e delimitado no tempo e os respetivos logs.

Os limites e campos de correspondência da CLI são definidos de forma mais precisa do que a regra curta de exemplo sugere:

system dos-config flush dos-rules remove todas as regras DoS da CLI e não é uma reversão para um único teste. Antes de uma ação global deste tipo, as regras existentes são registadas individualmente com show e a configuração é guardada. Para uma reversão normal, elimina-se de forma específica a regra indicada. A ajuda publicada descreve flush para as regras, não como eliminação das políticas associadas.

Após a criação, deve-se primeiro verificar se os nomes, o tipo, o limite e a condição da regra estão corretos:

system dos-config show dos-policies policy-name TestSYN
system dos-config show dos-rules rule-name TestRuleSYN

Para reverter, eliminar primeiro a regra e depois a política que já não é utilizada:

system dos-config delete dos-rule rule-name TestRuleSYN
system dos-config delete dos-policy policy-name TestSYN

A sintaxe CLI está documentada na Sophos Firewall Command Line Help. Mesmo assim, deve ser utilizada primeiro com um fluxo de teste controlado. As regras DoS de CLI suportam apenas IPv4. Com uma política IP-Flood ativa, a coluna Applied em Intrusion prevention > DoS attacks continua a mostrar No; a Sophos descreve este comportamento como esperado.

Esta limitação a IPv4 aplica-se às regras DoS da CLI, não às DoS settings nativas em Intrusion prevention > DoS & spoof protection no WebAdmin: as definições DoS aí disponíveis protegem tanto o tráfego IPv4 como o IPv6, desde que estejam configuradas as flags de protocolo e os limites adequados.

Para o SFOS 22, está documentada a avaliação das regras e políticas CLI antes das definições DoS e spoof do WebAdmin; com essa ordem, uma regra bypass do WebAdmin não anula automaticamente uma política CLI correspondente. A ajuda CLI do SFOS 23 analisada não especifica esta ordem entre níveis. Isto não demonstra uma mudança de comportamento: confirmar a interação para a versão instalada antes de depender dela. Dentro do WebAdmin, ambas as versões continuam a documentar primeiro as DoS bypass rules e depois as DoS Settings para o tráfego restante.

Usar DoS bypass rules apenas de forma restrita

As DoS bypass rules são úteis quando um fluxo de dados conhecido seria, de outro modo, repetidamente bloqueado por engano pelas DoS Settings do WebAdmin. Exemplos típicos são monitoring, Health Checks ou um serviço claramente definido entre endereços IP conhecidos. A exceção deve ser o mais precisa possível: origem específica, destino específico, protocolo adequado e intervalo de portas estreito.

Regras de bypass amplas com redes grandes, lógica any ou intervalos de portas genéricos são perigosas. Essas exceções tornam a verificação DoS cega exatamente onde pode ser necessária mais tarde. Se uma exceção ampla parecer necessária, deve-se primeiro verificar se os limites, a arquitetura ou o caso de teste foram avaliados incorretamente.

Para as definições do WebAdmin, a ordem é importante: a Sophos Firewall verifica primeiro se uma DoS bypass rule corresponde e só depois aplica as DoS Settings desse ecrã ao tráfego restante. Uma regra de bypass demasiado ampla pode, por isso, tornar esta proteção ineficaz. Nas regras de bypass, Source, Destination, protocolo, Source Port e Destination Port devem ser definidos conscientemente, em vez de utilizar * por conveniência.

Uma exceção é criada em Intrusion prevention > DoS & spoof protection, na secção DoS bypass rule, através de Add. O SFOS 22 e o SFOS 23 exigem IP version, IP de Source e de Destination, Protocol, Source Port e Destination Port; * representa qualquer endereço ou qualquer porta. Para um Health-Check HTTPS de 198.51.100.20 para 203.0.113.10, uma configuração adequada seria: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * e Destination Port 443. Ambos os endereços reservados para documentação têm de ser substituídos pelos endpoints reais. A Source Port permanece variável apenas porque os clientes utilizam habitualmente uma porta de origem dinâmica. Após Save, testar precisamente este fluxo e outro fluxo; apenas o Health-Check definido deve poder contornar a proteção DoS do WebAdmin.

Verificar a alteração e o failover em HA

Num cluster HA, o Primary sincroniza para o Auxiliary a configuração da firewall, incluindo regras, policies, settings e comandos CLI. Faça as alterações DoS e spoof no Primary atual. Em seguida, verifique o estado HA em System services > High availability e volte a confirmar as entradas WebAdmin e regras CLI. Em Active-active, o teste de carga deve incluir ambos os caminhos de processamento. Em Active-passive, inclua um failover controlado na janela de manutenção se o procedimento operacional o permitir. Não crie uma configuração divergente no Auxiliary.

Nota para o SFOS 22.0 MR2

As Release Notes do SFOS 22.0 MR2 Build 546 indicam a correção de NC-180226: anteriormente, o WebAdmin não mostrava erro ao adicionar um endereço MAC duplicado em Spoof protection trusted MAC. Em builds 22.0 anteriores, a ausência de erro não prova que a entrada seja única. Verifique a lista e o binding efetivo ou atualize para um build corrigido.

Automação XML: preservar identidade e campos-pai

Antes de automatizar estas definições, verificar a configuração guardada e a API help específica do objeto na build instalada. As correspondências seguintes explicam a referência SFOS 22/SFOS 23; não são modelos de pedidos testados. Utilizar a API XML em segurança explica operações de escrita explícitas, proteção do acesso e verificações separadas do transporte, da resposta XML e do objeto guardado.

Regra bypass: correspondência antiga e nova, não um nome

DoSBypassRules não tem uma identidade Name documentada. A correspondência inclui IPFamily (IPv4 ou IPv6), SourceIPNetmask, DestinationIPNetmask e Protocol (TCP, UDP, ICMP ou AllProtocol), acrescentando SourcePort e DestinationPort para TCP/UDP. As portas são valores individuais de 1 a 65535 ou *; a referência não comprova aqui um payload de intervalo de portas. Para adicionar/editar, a tabela indica * para ambos os endereços e TCP para o protocolo como valores predefinidos. Não adotar estes valores abrangentes como exceção pretendida; definir deliberadamente toda a correspondência.

Numa atualização, DoSBypassRules/OldConfiguration contém a combinação anterior dos mesmos campos; os filhos diretos de DoSBypassRules contêm a nova correspondência pretendida. OldConfiguration pertence à identidade de atualização, não à criação nem à eliminação. A referência Delete identifica os campos de correspondência, não um nome. Antes de eliminar, identificar a combinação efetivamente guardada. O exemplo Add/Edit assinala expressamente as portas como exclusivas de TCP/UDP, enquanto as listas de parâmetros, incluindo Delete, declaram ambas as portas obrigatórias sem condições. Isto não permite deduzir um payload de eliminação fiável e executável para ICMP/AllProtocol: esclarecer a ajuda específica do objeto e a build, sem enviar valores de porta inventados.

Trusted MAC: chave MAC e famílias de endereços separadas

Em TrustedMAC, a identidade é MACAddress; numa atualização, TrustedMAC/OldConfiguration/MACAddress conserva a chave antiga, enquanto TrustedMAC/MACAddress contém o endereço MAC pretendido. Delete indica apenas MACAddress, não Name nem OldConfiguration. Guardar a entrada concreta e as suas associações antes de Update ou Delete e voltar a verificar a lista depois.

TrustedMAC/IPV4Association e TrustedMAC/IPV6Association são associações independentes com Static, DHCP ou None; a tabela API indica Static como valor predefinido de ambas. Os campos de endereços CSV correspondentes chamam-se exatamente IPV4Address e IPV6Address. A importação de ficheiros também utiliza DHCPv6: não transferir esse valor para IPV6Association sem verificação. Para AssociateIP, o valor de exemplo e a descrição contradizem-se; não se deduz aqui nenhum valor de escrita permitido. As ressalvas anteriores sobre a filtragem IP-MAC efetiva continuam necessárias para entradas geridas por API.

A importação de ficheiros é uma operação separada Upload_TrustedMAC, com Upload_TrustedMAC/TrustedMACListFile para .csv ou .txt. O exemplo indica o nome do ficheiro transmitido por multipart, mas não comprova um nome concreto da parte multipart nem a sua associação a este campo XML. Não deduzir do exemplo um pedido de carregamento pronto a utilizar; esclarecer primeiro o contrato de carregamento específico da build e verificar depois as associações importadas.

Não achatar Spoof Prevention nem DoS Settings

O nome duplicado é intencional na estrutura de exemplo: SpoofPrevention é a raiz e SpoofPrevention/SpoofPrevention o interruptor. SpoofPrevention/RestrictUnknownIPOnTrustedMAC é um interruptor separado. Os três tipos de verificação têm listas de zonas distintas: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone e SpoofPrevention/IPMACFilter/EnableOnZone/Zone. O exemplo mostra Enable/Disable, a tabela de parâmetros indica antes on/off, e a nota de desativação é ambígua. Nem essas indicações nem listas de zonas omitidas ou vazias confirmam uma sintaxe de limpeza ou desativação. Esclarecer valores e reversão na build instalada antes de escrever.

Em DoSSettings, SYNFlood, UDPFlood, TCPFlood e ICMPFlood têm cada um os seus próprios elementos-pai Source e Destination. Em Source encontram-se PacketRatePerSource, BurstRatePerSource e ApplyFlag; em Destination, PacketRatePerDestination, BurstRatePerDestination e ApplyFlag. Por exemplo, DoSSettings/UDPFlood/Destination/ApplyFlag pertence apenas ao limite UDP de destino. A tabela permite taxas de pacotes de 1–600000 e taxas burst de 1–10000; o valor predefinido 1 e os números do exemplo não são uma baseline de produção. As flags adicionais estão em DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag e DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Não juntar os rótulos repetidos da tabela num PacketRate, BurstRate ou ApplyFlag global; preservar os valores guardados com o respetivo caminho-pai.

Ler códigos com a operação e o estado guardado

A referência enumera os seguintes códigos específicos de operação, não resultados HTTP universais:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. Não confundir, em particular, o 409 de Add com o 404 de Edit.
• Configure Spoof Prevention e Configuration DOS Settings: cada uma 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule e Delete Trusted MAC: apenas 200, 500 nestas páginas.
• Add Trusted MAC e Update Trusted MAC: cada uma 200 com Operation Successful. e 500 com Operation Fail..

Para as restantes operações citadas, as mensagens nas fontes completas continuam a ser símbolos JavaScript, não textos de resposta resolvidos:

Após cada alteração, comparar a resposta com as zonas, taxas, associações ou combinação bypass efetivamente guardadas. Perante erro ou resposta incerta, voltar a ler o estado atual antes de repetir; não recriar a entrada às cegas nem deduzir a eficácia do filtro apenas de 200. Verificar depois, separadamente, um fluxo de teste correspondente e outro não correspondente, como descrito acima.

O que essas configurações não resolvem

Spoof Protection e DoS Settings são blocos de construção importantes, mas não resolvem todos os problemas de segurança.

• O servidor está a ser atacado através de pedidos HTTP permitidos: Verificar a regra WAF e a Webserver Protection.
• Uma IP de origem reconhecidamente maliciosa está a atacar: Verificar os Threat Feeds ou o bloqueio por país/IP.
• Tentativa de exploração de uma vulnerabilidade num serviço: Ativar uma IPS-Policy adequada à regra.
• A ligação à Internet está saturada por um ataque DDoS: Envolver o fornecedor de serviços, recorrer a scrubbing ou a proteção DDoS a montante.
• A regra de firewall permite demasiado tráfego: Rever e corrigir o conjunto de regras, o NAT e o modelo de objetos.
• Não é possível explicar os descartes de pacotes: Melhorar o registo de eventos, o Packet Capture, o Syslog ou o Central Reporting.

O artigo Publicar servidor com DNAT em Sophos Firewall também é relevante para servidores acessíveis publicamente. É sobre NAT, regras de firewall e erros típicos de publicação.

Logs e verificação de acompanhamento

Após a ativação, você não deve apenas verificar se o acesso normal à Internet ainda funciona. O que é importante é se o firewall mostra claramente os eventos esperados e inesperados.

Verifique:

1. Filtrar o Log Viewer por eventos de Firewall e eventos de Security relevantes.
2. Gerar tráfego de teste com IP de Source, IP de Destination e Service claramente definidos.
3. Utilizar Packet Capture quando o motivo do descarte de pacotes não for claro.
4. Para armazenamento mais longo, planeje syslog para SIEM ou servidor de log.
5. Ao executar o Sophos Fusion (anteriormente Sophos Central), verifique se Central Firewall Reporting torna os eventos desejados visíveis.

Se um pacote for descartado, mas o motivo não estiver claro, a análise sistemática de descarte em Sophos Firewall descarta pacotes: verificar causas ajuda. Também descreve por que Log Viewer e Packet Capture respondem a perguntas diferentes.

O SFOS regista o tráfego descartado por estas proteções. Antes de um teste DoS, anote a hora, Source, Destination, Protocol e contadores. Durante o teste, Intrusion prevention > DoS attacks mostra em tempo real Source ou Destination e os dados descartados. Como o estado desaparece 30 segundos após o fim do ataque e Traffic dropped acumula desde o último reinício, só uma comparação delimitada antes/depois é significativa. O modo CLI global não se aplica a estes contadores da interface; nem esta comparação valida a agregação global. Para uma política CLI global, separar a verificação da configuração com show da avaliação do fluxo de teste definido e dos respetivos descartes/logs. O Packet Capture mostra ainda a interface de entrada e os endereços do pacote, mas isoladamente não prova qual mecanismo descartou o fluxo.

Resolução de problemas após a ativação

Depois de uma alteração, os sintomas não devem ser interpretados demasiado cedo como ataque. A análise mais rápida costuma comparar expectativa, observação e próximo teste.

• Uma única rede perde acesso: a rede de origem pode estar a chegar por uma interface diferente da esperada. Comparar route, VLAN, SD-WAN Route e Packet Capture.
• Muitos clientes atrás de NAT upstream chamam a atenção: se o tráfego já tiver sido submetido a NAT antes da Sophos Firewall, esta vê vários clientes como uma Source partilhada. Verificar o limite, o caminho NAT e o pico de carga legítimo.
• VoIP, monitoring ou scanner gera drops: taxas regulares de pacotes podem parecer flooding. Verificar janela de teste curta, Log Viewer e, se necessário, regra de bypass precisa.
• Dispositivos deixam de funcionar após alteração DHCP: binding IP-MAC ou lógica Trusted MAC pode já não corresponder. Controlar lease, endereço MAC e binding.
• Só falta tráfego de retorno: é provável um caminho assimétrico ou gateway errado. Verificar ida e volta separadamente com Packet Capture.
• Alteração ARP ou ICMP cria efeitos secundários: ARP hardening, source-routed packets ou ICMP redirect podem afetar designs de rede invulgares. Verificar routers downstream, segmentos Layer 2 e caminho de routing.

Reverter em segurança

Se tráfego legítimo for afetado e não for possível determinar a causa durante a janela de manutenção, não improvise uma exceção ampla. Restaure Packet Rate, Burst Rate, flags Apply, tipo de inspeção spoof, zonas e Restrict unknown IP on trusted MAC anteriormente registados; remova apenas as novas entradas bypass ou Trusted MAC. Use Apply ou Save e repita o mesmo fluxo de teste. Para uma policy CLI, elimine primeiro apenas a regra indicada e depois a policy dedicada já sem uso. flush dos-rules não faz parte desta reversão.

Erros típicos

• Ativar Spoof Protection sem compreender o encaminhamento: O tráfego legítimo pode ser bloqueado. Verificar previamente as zonas, as interfaces, as rotas e os caminhos de retorno.
• Aplicar limiares de DoS sem os verificar: VoIP, monitorização, varrimentos ou serviços publicados podem ser afetados. Planear uma linha de base e uma fase de testes.
• Confundir Packet Rate com Burst Rate: A taxa sustentada de pacotes e um pico de curta duração são parâmetros de ajuste distintos. Ambos devem ser adequados ao serviço.
• Resolver cada anomalia com uma exceção abrangente: O reforço da segurança torna-se ineficaz e difícil de gerir. Identificar a causa e documentar exceções de âmbito restrito.
• Definir uma DoS bypass rule demasiado abrangente: No WebAdmin, o bypass é avaliado antes das DoS Settings aí configuradas e pode contornar completamente esse controlo. Restringir Source, Destination, protocolo e portas; verificar também as políticas CLI separadas.
• Deixar o IP-MAC-Pair-Filter vazio: Sem entradas devidamente mantidas, não se estabelece uma associação eficaz. Após a ativação, verificar sempre com um cliente de teste conhecido.
• Apresentar DoS Settings como proteção DDoS: Cria uma expectativa falsa no caso de ataques que saturam a largura de banda. Planear separadamente a proteção do fornecedor de serviços e a proteção a montante.
• Não verificar os registos: Os bloqueios indevidos ou os ataques passam despercebidos. Definir a verificação do Log Viewer, do Central Reporting ou do Syslog como tarefa operacional.
• Interpretar os descartes de pacotes por spoofing apenas como um ataque: Os erros de encaminhamento ou de VLAN passam despercebidos. Comparar Source-IP, Interface, rota e Packet Capture.

Lista de verificação operacional

Antes da ativação:

• Zonas, interfaces e encaminhamento compreendidos.
• Serviços críticos e casos de teste definidos.
• Packet Rate, Burst Rate e flags ativadas avaliados tecnicamente.
• Cópia de segurança ou documentação da alteração disponível.
• Registo de eventos e análise preparados.
• Área-piloto ou janela de manutenção definida.

Após a ativação:

• Internet, VPN, WAF, DNAT, VoIP e monitorização testados.
• Log Viewer verificado quanto a descartes inesperados de pacotes.
• Packet Capture utilizado para pelo menos um caso de teste claramente definido, se ocorrer descarte de pacotes.
• Exceções configuradas apenas com âmbito restrito e justificação.
• DoS bypass rules verificadas quanto a Source, Destination, protocolo e portas.
• Resultado registado na documentação operacional.

Regularmente:

• Verificar eventos DoS e Spoof.
• Rever a necessidade das exceções.
• Voltar a testar após reestruturações da rede, alterações de VPN ou novas VLANs.
• Correlacionar os registos com eventos de IPS, Threat-Feed, WAF e regras de firewall.

FAQ