RADIUS Accounting: Seguimiento de sesiones, uso y registros de auditoría

Esta guía proporciona una referencia técnica completa sobre RADIUS accounting: cómo registra los datos de inicio, finalización y actualizaciones provisionales (interim-updates) de las sesiones de WiFi, qué atributos se capturan y cómo aprovechar esos datos para la auditoría de seguridad, el cumplimiento de GDPR y la planificación de capacidad. Es una lectura esencial para los equipos de operaciones de red y seguridad que necesitan pistas de auditoría defendibles de los eventos de autenticación de WiFi, y para los operadores de establecimientos que buscan integrar los datos de sesión en plataformas SIEM y paneles de analíticas.

📖 9 min de lectura📝 2,044 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 9 definiciones clave

Escucha esta guía

Ver transcripción del podcast

Bienvenidos de nuevo al Purple Technical Briefing. Soy su anfitrión, y hoy nos sumergiremos en un componente crítico, pero a menudo incomprendido, de la infraestructura de WiFi empresarial: RADIUS Accounting. Específicamente, cómo realizamos el seguimiento de las sesiones, monitoreamos el uso y creamos registros de auditoría sólidos. Si es un gerente de TI, un arquitecto de red o un director de operaciones de un establecimiento, esto es para usted. Nos saltaremos la teoría académica y pasaremos directamente a la aplicación práctica.

Comencemos con lo fundamental. Para el CTO que necesita la explicación rápida de 60 segundos: ¿qué es RADIUS accounting y en qué se diferencia de la autenticación RADIUS?

En pocas palabras, la autenticación es el cadenero en la puerta que revisa su identificación. El accounting es el barman que registra cuánto tiempo se queda y cuánto consume. La autenticación utiliza el puerto UDP 1812 y maneja el quién y el cómo del acceso a la red. El accounting utiliza el puerto UDP 1813 y registra meticulosamente el qué, el cuándo y el cuánto. Realiza un seguimiento de cuándo comienza una sesión, cuándo se detiene, cuántos bytes se transfirieron y qué dirección IP se asignó al dispositivo cliente.

Entonces es la pista de auditoría. Pero, ¿cómo captura exactamente estos datos? ¿Cuál es el mecanismo?

Se basa en tres tipos de paquetes principales enviados desde el Network Access Server (generalmente su punto de acceso o controlador inalámbrico) al servidor RADIUS. Estos se denominan paquetes Accounting-Request. Primero, tiene el paquete Start. Este se envía en el momento en que un usuario se conecta con éxito. Establece el registro base en la base de datos de accounting, capturando la identidad del usuario, la dirección MAC del dispositivo, la dirección IP asignada y el AP al que se conectó el usuario. Luego, tiene el paquete Stop, enviado cuando el usuario se desconecta, que contiene las estadísticas acumuladas finales de toda la sesión.

Eso suena sencillo. Start y Stop. Trabajo terminado.

No del todo. Depender únicamente de los paquetes Start y Stop es un riesgo operativo significativo. Considere esto: ¿qué pasa si un huésped se conecta en un hotel y permanece conectado durante tres días? Si solo depende de Start y Stop, tiene cero visibilidad de su uso durante esos tres días. O peor aún, ¿qué pasa si el punto de acceso pierde energía? Nunca enviará el paquete Stop, y se quedará con una sesión inactiva en su base de datos que parecerá seguir activa indefinidamente.

Entonces, ¿cuál es la solución?

El tercer tipo de paquete: la Interim-Update. Esto es crítico, y es el elemento que peor se configura en las implementaciones de RADIUS accounting. Configura el controlador inalámbrico para que envíe una actualización cada, por ejemplo, 15 minutos durante una sesión activa. Funciona como un latido de corazón y proporciona una instantánea del uso actual: bytes transferidos, duración de la sesión y recuento de paquetes. Si el servidor RADIUS deja de recibir actualizaciones provisionales de una sesión en particular, sabrá que la sesión terminó, incluso si nunca recibió un paquete Stop. La regla general aquí es simple: Sin actualización provisional, no hay información.

Ahora hablemos de los datos en sí. ¿Qué atributos específicos estamos buscando en estos paquetes que son tan valiosos para los registros de auditoría y los informes de cumplimiento?

Hay varios clave. El Acct-Session-Id es la clave primaria que une los paquetes Start, Interim-Update y Stop en un registro de sesión coherente. Sin esto, no puede correlacionar los tres tipos de paquetes. Luego tiene el Calling-Station-Id, que suele ser la dirección MAC del cliente, el identificador de hardware del dispositivo. La Framed-IP-Address es la dirección IP asignada al cliente para esa sesión. El Acct-Input-Octets y el Acct-Output-Octets registran el volumen de datos recibidos y enviados al cliente. Y el Acct-Terminate-Cause, incluido en los paquetes Stop, le indica por qué terminó la sesión, ya sea porque el usuario se desconectó manualmente, alcanzó un límite de tiempo por inactividad o se perdió la conexión.

¿Cómo utilizamos esos atributos en un escenario del mundo real? Tomemos el cumplimiento de GDPR o una solicitud de interceptación legal.

Aquí es precisamente donde RADIUS accounting demuestra su retorno de inversión. Supongamos que las autoridades se acercan a una cadena de tiendas minoristas y dicen: una dirección IP en su WiFi de invitados se utilizó para acceder a contenido malicioso el martes pasado a las 2 p. m. ¿Quién fue? Si solo tiene registros de firewall, solo tiene una dirección IP. Pero las direcciones IP cambian constantemente con DHCP. Necesita vincular esa IP a un dispositivo específico en un momento específico. Por lo tanto, consulta su base de datos de RADIUS accounting. Busca una sesión donde la Framed-IP-Address coincida con la IP del registro del firewall, y donde la marca de tiempo del incidente se encuentre entre la hora de inicio (Start) y finalización (Stop) de la sesión. Ese registro le dará el Calling-Station-Id, la dirección MAC del dispositivo. Acaba de vincular la capa de red con la capa de dispositivo. Esa es su pista de auditoría completa.

