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.

La ruta de menú típica, dependiendo de la versión SFOS, está en el rango:

Intrusion prevention > DoS & spoof protection

Si la interfaz está etiquetada de manera ligeramente diferente en una versión más reciente, debe buscar DoS, protección contra falsificación o prevención de intrusiones. Lo importante no es la ruta exacta del clic, sino que la función se planifique, pruebe y luego registre conscientemente.

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; no omiten automáticamente las políticas CLI evaluadas previamente.

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.

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. Comience con una zona o interfaz clara, por ejemplo WAN o una zona de cliente claramente separada.
3. Guardar activación.
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.

La expectativa es importante: un IP-MAC pair filter activado sin Trusted MAC o pares IP-MAC mantenidos no protege automáticamente. Si no existen entradas coincidentes, el tráfico no se bloquea, sino que se permite. La protección empieza únicamente con 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.

DoS Settings plan

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?
• ¿Qué eventos deberían registrarse únicamente y cuáles deberían bloquearse realmente?
• ¿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.

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. Este ejemplo documentado por Sophos limita el tráfico SYN de la dirección de ejemplo 198.51.100.50 a 1000 pps por origen:

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 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

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.

Las reglas y políticas CLI se evalúan antes que los ajustes DoS y spoof de WebAdmin. Dentro de los ajustes de WebAdmin, el firewall comprueba primero las DoS bypass rules y después los DoS Settings restantes. Por tanto, una regla de bypass en WebAdmin no anula automáticamente una política CLI coincidente.

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.

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 Central, compruebe si Informes de Central Firewall hace visibles los eventos deseados.

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.

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:

• Check DoS and spoof events.
• 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