paranoia

Towards a moderately paranoid Debian laptop setup [Update]

I was planning to set up my laptop from scratch for a while now... so I did.

Preparation

  • First, go home. No, really! Do all of this at home in a non-hostile, firewalled network. You don't want to be in a crowded place such as a conference where people can shoulder-surf your passwords, nor do you want your network traffic sniffed or MITM'd in a hostile network.
  • Backup all your data! You'll be wiping your whole drive soon, so make sure you have recent, tested backups.
  • Get the most recent Debian-installer ISO image (currently etch-beta3), as well as the MD5SUMS and MD5SUMS.sign files:
    wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso
    wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS
    wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS.sign
  • Run gpg --verify MD5SUMS.sign, which will fail but tell you the signing key ID (88C7C1F7 in this case). Get the key and re-run the verification: gpg --recv-key --keyserver subkeys.pgp.net 88C7C1F7 && gpg --verify MD5SUMS.sign. The output should now say "Good signature from [...]".
  • Now check the MD5 checksums via md5sum -c MD5SUMS. The output should contain debian-testing-i386-binary-1.iso: OK.
  • As you now have (somewhat) verified the integrity of the ISO image, burn it on a CD-R: wodim debian-testing-i386-binary-1.iso.
  • Put trusted versions of some files on a USB thumb drive (or CD-ROM); at least a firewall script, but maybe also your bashrc, bash_logout, inputrc, vimrc, muttrc.
  • Disconnect your laptop from any kinds of networks. Pull all ethernet cables. Disable WLAN (via hardware killswitch). Disable Bluetooth. Disable/remove Firewire, USB, serial, whatever.
  • Put on your tin-foil hat (optional).

BIOS

  • Set a good BIOS boot password (which you need to boot any OS). Set a (different) good BIOS boot setup password (which you need to enter the BIOS).
  • Disable all boot possibilities in the BIOS, except for CD-ROM. This means it should not be possible to boot via USB, hard drive, network, PXE, Firewire, floppy, whatever. The BIOS setup password helps to prevent tampering with this setting.
  • Finally, never rely on BIOS passwords alone for security! They can often be circumvented very easily.

Installation / Setting up full-disk encryption using dm-crypt

  • Insert the installer CD and boot in expert-mode (don't hit ENTER when you boot, but rather type "expert").
  • As for networking: select "Do not configure the network at this time". We'll fix and enable networking later.
  • Partitioning:

    • Select manual partitioning. Remove all partitions (if any). Create a 100 MB /boot (ext3) as primary partition, and make the rest of the hard drive one huge partition which has "Use as:" set to "physical volume for encryption".
    • The standard options for cipher, key size, IV mode etc. should be fine (AES, 256 bit, CBC-ESSIV-SHA256, dm-crypt).
    • After the erasing is done (this is important!), use the whole encrypted space as "physical volume for LVM". Then select "Configure the Logical Volume Manager". Create one big volume group and a bunch of logical volumes for the various partitions we'll use (lv-root, lv-usr, lv-var, lv-tmp, lv-swap, lv-home).
    • It is extremely important that your swap space is encrypted (in this case it is, as all partitions except for /boot reside on a dm-crypt device)! Never set up unencrypted swap!
  • Enable shadow passwords. Allow login as root (I feel confident that I won't do stupid things as root).
  • Choose a good root password, and a (different) good user password. Don't enter a full name for the user.
  • Choose the latest kernel (old kernels might have security issues). Do not participate in popcon.
  • Do not install any tasks (no "desktop", no "base system"). We want the smallest installation possible, and add only the packages we really need. Fewer packages means fewer security issues (statistically).
  • That's it. Eject the CD-ROM, reboot, change the BIOS to only allow booting from hard drive.

Post-installation tasks

  • Enter the USB thumb drive, copy all config-files to /root and /home/uwe. Log out and log in again to make ~/.bashrc and ~/.inputrc take effect.
  • Enable the firewall: mkdir /etc/rc.boot && cp fw_laptop /etc/rc.boot && chmod 700 /etc/rc.boot/fw_laptop && sh /etc/rc.boot/fw_laptop
  • Shut down all networked daemons (if any): /etc/init.d/foo stop.
  • Tighten home-directory permissions: chmod 700 /root /home/uwe.
  • Edit /etc/passwd: give all users except for root, sync, uucp and your user account /usr/sbin/nologin as login shell. None of these accounts really needs a valid login shell (nologin will log any login attempts for those accounts).
  • Edit /etc/group: remove your user account from the dialout, cdrom, and floppy group. The groups audio, video, and plugdev can stay.
  • Edit /etc/fstab: add some mount options such as ro, nosuid, noexec, or nodev as you see fit. Example:
    /dev/mapper/vg--whole-lv--root /     ext3 defaults,errors=remount-ro      0 0
    /dev/sda2                      /boot ext3 defaults,nodev,nosuid,noexec,ro 0 0
    /dev/mapper/vg--whole-lv--home /home ext3 defaults,nodev,nosuid           0 0
    /dev/mapper/vg--whole-lv--tmp  /tmp  ext3 defaults,nodev,nosuid           0 0
    /dev/mapper/vg--whole-lv--usr  /usr  ext3 defaults,nodev,ro               0 0
    /dev/mapper/vg--whole-lv--var  /var  ext3 defaults,nodev                  0 0
    /dev/mapper/vg--whole-lv--swap none  swap sw                              0 0
    /dev/scd0 /media/cdrom iso9660 noauto,nodev,nosuid,noexec,uid=uwe,gid=uwe 0 0
    
  • If you have read-only (ro) file systems, configure Apt so that it can remount them read-write when installing/removing packages. Add this to /etc/apt/apt.conf:
    DPkg
    {
      Pre-Invoke { "mount -o remount,rw /usr; mount -o remount,rw /boot"; }
      Post-Invoke { "mount -o remount,ro /usr; mount -o remount,ro /boot"; }
    }
    
  • Fix the GRUB configuration. Replace the "password foo" line (which contains the GRUB password in plain-text) from your /boot/grub/menu.lst with a "password --md5 $1$1234567890..." line, where the MD5 hash ($1$1234567890...) can be generated with grub-md5-crypt. Additionally, add such a password line after each "title" line in the GRUB config-file, so that nobody can boot any OS installed on the laptop without a password!

Networking, Upgrading and Apt-secure

  • Now that we have a small, hardened system, it should be reasonably safe to enable networking. Add this to /etc/network/interfaces:
    auto eth0
    iface eth0 inet dhcp
      pre-up /etc/rc.boot/fw_laptop
    

    Run /etc/init.d/networking restart. The firewall script will run every time the network is started.

  • Now add this (tweak as you see fit) to /etc/apt/sources.list:
    deb http://ftp.de.debian.org/debian unstable main
    deb-src http://ftp.de.debian.org/debian unstable main
  • Time for upgrading: apt-get update && apt-get dist-upgrade. All packages are GnuPG-signed and will be verified by Apt. The installer already ships the required key (for 2006), so everything should just work. Still, you should read about SecureApt.
  • Install the rest of your system now, and restore your data from backups.
  • Use sysv-rc-conf to disable all daemons you don't want to start per default: sysv-rc-conf foo off.
  • Install and set up Samhain (or any other file integrity checker): apt-get install samhain. You want to be notified if your system files are being tampered with (e.g. replaced by a rootkit).
  • Install and configure Tor for anonymous browsing. More details here.
  • Install and configure more security-related programs, e.g. logcheck, snort, rkhunter, chkrootkit, tiger, sxid, etc.

SELinux

Now install and set up SELinux. This section is based on notes from Erich Schubert (thanks!), and will soon appear in the SELinuxSetup wiki page, too.

  • Install the base packages and an SELinux policy: apt-get install selinux-basics selinux-policy-refpolicy-targeted.
  • Edit /boot/grub/menu.lst and add selinux=1 to your kernel command line to enable SELinux upon booting.
  • In /etc/pam.d/login uncomment the "session required pam_selinux.so multiple" line. Do the same in /etc/pam.d/ssh if you have ssh installed.
  • In /etc/default/rcS set FSCKFIX=yes.
  • In /etc/init.d/bootmisc.sh search for "Update motd" and comment the two lines below that line. Then rm /var/run/motd.
  • If you have exim installed, you must either install postfix or write an exim policy, as none currently exists. But even postfix needs some fixing (no pun intended ;-). Disable chroot-support (change all "chroot" fields to "n" in /etc/postfix/master.cf and execute echo 'SYNC_CHROOT="n" >> /etc/default/postfix').
  • Use check-selinux-installation to check for common SELinux problems on Debian (such as the above mentioned).
  • touch /.autorelabel. Reboot. touch /.autorelabel (again). Reboot (again).
  • Done. You should now have a working SELinux system. If no critical audit errors appear and you feel comfortable with SELinux, enable enforcing mode via setenforce 1 or by adding enforcing=1 to the kernel command line in /boot/grub/menu.lst.

Behaviour

  • Never leave your laptop unattended!
  • Always lock your terminal (using vlock) when you move more than 30 cm away from the laptop!
  • Don't run insecure and/or closed-source software (which you can never trust!). No NVIDIA/ATI drivers, no VMware, no Google Earth, no Flash Plugin (except for Gnash maybe), no Adobe Acrobat. You get the idea.
  • Keep the number of installed packages small and try to configure each of them as secure as possible.
  • Never enable networking or WLAN or Bluetooth if you don't absolutely have to.
  • Trust no one. Don't let other people use you laptop, don't give out shell accounts.

Further ideas

  • The /boot partition is still unencrypted, so an attacker can tamper with it. Boot from a CD-R, forbid booting from hard drive (BIOS). Sign/mark the CD-R physically, so you'll know when someone replaced your CD-R with his own, back-doored one.
  • Another idea is to use an additionaly USB thumb drive or CD-ROM or smartcard for two-factor authentication.
  • Install another Debian into a QEMU image. Use it as a sandbox for stuff you don't trust: qemu -snapshot -net none foo.img.
  • At all costs, disable Firewire! If possible via hardware or BIOS, or at least don't load the drivers and/or fix them (page 19).
  • Replace the proprietary, closed-source BIOS with LinuxBIOS, if possible.

That's it. You can take off that stupid tin-foil hat now.

Update 2006-09-29: Fixed typos. Mentioned sxid. Added two-factor authentication.

Why disk-encryption is not only useful for paranoid computer geeks

According to this (German) spiegel.de article, thieves have stolen a hard drive from the recording studio of the quite popular German band Rosenstolz.

Among the contents of the drive are unreleased songs from the past six years and two songs which should be released on a new single in a few weeks. Apparently those two songs on the drive were the only instance they had, off-site backups only contained older "beta" versions of the songs. As the band is touring at the moment (i.e. no time for re-recording the songs), it's unclear whether the single can be released in time.

Lessons learned:

  • Backups, backups, backups!
  • Disk-encryption is not only for paranoid computer geeks, but also for normal people like you and me[1]. Really! If that hard drive would have been encrypted they would still suffer because of the lack of good backups, but at least their unreleased songs wouldn't have fallen in the hands of the thieves. I bet those songs will soon appear in P2P networks around the globe[2].

(via Fefe)

[1] Well, I am a paranoid computer geek, and I'm probably not a normal person, but you get the point ;-)
[2] Oh, and if the thieves are stupid enough they will get caught while uploading the files ;-)

HOWTO: Disk encryption with dm-crypt / LUKS and Debian [Update]

A few weeks ago I published a small HOWTO for using loop-aes to encrypt your hard drive, usb thumb drive etc.

As I have bought a new 300 GB external USB disk drive on Friday, I have tried something new this time: disk encryption using dm-crypt / LUKS. It has been suggested to me multiple times that dm-crypt is superior to loop-aes, however I didn't get a real reason. Yes, it doesn't require any kernel patches and is easier to setup. But has any serious cryptographer looked at it sharply, yet? Did it withhold his eye contact?

Anyways, here's how I encrypted my 300 GB drive. I largely followed the guide at the EncryptedDeviceUsingLUKS wiki page...

  1. Make sure you run Linux 2.6.16 or better. Previous versions suffer from an implementation problem which affects the security of dm-crypt, see Linux Kernel dm-crypt Local Cryptographic Key Disclosure.
  2. Enable the following options in your kernel:

    • Code maturity level options
      • Prompt for development and/or incomplete code/drivers
    • Device Drivers -> Multi-device support (RAID and LVM)
      • Device mapper support
      • Crypt target support
    • Cryptographic options
      • AES cipher algorithms
  3. Overwrite the whole drive with random data in order to slow down attacks on the encryption. At the same time perform a bad blocks scan to make sure the hard drive is not going to die too soon:
    badblocks -c 10240 -s -w -t random -v /dev/sdb
    Replace /dev/sdb with whatever is correct on your system. If you're really paranoid, and are willing to wait one or two days, do this:
    dd if=/dev/urandom of=/dev/sdb
  4. Install the required packages:
    apt-get install cryptsetup
    The current cryptsetup in Debian unstable already supports LUKS, which was not the case a while ago, if I'm not mistaken. So Debian testing or stable will most probably not work!
  5. Create one or more partitions on the drive:
    cfdisk /dev/sdb
    I created one big 300 GB partition, /dev/sdb1.
  6. Setup LUKS:
    cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1
    Enter a good passphrase here. Don't spoil the whole endeavour by chosing a stupid or short passphrase.
  7. Open the encrypted device and assign it to a virtual /dev/mapper/samsung300gb device:
    cryptsetup luksOpen /dev/sdb1 samsung300gb
  8. Create a filesystem on the encrypted device:
    mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/samsung300gb
    I used ext3 with some optimizations, see mke2fs(8).
  9. Mount the encrypted partition:
    mkdir /mnt/samsung300gb
    mount /dev/mapper/samsung300gb /mnt/samsung300gb
    That's it. Everything you write to /mnt/samsung300gb will be encrypted transparently.
  10. For unmounting use:
    umount /mnt/samsung300gb
    cryptsetup luksClose /dev/mapper/samsung300gb

After unmounting, nobody will be able to see your data without knowing the correct passphrase. Drive is stolen? No problem. Drive is broken, and you want to send it in for repair without the guys there poking in your data? No problem. You leave the USB drive at home and some jerk breaks into your house, steals your drive, rapes your wife, and kills your kids? No problem. Well, sort of, but you get the idea ;-)

