2 points par GN⁺ 2024-09-04 | 1 commentaires | Partager sur WhatsApp
  • Même après la convergence des serveurs vers du matériel polyvalent proche des PC, la gestion hors bande des pannes, du démarrage et de l’installation à distance reste une fonction clé qui distingue les clients des serveurs
  • IPMI n’est pas un nom de produit, mais une spécification ; les systèmes de gestion propres aux fournisseurs, comme HP iLO et Dell DRAC, recoupent IPMI tout en ayant chacun leur histoire et leurs extensions
  • IPMI fonctionne sur un BMC et fournit à la fois des interfaces hors bande réseau ou série, et une interface in-band via un pilote du système d’exploitation
  • Les implémentations réelles offrent interface web, SSH, VNC, commandes sur UDP 623, console distante, média virtuel, contrôle des capteurs, de l’alimentation, des ventilateurs et du watchdog, mais sont particulièrement vulnérables à l’exposition de sécurité
  • Intel ME et Intel AMT sont des technologies similaires côté PC client, mais l’idée répandue selon laquelle un accès réseau sideband serait possible sur les appareils grand public est généralement fausse, en raison des conditions liées à AMT et vPro

Jusqu’à ce que les serveurs deviennent de « gros ordinateurs »

  • Le modèle client-serveur est issu de l’évolution de l’informatique en temps partagé, où plusieurs terminaux étaient connectés à un même ordinateur
  • Les terminaux n’avaient pas besoin d’avoir la même architecture que l’ordinateur, et cette perception s’est prolongée dans les premiers systèmes client-serveur
  • Au milieu des années 1990, la révolution du PC a créé côté client une monoculture WinTel, mais jusque dans les années 2000 il restait courant que les serveurs utilisent des systèmes d’exploitation et des architectures distincts
    • Le couple SPARC et Solaris était largement utilisé sur les serveurs
    • Les architectures de mini-ordinateurs d’IBM et plusieurs systèmes d’exploitation constituaient aussi d’importantes plateformes serveur
    • Java a contribué aux applications d’entreprise en permettant la réutilisation de code entre des backends Solaris/SPARC et des clients Windows/x86
  • Avec le temps, les architectures dédiées aux serveurs sont devenues de moins en moins compétitives face aux architectures PC en coût et en performance
  • Les logiciels serveur sont eux aussi passés d’un modèle centré sur la montée en charge verticale et la haute disponibilité à un modèle de mise à l’échelle horizontale et d’exigences de fiabilité assouplies, réduisant l’avantage des ordinateurs de classe enterprise
  • Aujourd’hui, les différences des serveurs résident surtout dans le SMP multi-socket, NUMA, les contrôleurs et topologies de stockage complexes, ainsi que les fonctions de gestion hors bande

À quoi sert la gestion hors bande

  • La gestion hors bande permet d’accéder à un serveur via un ordinateur de gestion séparé, même lorsque le système d’exploitation ou des composants génériques ne fonctionnent pas correctement
  • SSH est l’exemple typique d’une gestion in-band fournie par un logiciel au-dessus du système d’exploitation
  • La gestion hors bande repose sur une pile matérielle et logicielle distincte et, traditionnellement, ne nécessitait pas la coopération du système d’exploitation ni du CPU
  • Aujourd’hui, cette fonction se voit le mieux dans la console distante des serveurs
    • Elle se comporte comme un IP KVM intégré, permettant de manipuler le serveur comme si un écran et un clavier locaux étaient connectés
    • La fonction de « média virtuel » permet de téléverser un fichier ISO et de le faire apparaître comme un périphérique physique, ce qui est utile pour installer un système d’exploitation
  • Ces fonctions ne sont pas nouvelles, et l’on trouve des fonctions similaires tout au long de l’histoire de l’informatique d’entreprise
  • Les serveurs relativement modernes intégraient généralement plusieurs niveaux de fonctions de gestion
    • Une interface opérateur locale, comme un écran LCD ou des LED affichant l’état matériel
    • Une console série donnant accès au bootloader initial et à un système permanent de gestion bas niveau
    • Un système de gestion de plus haut niveau pour administrer à distance la charge de travail de la machine
  • Aujourd’hui encore, les indications de panne en façade et les fonctions de gestion série subsistent, mais l’étendue des composants redondants remplaçables à chaud est moindre qu’auparavant

