Proteger Sophos AP6 frente a AirSnitch: planificar bien el aislamiento de clientes

La vulnerabilidad AirSnitch identificada como sophos-sa-20260421-airsnitch afecta a todas las versiones de AP6 clasificadas actualmente como vulnerables. La exposición real depende del diseño del SSID, la configuración, la variante de ataque y la red ascendente. Para AP6 son relevantes tres rutas orientadas a la inyección: GTK Abuse, Broadcast Reflection y Gateway Bouncing. AirSnitch por sí solo no permite un ataque completo de intermediario en AP6.

⚠️ No existe una solución completa: actualmente no hay una mitigación completa, una corrección ni una versión corregida para esta clase de ataques. Las medidas siguientes reducen el riesgo, pero no lo eliminan. Justo antes de cada fase del despliegue, comprueba el estado actual de las versiones AP6 y de la corrección. Si el estado ha cambiado, detén el despliegue y reevalúa las protecciones, el piloto y la reversión.

Procedimiento rápido: registra primero la configuración de referencia exacta. En un único SSID piloto, comprueba o activa Client isolation y Proxy ARP en My Products > Wireless > SSIDs > nombre del SSID > Advanced Settings. Separa los dispositivos de confianza y no fiables en SSID y VLAN distintos, bloquea en el gateway el tráfico entre clientes, incluidas posibles rutas hairpin, y prueba los controles anti-spoofing compatibles solo tras validar la topología. WPA2/WPA3 Enterprise y 802.11w aportan protección adicional, pero no son soluciones completas para AirSnitch.

Por qué Client isolation no es suficiente

La opción Client isolation de Central bloquea la comunicación entre dispositivos inalámbricos conectados al mismo punto de acceso. Los dispositivos de la misma subred aún pueden comunicarse si están conectados a puntos de acceso diferentes. Este límite L2 local habitual debe distinguirse de una ruta enrutada o reflejada.

En Gateway Bouncing se explota precisamente la separación entre las capas 2 y 3: una trama preparada se envía al gateway ascendente, que la enruta de vuelta a la víctima. Bloquear solo el reenvío directo en el AP no cubre automáticamente esta ruta L3 o hairpin. Un estado verde en Central tampoco demuestra la política del gateway ni el aislamiento entre AP.

Proxy ARP permite al AP responder a solicitudes ARP destinadas a los dispositivos inalámbricos conectados. Reduce la exposición a broadcasts y, por ello, es una medida importante frente a AirSnitch. No sustituye al aislamiento de clientes, la separación VLAN, las políticas de firewall ni la validación de la ruta de retorno.

Registra la referencia exacta antes del piloto

Antes del primer Save, registra al menos lo siguiente para cada SSID afectado, preferiblemente con una exportación o capturas fechadas:

• nombre del SSID, Enable SSID, AP6 asignados y bandas activadas;
• modo de cifrado, selección RADIUS y valores de autenticación relevantes, sin secretos;
• estado actual de Client isolation, Proxy ARP y 802.11w;
• modo Client connection e ID de VLAN estáticos o entregados por RADIUS;
• uplink del AP, VLAN permitidas, subred cliente, gateway, DHCP, DNS y reglas existentes;
• ajustes de DHCP Snooping, IP Source Guard o uRPF, con puertos, roles de confianza y excepciones;
• dos clientes de prueba conocidos, AP piloto, segundo AP y flujos permitidos y bloqueados que funcionan actualmente.

Estos valores forman la referencia de reversión. «Restaurar la configuración anterior» solo es seguro si se conocen las casillas, asignaciones, VLAN y reglas previas. Como Save actualiza todos los AP asignados al SSID y puede desconectar brevemente a los clientes, limita el primer cambio a un SSID de prueba o un único AP piloto.

Protege el SSID AP6 por capas

1. Activa Client isolation y Proxy ARP

Ve a My Products > Wireless > SSIDs, selecciona el SSID piloto y abre Advanced Settings. En Security, activa Client isolation. Después, activa Proxy ARP en Quality of service y guarda inicialmente solo para el alcance piloto previsto.

Client isolation protege la ruta directa entre clientes del mismo AP. Proxy ARP reduce los broadcasts ARP respondiendo en nombre de los dispositivos conectados. Se complementan, pero no cierran por completo la ruta entre AP, todas las variantes broadcast/multicast ni la ruta a través de un gateway ascendente.

Antes de ampliar el despliegue, prueba las aplicaciones que necesitan descubrimiento local, como impresoras o casting. Si falla una función necesaria, no retires toda la protección ni crees una excepción directa entre clientes. Integra el descubrimiento controlado o el acceso entre clientes en una política o un gateway de descubrimiento diseñados por separado, con reglas muy limitadas.

2. Separa las zonas de confianza con SSID y VLAN

Los dispositivos no fiables, BYOD, IoT e internos gestionados no deberían compartir una red cliente plana. Utiliza SSID y VLAN distintos con sus propias políticas y evita mezclar clientes de confianza y no fiables en el mismo SSID y, cuando sea posible, en el mismo AP.

Central solo etiqueta el tráfico cliente con el ID de VLAN elegido; el switch, gateway, DHCP, DNS y las reglas deben existir fuera de Central. Configurar un SSID AP6 con una VLAN explica el diseño completo. Un ID de VLAN por sí solo no es una frontera de seguridad: la política del gateway o firewall determina qué zonas y destinos son accesibles.

3. Bloquea las rutas L3 y hairpin en el gateway

En el gateway o firewall, bloquea el tráfico de capa 3 entre clientes de la forma más restrictiva posible, incluido el tráfico que el gateway devolvería a la misma subred cliente. Permite solo destinos y servicios necesarios. El registro de la regla piloto ayuda a demostrar si el tráfico de prueba toma realmente esa ruta.

La distinción es esencial: según la ruta inalámbrica y de switching, los dispositivos de una misma VLAN pueden comunicarse directamente sin pasar por el gateway. Una regla de firewall solo bloquea tráfico que llega al firewall. Si el tráfico entre AP se puentea localmente, el diseño debe usar segmentación inalámbrica, de switch o VLAN adecuada para forzarlo a cruzar la frontera de política controlada. Una regla nominal «client-to-client deny» sin una ruta de datos demostrada no es un criterio de éxito.

4. Aplica anti-spoofing ascendente solo cuando encaje

Las protecciones adicionales incluyen DHCP Snooping, IP Source Guard y validación de origen en el gateway, como uRPF, cuando el switch o gateway lo admitan. Estos controles dependen del entorno: uplinks de confianza, servidores DHCP, clientes estáticos, relays, routing asimétrico y redundancia afectan a una configuración segura.

No los actives a ciegas en todos los puertos. Documenta primero bindings y rutas legítimas y prueba después un control en el segmento piloto. La renovación DHCP, los dispositivos estáticos, el failover del gateway y la ruta de retorno deben seguir funcionando. Si no hay una configuración verificada del fabricante para el switch o router utilizado, deja el punto abierto y resuélvelo con su documentación o soporte.

5. Sitúa Enterprise y 802.11w en su contexto

Con WPA2-Personal, WPA3-Personal o modos personales mixtos, la Group Temporal Key compartida por los clientes del mismo SSID puede emplearse para GTK Abuse. Avanet recomienda por ello WPA2/WPA3 Enterprise (802.1X) con RADIUS externo en lugar de autenticación con clave compartida. Esto mejora el control de acceso y reduce accesos no autorizados, pero no elimina los vectores basados en GTK. Prueba por separado migración y compatibilidad con RADIUS y WPA3 Enterprise para AP6.

