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 bien definidas, 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 y SFOS 23, 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 una IP de origen no plausible, reduce los intentos básicos de suplantación y hace más visibles los paquetes enrutados incorrectamente. Sin embargo, esta función no sustituye una planificación adecuada de zonas, interfaces y enrutamiento.
• DoS Settings: limitan los patrones básicos de inundación y permiten detectar antes los ataques ruidosos o las configuraciones incorrectas. Sin embargo, esta función no sustituye la protección DDoS del proveedor, una WAF ni un diseño de la conectividad upstream correctamente 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 clientes, invitados o IoT en las que no deben aparecer otras redes internas como origen.
• 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 las zonas, interfaces, VLANs, Bridges 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.

Activar Spoof Protection con cuidado

Un enfoque paso a paso tiene sentido para Spoof Protection. Primero debe proteger las zonas cuyo diseño esté más claro, 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. Revisar Log Viewer y Packet Capture para detectar descartes de paquetes inesperados.
6. No evitar de inmediato los descartes anómalos de tráfico legítimo mediante excepciones amplias; comprobar primero el enrutamiento, la Source-IP y la interfaz.

Un error habitual es tratar Spoof Protection como una simple casilla de verificación de seguridad. En realidad, la función comprueba una premisa sobre el diseño de la red. Si esa premisa no se cumple, no significa necesariamente que Spoof Protection esté funcionando incorrectamente. A menudo, una interfaz, una ruta, una VLAN o una ruta de retorno no están configuradas como se esperaba.

Entender correctamente IP, MAC y pares IP-MAC

Sophos distingue varios tipos de comprobación. IP spoofing descarta el tráfico cuando la IP de origen no concuerda con la tabla de enrutamiento o el paquete no procede de una subred directamente conectada. MAC filter descarta los paquetes cuya dirección MAC no está registrada como Trusted MAC; para ello, debe haberse configurado al menos una Trusted MAC Address. El filtro MAC no se aplica a los 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.

Ejemplo con un switch de núcleo: el switch se encarga del enrutamiento entre VLANs y utiliza Sophos Firewall como puerta de enlace predeterminada. Un cliente de la VLAN 1 con 10.10.10.5 envía una solicitud a Internet que llega a la interfaz LAN de la firewall. El hecho de que el switch conozca las VLANs no hace que sus subredes estén directamente conectadas a la firewall. Antes de la activación, comprobar en la firewall la ruta para 10.10.10.5 y las subredes directamente conectadas. Si no se cumplen las condiciones de IP-Spoofing documentadas, la solicitud puede descartarse aunque la dirección del cliente sea legítima. Una prueba de acceso WAN por sí sola no sustituye esta comprobación de la ruta interna.

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: con IP-MAC pair filter activado en las zonas seleccionadas y esta opción marcada, Sophos describe el descarte de paquetes procedentes de una Trusted MAC sin vinculación IP cuando la IP es desconocida. «Desconocida» significa aquí que no existe una entrada coincidente en la tabla de enrutamiento o que no procede de una subred directamente conectada. Esto mejora la seguridad en redes controladas, pero puede causar problemas con DHCP, las migraciones y los cambios temporales de IP.

Cuando la opción no está marcada, la ayuda general de SFOS 22 y SFOS 23 indica que se permiten una Trusted MAC con cualquier IP y una Trusted MAC sin vinculación IP. En cambio, la guía independiente de Add afirma de forma general que, cuando existe una vinculación, solo se acepta un par IP-MAC coincidente. Estas afirmaciones no deben combinarse para deducir una garantía de bloqueo incondicional. Comprobar conjuntamente el tipo de comprobación, la zona, la vinculación y la casilla de verificación, y verificar en el Build instalado los casos permitidos y los casos no coincidentes que sean necesarios; si el efecto no está claro, aclararlo con Sophos Support antes de utilizarlo en producción.

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 mediante un archivo .csv o .txt. En la sección Spoof protection trusted MAC, seleccionar Import, elegir el archivo con Browse y cargarlo con Upload file. En cada línea deben indicarse la dirección MAC y IP Association. La primera línea debe contener exactamente MAC Address,IP Association,IP Address. Los valores permitidos para IP Association son Static, DHCP, DHCPv6 y None. Con Static, se pueden indicar como máximo 16 direcciones IP por MAC, separadas por comas; con las otras tres asociaciones, el campo IP se deja vacío.

El siguiente ejemplo de formato muestra vinculaciones estáticas IPv4 e IPv6 y las tres asociaciones sin 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

Las direcciones MAC e IP son marcadores de posición ficticios, no dispositivos que deban autorizarse. Sustituir cada línea por la MAC real del dispositivo y la asociación elegida deliberadamente. Static es adecuado para direcciones fijas conocidas, y DHCP o DHCPv6 para la vinculación automática mediante concesiones; None no contiene ninguna vinculación IP y, por tanto, no sustituye una comprobación de pares estáticos.

La firewall descarta durante la importación toda la entrada si esta contiene una dirección MAC no válida, una IP Association no válida o una dirección IP no válida. Esto debe distinguirse de los valores IP introducidos pese a utilizar DHCP, DHCPv6 o None: esos valores IP se descartan; esto no implica automáticamente que se elimine toda la entrada MAC. Por ello, importar primero unas pocas líneas piloto, comprobar después las vinculaciones visibles y probar un caso IP-MAC permitido y otro deliberadamente incorrecto. Una carga correcta no demuestra todavía que se aplique la lógica de filtrado deseada.

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.

Los tipos de inundación generan cargas diferentes: SYN flood genera muchas conexiones TCP semiabiertas; el servidor responde con SYN-ACK, pero no recibe una respuesta final. TCP flood se refiere, en general, a una tasa elevada de paquetes TCP. UDP flood puede sobrecargar el host de destino con comprobaciones de puertos y respuestas ICMP para puertos no utilizados. ICMP/ICMPv6 flood implica numerosos Echo Requests y puede consumir ancho de banda. En un DDoS, la carga procede de varios dispositivos de forma distribuida; por ello, un único límite por origen no aborda la misma cuestión que un límite por destino.

En la pantalla también son relevantes estos indicadores:

• Dropped source routed packets: descarta los paquetes cuya ruta especifica el remitente. De este modo se limita esta posibilidad de manipular el enrutamiento.
• Disable ICMP/ICMPv6 redirect packet: no acepta redirecciones ICMP o ICMPv6. Los routers downstream también pueden enviar legítimamente estos mensajes para indicar una ruta mejor o activa; por tanto, la opción modifica una premisa de enrutamiento y no solo la detección de ataques.
• ARP hardening: solo permite ARP Replies cuando la IP de origen y la IP de destino están en la misma subred. Sophos lo describe como una protección frente a ARP Flood y ARP Poisoning.

Estas opciones son medidas útiles de endurecimiento básico porque pueden reducir las manipulaciones del comportamiento de enrutamiento o de ARP. Aun así, deben probarse después de activarlas, especialmente en redes con routers downstream, segmentos antiguos o diseños de Layer-2 poco habituales.

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é origen o destino se aplica un límite y cuántos paquetes se han descartado. Hacer clic en el tipo de ataque para abrir los detalles; el enlace de estado de DoS & spoof protection también lleva a esta vista. Tras una detección, la limitación se aplica inicialmente durante diez segundos. Si el ataque ha terminado al finalizar ese periodo, se retira la limitación. Si continúa, la firewall reinicia este contador de forma sucesiva cada diez segundos y mantiene la limitación. Un nuevo ataque desde el mismo origen o hacia el mismo destino vuelve a reiniciar el contador y reactiva la limitación. Cuando termina el ataque, los datos desaparecen después de 30 segundos. Por tanto, un estado vacío no demuestra que no se haya producido antes un evento DoS; para el análisis retrospectivo se necesitan los eventos registrados.

Los límites de WebAdmin se aplican por origen o destino, no como una suma global de todos los hosts. Ejemplo meramente explicativo con Burst rate 100: inicialmente se permiten los primeros 100 paquetes sin comprobar la Packet rate; después se compara la tasa. Por debajo de la tasa configurada se acepta el tráfico; por encima, puede descartarse. 100 no es un valor recomendado para producción.

