Tag Archives: security

Why Heartbleed did more to increase security than any friendly advice you ever gave

Doing IT operations during these heartbleeding times isn’t easy. If you’ve been following even remotely the Heartbleed saga, you know it’s a critial design flaw in the most popular implementation of the most popular encryption protocol, OpenSSL. To be plain, most of the credentials you held in the recent past are potentially compromised, since even if eveyone are now updated and protected, your credentials might have been stolen beforehand.

If you indeed do operations, you know it gets painful logging into another web console of some service provider to see a warning banner with the latest security advisory about Heartbleed. It usually goes in the same spirit of “please reset all your passwords, please recycle all your keys, please reissue all your certificates”. And the more responsible of us do: We reset all our passwords, we annihilate the deployment keys we used for the last year, and certificates older than the buildings we work in are being reissued. We update and patch all our servers, and we have a lot of servers. We mass-email users to change their login credentials, and go on a frenzy of forcing everyone to enable 2-factor authentication and security questions. And we’re probably just getting started.

We press hard, and the users, for once as terrified as we are, are being cooperative. Hours are spent on memorizing, forgetting and resetting new passwords, patching servers, and fixing outages caused by revoked keys and certificates. Everyone gets a crash course in encryption. Security is on everyone’s agenda. Users who thought certificates were for gifts now ask about SSL. Naturally, educating, updating, revoking and reissuing is time consuming, and the regular workday goes down the drain. Yet another compromised vendor or service, yet another unpatched server.

And here you should stop and think about what you are going through: if you do value security with more than just your lips, you realize this is one of the best things that happened to your operation. You are basically forced to do the very same things you knew you should have been doing all along, but always left for later. Recycling my passwords? New ones are hard to remember! Reissuing certificates on a regular basis? What kind of a sadist would put that in OpenVPN’s Wiki! Changing deployment keys? Doesn’t look amazing on anyone’s resume! Just stop and try to remember how many times, before Heartbleed, have your users/coworkers/clients cared about the same thing you do? How many times have they came to you asking you about updating a server, instead of you suggesting to them in a friendly manner they should really apply that last year of updates on their corporate laptop?

Heartbleed is the best thing that happened to network security since firewalls: Very few credentials were likely compromised via Heartbleed, but everyone is rotating their credentials and protecting themselves from more common vulnerabilities and leaked passwords. It’s hard to appreciate it between all the password resets, but when you are done with it all, sit back and have a beer. To Heartbleed!




1 Comment

Filed under #!

TrueCrypt + BTRFS

TrueCrypt is the weapon of choice for easy end-to-end filesystem encryption, and conveniently supports FAT, NTFS, and EXT2/3/4 out of the box. This means all you have to do is specify the filesystem during the creation of the encrypted volume, and it will be automatically mounted when the volume is unlocked. That’s great!

…But wait, I don’t want any Ext4, I want the latest and greatest BTRFS (ooooh copy on write…). Luckily, it’s only slightly more complicated, and requires treating a TrueCrypt volume like, well, a volume and not a filesystem: Create a volume and make it available, then interact with the filesystem on the volume outside of TrueCrypt.

truecrypt --text --create --filesystem=none /dev/sdx1

truecrypt --text --mount --filesystem=none --keyfiles= --volume-type=normal --protect-hidden=no --slot=1 /dev/sdx1

mkfs.btrfs /dev/mapper/truecrypt1

mount /dev/mapper/truecrypt1 /mnt

To dismount the filesystem and then the volume:

umount /mnt

truecrypt --text --dismount /dev/sdx1

1 Comment

Filed under #!, Slackware, Uncategorized

Encrypting a Linux home partition with Truecrypt


This post will be short (and sweet). We will secure the majority of our personal data by encrypting our home partition. This is important for users with personal or sensitive data on their laptops, as well as other mobile devices such as the Google Nexus 7 when it runs Ubuntu Linux.

General Information:

