Sécurisation d'un SuperMicro IPMI BMC

J'ai récemment acquis une carte mère SuperMicro X8DTU-F, qui a un BMC intégré, qui exécute essentiellement le système IPMI. Il s'agit d'un petit système Linux fonctionnant sur un processeur ARM.

Malheureusement, il exécute une cargaison de logiciels, dont je n'ai pas besoin en grande partie, et je n'ai pas la possibilité de le mettre derrière un pare-feu. Cependant, je veux la fonctionnalité IPMI. Est-ce que quelqu'un qui a utilisé l'un de ces outils a des suggestions spécifiques sur la façon de sécuriser la chose? Il démarre à partir de ce qui est essentiellement un système de fichiers ROM, et il ne semble même pas y avoir de hooks pour éteindre les différents serveurs qu'il exécute ...

Je serais également intéressé par la façon dont je pourrais vérifier la liste des noms et mots de passe qui peuvent être utilisés pour accéder au système via tous les différents services. La valeur par défaut est ADMIN/ ADMIN, mais aucun des fichiers dans / conf ou / etc ne contient 'ADMIN', ce qui m'inquiète plutôt. Il y a /conf/shadowet /conf/webshadowfichiers, avec ID « test » mystérieux en eux, ce qui ne fait pas me sentir particulièrement à l' aise non plus .

L'utilisation /conf/crontab, comme l'a souligné dlawson, me semble une excellente idée. Cela me permet d'exécuter un script une fois par minute qui garantit que tout sauf http et ssh est arrêté:

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

Cela me laisse encore un serveur Web avec un contrôle d'accès basé sur un mot de passe (je ne vois aucun moyen de le faire valider les certificats clients) et qui sait quelles vulnérabilités à distance. Le désactiver lorsque je ne l'utilise pas (ce qui est la plupart du temps) semble être une solution raisonnable; l'ajout d'une entrée crontab pour le fermer toutes les cinq ou dix minutes permettrait de détecter les cas où quelqu'un oublie de le fermer lorsqu'il a terminé.

Le démon ssh est une version de dropbear qui semble être assez fortement modifiée. Il lit les noms d'utilisateur et les mots de passe en texte brut /conf/PMConfig.dat(qui sont également utilisés par le serveur Web), connecte tout nom et mot de passe valide en tant qu'utilisateur root et ignore le ~/.ssh/authorized_keysfichier. Ce dernier problème est ennuyeux; il vous oblige à autoriser les connexions par mot de passe et ouvre la possibilité de backdoors selon d'où-tout il obtient ses noms et mots de passe.

Voilà donc le dilemme auquel vous êtes confronté: à quel point faites-vous vraiment confiance à ce démon ssh modifié installé sur un système qui a été assez évidemment conçu par des développeurs naïfs de sécurité? Pas grand-chose du tout, étant donné le nombre de morceaux de cruches cassés que j'ai vus dans leurs scripts shell. Il existe des conventions de dénomination inhabituelles (/etc/rc?.d/sshd est un lien symbolique vers /etc/init.d/ssh), une énorme quantité de code qui semble inutilisée et des fonctionnalités dans le script de démarrage ssh, telles que le /conf/portcfg_sshfichier et même la restartcommande sont entièrement cassés. (N'essayez pas de les utiliser; sshd ne redémarrera pas et vous serez foutu à moins que vous n'ayez une connexion existante. Nous avons redémarré le BMC et avons finalement dû le reflasher.)

La meilleure option à laquelle je peux penser, si l'on veut utiliser la chose, est de démarrer ssh sur un autre port en utilisant une tâche cron, donc au moins, il est moins susceptible d'apparaître dans un portscan.

Le dernier composant est les ports de gestion de réseau IPMI; Je ne vois pas comment les désactiver.

Idéalement, votre réseau de gestion serait un réseau différent de votre autre réseau, ou au moins un vlan différent avec un accès routé limité.

