Hacker News Reader

Comment by johnklos | Hacker News Reader

BMCs are horribly insecure and probably intentionally so. They should always be on a dedicated ethernet port and never shared (looking at you, Supermicro - no port should ever be able to accidentally become shared), and the network to which they're connected should be 100% disconnected from the Internet, which means you'd obviously need to be running your own NTP server.

If you weren't previously using NTP with your BMC, then that might suggest you haven't put enough time and attention in to your configurations.

If you're not already keeping your BMCs from talking to the Internet, then you really, really should, as soon as you can.

View on HN

> If you weren't previously using NTP with your BMC, then that might suggest you haven't put enough time and attention in to your configurations.

> not all vendors include NTP as a free feature on all of their BMCs. Charging licensing costs for some features is a good way to insure that we don't use them, unless the licensing cost is trivial (which, spoiler, it hasn't been when we asked

If you bought servers that nickel-and-dime you on NTP that means you haven't put enough time and attention in to your purchasing.

Some BMCs have get their clock synced with OS which is connected to internet. This way BMC does not need outside connection.

Are there any resources that talk about the specific concerns of the bmc having outbound Internet access?

It is general advice across most server application deployments to limit internet egress (see for example NIST NIST SP 800-190, section 4.4.2 “Unbounded network access from containers”) . A machine that can talk out to the internet usually provides an attacker more avenues to compromise it and control/exfiltrate data from it post-compromise. A classic example is a SSRF bug, like how the recent log4j/log4shell bug used an attacked-instigated outbound LDAP call to a malicious internet host to achieve RCE.

You remember those Bloomberg articles about SuperMicro servers being bugged? The details they came up with for how the bugs were inserted were kind of out there, but the scenarios for what could be done line up with a compromised BMC.

If you assume something will get remote execution on your BMC, it's likely going to get full access to the BMC, because no updates. Then, what does your BMC have access to? DMA to the host, ability to monitor and trigger lots of exciting things, etc. It's pretty scary if you think about it, but IPMI replaces serial concentrators and remote access PDUs with zero rack space and not much security, so yay?

But if the BMC is compromised, then basically all the protections you put in place to seperate its connection from the host are useless anyway, since the BMC can easily masquerade as the host. I can see why it's a good idea to restrict access to the BMC itself, since it's a likely quite soft target for exploits, but once it's exploited, there's not really much benefit to restrictions which target the BMC specifically.

If you can restrict access to the BMC before it's comrpomised, you might have a chance at a secure environment... You definitely want it to always use its dedicated port, preferably with no factory way to use the host nics (although, once it gets compromised, dma says it can use the host nic if it's sneaky)

Reply on news.ycombinator.com