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 actualización intermedia de las sesiones 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 seguridad y operaciones de red que necesitan registros de auditoría justificables a partir de eventos de autenticación WiFi, y para los operadores de recintos que buscan integrar los datos de sesión en plataformas SIEM y paneles de análisis.

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

Escuchar esta guía

Ver transcripción del podcast

Te damos la bienvenida de nuevo al Purple Technical Briefing. Soy tu anfitrión y hoy vamos a profundizar en un componente fundamental, aunque a menudo incomprendido, de la infraestructura de WiFi empresarial: RADIUS Accounting. Específicamente, cómo realizamos el seguimiento de las sesiones, monitorizamos el uso y creamos registros de auditoría sólidos. Si eres director de TI, arquitecto de red o director de operaciones de un establecimiento, esto te interesa. Nos saltaremos la teoría académica para ir directamente a la aplicación práctica.

Comencemos con lo básico. Para el CTO que necesita el discurso de presentación 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 portero de la discoteca que comprueba tu identificación. Accounting es el camarero que controla cuánto tiempo te quedas y cuánto consumes. La autenticación utiliza el puerto UDP 1812 y se encarga del quién y el cómo del acceso a la red. Accounting utiliza el puerto UDP 1813 y registra minuciosamente el qué, el cuándo y el cuánto. Realiza un seguimiento de cuándo se inicia una sesión, cuándo se detiene, cuántos bytes se han transferido y qué dirección IP se ha asignado al dispositivo del cliente.

Así que 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 que se envían desde el Servidor de Acceso a la Red (normalmente tu punto de acceso o controlador inalámbrico) al servidor RADIUS. Estos se denominan paquetes Accounting-Request. En primer lugar, tienes el paquete Start. Este se envía en el momento en que un usuario se conecta correctamente. Establece el registro de referencia en la base de datos de contabilidad, capturando la identidad del usuario, la dirección MAC del dispositivo, la dirección IP asignada y el punto de acceso al que se ha conectado el usuario. Luego, tienes el paquete Stop, que se envía cuando el usuario se desconecta y contiene las estadísticas acumuladas finales de toda la sesión.

Eso parece sencillo. Start y Stop. Trabajo hecho.

No del todo. Depender únicamente de los paquetes Start y Stop supone un riesgo operativo importante. Piénsalo: ¿qué pasa si un cliente se conecta en un hotel y permanece conectado durante tres días? Si solo dependes de Start y Stop, no tendrás ninguna visibilidad de su uso durante esos tres días. O peor aún, ¿qué pasa si el punto de acceso se queda sin energía? Nunca enviará el paquete Stop y te quedarás con una sesión obsoleta en tu base de datos que parecerá estar activa de forma indefinida.

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

El tercer tipo de paquete: el Interim-Update. Esto es fundamental y es el elemento que peor se suele configurar en las implementaciones de RADIUS accounting. Configuras 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 captura instantánea en tiempo real del uso actual: bytes transferidos, duración de la sesión y recuento de paquetes. Si el servidor RADIUS deja de recibir actualizaciones intermedias de una sesión concreta, sabrás que la sesión ha finalizado, incluso si nunca has recibido un paquete Stop. La regla general aquí es sencilla: sin actualizaciones provisionales, no hay información.Ahora hablemos de los datos en sí. ¿Qué atributos específicos de estos paquetes estamos analizando que son tan valiosos para los registros de auditoría y los informes de cumplimiento?

Hay varios que son clave. El Acct-Session-Id es la clave principal que vincula los paquetes Start, Interim-Update y Stop en un registro de sesión coherente. Sin esto, es imposible correlacionar los tres tipos de paquetes. Luego está el Calling-Station-Id, que suele ser la dirección MAC del cliente (el identificador de hardware del dispositivo). El Framed-IP-Address es la dirección IP asignada al cliente para esa sesión. El Acct-Input-Octets y el Acct-Output-Octets realizan el seguimiento del volumen de datos recibidos del cliente y enviados a este. Y el Acct-Terminate-Cause, incluido en los paquetes Stop, indica por qué finalizó la sesión (ya sea porque el usuario se desconectó manualmente, se alcanzó un límite de tiempo por inactividad o se perdió la señal del operador).

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