Veamos otro escenario: un hotel grande. El sector de la hospitalidad está particularmente expuesto aquí. Un hotel de 300 habitaciones con instalaciones para conferencias podría tener miles de sesiones de WiFi simultáneas. El equipo de operaciones necesita comprender los períodos de uso pico para la planificación de capacidad, mientras que el equipo de cumplimiento debe demostrar que los datos de los huéspedes se manejan adecuadamente bajo GDPR.

En este entorno, RADIUS accounting proporciona ambos. Los datos de la sesión se envían a una plataforma de analíticas de WiFi, que traduce los bytes sin procesar y las duraciones de las sesiones en métricas de afluencia y tendencias de consumo de ancho de banda. Simultáneamente, los mismos datos se envían a un módulo de informes de cumplimiento que puede demostrar a los auditores exactamente qué datos se recopilaron, durante cuánto tiempo se retuvieron y cómo se protegieron.

Entonces, para que todo esto suceda, necesitamos extraer estos datos del servidor RADIUS y enviarlos a sistemas donde podamos consultarlos y actuar sobre ellos. ¿Cómo deberían los equipos diseñar ese flujo de trabajo?

La primera regla es: no deje los registros en archivos de texto plano en el servidor RADIUS. Configure el servidor para escribir los datos de accounting en una base de datos relacional estructurada; PostgreSQL o MySQL son opciones comunes. Desde allí, tiene dos rutas de consumo principales. Primero, reenvíe los registros a su SIEM (Splunk, Microsoft Sentinel o IBM QRadar) utilizando Syslog o una API REST. Esto permite a su equipo de seguridad correlacionar los eventos de autenticación de WiFi con bloqueos de firewall, alertas de detección de intrusos o activadores de prevención de pérdida de datos. Segundo, envíe los datos a su plataforma de analíticas. Purple WiFi Analytics, por ejemplo, puede ingerir estos datos de sesión y transformarlos en información útil sobre afluencia, tiempo de permanencia y utilización de la capacidad.

Ahora hablemos de los errores comunes. ¿Dónde fallan las implementaciones?

Dos modos de falla principales. Primero, como hemos discutido, no habilitar las Interim-Updates en absoluto. Esto es sorprendentemente común. Los administradores configuran la autenticación correctamente pero nunca tocan los ajustes de accounting. Segundo, y esto es igualmente perjudicial, configurar el intervalo de Interim-Update de manera demasiado agresiva. Si tiene 10,000 usuarios simultáneos y configura el intervalo en 1 minuto, estará generando 10,000 operaciones de escritura en la base de datos por minuto solo para las actualizaciones de accounting. Eso saturará la capacidad de E/S de su servidor RADIUS muy rápidamente. El punto óptimo para la mayoría de las implementaciones empresariales es de 10 a 15 minutos. Proporciona suficiente granularidad para la visibilidad operativa sin crear una carga de escritura insostenible.

Repasemos un conjunto de escenarios rápidos.

Escenario uno: El gerente de un establecimiento informa que el panel de analíticas muestra usuarios conectados durante 48 horas, pero el lugar cierra por la noche.

Ese es un problema de sesión inactiva. Los puntos de acceso no están enviando paquetes Stop (probablemente debido a un reinicio de energía o una interrupción de la red) y las sesiones nunca se cierran en la base de datos. La solución es implementar un script de limpieza de sesiones inactivas en el servidor RADIUS. Cualquier sesión que no haya recibido una actualización provisional dentro de dos a tres veces el intervalo configurado debe cerrarse automáticamente.

Escenario dos: El equipo de seguridad de una cadena de tiendas minoristas dice que los registros del firewall solo muestran direcciones IP, lo que hace imposible auditar qué terminal de punto de venta específica accedió a una IP externa sospechosa.

Asegúrese de que los puntos de acceso estén configurados para incluir el atributo Framed-IP-Address en los paquetes de RADIUS accounting, e integre esa base de datos de RADIUS accounting con el SIEM para correlacionar la dirección IP con la dirección MAC.

Escenario tres: El servidor RADIUS está experimentando una alta carga de CPU durante las horas pico, lo que provoca retrasos en la autenticación.

Revise primero el intervalo de actualización provisional. Si está configurado en 1 o 2 minutos en una gran infraestructura, auméntelo a 15 minutos. Verifique también que la base de datos de accounting tenga los índices adecuados en las columnas Acct-Session-Id y User-Name. Las tablas sin indexar provocarán escaneos completos de la tabla en cada escritura, lo cual es catastrófico a gran escala. Y considere separar sus cargas de trabajo de autenticación y accounting en instancias de servidor dedicadas.

Para terminar, aquí están los puntos clave para cualquier gerente de TI o arquitecto de red que implemente o audite su infraestructura de RADIUS accounting.

Primero: RADIUS accounting es independiente de la autenticación. Realiza un seguimiento de los datos de la sesión, no de las decisiones de acceso. Ambos son esenciales, pero sirven para diferentes propósitos operativos y de cumplimiento.

Segundo: Habilite siempre las Interim-Updates. Sin ellas, no tiene visibilidad de las sesiones activas ni un mecanismo para detectar registros inactivos.

