Revisar Spoof Protection y DoS Settings

Spoof Protection y DoS Settings se encuentran entre las funciones de endurecimiento clásicas de un Sophos Firewall. Las funciones reducen los paquetes simples, ruidosos o obviamente incorrectos antes de que se conviertan en ruido innecesario en los registros, reglas o servicios publicados. Al mismo tiempo, estos ajustes no son una protección mágica contra todo tipo de ataques.

El artículo clasifica las funciones como un refuerzo básico cuidadoso: primero comprenda el diseño de la red y las rutas de retorno, luego active, pruebe y verifique los registros. La distinción es particularmente importante: estas funciones complementan las [reglas de firewall] limpias(/es/kb/sophos-firewall-rules/), IPS, Threat Feeds, WAF y el registro. No reemplazan estos componentes básicos.

Explicado brevemente

Spoof Protection comprueba si los paquetes con una dirección de origen plausible llegan a la interfaz esperada. Por ejemplo, si un paquete con una dirección de origen interna aparece desde Internet, esto resulta sospechoso en la mayoría de los diseños. DoS Settings, por otro lado, responde a ciertos patrones de inundación o ataque de conexión, por ejemplo, cantidades notables de tráfico SYN, UDP o ICMP.

En SFOS 22, la ruta de WebAdmin es:

Intrusion prevention > DoS & spoof protection

Los ajustes de esta página afectan al procesamiento de paquetes. Antes de seleccionar Apply o Save, anote los valores actuales y defina cómo revertir el cambio.

Qué hacen las funciones

• Spoof Protection: Descarta paquetes con IP de origen inverosímil, reduce los intentos simples de suplantación de identidad, hace visibles los paquetes enrutados incorrectamente. no reemplaza la zona limpia, la interfaz y la planificación de enrutamiento.
• DoS Settings: limita los patrones de inundación simples, hace que los ataques fuertes o las configuraciones incorrectas se noten antes. no reemplaza la protección DDoS del proveedor, ni WAF ni un diseño ascendente claramente dimensionado.

En la práctica, estas funciones son particularmente interesantes como refuerzo básico. El beneficio es reducir las tonterías obvias. En ataques DDoS volumétricos reales, la conexión a Internet suele estar ya al máximo de su capacidad antes de que el firewall pueda responder de manera significativa. Entonces necesita protección del proveedor, limpieza ascendente u otra arquitectura.

No mezclar los tipos de protección

En la misma pantalla hay varios mecanismos que responden a preguntas operativas diferentes.

• Enable spoof prevention: activa Spoof Prevention para las zonas seleccionadas. Las zonas o rutas de retorno mal interpretadas pueden afectar al tráfico legítimo.
• Trusted MAC y pares IP-MAC: las direcciones MAC o combinaciones IP-MAC conocidas se consideran de confianza. Los dispositivos móviles, cambios de DHCP o la virtualización pueden generar trabajo de mantenimiento.
• DoS settings: establecen umbrales y flags para floods SYN, UDP, TCP o ICMP/ICMPv6. Los valores demasiado estrictos afectan a picos de carga legítimos, escaneos, monitoring o VoIP.
• DoS bypass rule: excluye determinado tráfico de los DoS Settings de WebAdmin. Las excepciones amplias debilitan esta protección. Para la interacción con las políticas CLI, consulte las precisiones de versión en la sección CLI.

Esta distinción es importante porque un error tras la activación no implica automáticamente un problema con una regla de firewall. A veces el umbral DoS es demasiado agresivo, a veces un binding IP-MAC ya no es correcto y, en ocasiones, Spoof Protection revela un problema real de routing o VLAN.

Cuando Spoof Protection tiene sentido

Spoof Protection encaja especialmente bien con redes claramente segmentadas en las que las redes de origen, las interfaces y las rutas están claramente planificadas. Cuanto más clara sea la estructura de la red, más fácil será evaluar si una dirección de origen en una interfaz es plausible.

Aplicaciones útiles:

• Internet WAN en el que no deben aparecer fuentes internas RFC1918.
• DMZ o zonas de servidor con redes de origen y destino claras.
• Zonas de cliente, invitado o IoT en las que no deben aparecer redes internas externas como fuentes.
• Ubicaciones donde el enrutamiento, VLANs y zonas están claramente documentados.
• Entornos en los que las caídas de paquetes deben poder rastrearse posteriormente con Packet Capture y registros.