Aquí es precisamente donde el registro de contabilidad RADIUS demuestra su retorno de la inversión. Supongamos que las autoridades se dirigen a una cadena de tiendas y les dicen: una dirección IP de su WiFi de invitados se utilizó para acceder a contenido malicioso el martes pasado a las 14:00. ¿Quién fue? Si solo dispone de los registros del firewall, solo tendrá una dirección IP. Pero las direcciones IP cambian constantemente con DHCP. Necesita vincular esa IP a un dispositivo específico en un momento concreto. Para ello, realiza una consulta en su base de datos de contabilidad RADIUS. Busca una sesión en la que el Framed-IP-Address coincida con la IP del registro del firewall, y donde la marca de tiempo del incidente se sitúe entre la hora de inicio (Start) y de finalización (Stop) de la sesión. Ese registro le proporcionará el Calling-Station-Id, es decir, la dirección MAC del dispositivo. Acaba de vincular la capa de red con la capa de dispositivo. Ese es su registro de auditoría completo.

Veamos otro escenario: un hotel de grandes dimensiones. El sector de la hostelería está especialmente expuesto en este ámbito. Un hotel de 300 habitaciones con instalaciones para conferencias puede registrar miles de sesiones de WiFi simultáneas. El equipo de operaciones necesita comprender los periodos de máximo uso para la planificación de la capacidad, mientras que el equipo de cumplimiento debe demostrar que los datos de los huéspedes se gestionan adecuadamente de acuerdo con el GDPR.

En este entorno, el registro de contabilidad RADIUS ofrece ambas soluciones. Los datos de la sesión se envían a una plataforma de analítica de WiFi, que traduce los bytes brutos y la duración de las sesiones en métricas de afluencia de visitantes y tendencias de consumo de ancho de banda. Al mismo tiempo, esos mismos datos se introducen en un módulo de informes de cumplimiento que puede demostrar exactamente a los auditores qué datos se recopilaron, durante cuánto tiempo se conservaron y cómo se protegieron.

Por lo tanto, para que todo esto sea posible, necesitamos extraer estos datos del servidor RADIUS y enviarlos a sistemas en los que podamos realizar consultas y tomar medidas. ¿Cómo deberían los equipos diseñar esa arquitectura de flujo de datos?

La primera regla es: no deje los logs almacenados en archivos de texto plano en el servidor RADIUS. Configure el servidor para escribir los datos de contabilidad en una base de datos relacional estructurada; PostgreSQL o MySQL son opciones habituales. A partir de ahí, tiene dos vías principales de consumo. En primer lugar, reenvíe los logs a su SIEM —Splunk, Microsoft Sentinel o IBM QRadar— mediante Syslog o una API REST. Esto permite a su equipo de seguridad correlacionar los eventos de autenticación WiFi con bloqueos de firewall, alertas de detección de intrusiones o activadores de prevención de pérdida de datos. En segundo lugar, introduzca los datos en su plataforma de análisis. Purple's WiFi Analytics, por ejemplo, puede ingerir estos datos de sesión y transformarlos en información accionable sobre la afluencia de visitantes, el tiempo de permanencia y la utilización de la capacidad.

Ahora hablemos de los errores comunes. ¿Dónde suelen fallar los despliegues?

Existen dos modos de fallo principales. El primero, como ya hemos comentado, es no activar en absoluto los Interim-Updates. Esto es sorprendentemente común. Los administradores configuran la autenticación correctamente pero nunca tocan los ajustes de contabilidad. El segundo, igualmente perjudicial, es establecer el intervalo de Interim-Update de forma demasiado agresiva. Si tiene 10.000 usuarios concurrentes y establece el intervalo en 1 minuto, estará generando 10.000 operaciones de escritura en la base de datos por minuto solo para las actualizaciones de contabilidad. Eso saturará la capacidad de E/S de su servidor RADIUS muy rápidamente. El punto óptimo para la mayoría de los despliegues empresariales es de 10 a 15 minutos. Ofrece una granularidad suficiente para la visibilidad operativa sin crear una carga de escritura insostenible.