Tercero: Los tres atributos que siempre debe capturar son Acct-Session-Id, Framed-IP-Address y Calling-Station-Id. Estos tres forman la base de cualquier pista de auditoría significativa.

Cuarto: Exporte sus datos de accounting. No los deje en archivos planos. Escriba en una base de datos estructurada, reenvíe a un SIEM y envíe a una plataforma de analíticas.

Quinto: Diseñe para escalar. Un intervalo de actualización provisional de 15 minutos es el equilibrio adecuado para la mayoría de las implementaciones empresariales. Ajústelo según sus requisitos de cumplimiento específicos y la capacidad de su infraestructura.

La conclusión es esta: RADIUS accounting no es algo opcional. En cualquier entorno regulado (hospitalidad, comercio minorista, atención médica, sector público), es la base de su pista de auditoría de WiFi. Hágalo bien y tendrá una herramienta poderosa para la seguridad, el cumplimiento y la inteligencia operativa. Hágalo mal y tendrá un vacío en su pista de auditoría que podría resultar muy costoso.

Gracias por escuchar el Purple Technical Briefing. Hasta la próxima.

Puntos clave

✓RADIUS accounting (RFC 2866) es independiente de la autenticación: registra los datos de uso de la sesión (duración, bytes transferidos, asignación de IP) en lugar de tomar decisiones de control de acceso.
✓Los tres tipos de paquetes (Start, Interim-Update y Stop) deben estar configurados y operativos para tener una pista de auditoría completa. Las Interim-Updates son la configuración que más se suele omitir.
✓Los atributos Acct-Session-Id, Framed-IP-Address y Calling-Station-Id forman la pista de auditoría mínima viable, lo que permite la correlación de IP a dispositivo para investigaciones de cumplimiento y seguridad.
✓Las sesiones inactivas (causadas por la falta de paquetes Stop) deben gestionarse con un script de limpieza de sesiones inactivas utilizando la regla de 2.5 veces el intervalo de actualización provisional.
✓Los datos de RADIUS accounting deben exportarse a una base de datos estructurada e integrarse con un SIEM y una plataforma de analíticas para entregar todo su valor operativo y de cumplimiento.
✓Para el cumplimiento de PCI DSS, GDPR y la interceptación legal, la capacidad de vincular una dirección IP a una dirección MAC en un momento específico es el requisito principal que cumple RADIUS accounting.
✓A gran escala (más de 5,000 usuarios simultáneos), separe las instancias de servidor de autenticación y de accounting, y considere una base de datos de series temporales para las escrituras de accounting para evitar la degradación del rendimiento.

Resumen Ejecutivo

Para los equipos de TI y operaciones de red empresariales, autenticar a los usuarios en una red WiFi es solo la mitad de la batalla. Una vez que un dispositivo está conectado, comprender qué hace ese dispositivo (cuánto tiempo permanece conectado, cuántos datos consume y cuándo se desconecta) es fundamental para la seguridad, la planificación de la capacidad y el cumplimiento normativo. Aquí es donde el registro de conexiones (accounting) de RADIUS se vuelve indispensable. Mientras que la autenticación RADIUS maneja el quién y el cómo del acceso a la red, el registro de conexiones de RADIUS registra meticulosamente el qué, el cuándo y el cuánto.

Esta guía ofrece un análisis técnico profundo del registro de conexiones de RADIUS, explorando la mecánica de los paquetes Start, Stop e Interim-Update, y los atributos que los hacen valiosos. Describe cómo los operadores de establecimientos en sectores como Hospitalidad , Retail y otros pueden aprovechar estos datos para mantener pistas de auditoría sólidas, garantizar el cumplimiento de GDPR y alimentar con inteligencia procesable a las plataformas SIEM o sistemas de WiFi Analytics . Al dominar el registro de conexiones de RADIUS, los arquitectos de red pueden transformar los registros de sesión sin procesar en activos estratégicos que impulsan la eficiencia operativa y mitigan el riesgo.

Análisis Técnico Profundo

Registro de Conexiones de RADIUS vs. Autenticación RADIUS

RADIUS (Remote Authentication Dial-In User Service), definido en RFC 2865 y ampliado para el registro de conexiones en RFC 2866 , opera bajo un modelo cliente-servidor. En una implementación típica de WiFi empresarial, el Punto de Acceso (AP) o el Controlador de LAN Inalámbrica (WLC) actúa como el Servidor de Acceso a la Red (NAS): el cliente RADIUS. El servidor RADIUS (por ejemplo, FreeRADIUS, Cisco ISE, Aruba ClearPass) recibe y procesa las solicitudes.

La distinción entre autenticación y registro de conexiones es fundamental:

Dimensión	Autenticación RADIUS	Registro de Conexiones de RADIUS
Propósito	Verificar la identidad y otorgar/denegar el acceso	Registrar el uso y la actividad de la sesión
Puerto UDP	1812	1813
Referencia RFC	RFC 2865	RFC 2866
Tipos de Paquete	Access-Request, Access-Accept, Access-Reject	Accounting-Request (Start/Stop/Interim)
Datos Capturados	Credenciales, asignación de VLAN, políticas	Tiempo de sesión, bytes transferidos, dirección IP
Rol de Cumplimiento	Control de acceso	Pista de auditoría, interceptación legal

Para los equipos que implementan Guest WiFi a gran escala, ambas funciones son necesarias, pero el registro de conexiones es el que mantiene el cumplimiento y la defensa legal.

Los Tres Tipos de Paquetes de Registro de Conexiones

El registro de conexiones de RADIUS se basa en tres tipos principales de paquetes Accounting-Request, cada uno definido por el atributo Acct-Status-Type:

