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.
If you access it locally you can specify a new password. On Linux this would be done via ipmitool
. Something like this should work:
ipmitool -I open lan set 1 password NEWPASSWORD
If you don't know which channel is your ethernet interface, just page through them one at at time, like so:
# ipmitool -I open channel info 1
Channel 0x1 info:
Channel Medium Type : 802.3 LAN
Channel Protocol Type : IPMB-1.0
Session Support : multi-session
Active Session Count : 0
Protocol Vendor ID : 7154
Volatile(active) Settings
Alerting : disabled
Per-message Auth : disabled
User Level Auth : enabled
Access Mode : always available
Non-Volatile Settings
Alerting : disabled
Per-message Auth : disabled
User Level Auth : enabled
Access Mode : always available
Note that the medium type is "802.3 LAN". That's the one you want. Other channels may look like this:
# ipmitool -I open channel info 2
Channel 0x2 info:
Channel Medium Type : Serial/Modem
Channel Protocol Type : IPMB-1.0
Session Support : single-session
Active Session Count : 0
Protocol Vendor ID : 7154
# ipmitool -I open channel info 3
Channel 0x3 info:
Channel Medium Type : System Interface
Channel Protocol Type : KCS
Session Support : session-less
Active Session Count : 0
Protocol Vendor ID : 7154
Best Answer
Simply telnet to the IPMI IP Address in port 49152 and do a specific GET request. You should get your users and passwords if you're compromised.
After the connection ask for
GET /PSBlock
and watch the results, it should be something like this:Answer:
To solve this issue update the IPMI firmware to the latest version. The firmware is specific to your IPMI controller, so you should get the specified in Supermicro website.
Then after updating the firmware change your passwords.