No equiparar la secuencia del ejemplo con el temporizador de estado: la ayuda general de SFOS 22 y SFOS 23 denomina esta secuencia un intento de ARP-Flood y describe descartes adicionales de paquetes y logs cuando el siguiente paquete del mismo origen llega en un plazo de 30 segundos. Describe que se permite el tráfico cuando ha transcurrido más tiempo desde el paquete anterior, pero expresamente no una incorporación automática a la Allow List por el mero hecho de que hayan pasado 30 segundos sin tráfico. En cambio, la ayuda independiente sobre el estado de DoS describe la limitación sucesiva de diez segundos explicada anteriormente. Estos tiempos no constituyen plazos universales fiables de autorización o espera para todos los tipos de inundación. No concluir que el tráfico está permitido basándose únicamente en un temporizador: evaluar conjuntamente el tipo de ataque, el estado en tiempo real, los logs y un flujo de prueba legítimo claramente delimitado; aclarar cualquier comportamiento no explicado con Sophos Support.

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.

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. Si parece necesaria una excepción amplia, primero se debe comprobar si se han evaluado incorrectamente los umbrales, la arquitectura o el caso de prueba.

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.

Se crea una excepción en Intrusion prevention > DoS & spoof protection, en la sección DoS bypass rule, mediante Add. SFOS 22 y SFOS 23 requieren IP version, las IP de origen y destino, Protocol, Source Port y Destination Port; * representa cualquier dirección o cualquier puerto. Para una comprobación de estado HTTPS desde 198.51.100.20 hacia 203.0.113.10, una configuración adecuada sería: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * y Destination Port 443. Ambas direcciones de documentación deben sustituirse por los extremos reales. El Source Port solo se deja variable porque los clientes suelen utilizar un puerto de origen dinámico. Después de Save, probar exactamente este flujo y otro flujo distinto; solo la comprobación de estado definida debe poder 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.

Automatización XML: conservar identidad y campos padre

Antes de automatizar estos ajustes, comprobar la configuración guardada y la API help específica del objeto en el build instalado. Las siguientes correspondencias explican la referencia SFOS 22/SFOS 23; no son plantillas de solicitudes probadas. Usar la API XML de forma segura explica operaciones de escritura explícitas, protección del acceso y comprobaciones separadas del transporte, la respuesta XML y el objeto guardado.

Regla bypass: coincidencia antigua y nueva, no un nombre

DoSBypassRules no tiene una identidad Name documentada. La coincidencia consta de IPFamily (IPv4 o IPv6), SourceIPNetmask, DestinationIPNetmask y Protocol (TCP, UDP, ICMP o AllProtocol), más SourcePort y DestinationPort para TCP/UDP. Los puertos son valores individuales de 1 a 65535 o *; la referencia no acredita aquí un payload de rango de puertos. Para añadir/editar, la tabla indica * para ambas direcciones y TCP para el protocolo como valores predeterminados. No adoptar esos valores amplios como excepción deseada: definir deliberadamente toda la coincidencia.

Al actualizar, DoSBypassRules/OldConfiguration contiene la combinación anterior de los mismos campos; los hijos directos de DoSBypassRules contienen la nueva coincidencia deseada. OldConfiguration pertenece a la identidad de actualización, no a la creación ni a la eliminación. La referencia Delete enumera los campos de coincidencia, no un nombre. Identificar la combinación realmente guardada antes de eliminarla. El ejemplo Add/Edit marca expresamente los puertos como exclusivos de TCP/UDP, mientras que las listas de parámetros, incluida Delete, declaran ambos puertos obligatorios sin condiciones. Esto no permite deducir un payload de eliminación fiable y ejecutable para ICMP/AllProtocol: aclarar la ayuda específica del objeto y el build, sin enviar valores de puerto inventados.

Trusted MAC: clave MAC y familias de direcciones separadas