Start (Acct-Status-Type = 1): Enviado por el NAS cuando un usuario se conecta con éxito y comienza una sesión. Establece el registro base en la base de datos de registro de conexiones, capturando la identidad del usuario, la dirección MAC del dispositivo, la dirección IP asignada y el AP al que se conectó el usuario.
Interim-Update (Acct-Status-Type = 3): Enviado periódicamente durante una sesión activa. Estos paquetes proporcionan capturas instantáneas del uso actual: bytes transferidos, duración de la sesión y recuento de paquetes. Actúan como un latido para confirmar que la sesión sigue activa y proporcionan visibilidad de las sesiones de larga duración sin tener que esperar a la desconexión.
Stop (Acct-Status-Type = 2): Enviado cuando la sesión termina, ya sea por una desconexión iniciada por el usuario, un reinicio del AP, un tiempo de espera por inactividad o un tiempo de espera de la sesión. Contiene las estadísticas finales y acumulativas de toda la sesión.

Figura 1: El ciclo de vida del paquete de registro de conexiones de RADIUS a lo largo de una sesión de WiFi.

Atributos Clave del Registro de Conexiones

Para rastrear eficazmente las sesiones y crear pistas de auditoría sólidas, el NAS llena los paquetes Accounting-Request con atributos específicos. Los siguientes son los más significativos a nivel operativo:

Atributo	Descripción	Relevancia para el Cumplimiento
Acct-Session-Id	Identificador único de sesión generado por el NAS	Clave primaria para correlacionar registros Start, Interim y Stop
User-Name	Identidad autenticada (nombre de usuario o dirección MAC)	Asocia la sesión a un usuario o dispositivo específico
NAS-IP-Address	Dirección IP del AP o WLC que reporta	Identifica el segmento de red y la ubicación física
Framed-IP-Address	Dirección IP asignada al dispositivo cliente	Crítico para correlacionar con registros de firewall y proxy web
Calling-Station-Id	Dirección MAC del dispositivo cliente	Identidad a nivel de dispositivo para la pista de auditoría
Called-Station-Id	Dirección MAC del AP y SSID	Identifica la radio y red específica a la que se conectó el usuario
Acct-Input-Octets	Bytes recibidos desde el cliente	Monitoreo de ancho de banda y planificación de capacidad
Acct-Output-Octets	Bytes enviados al cliente	Monitoreo de ancho de banda y planificación de capacidad
Acct-Session-Time	Duración de la sesión en segundos	Análisis de tiempo de permanencia y facturación
Acct-Terminate-Cause	Razón por la que terminó la sesión	Resolución de problemas y detección de anomalías

Para los equipos que trabajan con 802.1X Authentication , el atributo User-Name contendrá la identidad autenticada del intercambio EAP, proporcionando una pista de auditoría más rica que el Bypass de Autenticación MAC (MAB) por sí solo.

Guía de Implementación

Implementar una infraestructura sólida de registro de conexiones de RADIUS requiere una configuración cuidadosa tanto a nivel del NAS como del servidor RADIUS. El siguiente es un enfoque independiente del proveedor para establecer un flujo de registro de conexiones confiable.

Paso 1: Configurar el NASS (Access Points / Controllers)

La configuración del NAS es donde fallan la mayoría de las implementaciones. Los administradores a menudo configuran la autenticación correctamente pero dejan el registro de actividad (accounting) en la configuración predeterminada o completamente deshabilitado.

Definir el Servidor de Accounting: Especifica la dirección IP del servidor RADIUS y el secreto compartido para el puerto UDP 1813. En implementaciones de alta disponibilidad, configura un servidor de accounting secundario para evitar la pérdida de datos si el principal deja de estar disponible.
Habilitar Actualizaciones Interinas (Interim Updates): Este es el paso de configuración más importante. Establece un intervalo adecuado, típicamente de 10 a 15 minutos para implementaciones empresariales. Los intervalos más cortos (por ejemplo, 1 minuto) proporcionan datos más detallados pero generan una carga de escritura insostenible a gran escala; los intervalos más largos (por ejemplo, 30 minutos) reducen la sobrecarga pero retrasan la visibilidad de las sesiones activas.
Garantizar la Sincronización de la Hora: Configura NTP en todos los dispositivos NAS y en el servidor RADIUS. Las marcas de tiempo precisas no son negociables para los registros de auditoría y la correlación de SIEM. Un desfase del reloj de 5 minutos puede invalidar un rastro de auditoría en un escenario de interceptación legal.

Paso 2: Configurar el Servidor RADIUS

Integración de Base de Datos: Configura el servidor RADIUS para registrar los datos de accounting en una base de datos relacional estructurada (por ejemplo, PostgreSQL, MySQL) en lugar de archivos de texto plano. El almacenamiento estructurado permite realizar consultas eficientes, indexación e integración con sistemas descendentes. Asegúrate de que existan índices en Acct-Session-Id, User-Name, Framed-IP-Address y en la marca de tiempo de inicio de la sesión.
Políticas de Retención de Datos: Implementa scripts automatizados de archivo o depuración alineados con tus requisitos de cumplimiento. El Artículo 5(1)(e) del GDPR exige que los datos no se conserven más tiempo del necesario; sin embargo, las regulaciones de interceptación legal en muchas jurisdicciones (por ejemplo, la Ley de Poderes de Investigación del Reino Unido de 2016) pueden requerir una retención de hasta 12 meses.

Paso 3: Construir el Pipeline de Datos

Para maximizar el valor de los datos de accounting, estos deben exportarse a plataformas de consumo donde puedan ser consultados, correlacionados y visualizados.