Repasemos rápidamente una serie de escenarios.

Escenario uno: El gerente de un establecimiento informa que el panel de análisis muestra usuarios conectados durante 48 horas, pero el establecimiento cierra por la noche.

Se trata de un problema de sesión obsoleta (stale session). Los puntos de acceso no están enviando paquetes Stop —probablemente debido a un ciclo de apagado y encendido o a una interrupción de la red— y las sesiones nunca se cierran en la base de datos. La solución consiste en implementar un script de limpieza de sesiones inactivas en el servidor RADIUS. Cualquier sesión que no haya recibido una actualización provisional (interim update) en un plazo de dos a tres veces el intervalo configurado debería cerrarse automáticamente.

Escenario dos: El equipo de seguridad de una cadena de tiendas afirma que los logs del firewall solo muestran direcciones IP, lo que imposibilita auditar qué terminal de punto de venta específico 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 contabilidad de RADIUS, e integre esa base de datos de contabilidad de RADIUS con el SIEM para correlacionar la dirección IP con la dirección MAC.

Escenario tres: El servidor RADIUS experimenta una elevada carga de CPU durante las horas punta, lo que provoca retrasos en la autenticación.

Compruebe primero el intervalo de actualización provisional. Si está configurado en 1 o 2 minutos en un despliegue de gran tamaño, increméntelo a 15 minutos. Verifique también que la base de datos de contabilidad tenga los índices adecuados en las columnas Acct-Session-Id y User-Name. Las tablas sin indexar provocarán un escaneo completo 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 contabilidad en instancias de servidor dedicadas.

Para resumir, estas son las conclusiones clave para cualquier director de TI o arquitecto de redes que implemente o audite su infraestructura de contabilidad RADIUS.

Primero: la contabilidad RADIUS es diferente de la autenticación. Realiza el seguimiento de los datos de la sesión, no de las decisiones de acceso. Ambos son esenciales, pero sirven a diferentes propósitos operativos y de cumplimiento.

Segundo: active siempre Interim-Updates. Sin ellos, no tendrá visibilidad de las sesiones activas ni ningún mecanismo para detectar registros obsoletos.

Tercero: los tres atributos que siempre debe capturar son Acct-Session-Id, Framed-IP-Address y Calling-Station-Id. Estos tres constituyen la base de cualquier registro de auditoría significativo.

Cuarto: exporte sus datos de contabilidad. No los deje en archivos de texto plano. Escríbalos en una base de datos estructurada, reenvíelos a un SIEM y aliméntelos en una plataforma de analítica.

Quinto: diseñe a escala. Un intervalo de actualización provisional de 15 minutos es el equilibrio adecuado para la mayoría de los despliegues empresariales. Ajústelo en función de sus requisitos específicos de cumplimiento y de la capacidad de su infraestructura.

La conclusión es esta: la contabilidad RADIUS no es algo secundario. En cualquier entorno regulado (hostelería, retail, sanidad, sector público) es la base de su registro de auditoría de WiFi. Hágalo bien y dispondrá de una herramienta potente para la seguridad, el cumplimiento normativo y la inteligencia operativa. Hágalo mal y tendrá un vacío en su registro de auditoría que podría resultar muy costoso.

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

Conclusiones clave

✓La contabilidad RADIUS (RFC 2866) es distinta 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 obtener un registro de auditoría completo. Interim-Updates es la configuración que más se suele omitir.
✓Los atributos Acct-Session-Id, Framed-IP-Address y Calling-Station-Id forman el registro de auditoría mínimo 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 intervalo de actualización intermedia de 2.5x.
✓Los datos de contabilidad RADIUS deben exportarse a una base de datos estructurada e integrarse con un SIEM y una plataforma de analítica para ofrecer 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 la contabilidad RADIUS.
✓A gran escala (más de 5.000 usuarios concurrentes), separe las instancias del servidor de autenticación y de contabilidad, y considere una base de datos de series temporales para las escrituras de contabilidad para evitar la degradación del rendimiento.

