Archives For June 2013

Me and two colleagues went to Amsterdam today, for a 1-day CFEngine-3 training. I’ve worked with configuration management before (Puppet), and my goal is to explore alternatives to be able to pick the right tool. Today’s quick overview training was a nice opportunity to get into CFEngine and meet some people behind the scenes.

Impression of CFEngine training

Impression of CFEngine training


Diego Zamboni, author of the book Learning CFEngine 3, taught us what the concepts behind CFEngine are, how the language is build and how to get started. He demo’ed a lot of things and answered all of our questions. It was a very informative training that really inspired me.

What surprised me most, was that CFEngine is actually a pretty nice monitoring tool! A smart one, because it is either able to fix things, or is able to report it. All in all, I’ve to say I’m really impressed by CFEngine 3.5. We have now inspiration to create a good plan and then start working on implementing it. Looking forward to it!

Thanks Diego and Carsten for this training and the nice drinks we had afterwards 🙂

LPICLevel3_logoToday I passed the senior level LPIC-301 core exam. I am now LPIC-3 certified!

The exam objectives are OpenLDAP and Capacity planning. Both of which I used in past projects, so I was already pretty familiar with them. In my current job I came across AD integration and Kerberos, and those were objectives as well.

In the past weeks I went through every detail of the objectives and learned some new stuff. My score on the exam was 690/800.

I’ve mainly used the IBM Developer Works LPIC-3 website, OpenLDAP manual and the LPIC-3 page hosted at As always, the man pages of the Linux commands are very useful.

After studying the materials, it’s just practice, practice, practice. I’ve setup an environment in which I could test and play with the tools and that worked really well for me.

The Security LPIC-3 specialty exam is the next one on my wish-list. I’ve already started to study it because I’m really interested in these topics.

Later this year I’ll be doing the RedHat RHCSA and RHCE exams. I’ve booked them on the same day, so that’s probably getting a bit touch 😉 But I’m looking forward to it and enjoy the steps on the certification road.

As discussed in a previous post, multi-factor authentication really makes things more secure. Let’s see how we can secure services like SSH and the Gnome desktop with multi-factor authentication.

The Google Authenticator project provides a PAM module than can be integrated with your Linux server or desktop. This PAM module is designed for for home and other small environments. There is no central management of keys, and the configuration is saved in each users home folder. I’ve successfully deployed this on my home server (a Raspberry Pi) and on my work laptop.

When using a Debian-like OS, you can install it with a one-liner

apt-get install libpam-google-authenticator

But note the packaged version is old and does not support all documented options. Below I talk about the ‘nullok’ option, but that is not supported in the packaged version. You then see this error:

sshd(pam_google_authenticator)[884]: Unrecognized option "nullok"
sshd(pam_google_authenticator)[887]: Failed to read "/home/pi/.google_authenticator"

That’s why I suggest building from source, as this can be done quickly:

apt-get remove libpam-google-authenticator
apt-get install libpam0g-dev libqrencode3
cd ~
tar jvxf libpam-google-authenticator-1.0-source.tar.bz2
cd libpam-google-authenticator-1.0/
make install

Open a shell for a user you want to enable two-factor authentication for and run ‘google-authenticator’ to configure.

Configure Google Authenticator

Configure Google Authenticator


Configure your Mobile device
Install the ‘Google Authenticator’ app and just scan the QR-code. It will automatically configure itself and start displaying verification codes.

Verification codes displayed by app

Verification codes displayed by app

You should notice it’ll display new codes each 30 seconds.

Configure SSH
Two files need to be edited in order to enable two-factor authentication in SSH.

vim /etc/pam.d/sshd

Add this line:

auth required nullok

Where to put this in the file? That depends. When you put it at the top, SSH will first ask a verification code, then a password. To me this sounds unlogical, so I placed it just below this line:

@include common-auth

The ‘nullok’ option, by the way, tells PAM whenever no config for 2-factor authentication is found, it should just ignore it. If you want SSH logins to fail, when no two-factor authentication is configured, you can delete the option. Be warned to at least config it for one user, or you will be locked out of your server.

Now tel SSH to ask for the verification code:

vim /etc/ssh/sshd_config

Edit the setting, it’s probably set to ‘no’:

ChallengeResponseAuthentication yes

Now all you need to do is restart SSH. Keep a spare SSH session logged-in, just in case.

/etc/init.d/ssh restart
SSH 2-factor authentication in action

SSH two-factor authentication in action

SSH will now ask for a verification code when you do an interactive login. When a certificate is used, no verification code is asked.

Configuring Ubuntu Desktop
The Ubuntu desktop can also ask for a verification code. Just edit one file:

vim /etc/pam.d/lightdm

And add this line, just like SSH:

auth required nullok

The login screen should now ask for a verification code. It looks like:

Two-factor authentication in Ubuntu

Two-factor authentication in Ubuntu

You can setup any PAM service like this, the basic principles are all the same.

Skip two-factor authentication if logging in from the local network
At first this is all very cool, but soon it becomes a bit annoying, too. When I SSH from a local network, I just don’t want to enter the verification code because I trust my local network. When I SSH from remote, a verification code is required. One way to arrange that, is always login with certificates. But there is another way to configure it: using the pam_access module. Try this config:

