PsychoArs Ars Scholae Palatinae
20y
768
Subscriptor
jhodge said:
If your management network is accessible from the Internet, you're doing it wrong.It needs to be fixed, but this shouldn't be a full-on freakout for most shops.
Yes and no.
If your management network is accessible from your workload network, you're doing it wrong. All it takes is a compromised laptop/desktop/IoT device that's reaching out and lets a bad actor control it. Defense in depth. //
fuzzyfuzzyfungus Ars Legatus Legionis
12y
10,234
PsychoArs said:
Yes and no.If your management network is accessible from your workload network, you're doing it wrong. All it takes is a compromised laptop/desktop/IoT device that's reaching out and lets a bad actor control it. Defense in depth.
You also probably want 'your management network' to be internally divided to the degree possible. Ideally you'd like all your BMCs to work for you; but if one of them turns out not to you can't necessarily trust the remainder to protect themselves(and for newly added devices that aren't supposed to require hands-on provisioning more or less blind trust in the first thing that talks to you is a feature; so you really, really, want that to be you).
Not every wire can be cut, or you might as well just get an empty shed for much, much, less money; but there is often not much call for any two random devices on the management network to talk to one another, rather than a relative handful of monitoring and provisioning systems talking to otherwise solitary BMCs who have no excuse for knowing about one another. //
Little-Zen Ars Praefectus
24y
3,201
Subscriptor
Deny_Deflect_Disavow said:
“The vulnerability, carrying a severity rating of 10 out of a possible 10, resides in the AMI MegaRAC, a widely used firmware package that allows large fleets of servers to be remotely accessed and managed even when power is unavailable or the operating system isn't functioning.”I‘m not sure I understand how firmware can be manipulated if electricity is not available or the OS is not functioning. Secondly, these hosts may be physically wired to any network, yet how can a remote execution or procedure call be issued to the server if powered down?
If there's literally no power, like at all, then they aren't accessible, yes. But that's "no power" as in "the whole building's power is out."
If, however, it's just that the server has been powered off but is still plugged in, and the BMC is connected to a network, you can reach it. These are things like Dell iDRAC, HP iLO, Lenovo IMM, etc. They're designed to be always on, and they provide a way to access the server as though you were physically there, including a virtual console that acts like a connected monitor and keyboard, so you can even remotely power on/off a server if necessary. It doesn't use the installed host operating system - thing of it like a remotely accessible BIOS with a ton of other functionality that also lets you see what's happening on the system in real time. You can even virtually mount ISOs to remotely install an operating system.
It is extremely convenient and I'm sure anyone here who has worked in IT has stories about how iDRAC saved their life at one point or another. I certainly have a few.
However, I can also say - when I was managing servers, all my BMCs were connected to an isolated VLAN, in-building only accessible from another isolated VLAN and to only a very specific set of users with separate logins used solely for interacting with devices on the management network, and remotely over a VPN that only allowed that very specific set of users to access a jump box, which itself was accessible only with the separate management network logins.
You absolutely want to isolate and protect these interfaces specifically because of vulnerabilities like this one.