Comment sécuriser firmware UEFI, réseau et BMC

Le micrologiciel s’exécute avant le système d’exploitation, parfois à côté de lui, et souvent avec des droits qu’aucun agent installé sur le serveur ne peut contrôler. Traiter le firmware comme un détail matériel revient à confier les clés du bâtiment à un sous-traitant dont personne ne vérifie le badge.

→ Lire l’explication complète de la marmotte

UEFI, contrôleurs réseau et privilèges pré-système

L’UEFI (Unified Extensible Firmware Interface) initialise le matériel, choisit le programme de démarrage et charge le système d’exploitation. Son code réside généralement dans une mémoire flash accessible par le processeur avant toute protection apportée par le noyau, l’antivirus ou l’agent de détection. Une compromission UEFI survit donc à la réinstallation du disque, au remplacement des partitions et à la plupart des procédures de réponse à incident centrées sur le système d’exploitation.

Le compromis central est brutal : plus le micrologiciel offre de fonctions de démarrage, de gestion et de diagnostic, plus il expose du code très privilégié, rarement observé et difficile à restaurer proprement. La recommandation est de conserver les fonctions nécessaires à l’exploitation, mais de désactiver celles qui ne servent pas. Un démarrage réseau jamais utilisé, une console distante laissée active ou une pile de compatibilité héritée ne créent pas de résilience. Ils créent du code exécutable supplémentaire. Le matériel adore les options inutilisées, elles ont tendance à rester là jusqu’au jour où quelqu’un les utilise avec de mauvaises intentions.

Secure Boot, ou démarrage sécurisé, vérifie la signature des composants chargés durant le démarrage. Cette fonction réduit le risque de chargeur non autorisé, à condition que les clés de confiance, les listes de révocation et les réglages UEFI soient eux-mêmes maîtrisés. Elle ne protège pas contre un firmware déjà compromis, contre une clé de signature abusivement approuvée, ni contre un opérateur qui désactive le contrôle dans l’interface locale.

Les contrôleurs réseau disposent aussi de leur propre firmware. Une carte compatible PCI Express (Peripheral Component Interconnect Express) peut charger une ROM d’option avant le système d’exploitation, notamment pour le démarrage par réseau. Elle peut également effectuer des accès DMA (Direct Memory Access), c’est-à-dire lire ou écrire directement la mémoire principale sans passer par le processeur. Une isolation d’entrées-sorties correctement activée limite ces accès, mais elle ne transforme pas un contrôleur compromis en périphérique digne de confiance.

Un pilote du système d’exploitation compromis reste visible dans les journaux, les processus ou les mécanismes de contrôle d’intégrité. Un micrologiciel compromis peut falsifier les données que reçoit ce pilote. Ce n’est pas une subtilité académique : l’outil de supervision qui interroge un matériel compromis demande au suspect de rédiger son propre procès-verbal.

La gestion de cette couche doit rejoindre les fondations d’architecture et non vivre dans une feuille de calcul oubliée entre deux références de câbles. Chaque serveur doit disposer d’un état attendu : version UEFI, version du contrôleur réseau, version du contrôleur de stockage, version du contrôleur de gestion, réglages de démarrage et état du démarrage sécurisé.

BMC, un ordinateur d’administration indépendant

Le BMC (Baseboard Management Controller) est un contrôleur autonome de gestion matérielle. Il possède son processeur, sa mémoire, son système embarqué, son stockage, ses interfaces réseau et souvent son propre serveur web. Les appellations commerciales iLO, iDRAC ou XClarity changent selon le constructeur ; le modèle de risque ne change pas.

Le BMC reste alimenté tant que le serveur reçoit une alimentation de veille. Il peut démarrer, arrêter, redémarrer, monter un média virtuel, modifier l’ordre de démarrage, accéder à la console graphique et lire des capteurs même lorsque le système d’exploitation est arrêté. Cette capacité est précieuse pour l’exploitation distante. Elle signifie aussi qu’un BMC compromis contrôle la séquence de démarrage et peut observer ou modifier une machine avant que ses protections logicielles existent.

L’IPMI (Intelligent Platform Management Interface) fournit des mécanismes historiques de gestion à distance. Redfish est une interface de programmation applicative fondée sur HTTP, généralement plus structurée et mieux intégrée aux outils d’inventaire. Ni IPMI ni Redfish ne compensent un réseau de gestion ouvert. Authentifier une interface exposée directement à Internet reste une mauvaise idée, même avec Transport Layer Security, ou TLS, parce que la surface comprend le service web, les bibliothèques cryptographiques, les comptes locaux, les mécanismes de session et le firmware entier.