auth [success=1 default=ignore] accessfile=/etc/security/access-local.conf
auth required nullok

The config file, /etc/security/access-local.conf looks like:

# Two-factor can be skipped on local network
 + : ALL :
 + : ALL : LOCAL
 - : ALL : ALL

Local login attempts from will not require two-factor authentication, while all others do.

Two-factor only for users of a certain group
You can even enable two-factor authentication only for users of a certain group. Say, you’d want only users in the ‘sudo’ group to do use two-factor authentication. You could use:

auth [success=1 default=ignore] user notingroup sudo
auth required nullok

By the way, “[success=1 default=ignore]” in PAM means: on success, skip the next 1 auth provider (two-factor authentication), on failure, just pretend it didn’t happen.

Moving the config outside the user’s home
Some people prefer not to store the authentication data in the user’s home directory. You can do that using the ‘secret’ parameter:

mkdir -p /var/lib/google-authenticator/
mv ~remibergsma/.google_authenticator /var/lib/google-authenticator/remibergsma
chown root.root /var/lib/google-authenticator/*

The PAM recipe will then become:

auth required nullok user=root secret=/var/lib/google-authenticator/${USER}

As you’ve seen, PAM is very flexible. You can write almost anything you want.

Try the Google Authenticator two-factor authentication. It’s free and adds another security layer to your home server.

The recent article on Ars Technica, Anatomy of a hack: How crackers ransack passwords like “qeadzcwrsfxv1331” made me realize again how weak password authentication is. True, in this case the MD5 hashes were known, but still it’s only a single factor. Imagine what happens when you reuse a password on multiple sites, and one of them stores it as MD5 (or SHA-1, even plain-text) and gets comprimised.

What’s interesting in the above article, is that brute-force attacks only work up to 6 to 7 characters (depending on the hardware available) because of the so-called “exponential wall of brute-force cracking” caused by the exponentially increasing number of guesses each additional character creates. Although project Erebus v 2.5 already demonstrated brute-forcing any 8 character password in just 12 hours with a 8 GPU cluster. This, however, does not mean a 9+ character password is safe. In fact, passwords of 16 characters are easily cracked when using the right techniques.

One of the techniques used to crack the passwords, is to use common patterns. These patterns were learned from past security breaches. Especially the famous RockYou breach, in which they lost millions of passwords in plain-text. This revealed many passwords people use in real life and gave an interesting view on how people choose passwords. Not only are these passwords added to the word lists used to crack passwords today (500 hundred million words is no exception), patterns were developed as well to help efficient cracking of more complex longer passwords.

A simple example of such a pattern is: Winter09 (word starting with a capital, two digits added to the end, all lowercase in the middle). Don’t think ‘W1nt3r09’ is safer, as this is also a pattern: i is replaced by 1, e with 3, etc. Huge collections of patterns can be found online.

You can now imagine why you should use random password instead. Random strings are the best, because they can only be brute-forced. When you take a 12 character random password, such as 45zCpJEq8bAf, you’ll be safe. The longer, the better, but W6Bf7TwFfRhM3xQ9FYckCYs3VpY38yJR is much harder to remember, of course. Fortunately, tools exist to help you.

Password managers
Use a secure password manager to help you remember strong passwords. I say secure, because the password managers in browsers are not secure (at all). Services like 1Password and LastPass provide an encrypted vault in which you can store your passwords, protected by a secure, random master-password. They integrate in your browser, and automatically fill-in your site-specific, strong, password. This password can now be much longer, since you don’t have to remember it. All you have to remember is the master-password.

Everything is encrypted locally, before sending to their servers, making it useless data without your master-password. It’s automatically sync’ed across your devices (laptop, desktop, mobile, tablet, etc). Check it out, it’s great.

Google Authenticator

Google Authenticator

Multi-facor authentication
Now that you have safe passwords, and a way to manage them, I’d like to suggest another technique called ‘multi-factor authentication‘. Multi-factor authentication (also Two-factor authentication, TFA, T-FA or 2FA) is an approach to authentication which requires the presentation of two or more of the three authentication factors: a knowledge factor (“something the user knows”), a possession factor (“something the user has”), and an inherence factor (“something the user is”).

Both 1Password and LastPass support two-factor authentication. This can eiher be hardware device (RSA, Yubikey, etc) or software (like Google Authenticator). Sometimes verification codes are send as SMS-messages. When two-factor authentication is enabled, you need to have a master-password and a verification key to access your vault. That’s great security for your passwords!

Final thing you should do, is protect your e-mail address with two-factor authentication, as well. Some e-mail providers offer this service. Google’s Gmail even offers it for free. Why this is important? Because most sites send a ‘password lost’ e-mail to verify a password change. So your passwords are only as secure as your e-mail password. With an added security layer, this becomes much harder to crack. You now probably also understand why you shouldn’t reuse your e-mail password on other sites..

I hope this blog brings in some inspiration to upgrade your online security!