Blogging about Linux, networks and security

Unlocking a LUKS encrypted root partition via SSH has become very easy

with 5 comments

Recently, I’ve set up a small home server again. As usual, I’ve gone with a fully encrypted hard drive. However, for a server it’s quite inconvenient to attach a display and a keyboard every time it should be booted.

Therfor, again as usual, I wanted to be able to unencrypt the device using SSH. As many times before I followed the instructions on this page. When I tried to recreate the initrd, all I got was an “error 72” along with a note, that this all was deprecated — and a hint where to find more, which I ignored…

As Google couldn’t help much, I decided to read the information: Debian now supports this feature natively and it’s damn easy to configure:

[edit 2010-12-29 17:00] A small word of warning: As I just found out, this isn’t that easily working with Ubuntu. According to bug report 595648 on launchpad Plymouth is responsible for problems unencrypting the device. Comment #5 provides a workaround. However, I haven’t tested this. [/edit]

All you need to do is installing dropbear (a tiny SSH server) and BusyBox (a tiny shell, usually already installed) using apt-get. The initrd will be recreated automatically. Then reboot your computer. Don’t worry: If you can’t login via SSH you can still do by using the keyboard. It’s absolutley(?) fail-safe.

There’s also a public/private key pair being created automatically when dropbear is installed. For later public key authentication you can either use the private key provided in /etc/initramfs-tools/root/.ssh/id_rsa (copy to your own machine and use it when logging into the server specifying “-i”, see below) or just add your usual (public) key to /etc/initramfs-tools/root/.ssh/authorized_keys. (cat >> …authorized_keys and recreate the initrd with update-initramfs)

The final command (for logging into your booting server only) looks then something like:

ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
-i "your_public_key"

-o” specifies a different known_hosts. This is necessarry, because your server will (going this easy way) have two separate fingerprints: One during the boot process offered by dropbear and one afterwards offered by your usual SSH server. This would cause a lot of inconvnience and warnings as changed fingerprints can indicate something nasty going on — as the warning will tell you.
-i” specifies the private key to use and is only needed if you copied the one being created by dropbear. If you copied your regular one over this can be omitted.

As you probably don’t want to do too much on your server in this state, it’s comfortable to pass the command for decrypting the harddrive directly:

ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
 -i "~/.ssh/id_rsa.initramfs" root@ \
 "echo -ne \"encryptionpassphrase\" >/lib/cryptsetup/passfifo"

Yes, that’s right: The password to decrypt the device is in plain here…

As you can see, this is really easy: Install dropbear, copy dropbear’s private key and use it to login. Three short steps and almost fool proof.

Written by Flo

December 28, 2010 at 11:57 pm

Hands-on security for beginners: Windows system encryption with TrueCrypt

leave a comment »

I’ve been using a fully encryped Linux system on my laptop for quite a while now. My (windows-driven) desktop, however, was still partly unencrypted. Of course, most of my private data was stored on a TrueCrypt encrypted partition. Windows itself, as well as some of my programs (mainly games), still resided unencrypted on several partitions. This was mainly due to my expectation of a somewhat huge perfomance loss, if all that data had been encrypted, too.

Quite a time ago when I read how easy Truecrypt would offer complete system encryption, I decided to do some benchmarks. As I was especially afraid of performance loss in Games I looked around for some benchmark demos. These results do NOT represent the games I play😉

Devil May Cry 4 Benchmark Demo Crysis Demo Anno 1404
unencrypted 66.12 / 43.91 / 72.21 / 41.32 31.89 / 34.23 / 34.10 / 34.76 8
encrypted 65.69 / 43.75 / 69.15 / 43.75 30.99 / 35.50 / 35.58 / 34.59 8

Atto Disk Benchmark 2.46

Drive C unencrypted

Drive C encrypted

Based on the results of these benchmarks, you can see mainly two things:

  • I’ve got pretty old and slow hardware.
  • There is no performance loss. Not even in games.

After having done these benchmarks, there was only one single question remaining: What is the reason for my desktop to still be unencrypted, if a) there is no disadvantage and b) the encryption is that easy? Right, there was no reason, and so I encrypted my whole system drive.

This is what I want you to do now, too. But let me start explaining, why you should even think about encrypting your computer: You don’t have anything to hide? Really? Okay, go! Really. I don’t wan’t to explain everything to you. Maybe you really don’t have to encrypt your Desktop system (as long as you do not fear the police or your family). However, an unencrypted laptop is an absolute no go.

If you loose it, you do not only loose a device, but also valuable data. What data? For example your stored WiFi passwords, maybe even more passwords stored in your browser. What about your private documents? Do you want everybody to be able to read them? What about sensitive data from your company (that shouldn’t reside on your private laptop!)?

If you still don’t care, it’s okay. It’s not my problem. Otherwise, here’s what to do:

First of all: Make some backups. There shouldn’t be any problems and I didn’t experience any, but there *could* be some. And backups are always good (when did you make your last?)

In case you are still using Windows XP or 2003: TrueCrypt cannot handle logical partitions. So you can either only encrypt your System Partition or get rid of those partitions. In Windows Vista/7 there is no such limitation any more.

For almost every click you do, TrueCrypt provides detailed information on what you are about to do. Make sure you understand them, before proceeding. I do NOT take responsibility for any damage occurring from following this tutorial. Asking stupid questions beforehand is better than asking stupid questions afterwards😉 And there are no stupid questions anyway…

Open TrueCrypt and select System->Encrypt System Partition/Drive

You don't want a hidden OS for now😉

No bit will remain unencrypted

A little warning for XP/2k3 users: TrueCrypt doesn't support logical paritions for those OS

Read the text. If you have such tools, you should probably select "No" here

Usually these defaults are a good choice. Select "Benchmark" to test the algorithms

You probably want to go for AES. Especially if you own a more recent Intel CPU offering hardware acceleration

Choose your password. It should be hard to guess. However, you shouldn't forget it!

Depending on your paranoia you can select here how to overwrite old data

A rescue disk is created. You can either burn it or mount it with Daemon-Tools to let TrueCrypt verify it. The disk is needed in case you need to unencrypt the device without booting Windows. However, this is NOT a way to get into the system without password.

Before anything is encrypted, TrueCrypt performs a pretest where your system is rebooted.

After rebooting Windows and starting TrueCrypt, TrueCrypt asks to encrypt the device. My 250 gig drive took about 3 hours.

Finished! I hope you still remember your password?!

My system has been encrypted for a few months now and I had no problems yet. Just the shock, when I saw the password prompt after the first night when I had problems remembering the password😀 Moreover, it’s even more convenient as I don’t forget to mount the data partition any more…

The only real limitation I experienced is a little more CPU load during large copy actions which however is obvious and not that bad. For most of the data I’ve had this before on my encrypted partition, anyway.

One last advise: DO IT!

Written by Flo

May 30, 2010 at 12:10 am

Hands-on security for beginners: SSL-encrypted Google search without revealing too much to Google

leave a comment »

A few days ago, Google announced a new service: Google SSL. Using the SSL encrypted version of Google’s search will make your queries no longer look like

GET /search?hl=en&source=hp&q=Foobar&aq=f&aqi=g10&aql=&oq=&gs_rfai=

to everyone in between you and Google’s server (e.g. your admin, your ISP, the script-kiddie abusing your unencrypted WiFi), but rather something like:


Of course, SSL can be defeated in several ways, but nonetheless, this is a very easy way to enhance your privacy…

Uh, wait? Did I just mention “privacy” while talking about Google? Well, yes. Despite all the encryption stuff, Google still knows, what you are looking for. Obvious? Yes. Inevitable? No. There is a way to use Google’s search algorithm (which is probably one of the best) without revealing your identity to Google.

This is done by using a proxy service like Scroogle. Instead of sending your queries directly to Google, you ask Scroogle to do that. Scroogle then forwards your request to Google’s servers, but drops information about you (things like your browser, your location, &c.). It then returns the results of the search to your computer, but does not save any other data like cookies to later identify you again. Google only sees a lot of requests from Scroogle, but doesn’t know, who is *really* searching anything — pretty cool, isn’t it?

Furthermore, Scroogle also offers an SSL encrypted service. By using POST instead of GET for the search it also avoids website owners to see with which search terms you found their site: Instead of a log entry like

they only see that you came from Scroogle, not knowing your exact search terms:

If you want to tell them, what you were looking for, or you simply want to bookmark a search, you can use the GET version of Scroogle (at the bottom). For more detailed information about POST and GET have a look at Scroogle’s Explanation.

Written by Flo

May 29, 2010 at 10:47 pm

Upgrading Pidgin and libpurple in Ubuntu 9.04

with one comment

I’ve been using Pidgin for quite a while now, but just a few days came across a problem: The current version of Pidgin and libpurple in the repository of Ubuntu 9.04 (2.6.3) can’t handle offline messages from ICQ users (I’m usually not a big fan of ICQ, so it took a time to get notice about it). Luckily, the messages, you haven’t received aren’t gone, but still stored on the ICQ servers (luckily?!), so you’ll get them, as soon as you log on with the newer version.

Unfortunately, I was about to get an important message… and was offline at that time. Therefore, I was searching for a (stupid^^) way to upgrade Pidgin — withouth adding the repositories of 9.10.

I finally decided, it would be the best to compile Pidgin myself… and didn’t expect the problems I was going to have:

After installing Pidgin 2.6.4, the pidgin-plugin-pack, which I need for some reasons, wasn’t working. So I spent a whole evening, installing and removing packages from the repository and from source, until I finally managed to have Pidgin 2.6.4 with a working plugin-pack — unfortunately, I couldn’t remember the way and my system was in RAM… and everything gone afterwards😦

As I found no way to get there again, I decided to try changing the libpurple withouth installing a newer version of Pidging — not surprisingly: It didn’t work.

However, after installing Pidgin 2.6.4 from Sources (without uninstalling anything), everything was working: Receiving offline messages as well as the plugin-pack😀

