Le port le plus privilégié du rack est celui que personne ne surveille

Chaque serveur moderne porte en lui un second ordinateur, plus petit : le contrôleur de gestion. Sur les serveurs HPE c'est iLO, sur les serveurs Dell c'est iDRAC, et sur les châssis de lames il y a un Onboard Administrator au-dessus des lames. On le traite souvent comme une commodité pour les redémarrages à distance. C'est en réalité le composant le plus privilégié du rack, et il mérite qu'on conçoive autour de lui.

Ce qu'un contrôleur de gestion peut faire

Tout le durcissement que vous faites à l'intérieur de l'OS est hors sujet si le contrôleur est joignable par les mauvaises personnes.

Règle un : son propre port, son propre réseau

La plupart des serveurs peuvent faire tourner le contrôleur soit sur un port de gestion dédié, soit en partage avec l'un des ports réseau principaux. Le partage est pratique, parce qu'il économise un câble et un port de switch. Il place aussi le contrôleur sur le même réseau que le trafic ordinaire du serveur, ce qui est exactement là où il ne devrait pas être.

Nous donnons à chaque contrôleur son propre port physique, son propre câble et sa propre commutation, sur un espace d'adressage privé qui n'est jamais routé vers ou depuis un réseau client et jamais annoncé sur Internet. C'est ce que nous entendons par réseau de gestion air-gap. Une machine client, même compromise, n'a aucun chemin vers un contrôleur. Les ingénieurs atteignent le réseau de gestion uniquement à travers nos propres passerelles VPN et hôtes de rebond.

Vous pouvez vérifier le choix actuel depuis le contrôleur lui-même. Sur iDRAC :

racadm get iDRAC.NIC.Selection      # Dedicated, or one of the LOM ports
racadm get iDRAC.IPv4               # address, gateway, DHCP state

Sur tout serveur où les outils IPMI sont installés, depuis le système d'exploitation :

ipmitool lan print 1

Cela montre l'adresse du contrôleur, le VLAN et les suites de chiffrement qu'il accepte sur le réseau.

Règle deux : désactivez ce que vous n'utilisez pas

Les contrôleurs sont livrés avec plusieurs voies d'accès, et chacune est de la surface d'attaque. Passez-les en revue sur chaque machine :

• IPMI over LAN. Plus ancien, moins sûr que les interfaces web et SSH du contrôleur. Si rien dans votre outillage n'en a besoin, désactivez-le (racadm get iDRAC.IPMILan.Enable montre l'état sur iDRAC). Si quelque chose en a besoin, assurez-vous que seules des suites de chiffrement fortes sont acceptées.
• Heure et journalisation. Pointez le contrôleur vers vos sources de temps, et envoyez ses journaux et ses traps SNMP vers vos collecteurs de gestion.

Règle trois : licenciez-le correctement

L'IPMI nu vous donne le contrôle de l'alimentation et pas grand-chose de plus. Les niveaux sous licence sont ce qui rend un contrôleur utile pour de vraies opérations : une console distante qui fonctionne de manière fiable, des médias virtuels pour les installations à distance, une télémétrie matérielle complète et la gestion des firmwares. Nous exploitons iDRAC Enterprise avec la licence Datacenter sur les serveurs Dell, iLO Advanced sur les serveurs HPE, et des Onboard Administrators redondants sur chaque châssis de lames. Un serveur qui ne peut pas être entièrement atteint par son contrôleur est un serveur qui a besoin d'une personne devant lui, et c'est la manière coûteuse d'exploiter un datacenter.

Configurez tout le châssis d'un coup

Sur les châssis de lames HPE, il existe une meilleure voie. L'Onboard Administrator peut transmettre un script de configuration à l'iLO de chaque lame à travers le fond de panier du châssis en une seule opération, en utilisant le format de script RIBCL de HPE via la commande HPONCFG. Le châssis s'authentifie lui-même auprès de chaque iLO, donc aucun identifiant par lame n'est nécessaire, ce qui signifie qu'une lame rackée ce matin, encore sans mot de passe propre, peut être entièrement configurée cet après-midi.

Une passe typique à l'échelle du châssis définit la licence, ajoute un compte de gestion, fixe le délai d'expiration de session, pointe l'heure et le SNMP vers les collecteurs de gestion, et est suivie d'une seconde passe qui relit chaque réglage pour vérification. Dell a l'équivalent avec les scripts racadm et les profils de configuration de serveur. Quel que soit le fabricant, le principe est le même : une configuration écrite, appliquée à l'identique, vérifiée par relecture.

Donner l'accès aux clients sans casser le modèle

Les clients disposant de serveurs dédiés ont parfois besoin de leur propre accès console. Par défaut, nos ingénieurs utilisent la console distante pour le compte du client, en continu. Là où un client a besoin d'un accès direct à iLO ou iDRAC, nous le fournissons via un VPN dédié, pour que le contrôleur lui-même reste sur le réseau de gestion isolé et que seul le contrôleur de ce client soit joignable à travers lui.

Vérifiez vos propres contrôleurs

• Chaque contrôleur est-il sur un port dédié, ou certains partagent-ils un port de données ?
• Un contrôleur peut-il être atteint depuis un réseau client ou depuis Internet ?
• L'IPMI over LAN est-il activé quelque part où il n'est pas nécessaire ?
• Des comptes d'usine sont-ils encore actifs ?
• Les journaux et les traps des contrôleurs atteignent-ils votre supervision ?
• Existe-t-il une configuration écrite face à laquelle chaque contrôleur est vérifié ?

Si vous souhaitez que votre matériel soit géré avec les contrôleurs enfermés là où ils doivent l'être, nous en parlerons volontiers. Parler à un ingénieur

Related (rows[1])

Voir aussi : Montage en rack, intégration des lames, contrôleurs de gestion · Le socle de durcissement sur chaque hôte · DCIM : chaque objet, port, câble et adresse suivis