Integración con SIEM: Configura el servidor RADIUS o la base de datos subyacente para reenviar los registros a tu SIEM (por ejemplo, Splunk, Microsoft Sentinel, IBM QRadar) utilizando Syslog o una API REST. Esto permite a los equipos de seguridad correlacionar los eventos de autenticación de WiFi con bloqueos de firewall, alertas de detección de intrusos o activadores de prevención de pérdida de datos.
Integración de Analytics: Introduce los datos de sesión en plataformas como WiFi Analytics de Purple para transformar bytes sin procesar y direcciones MAC en información útil sobre la afluencia, el tiempo de permanencia y los períodos de mayor uso. Esto es particularmente valioso para los operadores de Retail y Hospitality que necesitan alinear el personal y la inversión en infraestructura con los patrones de uso reales.

Figura 2: El pipeline de datos de accounting de RADIUS desde los Access Points hasta las plataformas de SIEM y analytics.

Mejores Prácticas

Utiliza siempre Interim Updates. Depender únicamente de los paquetes Start y Stop crea puntos ciegos operativos. Una caída de la conexión o una falla de energía en el AP puede evitar que se envíe un paquete Stop, dejando una sesión inactiva en la base de datos de forma indefinida. Las actualizaciones interinas proporcionan el mecanismo para detectar y cerrar estas sesiones inactivas. La regla general: si una sesión no ha enviado una actualización interina dentro de dos a tres veces el intervalo configurado, considérala como terminada.

Correlaciona el Accounting de RADIUS con los Registros de DHCP. El accounting de RADIUS proporciona la Framed-IP-Address, pero los tiempos de concesión de DHCP pueden ser más cortos que la duración de las sesiones en algunos entornos. Mantener los registros de DHCP junto con los registros de RADIUS proporciona un rastro de auditoría más resistente, particularmente en lugares de alta densidad donde el reciclaje de direcciones IP es frecuente.

Protege el Transporte con RadSec. El tráfico RADIUS tradicional se transmite a través de UDP con un cifrado mínimo: solo se ofusca el campo de la contraseña del usuario. En implementaciones distribuidas, particularmente aquellas que abarcan múltiples sitios o servidores RADIUS alojados en la nube, utiliza RadSec (RADIUS sobre TLS, definido en RFC 6614) o túneles IPsec para proteger los datos de accounting en tránsito. Este es un requisito bajo PCI DSS 4.0 para cualquier red que maneje datos de titulares de tarjetas.

Monitorea la Fila de Accounting. Si el servidor RADIUS deja de estar disponible, los dispositivos NAS pondrán en cola los paquetes de accounting localmente. Monitorea la longitud de esta fila; una fila llena dará como resultado la pérdida de paquetes y de datos de auditoría. Configura alertas sobre la profundidad de la fila e implementa un servidor de accounting secundario para implementaciones de alta disponibilidad.

Separa los Servidores de Autenticación y de Accounting a Gran Escala. En implementaciones que superan los 5,000 usuarios concurrentes, la carga de escritura del accounting puede degradar los tiempos de respuesta de la autenticación. Los servidores de accounting dedicados con instancias de bases de datos separadas evitan este conflicto.

Resolución de Problemas y Mitigación de Riesgos

El Problema de la Sesión Inactiva (Stale Session)

Síntoma: La base de datos de RADIUS muestra que un usuario ha estado conectado durante 48 horas, pero el establecimiento cerró por la noche.

Causa Raíz: El NAS no pudo enviar un paquete Stop, típicamente debido a una falla de energía, reinicio del AP o interrupción de la red, y el paquete nunca fue recibido por el servidor RADIUS.

Mitigación: Implementa un script de limpieza de sesiones inactivas en el servidor RADIUS. El script debe escanear periódicamente las sesiones activas donde el último paquete recibido (Start o Interim-Update) sea más antiguo que un umbral definido (por ejemplo, 2.5 veces el intervalo de actualización interina). Las sesiones que superen este umbral deben cerrarse a la fuerza con un registro Stop sintético, indicando la causa de la terminación como 'Lost-Carrier' o 'Admin-Reset'.

Alta carga de CPU y de E/S en el servidor RADIUS

Síntoma: Los tiempos de respuesta de autenticación se degradan durante las horas pico; el servidor RADIUS reporta un alto uso de CPU y de E/S de disco.

Causa raíz: Un intervalo de actualización provisional demasiado agresivo (por ejemplo, de 1 minuto) en miles de AP genera un volumen insostenible de escrituras en la base de datos.

Mitigación: Incremente el intervalo de actualización provisional a 15 minutos. Verifique que la base de datos de contabilidad tenga los índices adecuados. Considere separar la autenticación y la contabilidad en instancias de servidor dedicadas. Evalúe si una base de datos de series temporales (por ejemplo, InfluxDB) es más adecuada que una base de datos relacional para datos de contabilidad de alto volumen.

Falta el Framed-IP-Address en los registros de contabilidad

Síntoma: Existen registros de contabilidad de RADIUS, pero el campo Framed-IP-Address está vacío o ausente, lo que imposibilita la correlación de IP a MAC.

Causa raíz: El NAS puede estar enviando el paquete Start antes de que DHCP haya asignado una dirección IP al cliente. La IP solo está disponible después de que se completa el intercambio de DHCP.

Mitigación: Configure el NAS para retrasar el envío del paquete Start hasta después de la asignación de DHCP, si la plataforma lo admite. Alternativamente, dependa de los paquetes Interim-Update, que se envían después de la asignación de DHCP y contendrán el Framed-IP-Address. Asegúrese de que sus consultas de auditoría contemplen esto al verificar los registros de Interim-Update si el registro Start carece de una IP.

ROI e impacto empresarial

