El puerto más privilegiado del rack es el que nadie vigila
iLO e iDRAC pueden apagar, reinstalar o leer cualquier servidor. Cómo aislamos los controladores de gestión en una red separada y los bastionamos.

Todo servidor moderno lleva dentro un segundo ordenador más pequeño: el controlador de gestión. En los servidores HPE es iLO, en los servidores Dell es iDRAC, y en los chasis de blades hay un Onboard Administrator por encima de los blades. A menudo se trata como una comodidad para reinicios remotos. En realidad es el componente más privilegiado del rack, y merece que se diseñe en torno a él.
Qué puede hacer un controlador de gestión
Todo el bastionado que haga dentro del sistema operativo es irrelevante si las personas equivocadas pueden alcanzar el controlador.
Regla uno: su propio puerto, su propia red
La mayoría de los servidores pueden ejecutar el controlador en un puerto de gestión dedicado o compartido con uno de los puertos de red principales. Compartir es cómodo, porque ahorra un cable y un puerto de switch. También coloca el controlador en la misma red que el tráfico ordinario del servidor, que es exactamente donde no debería estar.
Nosotros damos a cada controlador su propio puerto físico, su propio cable y su propia conmutación, en un espacio de direcciones privado que nunca se enruta hacia o desde ninguna red de cliente y nunca se anuncia a internet. Eso es lo que entendemos por una red de gestión aislada. Una máquina de cliente, incluso una comprometida, no tiene camino hacia ningún controlador. Los ingenieros llegan a la red de gestión solo a través de nuestros propios gateways VPN y jump hosts.
Puede comprobar la elección actual desde el propio controlador. En iDRAC:
racadm get iDRAC.NIC.Selection # Dedicated, or one of the LOM ports
racadm get iDRAC.IPv4 # address, gateway, DHCP state
En cualquier servidor con las herramientas IPMI instaladas, desde el sistema operativo:
ipmitool lan print 1
Eso muestra la dirección del controlador, la VLAN y los cipher suites que acepta por la red.
Regla dos: apague lo que no use
Los controladores vienen de fábrica con varias vías de entrada, y cada una es superficie de ataque. Revíselas en cada máquina:
- IPMI over LAN. Más antiguo y menos seguro que las interfaces web y SSH del controlador. Si nada en sus herramientas lo necesita, desactívelo (
racadm get iDRAC.IPMILan.Enablemuestra el estado en iDRAC). Si algo lo necesita, asegúrese de que solo se aceptan cipher suites fuertes. - Hora y registro. Apunte el controlador a sus fuentes de tiempo, y envíe sus logs y traps SNMP a sus colectores de gestión.
Regla tres: licéncielo correctamente
El IPMI básico le da control de alimentación y poco más. Los niveles con licencia son lo que hace útil un controlador para operaciones reales: consola remota que funciona de forma fiable, medios virtuales para instalaciones remotas, telemetría completa del hardware y gestión del firmware. Nosotros operamos iDRAC Enterprise con licencia Datacenter en los servidores Dell, iLO Advanced en los servidores HPE y Onboard Administrators redundantes en cada chasis de blades. Un servidor al que no se puede llegar por completo a través de su controlador es un servidor que necesita a una persona delante, y esa es la forma cara de operar un datacenter.
Configure todo el chasis de una vez
En los chasis de blades HPE hay una vía mejor. El Onboard Administrator puede pasar un script de configuración al iLO de cada blade a través del backplane del chasis en una sola operación, usando el formato de scripting RIBCL de HPE mediante el comando HPONCFG. El chasis se autentica él mismo ante cada iLO, así que no hacen falta credenciales por blade, lo que significa que un blade montado en el rack esta mañana, todavía sin contraseña propia, puede estar completamente configurado esta tarde.
Una pasada típica para todo el chasis fija la licencia, añade una cuenta de gestión, fija el timeout de sesión, apunta la hora y SNMP a los colectores de gestión, y va seguida de una segunda pasada que relee cada ajuste para verificarlo. Dell tiene el equivalente en el scripting de racadm y en los perfiles de configuración de servidor. Sea cual sea su fabricante, el principio es el mismo: una configuración escrita, aplicada de forma idéntica, verificada releyéndola.
Dar acceso a los clientes sin romper el modelo
Los clientes con servidores dedicados a veces necesitan su propio acceso a la consola. Por defecto nuestros ingenieros usan la consola remota en nombre del cliente, a cualquier hora. Cuando un cliente necesita acceso directo a iLO o iDRAC, se lo proporcionamos a través de una VPN dedicada, de modo que el propio controlador se queda en la red de gestión aislada y solo el controlador de ese cliente es alcanzable a través de ella.
Compruebe sus propios controladores
- ¿Está cada controlador en un puerto dedicado, o algunos comparten un puerto de datos?
- ¿Se puede alcanzar algún controlador desde una red de cliente o desde internet?
- ¿Está IPMI over LAN activado en algún sitio donde no hace falta?
- ¿Sigue activa alguna cuenta de fábrica?
- ¿Llegan los logs y traps de los controladores a su monitorización?
- ¿Hay una configuración escrita contra la que se compruebe cada controlador?
Si quiere que su hardware se gestione con los controladores guardados bajo llave donde deben estar, con gusto hablamos. Hable con un ingeniero
Related (rows[1])
Relacionado: Montaje en rack, onboarding de blades, controladores de gestión · El hardening baseline de cada host · DCIM: cada objeto, puerto, cable y dirección registrados
Publicado el 6 de agosto de 2026.
Todas las notas de campo