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.
# 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
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
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.
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.
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.
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
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.
