NeuralWall Rules Kit
community out_of_band_server_management

Appliance d'intégration de gestion matérielle out-of-band (BMC)

Ce scénario couvre les flux réseau d'un appliance d'intégration qui administre des serveurs via leur plan de gestion out-of-band (contrôleurs BMC, indépendants du système d'exploitation). L'appliance expose une interface web et une API à des administrateurs et à un gestionnaire de virtualisation ; il pilote les BMC des serveurs gérés (découverte, inventaire, configuration, mise à jour de firmware) ; et il joint un service éditeur sur Internet pour télécharger les paquets de firmware. Le plan de gestion out-of-band donne un contrôle matériel total (sous le système d'exploitation) : il est traité comme une zone à privilège élevé, segmentée et inspectée. Les protocoles de gestion en clair hérités (CIM-HTTP, transfert de fichiers non chiffré) sont bloqués au profit de leurs équivalents chiffrés. La provenance (produit éditeur d'origine) est documentée dans la section Sources.

Schéma:
1.0.0
Version:
1.0.0
Auteurs:
NeuralWall Rules Team (NeuralWall)

Confiance & attestations

Trust tiercommunity
Chargement des infos de confiance…
community
reviewed
verified

Prochain palier : reviewed
Aperçu {} Machine JSON AI IA/RAG Markdown ~ YAML source RAG [en]

Sources

Modèle de menace

Résumé
Le plan de gestion out-of-band (BMC) confère un contrôle matériel total, indépendant et sous le système d'exploitation : montage de média virtuel, reconfiguration, et surtout écriture de firmware. C'est une cible de très haute valeur. L'appliance d'intégration est un point de passage privilégié car il relie le plan IT (gestionnaire de virtualisation, administrateurs) au plan de gestion matériel. Trois risques dominent. (1) Compromission de l'appliance via son interface exposée, puis pivot vers les BMC. (2) Interception des protocoles de gestion en clair hérités (CIM-HTTP, transfert de fichiers non chiffré) sur un réseau de gestion mal segmenté. (3) Chemin de mise à jour de firmware sur Internet détourné en vecteur de chaîne d'approvisionnement (paquet de firmware malveillant).
Objectif attaquant
Obtenir un contrôle persistant sous le système d'exploitation en écrivant un firmware malveillant via le BMC, ou pivoter depuis l'appliance d'intégration vers le plan de gestion out-of-band pour prendre la main sur l'ensemble du parc de serveurs.
Contrôles clés
management_zone_segmentationssl_inbound_inspectionblock_cleartext_managementssl_forward_proxyfirmware_sandboxingidentity_user_group

MITRE ATT&CK

Technique Nom Tactique
T1190 Exploit Public-Facing Application initial-access
T1210 Exploitation of Remote Services lateral-movement
T1542.001 Pre-OS Boot: System Firmware persistence
T1557 Adversary-in-the-Middle credential-access

Règles

# App ID Action Direction Zones Risque Profils sécurité Déchiffrement
0 infra_mgmt_web allow inbound trust, internal, management → management 4 antivirus, ips, url_filtering ssl_inbound_inspection
1 bmc_management allow internal management → management 4 antivirus, ips, sandboxing none
2 icmp_probe allow internal management → management 1 ips none
3 slp allow internal management → management 2 ips none
4 dns allow internal management → internal 2 dns_security none
5 firmware_update allow outbound management → internet 3 antivirus, dns_security, ips, sandboxing, url_filtering ssl_forward_proxy
6 clear_text_mgmt drop internal management → management 4 — —

Détail des règles

Règle 0 — infra_mgmt_web (allow)

Rationale

Cette règle autorise les administrateurs (postes conformes) et le gestionnaire de virtualisation à atteindre l'interface de l'appliance en HTTPS. L'appliance étant un serveur interne contrôlé, ssl_inbound_inspection déchiffre le trafic entrant pour détecter les exploits visant l'interface (T1190) et les fichiers malveillants déposés. L'accès est restreint par groupe annuaire (moindre privilège) et l'appliance reste dans la zone management. Le risque applicatif est élevé (risk 4) car compromettre l'appliance ouvre un pivot vers le plan de gestion matériel.

Application

app_id:
infra_mgmt_web
category:
infrastructure
risk:
4
depends_on:
dns

Zones

trust, internal, management → management

direction: inbound

Profils de sécurité

antivirus: action=block ips: action=block, min_severity=medium url_filtering: credential_phishing=block

Déchiffrement

mode=ssl_inbound_inspection

Journalisation

log_start: false
log_end: true
forwarding → siem_high_priority

Règle 1 — bmc_management (allow)

Rationale

L'appliance pilote les BMC via une API de gestion chiffrée (Redfish/CIM-HTTPS) et transfère les images de firmware. Le déchiffrement est désactivé et documenté par l'exclusion cert_pinned_app : les contrôleurs embarqués valident des certificats d'équipement, et un proxy MITM romprait l'authentification du BMC. Le flux est confiné à la zone management segmentée, ce qui borne l'angle mort. L'antivirus et le sandboxing inspectent les images de firmware avant application (atténuation de T1542.001), et l'IPS couvre les exploits des services de gestion (T1210). Note opérationnelle : une sonde de liveness ICMP accompagne ces transferts (règle 3).

Application

app_id:
bmc_management
category:
infrastructure
risk:
4
depends_on:
dns

Zones

management → management

direction: internal

Profils de sécurité

antivirus: action=block ips: action=block, min_severity=low sandboxing: enabled=true, file_types=firmware_image+pe

Déchiffrement

mode=none

exclusions: cert_pinned_app

Journalisation

log_start: false
log_end: true
forwarding → siem_high_priority

Règle 2 — icmp_probe (allow)

Rationale

L'appliance vérifie la disponibilité d'un BMC par ICMP avant et pendant une mise à jour de firmware. Le flux est interne au plan de gestion. Le profil IPS en mode default détecte les anomalies de protocole (ex. tunneling ICMP) sans bloquer la sonde légitime. Le déchiffrement est non applicable : ICMP n'est pas un flux chiffré.

Application

app_id:
icmp_probe
category:
networking
risk:
1

Zones

management → management

direction: internal

Profils de sécurité

ips: action=default

Déchiffrement

mode=none

Journalisation

log_end: true
forwarding → siem_default

Règle 3 — slp (allow)

Rationale

La découverte de service (SLP) permet à l'appliance de localiser les BMC sur le réseau de gestion. Le flux est confiné à la zone management. SLP étant un protocole amplifiable, l'IPS surveille les anomalies et les tentatives d'abus en réflexion. Le déchiffrement est non applicable : SLP sur UDP n'est pas chiffré.

Application

app_id:
slp
category:
networking
risk:
2

Zones

management → management

direction: internal

Profils de sécurité

ips: action=default

Déchiffrement

mode=none

Journalisation

log_end: true
forwarding → siem_default

Règle 4 — dns (allow)

Rationale

La résolution DNS est requise pour joindre les BMC, le gestionnaire de virtualisation et le service éditeur de firmware. Le flux est restreint vers un résolveur interne contrôlé (pas de résolution directe vers Internet). Le profil dns_security avec sinkhole atténue le tunneling DNS depuis un hôte de gestion compromis. Le déchiffrement est non applicable : DNS sur UDP n'est pas chiffré.

Application

app_id:
dns
category:
networking
risk:
2

Zones

management → internal

direction: internal

Profils de sécurité

dns_security: action=block, sinkhole=true

Déchiffrement

mode=none

Journalisation

log_end: true
forwarding → siem_default

Règle 5 — firmware_update (allow)

Rationale

L'appliance télécharge des paquets de firmware depuis un service éditeur sur Internet. C'est l'unique flux sortant vers Internet et un vecteur de chaîne d'approvisionnement : ssl_forward_proxy est obligatoire pour que l'antivirus et le sandboxing inspectent le contenu (atténuation de T1542.001 — firmware malveillant). url_filtering bloque les catégories à risque et les sites non catégorisés (durcissement). La liste blanche des domaines de l'éditeur reste spécifique au déploiement : les domaines documentés par la source figurent en provenance (references[].endpoints / section Sources), à reporter en url_filtering.allow_list au déploiement — sans coder de marque dans la règle. Le risque applicatif est moyen (risk 3) : flux sortant légitime mais sensible.

Application

app_id:
firmware_update
category:
infrastructure
risk:
3
depends_on:
dns, ssl

Zones

management → internet

direction: outbound

Profils de sécurité

antivirus: action=block dns_security: action=block, sinkhole=true ips: action=block, min_severity=low sandboxing: enabled=true, file_types=firmware_image+pe+archive url_filtering: block_categories=malware+phishing+c2+newly_registered_domain+compromised, credential_phishing=block, uncategorized_action=block

Déchiffrement

mode=ssl_forward_proxy

Journalisation

log_start: false
log_end: true
forwarding → siem_high_priority

Règle 6 — clear_text_mgmt (drop)

Rationale

Durcissement : les protocoles de gestion en clair hérités (CIM-HTTP sur 5988, transfert de fichiers non chiffré sur 115) sont bloqués silencieusement. Ils sont interceptables sur un réseau de gestion mal segmenté (T1557 — vol d'identifiants et altération en vol) et doivent être remplacés par leurs équivalents chiffrés (CIM-HTTPS 5989, gestion sur 443 — règle 2). Le log en haute priorité signale toute tentative d'usage, indice de matériel hérité mal configuré ou de tentative de contournement. La protection par gestion out-of-band en clair (IPMI hérité sur udp/623) relève de la même posture et doit être confinée puis éliminée.

Application

app_id:
clear_text_mgmt
category:
infrastructure
risk:
4

Zones

management → management

direction: internal

Journalisation

log_start: true
log_end: true
forwarding → siem_high_priority