Ubuntu shows “No Bootable Device” after installation in UEFI mode

When doing a fresh install of Ubuntu 16.04, or any other version of Ubuntu or Linux, after the install you might get your laptop or desktop machine not booting the installed OS, but instead returning “No Bootable Device” message, if laptop is set to UEFI mode.

You might be presented with this image after rebooting your laptop, after a successful OS install.

No Bootable Device message
No Bootable Device message

To resolve this issue reboot your laptop and enter BIOS.

There go to “Select and UEFI file as trusted for executing:” and press Enter key.

BIOS Select UEFI file

Once there choose HDD1.

BIOS select Hard Drive

Then choose <EFI>.

BIOS select EFI

Then you should be able to see <ubuntu> or possibly some other name of your Linux installation.

BIOS select Ubuntu

Then choose shimx64.efi

BIOS select shimx64

And then choose Yes when asked if you want to add this file to allowable database.

BIOS add file to database

Reboot your laptop and you should now be able to boot your OS normally.

VirtualBox returns “Kernel driver not installed” on Ubuntu

When trying to run VirtualBox on Ubuntu 16.04, or some other version of Linux, you might get a following type an error message, when trying to start a virtual machine, you just created on a fresh installation of VirtualBox.

VirtualBox might return error saying that it failed to open a session for  the virtual machine.

Details of error message will say that virtual machine has terminated unexpectedly during startup with exit code 1 (0x1).

VirtualBox failed session message
VirtualBox failed session message