This is probably the worst solution ever and maybe not even worth to be called “work-around”, but I hope, it will be enough until I upgrade the system over the Christmas holidays.

Just forget about it. It’s much easier to just copy the plugins (the ones I needed were in /usr/lib/pidgin/, uninstall the plugin-pack und copy the files back. This works just as fine and has the advantage that it doesn’t screw up your package management. Thank you to my brain, which started working again -.-

Written by Flo

December 11, 2009 at 1:10 pm

Posted in Uncategorized

Tagged with , ,

Opera meets HFU

with 3 comments

Last thursday, the Opera University Tour reached Furtwangen, where I am studying at the Hochschule Furtwangen University. Luckily I heard about this by some student as there were *no* posters or whatever promoting this event at all – except for a really small note on the university’s page.

The talk itself was held by Patrick H. Lauke and was absolutely brilliant. Humorous, easy to follow, interesting and peppered with examples of the “sexy features”, that are about to come. It really seemed to be a look into the future of the Web.

The presentation opened with a little movie about working at Opera Software – guess what: I got a new favorite place to do my internship… now I just need the right marks. I was a little afraid that it will be a presentation about how cool Opera is (what would have been useless, as we all know that), but was all the more surprised as Patrick’s main topic was to point out the importance of open web standards, which he did for about 90 minutes. Always telling, how these standards could help you and me as a user, but also the web designers. Only the last roughly 20 minutes he showed some of the “sexy features” (he liked that one^^) of Opera, namely their widgets as well as “Opera Unite“.

A very big thank you to Patrick and his team for coming to Furtwangen as well as to everyone else making this fantastic event happen – even though it was of limited value to me for my studies, since I’m not studying anything related to media.

Written by Flo

November 9, 2009 at 8:00 pm

Posted in Uncategorized

Tagged with ,

Bringing Backspace to Xfce4-terminal with screen

leave a comment »

For quite a long time I’ve been annoyed by the fact, that backspace isn’t working in GNU Screen when run in a Xfce4-terminal (instead of a backspace it was sending “^@”). Today, by accident, I stumbled upon a working solution:

Just add the line bindkey -d ^@ stuff ^? to your .screenrc and restart your screen sessions. I cannot judge the quality of this nor do I know the consequences, but it’s working.

Finally, I don’t have to look for an alternative of my terminal🙂

Written by Flo

October 13, 2009 at 2:24 pm

Posted in Uncategorized

Tagged with , ,

poor auto-mounting with udev

leave a comment »

Although I should learn for my ongoing exams I found a few moments to try getting auto-mounting on the console. (Note: This is rather a post for me to remember than anything useful😉 )

As I didn’t find a properly working solution for my minimal installation (some troubles with thunar and I wanted also for the console), I decided to do a poor alternative on my own. I tried to make it almost as convenient as in GNOME (or KDE…) as I was sick of always typing “sudo mount /dev/sd?1 /mnt” which also led to some troubles when using more than one stick.

It’s no more than two small scripts combined with two rules of udev (save as /etc/udev/rules/01-YOURNAME.rules and modify the script path):
BUS=="usb", KERNEL=="sd??", ACTION=="add", RUN+="/home/flo/.scripts/udev/ %k"
BUS=="usb", KERNEL=="sd??", ACTION=="remove", RUN+="/home/flo/.scripts/udev/ %k"

These lines execute when attaching an USB device and execute when removing it. “%k” gives the device name (e.g. sdb1) as parameter for the script.

label=$(ls -l /dev/disk/by-label/ | grep $1)
if [ $? -eq 0 ]; then	#found the device
    label=$(echo $label | sed -e 's/.*:...//g' | sed -e 's/.->.*//g')
    label=$(ls -l /dev/disk/by-uuid | grep $1 | sed -e 's/.*:...//g' | sed 's/.->.*//g')
mkdir /media/$label
mount /dev/$1 /media/$label -o sync,gid=46,umask=007

This script tries to find the label of the partition. If not possible it uses the UUID as a name for the mount directory, which is /media/{UUID|LABEL}. It finally mounts the device into this newly created folder, setting the “sync” option, which makes it save to remove the device without umounting it. “gid=46,umask=007” means, that only root and members of the group “plugdev” are allowed to acces the device – this is needed for FAT formated sticks.

label=$(mount | grep $1 | sed -e 's/.*\/media\///g' | sed -e 's/.type.*//g' )
umount -l /dev/$1
rmdir /media/$label

This script umounts the device and removes the folder, that was created.

Important note: These scripts should *not* be editable by users as they are executed with root rights – and therefor might be used to “hack” the system when modified!

I have no idea, how well these lines work with hard drives containing several partitions (I don’t have one here at the moment) or with encrypted partitions. I’ll have a look at that after the exams (in roughly 2 weeks).

As always: Use with care, I’m not responsible for any harm😉

Written by Flo

July 7, 2009 at 10:51 pm

Posted in Uncategorized

Tagged with , , , ,