Un BMC doit se trouver sur un réseau d’administration distinct, filtré au niveau des pare-feu et accessible seulement depuis des postes d’administration durcis ou un bastion. Aucun routage direct depuis les réseaux utilisateurs, les réseaux applicatifs ou Internet ne doit exister. L’administration hors bande n’est pas un réseau de production avec une adresse IP plus discrète. C’est un domaine de sécurité séparé, avec ses propres identités, journaux et règles de filtrage. La segmentation réseau vaut ici davantage qu’une politique de mot de passe écrite en police huit.

Les comptes locaux par défaut doivent être supprimés, désactivés ou placés sous contrôle d’un coffre de secrets. Lorsqu’une fédération d’identité est disponible et correctement journalisée, elle réduit la prolifération de comptes partagés. Elle ne dispense pas d’un compte de secours local, documenté, protégé dans un coffre et testé. Sans accès de secours, une panne du fournisseur d’identité peut transformer une intervention matérielle en exercice de spéléologie administrative.

Inventaire firmware par Redfish et système local

L’inventaire doit être automatisé, exporté vers l’outil de gestion de configuration et comparé à une base de versions approuvées. L’objectif n’est pas de mettre à jour tout ce qui bouge dès qu’un constructeur publie une archive. Une mise à jour de firmware peut modifier les réglages, invalider une compatibilité de pilote ou exiger un cycle d’alimentation complet. L’objectif est de savoir exactement ce qui tourne, d’évaluer les avis de sécurité, puis de déployer par vagues avec un retour arrière réaliste.

L’exemple suivant collecte la version UEFI et celle du pilote réseau depuis Linux, puis interroge l’inventaire firmware du BMC via Redfish. Le fichier Netrc contient un compte de lecture dédié et doit être lisible uniquement par son propriétaire.

# Lire la version UEFI exposée par la table matérielle du serveur.
sudo dmidecode --type bios | grep -E 'Vendor:|Version:|Release Date:'

# Lire le pilote et sa version pour une interface réseau donnée.
sudo ethtool -i enp1s0 | grep -E 'driver:|version:|firmware-version:'

# Préparer ~/.config/bmc-inventory.netrc avec des droits restrictifs :
# machine bmc-admin.example.internal login inventory-ro password <secret>
chmod 600 "$HOME/.config/bmc-inventory.netrc"

# Récupérer les objets d'inventaire publiés par l'interface Redfish.
curl --fail --silent --show-error \
  --cacert /etc/ssl/certs/bmc-ca.pem \
  --netrc-file "$HOME/.config/bmc-inventory.netrc" \
  "https://bmc-admin.example.internal/redfish/v1/UpdateService/FirmwareInventory" |
  jq -r '.Members[]."@odata.id"'

La vérification du certificat serveur est obligatoire. Ajouter --insecure pour contourner une chaîne de certification défaillante revient à accepter qu’un équipement intermédiaire fournisse un faux inventaire ou vole les identifiants du compte technique. Ce genre de raccourci disparaît souvent après un audit, puis revient mystérieusement dans un script d’urgence. Les scripts d’urgence ont une mémoire particulièrement longue.

La version du pilote n’est pas la version du firmware de la carte. Les deux doivent être collectées, avec la référence matérielle et la version du système d’exploitation, car les matrices de compatibilité constructeur portent fréquemment sur ce couple. Une mise à jour de carte réseau sans pilote compatible peut produire des pertes de lien intermittentes, donc précisément le type de panne qui semble surnaturelle jusqu’à ce qu’un câble innocent soit accusé.

Correctifs, chaîne de confiance et reprise matérielle

Un paquet de mise à jour firmware doit provenir du constructeur, être vérifié cryptographiquement lorsque le mécanisme existe et être associé à une référence matérielle exacte. Une image prévue pour une révision voisine n’est pas « presque compatible ». Elle est potentiellement capable de rendre l’équipement inutilisable. Les mises à jour distribuées par un système d’exploitation ou une plateforme de gestion centralisée restent acceptables si la chaîne de provenance, les signatures et les hash sont vérifiés.

Le risque de retour arrière mérite une décision explicite. Un firmware ancien peut corriger une régression fonctionnelle, mais il peut aussi réintroduire une vulnérabilité corrigée. Activer la protection contre le retour arrière lorsque le matériel la propose est le bon choix pour les composants d’amorçage et de gestion, après avoir validé une version stable. Sans cette protection, un attaquant disposant d’un accès privilégié peut parfois réinstaller une version vulnérable puis exploiter une faille connue.

Une fenêtre de maintenance doit prévoir un redémarrage complet, et non seulement un redémarrage logiciel. Certains composants ne chargent leur nouveau micrologiciel qu’après une coupure d’alimentation. Cette dépendance doit figurer dans le plan d’intervention et dans les critères de réussite. Un serveur déclaré corrigé alors que son BMC exécute encore l’ancienne image est un joli tableau de bord, pas une remédiation.

