---[ Anonymizing UNIX Systems ]---
version 0.9



Author: van Hauser / THC






--------------------




* I. THE AUDIENCE

This text is for any human being out there who wishes to keep their data and doings private from any snooping eye - monitoring network traffic and stealing/accessing the computer including electronic forensics. Hackers, phreakers, criminals, members of democracy parties in totalitarian states, human rights workers, and people with high profiles might be interested in this information. It was especially written for novice hackers so they are not so easily convicted when busted for their early curiosity.

Thanks to Solar Designer, Fyodor, typo, tick, pragmatic, mixter and doc holiday for comments, critics and ideas.
Special thanks to rookie who had the original idea writing this paper but through personal problems couldn't do it himself.



* II. GOAL

Our goal is to provide solutions to the following statements:

Maybe you see contradictions ;-)



* III. PREREQUISITES

It is important to state the prerequisites for this project:
Note that the solutions presented do not 100% fit internet servers.
However it's (nearly, bah ;-) perfect for enduser systems.

For the UNIX part, we show the solutions for Linux because it is the unix most easily for beginners to get their hands on and administrate.
The Linux distribution we use is the SuSE Linux Distribution 6.0
Debian is better but more complicated for beginners. And I dislike redhat for it's missing security.
You should know enough about unix (what is portmap, mount, rc2.d etc.) before trying to understand this text. It's *not* a Linux-Howto!



* IV. USER DATA
*** 1. Sensitive user data

What is sensitive user data? Well *any* data from a user account. This includes:
We are trying to protect all this data.
Note that utmp/wtmp/lastlog data and mail (mqueue/mail/fax/lpd) is handled in the SYSTEM DATA section.
Note that all user accounts can be seen from /etc/passwd ;-) So maybe you'd like to add some/many fake accounts, together with homedirs and crypted data ...


*** 2. Protecting /home directories

Most important for protecting user data is protecting the users' /home directories.
Each home directory must be encrypted with a strong cypher so that even with full physical access to the system the data can't be obtained. Currently I know of only one software provididing a solution to our requirements: CFS - the cryptographic filesystem.

There are also some other crypto solutions available : TCFS, SFS and the loop filesystem with crypt support. They are faster but have got the disadvantage that you'll have to recompile your kernel with patches from these tools. So for the sake of easeness, I stick with CFS here. (Pointers to all tools mentioned in this text can be found at the end)

To enable CFS we must put these six lines in a rc2.d script: 
        portmap

        rpc.mountd -P 894     # mountd should bind to port 894

        cfsd 895              # cfsd   should bind to port 895

        rm -rf /tmp/.tmp

        mkdir -p -m 700 /tmp/.tmp

        mount -o port=895,intr localhost:/tmp/.tmp /home
Additionaly we have to put this entry into /etc/exports: 
        /tmp/.tmp       localhost


Okay. This starts the sunrpc with the mountdaemon which are necessary for CFS to be started and used.
Now we need to get the following going: if a user logs on, the system has to check if he's already logged in to decide whether to decrypt the users' home directory. This sounds hard but is easy: the user's /home/user directory doesn't exist (even if it would, because of mount command nine lines above would make it nonexistent), so the user's HOME variable is set to '/' the root directory. Then his login shell is started which looks for it's start scripts. And that's were we put our hooks in.
We create (this example is for bash) the file /.profile with the following contents: 
        cattach /crypt/$USER $USER  ||  exit 0

        export HOME=/home/$USER

        cd $HOME

        if test -f $HOME/.profile; then

                . $HOME/.profile

        fi

When a user logs on the first time, this script will be executed. The user has to enter the password for his crypted homedir, and after this his correct HOME variable is set and the normal login profile is read and done. If a user doesn't know the passphrase for his crypted homedir, he is logged out.

