Asegurar un SuperMicro IPMI BMC

17

Recientemente adquirí una placa base SuperMicro X8DTU-F, que tiene un BMC incorporado, que básicamente ejecuta el sistema IPMI. Resulta ser un pequeño sistema Linux que se ejecuta en un procesador ARM.

Desafortunadamente, está ejecutando una gran cantidad de software, gran parte del cual no necesito, y no tengo la capacidad de ponerlo detrás de un firewall. Sin embargo, sí quiero la funcionalidad IPMI. ¿Alguien que haya usado uno de estos tiene algunas sugerencias específicas sobre cómo asegurarlo? Se inicia desde lo que es esencialmente un sistema de archivos ROM, y ni siquiera parece haber ganchos para apagar ninguno de los diversos servidores que ejecuta ...

También me interesaría cómo podría verificar la lista de nombres y contraseñas que se pueden utilizar para acceder al sistema a través de todos los diversos servicios. El valor predeterminado es ADMIN/ ADMIN, pero ninguno de los archivos en / conf o / etc tiene 'ADMIN', lo que me preocupa. Hay /conf/shadowy /conf/webshadowarchivos, con misteriosas ID de 'prueba' en ellos, lo que tampoco me hace sentir particularmente cómodo.

Curt J. Sampson
fuente
Todavía tengo que encontrar una correlación entre el contenido de shadow, webshadow y lo que en realidad son usuarios válidos. Los nuevos usuarios agregados a través de la administración de BMC no aparecen en estos archivos. Además, los usuarios "anónimo", "test1", "test2" tienen un shell que no existe en el sistema de archivos.
Daniel Lawson
2
Consulte también la guía de Dan Farmer en IPMI Security Best Practices . Publicó un artículo reciente que detalla algunos problemas de seguridad significativos con IPMI titulado ipmi: tren de carga al infierno .
Stefan Lasiewski
1
Gracias por ese gran enlace. El breve resumen de los problemas de seguridad se encuentra en fish2.com/ipmi/itrain-gz.html y el breve resumen es "estás completamente jodido". Suspiro.
Curt J. Sampson el

Respuestas:

6

Usar /conf/crontab, como señaló dlawson, me parece una excelente idea. Esto me permite ejecutar un script una vez por minuto que garantiza que todo, excepto http y ssh, se apague:

/etc/init.d/cdserver stop
/etc/init.d/fdserver stop
/etc/init.d/cim_sfcb stop
/etc/init.d/webgo stop

Eso todavía me deja con un servidor web con control de acceso basado en contraseña (no veo forma de validar los certificados del cliente) y quién sabe qué vulnerabilidades remotas. Apagarlo cuando no lo estoy usando (que es la mayoría de las veces) parece una solución razonable; agregar una entrada crontab para apagarlo cada cinco o diez minutos detectaría aquellos casos en los que alguien olvida cerrarlo cuando haya terminado.

El demonio ssh es una versión de dropbear que parece estar bastante modificada. Lee los nombres de usuario y las contraseñas de texto sin formato /conf/PMConfig.dat(que también utiliza el servidor web), registra cualquier nombre y contraseña válidos como usuario raíz e ignora el ~/.ssh/authorized_keysarchivo. Este último problema es molesto; te obliga a permitir el inicio de sesión con contraseña y abre la posibilidad de puertas traseras dependiendo de dónde obtiene todos sus nombres y contraseñas.

Así que ese es el dilema que enfrenta: ¿cuánto confía realmente en este demonio ssh modificado instalado en un sistema que obviamente fue diseñado por desarrolladores sin experiencia en seguridad? No mucho, dada la cantidad de fragmentos rotos de cruft que he visto en sus guiones de shell. Hay convenciones de nomenclatura inusuales (/etc/rc?.d/sshd es un enlace simbólico a /etc/init.d/ssh), una gran cantidad de código que parece no estar usado y funciones en el script de inicio ssh, como el /conf/portcfg_ssharchivo e incluso el restartcomando están completamente rotos. (No intente usar estos; sshd no se reiniciará y se perderá a menos que tenga un inicio de sesión existente. Reiniciamos el BMC y terminamos teniendo que volver a actualizarlo).

La mejor opción que se me ocurre, si alguien va a usar la cosa, es comenzar ssh en un puerto alternativo usando un trabajo cron, por lo que al menos es menos probable que aparezca en un escaneo de puertos.

El componente final son los puertos de administración de red IPMI; No puedo ver cómo apagarlos.

Curt J. Sampson
fuente
La mayoría de sus inquietudes con respecto a las modificaciones probablemente no sean un problema. Dropbear usa pam, que usa libpamipmi para autenticación; no he visto ninguna evidencia de que realmente lea las contraseñas de texto sin cifrar directamente. Libpamipmi hará una llamada ipmi a la pila de ipmi, y eso podría estar leyendo contraseñas de texto sin formato, pero mi punto es que no parece que el demonio dropbear haya sido arruinado. Sin embargo, me interesaría escuchar cualquier prueba definitiva que tenga de lo contrario.
Daniel Lawson
Bueno, sabemos que se ha roto porque no hay forma de a) usar claves, en lugar de contraseñas, yb) deshabilitar la autenticación de contraseña.
Curt J. Sampson
6

Idealmente, su red de administración sería una red diferente a su otra red, o al menos una vlan diferente con acceso de enrutamiento limitado.

Sin embargo, estos sistemas realmente no ejecutan tantos servicios:

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
555/tcp  open  dsf
5120/tcp open  unknown
5900/tcp open  vnc
5988/tcp open  unknown
MAC Address: 00:30:48:D9:3A:71 (Supermicro Computer)

