Intrusive Surveillance
THOMAS: What is this thing?
TRINITY: We think you're bugged. Try to relax. Come on, come on...
TRINITY: CLEAR!
THOMAS: Jesus Christ! That thing is real?!
Intrusive Surveillance basically means any type of surveillance that is occurring due to some form of intrusion into your machine. As such, it is the most difficult form of "forensics" to defend against, since doing so involves the securing and hardening of your operating system against attack. While keeping up with security patches is a necessary condition to be secure, sadly it is not sufficient. In spite of this, there are several obvious indicators that someone is investigating you/watching what you do with your computer.
I should probably start this section off by saying that if you need anonymity, you should probably reinstall your system now. Especially if you use Windows and Internet Explorer. It is way too easy for those machines to become infected with spyware if you haven't been practising safe computing up to this point. I've even seen spyware that modifies the Internet Explorer user agent string to contain a unique 128bit identifier.
If you intend to audit your machine while it's live, the very first thing you need to do is ensure that your kernel hasn't been modified via a rogue driver module. While lsmod will list loaded modules, it is possible (and quite trivial) to remove module names from this list while keeping the module in the kernel. For this reason, if you are concerned about local surveillance, you are advised to build a kernel without module support (preferably with grsec, which adds protection against ways to force modules into a module-free kernel). This will prevent someone from loading a module that could hide processes and network connections, log keys, etc.
If this is not an option (it is very difficult to get a monolithic kernel running, especially on systems that require closed-source drivers), you can perform a manual audit. I provide a couple Linux kernel modules that can aid in the auditing process. They will help you check for common ways rootkit modules hide themselves, and also can help you to ensure your kernel syscall path has not been tampered with. The ideas are based on this Security Focus article and this article on rootkit operation. All methods discussed there can be examined with those modules. The reason I created these modules is that Fedora's policy of disabling /dev/kmem has broken existing utilities that performed these functions. In particular, samhain is capable of performing these checks automatically for you on non-Fedora and *BSD systems.
Once you know your kernel hasn't been subverted, you can check the output of netstat -natup to see if any strange programs have established network connections to external hosts. ps xa will show you all the processes running on your system. If you don't recognize something, scroogle it.
To help watch for modification of your userland programs, you can run Chkrootkit and/or Rootkit Hunter, and also periodically run rpm -Va to verify checksums of your installed packages. TripWire and AIDE are also options for maintaining system integrity.
As far as live inspection and countermeasures, unfortunately, Mac OS doesn't have the advantage Linux has in being able to compile a monolithic kernel. This means that it is much more difficult to ensure that your system integrity is still valid. Just like on Linux, it is possible to write a kernel extension that goes in and verifies that none of the system calls have been hooked, and that the keyboard interrupt vector is still intact, but I don't think such a extension has been written yet. FIXME_MAC: any takers? FIXME_MAC: how about gdb + the syscall table? Is there a map file?
There is a piece of malware that exists for Mac OS X called Opener. It functions as a trojan, spyware, and a keylogger. It's worth searching your filesystem for it's presence. FIXME_MAC: more details on how it works..
However, since opener is not a kernel-level rootkit, it can be detected with system monitoring software such as CheckMate. Additionally, you can check for suspicious TCP and UDP connections via lsof -i TCP -i UDP. However, note that kernel-level rootkits like WeaponX are able to make themselves invisible from these checks.
For general rootkit detection, Sysinternals puts out a tool called Rootkit Revealer that uses various Windows APIs to check for inconsistencies (ie comparing raw registry data to API reported, etc). It does not use this information to detect rootkits by name, but instead prints a list of anomalies. If you have a clever rootkit implementer, be aware that they can hide among the noise.
If you are interested in looking for hidden files, or executables, your best bet is to create a bootable CDROM from your Windows XP install media. You can then look through your directories after booting from this CD and ensure they match your system under normal boot. UBCD has a tool called RootKitty which basically compares file listings of your computer from the CD versus while it is running on a normal boot.
Specific rootkit removal tools exist also. Currently the most popular of these are BlackLight and ICESword which both check for changes made to kernel memory to detect rootkits like FU, as well as hooks to functions in kernel space. In 3rd place is VICE, which checks for hooks in commonly targeted kernel and userland functions. The main issue with VICE is that for usermode, it will spew out one hell of a lot of false positives, as it is common for the Windows DLLs to "hook" one another.
The RKDetector utility linked off of this Hacker Defender Removal page is also pretty nice. While it has been written primarily to detect the Hacker Defender rootkit, it is also capable of finding hidden processes and services that may have been cloaked by other rootkits (such as FU).
Also available is UnHackMe, a shareware tool designed for AFX removal.
Lastly, just like Linux and Mac OS, Windows enables you to list active Internet connections and their associated processes. netstat -nab should do the trick.
FIXME_WIN32: Do AppInit_DLLs show up in procexp? How about other injected code? How do you know what is injected?
Because these scanners are unlikely to detect custom spyware, you probably should also give Sysinternals AutoRuns a try, to catch anything that may be scheduled to run that has not been signed/verified. And of course, don't forget to use the techniques discussed in the rootkits section to detect anything that may be attempting to hide itself via a rootkit.
For the technically curious and/or those concerned about custom keyloggers, there are two main types of windows keyloggers:
Message-hook and other application-level keyloggers can also be fooled in this way, but they can attempt to do things like sort keystrokes by destination window, target only specific apps, take screenshots, and even attempt to capture cut and paste events. In fact, most commercially available software keyloggers have advanced to the point where they are able to track both cut and paste activity and sort keystrokes according to their destination window. You can still attempt to confuse them by entering keys into other fields in the same window, however.
Be aware that antivirus software may detect hacker defender, especially before it has a chance to run. The README advises you insert <, >, ", and & characters randomly into the config file fields to help avoid detection, though obviously this is not fool proof. To conceal the Hacker Defender executable, you may wish to run it through Morphine, which is an executable encryptor. Even this is probably not foolproof, so use with caution if you are in an environment where the network administrator receives virus information on your PC.
FIXME: In a future revision, write up how to turn a webcam (and/or audio mic) into a security camera, to watch over your computer while you are gone in order to catch a 3rd party in the act of installing/retrieving a hardware or software keylogger at your computer. An excellent writeup for Mac OS can be found at engadget. For Linux there is Gspy, SCRAP, and Motion. A HOWTO on building a mini computer dedicated just to video surveillance on Linux is available at MagicITX. For windows, Dorgem has been discontinued, but it allows you to capture video when the camera detects motion.
On Windows, it is also possible to install monitoring software such as those listed here to monitor your computer. Promising candidates include PCSpy, SpyMyPC, All in One Keylogger and BlazingTools Perfect Keylogger.
FIXME_WIN32: maybe also write a section on how to elevate privs on your own machine. Can OpenVPN be installed from a BartPE? Many people will not have Administrator access on their machines. Test on vmware. You probably can't add yourself to Administrators, since that is a Domain group.. Can you create a RunAs.. shell?
For pre-configured, pre-tested Tor environments, you can try out Tails Live or Anonym.OS, which are boot cd that include Tor and have everything preconfigured to use it. Alternatively, you can save yourself some effort and purchase a bootable USB Key with Tor and other privacy software pre-installed.
Alternatively, you can build a BartPE image for the same purpose if you prefer Windows. While there are a couple of massive plugin directories, my favorite route is to use The UBCD Installer (which contains many of those plugins) and then just keep any extra apps I want (such as Tor) on my USB Key. The TorPark project is excellent for this purpose.
Either of these methods provide maximum protection and assurance against software trojans and viruses. In addition, you automatically get protection against cookie logging and browser history data for free.
An alternate (and possibly more convenient for home use) method is to use VMWare (or Xen) to create an innocuous looking operating system to interact with the real world. This has the advantage that if you need to use your original setup for something, you can, but for all other communications you have a system that you wouldn't mind being attacked. Furthermore, VMWare has a feature that allows you revert to a known safe snapshot of the OS at any time, which can be useful to ensure you haven't been trojaned or acquired any persistent cookies during your session. The snapshot feature of Xen is still in development, but various hacks are possible to get the same effect.
It should also be noted that anything uncovered while executing a warrant is admissible in court, even if it was not what the agents were looking for.
In the case of threat of civil action, it may be desirable to employ some form of steganographic filesystem so that the process of discovery cannot be used to assume you have destroyed incriminating evidence. Your best bet for this is TrueCrypt, which has an appealing hidden volume mode which can provide deniability for civil situations where you are compelled to give up the key during discovery. It exists for Windows and Linux, but since it is the only non-broken implementation of an encrypted filesystem for Windows, the writeup for it is right below the Windows sub-section. If you decide to use TrueCrypt for Linux, you should be aware that there are secondary logs (ie bash history on Linux) that can be used to demonstrate that files exist if they are not carefully purged.
In a criminal situation the rules are a bit different. In the US, you may have some luck in claiming that your encryption key is protected by your 5th amendment right to not incriminate/testify against yourself. However, be aware that if you are subpoenaed to testify against another individual, you can be ordered to give up their key, unless they are your spouse. In the event that you are ordered to testify against someone else, you can request immunity from the prosecution to protect you from any incriminating evidence found as a result of the key disclosure.
Your ability to assert your 5th amendment right (and thus be eligible for immunity) ultimately rests with the decision of the judge. If he thinks your 5th amendment right does not apply to the key due to the lack of real threat of incrimination or some other twisted legal logic and you still refuse to surrender it, you can be sentenced to up to 6 months in jail for contempt of court. Note that you can still be charged with contempt for refusing to obey even if you believe a higher court would rule in your favor. However, refusing to comply would get you a good deal of (most likely positive) press attention. Nobody likes to see people imprisoned for refusing to testify against themselves, even if some legal loophole would allow it.
There has been recent political maneuvering in the UK to attempt to enable Part III of the Regulation of Investigatory Powers Act to give the government the power to demand your keys even in the cases where it may incriminate you.
This is particularly short sighted for a number of reasons, the most obvious being: the ramifications of the damage of trust in SSL certificates and banking communications; the inability to discern what is encrypted data and what is simply random application data; the inability to discover or prove with any certainty exactly how many passwords there are; the unspecified language as to whether key files count as password, and what happens if they are lost or destroyed; and the inability to prove that the subject hasn't legitimately forgotten the password (which, with the infrequent use patterns of filesystem passwords, is entirely possible and even common among users). The rest of the world should thank the UK if decides to take it upon itself to prove the stupidity of this action for us. I have no doubt that this measure cannot survive in any country with a legitimate constitution or other declaration of human rights, for good reason. Get ready, hilarity is about to ensue.
So enough of that. Lets discuss filesystem cryptography on each of the 3 major platforms, as well how to erase data securely as you move it from non-encrypted storage to encrypted storage. As usual, *BSD users are left to fend for themselves. If anyone would like to submit a quick and dirty BSD writeup for this HOWTO, don't hesitate.
Under all of the following systems, you will need to make one or more passwords for each encrypted volume. You should avoid writing these passwords down at all costs, but note that filesystem passwords are particularly easy to forget, since they are used infrequently. As mentioned above, this fact makes mandatory key disclosure particularly short sighted. It is very possible to forget filesystem keys and risk complete data loss. For this reason, you should mentally rehearse your passwords every day for several weeks after you create them to make sure you do not forget them. I consider myself fairly mentally competent, but I have still lost more than one encrypted volume after creating it because the password was used once for creation and then forgotten.
Setting up dm-crypt is relatively easy to do (at least for a simple loop-back filesystem), and their wiki has several good HOWTOs. Unfortunately, setting it up right can be extremely hard and involved. Please read this guide carefully, as there are many subtleties than can catch you off-guard.
To protect against the legal snafus mentioned above, I prefer a bit different approach than that given on the Wiki for actual device creation. I prefer to use GPG to encrypt the filesystem key, and have the passphrase I type into the keyboard be the password to the GPG key. This enables you to change the password without having to rebuild the filesystem. It also enables you to carry the key with you on a USB microdrive to ensure its safety and also to prevent anyone from mounting the fs even if they know the password. In emergency situations, the USB key can be destroyed, and the data can never be recovered. In this way, you can be in full compliance with a court order requiring the password for the filesystem and still not reveal your data. Note that if you destroy a key after a court demands to see it (or simply refuse to give up the password) you can be held in contempt of court and sentenced to jail time (in the US, this is 6 months or less, however). However, if the key/data is a substantial portion of the prosecution's case, and the sentence you are facing is more than 6 months (or if you are a hardcore civil libertarian type), you may want to tell them to fuck off anyway. Probably would get you a good deal of (most likely positive) press attention. Nobody likes to see people imprisoned for refusing to testify against themselves, even if some legal loophole would allow it.
For added safety, I prefer to move /var, /tmp, and /home to /crypto and create symlinks back to /, so that .bash_history and system logs aren't available to someone who might want to prove you have certain files or access times. You should run telinit 1 before doing this, to ensure that no daemons are running and actively using those directories when you move them.
Once this is complete, you'll want to make sure that your crypto fs is mounted before anything tries to use /var. The way I prefer is to create a script interface to gpg that has the right options to enable it to work from /etc/rc.d/rc.sysinit. For Fedora Core users, you can typically just call that script right after the rest of the local filesystems are mounted. Search the rc.sysinit file for "mount -a -t" or "Mounting local filesystems". You should end up somewhere near a bunch of mount -f lines and an SELINUX relabeling call. Stick a call to /path/to/mount-crypto right before the SELINUX stuff. If you prefer to run your system in runlevel 5 (with graphical login), you will need to edit /etc/grub.conf and remove the rhgb option from the kernel config line in order to be able to enter your FS password. Note that you will probably want to have a boot disk handy or be ready to do linux init=/bin/bash from the boot command line in case something goes wrong.
Alternatively, if you don't wish to be prompted for a password at bootup because the machine is a remote server, you can use chkconfig or edit /etc/rc.d/rcN.d (where N is your runlevel -- type runlvl as root if unsure) to remove syslog, sendmail, crond, atd, and any other daemon that shows up in an lsof -n | grep var and lsof -n | grep tmp. In summary:
Note that if your system is running remotely, it may not be too happy about brining sshd up for you after the unmount or upon bootup, unless you mkdir -p /crypto/var/empty/sshd/, and mkdir -p /crypto/var/lock/subsys in the unmounted dm-crypt directory.
It should go without saying, but if you go through all this trouble to encrypt your harddisk, you shouldn't leave backups lying around on unencrypted media. If you have to transfer a backup to unencrypted media, tar it up, and then use gpg --cipher-algo AES256 -c to encrypt it. GPG does compression before encryption.
Last, but not least, you should also consider encrypting your swap so that pieces of programs you run aren't recoverable after shutdown. I prefer to use the lazy route and just make a swapfile on the encrypted filesystem.
If you do choose to run Windows on your desktop, an alternative you might consider is building a Linux fileserver that houses all your sensitive documents on an encrypted Samba share, but be aware that Samba does not encrypt traffic. You can set up an OpenVPN tunnel between your Linux and Windows machine, however, if there is danger of someone monitoring your network.
Additionally, they both have support keyfiles. The support for this feature is particularly excellent. This allows you to create a collection of both fake and real keyfiles such that your adversary has to know which subset are actually required (assuming they can even find any of them), in addition to knowing your password. It can be seen from this formula (or by visualizing keyfile "fake/real" as a binary string), that for N keyfiles, the total number of combinations of keyfiles is 2N. Thus you can easily provide for a large number of possible combinations of both keyboard and mouse input (which is particularly comforting if keyloggers are a possibility). Couple this with hidden volume support and clever concealment of encrypted volume files amongst other large and unintelligible program data files, and you have yourself a pretty secure and undetectable encrypted setup. Just remember to frequently mentally rehearse all of your passwords (instead of writing them down), as mentioned above. Filesystem passwords are used much less often than login passwords. It is easy to forget them.
Newer versions can also encrypt the entire system partition including the Windows Swap file, standby/sleep file, hibernation files and all the other little things that can save sensitive information across session.
On Linux, however, an encrypted volume can of course contain a swapfile as discussed above, and on PDAs swapfiles don't exist
This is problematic in that The Man could simply throw in a hub with a bunch of machines that would also respond to those IPs and turn it on as soon as they disconnected your box from the network (assuming they figured out what to do about power). So after thinking about it for a bit, I decided I didn't even want to make it that easy for that bastard. So I wrote a pair of scripts you can run on various machines on your LAN (or across the Internet) to ensure network connectivity.
The way this works is there is a client script and a server script. The client script is the one you run on your secure machine, and the server script you run on any host on the Internet. The scripts are written in standard perl, and depends upon the Unix utility md5sum, which is available on Linux, Mac OS, and cygwin. You should be able to replace md5sum with any command line hashing program, such as FSUM if you do not want to install all of cygwin.
When you start the pair (start the server first), they ask you for a password to be used for that session. The client script then periodically (every 0.25 seconds by default) sends the MD5 (or SHA1) hash of a random number (from /dev/urandom) to the server script, and the server script appends this random number to your password. It then hashes this combined value, and sends the result back to the client. The client compares this value to one it generates locally via the same manner. If they match, the process is repeated with a new random hash, if they do not match, a script you specify (such as crypt-stop to unmount your drives) is run. The script is also run after a timeout period (1 second) or if the TCP connection otherwise dies.
This is a common cryptographically secure authentication technique that is used to prove two people know a password without revealing it to a third party (The Man).
Note that there is nothing stopping you from running multiple copies of this program on a given machine to connect to multiple servers with different passwords, in case there is concern a password could be recovered by attacking a particular server. It won't hurt your volume to attempt to unmount it twice.
Whenever the topic of secure deletion comes up, an argument will inevitably be raised as to how many times a file must be overwritten and what must it be overwritten with in order for it to be truly gone. The tinfoil hat crowd will tell you all sorts of horror stories about this or that government agency that has the power to read through N+X layers of random overwritten data, where N was the number you asserted was secure and X is some arbitrary additional amount they made up to make you feel bad.
My personal opinion is that somewhere between 2 and 5 really is all you need. As drives become larger, the cost factor involving finding data below an arbitrary number of writes over the span of the entire disk grows tremendously. And then who's to say that the data wasn't there from a previous owner, possibly even someone who returned a drive back to the manufacturer because of some defect that was corrected and the drive resold. The other factor is that if secure deletion takes forever, you will find yourself doing it less and less, and postponing it more and more because it will interfere with your real work. This is obviously much worse than minimally wiping something quickly right away and getting it over with.
Flash drives (and SSDs) are difficult to wipe due to the internal wear-leveling preventing the OS from writing to the same flash block repeatedly. The file may be made inaccessible through the drive interface, but if the flash chip is removed from the drive, it can be completely dumped out.
For most uses, I would just accept the defaults. To wipe a file, wipe filename should be fine. wipe -r directory will get an entire directory recursively. To wipe all free space on a drive, wipe -a some_file should do the trick.
Modern Linux filesystems cannot be wiped at the individual file level due to the internal journal saving changes to the files. These include reiserfs, ext (>=3) and btrfs filesystems.
It is also possible to erase free space on your Mac if you emptied the trash bin without using the secure file deletion option. For instructions on how to do this, go to Applications/Utilities and select Disk Utility, and select your Macintosh HD. From here, under the "Erase" header, select Erase Free Space. This overwrites all the empty free space on your hard drive. However, if there is material on your hard drive that is unreadable by OSX (i.e. Windows Partition, etc.), this will remain untouched.
Use '-P' parameter of rm command for secure wiping in OpenBSD.
TRINITY: We think you're bugged. Try to relax. Come on, come on...
TRINITY: CLEAR!
THOMAS: Jesus Christ! That thing is real?!
Intrusive Surveillance basically means any type of surveillance that is occurring due to some form of intrusion into your machine. As such, it is the most difficult form of "forensics" to defend against, since doing so involves the securing and hardening of your operating system against attack. While keeping up with security patches is a necessary condition to be secure, sadly it is not sufficient. In spite of this, there are several obvious indicators that someone is investigating you/watching what you do with your computer.
I should probably start this section off by saying that if you need anonymity, you should probably reinstall your system now. Especially if you use Windows and Internet Explorer. It is way too easy for those machines to become infected with spyware if you haven't been practising safe computing up to this point. I've even seen spyware that modifies the Internet Explorer user agent string to contain a unique 128bit identifier.
Root Kits
Root Kits are the most intrusive and stealthy form of system
surveillance around. They are typically designed to take complete
control of your operating system kernel, causing it to lie to you about
what processes are running, what network connections it is making,
system diagnostics, and so on. Luckily, if someone just wants to spy on
you, they are much more likely to only install a keylogger rather than a
full blown rootkit. However, knowing some basic info about how to
detect rootkit installation is helpful for finding keyloggers as well,
especially since as keyloggers grow in sophistication, the line between
them and complete rootkits will blur.
For most users, this section probably covers a threat model they do not need to worry about (although with rootkits being used by RIAA goons, this is rapidly changing). Many users will want to just skip to the section on watching your back,
which describes how to use rootkits to hide various items on your
system from a fascist administrator and for plausible deniability ("a
hacker did it! Who installs a rootkit on their own machine?"). Still,
even in this case a read over this section is recommended, since it will
tell you how to undo what you have done.
Linux
On Linux, there are a couple of things you can do to protect yourself
from rootkits. The easiest, least technical method is to do an ls -laR / > dirty.list on your live system, and then compare this to an ls -laR /mnt/hdd > clean.list on a Knoppix live CD. The command line utility diff -u clean.list dirty.list can be used to compare the two listings. The utility xxdiff
may make this easier to view if there are lots of differences due to an
encrypted filesystem not being mounted, proc missing, udev, etc.
If you intend to audit your machine while it's live, the very first thing you need to do is ensure that your kernel hasn't been modified via a rogue driver module. While lsmod will list loaded modules, it is possible (and quite trivial) to remove module names from this list while keeping the module in the kernel. For this reason, if you are concerned about local surveillance, you are advised to build a kernel without module support (preferably with grsec, which adds protection against ways to force modules into a module-free kernel). This will prevent someone from loading a module that could hide processes and network connections, log keys, etc.
If this is not an option (it is very difficult to get a monolithic kernel running, especially on systems that require closed-source drivers), you can perform a manual audit. I provide a couple Linux kernel modules that can aid in the auditing process. They will help you check for common ways rootkit modules hide themselves, and also can help you to ensure your kernel syscall path has not been tampered with. The ideas are based on this Security Focus article and this article on rootkit operation. All methods discussed there can be examined with those modules. The reason I created these modules is that Fedora's policy of disabling /dev/kmem has broken existing utilities that performed these functions. In particular, samhain is capable of performing these checks automatically for you on non-Fedora and *BSD systems.
Once you know your kernel hasn't been subverted, you can check the output of netstat -natup to see if any strange programs have established network connections to external hosts. ps xa will show you all the processes running on your system. If you don't recognize something, scroogle it.
To help watch for modification of your userland programs, you can run Chkrootkit and/or Rootkit Hunter, and also periodically run rpm -Va to verify checksums of your installed packages. TripWire and AIDE are also options for maintaining system integrity.
Mac OS X
If you have a second Mac, the easiest way to scan for a rootkit that is hiding files is to run an ls -laR / > dirty.list
on your live system and compare this to an ls -laR /path/to/disk >
clean.list run from a "clean" Mac that has mounted your hard disk drive
in Target Disk Mode. The command line utility diff -u clean.list dirty.list can be used to compare the two listings. Compiling the utility xxdiff may make this easier, but you have to run it in the X windows emulator, which is painful.
As far as live inspection and countermeasures, unfortunately, Mac OS doesn't have the advantage Linux has in being able to compile a monolithic kernel. This means that it is much more difficult to ensure that your system integrity is still valid. Just like on Linux, it is possible to write a kernel extension that goes in and verifies that none of the system calls have been hooked, and that the keyboard interrupt vector is still intact, but I don't think such a extension has been written yet. FIXME_MAC: any takers? FIXME_MAC: how about gdb + the syscall table? Is there a map file?
There is a piece of malware that exists for Mac OS X called Opener. It functions as a trojan, spyware, and a keylogger. It's worth searching your filesystem for it's presence. FIXME_MAC: more details on how it works..
However, since opener is not a kernel-level rootkit, it can be detected with system monitoring software such as CheckMate. Additionally, you can check for suspicious TCP and UDP connections via lsof -i TCP -i UDP. However, note that kernel-level rootkits like WeaponX are able to make themselves invisible from these checks.
Windows
There are a few rootkits for Windows available which are capable of
hiding processes, services, files, etc. In addition, most rootkits come
with some form of device driver that is installed in order for them to
do their cloaking by directly manipulating kernel objects.
For general rootkit detection, Sysinternals puts out a tool called Rootkit Revealer that uses various Windows APIs to check for inconsistencies (ie comparing raw registry data to API reported, etc). It does not use this information to detect rootkits by name, but instead prints a list of anomalies. If you have a clever rootkit implementer, be aware that they can hide among the noise.
If you are interested in looking for hidden files, or executables, your best bet is to create a bootable CDROM from your Windows XP install media. You can then look through your directories after booting from this CD and ensure they match your system under normal boot. UBCD has a tool called RootKitty which basically compares file listings of your computer from the CD versus while it is running on a normal boot.
Specific rootkit removal tools exist also. Currently the most popular of these are BlackLight and ICESword which both check for changes made to kernel memory to detect rootkits like FU, as well as hooks to functions in kernel space. In 3rd place is VICE, which checks for hooks in commonly targeted kernel and userland functions. The main issue with VICE is that for usermode, it will spew out one hell of a lot of false positives, as it is common for the Windows DLLs to "hook" one another.
The RKDetector utility linked off of this Hacker Defender Removal page is also pretty nice. While it has been written primarily to detect the Hacker Defender rootkit, it is also capable of finding hidden processes and services that may have been cloaked by other rootkits (such as FU).
Also available is UnHackMe, a shareware tool designed for AFX removal.
Lastly, just like Linux and Mac OS, Windows enables you to list active Internet connections and their associated processes. netstat -nab should do the trick.
FIXME_WIN32: Do AppInit_DLLs show up in procexp? How about other injected code? How do you know what is injected?
Keyloggers and Spyware
If someone is out to spy on you, by far the most likely thing they
will do is install a keylogger. Some keyloggers can be easy to find,
some almost impossible. There are two types of keyloggers, software and
hardware.
Hardware
The main thing to watch for is an extra extension jack coming between your keyboard and the back of your computer. However, also be wary of internally installable keyloggers. If your physical environment can't be trusted (note that depending on your situation, this may or may not include your home),
buy a new keyboard and seal it with epoxy, or some tamper evident
mechanism. Also periodically check the inside of your computer for
dangling pieces of electronics coming between your keyboard port and
your motherboard. Normally there should only be wires or nothing at all.
People have been prosecuted using keylogged data as evidence.
Software
Windows
Your best bet for guarding against software keyloggers in Windows is to install some form of anti-spyware software. My personal favorites are Spyware Doctor, Microsoft's AntiSpyware, AdAware and SpyBot (in that order), since they all provide free versions that are fully capable of removing spyware they discover and also have received good reviews on the web. Although I have not tried it, Symmatec's Antivirus+AntiSpyware is supposedly very good as well, though pricey.Because these scanners are unlikely to detect custom spyware, you probably should also give Sysinternals AutoRuns a try, to catch anything that may be scheduled to run that has not been signed/verified. And of course, don't forget to use the techniques discussed in the rootkits section to detect anything that may be attempting to hide itself via a rootkit.
For the technically curious and/or those concerned about custom keyloggers, there are two main types of windows keyloggers:
- Message-Hook Based
- Being relatively easy to code, message-hook based keyloggers are the most common form available. It is estimated they comprise 90% of keylogger installs.
- Their simplistic nature means that they are relatively easy to detect as well. Follow the same steps involved in looking for a Windows root kit: Check for strange processes, and check the AppInit_Dlls registry key. Alternatively, you could install this anti-keylogger. It will run for 4 hours per reboot for 10 reboots before you have to pay for the registered version. It actually watches members of your message queues and notifies you when processes attach to listen for events. FIXME_WIN32: Are there more subtle ways to inject DLLs using hooks such that you can hijack, say, explorer.exe to do your keylogging? Yes. How do we enumerate them? SetWindowsHookEx with WM_DEBUG. Also !chkimg in kd.. CodeMe.
- Device Driver Based
- To date, I've only run into one commercially available implementation of a device driver based keylogger on Windows. Basically the way it works is it hooks itself onto your keyboard device driver and then writes the keys to a file, which can be viewed with an external program.
- While in theory a kernel mode driver can be made next to impossible to detect, in this case it is quite easy to find. You have a few options. The easiest thing to do is go to Control Panel, click on Keyboard, and then click on the "Driver Details..." button. That will list all the .sys files involved in making your keyboard work. The ones with a green checkmark are signed by Microsoft, and clicking on them will tell you so. If you see any that lack a green checkmark, they are most likely a keylogger. Alternatively, you can run regedit.exe to search your registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class for either "Keyboard" or "kbdclass". This is where all your device drivers live. Once you find the keyboard driver, check to make sure it ONLY has kbdclass under the UpperFilters value. If it has anything else after kbdclass (specifically the unsigned driver from control panel) edit it and remove it. Then search again for that name under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services and delete any subtrees that come up. FIXME_WIN32: Screenshots
Linux
For Linux, the rootkit detection techniques described above apply for keyloggers as well. Most Linux keyloggers will take the form of rootkits. Also, you should watch out for trojaned binaries (use rpm -Va or install tripwire or AIDE), especially ssh. You should also keep an eye on your aliases and shell rc files (eg ~/.bashrc and ~/.bash_profile) to make sure no one is sneaking an LD_PRELOADed library in on you. Last, but DEFINITELY not least, you want to make sure your ~/.Xauthority file is not world readable, and that you don't have any bizarre xhost entries. It is possible to remotely capture X events (and thus keystrokes).General Techniques Against Keyloggers
Keyloggers are typically pretty blind. Especially kernel and hardware keyloggers. If you are at a machine you cannot trust and do not feel like making it trustworthy, you do have some options to at least protect your passwords. For example, switching windows mid-password, cutting and pasting characters, and using the mouse to delete sections of text randomly are all effective against hardware and kernel keyloggers, which will only focus on actual keyboard events.Message-hook and other application-level keyloggers can also be fooled in this way, but they can attempt to do things like sort keystrokes by destination window, target only specific apps, take screenshots, and even attempt to capture cut and paste events. In fact, most commercially available software keyloggers have advanced to the point where they are able to track both cut and paste activity and sort keystrokes according to their destination window. You can still attempt to confuse them by entering keys into other fields in the same window, however.
Watching Your Back
Ok, now that we know how to find and remove keyloggers and rootkits, we're going to talk about how to use them to conceal what you are doing, and to watch for evidence of nosy coworkers. Using Hacker Defender with this config file will hide an OpenVPN installation. copy c:\windows\system32\cmd.exe Desktop\mycmd.exe will give you a command shell on your desktop that is still able to see the Hacker Defender config files.Be aware that antivirus software may detect hacker defender, especially before it has a chance to run. The README advises you insert <, >, ", and & characters randomly into the config file fields to help avoid detection, though obviously this is not fool proof. To conceal the Hacker Defender executable, you may wish to run it through Morphine, which is an executable encryptor. Even this is probably not foolproof, so use with caution if you are in an environment where the network administrator receives virus information on your PC.
FIXME: In a future revision, write up how to turn a webcam (and/or audio mic) into a security camera, to watch over your computer while you are gone in order to catch a 3rd party in the act of installing/retrieving a hardware or software keylogger at your computer. An excellent writeup for Mac OS can be found at engadget. For Linux there is Gspy, SCRAP, and Motion. A HOWTO on building a mini computer dedicated just to video surveillance on Linux is available at MagicITX. For windows, Dorgem has been discontinued, but it allows you to capture video when the camera detects motion.
On Windows, it is also possible to install monitoring software such as those listed here to monitor your computer. Promising candidates include PCSpy, SpyMyPC, All in One Keylogger and BlazingTools Perfect Keylogger.
FIXME_WIN32: maybe also write a section on how to elevate privs on your own machine. Can OpenVPN be installed from a BartPE? Many people will not have Administrator access on their machines. Test on vmware. You probably can't add yourself to Administrators, since that is a Domain group.. Can you create a RunAs.. shell?
Throwaway Computing
In certain situations where you have freedom over the computer but do not trust it, you might consider using a bootable CD. The obvious choice is Knoppix or a Knoppix derivative. I prefer Auditor Linux since it automatically supports my wireless card (unlike Knoppix) and comes with lots of useful security tools right on disc. It is possible to customize Knoppix using a USB key, so a Knoppix CD+tor on your USB key might be helpful if you frequently find yourself in shady labs. The Knoppix Wishlist includes Tor, so maybe that will happen someday.For pre-configured, pre-tested Tor environments, you can try out Tails Live or Anonym.OS, which are boot cd that include Tor and have everything preconfigured to use it. Alternatively, you can save yourself some effort and purchase a bootable USB Key with Tor and other privacy software pre-installed.
Alternatively, you can build a BartPE image for the same purpose if you prefer Windows. While there are a couple of massive plugin directories, my favorite route is to use The UBCD Installer (which contains many of those plugins) and then just keep any extra apps I want (such as Tor) on my USB Key. The TorPark project is excellent for this purpose.
Either of these methods provide maximum protection and assurance against software trojans and viruses. In addition, you automatically get protection against cookie logging and browser history data for free.
An alternate (and possibly more convenient for home use) method is to use VMWare (or Xen) to create an innocuous looking operating system to interact with the real world. This has the advantage that if you need to use your original setup for something, you can, but for all other communications you have a system that you wouldn't mind being attacked. Furthermore, VMWare has a feature that allows you revert to a known safe snapshot of the OS at any time, which can be useful to ensure you haven't been trojaned or acquired any persistent cookies during your session. The snapshot feature of Xen is still in development, but various hacks are possible to get the same effect.
Search and Seizure
The last and most perilous threat to your privacy is when The Man busts in and takes all your gear (and they will take all of it). This sucks, and will often leave you without computer equipment for the better part of a year. There are limits on scope of warrants, but the courts have proved to err on the side of The Man. Of course, it is always advisable to practice good Kung Foo so that he's never able to trace you in the first place, but luck favors the prepared. You never know when some scumbag decides to turn states evidence, or some enemy of yours decides it might be funny to see you sweat out an investigation for no reason. As such, lets spend a bit of time discussing how search and seizure functions in the US.Warranted and Warrantless Search
There are several methods by which an Agent can obtain the legal right to search and seize your digital goods, most of which are conveniently outlined in the US DOJ Search and Seizure Manual (local copy). There are a couple instances where they can get away with searching you WITHOUT A WARRANT that you might not have anticipated:Private Searches
These are probably the most dangerous type of warrantless search, because it is most likely to catch you off guard. Essentially a private search is a search conducted by someone who is not acting as an agent of the government (ie a vigilante). In this case, a neighbor, roommate, officemate, janitor, repairman, maid, sysadmin, etc can be snooping around on your computer, discover what they might think is criminal evidence (such as this HOWTO :), and call the police. The police are then legally authorized to repeat the search conducted by the private citizen without warrant (unless it was a search of a residence), and arrest you for both the original and any additional contraband (within the scope of the original search). Bad news all around.Searches/Consent by Employers/Coworkers
In this case, not only can employers and coworkers conduct "private searches", but they can also consent to search of your office space for you. How nice. Don't forget: you're their slave, coppertop.Implied Consent
This is another beauty. If you've signed away or otherwise have been warned of a reduced right to privacy (ie through a work contract or login banner), you can be considered to implicitly consent to search. I wonder if this is why AOL changed its Terms of Service (before changing them back due to prompt public outcry, and zero corporate media coverage).Exigent Searches
If the feds have reason to believe that there is extreme urgency in obtaining the data due to either danger to person or threat of its destruction, they can search without a warrant. Thankfully "laptop batteries might be about to run out" was ruled not to be an exigent circumstance. But note that some Agent did try to use that as an excuse.. Gotta love The Man.No-Knock/"Sneak and Peak" Searches
If the feds can show that there is either danger of violence or threat of destruction of evidence if they announce their search, they can obtain a "No-Knock" warrant, which allows them to barge right in if you are home or not. Also, with the passage of the Patriot Act, they are also able to conduct "Sneak and Peak" searches. Typically "Sneak and Peak" search cannot involve seizure, and the authorities must typically notify you within 90 days. For defensive techniques against "Sneak and Peak" searches, consult the section on watching your back.Subpoena of ISP Records
A subpoena is a court order to testify or produce evidence. The downside is it can be used if you are not suspected of a crime but instead may only have evidence relating to a crime. It is possible for the feds to obtain your ISP records, files, and "opened" emails via subpoena. However, they do have to notify you of this fact immediately, unless there is fear of danger to person, flight, destruction of evidence, or otherwise jeopardizing the investigation.Deception of Purpose
This little doosey was a fun one to discover. How to Be Invisible cites a January 1994 FBI Law Enforcement Bulletin that states agents may disguise themselves as utility repairmen, delivery personnel, distressed motorists, etc, and ask for entrance into your home to make a phone call, look up something on the web, etc. Once you grant them entrance, anything they happen to see (or claim to smell) in plain view can be used to go back and get an actual warrant. Good times!Trash Inspection
Ruling that there is no expectation of privacy for discarded items, the Supreme Court has held that trash is not protected by the 4th amendment. This ruling has allowed the government to tell garbage collectors that certain trash bins are to be delivered directly to their doorstep, without warrant. They do not even have to collect it themselves.Retroactive FISA Warrants
The USA Patriot Act has expanded the ability for the FBI to obtain secret warrants against "terrorism" suspects. At the direction of the Attorney General, the FBI is able to conduct a secret search of your residence, phone communications, and/or Internet activity and then 72 hours later, apply for a secret search warrant to do so from the FISA court. Since the FISA court is secret, and has only turned down 4 requests in the past 5 years, this power has essentially destroyed any guarantee against unreasonable search. The Patriot Act also amended 18 USC 2518-7 to allow for "specially designated" law enforcement officers to conduct warrantless search and surveillance for 36 hours in situations of suspicion of organized crime, national security interest, and threat of serious physical injury to a person.Search of Corporate Records
In an astounding display of new advances in Constitutional interpretation, the Supreme Court ruled in 1976 that since corporations are not natural persons, they do not (nor even their owners!) enjoy any protection from the search and seizure of their records. My oh my, that certainly makes it convenient to fetch just about any information on anyone. With this ruling, the US government is able to enumerate just about everything in your home simply by demanding purchase records from your credit card company. The ruling also extends to subpoenas of logs and other files at colocation providers, and also provides the basis for the "constitutionality" of National Security Letters.It should also be noted that anything uncovered while executing a warrant is admissible in court, even if it was not what the agents were looking for.
Civil Procedure
In addition to the above, you need to be at least peripherally aware of the rules of discovery in civil procedure, especially if it is likely that someone may seek to sue you for damages instead of (or in addition to) pressing charges. In civil procedure, if there is reason to believe that you may have evidence supporting the plaintiffs claim, the process of discovery enables them to demand evidence/records from you. If you destroy this evidence, then not only are you potentially liable for criminal charges, but the plaintiff also is allowed to assume that the destroyed records contained the proof they sought. In the case of civil litigation by large corporations against individual people, the police are sometimes called in to immediately seize relevant materials without warning. Isn't that great?Encrypted Filesystems
The solution to these perils hinges on cryptography, and each system has its own way of accomplishing this. Depending upon your threat model for The Man, you may want different levels of assuredness that he cannot obtain your data. As described above, your two main classes of threat are civil action, and criminal action.In the case of threat of civil action, it may be desirable to employ some form of steganographic filesystem so that the process of discovery cannot be used to assume you have destroyed incriminating evidence. Your best bet for this is TrueCrypt, which has an appealing hidden volume mode which can provide deniability for civil situations where you are compelled to give up the key during discovery. It exists for Windows and Linux, but since it is the only non-broken implementation of an encrypted filesystem for Windows, the writeup for it is right below the Windows sub-section. If you decide to use TrueCrypt for Linux, you should be aware that there are secondary logs (ie bash history on Linux) that can be used to demonstrate that files exist if they are not carefully purged.
In a criminal situation the rules are a bit different. In the US, you may have some luck in claiming that your encryption key is protected by your 5th amendment right to not incriminate/testify against yourself. However, be aware that if you are subpoenaed to testify against another individual, you can be ordered to give up their key, unless they are your spouse. In the event that you are ordered to testify against someone else, you can request immunity from the prosecution to protect you from any incriminating evidence found as a result of the key disclosure.
Your ability to assert your 5th amendment right (and thus be eligible for immunity) ultimately rests with the decision of the judge. If he thinks your 5th amendment right does not apply to the key due to the lack of real threat of incrimination or some other twisted legal logic and you still refuse to surrender it, you can be sentenced to up to 6 months in jail for contempt of court. Note that you can still be charged with contempt for refusing to obey even if you believe a higher court would rule in your favor. However, refusing to comply would get you a good deal of (most likely positive) press attention. Nobody likes to see people imprisoned for refusing to testify against themselves, even if some legal loophole would allow it.
There has been recent political maneuvering in the UK to attempt to enable Part III of the Regulation of Investigatory Powers Act to give the government the power to demand your keys even in the cases where it may incriminate you.
This is particularly short sighted for a number of reasons, the most obvious being: the ramifications of the damage of trust in SSL certificates and banking communications; the inability to discern what is encrypted data and what is simply random application data; the inability to discover or prove with any certainty exactly how many passwords there are; the unspecified language as to whether key files count as password, and what happens if they are lost or destroyed; and the inability to prove that the subject hasn't legitimately forgotten the password (which, with the infrequent use patterns of filesystem passwords, is entirely possible and even common among users). The rest of the world should thank the UK if decides to take it upon itself to prove the stupidity of this action for us. I have no doubt that this measure cannot survive in any country with a legitimate constitution or other declaration of human rights, for good reason. Get ready, hilarity is about to ensue.
So enough of that. Lets discuss filesystem cryptography on each of the 3 major platforms, as well how to erase data securely as you move it from non-encrypted storage to encrypted storage. As usual, *BSD users are left to fend for themselves. If anyone would like to submit a quick and dirty BSD writeup for this HOWTO, don't hesitate.
Under all of the following systems, you will need to make one or more passwords for each encrypted volume. You should avoid writing these passwords down at all costs, but note that filesystem passwords are particularly easy to forget, since they are used infrequently. As mentioned above, this fact makes mandatory key disclosure particularly short sighted. It is very possible to forget filesystem keys and risk complete data loss. For this reason, you should mentally rehearse your passwords every day for several weeks after you create them to make sure you do not forget them. I consider myself fairly mentally competent, but I have still lost more than one encrypted volume after creating it because the password was used once for creation and then forgotten.
Linux
There are two main cryptographic filesystem solutions for Linux: dm-crypt and TrueCrypt. TrueCrypt setup is covered below, and arguably it has some more appealing features than dm-crypt, but since it is not included in any major distributions, typically you will have to recompile your kernel to support it.Setting up dm-crypt is relatively easy to do (at least for a simple loop-back filesystem), and their wiki has several good HOWTOs. Unfortunately, setting it up right can be extremely hard and involved. Please read this guide carefully, as there are many subtleties than can catch you off-guard.
To protect against the legal snafus mentioned above, I prefer a bit different approach than that given on the Wiki for actual device creation. I prefer to use GPG to encrypt the filesystem key, and have the passphrase I type into the keyboard be the password to the GPG key. This enables you to change the password without having to rebuild the filesystem. It also enables you to carry the key with you on a USB microdrive to ensure its safety and also to prevent anyone from mounting the fs even if they know the password. In emergency situations, the USB key can be destroyed, and the data can never be recovered. In this way, you can be in full compliance with a court order requiring the password for the filesystem and still not reveal your data. Note that if you destroy a key after a court demands to see it (or simply refuse to give up the password) you can be held in contempt of court and sentenced to jail time (in the US, this is 6 months or less, however). However, if the key/data is a substantial portion of the prosecution's case, and the sentence you are facing is more than 6 months (or if you are a hardcore civil libertarian type), you may want to tell them to fuck off anyway. Probably would get you a good deal of (most likely positive) press attention. Nobody likes to see people imprisoned for refusing to testify against themselves, even if some legal loophole would allow it.
Note
Since The Man will usually attempt to take all of your electronic gear right away, you will have to find some mechanism to either store the key some place safe or have an instantaneous mechanism to destroy it as soon as you hear the knock. Be advised that if your key media fails, you will lose all your data. Floppies are a no-no, but can be used to provide plausible deniability.Here are the steps to generate such a key that can be destroyed on a moment's notice:
[root@machine ~/dir]# dd if=/dev/random bs=4k count=1 | gpg -a --cipher-algo AES256 -c - > /mnt/usb/keys/fs.gpg
[root@machine ~/dir]# gpg -q -o - /mnt/usb/keys/fs.gpg | cryptsetup -v -c aes create cryptfs /dev/hdxN
[root@machine ~/dir]# mkfs.ext3 /dev/mapper/cryptfs
[root@machine ~/dir]# mount /dev/mapper/cryptfs /crypto
So basically what this does is get some random data for the fs key
material, and use gpg and AES256 to symmetrically encrypt (-c) it with
your passphrase. The next command then decrypts your key file and uses
the key material to initialize the dmcrypt driver using /dev/hdxN, where
x is one of a-d, and N is the partition number. Note you can also use
files instead of partitions, but it is not recommended, especially if
that file resides on a journaled filesystem. After that, the
/dev/mapper/cryptfs block device will appear, and you can format it for
whatever FS you like, and then mount it.
For added safety, I prefer to move /var, /tmp, and /home to /crypto and create symlinks back to /, so that .bash_history and system logs aren't available to someone who might want to prove you have certain files or access times. You should run telinit 1 before doing this, to ensure that no daemons are running and actively using those directories when you move them.
[root@machine ~/dir]# telinit 1 [or reboot into single user mode]
[root@machine ~/dir]# [killall rpc.idmapd]
[root@machine ~/dir]# [umount /var/lib/nfs/rpc_pipefs]
[root@machine ~/dir]# mv /var /tmp /home /crypto
[root@machine ~/dir]# ln -s /crypto/* /
[root@machine ~/dir]# [vim /etc/selinux/config]
[root@machine ~/dir]# telinit 3 [or reboot]
On Fedora Core 4 systems, you'll need to killall rpc.idmapd and possibly umount /var/lib/nfs/rpc_pipefs before the mv, or just reboot into single user mode. In addition, this whole setup is likely to cause SELinux conflicts, so you should probably set SELINUX=permissive or SELINUX=disabled in /etc/selinux/config (or add selinux=0 to the kernel boot parameters in /etc/grub.conf).
Once this is complete, you'll want to make sure that your crypto fs is mounted before anything tries to use /var. The way I prefer is to create a script interface to gpg that has the right options to enable it to work from /etc/rc.d/rc.sysinit. For Fedora Core users, you can typically just call that script right after the rest of the local filesystems are mounted. Search the rc.sysinit file for "mount -a -t" or "Mounting local filesystems". You should end up somewhere near a bunch of mount -f lines and an SELINUX relabeling call. Stick a call to /path/to/mount-crypto right before the SELINUX stuff. If you prefer to run your system in runlevel 5 (with graphical login), you will need to edit /etc/grub.conf and remove the rhgb option from the kernel config line in order to be able to enter your FS password. Note that you will probably want to have a boot disk handy or be ready to do linux init=/bin/bash from the boot command line in case something goes wrong.
Alternatively, if you don't wish to be prompted for a password at bootup because the machine is a remote server, you can use chkconfig or edit /etc/rc.d/rcN.d (where N is your runlevel -- type runlvl as root if unsure) to remove syslog, sendmail, crond, atd, and any other daemon that shows up in an lsof -n | grep var and lsof -n | grep tmp. In summary:
[root@machine ~/dir]# runlvl
[root@machine ~/dir]# lsof -n | grep var
[root@machine ~/dir]# chkconfig --level 3 syslog off
[root@machine ~/dir]# chkconfig --level 3 sendmail off
[root@machine ~/dir]# chkconfig --level 3 crond off
[root@machine ~/dir]# ...
Unfortunately, there are likely to be a crapload of daemons you're
going to have to do this for, especially if you run Fedora Core 4. Once
you finish this, you'll want to make a script that mounts and then
starts all the needed daemons. As a starting point, you can have a look
at my crypt-start and crypt-stop.
Note that if your system is running remotely, it may not be too happy about brining sshd up for you after the unmount or upon bootup, unless you mkdir -p /crypto/var/empty/sshd/, and mkdir -p /crypto/var/lock/subsys in the unmounted dm-crypt directory.
It should go without saying, but if you go through all this trouble to encrypt your harddisk, you shouldn't leave backups lying around on unencrypted media. If you have to transfer a backup to unencrypted media, tar it up, and then use gpg --cipher-algo AES256 -c to encrypt it. GPG does compression before encryption.
Last, but not least, you should also consider encrypting your swap so that pieces of programs you run aren't recoverable after shutdown. I prefer to use the lazy route and just make a swapfile on the encrypted filesystem.
Note
An alternate procedure to protect /var and /tmp is to encrypt your entire root filesystem and place the decryption scripts on an initial ramdisk. I have not done this, because it means that you cannot reboot your servers remotely, but it requires a hell of a lot less hacking with initscripts and SELinux permissions. As you saw above, this process can get pretty involved.
The Gentoo Wiki has a page on setting up an encrypted root filesystem for Gentoo, and Linux Journal has an article on setting up an encrypted root for Fedora Core 3. This Ubuntu Forum Post describes the same process for Ubuntu.
Debian's installer has the capability to create partitions that are encrypted with a key that is randomized and reformatted every boot. This can be used for swap and /tmp partitions that cannot be decrypted once the system is shut off.
Mac OS
In MacOS you have two options. If you trust Apple (and your sysadmin, where applicable), and really believe there is no master password set, you can use the built-in FileVault feature to encrypt your entire home directory with 128 bit AES, or you can attempt to do it yourself. Given the amount of work involved in doing it yourself, I would suggest trusting Apple and going the FileVault route.Windows
In Windows, everything is easy. Unfortunately, everything also sucks. For some reason, Windows implements encryption at the filesystem layer, and you can enable it by right clicking on a file/folder and going to Properties->Advanced. Unfortunately, all of the file names in an encrypted directory are still viewable without the key. Worse still, the Administrator account has access to all these files through a special recovery key, and there seems to be no option to disable this.If you do choose to run Windows on your desktop, an alternative you might consider is building a Linux fileserver that houses all your sensitive documents on an encrypted Samba share, but be aware that Samba does not encrypt traffic. You can set up an OpenVPN tunnel between your Linux and Windows machine, however, if there is danger of someone monitoring your network.
TrueCrypt/FreeOTFE
Another alternative is to use TrueCrypt or FreeOTFE, which actually provides the benefits of both crypto and steganography in that it has an emergency password that you can use if ordered to reveal your filesystem password under threat of force. Both of these programs are good, and more than makes up for the pile of suck that is NTFS encryption, and now also has a Linux/Windows Mobile version. Creation of hidden volumes is pretty straight forward. There is online documentation for both of them (truecrypt - freeotfe), but really you only need to be aware of a couple of things. First, it is best to create the hidden and the outer volumes at the same time. The outer volume is created first, and is populated (by you) with non-sensitive files and encrypted with the emergency password. Once the volumes are created, you can mount the same volume file/partition with either password to test it out.Additionally, they both have support keyfiles. The support for this feature is particularly excellent. This allows you to create a collection of both fake and real keyfiles such that your adversary has to know which subset are actually required (assuming they can even find any of them), in addition to knowing your password. It can be seen from this formula (or by visualizing keyfile "fake/real" as a binary string), that for N keyfiles, the total number of combinations of keyfiles is 2N. Thus you can easily provide for a large number of possible combinations of both keyboard and mouse input (which is particularly comforting if keyloggers are a possibility). Couple this with hidden volume support and clever concealment of encrypted volume files amongst other large and unintelligible program data files, and you have yourself a pretty secure and undetectable encrypted setup. Just remember to frequently mentally rehearse all of your passwords (instead of writing them down), as mentioned above. Filesystem passwords are used much less often than login passwords. It is easy to forget them.
Newer versions can also encrypt the entire system partition including the Windows Swap file, standby/sleep file, hibernation files and all the other little things that can save sensitive information across session.
On Linux, however, an encrypted volume can of course contain a swapfile as discussed above, and on PDAs swapfiles don't exist
SeizeD
For the extra paranoid, you can write a quick perl script to monitor network connectivity, and immediately unmount and remove the crypto device as soon as pings fail (or execute any other arbitrary command). I've done this already for you. My first cut was a simple script that pinged a series of hosts and executed your crypt-stop script from above. This script gave The Man one second to move your machine to a network that would also respond to all those pings while he transported it.This is problematic in that The Man could simply throw in a hub with a bunch of machines that would also respond to those IPs and turn it on as soon as they disconnected your box from the network (assuming they figured out what to do about power). So after thinking about it for a bit, I decided I didn't even want to make it that easy for that bastard. So I wrote a pair of scripts you can run on various machines on your LAN (or across the Internet) to ensure network connectivity.
The way this works is there is a client script and a server script. The client script is the one you run on your secure machine, and the server script you run on any host on the Internet. The scripts are written in standard perl, and depends upon the Unix utility md5sum, which is available on Linux, Mac OS, and cygwin. You should be able to replace md5sum with any command line hashing program, such as FSUM if you do not want to install all of cygwin.
When you start the pair (start the server first), they ask you for a password to be used for that session. The client script then periodically (every 0.25 seconds by default) sends the MD5 (or SHA1) hash of a random number (from /dev/urandom) to the server script, and the server script appends this random number to your password. It then hashes this combined value, and sends the result back to the client. The client compares this value to one it generates locally via the same manner. If they match, the process is repeated with a new random hash, if they do not match, a script you specify (such as crypt-stop to unmount your drives) is run. The script is also run after a timeout period (1 second) or if the TCP connection otherwise dies.
This is a common cryptographically secure authentication technique that is used to prove two people know a password without revealing it to a third party (The Man).
Note that there is nothing stopping you from running multiple copies of this program on a given machine to connect to multiple servers with different passwords, in case there is concern a password could be recovered by attacking a particular server. It won't hurt your volume to attempt to unmount it twice.
Secure Deletion
Oftentimes you will have old or temporary copies of data left on your hard disk after you finish making your encrypted filesystem. Sometimes applications will save data to unencrypted locations by default before you realize what they are doing. In these cases you need to have a mechanism to wipe traces of this data clean. Simply deleting files is not enough, since deletion only removes files from the directory listing and does nothing to actually remove their contents until they are overwritten by some new file.Whenever the topic of secure deletion comes up, an argument will inevitably be raised as to how many times a file must be overwritten and what must it be overwritten with in order for it to be truly gone. The tinfoil hat crowd will tell you all sorts of horror stories about this or that government agency that has the power to read through N+X layers of random overwritten data, where N was the number you asserted was secure and X is some arbitrary additional amount they made up to make you feel bad.
My personal opinion is that somewhere between 2 and 5 really is all you need. As drives become larger, the cost factor involving finding data below an arbitrary number of writes over the span of the entire disk grows tremendously. And then who's to say that the data wasn't there from a previous owner, possibly even someone who returned a drive back to the manufacturer because of some defect that was corrected and the drive resold. The other factor is that if secure deletion takes forever, you will find yourself doing it less and less, and postponing it more and more because it will interfere with your real work. This is obviously much worse than minimally wiping something quickly right away and getting it over with.
Flash drives (and SSDs) are difficult to wipe due to the internal wear-leveling preventing the OS from writing to the same flash block repeatedly. The file may be made inaccessible through the drive interface, but if the flash chip is removed from the drive, it can be completely dumped out.
Linux
On Linux, the relevant utility is called wipe. There are two versions of this utility. The more popular one is hosted at sourceforge, and the other is available here.For most uses, I would just accept the defaults. To wipe a file, wipe filename should be fine. wipe -r directory will get an entire directory recursively. To wipe all free space on a drive, wipe -a some_file should do the trick.
Modern Linux filesystems cannot be wiped at the individual file level due to the internal journal saving changes to the files. These include reiserfs, ext (>=3) and btrfs filesystems.
Mac OS
On Mac OS, secure file deletion is built right in to the trash bin. You need to ensure that you do not interrupt this process, however, or you may lose access to any FileVault volumes you may have. Keep the power plugged in.It is also possible to erase free space on your Mac if you emptied the trash bin without using the secure file deletion option. For instructions on how to do this, go to Applications/Utilities and select Disk Utility, and select your Macintosh HD. From here, under the "Erase" header, select Erase Free Space. This overwrites all the empty free space on your hard drive. However, if there is material on your hard drive that is unreadable by OSX (i.e. Windows Partition, etc.), this will remain untouched.
Windows
On Windows, far and away the best option is Eraser, since it adds right-click context menus to wipe a file or directory, and allows you to schedule tasks to wipe all free space as well. Very nice piece of software.OpenBSD
Use '-P' parameter of rm command for secure wiping in OpenBSD.