Cant access Dell BMC IPMI Over IP

dellelectrical-poweripmiremote-access

I have Dell R210 with iDRAC BMC (new name for old BMC). Which is on-board feature with shared NIC (I believe). Server is on colocation and I didnt set it up before sent there… So I asked for the remote hands to setup IPMI Over IP. They enabled it, set the IP and everything. The IP is different than main box IP. Also the box is cabled to NIC1 and the BMC supposed to share it (am I right?)

I can see new IP in the Open Server Administrator (installed on the box).

I tried Supermicro IPMI tool and I tried Dell ipmish.exe

command like this

ipmish -ip xxx -u root -p calvin sysinfo

gives BMC is not detected

What could be wrong? is there a diagnostics tool I can try? It must be something obvious. I just never used things like that before….

P.S. I read something about encryptions key in the Dell docs. But I understand that is for encrypted IPMI 2.0 and ipmish can use IPMI 1.5 without encryption.

Best Answer

Are you sure that the remote hands setup BMC to NIC instead of SERIAL?

Related Solutions

Security – Securing a SuperMicro IPMI BMC

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.

Using Supermicro IPMI behind a Proxy

It sounds like a VPN might actually be your best bet. Have an ACL on the router so that the only non-local traffic has to traverse the VPN and you're done. Very simple and secure as well as easy to manage.

Best Answer

Related Solutions

Security – Securing a SuperMicro IPMI BMC

Using Supermicro IPMI behind a Proxy

Related Topic