Las cosas se vuelven más difíciles con enrutamiento asimétrico, redes de tránsito complejas, rutas de migración temporal, VLANs documentados incorrectamente o múltiples firewalls en la misma ruta de datos. Un flujo de datos legítimo puede parecer una suplantación de identidad, aunque el diseño de enrutamiento o la ruta de retorno en realidad no sean limpios.

Verificar antes de la activación

Spoof Protection y DoS Settings no deben activarse a ciegas en un entorno de producción. Debe quedar claro de antemano qué redes y servicios se verán afectados.

Puntos de control importantes:

1. Documentar zonas, interfaces, VLANs, puentes y LAGs.
2. Verifique rutas estáticas, rutas SD-WAN, rutas VPN y rutas asimétricas.
3. Identificar los servicios publicados mediante DNAT o WAF.
4. Tenga en cuenta los servicios críticos como VoIP, monitoreo, respaldo, escaneos, VPN y conexiones de sitios.
5. Prepare el registro y la evaluación central si es necesario rastrear los eventos más adelante.
6. Establece la ventana de mantenimiento o el área piloto para la primera activación.
7. Revise las DoS bypass rules, las entradas Trusted MAC y los bindings IP-MAC existentes.
8. Anote el tipo de inspección spoof y las zonas actuales, Restrict unknown IP on trusted MAC, todos los flags Apply, Packet Rate, Burst Rate, excepciones y bindings. Estos son los valores que necesitará para revertir el cambio.

Si las reglas normales del firewall son difíciles de entender, primero se deben limpiar la regla y el estado del enrutamiento. Para conexiones de prueba individuales, Probar regla de firewall con Log Viewer, Prueba de política y Packet Capture es un mejor comienzo.

Spoof Protection active con cuidado

Un enfoque paso a paso tiene sentido para Spoof Protection. Primero debe proteger las zonas más despejadas, no todas las zonas especiales inmediatamente.

Proceso práctico:

1. Guarde la configuración actual o al menos documente los ajustes afectados.
2. En Intrusion prevention > DoS & spoof protection, seleccione Enable spoof prevention, el tipo de inspección necesario y, al principio, solo zonas bien documentadas.
3. Seleccione Apply.
4. Ejecute conexiones de prueba planificadas: acceso a Internet, VPN, servicios publicados, servidores centrales, monitoreo.
5. Verifique Log Viewer y Packet Capture para detectar caídas inesperadas.
6. No se ocupe inmediatamente de caídas legítimas llamativas con amplias excepciones, pero primero verifique el enrutamiento, la IP de origen y la interfaz.

Un error común es tratar a Spoof Protection como un puro gancho de seguridad. En realidad, la función prueba una suposición sobre el diseño de la red. Si esta suposición no es correcta, Spoof Protection no necesariamente tiene por qué estar equivocado. A menudo una interfaz, una ruta, un VLAN o una ruta de retorno no se construye como se esperaba.

Entender correctamente IP, MAC y pares IP-MAC

Sophos distingue varios tipos de comprobación. IP spoofing descarta tráfico cuando la IP de origen no coincide con la tabla de routing o con una subred conectada directamente. MAC filter trabaja con direcciones MAC de confianza; para ello debe mantenerse al menos una Trusted MAC Address. El MAC filter no se aplica a paquetes DHCP. IP-MAC pair filter comprueba si la combinación entrante de dirección IP y dirección MAC coincide con un par conocido.

Esto es útil en redes estáticas y claramente controladas, pero puede generar mucho mantenimiento en entornos dinámicos. DHCP, roaming Wi-Fi, máquinas virtuales, hypervisors, clústeres, NAC, docking stations o cambios de dispositivo pueden crear cambios MAC/IP legítimos. En esas redes conviene observar primero y crear bindings solo donde la realidad operativa sea suficientemente estable.

Para saber cómo comprobar la tabla de vecinos local y crear de forma consciente una asociación estática entre IP, MAC e interfaz, consulte Comprobar la caché de vecinos ARP y NDP.

