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.
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 : Unspecified IP Address : 0.0.0.0 Subnet Mask : 0.0.0.0 MAC Address : 00:00:00:00:00:00 SNMP Community String : public IP Header : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00 Default Gateway IP : 0.0.0.0 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.
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": 60, "y": 40, "detail": "ADMIN, slot 2, still on the factory-default password ADMIN. A one-guess key. Keep the account, change the password." }, { "id": "jsmith", "label": "jsmith (slot 3)", "kind": "admin", "x": 60, "y": 170, "detail": "jsmith, slot 3. Contractor, left six months ago. Still enabled, still admin." }, { "id": "intern", "label": "intern1 (slot 4)", "kind": "admin", "x": 60, "y": 300, "detail": "intern1, slot 4. Summer intern, gone. Should never have held admin." }, { "id": "bmc", "label": "BMC account DB", "kind": "bmc", "x": 430, "y": 170, "detail": "The BMC user database. Each enabled account can authenticate to this server's management plane." }, { "id": "testu", "label": "testuser (slot 5)", "kind": "admin", "x": 760, "y": 60, "detail": "testuser, slot 5. Commissioning test account, never removed after intake." }, { "id": "host", "label": "The server", "kind": "host", "x": 760, "y": 250, "detail": "Any one of these keys can power-cycle or reflash this box out-of-band, invisible to host security." } ], "edges": [ { "from": "admin", "to": "bmc", "label": "default password", "kind": "mgmt" }, { "from": "jsmith", "to": "bmc", "label": "stale admin", "kind": "mgmt" }, { "from": "intern", "to": "bmc", "label": "stale admin", "kind": "mgmt" }, { "from": "testu", "to": "bmc", "label": "stale", "kind": "mgmt" }, { "from": "bmc", "to": "host", "label": "full control", "kind": "power" } ], "toggle": { "label": "Account cleanup:", "on": "Before audit", "off": "After purge", "dimOff": ["jsmith", "intern", "testu", "e:jsmith-bmc", "e:intern-bmc", "e:testu-bmc"] } }
When you run user list in the Dell shell against this BMC, the roster reads ADMIN plus jsmith, intern1, and testuser, and the footer says Total users: 4. Those three names are the ones you purge.
>>> A stale BMC admin is a permanent out-of-band master key to the hardware. It survives OS reinstalls, it is invisible to host logging, and on a shared management net it can reach the neighbors. Departed-employee accounts are the first thing an auditor and an attacker both look for.
You have your findings. Now the honest part: what you can actually change on this BMC versus what goes in the report.
The remediation you make live is the account purge. In the Dell shell, user delete <name> genuinely removes each departed account from the BMC's user database. Purge jsmith, intern1, and testuser, then run user list again to confirm the footer drops to Total users: 1, ADMIN alone.
The cipher-zero disable, the anonymous-auth fix, the SNMP community change, and the ADMIN password rotation are all real findings you document in the compliance report. On this hardware you can read and prove every one of them, which is exactly what an audit requires.
Truthful simulation: this BMC is a standards-faithful emulator that really speaks IPMI over LAN and the Dell shell, so every audit command here is the exact one you would run against a physical iDRAC. What it does not do is let you log in through the weaknesses you found or run a password-policy engine, so the suite-0 disable and the ADMIN password change go in your report as findings while the account purge is the change you make live.
The compliance report is the deliverable the auditors keep. The purge is the deliverable the next attacker never gets to use.
Time to do it for real. On the machine you are about to open, close out Work Order DC-EAST-WO-1010 by auditing this BMC and locking down what you can. The BMC address is preset for you in $BMC_IP, and the credentials are ADMIN / ADMIN.
Six objectives stand between this server and a clean compliance record:
1. Audit the roster. Pull the full BMC account list through the Dell shell and file it to ~/user-audit.txt. 2. Enumerate the ciphers. List the channel's RMCP+ cipher suites and save them to ~/cipher-audit.txt. 3. Read the LAN posture. Dump the channel's auth types and SNMP community in one interrogation. 4. Check the account access. Audit the ADMIN account's per-channel access rights. 5. Purge the stale accounts. Remove the three departed accounts, then prove only ADMIN remains, captured to ~/purge-proof.txt. 6. The challenge. File the compliance hardening report to ~/hardening-report.txt, naming the findings and the actions you took. No hints on this one.
Here is the deal: the workspace shows no commands. It hands you one objective at a time, and you recall the move. That recall is the whole point; it is how this hour's reading becomes your skill.
Stuck is normal. Hit Request a signal on any objective for a nudge, or ask Daemon. It knows exactly which task you are on and will nudge, not spoil.
Your workstation dc-east-ws01 is booting in the bay below, with the flagged Dell BMC on the management network beside it. Launch it and close the work order.
Practice Security Hardening in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.