En TrustedMAC, la identidad es MACAddress; al actualizar, TrustedMAC/OldConfiguration/MACAddress conserva la clave anterior y TrustedMAC/MACAddress contiene la MAC deseada. Delete solo indica MACAddress, no Name ni OldConfiguration. Guardar la entrada concreta y sus asociaciones antes de Update o Delete y comprobar después la lista de nuevo.

TrustedMAC/IPV4Association y TrustedMAC/IPV6Association son asociaciones independientes con Static, DHCP o None; la tabla API indica Static como valor predeterminado de ambas. Sus campos de direcciones CSV se llaman exactamente IPV4Address e IPV6Address. La importación de archivos también usa DHCPv6: no trasladar ese valor a IPV6Association sin comprobarlo. Para AssociateIP, el valor de ejemplo y la descripción se contradicen; aquí no se deduce ningún valor de escritura permitido. Las precisiones anteriores sobre el filtrado IP-MAC efectivo siguen siendo necesarias para entradas gestionadas por API.

La importación de archivos es una operación separada Upload_TrustedMAC con Upload_TrustedMAC/TrustedMACListFile para .csv o .txt. El ejemplo indica el nombre del archivo enviado mediante multipart, pero no acredita ni un nombre concreto de parte multipart ni su vinculación a este campo XML. No deducir del ejemplo una solicitud de carga lista para usar; aclarar primero el contrato de carga específico del build y comprobar después las asociaciones importadas.

No aplanar Spoof Prevention ni DoS Settings

El nombre duplicado es intencionado en el ejemplo: SpoofPrevention es la raíz y SpoofPrevention/SpoofPrevention el interruptor. SpoofPrevention/RestrictUnknownIPOnTrustedMAC es otro interruptor independiente. Los tres tipos de comprobación tienen listas de zonas separadas: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone y SpoofPrevention/IPMACFilter/EnableOnZone/Zone. El ejemplo muestra Enable/Disable, la tabla de parámetros indica en cambio on/off, y la nota de desactivación es ambigua. Ni esas indicaciones ni listas de zonas omitidas o vacías confirman una sintaxis para vaciar o desactivar. Aclarar valores y reversión en el build instalado antes de escribir.

Bajo DoSSettings, SYNFlood, UDPFlood, TCPFlood e ICMPFlood tienen cada uno sus propios padres Source y Destination. Bajo Source están PacketRatePerSource, BurstRatePerSource y ApplyFlag; bajo Destination, PacketRatePerDestination, BurstRatePerDestination y ApplyFlag. Por ejemplo, DoSSettings/UDPFlood/Destination/ApplyFlag solo pertenece al límite UDP de destino. La tabla permite tasas de paquetes de 1–600000 y tasas burst de 1–10000; su valor predeterminado 1 y los números del ejemplo no son una baseline de producción. Los flags adicionales están en DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag y DoSSettings/DisableARPFlooding/Destination/ApplyFlag. No agrupar las etiquetas repetidas de la tabla en un PacketRate, BurstRate o ApplyFlag global; conservar los valores guardados con su ruta padre.

Leer los códigos con la operación y el estado guardado

La referencia enumera estos códigos específicos de cada operación, no resultados HTTP universales:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. No confundir en particular el 409 de Add con el 404 de Edit.
• Configure Spoof Prevention y Configuration DOS Settings: cada una 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule y Delete Trusted MAC: solo 200, 500 en estas páginas.
• Add Trusted MAC y Update Trusted MAC: cada una 200 con Operation Successful. y 500 con Operation Fail..

Para las demás operaciones citadas, los mensajes de las fuentes completas siguen siendo símbolos JavaScript, no textos de respuesta resueltos:

Tras cada cambio, comparar la respuesta con las zonas, tasas, asociaciones o combinación bypass realmente guardadas. Ante un error o una respuesta dudosa, volver a leer el estado actual antes de reintentar; no recrear la entrada a ciegas ni deducir la eficacia del filtro únicamente de 200. Comprobar después por separado un flujo de prueba coincidente y otro no coincidente, como se describe arriba.

