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 a limpeza de regras de firewall, 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, 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: Descartar pacotes com IP de origem implausível, reduzir tentativas simples de falsificação, tornar visíveis pacotes roteados incorretamente. não substitui zona limpa, interface e planejamento de roteamento.
• DoS Settings: limita padrões simples de inundação, torna perceptíveis ataques barulhentos ou configurações incorretas mais cedo. não substitui a proteção DDoS do provedor, não há WAF e nenhum design upstream dimensionado de forma limpa.

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; não contornam automaticamente políticas CLI anteriores.

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.
• Cliente, convidado ou zonas IoT nas quais nenhuma rede interna externa deve aparecer como fonte.
• Locais onde o roteamento, VLANs e zonas estão claramente documentados.
• Ambientes nos quais pacotes são descartados devem ser posteriormente rastreados 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. Documente zonas, interfaces, VLANs, pontes 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. Verifique Log Viewer e Packet Capture para quedas inesperadas.
6. Não lide imediatamente com quedas legítimas visíveis com amplas exceções, mas primeiro verifique o roteamento, o IP de origem e a interface.

Um erro comum é tratar Spoof Protection como um puro gancho de segurança. Na realidade, a função testa uma suposição sobre o design da rede. Se esta suposição não estiver correta, Spoof Protection não precisa necessariamente estar errado. Muitas vezes uma interface, uma rota, um VLAN ou uma rota de retorno não são construídas conforme o esperado.

Compreender corretamente IP, MAC e pares IP-MAC

Sophos distingue vários tipos de verificação. IP spoofing descarta tráfego quando o IP de origem não corresponde à tabela de routing ou a uma sub-rede diretamente ligada. MAC filter trabalha com endereços MAC de confiança; para isso deve existir pelo menos uma Trusted MAC Address mantida. O MAC filter não é aplicado a pacotes DHCP. IP-MAC pair filter verifica se a combinação recebida de endereço IP e endereço MAC 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.

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.

A expectativa é importante: um IP-MAC pair filter ativo sem Trusted MAC ou pares IP-MAC mantidos não protege automaticamente. Se não existirem entradas correspondentes, o tráfego não é bloqueado, mas permitido. A proteção só surge com bindings mantidos e testados.

A opção Restrict unknown IP on trusted MAC é especialmente rigorosa: pacotes de uma Trusted MAC sem binding IP correspondente podem ser descartados se o IP for desconhecido do ponto de vista da firewall. É um ganho de segurança em redes controladas, mas um ponto sensível com DHCP, migrações e alterações temporárias de IP.

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.

Importar Trusted MACs de forma controlada

É possível importar várias Trusted MACs em Intrusion prevention > DoS & spoof protection a partir de um ficheiro .csv ou .txt. A primeira linha deve 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 no máximo 16 endereços IP por MAC, separados por vírgulas; nas outras três associações, o campo IP fica vazio.

A firewall descarta durante a importação endereços MAC, associações ou endereços IP inválidos. Também descarta valores IP introduzidos com DHCP, DHCPv6 ou None. Por isso, devem importar-se primeiro algumas linhas piloto, verificar depois os bindings visíveis e testar um caso IP-MAC permitido e outro deliberadamente incorreto. Um upload bem-sucedido ainda não prova que a lógica de filtragem pretendida esteja a funcionar.

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.

No ecrã não contam apenas floods clássicos. Existem também flags como Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet e ARP hardening. Estas opções são um hardening básico útil, porque podem reduzir manipulações de routing ou do comportamento ARP. Mesmo assim, devem ser testadas após a ativação, especialmente em redes com routers downstream, segmentos antigos ou designs 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 para que Source ou Destination se aplica um limite e quantos pacotes foram descartados. Após a deteção, a limitação aplica-se inicialmente durante dez segundos. Se o ataque continuar, a firewall reinicia o contador de forma contínua a cada dez segundos e mantém a limitação. Quando o ataque termina, os dados desaparecem após 30 segundos. Um estado vazio não prova, portanto, que antes não tenha existido um evento DoS; a análise retrospetiva requer os eventos registados.

Utilizar assinaturas DDoS apenas em modelos suportados

A Sophos disponibiliza assinaturas DDoS apenas em XGS 5500 e firewalls de maior capacidade. Num modelo suportado, cria-se uma IPS Policy dedicada, filtra-se ddos através de Smart filter, define-se deliberadamente a ação Drop packet e atribui-se depois a Policy à regra de firewall que realmente processa o tráfego. Sem essa atribuição, a Policy 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. Este exemplo documentado pela Sophos limita o tráfego SYN do endereço de exemplo 198.51.100.50 a 1000 pps por Source:

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src
system dos-config add dos-rule rule-name TestRuleSYN srcip 198.51.100.50 dos-policy TestSYN

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

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.

As regras e políticas CLI são avaliadas antes das definições DoS e spoof do WebAdmin. Nas definições do WebAdmin, a firewall verifica primeiro as DoS bypass rules e depois as restantes DoS Settings. Por isso, uma regra de bypass no WebAdmin não anula automaticamente uma política CLI correspondente.

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.

Crie a exceção em Intrusion prevention > DoS & spoof protection, na secção DoS bypass rule, através de Add. O SFOS 22 exige IP version, IP Source e Destination, Protocol, Source Port e Destination Port; * significa qualquer endereço ou porta. Para um Health Check HTTPS de 198.51.100.20 para 203.0.113.10, use Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * e Destination Port 443. Substitua ambos os endereços de documentação pelos endpoints reais. A Source Port só fica variável porque os clientes normalmente usam uma porta de origem dinâmica. Depois de Save, teste este fluxo e outro diferente; apenas o Health Check definido deve ignorar 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.

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 é atacado por meio de solicitações HTTP permitidas: Verifique WAF regra e proteção do servidor web.
• Ataques de IP de origem maliciosa conhecida: Threat Feeds ou Verifique o bloqueio de país/IP.
• Tentativa de exploração contra um serviço: Ativar IPS-Policy de acordo com a regra.
• A linha da Internet está cheia devido a DDoS: Incluir provedor, limpeza ou proteção DDoS upstream.
• A regra de firewall permite muito: Regras de limpeza, NAT e modelo de objeto.
• Drops são incompreensíveis: Melhorar o registro, Packet Capture, syslog ou relatório central.

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. Log Viewer filtro para firewall e eventos de segurança relevantes.
2. Acione o tráfego de teste com IP de origem, IP de destino e serviço claros.
3. Use Packet Capture para quedas pouco claras.
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 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

• Spoof Protection ativar sem compreensão de roteamento: tráfego legítimo pode ser bloqueado. Verificar zonas, interfaces, rotas e caminhos de retorno antecipadamente.
• Aplicar limites de DoS sem verificar: VoIP, monitoramento, varreduras ou serviços publicados podem ser interrompidos. Planejar linha de base e fase de teste.
• Confundir Packet Rate e Burst Rate: taxa sustentada e pico curto são controlos diferentes. Ambos devem corresponder ao serviço.
• Resolva cada anomalia com uma ampla exceção: O endurecimento se torna ineficaz e confuso. Limite a causa e documente de perto as exceções.
• Criar uma DoS bypass rule demasiado ampla: no WebAdmin, o bypass é avaliado antes das DoS Settings desse ecrã e pode contornar completamente este controlo. Manter Source, Destination, protocolo e portas restritos; verificar também políticas CLI separadas.
• Deixar IP-MAC pair filter vazio: sem entradas mantidas não existe binding eficaz. Após a ativação, testar sempre com um cliente conhecido.
• Venda DoS Settings como proteção DDoS: falsas expectativas para ataques de largura de banda. Planeje o provedor e a proteção upstream separadamente.
• Não verifique logs: Blocos ou ataques incorretos permanecem invisíveis. Definir Log Viewer, relatório central ou syslog como ponto operacional.
• Interpretar spoofing drops como um ataque puro: Roteamento ou VLAN erros são ignorados. Compare IP de origem, interface, rota e Packet Capture.

Lista de verificação operacional

Antes da ativação:

• zonas, interfaces e roteamento compreendidos.
• Serviços críticos e casos de teste definidos.
• Packet Rate, Burst Rate e flags ativadas avaliados tecnicamente.
• Documentação de backup ou alteração disponível.
• Registro e avaliação preparados.
• Área piloto ou conjunto de janelas de manutenção.

Após ativação:

• Internet, VPN, WAF, DNAT, VoIP e monitoramento testado.
• Log Viewer verificado se há quedas inesperadas.
• Packet Capture usado para pelo menos um caso de teste claro quando ocorrem quedas.
• As exceções são feitas de forma restrita e fundamentada.
• DoS bypass rules verificadas por source, destination, protocol e portas.
• Resultado registrado na documentação operacional.

Regularmente:

• Verifique DoS e eventos de falsificação.
• Verifique as exceções quanto à necessidade.
• Teste novamente após modificações de rede, alterações de VPN ou novos VLANs. Correlacione registros
• com IPS, feed de ameaças, WAF e eventos de regras de firewall.

FAQ