802.11w solo está disponible para SSID AP6 y protege las tramas de gestión después de establecer una conexión segura mediante cifrado y autenticación. Actívalo como refuerzo adicional después de probar la compatibilidad de los clientes. No es aislamiento del tráfico de datos ni una corrección de AirSnitch y no debe contar como una validación de AirSnitch superada.

Valida en dos fases antes del despliegue general

El piloto valida la ruta de datos real, no solo las casillas. Aplica los criterios de aceptación correspondientes a cada fase:

Fase 1: un AP piloto y validación en el mismo AP

1. Configuración: Central muestra los valores esperados de Client isolation, Proxy ARP, VLAN y, si procede, 802.11w. Solo está asignado el AP piloto previsto.
2. Infraestructura aprobada: ambos clientes reciben la configuración IP prevista, resuelven DNS y alcanzan únicamente la infraestructura y los servicios externos aprobados. Prueba esos destinos por separado de las pruebas entre clientes.
3. Mismo AP: conecta ambos clientes al AP piloto. Con Client isolation activado, toda comunicación directa entre ellos debe fallar, sea cual sea el protocolo o servicio; un servicio directo entre clientes no es una excepción permitida.
4. Operación y descubrimiento: prueba la renovación DHCP y los flujos necesarios de impresión, casting o descubrimiento. Todo descubrimiento controlado o acceso entre clientes necesario debe atravesar una política o un gateway de descubrimiento diseñados por separado, no un reenvío directo entre clientes. Atribuye primero los fallos inesperados a la capa modificada.

Fase 2: un segundo AP controlado y validación entre AP

1. Ampliación controlada: solo después de superar la fase 1, asigna exactamente un segundo AP controlado. Central debe mostrar ahora exactamente esos dos AP con la configuración prevista; todavía no añadas el resto de AP.
2. AP distintos: conecta un cliente a cada AP en la misma subred y repite las pruebas de denegación entre clientes. No sustituyas esta prueba entre AP por lo esperado de Client isolation.
3. Capa 3 y hairpin: usa registros del gateway o una captura de paquetes para demostrar si cada ruta de prueba cruza la frontera de política y coincide con la regla de denegación prevista, incluida una ruta devuelta a la red cliente. No reproduzcas deliberadamente un exploit en una WLAN de producción.
4. Repetición y autorización: vuelve a conectar, prueba al menos otro tipo de cliente, repite las comprobaciones de infraestructura aprobada y verifica el estado de configuración de ambos AP. Solo después de superar ambas fases, despliega en grupos pequeños.

Estas dos fases solo demuestran que los controles definidos y las rutas normales funcionan según lo previsto en ese entorno. No demuestran una corrección completa de AirSnitch.

Revierte exactamente a la referencia

Si falla una prueba, detén el despliegue y no cambies a la vez SSID, VLAN, gateway y switch. Retira primero asignaciones de AP adicionales o devuelve el SSID al alcance piloto. Después restaura la referencia documentada de cada capa modificada:

1. Central: estados originales de Client isolation, Proxy ARP y 802.11w, modo Client connection, VLAN, bandas y asignaciones de AP.
2. Gateway/firewall: elimina solo las nuevas reglas piloto o restaura posiciones, orígenes, destinos, servicios, acciones y logging registrados.
3. Protección de switch/gateway: revierte únicamente los cambios piloto de DHCP Snooping, IP Source Guard o uRPF, incluidas las asignaciones de confianza y excepciones anteriores.
4. Comprobación: espera al estado de configuración de Central y vuelve a probar DHCP, DNS, servicios permitidos, destinos bloqueados y SSID existentes con los clientes conocidos.

No elimines como primer paso un SSID, VLAN o regla de producción. Si la referencia no está clara, detente y aclárala con los responsables de red o Sophos Support en vez de crear un estado desconocido con más cambios. El riesgo AirSnitch permanece tras la reversión: esta restablece el servicio, pero no corrige la vulnerabilidad.