Hardening del management plane (F5)

Contenido complementario

Combina lo visto en Securing BIG-IP (CAB1, 301a) con buenas prácticas generales. Revisa siempre las recomendaciones de seguridad de F5 para tu versión.

Pendiente: validar en el lab

Este contenido no salió de mis clases. Probar estos comandos y pasos en BIG-IP VE antes de usarlos en un trabajo real, y corregir lo que difiera en mi versión.

Resumen

El BIG-IP suele estar en el borde de la red, así que proteger su administración es crítico. La idea es simple: la gestión solo desde una red aislada y con usuarios nominales y roles mínimos, las self IPs externas cerradas, la autenticación centralizada, los logs fuera del equipo, el software al día y los respaldos cifrados y fuera del BIG-IP.

Requisitos previos

• Red de gestión aislada (fuera de banda)
• Servidor de autenticación (AD/TACACS+), syslog/SIEM y NTP
• Inventario de self IPs y virtual servers expuestos
• Acceso por consola por si te quedas fuera

Conceptos clave

Control	Qué protege
sys httpd allow / sys sshd allow	Quién llega a la GUI y a SSH
Management Port Rules	Firewall del puerto mgmt
Port Lockdown	Servicios en las self IPs
Roles + autenticación remota	Quién hace qué
Password policy	Contraseñas y bloqueo por intentos
SNMPv3, syslog remoto, NTP	Monitoreo seguro y trazabilidad
UCS cifrado fuera del equipo	Recuperación sin exponer llaves

Configuración (Ejemplo, Lab CBT Nuggets)

1. Limitar el acceso a la gestión

tmsh modify sys httpd allow replace-all-with { 192.168.121.0/24 }
tmsh modify sys sshd allow replace-all-with { 192.168.121.0/24 }
tmsh modify sys httpd auth-pam-idle-timeout 900
tmsh modify sys sshd banner enabled banner-text "Acceso solo autorizado"

GUI: System > Platform > Security > Management Port Rules (con logging).

2. Cerrar las self IPs externas

tmsh modify net self self_external allow-service none

3. Usuarios y autenticación

• Autenticación remota (TACACS+/AD) con Remote Role Groups (Usuarios, roles y autenticación remota).
• Una cuenta local de emergencia; sin cuentas compartidas.
• Password policy con longitud mínima, vencimiento y bloqueo por intentos.

4. Monitoreo seguro

Primero mira el nombre del objeto de la comunidad public con tmsh list sys snmp communities (suele ser comm-public) y bórralo por ese nombre:

tmsh list sys snmp communities
tmsh modify sys snmp communities delete { comm-public }
tmsh modify sys syslog remote-servers add { siem1 { host 10.10.10.50 remote-port 514 } }
tmsh modify sys ntp servers add { pool.ntp.org }

5. SSL de las aplicaciones

Perfiles basados en clientssl-secure, sin TLS 1.0/1.1, ciphers fuertes (Certificados y Client SSL).

6. Respaldos y parches

• UCS cifrado, diario o antes de cada cambio, copiado fuera del equipo (Backups (UCS) y QKview).
• Revisa las notificaciones de seguridad trimestrales de F5 y actualiza (Upgrades y hotfixes).
• Sube un QKview a iHealth periódicamente.

7. Quitar lo que no se usa

Desprovisiona módulos sin uso y borra objetos huérfanos (iHealth > Config Explorer > Unused Objects).

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
tmsh list sys httpd allow / tmsh list sys sshd allow	Solo la red de gestión	Paso 1
tmsh list net self	allow-service none en externas	Paso 2
tmsh list sys snmp communities	Sin public	Paso 4
Escaneo desde Internet a las self IPs	Solo ICMP responde	Revisa Port Lockdown
iHealth	Sin vulnerabilidades críticas pendientes	Actualiza

Errores comunes

Me quedé sin acceso a la GUI

• Causa: httpd allow sin tu red.
• Solución: por consola, tmsh modify sys httpd allow replace-all-with { ALL } y vuelve a restringir bien.

La autenticación remota falló y nadie puede entrar

• Causa: servidor caído sin cuenta local de emergencia.
• Solución: entra por consola con root; mantén siempre una cuenta break-glass.

El monitoreo dejó de funcionar al quitar public

• Causa: el sistema de monitoreo usaba esa comunidad.
• Solución: configúralo con SNMPv3 o una comunidad nueva restringida por origen.