> > Supermicro IPMI is crap. Use normal serial console and add a power strip > > which you can manage via ethernet to poweroff/power cycle the server. > > Well, I can't say it's the greatest implementation ever, but arguably it > doesn't seem much worse than on my Sun or IBM servers.
http://news.softpedia.com/news/Rapid7-Researchers-Discover-Vulnerabilities-in-Supermicro-IPMI-Firmware-398010.shtml http://www.darkreading.com/management/new-gaping-security-holes-found-exposing/240157724 [and many many more articles, if you just dug instead of saying "arguably"] My favorite part is that on some Supermicro machines you have an option to turn it off, but it actually doesn't turn off. Just awesome! We can come up with plausible reasons why that is so, because we read the news. Must be interesting where those machines end up. You just cannot compare this to what Sun did, by (almost always) using a seperate ethernet port. Probably still crap, but at least there was some attempt to provide isolation. At least you can build your own isolation in some way, if you feel compelled to use it. Must be great when people throw a full rack of those machines into a seperate vlan, and one vulnerable machine can screw the others, though. Lessons are just never learned. Is it still "arguably" fine? > The exact same IPMI SOL works fine under linux and illumos, so it > doesn't necessarily seem an underlying fault in the implementation. I > guess I could try booting freebsd on it and see if that works. "works fine" > If I used a regular serial console, I'd need a terminal server to access > it remotely, I'd rather just get this working and avoid the extra parts. "avoid the extra parts" versus "avoid the holes". Similar issues exist on Dell BMC, documented elsewhere, you just need to search. In fact it is unlikely that there are PC server-class machines that have a safe primary ethernet port. It is possible they all have such problems built in ("oops"). It is really amazing that so many people prefer to remain blissfully unaware. Yummy, "ASF" driver injection/sniffing, IPMI buffer overflows, BMC cpus without MMUs, SMI, SMIBIOS, shared I2C bus access....