You will also get a “Kernel driver not installed (rc=-1908” message.

VirtualBox Kernel driver error
VirtualBox Kernel driver error

Error will say “The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv.”

Error message will ask you to try to reinstall the kernel module by executing /sbin/vboxconfig as root, to reinstall the module, which could fail to complete successfully when you try to run the command in terminal.

One of the possible causes of this type of behavior is that you have Secure Boot enabled in your BIOS on the host machine, which is preventing the install of third-party drivers, and causing issues with VirtualBox installation, which fails to install all kernel modules.

To resolve this error, disable Secure Boot in your BIOS, and then try to run /sbin/vboxconfig command as root, or reinstall VirtualBox, with Secure Boot disabled, to install all the necessary modules.

VMware rename CentOS 7 NIC names

CentOS 7 virtual machines on VMware will by default use predictable network device naming for network interfaces on the machine, causing their names to be in enoXXXXXXXX format.

This will cause issues when adding 10 or more additional IPs in WHM, as network interface name will be longer than the 15 characters.

Maximum length supported for network interface name on cPanel servers is 15 characters.

When starting ipaliases service, only first 9 additional IPs will be added, and for rest of the IPs error “RTNETLINK answers: Numerical result out of range” will be shown, and IPs will not be shown in ip addr, or ifconfig output.

[[email protected] ~]# /scripts/restartsrv_ipaliases
Waiting for "ipaliases" to stop ...finished.
Waiting for "ipaliases" to start ...finished.
Service Status
Startup Log
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Bringing up eno33559296:cp14 RTNETLINK answers: Numerical
result out of range
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Routing 204.93.248.69 RTNETLINK answers: Invalid argument
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Bringing up eno33559296:cp15 RTNETLINK answers: Numerical
result out of range
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Routing 204.93.248.70 RTNETLINK answers: Invalid argument
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com systemd[1]: Started cPanel IP aliases service.
Log Messages
 Oct 3 20:29:20 server ipaliases: [FAILED]
 Oct 3 20:29:20 server ipaliases: Routing x.x.x.x RTNETLINK answers: Invalid argument
 Oct 3 20:29:20 server ipaliases: [FAILED]
 Oct 3 20:29:20 server ipaliases: Bringing up eno33559296:cp15 RTNETLINK answers: Numerical result out of range

To resolve the issues, network devices can be renamed back to old ethX type of naming.

To rename network devices to old names following steps are needed.

  1. Edit /etc/sysconfig/grub
  2. Update GRUB configuration with new kernel parameters
  3. Rename network files
  4. Edit renamed network files
  5. Reboot the server

To rename devices do the following

Edit /etc/sysconfig/grub

Find a line containing “GRUB_CMDLINE_LINUX”, and append “net.ifnames=0 biosdevname=0“ on the line.

File should look something like this.

[[email protected] ~]# cat /etc/sysconfig/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=myvg/rootvol rhgb quiet net.ifnames=0 biosdevname=0"
GRUB_DISABLE_RECOVERY="true"

Update GRUB configuration with new kernel parameters, with following command:

grub2-mkconfig -o /boot/grub2/grub.cfg

Rename enoXXXXXXXX network files of all interfaces to ethX network file.

For example:

mv /etc/sysconfig/network-scripts/ifcfg-eno16777984 /etc/sysconfig/network-scripts/ifcfg-eth0
mv /etc/sysconfig/network-scripts/ifcfg-eno33557248 /etc/sysconfig/network-scripts/ifcfg-eth1

This will rename file ifcfg-eno16777984, to ifcfg-eth0, renaming interface eno16777984 to eth0, and will rename file ifcfg-eno33557248, to ifcfg-eth1, renaming interface eno33557248, to eth1.

Edit new ethX network files.

Replace value of both NAME and DEVICE field with new ethX names.

File should look something like this.

[[email protected] ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
BOOTPROTO=static
NAME=eth0
UUID=b02f4abf-f6da-4ad4-b800-4abf4fe1d50d
DEVICE=eth0
ONBOOT=yes
NM_CONTROLLED=yes
IPADDR=x.x.x.x
NETMASK=255.255.255.0
GATEWAY=x.x.x.1

Reboot the server, and you should now see network interfaces using old CentOS 6 style names.

Additional changes for cPanel servers

Change public network interface in Basic cPanel & WHM Setup.

Go to Home »Server Configuration »Basic cPanel & WHM Setup and change public interface from old enoXXXXXXXX to new ethX name.

Change public interface to new name
Change public interface to new name

Restart ipaliases service with /scripts/restartsrv_ipaliases.

Yum and curl returning “Illegal instruction (core dumped)” on Xen

When running yum or curl commands on a CentOS 6 XenServer Virtual Machine you might be getting an “Illegal instruction (core dumped)” error returned in your console output.

[email protected] [~]# yum update
Loaded plugins: fastestmirror, rhnplugin
Setting up Update Process
Loading mirror speeds from cached hostfile
 * base: mirror.us.leaseweb.net
 * cloudlinux-x86_64-server-6: xmlrpc.cln.cloudlinux.com
 * extras: mirror.teklinks.com
 * updates: mirror.teklinks.com
Illegal instruction (core dumped)

The issue is due to Python attempting to execute a CPU opcode advertised as available by the server’s host node virtualization system (XEN), but is not actually supported by the host node’s hardware.

Workaround

Issue can be resolved by running export NSS_DISABLE_HW_AES=1, and then running yum update, to update to newer packages, after which issue should not be happening anymore.

[email protected] [~]# export NSS_DISABLE_HW_AES=1
[email protected] [~]# yum -y update
References:

https://www.centos.org/forums/viewtopic.php?t=58002

https://forums.cpanel.net/threads/kvm-xen-hw_aes-detection-issues-yum-update-illegal-instruction.551681/

How to check for, and clean Ebury SSH Rootkit

What is Ebury

Ebury is a SSH Rootkit, and password sniffer which steals SSH login credentials from incoming and outgoing SSH connections, and also steals private SSH keys stored on the infected system.

Ebury can replace SSH binaries, and shared library files used by executables like sshd, wget, curl, …

How to detect Ebury on a system

From version 1.5 Ebury uses Unix domain sockets for interprocess communication.

Malicious process can be seen using netstat -plan | grep atd.

This command should not return any results on clean systems.

[email protected] [~]# netstat -plan | grep atd 
unix 2 [ ACC ] STREAM LISTENING 103713 8119/atd @/tmp/dbus-ZP7tFO4xsL

Atd should not be listening on any network port or socket.

Ebury will also place additional shared library files, and patch installed libkeyutils file to link to those files.

Files usually found on Ebury infected machines can be one or more of the following:

/lib64/tls/libkeyutils.so.1.5
/lib64/tls/libkeyutils.so.1
/lib64/libns2.so
/lib64/libns5.so
/lib64/libkeyutils.so.1.3
/lib64/libpw3.so

If any of those files exist, check if the files were provided by any rpm using rpm -qf command.

[email protected] [~]# rpm -qf /lib64/tls/libkeyutils.so.1.5
file /lib64/tls/libkeyutils.so.1.5 is not owned by any package

On clean system command should return the name of the rpm package which installed that file.

[email protected] [/lib]# rpm -qf libkeyutils.so.1.3
keyutils-libs-1.4-5.el6.i686
Script to check for suspicious files, and processes

Here is a small script that can be used to check for possible Ebury infection.

#!/bin/bash

if [[ `netstat -pan | grep -w atd` ]]; then
    printf "This server appears to have atd process listening on Unix socket or network port\nCheck server for possible Ebury infection\n\n===\n`netstat -pan | grep -w atd`\n===\n\n"
fi

declare -a file_list=("/lib64/tls/libkeyutils.so.1.5" "/lib64/tls/libkeyutils.so.1" "/lib64/libns2.so" "/lib64/libns5.so" "/lib64/libkeyutils.so.1.3" "/lib64/libpw3.so"); 

for file in "${file_list[@]}"; do 
    if [[ -f $file ]]; then
        if [[ `rpm -qf $file` == *'not owned'* ]]; then
            printf "===\nFile $file is not owned by any RPM package, and there is a possible rootkit infection\nCheck server for possible Ebury infection\n===\n"
        fi
    fi
done

Save a script like check4ebury.sh on your system, and run with bash check4ebury.sh

On an infected system, command will return something like this:

[[email protected] ~]# bash /root/check4ebury.sh
This server appears to have atd process listening on Unix socket or network port
Check server for possible Ebury
infection

===
unix 2 [ ACC ] STREAM LISTENING 1278995234 127563/atd @/tmp/dbus-BmCahxCc3k
===

===
File /lib64/tls/libkeyutils.so.1.5 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
===
File /lib64/tls/libkeyutils.so.1 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
[[email protected] ~]#

NOTE: Suspicious processes and fileS might not be visible over SSH connections


Some variants of Ebury will hide suspicious processes and files, if you are checking the system over SSH connection (link).

In cases like that, checks will need to be done over local terminal, remote management console, or through screen session, for all processes and files to be visible.

If you are unable to connect to the server without SSH, install screen with yum -y install screen, and run check4ebury.sh from screen session, to double check for any possible infection.

In some cases when checks are done over SSH, you might be getting different result if you check for processes and files over screen session.

In this example script doesn’t return any signs of infection when run directly from SSH session, but shows running processes and files when run through a screen session.

[[email protected] ~]# /root/check4ebury.sh
[[email protected] ~]# screen -dmS ebury bash -c '/root/check4ebury.sh >> test'; sleep 30; cat test
This server appears to have atd process listening on Unix socket or network port
Check server for possible Ebury
infection

===
unix 2 [ ACC ] STREAM LISTENING 1278995234 127563/atd @/tmp/dbus-BmCahxCc3k
===

===
File /lib64/tls/libkeyutils.so.1.5 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
===
File /lib64/tls/libkeyutils.so.1 is not owned by any RPM package, and there is a possible rootkit infection
Check
server for possible Ebury infection
===
[[email protected] ~]#
How to clean Ebury infection

Most important thing to note is, that in case of root level infections like these ones, the only safe way is to do a complete server rebuild after you clean the infection, and make any necessary backups.

In order to clean Ebury infection, you need to kill the processes you found with netstat, remove suspicious library files, and reinstall keyutils-libs* rpm package. It would be also advisable to reinstall SSH packages.

Steps that can be taken to clean the system:

Check the actual keyutils-libs RPM packages you have installed on your system, and download them before removing any files from the system, as it is possible in some cases that some of the infected files are used by yum, curl, wget, and that you won’t be able to do install with yum after removing the files, or use curl, or wget to download RPMs for install.

  • Kill all SSH connections with killall sshd.
  • Kill the atd processes listening over Unix socket with kill -9 `lsof -Pt /usr/sbin/atd`.
  • Remove the suspicious files you found, that were not connected with any rpm package.
  • Reinstall keyutils-libs and SSH packages, preferably with rpm -ivh --replacefiles --replacepkgs on the predownloaded packages, but in most cases you can use yum:
    yum -y reinstall openssh* libssh* keyutils-libs*

After you have reinstalled necessary packages, change your root password, and all SSH keys on the server, and reboot the server to check if suspicious processes and files will return after it.

If possible, always do a full server rebuild, even if no signs of infection exist after reboot.

Avoid cleaning the infection over SSH connection

It would be advisable to kill all SSH connections that exist on the system you are about to clean, so you should be doing it while connected to the server some other way, but if you need to clean the server over SSH, a script like this can be used to accomplish that (you need to replace the files being referenced in the script, with the files you have found on your own system)

#!/bin/bash

killall sshd; 
kill -9 `lsof -Pt /usr/sbin/atd`; 
rm -f /lib64/tls/libkeyutils.so.1.5; 
rm -f /lib64/tls/libkeyutils.so.1; 
yum -y reinstall openssh* libssh* keyutils-libs*; 
service sshd start
References:

https://www.cert-bund.de/ebury-faq

https://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/

https://forums.cpanel.net/threads/ebury-rootkit-backdoor-trojan.396081/

https://documentation.cpanel.net/display/CKB/Determine+Your+System’s+Status