La relation entre IPMI et BMC

  • IPMI n’est pas un produit précis, mais la spécification Intel IPMI
  • Les principaux fournisseurs de serveurs disposent généralement de leur propre implémentation d’IPMI, avec des noms comme HP iLO et Dell DRAC
    • Certains de ces systèmes existaient avant IPMI, si bien qu’il n’est pas exact de les appeler simplement « IPMI »
    • Les fabricants plus récents utilisent souvent l’offre standard d’un fournisseur de firmware et l’appellent IPMI
  • Les logiciels IPMI s’exécutent généralement sur un processeur appelé BMC (Baseboard Management Controller)
  • Les termes IPMI et BMC sont parfois utilisés de manière interchangeable
  • LOM (Lights-Out Management) est globalement un terme ancien, mais il subsiste parce que HP(E) continue d’utiliser le nom Integrated Lights-Out
  • Le BMC doit être distingué du SMC (System Management Controller), qui assure sur les ordinateurs clients des tâches comme le contrôle de la vitesse des ventilateurs
    • Les deux composants sont historiquement liés
    • Sur les serveurs, le BMC prend en charge la plupart de ces fonctions
  • IPMI spécifie deux modes d’accès
    • Une interface hors bande via une connexion réseau ou série
    • Une interface in-band à laquelle le système d’exploitation accède via un pilote
  • Grâce à l’accès in-band, des outils comme ipmitool sous Linux peuvent interagir avec IPMI depuis le système d’exploitation en cours d’exécution
  • IPMI est un système de gestion indépendant, tout en fournissant par commodité une interface locale au système d’exploitation ; comprendre cette structure aide à éviter les confusions terminologiques

Modes d’utilisation réels d’IPMI et contraintes de sécurité

  • Les produits IPMI fournissent de plus en plus leurs fonctions autour d’une application web
  • De nombreux produits disposent aussi d’un logiciel client dédié, mais les fonctions ont tendance à migrer vers l’application web intégrée
  • La qualité des interfaces web varie fortement selon les implémentations et elle est généralement médiocre
  • La plupart des serveurs disposent d’une interface Ethernet dédiée indiquée comme IPMI ou management
  • Pour des raisons de sécurité et de fiabilité, il est préférable de placer l’interface de gestion IPMI sur un réseau physique dédié
    • Même en cas de problème de performance ou de stabilité sur le réseau principal, IPMI doit rester accessible
    • Un réseau physique dédié prend du temps, de l’espace et de l’argent
  • Un compromis courant consiste aussi à mettre en place le réseau de gestion sous forme de VLAN sur l’équipement réseau général
    • Il se comporte comme un réseau privé indépendant, mais l’équipement réel est partagé
    • L’isolation est mise en œuvre par logiciel
  • Pour éviter un câble supplémentaire, IPMI fournit aussi du réseau sideband
    • Le BMC communique directement avec la même NIC que celle utilisée par le système d’exploitation
    • La NIC se présente comme deux interfaces différentes ; le trafic IPMI est mélangé au même flux de paquets que le trafic de l’hôte, mais utilise une adresse MAC différente
    • La séparation entre IPMI et le trafic applicatif étant affaiblie, des considérations de sécurité s’imposent
  • De nombreuses implémentations IPMI ont présenté de graves problèmes de sécurité et ne doivent pas être rendues accessibles à des utilisateurs non fiables
  • Les fonctions réseau varient selon les implémentations, mais l’interface standard basée sur UDP 623 est couramment utilisée pour la découverte et les commandes de base
  • SSH et l’interface web sont fréquents, et VNC est souvent utilisé pour la console distante
  • Les fonctions de base qu’IPMI permet d’effectuer sont les suivantes
    • Consulter la liste des modules matériels au niveau des FRU ou des références de pièces fournisseur
    • Contrôler des fonctions matérielles de base comme les capteurs, l’état d’alimentation et les ventilateurs
    • Utiliser le watchdog timer standard
  • Le watchdog timer peut être combiné à un logiciel tournant au-dessus du système d’exploitation pour réinitialiser le serveur si une application tombe dans un état anormal
  • Le délai d’expiration du watchdog doit être suffisamment long pour permettre au système de démarrer et de le désactiver après connexion

