Using /conf/crontab, as dlawson pointed out, sounds like an excellent idea to me. This allows me to run a script once a minute that ensures everything but http and ssh is
shut down:
/etc/init.d/cdserver stop
/etc/init.d/fdserver stop
/etc/init.d/cim_sfcb stop
/etc/init.d/webgo stop
That still leaves me with a web server with password-based access control (I can see no way to have it validate client certificates) and who knows what remote vulnerabilities. Turning it off when I'm not using it (which is most of the time) seems like a reasonable solution; adding a crontab entry to shut it down every five or ten minutes would catch those cases where someone forgets to shut it down when he's done.
The ssh daemon is a version of dropbear that appears to be fairly heavily modified. It reads usernames and plaintext passwords from /conf/PMConfig.dat (which is also used by the web server), logs in any valid name and password as the root user, and ignores the ~/.ssh/authorized_keys file. This last problem is annoying; it forces you to allow password logins and opens the possibility of backdoors depending on from where-all it gets its names and passwords.
So that's the dilemma you face: how much do you really trust this modified ssh daemon installed on a system that was fairly obviously designed by security-naïve developers? Not much at all, given the number of broken bits of cruft I've seen in their shell scripts. There are unusual naming conventions (/etc/rc?.d/sshd is a symlink to /etc/init.d/ssh), huge amount of code that appear to be unused, and features in just the ssh startup script, such as the /conf/portcfg_ssh file and even the restart command are entirely broken. (Don't try using these; sshd won't restart and you'll be screwed unless you have an existing login. We rebooted the BMC and ended up having to reflash it.)
The best option I can think of, if one's going to use the thing at all, is to start ssh on an alternate port using a cron job, so at least it's less likely to appear in a portscan.
The final component is the IPMI network management ports; I can't see how to turn these off.
I wound up resetting the IPMI interface by downloading the IPMI tools for Linux from Supermicro's website, making a bootable linux USB drive & copying the tools over to them, booting to it, & issuing ./ipmicfg-linux.x86.static -fd. This has to be done from the server/workstation directly.
Best Answer
There's a couple of issues here:
The "ipmitool" command on it's own uses a local interface to the ipmi controller. This is why you need to load the modules in order to use ipmitool from the same host. If you're on a remote host you can use ipmitool over the network, using something like "ipmitool -I lan -H hostname -U username -P password chassis status", substituing appropriate values for hostname, username and password.
If you're not using the dedicated IPMI controller ethernet port, then you may need to actively tell the IPMI controller to use the onboard ethernet port. These IPMI controllers default to an "auto fallback", so if you have an ethernet cable plugged into the dedicated LAN port at the time the IPMI controller is powered up, it will use the dedicated port, otherwise it will fallback. So if you've changed your mind about which port to use, this might be occuring.
The onboard port the IPMI controller piggybacks on is LAN1. Are you sure you're using LAN1? It may not be the same as the interface that your linux install thinks is eth0.
Finally, I've definitely seen connectivity issues when using IPMI over a non-dedicated port. The way the ethernet controller in the IPMI piggybacks onto your host ethernet port can result in DHCP issues, as well as network card driver crashes. I've also seen the situation where the IPMI IP address on a non-dedicated port is accessible from a remote machine, but not from the local one (which isn't a problem generally, because you can use the ipmitool kernel interface anyway).
I always advocate using a dedicated port where available.
In all cases, to reset the IPMI controller you need to either use the ipmitool interface once you get that working, or to physically remove power from the machine (off at the wall/PDU etc - turning the machine off from the button at the front isn't enough, as the IPMI controller is still powered)