Conviene distinguir los casos: si no hay ninguna Trusted MAC configurada, el IP-MAC pair filter activado permite todo el tráfico en esta comprobación. Una lista Trusted MAC vacía no equivale a un paquete que no coincide con un binding IP-MAC configurado. Con entradas presentes, el filtrado depende de los bindings y de Restrict unknown IP on trusted MAC; la ausencia de un par coincidente no implica siempre un bloqueo independientemente de esta opción. La protección requiere bindings mantenidos y probados.

La opción Restrict unknown IP on trusted MAC es especialmente estricta: los paquetes de una Trusted MAC sin binding IP correspondiente pueden descartarse si la IP es desconocida desde la perspectiva del firewall. Es una mejora de seguridad en redes controladas, pero un punto delicado con DHCP, migraciones y cambios IP temporales.

Una entrada individual de Trusted MAC se crea en Intrusion prevention > DoS & spoof protection, en la sección Spoof protection trusted MAC, mediante Add. Después de introducir la dirección MAC, se selecciona Static y se indican una o varias direcciones IPv4 o IPv6 separadas por comas, o bien DHCP para que el firewall asocie automáticamente las direcciones concedidas. Tras Save, conviene probar un caso IP-MAC coincidente y otro deliberadamente distinto; una entrada visible no confirma por sí sola que el filtro se aplique.

SFOS 23 documenta las opciones de búsqueda y filtrado de la lista Trusted MAC para encontrar una entrada que se deba mantener. Esta vista no cambia el filtrado de paquetes ni implica que SFOS 22 carezca de estos controles.

Importar Trusted MACs de forma controlada

Se pueden importar varias Trusted MACs en Intrusion prevention > DoS & spoof protection desde un archivo .csv o .txt. La primera fila debe contener exactamente MAC Address,IP Association,IP Address. Los valores permitidos de IP Association son Static, DHCP, DHCPv6 y None. Con Static pueden indicarse como máximo 16 direcciones IP por MAC, separadas por comas; con las otras tres asociaciones, el campo IP queda vacío.

El firewall descarta durante la importación las direcciones MAC, asociaciones o direcciones IP no válidas. También descarta valores IP introducidos con DHCP, DHCPv6 o None. Por eso conviene importar primero unas pocas filas piloto, revisar después los bindings visibles y probar un caso IP-MAC permitido y otro deliberadamente incorrecto. Una carga correcta todavía no demuestra que funcione la lógica de filtrado prevista.

Planificar DoS Settings

DoS Settings debe adaptarse al entorno. Rara vez tiene sentido adoptar valores de otro ejemplo sin comprobarlo. Un sitio con unos pocos usuarios, VoIP y un pequeño WAN, se comporta de manera diferente a un centro de datos, una red escolar o un sitio con escaneos y monitoreo regulares.

Antes de adaptarte responde a estas preguntas:

• ¿Qué servicios públicos están expuestos?
• ¿Existen picos de carga, análisis, monitoreo o controles de estado legítimos?
• ¿Se utilizan VoIP, VPN, WAF, DNAT o transferencias de archivos grandes?
• ¿Para qué protocolos debe activar el flag Apply para que el firewall descarte y registre realmente las superaciones del umbral?
• ¿Quién verifica los registros después de la activación?

DoS Settings puede ayudar a limitar patrones de inundaciones simples. Sin embargo, unos umbrales demasiado estrictos también pueden afectar al tráfico legítimo. Se debe tener especial cuidado con VoIP, sistemas de monitoreo, trabajos de respaldo, escaneos de vulnerabilidades y servicios publicados muy utilizados.

En la pantalla no solo importan los floods clásicos. También hay flags como Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet y ARP hardening. Estas opciones son un hardening básico útil porque pueden reducir manipulaciones del routing o del comportamiento ARP. Aun así, deben probarse después de activarlas, especialmente en redes con routers downstream, segmentos antiguos o diseños Layer 2 inusuales.

Para los umbrales de WebAdmin hay dos conceptos importantes:

• Packet rate: número de paquetes que un host puede enviar o recibir por minuto antes de que el tráfico sea descartado.
• Burst rate: número de paquetes que se permiten inicialmente sin comprobar el Packet Rate. Después pueden tolerarse picos breves y ocasionales por encima del Packet Rate, pero no excesos frecuentes o sostenidos.