La sauvegarde de configuration est distincte de la sauvegarde du firmware. Exporter les paramètres UEFI et BMC, les certificats de l’interface de gestion, les paramètres réseau, les rôles d’administration et l’ordre de démarrage permet une restauration après remplacement matériel ou remise à zéro. Les secrets ne doivent pas apparaître dans ces exports en clair. Lorsqu’un export les contient malgré tout, il devient un secret à part entière : chiffrement, contrôle d’accès, durée de conservation limitée et rotation après usage.

Ce que la sécurité du firmware ne garantit pas

Un firmware à jour ne protège pas contre l’usage abusif de comptes d’administration valides, une console BMC laissée accessible depuis un poste compromis ou un support physique mal contrôlé. Il ne remplace ni l’authentification forte, ni la segmentation, ni la supervision des connexions de gestion. Il ne détecte pas non plus nécessairement une compromission antérieure : une mise à jour peut écraser le code malveillant, mais elle ne prouve pas que les réglages, les clés ou les données manipulées pendant l’incident sont sains.

La supervision doit centraliser les journaux BMC : connexions, échecs d’authentification, création de comptes, changements de configuration réseau, montage de média virtuel, mise à jour de firmware et redémarrages à distance. Les horloges des BMC doivent être synchronisées avec une source de temps contrôlée, sinon l’investigation devient un puzzle dont les pièces ont été imprimées dans des fuseaux horaires concurrents.

Le contrôle d’intégrité matériel, lorsqu’il existe, apporte une mesure utile seulement si elle est collectée hors du serveur contrôlé et comparée à une valeur attendue. Une attestation ne vaut que par la clé qui la signe, la chaîne qui valide cette clé et le système qui interprète le résultat. Dire « matériel de confiance » sans décrire cette chaîne revient à ajouter une étiquette rassurante sur une boîte noire.

🐝 Ce qui arrive si on s’en passe

Sans cette couche de protection, un seul BMC compromis ouvre souvent toute la flotte : les comptes de gestion identiques d’un serveur à l’autre et un réseau d’administration plat permettent de rejouer le même identifiant sur chaque contrôleur joignable. Le média virtuel permet alors de démarrer une image choisie par l’attaquant et de lire les disques non chiffrés sans jamais lancer le système installé. Les journaux locaux du BMC, de taille limitée et effaçables par un compte administrateur, disparaissent avant toute collecte s’ils ne sont pas exportés. Sans inventaire, un avis de sécurité constructeur ne peut pas être rapproché des machines concernées, et la fenêtre d’exposition reste inconnue. Enfin, un serveur renvoyé en garantie ou réformé sans remise à zéro du BMC emporte ses comptes, ses certificats et la cartographie du réseau de gestion.

🦫 Explication de la marmotte 🍫

Le micrologiciel est un programme enregistré dans les composants d’un serveur. Il démarre avant le système d’exploitation et prépare le processeur, la mémoire, le stockage et la connexion réseau. Le programme de démarrage vérifie ensuite quels logiciels peuvent être lancés. Si ce programme caché a été modifié, il peut lancer un programme non autorisé avant les protections habituelles du serveur.

Certaines cartes réseau possèdent aussi leur propre programme. Elles peuvent recevoir des instructions avant le démarrage complet et échanger directement avec la mémoire du serveur. Le système d’exploitation ne contrôle donc pas toujours tout ce qui s’est produit avant son lancement.

Le contrôleur de gestion à distance est un autre ordinateur miniature présent dans le serveur. Il reste alimenté lorsque le serveur est éteint. Il permet de l’allumer, de l’arrêter, de voir son écran, de modifier son démarrage et d’installer un système à distance. Une personne qui prend le contrôle de ce composant peut agir sur le serveur même si son système principal ne fonctionne plus.

La protection repose sur plusieurs actions liées : recenser les versions installées, installer les corrections du constructeur, limiter le réseau de gestion à des machines autorisées, protéger les comptes d’administration et conserver les journaux. Si une mise à jour échoue, le serveur peut nécessiter une coupure électrique complète ou une restauration de configuration. Si le contrôleur de gestion est exposé sur Internet, une erreur de mot de passe ou une faille peut donner un accès très puissant au serveur.

Pages voisines

La citent

Comment sécuriser firmware UEFI, réseau et BMC

Elle cite

Comment sécuriser firmware UEFI, réseau et BMC

Comment sécuriser firmware UEFI, réseau et BMC

UEFI, contrôleurs réseau et privilèges pré-système

BMC, un ordinateur d’administration indépendant

Inventaire firmware par Redfish et système local

Correctifs, chaîne de confiance et reprise matérielle

Ce que la sécurité du firmware ne garantit pas

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines