pantz.org banner
Reset HP iLo, Dell DRAC, and IBM remote management accounts
Posted on 07-25-2013 01:32:11 UTC | Updated on 12-29-2013 23:37:01 UTC
Section: /hardware/ipmi/ | Permanent Link

Here is a easy way to reset the admin account on differnet remote management interfaces. This has been tried on HP iLO interfaces, Dell DRAC interfaces, IBM 3650 and Bladecenters. It is likely to work on any system that uses a Baseboard Management Controller, and uses the above mentioned management interfaces.

This reset process will use the Intelligent Platform Management Interface (IPMI) interface on a running Linux machine. All tht is needed is the installation of a few kernel drivers and the program ipmitool.

For the Impatient

# Install on RedHat/CentOS as root
yum install OpenIPMI-tools
# or 
# Install on Debian/Ubuntu
sudo apt-get install ipmitool

# Load kernel modules
modprobe ipmi_msghandler
modprobe ipmi_devintf
modprobe ipmi_si

# Find admin account ID #
ipmitool -v user list 1

# Reset account matched to ID #3 back to password "admin" 
ipmitool -v user enable 3
ipmitool -v user set password 3 admin

Installing IPMI Drivers

To make this work you need to install the Open IPMI tools package from whatever distribution you have. In Redhat/CentOS this package is called "OpenIPMI-tools". In Debian/Ubuntu it's called "ipmitool". Those are just examples. Search your distro's packages to find it.

# Install on RedHat/CentOS as root
yum install OpenIPMI-tools

# Install on Debian/Ubuntu
sudo apt-get install ipmitool

Load the IPMI drivers

Now that OpenIPMI is loaded we need to load the kernel modules. Do the following as root. If they are already loaded proceed to the next step.

 
modprobe ipmi_msghandler
modprobe ipmi_devintf
modprobe ipmi_si

You may also just be able to start the IPMI service if it is installed on your machine. Something like "service ipmi start". One way or another you have to get these kernel modules loaded to be able to access /dev/ipmi0 which ipmitool uses to talk to the BMC.

Find the Account

Now that the kernel modules are loaded let's list the accounts that exist on the management interface.

ipmitool -v user list 1

The above uses channel 1. If you don't find any users on that channel try other numbers. I have yet to see channel 1 fail on lots of different manufactures devices.

In the output you will see the account names. Find the account name you want to reset and match it to the ID number to it's left. We will use the ID number to tell the controller which account to reset.

Resetting the Password

Now that we have the ID number we can run the reset command. My example will use an HP iLo admin account which is by default ID 3. This command will reset the password back to the factory default of "admin". If need be run the user enable command for the user first if it is not an administrative account. This is not needed if the account your setting the password for is already a privileged account.

 
ipmitool -v user enable 3
ipmitool -v user set password 3 admin

That should have reset the account back to the password you gave it. Try to login and see.

Resetting the password one other way

Rapid7 did a great evaluation on how bad IPMI security is. The best portion of this article shows how to get administrative access to the IPMI interface remotely by just issuing one type of command with IPMI tool. You can use Cipher 0 to list the users an then change the password of a user that was found. Then you can elevate the privs of the user if they are already not an administrator. The following is an example using info taken from the Rapid7 site. It changes the password for the Admin user(user 2) to admin. Take the time to read the whole article it is fantastic.

 
ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Admin -P BSPassword user set password 2 admin

Parting Words and Suggestions

Del.icio.us! | Digg Me! | Reddit!

Related stories

IPMI conflicts with RPC
Posted on 09-18-2008 02:46:52 UTC | Updated on 09-18-2008 03:38:13 UTC
Section: /hardware/ipmi/ | Permanent Link

I have a friend that had a really weird problem with a program that used RPC. Every once and a while the program that used RPC would open a port and tell the client to contact on the port it just opened. The client would try to do that and fail. Problem was this only happened randomly. Random problems are a pain to track down. The problem was eventually tracked down. The following is a description of what it was and the fix for it.

RPC uses a range of ports on Linux to allow clients to contact the server. By default these are 650-1023. RPC will pick a port at random from the range of ports. That is as long as port in the range is not already being used. Their servers have built in Baseband Management Controllers (BMC). BMC communicates with a BMC management utility (BMU) on a remote client using IPMI protocols. The BMC for the servers are in band and use the network controller on the motherboard to send and recieve data. The ports the BMC uses are 623 and 664.The thing is the controllers don't run any software in Linux to do this. So how do they work you ask? Well, they intercept the traffic on those ports before it gets into the OS's network stack. That means any data you send to those ports on those machines the OS will never see. You won't see it on any network sniffer on that machine at all. So any machine that RPC told to connect to it on 664 was failing. But it was random because that port would only come up from the pool of ports randomly.

Now that you know what the problem is how do you solve it? You could just run a dummy process out of xinetd to listen on port 664 (and 623 if your RPC uses ports that low) and be done with it.

You could also try to bump up your port range to start at 665. That can be done on some 2.6 linux kernels in proc.

echo 665 > /proc/sys/sunrpc/min_resvport

Restart your daemons that use RPC. If that works then you can put line sunrpc.min_resvport=665 in /etc/sysctl.conf so it sets on reboot. I have heard that some of the latest Linux kernels are going to up the port range to start after 665 to avoid this problem in the future.

RPC is most notably used by NFS. This can cause NFS mounts to fail randomly or just any other program that uses RPC.

Del.icio.us! | Digg Me! | Reddit!

Related stories


RSS Feed RSS feed logo
About


3com
3ware
alsa
alsactl
alsamixer
amd
android
apache
areca
arm
ati
auditd
awk
badblocks
bash
bind
bios
bonnie
cable
carp
cat5
cdrom
cellphone
centos
chart
chrome
cifs
cisco
cloudera
comcast
commands
comodo
compiz-fusion
corsair
cpufreq
cpufrequtils
cpuspeed
cron
crontab
crossover
cu
cups
cvs
database
dbus
dd
dd_rescue
ddclient
debian
decimal
dhclient
dhcp
diagnostic
diskexplorer
disks
dkim
dns
dos
dovecot
drac
dsniff
dvdauthor
e-mail
echo
editor
emerald
ethernet
expect
ext3
ext4
fat32
fedora
fetchmail
fiber
filesystems
firefox
firewall
flac
flexlm
floppy
flowtools
fonts
format
freebsd
ftp
gdm
gmail
gnome
greasemonkey
greylisting
growisofs
grub
hacking
hadoop
harddrive
hba
hex
hfsc
html
html5
http
https
idl
ie
ilo
intel
ios
iperf
ipmi
iptables
ipv6
irix
javascript
kde
kernel
kickstart
kmail
kprinter
krecord
kubuntu
kvm
lame
ldap
linux
logfile
lp
lpq
lpr
maradns
matlab
memory
mencoder
mhdd
mkinitrd
mkisofs
moinmoin
motherboard
mouse
movemail
mplayer
multitail
mutt
myodbc
mysql
mythtv
nagios
nameserver
netflix
netflow
nginx
nic
ntfs
ntp
nvidia
odbc
openbsd
openntpd
openoffice
openssh
openssl
opteron
parted
partimage
patch
perl
pf
pfflowd
pfsync
photorec
php
pop3
pop3s
ports
postfix
power
procmail
proftpd
proxy
pulseaudio
putty
pxe
python
qemu
r-studio
raid
recovery
redhat
router
rpc
rsync
ruby
saltstack
samba
schedule
screen
scsi
seagate
seatools
sed
sendmail
sgi
shell
siw
smtp
snort
solaris
soundcard
sox
spam
spamd
spf
sql
sqlite
squid
srs
ssh
ssh.com
ssl
su
subnet
subversion
sudo
sun
supermicro
switches
symbols
syslinux
syslog
systemrescuecd
t1
tcpip
tcpwrappers
telnet
terminal
testdisk
tftp
thttpd
thunderbird
timezone
ting
tls
tools
tr
trac
tuning
tunnel
ubuntu
unbound
vi
vpn
wget
wiki
windows
windowsxp
wireless
wpa_supplicant
x
xauth
xfree86
xfs
xinearama
xmms
youtube
zdump
zeromq
zic
zlib