La implementación de una contabilidad RADIUS sólida ofrece un valor empresarial medible en tres dimensiones:

Mitigación de riesgos legales y de cumplimiento. En caso de un incidente de seguridad, una solicitud de acceso a datos personales bajo la GDPR o una orden de interceptación legal, los registros de contabilidad precisos proporcionan la pista de auditoría necesaria para identificar qué usuario o dispositivo tenía una dirección IP específica en un momento determinado. Sin esto, las organizaciones se enfrentan a posibles sanciones regulatorias bajo la GDPR (de hasta el 4% de la facturación anual global) y daños a la reputación. El costo de implementar una infraestructura de contabilidad adecuada es una fracción del costo de una sola acción de cumplimiento regulatorio.

Planificación de capacidad y ROI de infraestructura. Al analizar las tendencias de Acct-Input-Octets y Acct-Output-Octets a lo largo del tiempo, los arquitectos de red pueden identificar patrones de consumo de ancho de banda, periodos de uso pico y los AP o SSID específicos que generan la mayor carga. Estos datos informan directamente las decisiones de actualización de WAN y las estrategias de ubicación de AP, garantizando que la inversión en infraestructura se dirija a donde genere el mayor impacto. Para los centros de Transport y los grandes recintos, esto puede representar ahorros significativos en gastos de capital.

Análisis avanzado e inteligencia de recintos. Cuando los datos de sesión de RADIUS se combinan con plataformas como WiFi Analytics y Sensors de Purple, los datos de contabilidad sin procesar se transforman en inteligencia de recintos. Las métricas de tiempo de permanencia derivadas de la duración de la sesión, la identificación de visitantes recurrentes a partir del historial de Calling-Station-Id y el análisis de ocupación pico a partir del recuento de sesiones concurrentes se vuelven disponibles. Para los operadores de Hospitality , estos datos informan directamente los modelos de personal, la ubicación de alimentos y bebidas, y las estrategias de personalización de marketing. Para obtener más contexto sobre cómo la infraestructura de WiFi respalda estas capacidades, consulte nuestras guías sobre Wireless Access Points y Modern Hospitality WiFi Solutions .

Definiciones clave

RADIUS Accounting

El proceso de recopilar y registrar datos sobre el consumo de recursos de red de los usuarios, incluidos los tiempos de inicio y finalización de la sesión, el volumen de datos transferidos y la asignación de direcciones IP. Definido en RFC 2866.

Esencial para la facturación, la planificación de capacidad, el cumplimiento de GDPR y el mantenimiento de pistas de auditoría de seguridad en cualquier implementación de WiFi empresarial.

Acct-Status-Type

Un atributo RADIUS (ID de atributo 40) que indica el propósito de un paquete de accounting. Los valores incluyen Start (1), Stop (2) e Interim-Update (3).

Utilizado por el servidor RADIUS para determinar si debe crear un nuevo registro de sesión, actualizar uno existente o cerrarlo. El atributo más fundamental en cualquier paquete de accounting.

Interim-Update

Un paquete periódico de RADIUS accounting enviado por el NAS durante una sesión activa para reportar estadísticas de uso actuales, incluidos los bytes transferidos y la duración de la sesión.

Crítico para el seguimiento de sesiones de larga duración y para detectar sesiones inactivas si un cliente se desconecta inesperadamente sin enviar un paquete Stop.

Acct-Session-Id

Una cadena única generada por el NAS para identificar una instancia de conexión de usuario específica. Este valor es consistente en todos los paquetes de accounting (Start, Interim-Update, Stop) para la misma sesión.

La clave primaria utilizada para correlacionar todos los registros de accounting que pertenecen a la misma sesión. Sin esto, es imposible reconstruir un historial de sesión completo.

NAS (Network Access Server)

El dispositivo, típicamente un punto de acceso inalámbrico o un controlador de LAN inalámbrica, que controla el acceso físico a la red y actúa como cliente RADIUS, generando y enviando paquetes de accounting.

El NAS es responsable de la precisión e integridad de los datos de accounting. Una configuración incorrecta a nivel de NAS (por ejemplo, accounting deshabilitado, atributos faltantes) no se puede solucionar a nivel del servidor RADIUS.

Framed-IP-Address

La dirección IP asignada al dispositivo cliente durante la sesión, incluida en los paquetes de RADIUS accounting.

Crítico para correlacionar los registros de RADIUS accounting con otros registros de red, como los de firewall, proxy web o DNS. La ausencia de este atributo hace imposible la correlación entre IP y dispositivo.

Calling-Station-Id

Típicamente la dirección MAC del dispositivo cliente que se conecta a la red, formateada como una cadena hexadecimal separada por dos puntos (por ejemplo, AA:BB:CC:DD:EE:FF).

Se utiliza para identificar el dispositivo de hardware específico, independientemente de la dirección IP que tenga asignada. El anclaje de la capa de dispositivo de la pista de auditoría.

Acct-Terminate-Cause

Un atributo incluido en los paquetes Stop que especifica la razón por la que finalizó una sesión. Los valores comunes incluyen User-Request, Lost-Carrier, Idle-Timeout, Session-Timeout y Admin-Reset.

Valioso para la resolución de problemas de conectividad y para la detección de anomalías; por ejemplo, una alta tasa de terminaciones por Lost-Carrier en un AP específico puede indicar un problema de hardware o interferencia.

RadSec

RADIUS sobre TLS (Transport Layer Security), definido en RFC 6614. Proporciona transporte cifrado y autenticado para paquetes RADIUS, reemplazando el transporte tradicional basado en UDP.