Resumen Ejecutivo

Para los equipos de operaciones de TI y redes de las empresas, 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 la contabilidad RADIUS se vuelve indispensable. Mientras que la autenticación RADIUS gestiona el quién y el cómo del acceso a la red, la contabilidad RADIUS registra minuciosamente el qué, el cuándo y el cuánto.

Esta guía ofrece un análisis técnico profundo de la contabilidad RADIUS, explorando el funcionamiento de los paquetes Start, Stop e Interim-Update, así como los atributos que los hacen valiosos. Describe cómo los operadores de recintos en sectores como Hostelería , Retail y otros pueden aprovechar estos datos para mantener pistas de auditoría sólidas, garantizar el cumplimiento de la GDPR y proporcionar información procesable a plataformas SIEM o sistemas de WiFi Analytics . Al dominar la contabilidad RADIUS, los arquitectos de redes pueden transformar los registros de sesión sin procesar en activos estratégicos que impulsan la eficiencia operativa y mitigan los riesgos.

Análisis Técnico Profundo

Contabilidad RADIUS frente a Autenticación RADIUS

RADIUS (Remote Authentication Dial-In User Service), definido en la norma RFC 2865 y ampliado para la contabilidad en la RFC 2866 , funciona según un modelo cliente-servidor. En una implementación WiFi empresarial típica, el punto de acceso (AP) o el controlador de LAN inalámbrica (WLC) actúa como el Servidor de Acceso a la Red (NAS), es decir, 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 contabilidad es fundamental:

Dimensión	Autenticación RADIUS	Contabilidad RADIUS
Propósito	Verificar la identidad y conceder o 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 Paquetes	Access-Request, Access-Accept, Access-Reject	Accounting-Request (Start/Stop/Interim)
Datos Capturados	Credenciales, asignación de VLAN, política	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 la contabilidad es la que le mantiene en conformidad y con una postura defendible.

Los Tres Tipos de Paquetes de Contabilidad

La contabilidad 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 correctamente y comienza una sesión. Establece el registro de base en la base de datos de contabilidad, registrando la identidad del usuario, la dirección MAC del dispositivo, la dirección IP asignada y el punto de acceso (AP) al que se ha conectado el usuario.
Interim-Update (Acct-Status-Type = 3): enviado periódicamente durante una sesión activa. Estos paquetes proporcionan capturas continuas del uso actual: bytes transferidos, duración de la sesión y recuento de paquetes. Actúan como una señal de actividad para confirmar que la sesión sigue activa y proporcionan visibilidad sobre las sesiones de larga duración sin tener que esperar a la desconexión.
Stop (Acct-Status-Type = 2): enviado cuando finaliza la sesión, 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 acumuladas finales de toda la sesión.

Figura 1: El ciclo de vida de los paquetes de contabilidad RADIUS a lo largo de una sesión de WiFi.

Atributos clave de contabilidad

Para realizar un seguimiento eficaz de las sesiones y generar registros de auditoría sólidos, el NAS rellena 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 de sesión único generado por el NAS	Clave primaria para correlacionar los registros Start, Interim y Stop
User-Name	Identidad autenticada (nombre de usuario o dirección MAC)	Vincula la sesión con un usuario o dispositivo específico
NAS-IP-Address	Dirección IP del AP o WLC emisor	Identifica el segmento de red y la ubicación física
Framed-IP-Address	Dirección IP asignada al dispositivo cliente	Fundamental para la correlación con los registros del firewall y del proxy web
Calling-Station-Id	Dirección MAC del dispositivo cliente	Identidad a nivel de dispositivo para la traza de auditoría
Called-Station-Id	Dirección MAC del AP y SSID	Identifica la radio y la red específicas a las que se ha conectado el usuario
Acct-Input-Octets	Bytes recibidos desde el cliente	Monitorización del ancho de banda y planificación de capacidad
Acct-Output-Octets	Bytes enviados al cliente	Monitorización del ancho de banda y planificación de capacidad
Acct-Session-Time	Duración de la sesión en segundos	Análisis del tiempo de permanencia y facturación
Acct-Terminate-Cause	Motivo por el que finalizó la sesión	Resolución de problemas y detección de anomalías

