community out_of_band_server_management

Out-of-band hardware management integration appliance (BMC)

This scenario covers the network flows of an integration appliance that administers servers through their out-of-band management plane (BMC controllers, independent of the operating system). The appliance exposes a web UI and an API to administrators and to a virtualization manager; it drives the managed servers' BMCs (discovery, inventory, configuration, firmware updates); and it reaches a vendor service on the Internet to download firmware packages. The out-of-band management plane grants full hardware control (below the operating system): it is treated as a high-privilege zone, segmented and inspected. Legacy clear-text management protocols (CIM-HTTP, unencrypted file transfer) are blocked in favor of their encrypted equivalents. The provenance (original vendor product) is documented in the Sources section.

Schema:: 1.0.0
Version:: 1.0.0
Authors:: NeuralWall Rules Team (NeuralWall)

Trust & attestations

Trust tiercommunity

Loading trust info…

community

reviewed

verified

Next tier: reviewed

Preview {} Machine JSON AI AI/RAG Markdown ~ Source YAML RAG [fr]

Sources

Lenovo — XClarity Integrator for VMware vCenter — Network requirements (retrieved 2026-06-04)
https://pubs.lenovo.com/lxci-vcenter/network_requirements

Documented endpoints : datacentersupport.lenovo.com, download.lenovo.com, filedownload.lenovo.com, support.lenovo.com, supportapi.lenovo.com

Threat model

Summary

The out-of-band management plane (BMC) grants full hardware control, independent of and below the operating system: virtual media mounting, reconfiguration, and above all firmware writes. It is a very high-value target. The integration appliance is a key choke point because it bridges the IT plane (virtualization manager, administrators) and the hardware management plane. Three risks dominate. (1) Compromise of the appliance through its exposed interface, then pivot to the BMCs. (2) Interception of legacy clear-text management protocols (CIM-HTTP, unencrypted file transfer) on a poorly segmented management network. (3) The Internet firmware-update path hijacked into a supply-chain vector (malicious firmware package).

Attacker goal

Gain persistent below-OS control by writing malicious firmware through the BMC, or pivot from the integration appliance into the out-of-band management plane to take over the entire server fleet.

Key controls

management_zone_segmentationssl_inbound_inspectionblock_cleartext_managementssl_forward_proxyfirmware_sandboxingidentity_user_group

MITRE ATT&CK

Technique	Name	Tactic
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

Rules

#	App ID	Action	Direction	Zones	Risk	Security profiles	Decryption
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	—	—

Rule details

Rule 0 — `infra_mgmt_web` (allow)

Rationale

This rule allows administrators (compliant devices) and the virtualization manager to reach the appliance interface over HTTPS. Since the appliance is a controlled internal server, ssl_inbound_inspection decrypts inbound traffic to detect exploits targeting the interface (T1190) and malicious uploaded files. Access is restricted by directory group (least privilege) and the appliance stays in the management zone. Application risk is high (risk 4) because compromising the appliance opens a pivot into the hardware management plane.

Application

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

Zones

trust, internal, management → management

direction: inbound

Security profiles

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

Decryption

mode=ssl_inbound_inspection

Logging

log_start: false

log_end: true

forwarding → siem_high_priority

Rule 1 — `bmc_management` (allow)

Rationale

The appliance drives the BMCs through an encrypted management API (Redfish/CIM-HTTPS) and transfers firmware images. Decryption is disabled and documented via the cert_pinned_app exclusion: embedded controllers validate device certificates, and a MITM proxy would break BMC authentication. The flow is confined to the segmented management zone, which bounds the blind spot. Antivirus and sandboxing inspect firmware images before they are applied (mitigating T1542.001), and IPS covers management-service exploits (T1210). Operational note: an ICMP liveness probe accompanies these transfers (rule 3).

Application

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

Zones

management → management

direction: internal

Security profiles

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

Decryption

mode=none

exclusions: cert_pinned_app

Logging

log_start: false

log_end: true

forwarding → siem_high_priority

Rule 2 — `icmp_probe` (allow)