El Apply flag decide si el límite configurado se aplica realmente al protocolo correspondiente. Si los valores son demasiado altos, aportan poco. Si son demasiado bajos, bloquean picos legítimos. Por tanto, los valores deben alinearse con el tráfico real, los servicios publicados y las ventanas de mantenimiento conocidas.

Para obtener una línea base defendible, registre primero los picos normales y las cargas excepcionales previstas. Elija después el valor de cada protocolo según el pico legítimo medido y la capacidad del servicio protegido: Sophos no ofrece un valor universal para producción. Tras cada cambio, ejecute una prueba de carga definida y compare Traffic dropped. Este contador se acumula desde el último reinicio del firewall, por lo que también debe anotar la hora de la prueba y el valor inicial.

Leer correctamente el estado DoS

En Intrusion prevention > DoS attacks, SFOS muestra en tiempo real para qué Source o Destination se aplica un límite y cuántos paquetes se han descartado. Tras la detección, el límite se aplica inicialmente durante diez segundos. Si el ataque continúa, el firewall reinicia el contador de forma continua cada diez segundos y sigue limitando. Cuando termina el ataque, los datos desaparecen al cabo de 30 segundos. Por tanto, un estado vacío no demuestra que antes no hubiera un evento DoS; para el análisis retrospectivo se necesitan los eventos registrados.

Usar firmas DDoS solo en modelos compatibles

Sophos ofrece firmas DDoS únicamente en XGS 5500 y firewalls de mayor capacidad. En un modelo compatible, el procedimiento es:

1. En Intrusion prevention > IPS policies > Add, cree una IPS Policy propia con un nombre inequívoco de su elección y guárdela con Save.
2. En esta Policy ya guardada, seleccione Edit, después Add e introduzca un nombre inequívoco para la regla.
3. Seleccione Select all, introduzca ddos en Smart filter y aplíquelo con la tecla Enter. Establezca deliberadamente Action en Drop packet.
4. Guarde primero la regla con Save y después la Policy que la contiene con el segundo Save.
5. En Rules and policies > Firewall rules, asigne la Policy a la regla de firewall que realmente procesa el tráfico previsto; compruebe por separado la asignación y la protección efectiva, como se indica en el procedimiento piloto de IPS. Sin esa asignación, la Policy no tiene efecto.

Estas firmas complementan los umbrales DoS locales, pero no sustituyen la protección DDoS del proveedor. Si la conexión a internet ya está saturada, el firewall no puede resolver el cuello de botella situado antes de la conexión WAN. Por ello deben comprobarse por separado el modelo, la licencia, la coincidencia de la regla y una prueba controlada.

Reglas CLI con system dos-config

La Device Console permite crear políticas DoS personalizadas y las reglas correspondientes. Esto es necesario, entre otras cosas, para IP Flood, ya que este tipo no se puede configurar en WebAdmin. Las unidades son diferentes: WebAdmin utiliza paquetes por minuto, mientras que system dos-config utiliza paquetes por segundo (pps).

Después de iniciar sesión por SSH, se selecciona 4. Device Console en el menú principal. Los comandos se ejecutan en el prompt console>, no en Advanced Shell.

Primero se crea la política con el tipo de ataque, el umbral y el método de recuento. Después, la regla define el tráfico al que se aplica. El ejemplo SYN documentado prevé la política TestSYN y la regla TestRuleSYN para el origen 198.51.100.50, con 1000 pps por origen.

Comprobar la ayuda de la versión de destino antes de crear objetos: la ayuda publicada para SFOS 22 y SFOS 23 usa rule_name para add dos-rule en los bloques de sintaxis y opciones, pero rule-name en los ejemplos. No está confirmado que ambas formas sean intercambiables. Consulte primero la ayuda de system dos-config en la Device Console de la versión instalada y compruebe el token de alta aceptado y los parámetros. Si persiste la duda, no cree ninguna regla y solicite una aclaración a Sophos Support. El comando completo de alta de regla se omite deliberadamente como plantilla para copiar y pegar. Cree también la política siguiente solo después de esta comprobación; por sí sola aún no vincula el tráfico de ejemplo. Este ejemplo no se presenta como probado con éxito.

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

1000 pps es un ejemplo de sintaxis, no una recomendación para una red de producción. Para una regla propia deben adaptarse deliberadamente, como mínimo, los siguientes elementos:

