Puntos de acceso rogue: cómo detectarlos, controlarlos y evitar que vuelvan a aparecer

El problema empieza antes de que el router se enchuje

Un empleado llega a la oficina, no puede acceder a un recurso concreto porque la política WiFi corporativa bloquea su dispositivo personal, no sabe a quién pedir ayuda o sabe que el proceso tarda días, y decide resolver el problema por su cuenta: saca un router del maletín, lo conecta a la toma de red más cercana y listo. En su cabeza, ha solucionado un problema. En el tuyo, acaba de crear varios.

Esto no es un caso extremo. Es una situación habitual en organizaciones con cientos o miles de usuarios, especialmente cuando la política de acceso WiFi no está alineada con las necesidades reales del día a día. El resultado es una red llena de puntos de acceso no autorizados, también llamados APs rogue, que nadie gestiona, nadie monitoriza y que están degradando activamente tu infraestructura inalámbrica.

Qué hace exactamente un AP rogue a tu red

Hay una diferencia importante entre un empleado que comparte conexión desde el móvil y alguien que conecta un router doméstico con múltiples antenas transmitiendo a potencia máxima. Ambos causan interferencia, pero no en la misma medida.

Un router doméstico en un entorno de oficina de alta densidad puede provocar:

• Contención de aire: múltiples dispositivos intentando transmitir al mismo tiempo en el mismo canal, lo que reduce el rendimiento general de toda la red.
• Interferencia en canales adyacentes: especialmente en 2.4 GHz, donde los canales libres son escasos y cualquier emisor adicional contamina el espectro.
• Spam de beacon frames: cada AP rogue anuncia su presencia de forma constante, añadiendo ruido al medio inalámbrico aunque ningún dispositivo esté conectado a él.
• Pseudo-jamming por cambio automático de canal: algunos routers domésticos cambian de canal de forma autónoma para evitar interferencias, lo que provoca deautenticaciones en los dispositivos conectados a los APs corporativos cercanos.
• Nodos ocultos: dispositivos que no se ven entre sí pero sí al AP, lo que genera colisiones invisibles para el sistema de gestión.

El resultado visible: pérdida de paquetes, latencia irregular y usuarios quejándose de que el WiFi va lento. Sin saber que la causa está a dos mesas de distancia.

Y más allá del rendimiento, hay un problema de seguridad que no se puede ignorar: un AP rogue conectado a la red corporativa es un vector de ataque activo. Sin control de acceso, cualquier dispositivo conectado a ese router puede intentar ataques de tipo man-in-the-middle, interceptar tráfico no cifrado o acceder a recursos internos que deberían estar protegidos. Desde el punto de vista de las medidas técnicas y organizativas que exige el RGPD, una red sin control es una red que no puedes defender.

NAC con 802.1x: el punto de partida que no es opcional

El Network Access Control (NAC) con autenticación 802.1x es la base de cualquier política seria de control de acceso a red. La idea es sencilla: ningún dispositivo se conecta a la red corporativa sin autenticarse primero. Si el dispositivo no tiene el certificado correcto o no supera la verificación, no entra. O entra en una VLAN de cuarentena sin acceso a nada útil.

Esto no apaga físicamente un AP rogue que alguien haya traído de casa. Pero sí consigue algo igualmente efectivo: el router conectado al puerto de red queda aislado en una VLAN sin salida. Puede encenderse, puede emitir beacons, pero no llega a ningún sitio. El empleado descubre que su solución no funciona y, con suerte, lo reporta al equipo de IT en lugar de seguir buscando formas de saltarse el sistema.

Para implementar NAC con 802.1x necesitas:

• Switches gestionables que soporten 802.1x por puerto.
• Un servidor RADIUS (puede ser parte de una solución NAC existente o un servicio independiente).
• Certificados digitales para los dispositivos corporativos, gestionados vía PKI interna o externa.
• Políticas de GPO en equipos Windows y perfiles MDM en dispositivos móviles para controlar a qué SSIDs pueden conectarse.

El coste de esta infraestructura es moderado. La migración, si la red ya tiene switches gestionables, puede completarse en una o dos semanas para un entorno de tamaño medio. El retorno es inmediato: menos tickets de conectividad, menos tiempo de troubleshooting y una superficie de ataque significativamente reducida.

Detección automatizada: Ansible, tickets y el efecto disuasorio de la facturación

NAC resuelve el problema de la conectividad no autorizada, pero no elimina la interferencia RF de un AP que está encendido aunque no esté conectado a nada. Para eso necesitas un sistema de detección activa.

La aproximación más efectiva que se ha visto en entornos reales combina tres elementos:

• Escaneo automatizado del espectro: barridos periódicos que identifican SSIDs no reconocidos, potencias de señal anómalas y dispositivos que no forman parte del inventario autorizado.
• Generación automática de tickets: cuando el sistema detecta un AP rogue, se abre automáticamente un ticket de incidencia. Herramientas de automatización como Ansible pueden integrarse con plataformas de ticketing para que esto ocurra sin intervención manual.
• Equipo de búsqueda física y geolocalización: alguien tiene que ir a buscar el dispositivo. La señal WiFi permite triangualar la ubicación aproximada; a partir de ahí, es trabajo de campo.

Hasta aquí, el proceso es razonablemente estándar. Lo que marca la diferencia es el siguiente paso: facturar el tiempo de búsqueda al departamento donde se encontró el dispositivo.

Esta táctica puede parecer agresiva, pero los resultados hablan solos. Cuando un departamento recibe una notificación de que su presupuesto ha absorbido el coste de horas de técnico por culpa de un router no autorizado, la conversación interna cambia. Los jefes de equipo empiezan a preguntar activamente si alguien ha traído equipos de casa. Las reincidencias caen drásticamente tras la primera sanción. No porque la gente tenga miedo, sino porque el coste se hace visible y concreto para alguien con autoridad para cambiar el comportamiento del equipo.

Barridos periódicos: sistemáticos o inútiles

Un barrido puntual tras un incidente no es una política. Para que la detección sea efectiva, el proceso debe ser regular y documentado:

• Escaneo de espectro en todas las plantas y zonas de cobertura, con frecuencia definida.
• Inventario actualizado de todos los APs autorizados con sus MACs, SSIDs y ubicaciones físicas.
• Comparación automatizada entre lo detectado y lo autorizado, con alertas ante cualquier discrepancia.
• Registro de todos los incidentes: fecha, ubicación, tipo de dispositivo, departamento responsable, acción tomada.

Este registro no es burocracia. Es la base de cualquier auditoría interna o externa, y es la evidencia que necesitas si tienes que aplicar una sanción o defender tu postura ante un responsable de departamento que no acepta la facturación.

El problema de fondo: por qué los empleados traen routers

Antes de endurecer políticas, vale la pena hacer una pregunta incómoda: ¿por qué alguien decide traer un router de casa en lugar de pedir acceso por los canales habituales?

Las respuestas más comunes son predecibles: el proceso de solicitud de acceso es lento o poco claro, la cobertura WiFi no llega bien a ciertas zonas, determinados dispositivos o sistemas operativos no están soportados en la política actual, o simplemente nadie explicó nunca que conectar un equipo personal a la red estaba prohibido.

Esto no justifica el comportamiento, pero sí indica dónde hay que actuar primero. Una política restrictiva que no va acompañada de una alternativa funcional genera presión hacia las salidas de emergencia. Si el WiFi corporativo no cubre una sala de reuniones, alguien lo va a resolver por su cuenta.

Rediseñar la política WiFi no significa bajar los controles. Significa hacer que los controles existentes sean más accesibles: un proceso de solicitud de acceso con tiempos definidos y comunicados, una VLAN para invitados bien configurada, cobertura adecuada en todas las zonas de trabajo, y un canal claro para reportar problemas. Cuando el sistema oficial funciona, la gente lo usa.

Política escrita, aplicación consistente y el papel de RRHH

Todo lo anterior —NAC, automatización, barridos, facturación— pierde efectividad si no está respaldado por política escrita y aplicación consistente.

El manual de empleado debe incluir de forma explícita la prohibición de conectar equipos de red no autorizados, con una descripción clara de qué se considera un equipo no autorizado y cuáles son las consecuencias. Los acuerdos de acceso a la red deben firmarse antes de dar credenciales. Y cuando se detecta una infracción, la respuesta debe ser la misma independientemente del departamento o del rango del empleado.

Sin ese respaldo de RRHH, las sanciones técnicas quedan en el aire. Un técnico puede desactivar un puerto, pero si el empleado puede recurrir a su director y el director no sabe que existe una política firmada, el problema vuelve a aparecer la semana siguiente. La consistencia en la aplicación es lo que convierte una norma en cultura.

Un problema de gobernanza, no solo de tecnología

La tentación cuando se enfrenta este tipo de problema es buscar la solución técnica perfecta. Y las hay: NAC robusto, detección automatizada, barridos sistemáticos. Pero ninguna de ellas funciona de forma aislada.

Los APs rogue son un síntoma de una organización donde los empleados sienten que pueden eludir las políticas porque nadie las aplica, porque no las conocen o porque el sistema oficial no resuelve sus necesidades reales. La tecnología puede detectar y contener el problema. La gobernanza es lo que lo elimina.

Para un equipo IT de tamaño medio, la combinación de NAC básico con una política clara y un proceso de detección automatizado es perfectamente asumible en pocas semanas. El coste de no hacerlo —en rendimiento degradado, en tiempo de troubleshooting, en exposición a riesgos de seguridad— suele ser bastante mayor de lo que parece cuando el problema todavía no es urgente.

Vale la pena revisar qué está pasando exactamente en tu red antes de que el siguiente router aparezca debajo de una mesa.