There's more things you can do, thanks to LUKS: have multiple passphrases which unlock your data, change/add/remove passphrases as you see fit, etc.

Comments?

Update 2006-04-17: You have to use cryptsetup from unstable if you want LUKS support. cryptsetup in testing does not support this (thanks Ariel).

How to detect and defeat hardware backdoors and wiretaps?

A network card

How nice. The FCC wants "a "back door" be built into all Internet-communications hardware and software to provide access for law enforcement agencies".

This and similar horror scenarios for the freedom and privacy of the people are nothing unusual these days.

A more general (and more paranoid) question:

How do we know whether our software or hardware is backdoored/wiretapped? We all know that using a certain OS from Redmond opens a lot of security holes in itself. Add to that all the now-public attempts of agencies and companies ranging from the FBI, NSA, Sony to antivirus-software vendors who install backdoors on your PC, and you've got some very good reasons to never trust any closed-source software again.

This is not a problem for most of us using Free Software and free operating systems (Linux, *BSD, etc.). Theoretically, we can read the source code of almost every single instruction being executed on our hardware, and verify that the software doesn't do any funny things like phoning home, logging keystrokes, opening backdoors and so on.

However, how can we know whether or not our hardware has been backdoored/wiretapped/trojaned (or whatever you want to call it)? Given that almost all devices we own nowadays (PDA, iPod, cell phone, hardware VOIP phone, and all the other gadgets) as well as most parts of our PCs and laptops have some sort of microcontrollers on them, how can we be sure that there is no secret code hidden in there which spies on us or provides hidden backdoors to them (whoever that may be)?

With some devices you can dump the firmware and analyze that, but most parts are probably not easily analyzable by mere mortals. Think network cards, builtin wireless cards, sound cards, bluetooth chips and so on. IMHO, a good first step in the right direction are things like OpenBIOS (Free Software firmware/BIOS) and OpenEZX (Free Software GSM phones). Alas, I think DRM will pose a major threat here in future, as we probably cannot easily replace custom firmware/software anymore if DRM in the worst form becomes reality.

So, how would you go about to ensure that your hardware has not been backdoored? How can we detect such things? How can we defend against such things? How can we remove backdoors if we find any? Do you know of any relevant research, papers, documents, HOWTOs? Any cases you know of where such things happened? Any practical tips or advice?

EFF cracks the DocuColor Tracking Dot code

If you haven't yet read about it, some printer brands place tiny, almost invisible yellow dots on every page you print. These dots encode certain information (date, time, printer serial number, or similar things). I think you can easily imagine the security and privacy implications. The EFF has now cracked the DocuColor Tracking Dot code.

They have also written a program which decodes the dot patterns. The code is released under the terms of the GPL.

(via Boing Boing and CCC)

Syndicate content