Para los equipos que trabajan con la autenticación 802.1X , el atributo User-Name contendrá la identidad autenticada del intercambio EAP, lo que proporciona una traza de auditoría más detallada que la omisión de autenticación MAC (MAB) por sí sola.

Guía de implementación

La implementación de una infraestructura de contabilidad RADIUS robusta requiere una configuración meticulosa tanto en el NAS como en el servidor RADIUS. A continuación se presenta un enfoque neutral del proveedor para establecer un flujo de contabilidad fiable.

Paso 1: Configurar el NAS (Puntos de acceso / Controladores)

La configuración del NAS es donde fallan la mayoría de las implementaciones. Los administradores suelen configurar la autenticación correctamente, pero dejan la contabilidad con los ajustes predeterminados o desactivada por completo.

Definir el servidor de contabilidad: Especifique la dirección IP del servidor RADIUS y el secreto compartido para el puerto UDP 1813. En implementaciones de alta disponibilidad, configure un servidor de contabilidad secundario para evitar la pérdida de datos si el principal deja de estar accesible.
Habilitar actualizaciones provisionales (Interim Updates): Este es el paso de configuración más importante. Establezca un intervalo adecuado, normalmente 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 horaria: Configure NTP en todos los dispositivos NAS y en el servidor RADIUS. Las marcas de tiempo precisas son indispensables para los registros de auditoría y la correlación de SIEM. Una desviación del reloj de tan solo 5 minutos puede invalidar una pista de auditoría en un escenario de interceptación legal.

Paso 2: Configurar el servidor RADIUS

Integración de bases de datos: Configure el servidor RADIUS para registrar los datos de contabilidad en una base de datos relacional estructurada (por ejemplo, PostgreSQL, MySQL) en lugar de archivos de texto plano. El almacenamiento estructurado permite realizar consultas e indexaciones eficientes, así como la integración con sistemas posteriores. Asegúrese de que existan índices en Acct-Session-Id, User-Name, Framed-IP-Address y en la marca de tiempo de inicio de sesión.
Políticas de retención de datos: Implemente scripts de archivado o purga automatizados que se alineen con sus requisitos de cumplimiento. El Artículo 5(1)(e) de la 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 Investigatory Powers Act 2016 del Reino Unido) pueden exigir una retención de hasta 12 meses.

Paso 3: Crear el flujo de datos

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

Integración con SIEM: Configure el servidor RADIUS o la base de datos subyacente para reenviar los registros a su SIEM (por ejemplo, Splunk, Microsoft Sentinel, IBM QRadar) mediante Syslog o una API REST. Esto permite a los equipos de seguridad correlacionar eventos de autenticación de WiFi con bloqueos de firewall, alertas de detección de intrusos o desencadenadores de prevención de pérdida de datos.
Analytics Integration: Feed session data into platforms like Purple's WiFi Analytics to transform raw bytes and MAC addresses into actionable insights regarding footfall, dwell time, and peak usage periods. This is particularly valuable for Retail and Hospitality operators who need to align staffing and infrastructure investment with actual usage patterns.

Figure 2: The RADIUS accounting data pipeline from Access Points to SIEM and analytics platforms.

Best Practices

Always Use Interim Updates. Relying solely on Start and Stop packets creates operational blind spots. A dropped connection or AP power failure may prevent a Stop packet from being sent, leaving a stale session in the database indefinitely. Interim updates provide the mechanism to detect and close these stale sessions. The rule of thumb: if a session hasn't sent an interim update within two to three times the configured interval, treat it as terminated.

Correlate RADIUS Accounting with DHCP Logs. RADIUS accounting provides the Framed-IP-Address, but DHCP lease times can be shorter than session durations in some environments. Maintaining DHCP logs alongside RADIUS logs provides a more resilient audit trail, particularly in high-density venues where IP address recycling is frequent.

