Learn › BMC & Server Management › Operations
BMCs are the most attacked door in the rack. Audit a flagged Dell BMC's users, cipher suites, LAN auth, and channel access with interactive diagrams and real ipmitool output, then purge the stale accounts and file the compliance report on a live emulator.
It is 09:00 at the DC-EAST facility in Ashburn, Virginia. The quarterly compliance sweep just landed on your queue, and one machine is flagged: the Dell PowerEdge R750xs in Bay 14, Row 7.
Here is why it matters. Through 2025 and into 2026, a wave of intrusion crews stopped bothering with the host operating system. The host is patched, firewalled, and watched. So the crews went one layer down, straight for the management plane: the BMC. A BMC owns power, BIOS, firmware, and the console, and on a shared management network a compromised one can pivot to its neighbors across the row. Attack the BMC and the host's own hardening becomes irrelevant.
Your work order, DC-EAST-WO-1010, is an audit-plus-lockdown: examine this BMC's user accounts, its cipher suites, its LAN authentication, and its channel access, find what the compliance team flagged, and close the holes you can close.
This is a Practice Zone. The diagrams below react to you: click the boxes, flip the switches. The real machine comes at the end, under Ready to practice.
Before you audit anything, get the mental model straight. A BMC is not one door. It is a small always-on computer with its own network stack, and it listens on several services at once. Each one is a way in.
{ "height": 420, "caption": "One BMC, several doors. Flip the posture to see what hardening closes.", "nodes": [ { "id": "atk", "label": "BMC-pivot crew", "kind": "admin", "x": 0, "y": 180, "detail": "An attacker on the internet or a flat management VLAN. In the 2025-26 campaigns they never touch the host OS; they go straight for the management plane." }, { "id": "mgmt", "label": "Management net", "kind": "net", "x": 230, "y": 180, "detail": "The management network. If it is flat or internet-reachable, every BMC on it is one hop from the attacker." }, { "id": "ipmi", "label": "IPMI / RMCP+ 623", "kind": "nic", "x": 480, "y": 40, "detail": "IPMI over UDP 623. Its cipher suites and auth types decide whether a login needs real credentials." }, { "id": "ssh", "label": "Vendor SSH 22", "kind": "nic", "x": 480, "y": 180, "detail": "The Dell racadm shell. Stale or default accounts here are unlocked doors." }, { "id": "snmp", "label": "SNMP 161", "kind": "nic", "x": 480, "y": 320, "detail": "SNMP over UDP 161. A default community string like public leaks inventory and status." }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 730, "y": 180, "detail": "The BMC. Owns power, BIOS, firmware, and the console. Compromise it and the host's own security is irrelevant." }, { "id": "host", "label": "Host + workloads", "kind": "host", "x": 960, "y": 90, "detail": "The server this BMC controls. The attacker can power-cycle it, reflash it, or watch its console." }, { "id": "peers", "label": "Peer BMCs", "kind": "bmc", "x": 960, "y": 270, "detail": "Neighboring BMCs in the row. A compromised BMC on a shared management net can pivot and brick its peers." } ], "edges": [ { "from": "atk", "to": "mgmt", "label": "internet / VPN", "kind": "mgmt" }, { "from": "mgmt", "to": "ipmi", "kind": "mgmt" }, { "from": "mgmt", "to": "ssh", "kind": "mgmt" }, { "from": "mgmt", "to": "snmp", "kind": "mgmt" }, { "from": "ipmi", "to": "bmc", "kind": "mgmt" }, { "from": "ssh", "to": "bmc", "kind": "mgmt" }, { "from": "snmp", "to": "bmc", "kind": "mgmt" }, { "from": "bmc", "to": "host", "label": "power / BIOS / firmware", "kind": "power" }, { "from": "bmc", "to": "peers", "label": "lateral pivot", "kind": "plain" } ], "toggle": { "label": "Facility posture:", "on": "Default (as shipped)", "off": "Hardened", "dimOff": ["snmp", "e:mgmt-snmp", "e:snmp-bmc", "e:bmc-peers"] } }
Trace it left to right. The attacker reaches the management network, and from there every listening service on the BMC is exposed at once: IPMI on UDP 623, the vendor SSH shell on 22, SNMP on 161. Any one of them that answers without proper credentials is an open door into the BMC, and the BMC controls the host and can reach its peers. Flip the posture to Hardened and watch the SNMP door and the lateral-pivot path disappear. That is what today's work is: closing doors.
>>> No. The BMC runs beside the host on standby power with its own IPMI, SSH, and SNMP services. Patching the host does nothing for the BMC; it is a second computer with its own doors, and those doors are exactly what you audit today.
Start with IPMI. When a client opens an IPMI 2.0 session, the two sides negotiate a cipher suite: the combination of authentication, integrity, and encryption the session will use. Suite 3, the one you always name with -C 3, is HMAC-SHA1 authentication plus AES-128 encryption. It demands real credentials.
The problem is what else the channel may offer. Flip the toggle and watch the no-credential path appear and disappear.
{ "height": 360, "caption": "Flip suite 0 off and the no-credential path to the BMC disappears.", "nodes": [ { "id": "atk", "label": "Unauth attacker", "kind": "admin", "x": 0, "y": 170, "detail": "An attacker on the management network with no username and no password." }, { "id": "neg", "label": "RMCP+ setup", "kind": "net", "x": 260, "y": 170, "detail": "Session setup. The attacker asks the BMC which cipher suite it may use." }, { "id": "s0", "label": "Suite 0: none/none/none", "kind": "nic", "x": 540, "y": 50, "detail": "Cipher suite 0: auth none, integrity none, confidentiality none. A session that proves nothing and encrypts nothing." }, { "id": "s3", "label": "Suite 3: SHA1 + AES", "kind": "nic", "x": 540, "y": 300, "detail": "Cipher suite 3: HMAC-SHA1 auth plus AES-128. A session that demands real credentials." }, { "id": "bmc", "label": "BMC (admin ops)", "kind": "bmc", "x": 840, "y": 170, "detail": "The BMC, ready to run admin IPMI commands: power, boot device, user changes." } ], "edges": [ { "from": "atk", "to": "neg", "kind": "mgmt" }, { "from": "neg", "to": "s0", "label": "pick suite 0", "kind": "oob" }, { "from": "neg", "to": "s3", "label": "pick suite 3", "kind": "mgmt" }, { "from": "s0", "to": "bmc", "label": "admin, NO credentials", "kind": "power" }, { "from": "s3", "to": "bmc", "label": "blocked without valid login", "kind": "mgmt" } ], "toggle": { "label": "Cipher suite 0 on channel 1:", "on": "Enabled (as shipped)", "off": "Disabled (hardened)", "dimOff": ["s0", "e:neg-s0", "e:s0-bmc"] } }
To audit this for real, you ask the channel to list every suite it will accept. This is the star command of the whole work order, and this is the exact output the flagged BMC returns.
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN channel getciphers ipmi 1 output: ID IANA Auth Alg Integrity Alg Confidentiality Alg 0 N/A none none none 1 N/A hmac_sha1 none none 2 N/A hmac_sha1 hmac_sha1_96 none 3 N/A hmac_sha1 hmac_sha1_96 aes_cbc_128 4 N/A hmac_sha1 hmac_sha1_96 xrc4_128 5 N/A hmac_sha1 hmac_sha1_96 xrc4_40 6 N/A hmac_md5 none none 7 N/A hmac_md5 hmac_md5_128 none 8 N/A hmac_md5 hmac_md5_128 aes_cbc_128 9 N/A hmac_md5 hmac_md5_128 xrc4_128 10 N/A hmac_md5 hmac_md5_128 xrc4_40 11 N/A hmac_md5 md5_128 none hint: Ask the channel for its ciphers: channel getciphers ipmi 1. Then look hard at row 0.
Read row 0: none none none. That is cipher suite 0, the classic cipher-zero authentication bypass. A session opened on suite 0 authenticates nothing and encrypts nothing. Rows 6 through 11 are the weak HMAC-MD5 suites, also worth flagging, but suite 0 is the headline finding.
>>> Nothing. Suite 0 is the skeleton key: the session proves no identity, so a BMC that offers it hands admin-level access to anyone who asks. Disabling suite 0 is finding number one.
The diagram made the claim. Now make the BMC prove it, with your own hands and a password you already know is wrong.
Here is the test. You send the same request twice, with the same wrong password, and you change one thing between the runs: the cipher suite. Suite 3 first, the strong one. Then suite 0, the skeleton key.
Start on suite 3. Ask the BMC for its identity with mc info, but hand it wrongpass in place of the real password.
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P wrongpass mc info output: Error: Unable to establish IPMI v2 / RMCP+ session hint: It is the audit command with two edits: swap -P ADMIN for -P wrongpass, and keep -C 3.
That is authentication doing its job. Suite 3 checked the password, the password was wrong, and no session opened. No identity, no data, nothing.
Now change a single character. Swap -C 3 for -C 0, keep the same wrong password, and ask the same question.
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 0 -H $BMC_IP -U ADMIN -P wrongpass mc info output: Device ID : 0 Device Revision : 0 Firmware Revision : 9.08 IPMI Version : 2.0 Manufacturer ID : 674 Manufacturer Name : Dell Inc. Product ID : 564 (0x0234) Product Name : Unknown (0x234) Device Available : yes Provides Device SDRs : no Additional Device Support : Sensor Device SDR Repository Device SEL Device FRU Inventory Device IPMB Event Receiver Chassis Device Aux Firmware Rev Info : 0x00 0x00 0x00 0x00 hint: Take the command you just ran and change only -C 3 to -C 0. Leave the wrong password in place.
Read the two runs against each other. Same host, same wrong password, one different digit. Suite 0 handed over the full identity: Dell Inc., firmware 9.08, product ID 564, IPMI version 2.0, and the entire device support list. It asked for no proof, so a wrong password was as good as the right one.
The identity is only the opening. On suite 0 you can read the account roster too, still with no valid credential. Ask for the user list.
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 0 -H $BMC_IP -U ADMIN -P wrongpass user list output: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 1 true false false USER 2 ADMIN true false true ADMINISTRATOR 3 true false false Unknown (0x00) 4 true false false Unknown (0x00) 5 true false false Unknown (0x00) 6 true false false Unknown (0x00) 7 true false false Unknown (0x00) 8 true false false Unknown (0x00) hint: Same suite-0 form as the identity dump, but end the command with user list instead of mc info.
Row 2 is the prize. The ADMIN account, IPMI messaging on, privilege ADMINISTRATOR. An attacker with no password now knows the exact name of the full-rights account to attack next. The channel listed every user slot it has, sixty-three in all, for a request that proved nothing.
This is not a lab trick. Cipher suite 0 is a long-known IPMI weakness that security scanners flag, and controllers that still offer it turn up on real management networks. The wrong password worked because suite 0 never checked one.
You just ran the attack. In a real audit you never run it against production hardware. You scan for the exposure instead, then close it before anyone else finds it.
The scan is one read-only command, the same channel getciphers ipmi 1 you enumerated earlier. It lists every RMCP+ cipher suite the channel will accept, one row per suite. You are hunting for a single row.
Row 0 is the fingerprint. When it reads none for authentication, none for integrity, and none for confidentiality, the channel is offering suite 0, the no-credential session you just opened. That one row is the whole finding.
So the detection rule is short. Run getciphers against a BMC, read row 0, and flag any channel that answers none, none, none. You never have to open a suite-0 session to prove the hole. The offer alone is the vulnerability.
This is the auditor's discipline: prove the exposure with the read-only getciphers list, not by logging in through it. Row 0 is the line you cite in the report, and it is enough.
Cipher suites are one surface. The LAN channel has two more you can read the same way. The lan print 1 command dumps the channel's authentication and network configuration in one shot. Here is what the flagged BMC actually prints.
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN lan print 1 output: Set in Progress : Set Complete Auth Type Support : NONE MD2 MD5 PASSWORD Auth Type Enable : Callback : NONE MD2 MD5 PASSWORD : User : NONE MD2 MD5 PASSWORD : Operator : NONE MD2 MD5 PASSWORD : Admin : NONE MD2 MD5 PASSWORD : OEM : IP Address Source : Static Address IP Address : 10.100.7.2 Subnet Mask : 255.255.255.0 MAC Address : d4:ae:52:b1:23:45 SNMP Community String : public IP Header : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00 Default Gateway IP : 10.100.7.1 Default Gateway MAC : 00:00:00:00:00:00 Backup Gateway IP : 0.0.0.0 Backup Gateway MAC : 00:00:00:00:00:00 802.1q VLAN ID : Disabled 802.1q VLAN Priority : 0 RMCP+ Cipher Suites : 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 Cipher Suite Priv Max : aaaaaaaaaaaaaaa : X=Cipher Suite Unused : c=CALLBACK : u=USER : o=OPERATOR : a=ADMIN : O=OEM Bad Password Threshold : Not Available hint: One command dumps the whole LAN channel config: lan print 1.
Two more findings jump out. Auth Type Enable lists NONE for every privilege level, meaning the channel permits an anonymous, no-auth login. And SNMP Community String is public, the factory default that leaks inventory and status to anyone who asks.
There is one account-level view left to pull: channel getaccess 1 2 reports how user 2, the ADMIN account, is allowed to reach channel 1. On this BMC it comes back with IPMI Messaging: enabled and Privilege Level: ADMINISTRATOR, confirming ADMIN holds full administrator rights over the LAN. You will run that one yourself in the work order.
Everything in this step is a read-only interrogation. You are building the evidence list before you change a single thing. Auditors call this the finding phase; get it complete before you touch anything.
Three findings so far, all on the IPMI side of the controller. There is a fourth surface, and every compliance framework asks about it by name.
When you open a BMC's web interface, or drive it over HTTPS, the controller presents a TLS certificate. Think of it as a name badge. It states a name, it carries the public key you encrypt to, and it carries a signature.
The signature is the part that matters. A Certificate Authority, a third party your organization already trusts, signs the badge to vouch that the name is genuine. Without that signature a badge is just a claim.
A self-signed certificate is one the machine signed for itself. Nobody vouched. It is a name badge written in the wearer's own handwriting.
The Dell shell reports the certificate in one word, sslinfo. Type it at the controller prompt.
prompt: /admin1-> answer: sslinfo output:
SSL Certificate Information ============================================================
Subject: CN=bay14-r750xs Issuer: CN=bay14-r750xs Valid From: Jan 01 00:00:00 2026 GMT Valid To: Jan 01 00:00:00 2031 GMT Key Type: RSA 2048-bit Signature Algo: sha256WithRSAEncryption Serial Number: 01 Certificate Type: Self-Signed hint: At the /admin1-> prompt, the one word that reports the certificate is: sslinfo
Now audit it line by line.
Subject is the name being claimed: CN=bay14-r750xs. Issuer is who signed for that name: CN=bay14-r750xs. Those two fields are identical, and that is the finding. The machine vouched for itself. Certificate Type: Self-Signed says it again in plain words.
Two more details belong in the report. Serial Number: 01 is the mark of a certificate generated once at the factory and never touched since. And the validity window runs January 2026 to January 2031. That is a five-year life, far past what any public CA will issue, because a long-lived key is a long-lived problem the day it leaks.
Here is why an auditor cares, and it is not paperwork.
A self-signed certificate makes every browser throw a warning, so operators learn to click through it. That habit is the real damage. Once clicking through is routine, an attacker sitting between you and the BMC can present a certificate of their own, and it looks exactly like every other Tuesday. The one alarm that would catch an interception is the alarm everybody trained themselves to dismiss.
The second problem is scale. No CA also means no revocation list. If this key ever leaks there is nothing to revoke and nobody to notify. The remediation is a certificate signed by your internal CA, with a validity window your team actually rotates.
sslinfo reads, it does not install. Replacing a BMC certificate means uploading a CA-signed one and restarting the web service. On this controller the certificate is therefore a report finding, not a live change, exactly like cipher suite 0 and the ADMIN password.
Now the accounts. On a Dell BMC the account roster lives in the vendor shell, so you audit it by opening the Dell SSH shell and running user list, not through ipmitool. That table is where the compliance flag really came from.
Four accounts are enabled on this BMC. ADMIN in slot 2 is still on its factory-default password. And three departed-employee accounts were never removed. Flip the diagram from Before audit to After purge to see what least privilege should look like.
{ "height": 380, "caption": "Every enabled account is a live key. Flip to After purge to see least privilege.", "nodes": [ { "id": "admin", "label": "ADMIN (slot 2)", "kind": "admin", "x
Practice Security Hardening in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.