Lo que estas configuraciones no resuelven

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

• El servidor recibe ataques mediante solicitudes HTTP permitidas: revisar la regla WAF y Webserver Protection.
• Una IP de origen conocida como maliciosa está atacando: revisar Threat Feeds o el bloqueo por país/IP.
• Intento de explotación contra un servicio: activar una política IPS adecuada para la regla.
• El enlace a Internet está saturado por un DDoS: recurrir al proveedor, al scrubbing o a una protección DDoS situada aguas arriba.
• La regla de firewall permite demasiado: depurar el conjunto de reglas, NAT y el modelo de objetos.
• No se puede determinar la causa de los descartes de paquetes: mejorar el registro, Packet Capture, Syslog o Central Reporting.

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. Filtrar Log Viewer por eventos de Firewall y de Security relevantes.
2. Generar tráfico de prueba con una IP de origen, una IP de destino y un servicio claramente definidos.
3. Utilizar Packet Capture si no está claro por qué se descartan paquetes.
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

• Activar Spoof Protection sin comprender el enrutamiento: puede bloquearse tráfico legítimo. Comprobar previamente las zonas, las interfaces, las rutas y las rutas de retorno.
• Adoptar umbrales DoS sin verificarlos: pueden verse afectados VoIP, la monitorización, los escaneos o los servicios publicados. Prever una línea base y una fase de pruebas.
• Confundir Packet Rate y Burst Rate: la tasa sostenida de paquetes y un pico de corta duración son parámetros de ajuste distintos. Ambos deben adecuarse al servicio.
• Resolver cualquier anomalía con una excepción amplia: el endurecimiento pierde eficacia y resulta difícil de gestionar. Acotar la causa y documentar con precisión las excepciones, manteniendo un alcance limitado.
• Configurar una DoS bypass rule demasiado amplia: en WebAdmin, el bypass se comprueba antes que los DoS Settings de ese entorno y puede eludir por completo este control. Limitar estrictamente Source, Destination, el protocolo y los puertos; comprobar además las políticas CLI independientes.
• Dejar vacío el IP-MAC-Pair-Filter: sin entradas debidamente mantenidas, no se establece una vinculación eficaz. Tras la activación, comprobar siempre con un cliente de prueba conocido.
• Presentar DoS Settings como protección DDoS: genera una expectativa falsa ante ataques que saturan el ancho de banda. Planificar por separado la protección del proveedor y la protección aguas arriba.
• No revisar los registros: los bloqueos indebidos o los ataques pasan inadvertidos. Establecer la revisión de Log Viewer, Central Reporting o Syslog como tarea operativa.
• Interpretar los descartes de paquetes por spoofing únicamente como un ataque: se pasan por alto errores de enrutamiento o de VLAN. Comparar Source-IP, la interfaz, la ruta y Packet Capture.

Lista de verificación operativa

Antes de la activación:

• Comprender las zonas, interfaces y el enrutamiento.
• Definir los servicios críticos y los casos de prueba.
• Evaluar técnicamente Packet Rate, Burst Rate y los indicadores activados.
• Disponer de una copia de seguridad o de documentación del cambio.
• Preparar el registro y el análisis.
• Definir un ámbito piloto o una ventana de mantenimiento.

Después de la activación:

• Probar Internet, VPN, WAF, DNAT, VoIP y la monitorización.
• Revisar Log Viewer para detectar descartes de paquetes inesperados.
• Utilizar Packet Capture para al menos un caso de prueba claramente definido si se producen descartes de paquetes.
• Configurar únicamente excepciones de alcance limitado y justificadas.
• Revisar Source, Destination, protocolo y puertos de las DoS bypass rules.
• Registrar el resultado en la documentación operativa.

Periódicamente:

• Revisar los eventos DoS y de suplantación.
• Comprobar si las excepciones siguen siendo necesarias.
• Volver a probar después de reestructuraciones de red, cambios de VPN o nuevas VLANs.
• Correlacionar los logs con los eventos de IPS, Threat-Feed, WAF y reglas de firewall.

Preguntas frecuentes