Over 47,000 Supermicro Servers Are Exposing BMC Ports on the Internet

0
4
Over 47,000 Supermicro Servers Are Exposing BMC Ports on the Internet

typodupeerror
  • You really really shouldn’t expose IPMI services to the Internet given the dire potential consequences of any exploits that gain access to embedded management hardware on a server.

    • Agreed they shouldn’t be exposed.

      But even on a local network, it seems bad if management ports are wide open.

      • The one BMC BIOS I have had the displeasure to work with came with a psychotic number

        of services preconfigured in addition to IPMI channels, and to boot, it had IPv6 link-local

        addresses accepting traffic on the management port with no way to turn that off.

        Port isolation is the only good solution for this crap. You can’t just put it on a private VLAN

        with the rest of your BMC/ILO crap, because a compromise could come out the BMC/ILO of

        one machine to extend to your entire server farm.

    • Our setup has IPMI access between two servers (i.e. if one is still ok, IPMI on the other can be reached by it), but exposing it to the Internet was never an option. This does make things more complicated, but it is the only secure option. At the very least, you should put IPMI access behind a jump-host that is hardened and only accessible via SSH or VPN. Use two of these and a physically seperated IPMI network if you need redundancy.

      Thise that place convenience over security will have neither convenience n

      • Note that fundamentally, the protocols used by BMCs can be properly secured if implemented correctly by vendor and owner sets really strong passwords. This should be done even if the network is ostensibly physically segregated.

        The problem is that *any* appliance/firmware is a risk given the general inconsistency and update difficulties of the vendors. Those home routers are probably a much more enormous glob of security holes in practice.

        What is maddeining to me is that despite the existence of software t

        • I do agree on all of that. In particular, use of very defensive and careful engineering on the software of the BMCs, a minimal interface with very strict input validation, good crypto right from the start, secure update mechanism, etc. and the thing could have been exceptionally hard to hack. But all of that needs people that really know what they are doing, and these are rare and expensive. I expect that, as usual, some “managers” though their bonus much more important than the welfare of their customers a

        • Except you might have your BMC’s hooked up for authentication via your active directory for example, going to need a gateway setting. Other things are flinging their event log at a syslog host, contacting NTP servers so all those log entries are synchronized etc.

          That said all inbound traffic should be cut off at the knees.

          I take the view for example that running special NTP servers for the BMC network is introducing another potential security issue, where as letting them contact the campus NTP servers is ju

          • True, a complex environment should be able to competently mitigate the network, but then again I’ve found shops to be worse at it than they think they are.

            I take the view for example that running special NTP servers for the BMC network is introducing another potential security issue

            A well configured and automatically patched NTP service from a reputable OS vendor I would think a lower risk than putting appliances at greater risk of being globally available.

            I also take the view that connecting my syslog server directly to the BMC network is a bad idea as it means any compromise on that and my BMC network is wide open

            This is a key argument I can’t agree with. If you can’t reasonably secure an instance that is bridged to the same L2 segment, than you have much bigger problems corporate wide.

  • but Supermicro and security experts recommend restricting access to BMC management interfaces from the internet, as a precaution and industry best practice.

    So, why in the heck would you put an unprotected management port on the internet. Management functionality should come through a fairly airgapped network, a single jump host or something like that… Why oh Why

    • Because in 2019 “anyone can code” and everyone is an expert.

      • Indeed. And to make matters worse, many of these incompetents do not understand they are incompetent (Dunning-Kruger at work) and do not even get help with doing things. Worst case I have seen so far was where “management” sent the future staff of a newly established SOC to evening school to learn the basics of TCP/IP networking. If they ever have an incident, these people will be completely lost.

    • Why? Because it is easier. With the “cheaper than possible” IT personnel modern “management” likes to hire, people struggle to make things work at all. Of course, anybody competent will never expose IPMI to the internet, but the people doing it are anything but competent.

    • So, why in the heck would you put an unprotected management port on the internet?

      You may not realize you’re doing it.

      I have a FreeNAS box built using a Supermicro board, which has two gigabit NICs. I am aware it has IPMI/BMC, and I’m aware that I need to shut it off. I am also aware that IPMI is enabled by default on the “other” NIC. So I wandered into the BIOS, found a setting for IPMI, and turned off the switch that said (in effect), “Enable IPMI on the second NIC.” All set, right?

      What I didn’t re

  • Were these the motherboards that were rumoured at some point to have microscopic HW backdoor devices a while back?

    • Bloomburg made the accusation [tomshardware.com] but it was never proven to be true.

      • that’s generous.

        In fact it was shown (article in slashdot) to be utter bullshit and the component in question normal

        • Well, the idea was not completely without merit, but it had numerous practical issues that Bloomberg missed.

      • Accusation is as good as guilt nowadays.

    • Yes, though that did not appear under further scrutiny to be more than just an isolated occurrence. It appears to have been some sort of attack on the supply chain, rather than a manufacturer-installed feature.

      • Yes, though that did not appear under further scrutiny to be more than just an isolated occurrence.

        Oh? They got that far? Got a link, because everything I read on the topic turned out to be 100% unsubstantiated.

      • So let’s have some pix! (pr it didn’t happen).

      • It’s always great when an unsubstantiated claim from a news source that isn’t backed up anywhere and refuses to name a source is only verified by a completely anonymous internet post without any evidence at all.

        Don’t worry AC, I believe you. We’ll get our moment when they prove the aliens in Area 51 are real.

  • By default, if the IPMI is unplugged, the IPMI fails over the the first onboard ethernet port. If that happens to be your WAN interface it’s probably not the desired state. Failover behavior can be controlled in the BIOS, or plug the actual IPMI port back in.

    • And if you have the minimal competence to look at things and documentation and configure them right (and to block the IPMI port in the firewall you should have as well, just to be sure) then the port will not get exposed. Looks like at least 47’000 supermicro-based systems lack administrators with that minimal competence.

    • That’s an issue if you assign IPMI a reputable IP on your public network. You should never, ever do that.

      The failover is a different MAC on the same physical plug.

      • That should say “a routable public IP”.

        You’d only do that if you’re crazy.

      • That’s an issue if you assign IPMI a reputable IP on your public network. You should never, ever do that.

        Right, except that most by default will DHCP so if you have a





Read More

Leave a reply

More News