Secure the Transport with RadSec. Traditional RADIUS traffic is transmitted over UDP with minimal encryption — only the user password field is obfuscated. In distributed deployments, particularly those spanning multiple sites or cloud-hosted RADIUS servers, use RadSec (RADIUS over TLS, defined in RFC 6614) or IPsec tunnels to protect accounting data in transit. This is a requirement under PCI DSS 4.0 for any network handling cardholder data.

Monitor the Accounting Queue. If the RADIUS server becomes unreachable, NAS devices will queue accounting packets locally. Monitor this queue length; a full queue will result in dropped packets and lost audit data. Configure alerting on queue depth and implement a secondary accounting server for high-availability deployments.

Separate Authentication and Accounting Servers at Scale. In deployments exceeding 5,000 concurrent users, the write load from accounting can degrade authentication response times. Dedicated accounting servers with separate database instances prevent this contention.

Troubleshooting & Risk Mitigation

The Stale Session Problem

Symptom: The RADIUS database shows a user has been connected for 48 hours, but the venue closed overnight.

Root Cause: The NAS failed to send a Stop packet — typically due to a power failure, AP reboot, or network interruption — and the packet was never received by the RADIUS server.

Mitigation: Implement a dead-session cleanup script on the RADIUS server. The script should periodically scan for active sessions where the last received packet (Start or Interim-Update) is older than a defined threshold (e.g., 2.5x the interim update interval). Sessions exceeding this threshold should be forcefully closed with a synthetic Stop record, noting the termination cause as 'Lost-Carrier' or 'Admin-Reset'.

High RADIUS Server CPU and I/O Load

Symptom: Authentication response times degrade during peak hours; the RADIUS server reports high CPU and disk I/O.

Root Cause: An overly aggressive interim update interval (e.g., 1 minute) across thousands of APs generates an unsustainable volume of database writes.

Mitigation: Increase the interim update interval to 15 minutes. Verify that the accounting database has appropriate indexes. Consider separating authentication and accounting onto dedicated server instances. Evaluate whether a time-series database (e.g., InfluxDB) is more appropriate than a relational database for high-volume accounting data.

Missing Framed-IP-Address in Accounting Records

Symptom: RADIUS accounting records exist, but the Framed-IP-Address field is empty or absent, making IP-to-MAC correlation impossible.

Root Cause: The NAS may be sending the Start packet before DHCP has assigned an IP address to the client. The IP is only available after the DHCP exchange completes.

Mitigation: Configure the NAS to delay sending the Start packet until after DHCP assignment, if the platform supports it. Alternatively, rely on the Interim-Update packets, which are sent after DHCP assignment and will contain the Framed-IP-Address. Ensure your audit queries account for this by checking Interim-Update records if the Start record lacks an IP.

ROI & Business Impact

Implementing robust RADIUS accounting delivers measurable business value across three dimensions:

Compliance and Legal Risk Mitigation. In the event of a security incident, a data subject access request under GDPR, or a lawful intercept order, accurate accounting logs provide the audit trail necessary to identify which user or device held a specific IP address at a specific time. Without this, organisations face potential regulatory penalties under GDPR (up to 4% of global annual turnover) and reputational damage. The cost of implementing proper accounting infrastructure is a fraction of the cost of a single regulatory enforcement action.

Planificación de capacidad y ROI de la 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 SSIDs específicos que generan la mayor carga. Estos datos fundamentan directamente las decisiones de actualización de WAN y las estrategias de ubicación de los AP, garantizando que la inversión en infraestructura se dirija allí donde genere el mayor impacto. Para los centros de Transporte y los grandes recintos, esto puede representar un ahorro significativo en gastos de capital.

Analítica avanzada e inteligencia de recintos. Cuando los datos de sesión RADIUS se combinan con plataformas como WiFi Analytics y Sensors de Purple, los datos de contabilidad brutos 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 de los recuentos de sesiones concurrentes pasan a estar disponibles. Para los operadores de Hostelería , estos datos fundamentan directamente los modelos de personal, la ubicación de restauración y las estrategias de personalización de marketing. Para obtener más contexto sobre cómo la infraestructura WiFi respalda estas capacidades, consulte nuestras guías sobre Puntos de acceso inalámbrico y Soluciones de WiFi para hostelería moderna .

