--- /dev/null
+<HTML>\r
+<HEAD>\r
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">\r
+<TITLE>Anonymous Unix Systems</TITLE>\r
+</HEAD>\r
+\r
+<BODY BGCOLOR="#FFFFFF">\r
+<center>\r
+<h1>\r
+---[ Anonymizing UNIX Systems ]---\r
+<br>\r
+version 0.9\r
+</h1>\r
+<br><br>\r
+<table border=3 cellpadding=7 cellspacing=3>\r
+<tr><td>Author: <I><a href="mailto:vh@reptile.rug.ac.be">van Hauser</a> /\r
+THC</I><br>\r
+</td></tr>\r
+</table>\r
+</center>\r
+<br><br><br><br>\r
+<ul>\r
+I. <A HREF="#1">THE AUDIENCE</A><ul></ul><br>\r
+II. <A HREF="#2">GOAL</A><ul></ul><br>\r
+III. <A HREF="#3">PREREQUISITES</A><ul></ul><br>\r
+IV. <A HREF="#4">USER DATA</A><br>\r
+<ul> 1. <A HREF="#41">Sensitive user data</A><br>\r
+ 2. <A HREF="#42">Protecting /home directories</A><br>\r
+ 3. <A HREF="#43">Traceable user activity</A><br>\r
+ 4. <A HREF="#44">Protecting /var/spool/mail/user files</A></ul><br>\r
+V. <A HREF="#5">SYSTEM DATA</A><br>\r
+<ul> 1. <A HREF="#51">Sensitive system data</A><br>\r
+ 2. <A HREF="#52">Traceable system activity</A><br>\r
+ 3. <A HREF="#53">Logging - important and dangerous</A><br>\r
+ 4. <A HREF="#54">Protecting system configs</A><br>\r
+ 5. <A HREF="#55">Computer Memory and sensitive /proc interfaces</A></ul><br>\r
+VI. <A HREF="#6">DELETE(D) DATA AND SWAP</A><br>\r
+<ul> 1. <A HREF="#61">How to delete files in a secure way</A><br>\r
+ 2. <A HREF="#62">How to wipe free disk space</A><br>\r
+ 3. <A HREF="#63">How to handle swap data</A><br>\r
+ 4. <A HREF="#64">How to handle RAM</A><br>\r
+ 5. <A HREF="#65">Temporary data - it is evil</A></ul><br>\r
+VII. <A HREF="#7">NETWORK CONNECTIONS</A><ul></ul><br>\r
+VIII. <A HREF="#8">HIDING PRIVACY SETTINGS</A><br>\r
+<ul> 1. <A HREF="#81">Mount is your friend</A><br>\r
+ 2. <A HREF="#82">Removable Medias</A><br>\r
+ 3. <A HREF="#83">???</A></ul><br>\r
+IX. <A HREF="#9">EXAMPLE CONFIGURATION AND SCRIPTS</A><br>\r
+X. <A HREF="#10">FINAL COMMENTS</A><br>\r
+<ul> 1. <A HREF="#101">Where to get the tools mentioned in this text</A><br>\r
+ 2. <A HREF="#102">Additional thoughts</A><br>\r
+ 3. <A HREF="#103">Greetings (what would the world be without greets?)</A><br>\r
+ 4. <A HREF="#104">How to contact me for updates or comments</A></ul><br>\r
+</ul>\r
+<br><br>\r
+<center>\r
+--------------------\r
+</center><br><br><br><br>\r
+\r
+\r
+\r
+<A NAME="1"></A>\r
+<bold>* I. THE AUDIENCE</bold>\r
+<br>\r
+<br>\r
+\r
+This text is for any human being out there who wishes to keep their data and\r
+doings private from any snooping eye - monitoring network traffic and\r
+stealing/accessing the computer including electronic forensics.\r
+Hackers, phreakers, criminals, members of democracy parties in totalitarian\r
+states, human rights workers, and people with high profiles might be\r
+interested in this information.\r
+It was especially written for novice hackers so they are not so easily\r
+convicted when busted for their early curiosity.\r
+<br>\r
+<br>\r
+\r
+Thanks to Solar Designer, Fyodor, typo, tick, pragmatic, mixter and\r
+doc holiday for comments, critics and ideas.\r
+<br>\r
+Special thanks to rookie who had the original idea writing this paper\r
+but through personal problems couldn't do it himself.\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="2"></A>\r
+<bold>* II. GOAL</bold>\r
+<br>\r
+<br>\r
+\r
+Our goal is to provide solutions to the following statements:\r
+<br>\r
+<br>\r
+<ul>\r
+ (1) The solution should be simple and easy<br>\r
+ (2) All user data should be inaccessible by anyone except their owner<br>\r
+ (3) Nobody should be able to reconstruct what is happening on the system<br>\r
+</ul>\r
+\r
+Maybe you see contradictions ;-)\r
+\r
+\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+<A NAME="3"></A>\r
+<bold>* III. PREREQUISITES</bold>\r
+<br>\r
+<br>\r
+\r
+It is important to state the prerequisites for this project:\r
+<br>\r
+<ul>\r
+ - The system should be secure. No remote vulnerabilities (and hopefully\r
+ no local ones either)<br>\r
+ - The system administator(s) must be trusted and willing to set this up<br>\r
+ - The operating system to achieve this is a UNIX<br>\r
+</ul>\r
+\r
+Note that the solutions presented do not 100% fit internet servers.\r
+<br>\r
+However it's (nearly, bah ;-) perfect for enduser systems.\r
+<br>\r
+<br>\r
+\r
+For the UNIX part, we show the solutions for Linux because it is the unix\r
+most easily for beginners to get their hands on and administrate.\r
+<br>\r
+The Linux distribution we use is the SuSE Linux Distribution 6.0\r
+<br>\r
+Debian is better but more complicated for beginners. And I dislike\r
+redhat for it's missing security.\r
+<br>\r
+You should know enough about unix (what is portmap, mount, rc2.d etc.)\r
+before trying to understand this text. It's *not* a Linux-Howto!\r
+\r
+\r
+\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+<A NAME="4"></A>\r
+<bold>* IV. USER DATA</bold>\r
+<br>\r
+<A NAME="41"></A>\r
+<bold>*** 1. Sensitive user data</bold>\r
+<br>\r
+<br>\r
+\r
+What is sensitive user data? Well *any* data from a user account.\r
+This includes:\r
+<ul>\r
+ - utmp/wtmp/lastlog data (login times and duration plus login hosts)<br>\r
+ - history files (what commands you typed in your session)<br>\r
+ - your emails<br>\r
+ - temporary files from applications like mailers, browsers etc.<br>\r
+ - applications and their configuration<br>\r
+ - your own data (documents, porn pics, confidental data)<br>\r
+ - time stamps on your data (when were you accessing/editing which data)<br>\r
+ - on multiuser systems: what users CURRENTLY are doing.. this includes\r
+ process listing, and network connections as well as utmp (which is\r
+ already covered by another category). -> make proc more restrictive.<br>\r
+</ul>\r
+<br>\r
+\r
+\r
+We are trying to protect all this data.\r
+<br>\r
+Note that utmp/wtmp/lastlog data and mail (mqueue/mail/fax/lpd) is handled\r
+in the SYSTEM DATA section.\r
+<br>\r
+Note that all user accounts can be seen from /etc/passwd ;-) So maybe you'd\r
+like to add some/many fake accounts, together with homedirs and crypted\r
+data ...\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="42"></A>\r
+<bold>*** 2. Protecting /home directories</bold>\r
+<br>\r
+<br>\r
+\r
+Most important for protecting user data is protecting the users' /home\r
+directories.\r
+<br>\r
+Each home directory must be encrypted with a strong cypher so that even\r
+with full physical access to the system the data can't be obtained.\r
+Currently I know of only one software provididing a solution to our\r
+requirements: CFS - the cryptographic filesystem.\r
+<br>\r
+<br>\r
+\r
+There are also some other crypto solutions available : TCFS, SFS and the\r
+loop filesystem with crypt support. They are faster but have got the\r
+disadvantage that you'll have to recompile your kernel with patches from\r
+these tools. So for the sake of easeness, I stick with CFS here.\r
+(Pointers to all tools mentioned in this text can be found at the end)\r
+\r
+<br>\r
+<br>\r
+To enable CFS we must put these six lines in a rc2.d script:\r
+<pre> portmap\r
+ rpc.mountd -P 894 # mountd should bind to port 894\r
+ cfsd 895 # cfsd should bind to port 895\r
+ rm -rf /tmp/.tmp\r
+ mkdir -p -m 700 /tmp/.tmp\r
+ mount -o port=895,intr localhost:/tmp/.tmp /home\r
+</pre>\r
+\r
+Additionaly we have to put this entry into /etc/exports:\r
+<pre> /tmp/.tmp localhost\r
+</pre>\r
+\r
+<br>\r
+<br>\r
+Okay. This starts the sunrpc with the mountdaemon which are necessary\r
+for CFS to be started and used.\r
+<br>\r
+Now we need to get the following going: if a user logs on, the system\r
+has to check if he's already logged in to decide whether to decrypt the users'\r
+home directory. This sounds hard but is easy: the user's /home/user\r
+directory doesn't exist (even if it would, because of mount command nine\r
+lines above would make it nonexistent), so the user's HOME variable is\r
+set to '/' the root directory. Then his login shell is started which\r
+looks for it's start scripts. And that's were we put our hooks in.\r
+<br>\r
+We create (this example is for bash) the file /.profile with the following\r
+contents:\r
+<pre> cattach /crypt/$USER $USER || exit 0\r
+ export HOME=/home/$USER\r
+ cd $HOME\r
+ if test -f $HOME/.profile; then\r
+ . $HOME/.profile\r
+ fi\r
+</pre>\r
+\r
+<br>\r
+When a user logs on the first time, this script will be executed. The user\r
+has to enter the password for his crypted homedir, and after this his\r
+correct HOME variable is set and the normal login profile is read and done.\r
+If a user doesn't know the passphrase for his crypted homedir, he is logged\r
+out.\r
+<br>\r
+<br>\r
+But how do we remove the decrypted homedir after the user logs out? This\r
+script should be clever, because a user could be logged in several times at\r
+once, and it should only be removed when the last loginshell exits.\r
+<br>\r
+Thank god, this is easy too, we create a /home/user/.bash_logout script:\r
+<pre> # if the number of user's login shells are > 3 then this is the last.\r
+ shells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l`\r
+ test $shells -lt 3 || exit 0\r
+ export HOME=/\r
+ cd /\r
+ cdetach $USER\r
+</pre>\r
+\r
+<br>\r
+Thats all. From now on, the users' homedirectories are safe.\r
+\r
+<br>\r
+<br>\r
+Note that a user can't login now, start a background job which writes data\r
+in his homedirectory and log out because his homedirectory would be removed.\r
+The full .bash_logout script I provide in (see two lines below) checks for\r
+a $HOME/.keep file and if present doesn't remove the homedir.\r
+<br>\r
+\r
+<br>\r
+For network logins you should keep in mind that they should not be done via\r
+rlogin, telnet, etc. because they send all traffic (including passwords) in\r
+plaintext over the network. You should use a tool which encrypts the whole\r
+traffic like SSLtelnet or SSH (for SSH you need to set "UseLogin yes" in\r
+the /etc/sshd_config file).\r
+\r
+<br>\r
+<br>\r
+You'll find all these scripts with error checking, user creating, stop\r
+scripts and config files etc. in section IX. EXAMPLE CONFIGURATION\r
+<br>\r
+\r
+<br>\r
+Note that we started daemons in the section which can be contacted from\r
+remote. If you don't want this (because there are no external users who\r
+need to mount their crypted user data on their own machine) you should\r
+firewall these ports. Look in you manpages ("man ipchains" or "man ipfwadm").\r
+\r
+<br>\r
+<br>\r
+<br>\r
+<A NAME="43"></A>\r
+<bold>*** 3. Traceable user activity</bold>\r
+<br>\r
+<br>\r
+\r
+[Warning, this section shows first how to perform simple electronic forensics]\r
+<br>\r
+It is easy to see who logged on the system and what he did by the\r
+timestamps. Even if all your data is crypted, by checking the last access\r
+time (atime) of your files, someone may check when you logged in last time,\r
+for what duration and if you were idleing or doing much stuff.\r
+<br>\r
+If the systems doesn't have many users, someone might even tell what you\r
+did.\r
+<br>\r
+<br>\r
+Example: The earliest access time for a crypted file in your homedir\r
+can be seen by: \r
+<pre>\r
+ ls -altur /crypt/$USER | head -1 # shows the logout file\r
+ ls -altu /crypt/$USER | more # with some brain you'll find\r
+ # the login time\r
+</pre>\r
+\r
+<br>\r
+then you also have the duration of the session.\r
+<br>\r
+By checking the change/modification and access time of those crypted files\r
+with their timestamps someone can see how hard you were working, and get\r
+more conclusions (e.g. if many files nested in a three levels deep\r
+directory where modified this is probably a browser - so you were surfing\r
+the net).\r
+<br>\r
+<br>\r
+This insight will now make it possible to check what commands were run:\r
+<br>\r
+Let's say the login time as 22 hours ago, so you run:\r
+<pre>\r
+ find / -type f -atime 0 -ls # shows the accessed files\r
+ find / -type f -mtime 0 -ls # shows the modified files\r
+</pre>\r
+<br>\r
+(this can be done with directories too)\r
+<br>\r
+<br>\r
+Now check the output for the correct timeframe and analyze what you found.\r
+e.g. the telnet client was accessed. So it's probable, the user used it\r
+to connect to another system. I think you can imagine now what is possible.\r
+\r
+<br>\r
+<br>\r
+To protect against this is also very easy:\r
+<br>\r
+Create the file /usr/local/bin/touch_them and make it executable with\r
+the following contents:\r
+<pre>\r
+ find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch\r
+</pre>\r
+\r
+<br>\r
+Then put the following line into /etc/crontab:\r
+<pre>\r
+ 50 * * * * root /usr/local/bin/touch_them\r
+</pre>\r
+\r
+<br>\r
+finally you change the 4th row of all lines in /etc/fstab which have the\r
+keyword "ext2" in their third (the filesystem type) row:\r
+<pre> defaults (or anything else)\r
+</pre>\r
+should become\r
+<pre> defaults,noatime (the old value is kept, and noatime is appended)\r
+</pre>\r
+\r
+<br>\r
+example:\r
+<pre> /dev/hda1 / ext2 defaults 1 1\r
+</pre>\r
+becomes\r
+<pre> /dev/hda1 / ext2 defaults,noatime 1 1\r
+</pre>\r
+\r
+<br>\r
+What did we achieve? The crontab entry with the small script updates the\r
+atime, mtime and ctime to the current time every hour of special\r
+directories - especially those which may hold user data.\r
+<br>\r
+The mount options we changed now prevent the update of the atime.\r
+However, this needs a current 2.2.x kernel - it isn't implemented on the\r
+2.0 kernel tree!\r
+\r
+\r
+<br>\r
+<br>\r
+<br>\r
+<A NAME="44"></A>\r
+<bold>*** 4. Protecting /var/spool/* files</bold>\r
+\r
+<br>\r
+<br>\r
+/var/spool/mail :\r
+<br>\r
+Now it gets tricky. How can we protect the new mail for a user from\r
+spying eyes? It can't be sent directly to a user's homedir like qmail would\r
+do because it's crypted. The easiest solution is to use pgp to encrypt\r
+your outgoing emails and tell all your friends that they should also encrypt\r
+all emails to you.\r
+<br>\r
+<br>\r
+However, this is not satisfying. An attacker can still see who sent the user\r
+the email. The only possibility to hide this is using anonymous remailer.\r
+This is not a great solution, so this is an open point (see section <a\r
+href="#102">X.2</a>:\r
+Additional thoughts)\r
+<br>\r
+<br>\r
+\r
+/var/spool/{mqueue|fax|lpd} :\r
+<br>\r
+Well, all you can do is try to flush the queues when shutting down.\r
+<br>\r
+After that you have to decide if you delete the remaining files in a\r
+secure way or leave it where it is. Or program a special script which does\r
+something with the data (like taring the data and encrypting it with pgp,\r
+doing the reverse when the system is rebooted)\r
+<br>\r
+<br>\r
+\r
+You can also create a whole crypted /var partition, but that would require\r
+someone at the console while booting the system - every time.\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="5"></A>\r
+<bold>* V. SYSTEM DATA</bold>\r
+<br>\r
+<A NAME="51"></A>\r
+<bold>*** 1. Sensitive system data</bold>\r
+<br>\r
+<br>\r
+\r
+What is sensitive system data? *Anything* which gives conclusion on incoming\r
+and outgoing data, configuration files, logs, reboots and shutdowns.\r
+<br>\r
+<br>\r
+\r
+This includes:\r
+<ul>\r
+ - utmp/wtmp/lastlog data (boot, reboot, shutdown times + user times)<br>\r
+ - ppp dialup script<br>\r
+ - sendmail and tcp wrapper configurations<br>\r
+ - proxy cache data (e.g. squid web/ftp proxy)<br>\r
+ - syslog messages<br>\r
+ - /var/spool/* data {mqueue|fax|lpd|mail}<br>\r
+ - temporary files from daemons<br>\r
+ - time stamps on data (when were what data accessed/edited)<br>\r
+</ul>\r
+<br>\r
+\r
+How to prevent time stamp forensica, see section <a href="43">IV.3</a>\r
+<br>\r
+How to protect /var/spool/* data, see section <a href="44">IV.4</a> for an incomplete\r
+solution.\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="52"></A>\r
+<bold>*** 2. Traceable system activity</bold>\r
+<br>\r
+<br>\r
+\r
+(prevent of time stamp forensic is handled in section <a href="43">IV.3</a>)\r
+To trace system activity, you can easily check temporary files\r
+of daemons and applications. Some of them write to /tmp, root\r
+applications usually (should) write to /var/run. \r
+We handle this together with section <a href="53">V.3</a>: Logging.\r
+All you have to do is this, and only *once* :\r
+<pre> cd /var\r
+ mv run log\r
+ ln -s log/run run\r
+</pre>\r
+\r
+<br>\r
+this moves the /var/run directory to /var/log/run and sets a symlink in it's\r
+former place so that applications still find their files.\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="53"></A>\r
+<bold>*** 3. Logging - important and dangerous</bold>\r
+<br>\r
+<br>\r
+\r
+Logging is important to trace problems like misconfigurations.\r
+<br>\r
+Logging is dangerous because an attacker can see important data in\r
+the logfiles, like the user's login and logout time, if they executed\r
+"su" or other commands etc.\r
+<br>\r
+We try to find a balance between this.\r
+<br>\r
+Our solution: Write all log data to one special directory.\r
+<br>\r
+This directory is a RAM disk so the data is lost after a system shutdown.\r
+Ensure that syslogd [/etc/syslog.conf] and daemons (e.g. httpd [apache])\r
+only write to our special logging directory or a system console.\r
+/var/log should be used as our special logging directory.\r
+<br>\r
+<br>\r
+\r
+<br>\r
+Now we put the following commands into /sbin/init.d/boot.local:\r
+<pre> umask 027\r
+ mke2fs -m0 /dev/ram0 1> /dev/null 2>&1\r
+ rm -rf /var/log/* 2> /dev/null\r
+ mount -t ext2 /dev/ram0 /var/log\r
+ chmod 751 /var/log\r
+ cd /var/log\r
+ mkdir -m 775 run\r
+ chgrp uucp run\r
+ for i in `grep /var/log /etc/syslog.conf|grep -v '^#'| \\r
+ awk '{print $2}'|sed 's/^-//'`\r
+ do > $i ; done\r
+ umask 007 # 002 might be used too.\r
+ for i in run/utmp wtmp lastlog\r
+ do > $i ; chgrp tty $i ; done\r
+ cd /\r
+ kill -HUP `pidof syslogd` 2> /dev/null\r
+</pre>\r
+\r
+After your next reboot it behaves like described above.\r
+\r
+<br>\r
+<br>\r
+Some of you will not like the idea of having no logs after a reboot.\r
+This way you can't trace an intruder or guess from your logs what\r
+crashed the machine. Either you can tar the files and pgp before\r
+the shutdown is complete (but the data would be lost if a crash occurs),\r
+or you might also use ssyslog or syslog-ng, special syslogs with crypting\r
+capabilities, and write the data you really want to keep to (just an example)\r
+/var/slog.\r
+\r
+<br>\r
+<br>\r
+You can also create a whole crypted /var partition, but that would require\r
+someone at the console while booting the system - every time.\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="54"></A>\r
+<bold>*** 4. Protecting system configs</bold>\r
+<br>\r
+<br>\r
+This is tricky. It is easy to achieve but for a price.\r
+If we create an account with uid which has his homedir in /home\r
+and is hence protected by our CFS configuration, you need to\r
+be at the console at every reboot. This isn't practical for server systems\r
+that need to be administrated and rebooted remotely.\r
+This solution is only good for end-user pcs.\r
+<br>\r
+<br>\r
+\r
+Just create an account with the uid 0 (e.g. with the login name "admin").\r
+You can use the create_user script from section IX.\r
+<br>\r
+Put all your sensitive configuration files you want to protect into this\r
+directory (ppp dialup scripts, sendmail.cf configs, squid configs\r
+with their cache directory set to a subdir of "admin" etc.)\r
+<br>\r
+Now create a small shellscript which starts these daemons with a command\r
+line option to use the config files in your "admin" homedir.\r
+<br>\r
+<br>\r
+\r
+Your system is then secure from extracting the sensitive information\r
+from the config files. But for a price. You have to log in after each\r
+reboot as user "admin", enter your CFS passphrase and start the script.\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="55"></A>\r
+<bold>*** 5. Computer Memory and sensitive /proc interfaces</bold>\r
+<br>\r
+<br>\r
+\r
+For a real multiuser system on which the administrator want additionally\r
+ensure the privacy of the user online, he has to hide the user process\r
+information, a user would normally see when issuing a "who" or "ps"\r
+command. To protect the user's process information, you can use\r
+Solar Designer's secure-linux kernel patch. To protect the utmp/wtmp/lastlog\r
+we ensure that these files are only readable by root and group tty,\r
+hence a normal user can't access this data. (This is done in the boot.local\r
+example script)\r
+<br>\r
+Now one problem is left. Even with normal RAM a well funded organisation\r
+can get the contents after the system is powered off. With the modern\r
+SDRAM it's even worse, where the data stays on the RAM permanently until\r
+new data is written. For this, I introduced a small tool for the\r
+secure_delete package 2.1, called "smem" which tries to clean the memory.\r
+This one should be called on shutdown. It is done in the example\r
+in section <a href="64">VI.4</a>\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="6"></A>\r
+<bold>* VI. DELETE(D) DATA AND SWAP</bold>\r
+<br>\r
+<A NAME="61"></A>\r
+<bold>*** 1. How to delete files in a secure way<</bold>\r
+<br>\r
+<br>\r
+\r
+When a file is deleted, only the inode data is freed, the contents of\r
+the data is NOT wiped and can be gathered with tools like "dd" or the\r
+tool manpipulate_data from THC.\r
+<br>\r
+<br>\r
+\r
+Peter Gutmann wrote a paper with the name "Secure Deletion of Data from\r
+Magnetic and Solid-State Memory" presented 1996 at the 6th Usenix Security\r
+Symposium. This is the best civilian paper on how to wipe data in a way that\r
+it is hard for even electronic microscopes to regain the data.\r
+<br>\r
+There are four tools out there which uses the techniques described there,\r
+two called "wipe", one called "srm" from THC's secure_delete package and\r
+"shred" which is part of the new fileutil package from GNU.\r
+<br>\r
+Ours is still the best from it's design, features and security, and it\r
+has also all important and advanced commandline options and speed you need.\r
+<br>\r
+<br>\r
+\r
+To use one of these tools for deletion just set an alias in /etc/profile:\r
+<pre> alias rm=srm # or wipe or shred\r
+</pre>\r
+\r
+or even better, move /bin/rm to /bin/rm.orig and copy the secure delete\r
+program to /bin/rm. This ensures, that all data which is deleted via\r
+rm is securely wiped.\r
+<br>\r
+<br>\r
+\r
+If you can't install THC's secure_delete package or any other (for any\r
+reason) you can also set the wipe flag from the ext2 filesystem on files\r
+you wish to wipe before rm'ing them. It's nearly the same, but it's NOT\r
+a secure wipe like mentioned above. It's set by:\r
+<pre> chattr +s filename(s)\r
+</pre>\r
+\r
+<br>\r
+<br>\r
+[Note that it is *still* possible for a well funded organisation to get your\r
+data. Don't rely on this! See section <a href="64">VI.4</a> !]\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="62"></A>\r
+<bold>*** 2. How to wipe free disk space</bold>\r
+<br>\r
+<br>\r
+\r
+Most times applications like the editor in your mail program write a\r
+temporary file. And you don't know about it - you weren't even asked :(\r
+Because they don't wipe the data in a secure way, an attacker can\r
+get all your private emails just because you didn't know. That's bad.\r
+<br>\r
+The solution: You use a wiper program which cleans all unused data\r
+from the disk partitions.\r
+<br>\r
+The only one available is the one from THC's secure_delete package.\r
+You could put "sfill" (that is what it is called) in you crontab so it is\r
+run regulary but this might create problems when at this moment this space\r
+is needed by an important application. At least when the system shuts down,\r
+sfill should be called.\r
+<br>\r
+Put this in the "stop" part of a late rc2.d script:\r
+<pre> sfill -llf /tmp 2> /dev/null\r
+ sfill -llf /var/spool 2> /dev/null\r
+</pre>\r
+\r
+<br>\r
+<br>\r
+Note that it is a good idea to generate a new paritition for /tmp itself,\r
+and putting a symlink from /usr/tmp and /var/tmp to /tmp. This way it is\r
+easier to control and wipe.\r
+\r
+<br>\r
+<br>\r
+Again, if you can't install the secure_delete package for any reason,\r
+you can also use this solution (slower and not as secure):\r
+<pre> dd if=/dev/zero of=/tmp/cleanup\r
+ sync\r
+ rm /tmp/cleanup\r
+</pre>\r
+\r
+\r
+<br>\r
+<br>\r
+<br>\r
+<A NAME="63"></A>\r
+<bold>*** 3. How to handle swap data</bold>\r
+<br>\r
+<br>\r
+\r
+Securely wiping files and free diskspace - well what's left?\r
+Today, harddisk MB's are cheaper than RAM, thats why swap space is used to\r
+expand the available RAM. This is in reality a file or partition on your\r
+harddisk. And can have your sensitive data in it.\r
+<br>\r
+<br>\r
+\r
+Again there is only one tool which helps you out here, "sswap" from THC's\r
+secure_delete package ;-)\r
+<br>\r
+Put this line after the "swapoff" line in /sbin/init.d/halt:\r
+<pre> sswap -l /dev/XXXX # the device for your swap, check /etc/fstab\r
+</pre>\r
+\r
+<br>\r
+<br>\r
+<br>\r
+\r
+<A NAME="64"></A>\r
+<bold>*** 4. How to handle RAM</bold>\r
+<br>\r
+<br>\r
+\r
+In section <a href="55">V.5</a> I wrote about sensitive information in your RAM, the fast\r
+memory of your computer system. It can hold very sensitive information\r
+like the email you wrote before pgp'ing it, passwords, anything.\r
+<br>\r
+To ensure, that the memory is cleaned, use the smem utility.\r
+<br>\r
+It should be called like this in the stop part of a late rc2.d script (as\r
+already mentioned above), after the wiping the file of /tmp etc. and\r
+then wiping the free memory:\r
+<pre> smem -ll\r
+</pre>\r
+\r
+\r
+<br>\r
+<br>\r
+<br>\r
+\r
+<A NAME="65"></A>\r
+<bold>*** 5. Temporary data - it is evil</bold>\r
+<br>\r
+<br>\r
+\r
+After you have secured/anonymized/privatized your system so far everything's\r
+ready - or did you forget something?\r
+<br>\r
+Remember what we told you in section <a href="61">VI.1</a>, that temporary data is written\r
+somewhere and sometimes you don't know. If you are unlucky, all we've done\r
+here was useless. We have to ensure that there's no temporary data\r
+left on the devices and that it can't be recovered either.\r
+<br>\r
+We already dealed with /var/log, /var/run and sent email (/var/spool/...),\r
+and we wipe all free diskspace from our temporary disk locations.\r
+Now we must wipe also the temporary data.\r
+<br>\r
+Put this line in the stop part of a late rc2.d script (before sfill\r
+from <a href="63">VI.3</a>):\r
+<pre> ( cd /tmp ; ls -A | xargs -n 250 srm -r ; )\r
+</pre>\r
+\r
+Also a $USER/tmp directory should be created for all users under the CFS\r
+/home protection and a TMPDIR variable set to this directory.\r
+\r
+<br>\r
+<br>\r
+See section IX. for all these scripts ...\r
+\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="7"></A>\r
+<bold>* VII. NETWORK CONNECTIONS</bold>\r
+<br>\r
+<br>\r
+\r
+This is a very specialized area of this document. I write here a few ways\r
+how someone can protect some of their data being transfered on the internet.\r
+<br>\r
+<br>\r
+\r
+The basic prerequisites are as following:\r
+You've got an external POP3 and SMTP (mail relayer) where you get and send\r
+your email. When your go on irc, you also don't like your real hostname\r
+being printed on the channels.\r
+<br>\r
+<br>\r
+\r
+Your external mail server should be in another country, because if maybe\r
+some official agencies think you're doing something illegal (and I'm sure\r
+you won't) it's harder to get a search warrant. It's also harder because\r
+companies or individuals that try to get your data would need to invest more\r
+time, work and money to get it.\r
+<br>\r
+<br>\r
+\r
+You can tunnel your SMTP and POP3 via ssh to the external mail server.\r
+<br>\r
+For POP3 this is easy, but for SMTP this is a bit harder.\r
+<br>\r
+Just as an example, irc traffic can be tunneled through this as well,\r
+but dcc stuff won't work (one way doesn't work, the other would reveal\r
+your ip address to the sender and the data is not encrypted on any part\r
+of the internet)\r
+<br>\r
+Note that you can also use redirectors and proxies to accomplish further\r
+redirecting for other protocols (www, irc, ftp proxies etc.)\r
+<br>\r
+<br>\r
+\r
+Thats all. All mail traffic (and as you can see below, irc traffic too) is\r
+being crypted between you and your mail/proxy server.\r
+<br>\r
+<br>\r
+\r
+sendmail.cf (important parts):\r
+<pre> DSsmtp:[127.0.0.1]\r
+ DjTHE_DOMAIN_NAME_OF_YOUR_EMAIL\r
+ DMTHE_DOMAIN_NAME_OF_YOUR_EMAIL\r
+- Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,\r
++ Msmtp, P=[IPC], F=mDFMuXk, S=11/31, R=21, E=\r\n, L=990,\r
+</pre>\r
+(add the "k" switch to the smtp option config line)\r
+<br>\r
+<br>\r
+\r
+\r
+~user/.fetchmailrc:\r
+<pre> poll localhost protocol POP3:\r
+ user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here\r
+ mda "/usr/sbin/sendmail -oem USER_LOCAL"\r
+</pre>\r
+(enter the corresponding USER_* and PASSWORD in here)\r
+<br>\r
+<br>\r
+\r
+The ssh commandline which tunnels the traffic for POP3, SMTP and irc:\r
+<pre> ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \\r
+ 25:localhost:25 your_mail_server.com\r
+</pre>\r
+<br>\r
+<br>\r
+\r
+That's all. I won't tell you more. Use your brain ;-)\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="8"></A>\r
+<bold>* VIII. HIDING PRIVACY SETTINGS</bold>\r
+<A NAME="81"></A>\r
+<bold>*** 1. Mount is your friend</bold>\r
+<br>\r
+<br>\r
+\r
+Take a look at the following commands:\r
+<pre># ls -l /home\r
+total 3\r
+drwxr-x--- 1 root root 1024 Mar 28 14:53 admin\r
+drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh\r
+drwxr-x--- 1 user users 1024 Mar 28 11:22 user\r
+# mount -t ext2 /dev/hda11 /home # or a ramdisk, doesn't matter\r
+# ls -l /home\r
+total 0\r
+# : whoops, where are the homedirs ?\r
+# umount /home\r
+# ls -al /home\r
+total 3\r
+drwxr-x--- 1 root root 1024 Mar 28 14:53 admin\r
+drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh\r
+drwxr-x--- 1 user users 1024 Mar 28 11:22 user\r
+# : ah, yeah there they are again ...\r
+</pre>\r
+\r
+This is a nice feature to hide your crypted data and binaries.\r
+Just put your files into e.g. /usr/local/bin and /usr/local/crypt\r
+and mount a decoy filesystem over /usr/local. If you then have got\r
+a process started in your boot scripts which opens a file on the decoy\r
+filesystem, the filesystem can't be unmounted until the process is killed.\r
+This way, it's much harder for someone to detect your data!\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="82"></A>\r
+<bold>*** 2. Removable Medias</bold>\r
+<br>\r
+<br>\r
+\r
+An even better possibility is: put all your sensitive data on a removable\r
+media. Put your media in, mount it, it run the startscript from it\r
+to activate all the privacy stuff. This way you made it one step harder\r
+for someone to get to know whats going on.\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="83"></A>\r
+<bold>*** 3. ???</bold>\r
+<br>\r
+<br>\r
+\r
+Any other ideas? Think about it! (and maybe send me your ideas ;-)\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="9"></A>\r
+<bold>* IX. EXAMPLE CONFIGURATION AND SCRIPTS</bold>\r
+<br>\r
+<br>\r
+<a href="anonymous-unix-0.9.tar.gz">Click here</a> to download the\r
+<bold>anonymous-unix-0.9.tar.gz</bold> tools!\r
+<br>\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+\r
+<A NAME="10"></A>\r
+<bold>* X. FINAL COMMENTS</bold>\r
+<br>\r
+<A NAME="101"></A>\r
+<bold>*** 1. Where to get the tools mentioned in this text</bold>\r
+<br>\r
+<br>\r
+\r
+- Crypto Filesystems\r
+<ul>\r
+ CFS (Cryptographic File System) <a href="http://www.replay.com">http://www.replay.com</a><br>\r
+ TCFS (Transparent CFS) <a href="ftp://mikonos.dia.unisa.it/pub/tcfs">ftp://mikonos.dia.unisa.it/pub/tcfs/</a><br>\r
+ SFS (Stegano File System) <a href="http://www.linux-security.org/sfs">http://www.linux-security.org/sfs</a><br>\r
+ Crypto Loopback Filesystem <a href="ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/">ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/</a><br>\r
+</ul>\r
+\r
+- Tools\r
+<ul>\r
+ THC's secure_delete package <a href="http://www.thc.org">http://www.thc.org</a><br>\r
+ secure-linux kernel patch <a href="http://www.false.com/security">http://www.false.com/security</a><br>\r
+ syslog-ng <a href="http://www.balabit.hu/products/syslog-ng.htm">http://www.balabit.hu/products/syslog-ng.htm</a><br>\r
+ ssylog <a href="http://www.core-sdi.com/ssyslog">http://www.core-sdi.com/ssyslog</a><br>\r
+</ul>\r
+\r
+- The example Linux Distribution\r
+<ul>\r
+ SuSE Linux Distribution <a href="http://www.suse.com">http://www.suse.com</a><br>\r
+</ul>\r
+<br>\r
+\r
+<A NAME="102"></A>\r
+<bold>*** 2. Additional thoughts</bold>\r
+<br>\r
+<br>\r
+\r
+The following problems are still present:\r
+<ul>\r
+ - If an attacker can gain access to the system without rebooting\r
+ and in time before data is wiped, unmounted, etc. these countermeasures\r
+ are worthless.</ul>\r
+<ul>\r
+ - If a really well funded organisation is trying to decrypt your\r
+ data via brute force/dictionary or good electronic microscopes\r
+ and technical staff with excellent knowhow, your wiping won't\r
+ help you very much.</ul>\r
+<ul>\r
+ - The solution for /var/spool/mail and /var/spool/mqueue etc. is far\r
+ away from being perfect. Remember this. Ideas welcome.</ul>\r
+<ul>\r
+ - The configuration of your system daemons can only be secured if\r
+ you are present at the console after a reboot. That's the price.</ul>\r
+<ul>\r
+ - It is not very hard to detect the privacy stuff done. This might\r
+ bring you in trouble in countries like China or Iran. Removable\r
+ medias might help, or try a crypto filesystem with stegano support.</ul>\r
+<br>\r
+\r
+Secure your system against unauthorized (from your point of view) access\r
+and use strong passwords.\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+<A NAME="103"></A>\r
+<bold>*** 3. Greetings (what would the world be without greets?)</bold>\r
+<br>\r
+<br>\r
+\r
+What would the world be without love and greetings? ;-)\r
+<br>\r
+<br>\r
+\r
+Greets to individuals (in alphabetic order):\r
+<ul>\r
+ Doc Holiday, Froody, Fyodor, plasmoid, pragmatic, rookie,\r
+ Solar Designer, Tick, Wilkins.</ul>\r
+<br>\r
+\r
+Greets to groups:\r
+<ul> ADM, THC (of course ;-) and arF</ul>\r
+<br>\r
+\r
+Greets to channel members:\r
+<ul> #bluebox, #hack, #hax, #!adm and #ccc</ul>\r
+\r
+<br>\r
+<br>\r
+\r
+<A NAME="104"></A>\r
+<bold>*** 4. How to contact me for updates or comments</bold>\r
+<br>\r
+<br>\r
+\r
+Please send me any further ideas you've got to make this documentation\r
+better! Did I wrote bad bad english in some part? Could I rephrase parts\r
+to make it easier to understand? What is wrong? What's missing? <a\r
+href="mailto:vh@reptile.rug.ac.be>Email me!</a>\r
+<br>\r
+Tell me (best with a corrected diff) and I'll update this text.\r
+<br>\r
+<br>\r
+\r
+<br>\r
+Please use my public pgp key below.\r
+<br>\r
+<br>\r
+<br>\r
+\r
+\r
+Ciao...\r
+<br><ul>\r
+<a href="mailto:vh@reptile.rug.ac.be">van Hauser / THC - [The Hacker's Choice]</a>\r
+</ul><br>\r
+<br>\r
+\r
+\r
+THC's Webpage -> <a href="http://www.thc.org">http://www.thc.org</a>\r
+<br>\r
+(or <a href="http://thc.pimmel.com">http://thc.pimmel.com</a> or <a href="http://www.thc.org">http://www.thc.org</a>)\r
+<br>\r
+\r
+<PRE>\r
+\r
+Type Bits/KeyID Date User ID\r
+pub 2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>\r
+\r
+-----BEGIN PGP PUBLIC KEY BLOCK-----\r
+Version: 2.6.3i\r
+\r
+mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU\r
+SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L\r
+XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC\r
+meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc\r
+QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq\r
+s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU\r
+SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD\r
+/3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn\r
+CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYnOkUXgUQdPo69B04dl\r
+C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN\r
+1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ\r
+PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ\r
+2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X\r
+lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/\r
+Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI\r
+o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==\r
+=MdzX\r
+-----END PGP PUBLIC KEY BLOCK-----\r
+</PRE>\r
+</BODY>\r
+</HTML>\r
projects / oweals / thc-archive.git / blobdiff