Requerido en cualquier implementación donde el tráfico RADIUS atraviese redes no confiables (por ejemplo, servidores RADIUS en la nube conectados a Internet). Cada vez más exigido por PCI DSS 4.0 para entornos de datos de titulares de tarjetas.

Ejemplos resueltos

Un hotel de 300 habitaciones con instalaciones para conferencias está implementando una nueva red WiFi para huéspedes. El gerente de TI debe asegurarse de que la implementación cumpla con los requisitos de GDPR para la minimización de datos y la integridad de la pista de auditoría, al mismo tiempo que proporciona al equipo de marketing analíticas de tiempo de permanencia y visitantes recurrentes. El hotel utiliza un servidor RADIUS alojado en la nube y AP de Cisco Meraki.

La implementación debe configurarse de la siguiente manera. En el panel de Meraki, navegue a Network-wide > RADIUS servers y agregue el servidor RADIUS en la nube en el puerto 1813 con un secreto compartido fuerte. Habilite accounting y configure el intervalo de actualización provisional (interim update) a 15 minutos. En el servidor RADIUS, configure accounting para escribir en una base de datos PostgreSQL con el siguiente esquema: session_id (clave primaria), user_name, nas_ip, framed_ip, calling_station_id, called_station_id, session_start, session_end, input_octets, output_octets, terminate_cause. Implemente una política de retención de datos que archive automáticamente los registros de más de 12 meses en almacenamiento en frío y depure los registros de más de 24 meses, documentado en el Registro de Actividades de Procesamiento de GDPR del hotel. Configure una integración con Purple WiFi Analytics para ingerir los datos de la sesión, lo que permitirá al equipo de marketing acceder a informes de tiempo de permanencia y paneles de frecuencia de visitantes recurrentes. Asegúrese de que el NTP esté sincronizado en todos los AP de Meraki y el servidor RADIUS con una diferencia máxima de 1 segundo.

Comentario del examinador: Este escenario demuestra el doble propósito de RADIUS accounting: cumplimiento y analíticas. El intervalo de actualización provisional de 15 minutos es adecuado para un entorno hotelero donde las sesiones pueden durar días. El diseño del esquema de PostgreSQL garantiza que se capturen todos los campos relevantes para GDPR, evitando al mismo tiempo la recopilación innecesaria de datos. La política de retención de 12/24 meses equilibra los requisitos de la Ley de Poderes de Investigación del Reino Unido con los principios de minimización de datos de GDPR.

Una cadena de tiendas minoristas con 150 sucursales necesita cumplir con los requisitos de PCI DSS 4.0 para el monitoreo de acceso a la red. Sus terminales de punto de venta utilizan MAC Authentication Bypass (MAB) en la red WiFi. El equipo de seguridad recibió una solicitud de su QSA (Asesor de Seguridad Calificado) para demostrar que pueden identificar qué terminal POS específica accedió a la red de pago en cualquier momento dado, utilizando únicamente una dirección IP de origen y una marca de tiempo de un registro de firewall.

La solución requiere una integración de tres componentes. Primero, verifique que todos los controladores de LAN inalámbrica estén configurados para incluir el atributo Framed-IP-Address en los paquetes de RADIUS accounting. Esto no siempre está habilitado de forma predeterminada y debe configurarse explícitamente. Segundo, integre la base de datos de RADIUS accounting con la plataforma SIEM (por ejemplo, Splunk). Cree una tabla de búsqueda en Splunk que asocie la Framed-IP-Address y los rangos de tiempo de la sesión con el Calling-Station-Id (dirección MAC). Tercero, cree una búsqueda guardada en Splunk que acepte una IP de origen y una marca de tiempo como entradas y devuelva la dirección MAC correspondiente, la NAS-IP-Address (que identifica la tienda y el AP) y el User-Name de los registros de RADIUS accounting. Luego se puede demostrar este flujo de trabajo al QSA: dada una entrada de registro de firewall que muestra la IP de origen 10.5.12.44 a las 14:23:07 en una fecha específica, la búsqueda devuelve la dirección MAC de la terminal POS, el AP al que estaba conectada y la ubicación de la tienda.

Comentario del examinador: Este escenario destaca el papel fundamental del atributo Framed-IP-Address para cerrar la brecha entre la identidad de la capa de red (dirección IP) y la identidad de la capa de dispositivo (dirección MAC). El enfoque de la tabla de búsqueda de SIEM es el método estándar de la industria para este tipo de correlación. Tenga en cuenta que en entornos con tiempos de concesión de DHCP muy cortos, la correlación debe utilizar una consulta de rango de tiempo en lugar de una búsqueda en un punto específico en el tiempo, ya que la misma IP puede haber sido asignada a múltiples dispositivos dentro de una ventana corta.

Preguntas de práctica

Q1. ¿Un gerente de TI de un hotel nota que el panel de analíticas de WiFi muestra muy pocos usuarios activos durante el día, a pesar de que el lobby y el restaurante están visiblemente llenos. Sin embargo, los informes históricos del día anterior muestran un aumento masivo en el uso de datos. Los registros del servidor RADIUS confirman que se están recibiendo paquetes Start, pero la base de datos muestra muy pocos registros de Interim-Update. ¿Cuál es la configuración incorrecta más probable y cómo la resolvería?

Sugerencia: Considere cómo se reporta el uso de datos durante una sesión activa en comparación con el momento de la desconexión.

Ver respuesta modelo

La causa más probable es que las Interim-Updates estén deshabilitadas o no configuradas en el controlador de LAN inalámbrica. Sin actualizaciones provisionales, el servidor RADIUS solo recibe un paquete Start cuando el usuario se conecta y un paquete Stop cuando se desconecta. El panel de analíticas no puede mostrar el uso actual porque no se reportan datos durante la sesión. Una vez que los usuarios se van y se desconectan, llegan los paquetes Stop con el total de datos acumulados, lo que provoca el pico retrasado en los informes históricos. La solución es habilitar las Interim-Updates en el WLC y configurar un intervalo adecuado; se recomiendan 15 minutos para un entorno hotelero. Después de habilitarlo, verifique que el servidor RADIUS esté recibiendo paquetes Interim-Update revisando la base de datos de accounting en busca de registros con Acct-Status-Type = 3.

Q2. Durante la investigación de un incidente de seguridad, su SIEM detectó que una dirección IP en la red WiFi de invitados accedió a un servidor de comando y control conocido a las 09:47:23 en una fecha específica. Necesita identificar el dispositivo físico responsable. El tiempo de concesión de DHCP está configurado en 30 minutos. Describa la lógica de consulta exacta que utilizaría en la base de datos de RADIUS accounting para identificar el dispositivo.

Sugerencia: Las direcciones IP no son estáticas. Debe utilizar una consulta de rango de tiempo, no una búsqueda en un punto específico en el tiempo, y tener en cuenta la reutilización de concesiones de DHCP.

Ver respuesta modelo

Debe consultar la base de datos de RADIUS accounting para buscar sesiones donde: (1) la Framed-IP-Address sea igual a la IP detectada, Y (2) la marca de tiempo de session_start sea anterior o igual a las 09:47:23, Y (3) la marca de tiempo de session_end sea posterior o igual a las 09:47:23, O session_end sea NULL (la sesión seguía activa al momento de la consulta). Si coinciden varias sesiones (lo cual es posible con una concesión de DHCP de 30 minutos), revise los registros de Interim-Update para confirmar qué sesión estaba reportando uso activamente a las 09:47:23. El registro de sesión coincidente contendrá el Calling-Station-Id (dirección MAC del dispositivo) y el User-Name (identidad autenticada, si se utilizó 802.1X). Cruce la dirección MAC con su inventario de dispositivos o con los registros del servidor DHCP para identificar el dispositivo físico y a su propietario.

Q3. Usted es el arquitecto de red de un centro de conferencias que alberga eventos con hasta 8,000 usuarios de WiFi simultáneos. Su servidor RADIUS actual está experimentando saturación de escritura en la base de datos durante los eventos pico, lo que provoca retrasos de autenticación de 3 a 5 segundos. Su intervalo de actualización provisional actual está configurado en 2 minutos. Describa un plan de remediación de varios pasos que aborde tanto el problema de rendimiento inmediato como el riesgo arquitectónico subyacente.

Sugerencia: Considere tanto los cambios de configuración como los cambios de arquitectura. El objetivo es mantener la integridad de la pista de auditoría mientras se reduce la carga de escritura.

Ver respuesta modelo

El plan de remediación debe abordar tres capas. Primero, como solución inmediata, aumente el intervalo de actualización provisional de 2 a 15 minutos en todos los controladores inalámbricos. Esto reduce la carga de escritura de accounting en aproximadamente un 87% (de una escritura cada 2 minutos a una cada 15 minutos por sesión), lo que debería aliviar de inmediato la presión de E/S de la base de datos. Segundo, separe las cargas de trabajo de autenticación y accounting en instancias de servidor dedicadas. El servidor de autenticación maneja los paquetes Access-Request/Accept/Reject, mientras que un servidor de accounting dedicado maneja los paquetes Accounting-Request y escribe en una base de datos separada. Esto evita que la carga de escritura de accounting afecte los tiempos de respuesta de autenticación. Tercero, para el riesgo arquitectónico subyacente, evalúe si una base de datos de series temporales (por ejemplo, InfluxDB o TimescaleDB) es más adecuada que una base de datos relacional para la carga de trabajo de accounting. Las bases de datos de series temporales están optimizadas para escrituras secuenciales de gran volumen y consultas de rango de tiempo, lo que coincide exactamente con el patrón de datos de accounting. Migre las escrituras de accounting a la base de datos de series temporales mientras conserva la base de datos relacional para las consultas de informes de cumplimiento.

Continúe leyendo esta serie

Medición del ROI empresarial de WiFi de invitados y analíticas de ubicación

Esta guía proporciona un marco técnico y operativo para medir el ROI empresarial de WiFi de invitados y analíticas de ubicación. Detalla cómo calcular el valor de las inversiones en hardware a través del incremento del tiempo de permanencia, la eficiencia operativa y la captura de datos de primera mano en los sectores de retail, hotelería y espacios públicos. Los directores de TI, arquitectos de red, CTO y directores de operaciones de establecimientos encontrarán marcos de medición concretos, casos de estudio reales y orientación de cumplimiento para justificar y maximizar su inversión en WiFi.

Privacy by Design: Anonymizing WiFi Data for GDPR Compliance

Esta guía autorizada detalla la arquitectura técnica y las estrategias de implementación para anonimizar datos de WiFi con el fin de garantizar el cumplimiento de la GDPR. Proporciona a los líderes de TI y arquitectos de redes marcos de trabajo prácticos para equilibrar análisis de ubicaciones robustos con requisitos estrictos de privacidad de datos.

Heatmapping vs Presence Analytics: Diferencias técnicas

Esta guía técnica autorizada detalla las diferencias arquitectónicas y operativas críticas entre el WiFi heatmapping y presence analytics para operadores de espacios empresariales. Proporciona a los líderes de TI, arquitectos de red y directores de operaciones marcos de implementación prácticos, escenarios de ejecución del mundo real y mejores prácticas neutrales respecto al proveedor para extraer el máximo ROI de su infraestructura inalámbrica existente.