• SYN-Flood: alternativamente UDP-Flood, ICMP-Flood o IP-Flood, disponible únicamente aquí
• per-src: umbral por origen; alternativamente per-dst por destino o global para todo el tráfico coincidente
• las condiciones que realmente se necesitan para origen, destino, zona, interfaz y protocolo
• el umbral según una baseline medida y la capacidad del servicio protegido

El modo de recuento global no se aplica a los contadores de Intrusion prevention > DoS attacks. Por tanto, estos contadores de la interfaz no demuestran un límite CLI agregado globalmente. Compruebe la configuración con show y evalúe la aplicación de la protección por separado, con un flujo de prueba claramente definido y acotado en el tiempo y sus registros.

Los límites y campos de coincidencia de CLI están definidos de forma más precisa de lo que sugiere la regla de ejemplo:

system dos-config flush dos-rules elimina todas las reglas DoS de CLI y no es una reversión para una sola prueba. Antes de una acción global de este tipo se registran las reglas existentes individualmente con show y se guarda la configuración. Para una reversión normal se elimina de forma específica la regla indicada. La ayuda publicada describe flush para las reglas, no como eliminación de las políticas asociadas.

Después de crear ambas, primero debe comprobarse que los nombres, el tipo, el umbral y la condición de la regla sean correctos:

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

Para revertir el cambio, primero se elimina la regla y después la política que ya no se utiliza:

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

La sintaxis CLI está documentada en la Sophos Firewall Command Line Help. Aun así, primero debe utilizarse con un flujo de prueba controlado. Las reglas DoS de CLI solo admiten IPv4. Con una política IP-Flood activa, la columna Applied de Intrusion prevention > DoS attacks sigue mostrando No; Sophos lo describe como un comportamiento esperado.

Esta limitación a IPv4 se aplica a las reglas DoS de CLI, no a los DoS settings nativos de Intrusion prevention > DoS & spoof protection en WebAdmin: los ajustes DoS de esa página protegen tanto el tráfico IPv4 como el IPv6 cuando están configurados los flags de protocolo y los umbrales adecuados.

Para SFOS 22 está documentado que las reglas y políticas CLI se evalúan antes que los ajustes DoS y spoof de WebAdmin; con ese orden, una regla bypass de WebAdmin no anula automáticamente una política CLI coincidente. La ayuda CLI de SFOS 23 revisada no especifica este orden entre niveles. Esto no demuestra un cambio de comportamiento: confirme la interacción para la versión instalada antes de basarse en ella. Dentro de WebAdmin, ambas versiones siguen documentando primero las DoS bypass rules y después los DoS Settings para el tráfico restante.

Usar DoS bypass rules solo de forma precisa

Las DoS bypass rules son útiles cuando un flujo claramente conocido se ve afectado erróneamente por los DoS Settings de WebAdmin. Algunos ejemplos típicos son monitoring, Health Checks o un servicio estrictamente definido entre direcciones IP conocidas. La excepción debe ser lo más precisa posible: origen concreto, destino concreto, protocolo adecuado y rango de puertos estrecho.

Las reglas amplias con redes grandes, lógica any o rangos de puertos generales son peligrosas. Dejan ciega la inspección DoS justo donde podría necesitarse más tarde.

El orden de los ajustes de WebAdmin es importante: Sophos Firewall comprueba primero si coincide una DoS bypass rule y solo aplica los DoS Settings de WebAdmin al tráfico restante. Una regla de bypass demasiado amplia puede volver ineficaz esta protección. En las reglas bypass conviene definir conscientemente origen, destino, protocolo, puerto de origen y puerto de destino, en lugar de usar * por comodidad.

Cree la excepción en Intrusion prevention > DoS & spoof protection, dentro de DoS bypass rule, con Add. SFOS 22 exige IP version, IP de origen y destino, Protocol, puerto de origen y puerto de destino; * significa cualquier dirección o puerto. Para un Health Check HTTPS desde 198.51.100.20 hasta 203.0.113.10, use origen 198.51.100.20, destino 203.0.113.10, protocolo TCP, puerto de origen * y puerto de destino 443. Sustituya ambas direcciones de documentación por los endpoints reales. El puerto de origen solo queda variable porque los clientes suelen usar un puerto dinámico. Después de Save, pruebe este flujo y otro distinto; solo el Health Check definido debe omitir la protección DoS de WebAdmin.

