September 2011


Having recently taken delivery of a new VPS, I logged on and immediately set about, securing the setup.

Changing the root password sounds obvious, but there are alternatives:

  • Blocking root access via ssh.
  • Turning off password authentication and using known keys only.

Doing either of the above might have you thinking that the strong password the datacentre setup for you can now stay – but wait!

VPS, cloud servers, and some dedicated servers are often provisioned from templates.

Those templates may have set the password early in the build process, before secure hashing was fully configured.

 

At a glance – is the root password in /etc/shadow sufficiently hashed?

Here is an example which shares some characteristics with what I found on my newly provisioned server:

root:Npge08pfz4wuk:15000:0:730:7:::

If you are accustomed to working with /etc/passwd and /etc/shadow, you will have spotted the problem already …

The second field is way too short!

It should instead look something like this:

root:$6$OBEzW/iiKRe/ww$vfnfEFg41l1dK4zE4YM9PiRKs7ic5lvg1WgFWgi.VF0O/MYCZPELqedCmSybFQ5.0twYbc1fU6VnXqdACqELj0:15000:0:730:7:::

The second field beginning $6 indicates that the password has been hashed using SHA2 (512), often abbreviated to sha512

If you just want to printout the shadow password entries for those users that can login then use this command:

egrep -v '.*:\*|:\!' /etc/shadow | awk -F: '{print $2}'

and just double-check that all lines output begin $6

If not, then issue a passwd command and input a new password for the problem user (root or otherwise)

Providing your system is not outdated the proper sha512 hashing should be in place. When you regenerate the password with passwd, you should now see the second field in /etc/shadow a lot wider, and no longer a security issue.

 

The third field in /etc/shadow – pre-populated for you during build:

Days since Jan 1, 1970 that password was last changed

That third field will probably be set to 15000 or a number of that magnitude.

Too large a number would see ‘in future’ complaints being registered in a log file in /var/log/

 

Links and Further reading:

The link below gives an example of using mkpasswd to fix things.

However do be aware that echoing passwords to pipe into a secondary command is not considered ideal, due to the process details being visible in plain text to other users who might be running ‘top’

Python can also be used to generate replacement passwords – although again be careful what might be viewable by other users whilst your process is running:

python -c "import crypt, getpass, pwd; print crypt.crypt('passwordunhashed', '\$6\$SALTsalt\$')"

/proc/sys/kernel/perf_event_paranoid is a Linux kernel flag with settings as follows:

  1. disallow cpu events for unpriv
  2. disallow kernel profiling for unpriv

There are also values 0 (disallow raw tracepoint access for unpriv) and -1 (not paranoid at all)

For virtual machines in VirtualBox 3.1, it is recommended that, if your machine hardware supports ‘Performance Events’, then you block kernel profiling access to VirtualBox user (unprivileged).

perf_event_paranoid gets 2

set perf_event_paranoid to 2

(Note: You must be root / privileged user to make the change permanently, so su or sudo as appropriate)

Not all VirtualBox users will receive a warning message from VirtualBox 3.1, it depends on how new the processor is in your machine. Newer the processor, more likely it will support ‘Performance Events’ / PEBS.

Query dmesg - see if 'Performance Events' supported in hardware

grep of dmesg

Jargon 1 – PEBS:

Precise Event-Based Sampling

Jargon 2 – IBS:

Instruction-based sampling (AMD specific), an idea similar to PEBS

Note: Some versions of VirtualBox 3.1 incorrectly refer to perf_counter_paranoid (mistake) instead of perf_event_paranoid. So if you see a message suggesting you should:

echo 2 > /proc/sys/kernel/perf_counter_paranoid

then instead look at the image I provided and use the correct /proc/sys/kernel/perf_event_paranoid

Links and Further Reading:

For now it is important to not use hardware-aided performance counters on the host while running VMs with VirtualBox, therefore the warning.

Source: Frank Mehnert in VirtualBox forums

Argument parsing in ANSI C has several helper functions.

The atoi() function is commonly used.

In C99 a new atoll() function was created.

On GNU / Linux systems /usr/bin/c99 will compile your ANSI C to C99 standard.

If you use /usr/bin/c99 and asprintf() function in your code, then you might want to include the following line, just before your include <stdio.h>

#define _GNU_SOURCE

Having that ‘# define’ will help you avoid warnings such as:

warning: implicit declaration of function ‘asprintf’

Links: