Por qué rotar el shared secret RADIUS#
El shared secret RADIUS no es una contraseña de usuario: es la clave que cifra el campo User-Password en cada paquete RADIUS entre el NAS (FortiGate, AP, switch) y el servidor FreeRADIUS. El protocolo PAP transporta la contraseña del usuario XOR-cifrada con un hash MD5 derivado del shared secret y un vector aleatorio del paquete.
El problema es que ese cifrado es débil por diseño: si alguien captura tráfico RADIUS durante meses y después consigue el shared secret, puede desencriptar retroactivamente todas esas contraseñas. No hay perfect forward secrecy en RADIUS clásico.
A esto se suma que muchas instalaciones nunca cambiaron el secret del ejemplo de configuración. Si en tu clients.conf ves secret = testing123, no estás solo. Y si llevas años con el mismo valor, cualquier empleado que haya tenido acceso a la configuración lo conoce indefinidamente.
Desde el punto de vista regulatorio, tanto ISO 27001 como el ENS (Esquema Nacional de Seguridad) exigen rotación periódica de credenciales de infraestructura. El shared secret RADIUS entra en esa categoría.
El riesgo central: la coordinación atómica#
Aquí está el problema operativo real. FortiGate y FreeRADIUS deben tener el mismo secret en el mismo instante. No hay handshake de negociación, no hay período de gracia, no hay solapamiento posible: un paquete con el secret incorrecto simplemente produce un Access-Reject y el usuario no se autentica.
Si cambias FreeRADIUS primero y tardas 30 segundos en actualizar el FortiGate, durante esos 30 segundos nadie puede conectarse por VPN ni autenticarse en WiFi corporativo. Si lo haces al revés, igual.
Esta naturaleza atómica es lo que hace que muchos administradores pospongan la rotación indefinidamente. El objetivo de este proceso es reducir esa ventana de impacto a unos pocos segundos y tener un plan de reversión claro si algo falla.
Limitaciones antes de empezar#
Antes de generar el nuevo secret, hay restricciones del hardware que debes conocer:
Longitud máxima: algunos modelos FortiGate más antiguos aceptan secrets de hasta 32 caracteres. Otros permiten más, pero la interoperabilidad entre NAS y servidor puede verse afectada con secrets muy largos. El rango seguro es 20-32 caracteres.
Caracteres permitidos: ciertos NAS tienen problemas con caracteres especiales. Los caracteres @, # y ! son los más conflictivos, especialmente en firmwares antiguos o implementaciones que no escapan correctamente el valor antes de pasarlo al stack RADIUS. Usar únicamente caracteres alfanuméricos elimina esa clase de problemas.
Verificar antes: si tienes dudas sobre tu modelo específico de FortiGate, genera un secret de 28 caracteres alfanuméricos y pruébalo en un entorno de laboratorio antes de tocarlo en producción.
Generación del nuevo secret#
Un secret generado con entropía criptográfica real, sin caracteres problemáticos y de longitud adecuada:
openssl rand -base64 24 | tr -d '=+/' | head -c 28Esto genera 24 bytes aleatorios, los codifica en base64, elimina los caracteres =, + y /, y toma los primeros 28 caracteres. El resultado es alfanumérico puro con alta entropía.
Guarda este valor en tu gestor de contraseñas corporativo antes de continuar. Lo necesitarás en tres lugares distintos durante el proceso.
El proceso paso a paso#
1. Elegir la ventana de mantenimiento#
Trabaja en horario de baja actividad: entre semana a las 2-4h, o fin de semana por la mañana. Notifica con antelación si hay usuarios con VPN activa. El impacto real si todo va bien es de 5-15 segundos; si hay que revertir, puede ser de 2-3 minutos.
2. Preparar FreeRADIUS (sin aplicar todavía)#
Edita /etc/freeradius/3.0/clients.conf con el nuevo secret pero no recargues el servicio aún:
client fortigate {
ipaddr = IP-FORTIGATE
secret = NuevoSecretAqui
nastype = other
require_message_authenticator = no
}Ten el archivo abierto en un editor o el cambio listo con sed preparado. El objetivo es que entre el cambio en FortiGate y el reload de FreeRADIUS pasen los menos segundos posibles.
3. Cambiar el secret en FortiGate#
Desde la CLI de FortiGate:
config user radius
edit "servidor-radius"
set server IP-RADIUS
set secret NuevoSecretAqui
next
endO desde la interfaz web: User & Authentication → RADIUS Servers → editar el servidor → campo Secret.
En el momento en que aplicas este cambio, FortiGate empieza a enviar paquetes con el nuevo secret. FreeRADIUS todavía espera el antiguo: hay impacto desde este instante.
4. Recargar FreeRADIUS inmediatamente#
systemctl reload freeradiusreload es suficiente si FreeRADIUS soporta recarga de configuración en caliente (versiones >= 3.0). Si tienes dudas o el reload no funciona en tu versión:
systemctl restart freeradiusEl restart añade 1-2 segundos adicionales de indisponibilidad, pero garantiza que se carga la configuración limpia.
5. Verificar con radtest#
Antes de dar la rotación por finalizada, valida que el nuevo secret funciona de extremo a extremo:
radtest usuario contraseña+OTP IP-RADIUS 0 NuevoSecretAquiUna respuesta exitosa devuelve Access-Accept. Cualquier otra respuesta indica un problema.
6. Plan de reversión#
Si radtest falla o ves Access-Reject en los logs, revierte en el orden inverso:
- Restaura el secret antiguo en FortiGate (CLI o web)
- Restaura el
clients.confcon el secret antiguo systemctl reload freeradius- Confirma con
radtestusando el secret antiguo
Por eso es fundamental tener el secret anterior a mano durante toda la operación. No lo elimines del gestor de contraseñas hasta que la verificación post-rotación esté completa.
Gestión de múltiples clientes RADIUS#
Si tienes varios NAS (múltiples FortiGate, APs con autenticación 802.1X, switches con TACACS+ extendido a RADIUS), no los cambies todos a la vez.
El enfoque correcto:
- Rotar un cliente cada vez
- Completar la verificación de ese cliente antes de pasar al siguiente
- Si los clientes usan secrets diferentes (lo cual es recomendable), documenta qué secret usa cada uno
En clients.conf puedes tener entradas separadas por cliente con secrets distintos:
client fortigate-sede-madrid {
ipaddr = IP-FORTIGATE-MAD
secret = SecretMadrid28Chars
nastype = other
}
client ap-controller {
ipaddr = IP-WLAN-CONTROLLER
secret = SecretAPs28Chars
nastype = other
}Esto te permite rotar cada cliente de forma independiente y reduce el radio de impacto si algo sale mal.
Almacenamiento seguro del secret#
El clients.conf contiene secrets en claro, lo que lo convierte en un archivo crítico:
chown freerad:freerad /etc/freeradius/3.0/clients.conf
chmod 640 /etc/freeradius/3.0/clients.confEstos permisos aseguran que solo el proceso FreeRADIUS y root pueden leerlo. Verifica que tu sistema de backup no está exportando este archivo a un destino sin cifrado.
Para entornos con mayor madurez de seguridad, las alternativas son:
- HashiCorp Vault: el script de despliegue recupera el secret de Vault en tiempo de ejecución y escribe
clients.confconvault kv get. El archivo nunca se persiste en disco sin cifrado. - Bitwarden o KeePass corporativo: para equipos pequeños, guardar el secret en una bóveda compartida con acceso auditado es suficiente y mucho mejor que una hoja de cálculo o un archivo de texto.
Lo que no es aceptable: el secret en un documento de Word compartido por email, en un comentario de un ticket de soporte, o en el historial de bash de un administrador.
Verificación post-rotación#
Una vez completada la rotación, el proceso de verificación no termina con radtest. Los pasos completos:
Inmediatos (primeros 2 minutos):
# Verificar que no hay errores en el log de FreeRADIUS
tail -f /var/log/freeradius/radius.logBusca líneas con Access-Accept para autenticaciones reales. Cualquier Access-Reject inesperado puede indicar un cliente que todavía usa el secret antiguo.
Prueba funcional:
- Conectar un usuario de prueba a la VPN y verificar que autentica correctamente
- Si tienes WiFi 802.1X, conectar un dispositivo de prueba a la red corporativa
- Verificar que las autenticaciones aparecen en los logs con el timestamp correcto
Monitorización los primeros 15 minutos:
# Si usas fail2ban para proteger RADIUS
tail -f /var/log/fail2ban.logUn pico de Access-Reject seguido de bloqueos en fail2ban puede indicar que algún dispositivo (impresora, teléfono corporativo, servicio automatizado) no se actualizó con las nuevas credenciales y está bloqueando IPs legítimas.
Conclusión#
La rotación del shared secret RADIUS no es complicada técnicamente, pero requiere coordinación y velocidad en los pasos críticos. El riesgo no está en el proceso en sí, sino en hacerlo de forma improvisada o sin tener claro el plan de reversión.
Con este procedimiento: ventana de impacto de menos de 15 segundos si todo va bien, reversión en menos de 3 minutos si algo falla, y el proceso documentado para repetirlo cada 6-12 meses como parte del calendario de rotación de credenciales de infraestructura.
El secret testing123 que llevas años usando puede esperar hasta esta noche. Pero no más.