Comprobar el cambio y la conmutación por error en HA

En un clúster HA, el Primary sincroniza con el Auxiliary la configuración del firewall, incluidas reglas, políticas, ajustes y comandos CLI. Realice los cambios DoS y spoof en el Primary actual. Compruebe después el estado HA en System services > High availability y vuelva a revisar las entradas de WebAdmin y las reglas CLI. En Active-active, la prueba de carga debe incluir ambas rutas de procesamiento; en Active-passive, incluya una conmutación controlada durante la ventana de mantenimiento si el procedimiento operativo lo permite. No cree una segunda configuración divergente en el Auxiliary.

Nota para SFOS 22.0 MR2

Las Release Notes de SFOS 22.0 MR2 Build 546 indican que se resolvió NC-180226: WebAdmin no mostraba ningún error al añadir una dirección MAC duplicada en Spoof protection trusted MAC. En builds 22.0 anteriores, la ausencia de un error no demuestra que la entrada sea única. Revise la lista y el binding real o actualice a un build corregido.

Lo que estas configuraciones no resuelven

Spoof Protection y DoS Settings son componentes importantes, pero no resuelven todos los problemas de seguridad.

• El servidor es atacado a través de solicitudes HTTP permitidas: Verifique WAF regla y protección del servidor web.
• Ataques IP de origen malicioso conocido: Threat Feeds o Verifique país/bloqueo de IP.
• Intento de explotación contra un servicio: Activar IPS-Policy de acuerdo con la regla.
• La línea de Internet está llena debido a DDoS: Incluir proveedor, depuración o protección DDoS ascendente.
• La regla de firewall permite demasiado: Reglas de limpieza, NAT y modelo de objetos.
• Las caídas son incomprensibles: Mejorar el registro, Packet Capture, syslog o informes centrales.

El artículo Publicar servidor con DNAT en Sophos Firewall también es relevante para servidores de acceso público. Se trata de NAT, reglas de firewall y errores de publicación típicos.

Registros y verificación de seguimiento

Después de la activación, no solo debe verificar si el acceso normal a Internet aún funciona. Lo importante es si el firewall muestra claramente los eventos esperados e inesperados.

Verifique:

1. Log Viewer filtro para firewall y eventos de seguridad relevantes.
2. Activa el tráfico de prueba con IP de origen, IP de destino y servicio claros.
3. Utilice Packet Capture para caídas poco claras.
4. Para un almacenamiento más prolongado, planifique syslog a SIEM o servidor de registro.
5. Al ejecutar Sophos Fusion (antes Sophos Central), compruebe si Informes de Central Firewall hace visibles los eventos deseados.

SFOS registra el tráfico descartado por estas protecciones. Para una prueba DoS, anote primero la hora, el origen, el destino, el protocolo y los contadores. Durante la prueba, Intrusion prevention > DoS attacks muestra en tiempo real el origen o destino y los datos descartados. Como el estado desaparece 30 segundos después de que termine el ataque y Traffic dropped se acumula desde el último reinicio, solo resulta significativa una comparación antes/después acotada. El modo CLI global no se aplica a estos contadores de la interfaz; ni siquiera esta comparación valida la agregación global. Para una política CLI global, separe la comprobación de configuración con show de las pruebas del flujo definido y de sus descartes/registros. Packet Capture muestra además la interfaz de entrada y las direcciones del paquete, pero por sí solo no demuestra qué protección descartó el flujo.

Si se descarta un paquete y el motivo no está claro, resulta útil el análisis sistemático de descartes en Sophos Firewall descarta paquetes: comprobar las causas. También describe por qué Log Viewer y Packet Capture responden a preguntas diferentes.

Solución de problemas después de la activación

Después de un cambio, los síntomas no deberían interpretarse demasiado rápido como un ataque. El análisis más rápido suele consistir en comparar expectativa, observación y siguiente prueba.

