Sécurisation d'un SuperMicro IPMI BMC

17

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 .

Curt J. Sampson
la source
Je n'ai pas encore trouvé de corrélation entre le contenu de shadow, webshadow et ce qui sont réellement des utilisateurs valides. Les nouveaux utilisateurs ajoutés via la gestion BMC n'apparaissent pas dans ces fichiers. De plus, les utilisateurs "anonymes", "test1", "test2" ont un shell qui n'existe pas sur le système de fichiers.
Daniel Lawson
2
Voir également le guide de Dan Farmer sur IPMI Security Best Practices . Il a publié un article récent détaillant certains problèmes de sécurité importants avec IPMI intitulé ipmi: train de marchandises en enfer .
Stefan Lasiewski
1
Merci pour ce super lien. Le court résumé des problèmes de sécurité se trouve sur fish2.com/ipmi/itrain-gz.html et le très court résumé est: "vous êtes complètement foutu". Soupir.
Curt J. Sampson

Réponses:

6

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.

Curt J. Sampson
la source
La plupart de vos préoccupations concernant les modifications ne sont probablement pas un problème. Dropbear utilise pam, qui utilise libpamipmi pour l'authentification - je n'ai vu aucune preuve qu'il lit réellement les mots de passe en texte clair directement. Libpamipmi fera un appel ipmi à la pile ipmi, et cela pourrait bien être la lecture de mots de passe en texte clair, mais mon point est qu'il ne semble pas que le démon dropbear ait été foiré. Je serais intéressé à entendre dans toute preuve définitive que vous avez le contraire cependant.
Daniel Lawson
Eh bien, nous savons qu'il a été brisé en ce sens qu'il n'y a aucun moyen a) d'utiliser des clés plutôt que des mots de passe et b) de désactiver l'authentification par mot de passe.
Curt J. Sampson
6

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.

Daniel Lawson
la source
J'adorerais avoir un réseau distinct pour la gestion, mais malheureusement, cela va dans le centre de données de quelqu'un d'autre, et je ne peux pas l'avoir. Quant à la gestion, tout ce que je veux vraiment, c'est https et ssh.
Curt J. Sampson
Vous ne voudrez plus jamais de KVM sur LAN?
Daniel Lawson
Vous pouvez avoir une unité de pare-feu distincte devant votre hôte au DC. Cela résoudrait quelque peu le problème. Avez-vous demandé de l'aide à Supermicro à ce sujet? Je les ai trouvés assez réactifs
Daniel Lawson
Non. Je n'ai pas besoin de KVM sur LAN puisque le BIOS, Grub et le noyau Linux prennent tous en charge une console série.
Curt J. Sampson
4

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.

ddrown
la source
2

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.

AntonioK
la source
0

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?


la source
1
Comme je l'ai dit plus tôt, il est de loin préférable de sécuriser votre contrôleur IPMI en externe: soit en le disposant sur un réseau physique ou VLAN complètement séparé, soit sécurisé par un pare-feu frontalier. Ce modèle particulier de contrôleur IPMI / BMC arrive à exécuter linux, ce qui vous invite à penser que vous pouvez le sécuriser avec iptables. La réalité est, cependant, que la grande majorité des BMC / IPMI / quoi que ce soit d'eux n'ont pas beaucoup, ou quoi que ce soit, en termes de pare-feu, et donc vous ne devriez pas vous en remettre à cela. Épargnez-vous les tracas et traitez votre réseau IPMI comme privé, sécurisé et non routé.
Daniel Lawson
1
Je ne suis pas d'accord qu'il est "préférable" de sécuriser votre contrôleur IPMI en externe; les pare-feu et similaires sont plus sujets aux défaillances de sécurité qu'un hôte correctement sécurisé en premier lieu. Cependant, si vous avez la possibilité d'utiliser un réseau séparé, c'est une bonne chose, et dans le cas d'appareils IPMI comme celui-ci, cela semble presque essentiel.
Curt J. Sampson
0

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.


la source
2
J'ai fait ssh -v, pour voir ce qui se passait, j'ai vu qu'il tentait l'authentification par clé publique. Je l'ai fait fonctionner en désactivant cela.
Je suis maintenant dans ATEN SMASH-CLP System Management Shell, version 1.00