Definiciones clave

RADIUS Accounting

El proceso de recopilación y registro de datos sobre el consumo de recursos de red de los usuarios, que incluye las horas de inicio y finalización de las sesiones, el volumen de datos transferido y la asignación de direcciones IP. Definido en RFC 2866.

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

Acct-Status-Type

Un atributo RADIUS (ID de atributo 40) que indica el propósito de un paquete de contabilidad. 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 contabilidad.

Interim-Update

Un paquete de contabilidad RADIUS periódico enviado por el NAS durante una sesión activa para informar sobre las estadísticas de uso actuales, incluyendo 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 contabilidad (Start, Interim-Update, Stop) para la misma sesión.

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

NAS (Network Access Server)

El dispositivo (normalmente 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 contabilidad.

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

Framed-IP-Address

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

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

Calling-Station-Id

Normalmente, la dirección MAC del dispositivo cliente que se conecta a la red, con formato de 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 elemento de anclaje a nivel de dispositivo de la traza de auditoría.

Acct-Terminate-Cause

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

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

RadSec

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

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

Ejemplos prácticos

Un hotel de 300 habitaciones con instalaciones para conferencias va a implantar una nueva red WiFi para huéspedes. El director de TI debe asegurarse de que el despliegue cumpla con los requisitos del GDPR en materia de minimización de datos e integridad del registro de auditoría, al mismo tiempo que proporciona al equipo de marketing análisis de tiempo de permanencia y de visitantes recurrentes. El hotel utiliza un servidor RADIUS alojado en la nube y puntos de acceso Cisco Meraki.

El despliegue debe configurarse de la siguiente manera. En el panel de control de Meraki, navegue a Network-wide > RADIUS servers y añada el servidor RADIUS en la nube en el puerto 1813 con un secreto compartido robusto. Habilite el accounting y configure el intervalo de actualización provisional en 15 minutos. En el servidor RADIUS, configure el accounting para que escriba 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 en almacenamiento frío los registros de más de 12 meses y purgue los de más de 24 meses, documentándolo en el Registro de Actividades de Tratamiento del 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 los informes de tiempo de permanencia y a los paneles de frecuencia de visitantes recurrentes. Asegúrese de que el protocolo NTP esté sincronizado en todos los puntos de acceso Meraki y en el servidor RADIUS con una diferencia máxima de 1 segundo.

Comentario del examinador: Este escenario demuestra el doble propósito del accounting de RADIUS: cumplimiento y analítica. 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 el 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 UK Investigatory Powers Act con los principios de minimización de datos del GDPR.

Una cadena minorista con 150 tiendas necesita cumplir con los requisitos de PCI DSS 4.0 para la monitorización del acceso a la red. Sus terminales de punto de venta utilizan MAC Authentication Bypass (MAB) en la red WiFi. El equipo de seguridad ha recibido una solicitud de su QSA (Asesor de Seguridad Cualificado) para demostrar que pueden identificar qué terminal POS específico 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 accounting de RADIUS. Esto no siempre está habilitado por defecto y debe configurarse explícitamente. Segundo, integre la base de datos de accounting de RADIUS 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 punto de acceso) y el User-Name de los registros de accounting de RADIUS. A continuación, 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 del terminal POS, el punto de acceso al que estaba conectado y la ubicación de la tienda.

Comentario del examinador: Este escenario destaca el papel fundamental del atributo Framed-IP-Address para salvar la distancia 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 SIEM es el método estándar del sector para este tipo de correlación. Tenga en cuenta que en entornos con tiempos de concesión DHCP muy cortos, la correlación debe utilizar una consulta por rango de tiempo en lugar de una búsqueda en un punto temporal concreto, ya que la misma IP podría haber sido asignada a varios dispositivos en un intervalo corto de tiempo.

Preguntas de práctica