Cependant, ces systèmes n'exécutent pas vraiment autant de services:

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)

(et UDP / 623 pour IPMI lui-même)

La plupart d'entre eux sont nécessaires si vous souhaitez effectuer n'importe quel type de gestion à distance. Si vous ne voulez pas faire de gestion à distance, vous devriez envisager de ne pas activer le contrôleur IPMI du tout, ou d'acheter une carte X9DTU à la place (le -F indique "BMC intégré")

Si vous souhaitez effectuer une gestion à distance complète, ne pouvez pas exécuter vos contrôleurs IPMI sur un réseau différent et souhaitez toujours désactiver certains accès, vous pouvez toujours demander au contrôleur IPMI d'exécuter les commandes iptables. Vous pouvez créer un script pour une connexion ssh pour exécuter les commandes, ou demander à Supermicro le devkit pour le BMC et créer une nouvelle image avec un script iptables personnalisé.

MISE À JOUR

J'ai jeté un coup d'œil à nos systèmes ici, et le système de fichiers / conf est monté rw. Aucun des scripts d'initialisation n'a appelé quoi que ce soit directement dans / conf (que j'ai pu voir), mais il existe un fichier crontab. Donc, je suppose que vous pouvez copier dans un script iptables et éditer / conf / crontab pour l'appeler à un intervalle approprié. Vous souhaitez qu'il soit exécuté dès que possible sur l'initialisation BMC, mais vous ne voulez pas nécessairement qu'il s'exécute toutes les minutes. Ou peut-être que vous ne vous en souciez pas.

Une chose à considérer lors de la sécurisation d'un Supermicro IPMI est le serveur ssh. Les versions plus anciennes du code IPMI X8SIL-F acceptaient les connexions ssh quel que soit le mot de passe donné. Le logiciel vérifierait alors le mot de passe et rejetterait ou accepterait la connexion, mais il y avait une brève fenêtre pour créer des ports ssh vers l'avant. Les gens recevaient des plaintes de spam / abus pour leurs IP IPMI à cause de cela . Pour la carte mère X8SIL-F, la version du firmware 2.60 IPMI a résolu le problème (il a peut-être été corrigé plus tôt, l'entrée du journal des modifications de 2.54 semble être la même).

Un deuxième problème est un utilisateur anonyme avec un mot de passe par défaut. L'utilisateur anonyme semble être corrigé dans la version 2.22 du firmware.

Il y a une petite astuce pour activer HTTPS pour l'interface Web d'IPMI.

Si votre micrologiciel IPMI le prend en charge (mon micrologiciel 2.04 pour X8DTH-iF le prend en charge), vous pouvez, dans un premier temps, activer l'accès HTTPS en accédant à Configuration -> SSL, en téléchargeant deux fichiers PEM (certificat et clé privée) et, en second lieu, manuellement redémarrez votre module IPMI.

Enfin, vous pouvez accéder à l'interface Web d'IPMI par https: // bmc-ip-or-hostname / . Je ne peux pas dire que HTTPS fonctionne plus lentement que HTTP.

Avez-vous essayé de sécuriser la chose avec iptables? Il semble qu'iptables soit installé, et je veux créer un ensemble de règles qui refuse tout ce qui est accepté par quelques IP de confiance pour le rendre un peu plus sécurisé ... Mais comme je l'ai lu ci-dessus, aucun script n'est lu depuis / config. Crontab est-il la seule option? Et si vous avez foiré iptables?

Comment avez-vous vu le système de fichiers? Si je telnet sur le port 22, je peux voir que dropbear fonctionne, mais si j'essaie de SSH avec différents noms d'utilisateur, il ne demande pas de mot de passe. J'ai ajouté un nouvel utilisateur avec des privilèges d'administrateur, mais SSH ne répondra pas non plus pour cet utilisateur. J'utilise une carte mère Supermicro X7SPA-HF qui a une puce Winbond Hermon IPMI 2.0, révision du firmware 01.29, temps de construction 2009-12-31.