Intel ME, AMD ST, AMT et les exceptions des PC clients

  • IPMI est courant sur les serveurs d’entreprise, mais rare sur les ordinateurs clients ordinaires ou les machines compactes et basse consommation
  • Intel ME et AMD ST sont des exceptions proches de contrôleurs de gestion OOB présents dans presque tous les processeurs Intel et AMD
  • Intel ME est un composant qui rend possible Intel AMT (Active Management Technology)
  • AMT était une tentative de diffuser la gestion hors bande sur les machines clientes et fournit la plupart des fonctions similaires à IPMI
  • AMT n’a pas rencontré un grand succès, principalement parce qu’Intel a limité l’utilisation de la plupart des fonctions AMT à de coûteuses plateformes de gestion d’entreprise
  • Il existe des clients AMT open source, mais il reste le problème de trouver des machines sur lesquelles AMT est réellement utilisable
  • La gestion sideband d’AMT a suscité des inquiétudes dans la communauté sécurité, mais en pratique toutes les conditions suivantes doivent être réunies
    • Le processeur doit être compatible AMT
    • Le chipset de la carte mère doit être compatible AMT
    • La NIC doit être compatible AMT
    • Les trois appareils sont limités aux produits Intel portant le badge vPro
  • Le simple fait que les NIC Intel soient peu populaires dans les appareils grand public rend déjà l’accès sideband peu courant
  • vPro est limité à des processeurs et chipsets relativement haut de gamme
  • Le « fait » largement répandu selon lequel Intel ME serait accessible sur les appareils grand public via du réseau sideband est généralement faux, et pas seulement à cause des licences logicielles d’Intel
  • Intel ME lui-même n’a quasiment pas de fonctions de gestion hors bande sans AMT, mais il semble servir de base pratique pour héberger et gérer des composants d’exécution de confiance comme Secure Boot et DRM
  • Intel ME ne peut pas être audité par des tiers et a déjà contenu par le passé d’importantes vulnérabilités de sécurité
  • Les SoC ARM grand public modernes disposent aussi de capacités similaires, de sorte que le problème ne se limite pas à un fournisseur x86 particulier