The steps to encrypt a partition with Truecrypt are probably the easiest ones compared to alternatives such as LUKS and other Linux Kernel built in tools. This involves installing Truecrypt, creating an encrypted partition, copying all the sensitive data into it, deleting the sensitive data from the unencrypted partition it was previously on, and configuring mounting and umounting of the Truecrypt volume during startup/shutdown. You will need to perform this as the root user, and you will need an empty partition which you can encrypt. The steps are generic: they assume you are encrypting a brand new home partition (and not something else), after storing your user data under the /home folder on the root partition. They have been tested on Slackware64 but will work on all Linux distributions. Please adjust the partitions, runlevel scripts and installation procedure for your Linux distribution (as an example, for Ubuntu, Truecrypt might be available via Aptitude repositories vs. a binary installation package, and the runlevels will not be in traditional BSD style).


  1. Install Truecrypt after downloading from here:
    # tar vxf ./truecrypt-7.1a-linux-x64.tar.gz
    # ./truecrypt-7.1a-setup-x64
  2. Create an encrypted Truecrypt partition. You will be asked about the partition, passwords and keyfiles to use:
    # truecrypt --text --create
  3. Mount the new encrypted volume in a temporary location and copy all sensitive data to it. This should be done as root from singleuser runlevel if operating on the /home folder:
    # telinit 1
    # mkdir /tmp/encrypted
    # /usr/bin/truecrypt --text --mount --protect-hidden=no --volume-type=normal --keyfiles= /dev/sda6 /tmp/encrypted
    # cp -aR --preserve=all /home/* /tmp/encrypted/
    # rm -rf /home/*
  4. Configure mounting/unmounting on startup/shutdown:
    Edit /etc/rc.d/rc.S and add the following line after “/sbin/mount -a …”:

    /usr/bin/truecrypt --text --mount --protect-hidden=no --volume-type=normal --keyfiles= /dev/sda6 /home

    Edit /etc/rc.d/rc.6 and add the following line before “/sbin/umount -a …”:

    /usr/bin/truecrypt --text --dismount /dev/sda6
  5. Test with a reboot!

1 Comment

Filed under #!, Slackware

Checking for Rootkits

What are rootkits? You can ask Wikipedia, or take this over-simplification:

The Windows flock has to worry about various security concerns – viruses, worms, trojans, bots. So may, in fact, they had been categorized into AdWare (unwanted commercial content), SpyWare (compromise of personal information) and Viruses (generally malicious code).

Linux folks, on the other hand, have to fear only one thing – a rootkit. Because Windows vulnerabilities allow exploiting a machine without administrative access for specific goals, a diversity of exploits was invented, while properly setup Linux can only be compromised with root (Administrator) access. However, once that had been achieved, the machine is fully compromised along with the network it’s on. Namely, there are very few things an attacker will not be able to do with a rooted Linux machine.

Periodic scans are a good measure to stay clean, similar to scheduled anti-virus scans in Windows PCs. chkrootkit is such an implementation, and appears to be the most popular today, for good reasons: it’s easy to build, easy to run, and easy to understand. A good idea might be to run it periodically and email the output to a system administrator.

Great, until you realize the catch22 of checking for root-kits: Once a machine had been infected with a rootkit (usually through an badly secured SSH account), there’s virtually no way to determine that is was compromised, unless a reference set of binaries can be used to compare the infected binaries to “clean” ones. This means that you may not use a machine to check itself for rootkits, because if it was already compromised at the time it was checked, the check would be useless.

There is, of course, a hack. Namely, Network Security Hack #99 from O’Reilly suggests we can run chkrootkit in Busybox! Right, Busybox has some 200 programs built into its binary, and we could use those instead of the host’s own suspected ones. Unfortunately, it does not show how.

Let’s think about this: We assume the machine might be compromised when we scan it. We would not want to use the machine’s own binaries (that could also be compromised). We would not want to use software that had been lying around on the machine while it was compromised, for the same reason, including Busybox or chkrootkit. Ideally, then, we would use a fresh copy of Busybox to download a fresh copy of chkrootkit, run one in the other and dump both (that way, one cannot compromise something that is not there).

I ended up with the (almost entirely self-sufficient) solution below. It will run on any machine that has internet access, GNU wget (to download Busybox and chkrootkit). Other than wget, the script makes use of Busybox applets instead of the system installed binaries, for extra safety 😉


# Temporary folder path. (It's a good idea to use a random name):

# A URL from which Busybox binaries can be downloaded

# A URL from which the chkrootkit source can be downloaded:

# Download and prepare the Busybox binary in the temporary folder:
/usr/bin/mkdir -p $TEMPORARY_FOLDER
/usr/bin/wget $BUSYBOX_URL/busybox-"`uname -m`"
/usr/bin/chmod +x $TEMPORARY_FOLDER/busybox-"`uname -m`"
BUSYBOX_BIN=$TEMPORARY_FOLDER/busybox-"`uname -m`"

# Download, confirm the MD5 sum, and extract the chkrootkit source using Busybox:
$BUSYBOX_BIN wget $CHKROOTKIT_URL/chkrootkit.tar.gz
$BUSYBOX_BIN wget $CHKROOTKIT_URL/chkrootkit.md5
if [ "`$BUSYBOX_BIN cat chkrootkit.md5`" != "`$BUSYBOX_BIN md5sum chkrootkit.tar.gz`" ]; then
  $BUSYBOX_BIN echo " !!! MD5 SUM check FAILED !!! "
  $BUSYBOX_BIN echo "MD5 checksum for chkrootkit source passed..."
$BUSYBOX_BIN tar vxf $TEMPORARY_FOLDER/chkrootkit.tar.gz

# Run the newly built chkrootkit in the just downloaded Busybox:
$BUSYBOX_BIN sh $TEMPORARY_FOLDER/chkrootkit*/chkrootkit

# Clean up:
cd /
$BUSYBOX_BIN echo "Done."


Filed under #!