Q1. Un responsable de TI de un hotel observa que el panel de análisis de WiFi muestra muy pocos usuarios activos durante el día, a pesar de que el vestíbulo y el restaurante están visiblemente concurridos. Sin embargo, los informes históricos del día anterior muestran un pico 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 Interim-Update. ¿Cuál es la configuración incorrecta más probable y cómo la resolverías?

Sugerencia: Considera 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 los Interim-Updates estén deshabilitados o no configurados en el Wireless LAN Controller. Sin actualizaciones intermedias, el servidor RADIUS solo recibe un paquete Start cuando el usuario se conecta y un paquete Stop cuando se desconecta. El panel de análisis no puede mostrar el uso actual porque no se están reportando datos dentro de 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 los Interim-Updates en el WLC y establecer un intervalo adecuado; se recomiendan 15 minutos para el entorno de un hotel. Después de habilitarlo, verifica que el servidor RADIUS esté recibiendo paquetes Interim-Update comprobando la base de datos de contabilidad para ver si hay registros con Acct-Status-Type = 3.

Q2. Durante la investigación de un incidente de seguridad, tu SIEM ha detectado 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. Necesitas identificar el dispositivo físico responsable. El tiempo de concesión de DHCP está configurado en 30 minutos. Describe la lógica de consulta exacta que utilizarías en la base de datos de contabilidad de RADIUS para identificar el dispositivo.

Sugerencia: Las direcciones IP no son estáticas. Debes utilizar una consulta de rango de tiempo, no una búsqueda en un momento puntual, y tener en cuenta el reciclaje de concesiones de DHCP.

Ver respuesta modelo

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

Q3. Eres el arquitecto de red de un centro de conferencias que alberga eventos con hasta 8.000 usuarios concurrentes de WiFi. Tu servidor RADIUS actual está experimentando saturación de escritura en la base de datos durante los picos de los eventos, lo que provoca retrasos en la autenticación de 3 a 5 segundos. Tu intervalo actual de actualización intermedia (interim update) está configurado en 2 minutos. Describe un plan de mitigación de varios pasos que aborde tanto el problema de rendimiento inmediato como el riesgo arquitectónico subyacente.

Sugerencia: Considera tanto los cambios de configuración como los cambios arquitectónicos. 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 mitigación debe abordar tres capas. Primero, como solución inmediata, aumenta el intervalo de actualización intermedia de 2 minutos a 15 minutos en todos los Wireless Controllers. Esto reduce la carga de escritura de contabilidad 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, separa las cargas de trabajo de autenticación y contabilidad en instancias de servidor dedicadas. El servidor de autenticación gestiona los paquetes Access-Request/Accept/Reject, mientras que un servidor de contabilidad dedicado gestiona los paquetes Accounting-Request y escribe en una base de datos independiente. Esto evita que la carga de escritura de contabilidad afecte a los tiempos de respuesta de autenticación. Tercero, para el riesgo arquitectónico subyacente, evalúa 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 contabilidad. 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 contabilidad. Migra las escrituras de contabilidad a la base de datos de series temporales mientras conservas la base de datos relacional para las consultas de informes de cumplimiento.

Continúe leyendo esta serie

Medición del ROI empresarial de la red WiFi de invitados y la analítica de ubicación

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

Privacy by Design: Anonymizing WiFi Data for GDPR Compliance

Esta guía de referencia 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 normativa GDPR. Proporciona a los líderes de TI y arquitectos de redes marcos de trabajo prácticos para equilibrar la analítica avanzada de espacios físicos con los estrictos requisitos de privacidad de datos.

Heatmapping frente a analítica de presencia: diferencias técnicas

Esta guía técnica de referencia detalla las diferencias arquitectónicas y operativas críticas entre el heatmapping WiFi y la analítica de presencia para operadores de recintos empresariales. Proporciona a los responsables de TI, arquitectos de redes y directores de operaciones marcos de despliegue prácticos, escenarios de implementación reales y mejores prácticas independientes del proveedor para obtener el máximo ROI de su infraestructura inalámbrica existente.