(y UDP / 623 para IPMI)

La mayoría de estos son necesarios si desea realizar algún tipo de gestión remota. Si no desea hacer una administración remota, entonces debería considerar no habilitar el controlador IPMI en absoluto, o comprar una placa X9DTU (la -F denota "BMC incorporado")

Si desea realizar una gestión remota completa, no puede ejecutar sus controladores IPMI en una red diferente y aún así desea deshabilitar algún acceso, siempre puede hacer que el controlador IPMI ejecute comandos de iptables. Puede ejecutar un inicio de sesión ssh para ejecutar los comandos, o pedirle a Supermicro el devkit para BMC y crear una nueva imagen con un script personalizado de iptables.

ACTUALIZAR

Eché otro vistazo a nuestros sistemas aquí, y el sistema de archivos / conf está montado rw. Ninguno de los scripts de inicio llamó a nada directamente en / conf (que pude ver), pero hay un archivo crontab. Entonces, supongo que podría copiar en un script de iptables y editar / conf / crontab para llamarlo en algún intervalo adecuado. Desea que se ejecute lo antes posible en el inicio de BMC, pero no necesariamente se ejecuta cada minuto. O tal vez no te importa.

Daniel Lawson
fuente
Me encantaría tener una red separada para la administración, pero desafortunadamente esto va al centro de datos de otra persona, y no puedo tener eso. En cuanto a la administración, todo lo que realmente quiero es https y ssh.
Curt J. Sampson
¿Nunca, nunca querrás KVM sobre lan?
Daniel Lawson
Podría tener una unidad de firewall separada frente a su host en DC. Eso resolvería un poco el problema. ¿Le ha pedido ayuda al soporte de Supermicro en esto? Los he encontrado bastante receptivos
Daniel Lawson,
No. No necesito KVM a través de LAN, ya que el BIOS, Grub y el kernel de Linux son compatibles con una consola en serie.
Curt J. Sampson
4

Una cosa a tener en cuenta al asegurar un Supermicro IPMI es el servidor ssh. Las versiones anteriores del código X8SIL-F IPMI aceptaban conexiones ssh sin importar la contraseña que se les proporcionara. El software verificará la contraseña y rechazará o aceptará la conexión, pero hubo una breve ventana para crear puertos ssh hacia adelante. Debido a esto, la gente recibía quejas de spam / abuso por sus IPMI . Para la placa base X8SIL-F, la versión de firmware 2.60 IPMI solucionó el problema (podría haberse solucionado antes, la entrada del registro de cambios de 2.54 parece que podría ser).

Un segundo problema es un usuario anónimo con una contraseña predeterminada. El usuario anónimo parece estar solucionado en la versión de firmware 2.22.

ahogarse
fuente
2

Hay un pequeño truco para habilitar HTTPS para la interfaz web de IPMI.

Si su firmware IPMI lo admite (mi firmware 2.04 para X8DTH-iF lo admite), al principio, podría habilitar el acceso HTTPS yendo a Configuración -> SSL, cargando dos archivos PEM (certificado y clave privada) y, en segundo lugar, manualmente reinicie su módulo IPMI.

Finalmente, puede acceder a la interfaz web de IPMI mediante https: // bmc-ip-or-hostname / . No puedo decir que HTTPS funciona más lento que HTTP.

AntonioK
fuente
0

¿Alguno de ustedes ha tratado de asegurar la cosa con iptables? Parece que iptables está instalado, y quiero hacer un conjunto de reglas que niegue que todo sea aceptado por algunas IP confiables para hacerlo un poco más seguro ... Pero como leí anteriormente, no se están leyendo scripts de / config. ¿Es crontab la única opción? ¿Y qué pasa si arruinaste iptables?


fuente
1
Como dije anteriormente, es mucho mejor asegurar su controlador IPMI externamente: ya sea al tenerlo en una red física o vlan completamente separada, o bien protegido por un firewall de borde. Este modelo particular de controlador IPMI / BMC ejecuta Linux, lo que luego le lleva a la idea de que puede asegurarlo con iptables. Sin embargo, la realidad es que la gran mayoría de BMC / IPMI / lo que sea que los llame no tiene mucho, ni nada, en el camino del firewall, por lo que no debe confiar en él. Ahórrese la molestia y trate su red IPMI como privada, segura y no enrutada.
Daniel Lawson
1
No estoy de acuerdo con que sea "mejor" asegurar su controlador IPMI externamente; los cortafuegos y similares son más propensos a fallas de seguridad que un host debidamente asegurado en primer lugar. Sin embargo, si tiene la capacidad de usar una red separada, eso es algo bueno, y en el caso de dispositivos IPMI como este, parece ser casi esencial.
Curt J. Sampson
0

¿Cómo viste el sistema de archivos? Si hago telnet al puerto 22, puedo ver que dropbear se está ejecutando, pero si intento utilizar SSH con varios nombres de usuario, no se solicita una contraseña. Agregué un nuevo usuario con privilegios de administrador, pero SSH tampoco responderá por ese usuario. Estoy usando una placa base Supermicro X7SPA-HF que tiene un chip Winbond Hermon IPMI 2.0, revisión de firmware 01.29, tiempo de construcción 2009-12-31.


fuente
2
Hice ssh -v, para ver qué estaba pasando, vi que estaba intentando la autenticación de clave pública. Lo puse a trabajar deshabilitando eso.
Ahora estoy en ATEN SMASH-CLP System Management Shell, versión 1.00