Rationale

The appliance checks a BMC's availability via ICMP before and during a firmware update. The flow is internal to the management plane. The IPS profile in default mode detects protocol anomalies (e.g. ICMP tunneling) without blocking the legitimate probe. Decryption is not applicable: ICMP is not an encrypted flow.

Application

app_id:: icmp_probe
category:: networking
risk:: 1

Zones

management → management

direction: internal

Security profiles

ips: action=default

Decryption

mode=none

Logging

log_end: true

forwarding → siem_default

Rule 3 — `slp` (allow)

Rationale

Service discovery (SLP) lets the appliance locate BMCs on the management network. The flow is confined to the management zone. As SLP is an amplifiable protocol, IPS watches for anomalies and reflection-abuse attempts. Decryption is not applicable: SLP over UDP is not encrypted.

Application

app_id:: slp
category:: networking
risk:: 2

Zones

management → management

direction: internal

Security profiles

ips: action=default

Decryption

mode=none

Logging

log_end: true

forwarding → siem_default

Rule 4 — `dns` (allow)

Rationale

DNS resolution is required to reach the BMCs, the virtualization manager and the vendor firmware service. The flow is restricted to a controlled internal resolver (no direct Internet resolution). The dns_security profile with sinkhole mitigates DNS tunneling from a compromised management host. Decryption is not applicable: DNS over UDP is not encrypted.

Application

app_id:: dns
category:: networking
risk:: 2

Zones

management → internal

direction: internal

Security profiles

dns_security: action=block, sinkhole=true

Decryption

mode=none

Logging

log_end: true

forwarding → siem_default

Rule 5 — `firmware_update` (allow)

Rationale

The appliance downloads firmware packages from a vendor service on the Internet. This is the only outbound Internet flow and a supply-chain vector: ssl_forward_proxy is mandatory so antivirus and sandboxing can inspect the content (mitigating T1542.001 — malicious firmware). url_filtering blocks risky categories and uncategorized sites (hardening). The vendor's domain allow-list remains deployment-specific: the domains documented by the source are recorded as provenance (references[].endpoints / Sources section), to be set in url_filtering.allow_list at deployment — without hardcoding a brand into the rule. Application risk is medium (risk 3): a legitimate but sensitive outbound flow.

Application

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

Zones

management → internet

direction: outbound

Security profiles

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

Decryption

mode=ssl_forward_proxy

Logging

log_start: false

log_end: true

forwarding → siem_high_priority

Rule 6 — `clear_text_mgmt` (drop)

Rationale

Hardening: legacy clear-text management protocols (CIM-HTTP on 5988, unencrypted file transfer on 115) are silently dropped. They can be intercepted on a poorly segmented management network (T1557 — credential theft and in-flight tampering) and must be replaced by their encrypted equivalents (CIM-HTTPS 5989, management on 443 — rule 2). High-priority logging flags any usage attempt, a sign of misconfigured legacy hardware or a bypass attempt. Legacy clear-text out-of-band management (legacy IPMI on udp/623) falls under the same posture and must be confined then eliminated.

Application

app_id:: clear_text_mgmt
category:: infrastructure
risk:: 4

Zones

management → management

direction: internal

Logging

log_start: true

log_end: true

forwarding → siem_high_priority

Trust & attestations

Sources

Threat model

MITRE ATT&CK

Rules

Rule details

Rule 0 — infra_mgmt_web (allow)

Rule 1 — bmc_management (allow)

Rule 2 — icmp_probe (allow)

Rule 3 — slp (allow)

Rule 4 — dns (allow)

Rule 5 — firmware_update (allow)

Rule 6 — clear_text_mgmt (drop)

Usage & feedback

Rule 0 — `infra_mgmt_web` (allow)

Rule 1 — `bmc_management` (allow)

Rule 2 — `icmp_probe` (allow)

Rule 3 — `slp` (allow)

Rule 4 — `dns` (allow)

Rule 5 — `firmware_update` (allow)

Rule 6 — `clear_text_mgmt` (drop)