• Una sola red pierde acceso: la red de origen puede estar llegando por una interfaz distinta a la esperada. Comparar ruta, VLAN, SD-WAN Route y Packet Capture.
• Muchos clientes detrás de un NAT ascendente se ven afectados: si el tráfico ya se ha sometido a NAT antes de llegar a Sophos Firewall, esta ve varios clientes como un único origen compartido. Revisar el umbral, la ruta NAT y el pico de carga legítimo.
• VoIP, monitoring o un scanner genera drops: tasas de paquetes regulares pueden parecer flooding. Revisar una ventana de prueba estrecha, Log Viewer y, si es necesario, una regla de bypass precisa.
• Los dispositivos dejan de funcionar tras un cambio DHCP: el binding IP-MAC o la lógica Trusted MAC pueden no encajar. Comprobar lease, dirección MAC y binding.
• Solo falta el tráfico de retorno: es probable una ruta asimétrica o una puerta de enlace incorrecta. Revisar ida y vuelta por separado con Packet Capture.
• Un cambio ARP o ICMP genera efectos secundarios: ARP hardening, source-routed packets o ICMP redirect pueden afectar diseños de red inusuales. Revisar routers downstream, segmentos Layer 2 y ruta de routing.

Revertir de forma segura

Si se ve afectado tráfico legítimo y la causa no puede determinarse en la ventana de mantenimiento, no improvise una excepción amplia. Restaure los valores anotados de Packet Rate, Burst Rate, flags Apply, tipo de inspección spoof, zonas y Restrict unknown IP on trusted MAC; elimine únicamente las nuevas entradas bypass o Trusted MAC. Use Apply o Save y repita el mismo flujo de prueba. Para una política CLI, elimine primero solo la regla indicada y después su política dedicada ya sin uso. flush dos-rules no forma parte de esta reversión.

Errores típicos

• Spoof Protection activar sin comprender el enrutamiento: el tráfico legítimo puede bloquearse. Verifique las zonas, interfaces, rutas y rutas de retorno de antemano.
• Aplicar umbrales DoS sin verificar: VoIP, el monitoreo, los escaneos o los servicios publicados pueden verse interrumpidos. Planificar la línea base y la fase de prueba.
• Confundir Packet Rate y Burst Rate: la tasa sostenida y el pico corto son controles distintos. Ambos deben encajar con el servicio.
• Resolver cada anomalía con una excepción amplia: El endurecimiento se vuelve ineficaz y confuso. Limitar la causa y documentar detalladamente las excepciones.
• Crear una DoS bypass rule demasiado amplia: en WebAdmin, el bypass se comprueba antes que los DoS Settings y puede omitir completamente este control. Mantener origen, destino, protocolo y puertos estrictos; comprobar también las políticas CLI independientes.
• Dejar IP-MAC pair filter vacío: sin entradas mantenidas no hay un binding efectivo. Tras la activación, probar siempre con un cliente conocido.
• Vender DoS Settings como protección DDoS: falsas expectativas para ataques de ancho de banda. Planificar el proveedor y la protección ascendente por separado.
• No verificar los registros: Los bloques o ataques incorrectos permanecen invisibles. Definir Log Viewer, informes centrales o syslog como punto de operación.
• Interpretar las caídas de suplantación de identidad como un ataque puro: Se pasan por alto los errores de enrutamiento o VLAN. Comparar IP de origen, interfaz, ruta y Packet Capture.

Lista de verificación operativa

Antes de la activación:

• zonas, interfaces y enrutamiento entendidos.
• Servicios críticos y casos de prueba definidos.
• Packet Rate, Burst Rate y flags activados evaluados técnicamente.
• Copia de seguridad o documentación de cambios disponible.
• Registro y evaluación preparados.
• Zona piloto o ventana de mantenimiento configurada.

Después de la activación:

• Internet, VPN, WAF, DNAT, VoIP y monitoreo probado.
• Log Viewer comprobó caídas inesperadas.
• Packet Capture se utiliza para al menos un caso de prueba claro cuando se producen caídas.
• Las excepciones sólo se hacen de forma limitada y justificada.
• DoS bypass rules revisadas por origen, destino, protocolo y puertos.
• Resultado registrado en la documentación de funcionamiento.

Regularly:

• Revise los eventos DoS y spoof.
• Verifique las excepciones por necesidad.
• Pruebe nuevamente después de modificaciones de red, cambios de VPN o nuevos VLANs. Correlacione los registros de
• con IPS, la fuente de amenazas, WAF y los eventos de reglas de firewall.

Preguntas frecuentes