1 commentaires

 
GN⁺ 2024-09-04
Avis sur Hacker News
  • Certains points diffèrent un peu des informations les plus récentes. Intel est à la traîne face à AMD sur l’ensemble CPU/GPU, et seules quelques exceptions ressortent, comme la gamme N100, bien adaptée aux usages basse consommation et fanless.
    C’est pourquoi les CPU Intel sont surtout achetés par des organisations qui doivent renouveler un environnement existant avec des CPU du même fabricant ; par exemple avec l’EVC de vSphere, lorsqu’on fait fonctionner un nouveau processeur comme un ancien modèle du même fabricant afin de permettre la migration à chaud entre architectures CPU et de minimiser les interruptions lors du remplacement du matériel.
    En dehors de cela, l’ambiance est que presque tout le monde part sur des CPU AMD, meilleurs et moins chers au regard des performances de traitement. Les NIC Intel sont globalement correctes et se répandent aussi de plus en plus dans les appareils grand public. Il y a toutefois l’exception de la X710, qui figurait sur les listes de compatibilité « entreprise » comme celles de VMware, mais qui a provoqué pendant plus d’un an des pannes réseau silencieuses ou des crashs à cause de problèmes de pilotes.
    Pour les organisations qui achètent des serveurs, Supermicro peut généralement être un bon choix. C’est moins cher, plus flexible en termes de formats, châssis, composants, nombre de slots, etc., et globalement fiable, mais le support est moins solide que le support théorique de Dell/HPE ; cela convient donc surtout dans des configurations redondantes.
    Par ailleurs, la spécification IPMI est en train d’être remplacée par Redfish, qui fournit une API plus complète, plus sûre, standardisée et saine. Si c’est un serveur grand public courant sorti depuis quelques années, il y a de fortes chances qu’il dispose de Redfish en plus d’IPMI.
    Récemment, la société de recherche en vente à découvert Hindenburg a publié un rapport exposant des éléments suspects chez Supermicro, mais le matériel lui-même reste de tout premier plan et il est aussi utilisé par de grands fournisseurs cloud : https://hindenburgresearch.com/smci/

    • J’ai manipulé à la fois des cartes Supermicro et ASRock Rack pour des stations de travail, et une carte Supermicro donne l’impression de ne pas être un produit de 2024, mais une carte conçue en 2005.
      Pas de prise en charge de la veille ACPI, mauvaise prise en charge des ventilateurs 4 broches/3 broches avec des ventilateurs 3 broches toujours à 100 %, interface web IPMI restée coincée dans les années 2010, placement des NVMe empêchant l’utilisation de dissipateurs, et une foule de cavaliers opaques sans même d’étiquetage sur la carte.
      À l’inverse, la carte ASRock Rack équivalente était incomparablement meilleure.
    • Le problème de Supermicro n’est pas le rapport de vente à découvert, mais la fuite de clés Secure Boot. La racine de confiance est cassée, ce qui rend impossible la sécurisation d’une grande partie du matériel.
      https://arstechnica.com/security/2024/07/secure-boot-is-comp...
    • Sur le papier, les CPU Intel récents n’ont pas l’air mauvais, mais en pratique ils ont un problème de combustion.
      Plus les procédés de gravure se miniaturisent, plus les problèmes de durée de vie deviennent inévitables, donc ce n’est pas vraiment surprenant. Des problèmes comme les défauts de migration peuvent plus facilement provoquer de gros ennuis. On dit que le microcode demandait à la carte mère une tension excessive, et c’est vrai, mais il est aussi vrai que les puces deviennent plus sensibles aux variations de leur environnement.
      Avant, j’aimais les performances et la compatibilité Linux des NIC Intel, et j’aimais aussi les SSD Intel. Cela dit, il fallait savoir lire que leurs performances étaient un peu meilleures dans les percentiles P95 à P99 que celles de concurrents bon marché, et c’est justement dans ces P95 à P99 que l’on ressent la frustration d’un ordinateur lent. L’une des raisons pour lesquelles j’aimais Anandtech tout en le détestant, c’est qu’ils passaient souvent à côté de ce point essentiel.
    • J’aimerais que les PSU Supermicro soient accessibles via PMBus sans utilitaire IPMI propriétaire, mais ce n’est pas le cas. En plus, comme c’est réservé au x86, il n’y a aucun moyen de s’interfacer avec eux sur ppc64el.
      Si c’était open source, il suffirait de le compiler.
      https://www.supermicro.com/en/solutions/management-software/...
    • J’automatise avec Redfish la mise à jour des certificats SSL IPMI, mais le processus d’import d’un nouveau certificat exige une petite magie différente selon l’implémentation Redfish de chaque fournisseur.
      Rien que pour téléverser et remplacer un certificat — nom du certificat, encodage, etc. — j’ai tout un ensemble de modules Python pour gérer les bizarreries propres à chaque fournisseur. En théorie, quelques requêtes PUT standard devraient suffire partout, et la documentation de l’API Redfish pousse à le croire, mais ce n’est pas la réalité.
      J’ai donc du mal à accepter l’idée que ce soit standardisé ou utilisable, et c’est aussi pénible que l’époque où l’on manipulait directement l’interface web.
  • Une option face à l’idée que s’obstiner à utiliser des ordinateurs compacts ou basse consommation impose de vivre sans IPMI consiste à prendre une carte Supermicro MicroATX à base d’Atom avec IPMI et à la refroidir silencieusement avec un petit ventilateur Noctua dans un châssis 1U peu profond.
    J’utilise chez moi un ancien modèle, et il était bien plus attrayant que les modèles Dell R2x0 que j’avais vus, car il est silencieux et compact. Avec des fonctions serveur comme IPMI et la RAM ECC, il est meilleur qu’un mini-PC, et il était plus stable qu’un RasPi bricolé.
    Personnellement, je ne brancherais pas le port IPMI sur le LAN principal, mais une fois isolé, il s’est montré assez utile et amusant à expérimenter.

    • ASRock Rack propose des cartes qui utilisent des puces AM4/AM5 standard avec des chipsets comme X470, X570 ou X670, tout en offrant beaucoup de fonctions serveur comme IPMI et ECC. Côté AMD, l’ECC semble déjà assez courant.
      J’ai mis un 5950X sur ma carte, mais je l’ai aussi utilisée sans problème pendant un moment avec un 5600G. Comme c’est du mATX/ATX, ça rentre dans un boîtier et une alimentation ordinaires, sans besoin de rack.
    • IPMI et les autres interfaces d’administration sont isolés dans un VLAN de gestion séparé, et accessibles uniquement via un VPN dédié.
    • J’ai plusieurs de ces cartes Atom. C’est la première chose qui m’est venue à l’esprit en lisant l’article, et celui-ci met assez longtemps avant de dire qu’IPMI implique du gros matériel.
  • Si vous voulez ajouter une fonction d’accès à distance à du matériel dépourvu d’IPMI, vous pouvez essayer quelque chose comme le NanoKVM RISC-V à 30 $
    Il fournit la capture et l’encodage HDMI, Ethernet/Wi‑Fi, le contrôle de l’alimentation ATX, et exécute une distribution Linux standard
    https://www.aliexpress.com/item/1005007369816019.html
    https://github.com/sipeed/NanoKVM

    • Je suis en train d’en tester un kit complet branché sur un mini‑PC jouet. C’est un petit appareil RISC‑V qui ne consomme que quelques watts et, même s’il n’a pas encore le Wi‑Fi, il capture la sortie HDMI dans une UI web tout en s’émulant auprès du PC comme quatre périphériques
      Il se comporte comme un clavier USB, une souris USB, une clé USB servant à stocker des ISO de démarrage pour l’installation et la récupération, ainsi qu’une carte réseau USB plutôt excellente
      On peut utiliser cette carte réseau USB côté PC pour n’exposer qu’un port SSH d’administration, ce qui donne l’impression que le PC dispose d’une sorte d’interface IPMI dédiée. Les logiciels récents prennent aussi en charge WireGuard et Tailscale, ce qui permet de s’y connecter directement via VPN
      Il reste encore quelques petits problèmes, mais les développeurs les corrigent rapidement
    • Pour utiliser le breakout de contrôle d’alimentation ATX, il faut la version complète à 60 $. Ce breakout se branche sur un curieux connecteur USB‑C physique qui transporte les signaux ATX
      On pourrait sans doute le fabriquer soi‑même, mais les connecteurs USB‑C sont vraiment pénibles à souder
    • Je me demande pourquoi AliExpress ne vend pas cet appareil aux clients américains
    • Côté logiciel, comme ce n’est pas open source, il n’a rien de mieux que les alternatives
      Encore un KVM auquel on ne peut pas faire confiance
  • À la fin des années 1990, j’ai installé plusieurs serveurs fabriqués par Intel. Il s’agissait de plateformes de référence Intel livrées comme ordinateurs « barebone », avec la RAM et le stockage ajoutés par l’intégrateur, et l’administration lights‑out se faisait via LANDesk Server Manager Pro et une « Emergency Management Card » (EMC)
    C’étaient des machines de l’époque Pentium Pro à début Pentium II, comme les AP450GX, BB440FX et RC440FX
    Quand on pense au fait que le code de référence des plateformes x86 ne meurt jamais vraiment, je me suis souvent demandé quelle part de la structure IPMI actuelle descend de ce matériel et de ces logiciels. Le mot de passe par défaut de l’Intel LANDesk Emergency Management Card était « calvin » ; si vous avez déjà manipulé les premiers Dell iDRAC, il vous sera familier. Je ne pense pas que ce soit une coïncidence
    Pour la petite histoire, un employé d’Intel m’a dit que le nom de code de l’EMC était « Hobbes », mais je n’ai rien trouvé de documenté à ce sujet
    Des versions de l’EMC apparaissent régulièrement sur eBay, et il en existait à la fois en ISA et en PCI. C’était un PC x86 sur une carte, et certaines — voire toutes — intégraient un UPS. Il y avait un slot PCMCIA pour ajouter une gestion hors bande, une alimentation externe, et la carte se connectait à la carte mère du serveur via son interface de bus hôte et un connecteur propriétaire
    J’ai téléchargé et examiné le firmware de quelques versions de l’EMC ; certaines ressemblaient à des machines DOS embarquées. C’est encore un petit projet ludique que je garde pour plus tard, donc je n’ai pas encore rétro‑ingéniéré le code ni essayé de le lancer dans qemu, mais j’aimerais le faire
    Des tiers qui vendaient des plateformes de référence Intel, comme Unisys, Fujitsu, ALR/Gateway ou NCR, proposaient aussi cette carte. Si vous voyez cette carte dans une annonce, c’est un bon indice qu’il s’agit d’une plateforme de référence Intel, tout comme les références à « LDSM »
    Si quelqu’un connaît cette lignée, ce serait vraiment intéressant
    https://www.intel.com/pressroom/archive/releases/1998/ld1030...
    https://web.archive.org/web/20240903131630/https://www.ebay....

  • Intel ME et AMD PSP jouent un rôle important pour amener le CPU dans un état semblable à celui d’un PC x86, où le firmware hôte peut réellement s’exécuter
    La complexité de l’initialisation est devenue si élevée qu’il est plus logique de la traiter en logiciel sur un cœur embarqué séparé, proprement programmable en C, plutôt que d’écrire toute la logique dans de l’assembleur étrangement limité comme dans le code de démarrage des BIOS traditionnels
    Sur certains HPE ProLiant, il semble qu’une partie de cette initialisation de bas niveau soit effectivement effectuée par iLO. À cette étape du démarrage, iLO contrôle aussi directement le framebuffer ; sur les G10, on voit brièvement un message du type « passage de la console à l’hôte », puis l’affichage est réinitialisé et les indications des touches de fonction apparaissent
    Dell fait probablement quelque chose de similaire, mais aux premières étapes on ne voit qu’un « Please wait » et un gros indicateur de chargement, sans état d’avancement

  • IPMI et les autres solutions sont bien, mais ce que je veux, c’est une interface série standard vers un shell UEFI qui tourne en permanence. La manière d’accéder à ce port série, c’est mon problème

    • Les services de démarrage UEFI dont dépend le shell ne sont plus disponibles une fois que le bootloader ou le système d’exploitation a appelé ExitBootServices()
      Le code est littéralement retiré de la RAM et cette zone est rendue au système d’exploitation, donc ce n’est pas facile à implémenter
    • Ce qui me manque dans Sun SPARC et d’autres systèmes Unix, c’est qu’ils permettaient un véritable accès distant à très bas niveau
      Les consoles distantes BIOS/UEFI ont toujours été délicates, avec des résultats très variables. Il fallait souvent modifier la configuration de GRUB ou du noyau pour aligner correctement les entrées/sorties
    • Le matériel serveur permet généralement d’accéder à l’UEFI par port série. Mais il me semble qu’il faut quand même un contrôle d’alimentation à distance
  • IPMI est utile, mais il montre clairement qu’on ne peut pas faire confiance aux sociétés commerciales pour assurer correctement le support matériel sur le long terme
    Le système d’exploitation qui tourne sur IPMI est généralement relativement sûr quand le système est neuf, mais dès qu’un nouveau socket CPU arrive, les fabricants se désintéressent de plus en plus des mises à jour des anciens systèmes. C’est vrai même si le même matériel IPMI se trouve à la fois sur des cartes anciennes et récentes
    Si l’on pouvait installer son propre système d’exploitation sur le matériel IPMI, ce serait beaucoup plus utile. On pourrait alors le connecter directement à Internet en toute sécurité. Aujourd’hui, il faut des communications sideband comme un VPN, du port forwarding SSH ou un segment réseau séparé, ce qui ajoute beaucoup de matériel et de configuration simplement pour prendre en charge IPMI
    Dans les déploiements à grande échelle, le surcoût se répartit bien, mais dans les petites installations, c’est une charge assez importante. Pour une seule machine en colocation, cela peut ne même pas valoir le coup
    Comme on ne peut pas exposer IPMI directement sur Internet en toute sécurité, on finit par attacher une forme de Pi à chaque machine. Dans ce cas, utiliser un port série devient tout aussi simple, voire plus simple. Au final, on revient au contrôle standard par port série qui existait déjà à l’époque des VAX, Sun et Alpha, et plus on y pense, plus cela paraît logique qu’une interface réseau peu sûre

  • Pour un déploiement plus petit, par exemple autour de 10 000 cœurs, je le construirais directement via un intégrateur
    Avec des cartes mères Gigabyte/ASRock Rack, des Epyc série 9003, 384 Go de RAM et une configuration classique à double alimentation, on est autour de 7 000 dollars par nœud, avec une efficacité énergétique qui peut être assez bonne
    L’IPMI intégré est aussi plutôt correct, fonctionne bien avec ipmitool, et inclut généralement aussi un certain nombre de fonctions liées à Redfish

  • J’aime vraiment IPMI, mais ce qui me déplaît pour un homelab, c’est que la consommation au repos augmente d’environ 5 W
    Une carte Gigabyte MC12-LE0 avec un Ryzen Pro 5650 semble être un choix évident pour un serveur domestique à environ 50 dollars, mais cette consommation plus élevée ne me convainc pas complètement
    Les anciennes machines comme les Dell T20/T30 ont Intel AMT, avec des fonctions bien plus limitées et des failles de sécurité, mais avec MeshCommander cela donne au moins un moyen d’administration à distance. MeshCommander a malheureusement été abandonné et ses versions ont disparu de plusieurs endroits, mais par chance j’avais sauvegardé le paquet MSI et le paquet Node sur mon serveur
    Je prévois d’essayer PiKVM V2 avec un Raspberry 4 et une simple carte de capture USB-HDMI à 8 dollars : https://docs.pikvm.org/v2/
    À part l’absence de certaines fonctions, cela semble prometteur, car c’est utilisable plus largement même avec des appareils qui ne prennent pas du tout en charge l’administration à distance

    • La surconsommation dépend fortement de la qualité de l’alimentation. Concevoir une alimentation efficace à la fois en forte charge et au repos est assez difficile
      Je doute qu’un BMC, parfois intégré à la NIC, consomme réellement autant. Et avec un Raspberry 4 pour PiKVM, on dépassera les 5 W
    • Maintenant que le firmware est ouvert, je suis en train de regarder NanoKVM
      https://github.com/sipeed/NanoKVM
    • Les versions de MeshCommander sont encore disponibles sur https://www.meshcommander.com/ et l’installation est aussi possible via NPM
      Je ne l’ai pas essayé, mais https://meshcentral.com/ semble être le successeur visé
    • MeshCommander 0.96 est de nouveau téléchargeable depuis le site web. J’ai lu que c’était parce que le développeur s’adaptait à son nouveau poste
  • La grande question avec IPMI, c’est celle de la clé par défaut
    Si, quelque part dans la chaîne d’approvisionnement, quelqu’un installe une clé IPMI supplémentaire ou s’il existe une clé par défaut, cette personne peut administrer l’ordinateur à distance
    https://www.rapid7.com/blog/post/2013/07/02/a-penetration-te...

    • Comme le cite aussi le lien, le processus d’authentification d’IPMI 2.0 exige que, avant l’authentification du client, le serveur envoie au client un hash SHA1 ou MD5 salé du mot de passe de l’utilisateur demandé
      IPMI limite aussi la longueur maximale du mot de passe à 20 caractères. En pratique, il faut voir que l’on espère seulement que le hash restera secret face à un pentester connu opérant dans le cadre d’un contrat à durée limitée, mais pas face à un véritable attaquant disposant d’un temps illimité
      Je suis très critique sur ce point. Cela fait 20 ans que c’est dans la spécification. L’avantage du logiciel n’est-il pas d’être plus facile à modifier que le matériel ? Il est facile de dire « il faut le mettre dans un VLAN », mais lors des audits, on constate que l’IPMI est presque toujours connecté au réseau de production
      Quand on met quelque chose de stupide par défaut, on répand des configurations stupides dans le monde entier, y compris au moment où toutes les entreprises qui n’ont pas d’administrateur sécurité compétent « achètent un serveur »
    • Il devrait toujours être sur un réseau physiquement séparé, et il faut éviter les BMC qui partagent une NIC avec le système