But how do we remove the decrypted homedir after the user logs out? This script should be clever, because a user could be logged in several times at once, and it should only be removed when the last loginshell exits.
Thank god, this is easy too, we create a /home/user/.bash_logout script: 
        # if the number of user's login shells are > 3 then this is the last.

        shells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l`

        test $shells -lt 3 || exit 0

        export HOME=/

        cd /

        cdetach $USER

Thats all. From now on, the users' homedirectories are safe.

Note that a user can't login now, start a background job which writes data in his homedirectory and log out because his homedirectory would be removed. The full .bash_logout script I provide in (see two lines below) checks for a $HOME/.keep file and if present doesn't remove the homedir.

For network logins you should keep in mind that they should not be done via rlogin, telnet, etc. because they send all traffic (including passwords) in plaintext over the network. You should use a tool which encrypts the whole traffic like SSLtelnet or SSH (for SSH you need to set "UseLogin yes" in the /etc/sshd_config file).

You'll find all these scripts with error checking, user creating, stop scripts and config files etc. in section IX. EXAMPLE CONFIGURATION

Note that we started daemons in the section which can be contacted from remote. If you don't want this (because there are no external users who need to mount their crypted user data on their own machine) you should firewall these ports. Look in you manpages ("man ipchains" or "man ipfwadm").


*** 3. Traceable user activity

[Warning, this section shows first how to perform simple electronic forensics]
It is easy to see who logged on the system and what he did by the timestamps. Even if all your data is crypted, by checking the last access time (atime) of your files, someone may check when you logged in last time, for what duration and if you were idleing or doing much stuff.
If the systems doesn't have many users, someone might even tell what you did.

Example: The earliest access time for a crypted file in your homedir can be seen by: 

        ls -altur /crypt/$USER | head -1 # shows the logout file

        ls -altu  /crypt/$USER | more    # with some brain you'll find

                                         # the login time

then you also have the duration of the session.
By checking the change/modification and access time of those crypted files with their timestamps someone can see how hard you were working, and get more conclusions (e.g. if many files nested in a three levels deep directory where modified this is probably a browser - so you were surfing the net).

This insight will now make it possible to check what commands were run:
Let's say the login time as 22 hours ago, so you run: 

        find / -type f -atime 0 -ls # shows the accessed files

        find / -type f -mtime 0 -ls # shows the modified files

(this can be done with directories too)

Now check the output for the correct timeframe and analyze what you found. e.g. the telnet client was accessed. So it's probable, the user used it to connect to another system. I think you can imagine now what is possible.

To protect against this is also very easy:
Create the file /usr/local/bin/touch_them and make it executable with the following contents: 

        find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch

Then put the following line into /etc/crontab: 

        50 * * * *      root   /usr/local/bin/touch_them

finally you change the 4th row of all lines in /etc/fstab which have the keyword "ext2" in their third (the filesystem type) row: 
         defaults          (or anything else)
should become 
         defaults,noatime  (the old value is kept, and noatime is appended)

example: 
         /dev/hda1   /    ext2   defaults  1  1
becomes 
         /dev/hda1   /    ext2   defaults,noatime  1  1

What did we achieve? The crontab entry with the small script updates the atime, mtime and ctime to the current time every hour of special directories - especially those which may hold user data.
The mount options we changed now prevent the update of the atime. However, this needs a current 2.2.x kernel - it isn't implemented on the 2.0 kernel tree!


*** 4. Protecting /var/spool/* files

/var/spool/mail :
Now it gets tricky. How can we protect the new mail for a user from spying eyes? It can't be sent directly to a user's homedir like qmail would do because it's crypted. The easiest solution is to use pgp to encrypt your outgoing emails and tell all your friends that they should also encrypt all emails to you.

However, this is not satisfying. An attacker can still see who sent the user the email. The only possibility to hide this is using anonymous remailer. This is not a great solution, so this is an open point (see section X.2: Additional thoughts)

/var/spool/{mqueue|fax|lpd} :
Well, all you can do is try to flush the queues when shutting down.
After that you have to decide if you delete the remaining files in a secure way or leave it where it is. Or program a special script which does something with the data (like taring the data and encrypting it with pgp, doing the reverse when the system is rebooted)

You can also create a whole crypted /var partition, but that would require someone at the console while booting the system - every time.



* V. SYSTEM DATA
*** 1. Sensitive system data

What is sensitive system data? *Anything* which gives conclusion on incoming and outgoing data, configuration files, logs, reboots and shutdowns.

This includes:
How to prevent time stamp forensica, see section IV.3
How to protect /var/spool/* data, see section IV.4 for an incomplete solution.

*** 2. Traceable system activity

(prevent of time stamp forensic is handled in section IV.3) To trace system activity, you can easily check temporary files of daemons and applications. Some of them write to /tmp, root applications usually (should) write to /var/run. We handle this together with section V.3: Logging. All you have to do is this, and only *once* : 
        cd /var

        mv run log

        ln -s log/run run

this moves the /var/run directory to /var/log/run and sets a symlink in it's former place so that applications still find their files.

*** 3. Logging - important and dangerous

Logging is important to trace problems like misconfigurations.
Logging is dangerous because an attacker can see important data in the logfiles, like the user's login and logout time, if they executed "su" or other commands etc.
We try to find a balance between this.
Our solution: Write all log data to one special directory.
This directory is a RAM disk so the data is lost after a system shutdown. Ensure that syslogd [/etc/syslog.conf] and daemons (e.g. httpd [apache]) only write to our special logging directory or a system console. /var/log should be used as our special logging directory.


Now we put the following commands into /sbin/init.d/boot.local: 
        umask 027

        mke2fs -m0 /dev/ram0 1> /dev/null 2>&1

        rm -rf /var/log/* 2> /dev/null

        mount -t ext2 /dev/ram0 /var/log

        chmod 751 /var/log

        cd /var/log

        mkdir -m 775 run

        chgrp uucp run

        for i in `grep /var/log /etc/syslog.conf|grep -v '^#'| \

         awk '{print $2}'|sed 's/^-//'`

	    do > $i ; done

        umask 007		# 002 might be used too.

        for i in run/utmp wtmp lastlog

            do > $i ; chgrp tty $i ; done

        cd /

        kill -HUP `pidof syslogd` 2> /dev/null
After your next reboot it behaves like described above.

Some of you will not like the idea of having no logs after a reboot. This way you can't trace an intruder or guess from your logs what crashed the machine. Either you can tar the files and pgp before the shutdown is complete (but the data would be lost if a crash occurs), or you might also use ssyslog or syslog-ng, special syslogs with crypting capabilities, and write the data you really want to keep to (just an example) /var/slog.

You can also create a whole crypted /var partition, but that would require someone at the console while booting the system - every time.


*** 4. Protecting system configs

This is tricky. It is easy to achieve but for a price. If we create an account with uid which has his homedir in /home and is hence protected by our CFS configuration, you need to be at the console at every reboot. This isn't practical for server systems that need to be administrated and rebooted remotely. This solution is only good for end-user pcs.

Just create an account with the uid 0 (e.g. with the login name "admin"). You can use the create_user script from section IX.
Put all your sensitive configuration files you want to protect into this directory (ppp dialup scripts, sendmail.cf configs, squid configs with their cache directory set to a subdir of "admin" etc.)
Now create a small shellscript which starts these daemons with a command line option to use the config files in your "admin" homedir.

Your system is then secure from extracting the sensitive information from the config files. But for a price. You have to log in after each reboot as user "admin", enter your CFS passphrase and start the script.


*** 5. Computer Memory and sensitive /proc interfaces

For a real multiuser system on which the administrator want additionally ensure the privacy of the user online, he has to hide the user process information, a user would normally see when issuing a "who" or "ps" command. To protect the user's process information, you can use Solar Designer's secure-linux kernel patch. To protect the utmp/wtmp/lastlog we ensure that these files are only readable by root and group tty, hence a normal user can't access this data. (This is done in the boot.local example script)
Now one problem is left. Even with normal RAM a well funded organisation can get the contents after the system is powered off. With the modern SDRAM it's even worse, where the data stays on the RAM permanently until new data is written. For this, I introduced a small tool for the secure_delete package 2.1, called "smem" which tries to clean the memory. This one should be called on shutdown. It is done in the example in section VI.4



* VI. DELETE(D) DATA AND SWAP
*** 1. How to delete files in a secure way<

When a file is deleted, only the inode data is freed, the contents of the data is NOT wiped and can be gathered with tools like "dd" or the tool manpipulate_data from THC.

Peter Gutmann wrote a paper with the name "Secure Deletion of Data from Magnetic and Solid-State Memory" presented 1996 at the 6th Usenix Security Symposium. This is the best civilian paper on how to wipe data in a way that it is hard for even electronic microscopes to regain the data.
There are four tools out there which uses the techniques described there, two called "wipe", one called "srm" from THC's secure_delete package and "shred" which is part of the new fileutil package from GNU.
Ours is still the best from it's design, features and security, and it has also all important and advanced commandline options and speed you need.

To use one of these tools for deletion just set an alias in /etc/profile: 
        alias rm=srm      # or wipe or shred
or even better, move /bin/rm to /bin/rm.orig and copy the secure delete program to /bin/rm. This ensures, that all data which is deleted via rm is securely wiped.

If you can't install THC's secure_delete package or any other (for any reason) you can also set the wipe flag from the ext2 filesystem on files you wish to wipe before rm'ing them. It's nearly the same, but it's NOT a secure wipe like mentioned above. It's set by: 
        chattr +s filename(s)


[Note that it is *still* possible for a well funded organisation to get your data. Don't rely on this! See section VI.4 !]


*** 2. How to wipe free disk space

Most times applications like the editor in your mail program write a temporary file. And you don't know about it - you weren't even asked :( Because they don't wipe the data in a secure way, an attacker can get all your private emails just because you didn't know. That's bad.
The solution: You use a wiper program which cleans all unused data from the disk partitions.
The only one available is the one from THC's secure_delete package. You could put "sfill" (that is what it is called) in you crontab so it is run regulary but this might create problems when at this moment this space is needed by an important application. At least when the system shuts down, sfill should be called.
Put this in the "stop" part of a late rc2.d script: 
        sfill -llf /tmp 2> /dev/null

        sfill -llf /var/spool 2> /dev/null


Note that it is a good idea to generate a new paritition for /tmp itself, and putting a symlink from /usr/tmp and /var/tmp to /tmp. This way it is easier to control and wipe.

Again, if you can't install the secure_delete package for any reason, you can also use this solution (slower and not as secure): 
        dd if=/dev/zero of=/tmp/cleanup

        sync

        rm /tmp/cleanup



*** 3. How to handle swap data

Securely wiping files and free diskspace - well what's left? Today, harddisk MB's are cheaper than RAM, thats why swap space is used to expand the available RAM. This is in reality a file or partition on your harddisk. And can have your sensitive data in it.

Again there is only one tool which helps you out here, "sswap" from THC's secure_delete package ;-)
Put this line after the "swapoff" line in /sbin/init.d/halt: 
        sswap -l /dev/XXXX     # the device for your swap, check /etc/fstab



*** 4. How to handle RAM

In section V.5 I wrote about sensitive information in your RAM, the fast memory of your computer system. It can hold very sensitive information like the email you wrote before pgp'ing it, passwords, anything.
To ensure, that the memory is cleaned, use the smem utility.
It should be called like this in the stop part of a late rc2.d script (as already mentioned above), after the wiping the file of /tmp etc. and then wiping the free memory: 
        smem -ll



*** 5. Temporary data - it is evil

After you have secured/anonymized/privatized your system so far everything's ready - or did you forget something?
Remember what we told you in section VI.1, that temporary data is written somewhere and sometimes you don't know. If you are unlucky, all we've done here was useless. We have to ensure that there's no temporary data left on the devices and that it can't be recovered either.
We already dealed with /var/log, /var/run and sent email (/var/spool/...), and we wipe all free diskspace from our temporary disk locations. Now we must wipe also the temporary data.
Put this line in the stop part of a late rc2.d script (before sfill from VI.3): 
        ( cd /tmp ; ls -A | xargs -n 250 srm -r ; )
Also a $USER/tmp directory should be created for all users under the CFS /home protection and a TMPDIR variable set to this directory.

See section IX. for all these scripts ...



* VII. NETWORK CONNECTIONS

This is a very specialized area of this document. I write here a few ways how someone can protect some of their data being transfered on the internet.

The basic prerequisites are as following: You've got an external POP3 and SMTP (mail relayer) where you get and send your email. When your go on irc, you also don't like your real hostname being printed on the channels.

Your external mail server should be in another country, because if maybe some official agencies think you're doing something illegal (and I'm sure you won't) it's harder to get a search warrant. It's also harder because companies or individuals that try to get your data would need to invest more time, work and money to get it.

You can tunnel your SMTP and POP3 via ssh to the external mail server.
For POP3 this is easy, but for SMTP this is a bit harder.
Just as an example, irc traffic can be tunneled through this as well, but dcc stuff won't work (one way doesn't work, the other would reveal your ip address to the sender and the data is not encrypted on any part of the internet)
Note that you can also use redirectors and proxies to accomplish further redirecting for other protocols (www, irc, ftp proxies etc.)

Thats all. All mail traffic (and as you can see below, irc traffic too) is being crypted between you and your mail/proxy server.

sendmail.cf (important parts): 
        DSsmtp:[127.0.0.1]

        DjTHE_DOMAIN_NAME_OF_YOUR_EMAIL

        DMTHE_DOMAIN_NAME_OF_YOUR_EMAIL

- Msmtp,          P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,

+ Msmtp,          P=[IPC], F=mDFMuXk, S=11/31, R=21, E=\r\n, L=990,
(add the "k" switch to the smtp option config line)

~user/.fetchmailrc: 
        poll localhost protocol POP3:

            user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here

            mda "/usr/sbin/sendmail -oem USER_LOCAL"
(enter the corresponding USER_* and PASSWORD in here)

The ssh commandline which tunnels the traffic for POP3, SMTP and irc: 
        ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \

            25:localhost:25 your_mail_server.com


That's all. I won't tell you more. Use your brain ;-)



* VIII. HIDING PRIVACY SETTINGS *** 1. Mount is your friend

Take a look at the following commands: 
# ls -l /home

total 3

drwxr-x---   1 root     root         1024 Mar 28 14:53 admin

drwxr-x---   1 vh       thc          1024 Mar 28 16:22 vh

drwxr-x---   1 user     users        1024 Mar 28 11:22 user

# mount -t ext2 /dev/hda11 /home      # or a ramdisk, doesn't matter

# ls -l /home

total 0

# : whoops, where are the homedirs ?

# umount /home

# ls -al /home

total 3

drwxr-x---   1 root     root         1024 Mar 28 14:53 admin

drwxr-x---   1 vh       thc          1024 Mar 28 16:22 vh

drwxr-x---   1 user     users        1024 Mar 28 11:22 user

# : ah, yeah there they are again ...
This is a nice feature to hide your crypted data and binaries. Just put your files into e.g. /usr/local/bin and /usr/local/crypt and mount a decoy filesystem over /usr/local. If you then have got a process started in your boot scripts which opens a file on the decoy filesystem, the filesystem can't be unmounted until the process is killed. This way, it's much harder for someone to detect your data!


*** 2. Removable Medias

An even better possibility is: put all your sensitive data on a removable media. Put your media in, mount it, it run the startscript from it to activate all the privacy stuff. This way you made it one step harder for someone to get to know whats going on.

*** 3. ???

Any other ideas? Think about it! (and maybe send me your ideas ;-)



* IX. EXAMPLE CONFIGURATION AND SCRIPTS

Click here to download the anonymous-unix-0.9.tar.gz tools!



* X. FINAL COMMENTS
*** 1. Where to get the tools mentioned in this text

- Crypto Filesystems - Tools - The example Linux Distribution
*** 2. Additional thoughts

The following problems are still present:
Secure your system against unauthorized (from your point of view) access and use strong passwords.


*** 3. Greetings (what would the world be without greets?)

What would the world be without love and greetings? ;-)

Greets to individuals (in alphabetic order):
Greets to groups:
Greets to channel members:

*** 4. How to contact me for updates or comments

Please send me any further ideas you've got to make this documentation better! Did I wrote bad bad english in some part? Could I rephrase parts to make it easier to understand? What is wrong? What's missing? van Hauser / THC - [The Hacker's Choice]

THC's Webpage -> http://r3wt.base.org
(or http://thc.pimmel.com or http://www.infowar.co.uk/thc) 



Type Bits/KeyID    Date       User ID

pub  2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>



-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: 2.6.3i



mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU

SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L

XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC

meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc

QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq

s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU

SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD

/3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn

CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYnOkUXgUQdPo69B04dl

C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN

1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ

PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ

2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X

lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/

Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI

o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==

=MdzX

-----END PGP PUBLIC KEY BLOCK-----