3 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
\r
4 <TITLE>Anonymous Unix Systems</TITLE>
\r
7 <BODY BGCOLOR="#FFFFFF">
\r
10 ---[ Anonymizing UNIX Systems ]---
\r
15 <table border=3 cellpadding=7 cellspacing=3>
\r
16 <tr><td>Author: <I><a href="mailto:vh@reptile.rug.ac.be">van Hauser</a> /
\r
23 I. <A HREF="#1">THE AUDIENCE</A><ul></ul><br>
\r
24 II. <A HREF="#2">GOAL</A><ul></ul><br>
\r
25 III. <A HREF="#3">PREREQUISITES</A><ul></ul><br>
\r
26 IV. <A HREF="#4">USER DATA</A><br>
\r
27 <ul> 1. <A HREF="#41">Sensitive user data</A><br>
\r
28 2. <A HREF="#42">Protecting /home directories</A><br>
\r
29 3. <A HREF="#43">Traceable user activity</A><br>
\r
30 4. <A HREF="#44">Protecting /var/spool/mail/user files</A></ul><br>
\r
31 V. <A HREF="#5">SYSTEM DATA</A><br>
\r
32 <ul> 1. <A HREF="#51">Sensitive system data</A><br>
\r
33 2. <A HREF="#52">Traceable system activity</A><br>
\r
34 3. <A HREF="#53">Logging - important and dangerous</A><br>
\r
35 4. <A HREF="#54">Protecting system configs</A><br>
\r
36 5. <A HREF="#55">Computer Memory and sensitive /proc interfaces</A></ul><br>
\r
37 VI. <A HREF="#6">DELETE(D) DATA AND SWAP</A><br>
\r
38 <ul> 1. <A HREF="#61">How to delete files in a secure way</A><br>
\r
39 2. <A HREF="#62">How to wipe free disk space</A><br>
\r
40 3. <A HREF="#63">How to handle swap data</A><br>
\r
41 4. <A HREF="#64">How to handle RAM</A><br>
\r
42 5. <A HREF="#65">Temporary data - it is evil</A></ul><br>
\r
43 VII. <A HREF="#7">NETWORK CONNECTIONS</A><ul></ul><br>
\r
44 VIII. <A HREF="#8">HIDING PRIVACY SETTINGS</A><br>
\r
45 <ul> 1. <A HREF="#81">Mount is your friend</A><br>
\r
46 2. <A HREF="#82">Removable Medias</A><br>
\r
47 3. <A HREF="#83">???</A></ul><br>
\r
48 IX. <A HREF="#9">EXAMPLE CONFIGURATION AND SCRIPTS</A><br>
\r
49 X. <A HREF="#10">FINAL COMMENTS</A><br>
\r
50 <ul> 1. <A HREF="#101">Where to get the tools mentioned in this text</A><br>
\r
51 2. <A HREF="#102">Additional thoughts</A><br>
\r
52 3. <A HREF="#103">Greetings (what would the world be without greets?)</A><br>
\r
53 4. <A HREF="#104">How to contact me for updates or comments</A></ul><br>
\r
57 --------------------
\r
58 </center><br><br><br><br>
\r
63 <bold>* I. THE AUDIENCE</bold>
\r
67 This text is for any human being out there who wishes to keep their data and
\r
68 doings private from any snooping eye - monitoring network traffic and
\r
69 stealing/accessing the computer including electronic forensics.
\r
70 Hackers, phreakers, criminals, members of democracy parties in totalitarian
\r
71 states, human rights workers, and people with high profiles might be
\r
72 interested in this information.
\r
73 It was especially written for novice hackers so they are not so easily
\r
74 convicted when busted for their early curiosity.
\r
78 Thanks to Solar Designer, Fyodor, typo, tick, pragmatic, mixter and
\r
79 doc holiday for comments, critics and ideas.
\r
81 Special thanks to rookie who had the original idea writing this paper
\r
82 but through personal problems couldn't do it himself.
\r
91 <bold>* II. GOAL</bold>
\r
95 Our goal is to provide solutions to the following statements:
\r
99 (1) The solution should be simple and easy<br>
\r
100 (2) All user data should be inaccessible by anyone except their owner<br>
\r
101 (3) Nobody should be able to reconstruct what is happening on the system<br>
\r
104 Maybe you see contradictions ;-)
\r
112 <bold>* III. PREREQUISITES</bold>
\r
116 It is important to state the prerequisites for this project:
\r
119 - The system should be secure. No remote vulnerabilities (and hopefully
\r
120 no local ones either)<br>
\r
121 - The system administator(s) must be trusted and willing to set this up<br>
\r
122 - The operating system to achieve this is a UNIX<br>
\r
125 Note that the solutions presented do not 100% fit internet servers.
\r
127 However it's (nearly, bah ;-) perfect for enduser systems.
\r
131 For the UNIX part, we show the solutions for Linux because it is the unix
\r
132 most easily for beginners to get their hands on and administrate.
\r
134 The Linux distribution we use is the SuSE Linux Distribution 6.0
\r
136 Debian is better but more complicated for beginners. And I dislike
\r
137 redhat for it's missing security.
\r
139 You should know enough about unix (what is portmap, mount, rc2.d etc.)
\r
140 before trying to understand this text. It's *not* a Linux-Howto!
\r
149 <bold>* IV. USER DATA</bold>
\r
152 <bold>*** 1. Sensitive user data</bold>
\r
156 What is sensitive user data? Well *any* data from a user account.
\r
159 - utmp/wtmp/lastlog data (login times and duration plus login hosts)<br>
\r
160 - history files (what commands you typed in your session)<br>
\r
162 - temporary files from applications like mailers, browsers etc.<br>
\r
163 - applications and their configuration<br>
\r
164 - your own data (documents, porn pics, confidental data)<br>
\r
165 - time stamps on your data (when were you accessing/editing which data)<br>
\r
166 - on multiuser systems: what users CURRENTLY are doing.. this includes
\r
167 process listing, and network connections as well as utmp (which is
\r
168 already covered by another category). -> make proc more restrictive.<br>
\r
173 We are trying to protect all this data.
\r
175 Note that utmp/wtmp/lastlog data and mail (mqueue/mail/fax/lpd) is handled
\r
176 in the SYSTEM DATA section.
\r
178 Note that all user accounts can be seen from /etc/passwd ;-) So maybe you'd
\r
179 like to add some/many fake accounts, together with homedirs and crypted
\r
187 <bold>*** 2. Protecting /home directories</bold>
\r
191 Most important for protecting user data is protecting the users' /home
\r
194 Each home directory must be encrypted with a strong cypher so that even
\r
195 with full physical access to the system the data can't be obtained.
\r
196 Currently I know of only one software provididing a solution to our
\r
197 requirements: CFS - the cryptographic filesystem.
\r
201 There are also some other crypto solutions available : TCFS, SFS and the
\r
202 loop filesystem with crypt support. They are faster but have got the
\r
203 disadvantage that you'll have to recompile your kernel with patches from
\r
204 these tools. So for the sake of easeness, I stick with CFS here.
\r
205 (Pointers to all tools mentioned in this text can be found at the end)
\r
209 To enable CFS we must put these six lines in a rc2.d script:
\r
211 rpc.mountd -P 894 # mountd should bind to port 894
\r
212 cfsd 895 # cfsd should bind to port 895
\r
214 mkdir -p -m 700 /tmp/.tmp
\r
215 mount -o port=895,intr localhost:/tmp/.tmp /home
\r
218 Additionaly we have to put this entry into /etc/exports:
\r
219 <pre> /tmp/.tmp localhost
\r
224 Okay. This starts the sunrpc with the mountdaemon which are necessary
\r
225 for CFS to be started and used.
\r
227 Now we need to get the following going: if a user logs on, the system
\r
228 has to check if he's already logged in to decide whether to decrypt the users'
\r
229 home directory. This sounds hard but is easy: the user's /home/user
\r
230 directory doesn't exist (even if it would, because of mount command nine
\r
231 lines above would make it nonexistent), so the user's HOME variable is
\r
232 set to '/' the root directory. Then his login shell is started which
\r
233 looks for it's start scripts. And that's were we put our hooks in.
\r
235 We create (this example is for bash) the file /.profile with the following
\r
237 <pre> cattach /crypt/$USER $USER || exit 0
\r
238 export HOME=/home/$USER
\r
240 if test -f $HOME/.profile; then
\r
246 When a user logs on the first time, this script will be executed. The user
\r
247 has to enter the password for his crypted homedir, and after this his
\r
248 correct HOME variable is set and the normal login profile is read and done.
\r
249 If a user doesn't know the passphrase for his crypted homedir, he is logged
\r
253 But how do we remove the decrypted homedir after the user logs out? This
\r
254 script should be clever, because a user could be logged in several times at
\r
255 once, and it should only be removed when the last loginshell exits.
\r
257 Thank god, this is easy too, we create a /home/user/.bash_logout script:
\r
258 <pre> # if the number of user's login shells are > 3 then this is the last.
\r
259 shells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l`
\r
260 test $shells -lt 3 || exit 0
\r
267 Thats all. From now on, the users' homedirectories are safe.
\r
271 Note that a user can't login now, start a background job which writes data
\r
272 in his homedirectory and log out because his homedirectory would be removed.
\r
273 The full .bash_logout script I provide in (see two lines below) checks for
\r
274 a $HOME/.keep file and if present doesn't remove the homedir.
\r
278 For network logins you should keep in mind that they should not be done via
\r
279 rlogin, telnet, etc. because they send all traffic (including passwords) in
\r
280 plaintext over the network. You should use a tool which encrypts the whole
\r
281 traffic like SSLtelnet or SSH (for SSH you need to set "UseLogin yes" in
\r
282 the /etc/sshd_config file).
\r
286 You'll find all these scripts with error checking, user creating, stop
\r
287 scripts and config files etc. in section IX. EXAMPLE CONFIGURATION
\r
291 Note that we started daemons in the section which can be contacted from
\r
292 remote. If you don't want this (because there are no external users who
\r
293 need to mount their crypted user data on their own machine) you should
\r
294 firewall these ports. Look in you manpages ("man ipchains" or "man ipfwadm").
\r
300 <bold>*** 3. Traceable user activity</bold>
\r
304 [Warning, this section shows first how to perform simple electronic forensics]
\r
306 It is easy to see who logged on the system and what he did by the
\r
307 timestamps. Even if all your data is crypted, by checking the last access
\r
308 time (atime) of your files, someone may check when you logged in last time,
\r
309 for what duration and if you were idleing or doing much stuff.
\r
311 If the systems doesn't have many users, someone might even tell what you
\r
315 Example: The earliest access time for a crypted file in your homedir
\r
318 ls -altur /crypt/$USER | head -1 # shows the logout file
\r
319 ls -altu /crypt/$USER | more # with some brain you'll find
\r
324 then you also have the duration of the session.
\r
326 By checking the change/modification and access time of those crypted files
\r
327 with their timestamps someone can see how hard you were working, and get
\r
328 more conclusions (e.g. if many files nested in a three levels deep
\r
329 directory where modified this is probably a browser - so you were surfing
\r
333 This insight will now make it possible to check what commands were run:
\r
335 Let's say the login time as 22 hours ago, so you run:
\r
337 find / -type f -atime 0 -ls # shows the accessed files
\r
338 find / -type f -mtime 0 -ls # shows the modified files
\r
341 (this can be done with directories too)
\r
344 Now check the output for the correct timeframe and analyze what you found.
\r
345 e.g. the telnet client was accessed. So it's probable, the user used it
\r
346 to connect to another system. I think you can imagine now what is possible.
\r
350 To protect against this is also very easy:
\r
352 Create the file /usr/local/bin/touch_them and make it executable with
\r
353 the following contents:
\r
355 find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch
\r
359 Then put the following line into /etc/crontab:
\r
361 50 * * * * root /usr/local/bin/touch_them
\r
365 finally you change the 4th row of all lines in /etc/fstab which have the
\r
366 keyword "ext2" in their third (the filesystem type) row:
\r
367 <pre> defaults (or anything else)
\r
370 <pre> defaults,noatime (the old value is kept, and noatime is appended)
\r
375 <pre> /dev/hda1 / ext2 defaults 1 1
\r
378 <pre> /dev/hda1 / ext2 defaults,noatime 1 1
\r
382 What did we achieve? The crontab entry with the small script updates the
\r
383 atime, mtime and ctime to the current time every hour of special
\r
384 directories - especially those which may hold user data.
\r
386 The mount options we changed now prevent the update of the atime.
\r
387 However, this needs a current 2.2.x kernel - it isn't implemented on the
\r
395 <bold>*** 4. Protecting /var/spool/* files</bold>
\r
401 Now it gets tricky. How can we protect the new mail for a user from
\r
402 spying eyes? It can't be sent directly to a user's homedir like qmail would
\r
403 do because it's crypted. The easiest solution is to use pgp to encrypt
\r
404 your outgoing emails and tell all your friends that they should also encrypt
\r
408 However, this is not satisfying. An attacker can still see who sent the user
\r
409 the email. The only possibility to hide this is using anonymous remailer.
\r
410 This is not a great solution, so this is an open point (see section <a
\r
411 href="#102">X.2</a>:
\r
412 Additional thoughts)
\r
416 /var/spool/{mqueue|fax|lpd} :
\r
418 Well, all you can do is try to flush the queues when shutting down.
\r
420 After that you have to decide if you delete the remaining files in a
\r
421 secure way or leave it where it is. Or program a special script which does
\r
422 something with the data (like taring the data and encrypting it with pgp,
\r
423 doing the reverse when the system is rebooted)
\r
427 You can also create a whole crypted /var partition, but that would require
\r
428 someone at the console while booting the system - every time.
\r
437 <bold>* V. SYSTEM DATA</bold>
\r
440 <bold>*** 1. Sensitive system data</bold>
\r
444 What is sensitive system data? *Anything* which gives conclusion on incoming
\r
445 and outgoing data, configuration files, logs, reboots and shutdowns.
\r
451 - utmp/wtmp/lastlog data (boot, reboot, shutdown times + user times)<br>
\r
452 - ppp dialup script<br>
\r
453 - sendmail and tcp wrapper configurations<br>
\r
454 - proxy cache data (e.g. squid web/ftp proxy)<br>
\r
455 - syslog messages<br>
\r
456 - /var/spool/* data {mqueue|fax|lpd|mail}<br>
\r
457 - temporary files from daemons<br>
\r
458 - time stamps on data (when were what data accessed/edited)<br>
\r
462 How to prevent time stamp forensica, see section <a href="43">IV.3</a>
\r
464 How to protect /var/spool/* data, see section <a href="44">IV.4</a> for an incomplete
\r
471 <bold>*** 2. Traceable system activity</bold>
\r
475 (prevent of time stamp forensic is handled in section <a href="43">IV.3</a>)
\r
476 To trace system activity, you can easily check temporary files
\r
477 of daemons and applications. Some of them write to /tmp, root
\r
478 applications usually (should) write to /var/run.
\r
479 We handle this together with section <a href="53">V.3</a>: Logging.
\r
480 All you have to do is this, and only *once* :
\r
487 this moves the /var/run directory to /var/log/run and sets a symlink in it's
\r
488 former place so that applications still find their files.
\r
494 <bold>*** 3. Logging - important and dangerous</bold>
\r
498 Logging is important to trace problems like misconfigurations.
\r
500 Logging is dangerous because an attacker can see important data in
\r
501 the logfiles, like the user's login and logout time, if they executed
\r
502 "su" or other commands etc.
\r
504 We try to find a balance between this.
\r
506 Our solution: Write all log data to one special directory.
\r
508 This directory is a RAM disk so the data is lost after a system shutdown.
\r
509 Ensure that syslogd [/etc/syslog.conf] and daemons (e.g. httpd [apache])
\r
510 only write to our special logging directory or a system console.
\r
511 /var/log should be used as our special logging directory.
\r
516 Now we put the following commands into /sbin/init.d/boot.local:
\r
518 mke2fs -m0 /dev/ram0 1> /dev/null 2>&1
\r
519 rm -rf /var/log/* 2> /dev/null
\r
520 mount -t ext2 /dev/ram0 /var/log
\r
525 for i in `grep /var/log /etc/syslog.conf|grep -v '^#'| \
\r
526 awk '{print $2}'|sed 's/^-//'`
\r
528 umask 007 # 002 might be used too.
\r
529 for i in run/utmp wtmp lastlog
\r
530 do > $i ; chgrp tty $i ; done
\r
532 kill -HUP `pidof syslogd` 2> /dev/null
\r
535 After your next reboot it behaves like described above.
\r
539 Some of you will not like the idea of having no logs after a reboot.
\r
540 This way you can't trace an intruder or guess from your logs what
\r
541 crashed the machine. Either you can tar the files and pgp before
\r
542 the shutdown is complete (but the data would be lost if a crash occurs),
\r
543 or you might also use ssyslog or syslog-ng, special syslogs with crypting
\r
544 capabilities, and write the data you really want to keep to (just an example)
\r
549 You can also create a whole crypted /var partition, but that would require
\r
550 someone at the console while booting the system - every time.
\r
558 <bold>*** 4. Protecting system configs</bold>
\r
561 This is tricky. It is easy to achieve but for a price.
\r
562 If we create an account with uid which has his homedir in /home
\r
563 and is hence protected by our CFS configuration, you need to
\r
564 be at the console at every reboot. This isn't practical for server systems
\r
565 that need to be administrated and rebooted remotely.
\r
566 This solution is only good for end-user pcs.
\r
570 Just create an account with the uid 0 (e.g. with the login name "admin").
\r
571 You can use the create_user script from section IX.
\r
573 Put all your sensitive configuration files you want to protect into this
\r
574 directory (ppp dialup scripts, sendmail.cf configs, squid configs
\r
575 with their cache directory set to a subdir of "admin" etc.)
\r
577 Now create a small shellscript which starts these daemons with a command
\r
578 line option to use the config files in your "admin" homedir.
\r
582 Your system is then secure from extracting the sensitive information
\r
583 from the config files. But for a price. You have to log in after each
\r
584 reboot as user "admin", enter your CFS passphrase and start the script.
\r
591 <bold>*** 5. Computer Memory and sensitive /proc interfaces</bold>
\r
595 For a real multiuser system on which the administrator want additionally
\r
596 ensure the privacy of the user online, he has to hide the user process
\r
597 information, a user would normally see when issuing a "who" or "ps"
\r
598 command. To protect the user's process information, you can use
\r
599 Solar Designer's secure-linux kernel patch. To protect the utmp/wtmp/lastlog
\r
600 we ensure that these files are only readable by root and group tty,
\r
601 hence a normal user can't access this data. (This is done in the boot.local
\r
604 Now one problem is left. Even with normal RAM a well funded organisation
\r
605 can get the contents after the system is powered off. With the modern
\r
606 SDRAM it's even worse, where the data stays on the RAM permanently until
\r
607 new data is written. For this, I introduced a small tool for the
\r
608 secure_delete package 2.1, called "smem" which tries to clean the memory.
\r
609 This one should be called on shutdown. It is done in the example
\r
610 in section <a href="64">VI.4</a>
\r
619 <bold>* VI. DELETE(D) DATA AND SWAP</bold>
\r
622 <bold>*** 1. How to delete files in a secure way<</bold>
\r
626 When a file is deleted, only the inode data is freed, the contents of
\r
627 the data is NOT wiped and can be gathered with tools like "dd" or the
\r
628 tool manpipulate_data from THC.
\r
632 Peter Gutmann wrote a paper with the name "Secure Deletion of Data from
\r
633 Magnetic and Solid-State Memory" presented 1996 at the 6th Usenix Security
\r
634 Symposium. This is the best civilian paper on how to wipe data in a way that
\r
635 it is hard for even electronic microscopes to regain the data.
\r
637 There are four tools out there which uses the techniques described there,
\r
638 two called "wipe", one called "srm" from THC's secure_delete package and
\r
639 "shred" which is part of the new fileutil package from GNU.
\r
641 Ours is still the best from it's design, features and security, and it
\r
642 has also all important and advanced commandline options and speed you need.
\r
646 To use one of these tools for deletion just set an alias in /etc/profile:
\r
647 <pre> alias rm=srm # or wipe or shred
\r
650 or even better, move /bin/rm to /bin/rm.orig and copy the secure delete
\r
651 program to /bin/rm. This ensures, that all data which is deleted via
\r
652 rm is securely wiped.
\r
656 If you can't install THC's secure_delete package or any other (for any
\r
657 reason) you can also set the wipe flag from the ext2 filesystem on files
\r
658 you wish to wipe before rm'ing them. It's nearly the same, but it's NOT
\r
659 a secure wipe like mentioned above. It's set by:
\r
660 <pre> chattr +s filename(s)
\r
665 [Note that it is *still* possible for a well funded organisation to get your
\r
666 data. Don't rely on this! See section <a href="64">VI.4</a> !]
\r
673 <bold>*** 2. How to wipe free disk space</bold>
\r
677 Most times applications like the editor in your mail program write a
\r
678 temporary file. And you don't know about it - you weren't even asked :(
\r
679 Because they don't wipe the data in a secure way, an attacker can
\r
680 get all your private emails just because you didn't know. That's bad.
\r
682 The solution: You use a wiper program which cleans all unused data
\r
683 from the disk partitions.
\r
685 The only one available is the one from THC's secure_delete package.
\r
686 You could put "sfill" (that is what it is called) in you crontab so it is
\r
687 run regulary but this might create problems when at this moment this space
\r
688 is needed by an important application. At least when the system shuts down,
\r
689 sfill should be called.
\r
691 Put this in the "stop" part of a late rc2.d script:
\r
692 <pre> sfill -llf /tmp 2> /dev/null
\r
693 sfill -llf /var/spool 2> /dev/null
\r
698 Note that it is a good idea to generate a new paritition for /tmp itself,
\r
699 and putting a symlink from /usr/tmp and /var/tmp to /tmp. This way it is
\r
700 easier to control and wipe.
\r
704 Again, if you can't install the secure_delete package for any reason,
\r
705 you can also use this solution (slower and not as secure):
\r
706 <pre> dd if=/dev/zero of=/tmp/cleanup
\r
716 <bold>*** 3. How to handle swap data</bold>
\r
720 Securely wiping files and free diskspace - well what's left?
\r
721 Today, harddisk MB's are cheaper than RAM, thats why swap space is used to
\r
722 expand the available RAM. This is in reality a file or partition on your
\r
723 harddisk. And can have your sensitive data in it.
\r
727 Again there is only one tool which helps you out here, "sswap" from THC's
\r
728 secure_delete package ;-)
\r
730 Put this line after the "swapoff" line in /sbin/init.d/halt:
\r
731 <pre> sswap -l /dev/XXXX # the device for your swap, check /etc/fstab
\r
739 <bold>*** 4. How to handle RAM</bold>
\r
743 In section <a href="55">V.5</a> I wrote about sensitive information in your RAM, the fast
\r
744 memory of your computer system. It can hold very sensitive information
\r
745 like the email you wrote before pgp'ing it, passwords, anything.
\r
747 To ensure, that the memory is cleaned, use the smem utility.
\r
749 It should be called like this in the stop part of a late rc2.d script (as
\r
750 already mentioned above), after the wiping the file of /tmp etc. and
\r
751 then wiping the free memory:
\r
761 <bold>*** 5. Temporary data - it is evil</bold>
\r
765 After you have secured/anonymized/privatized your system so far everything's
\r
766 ready - or did you forget something?
\r
768 Remember what we told you in section <a href="61">VI.1</a>, that temporary data is written
\r
769 somewhere and sometimes you don't know. If you are unlucky, all we've done
\r
770 here was useless. We have to ensure that there's no temporary data
\r
771 left on the devices and that it can't be recovered either.
\r
773 We already dealed with /var/log, /var/run and sent email (/var/spool/...),
\r
774 and we wipe all free diskspace from our temporary disk locations.
\r
775 Now we must wipe also the temporary data.
\r
777 Put this line in the stop part of a late rc2.d script (before sfill
\r
778 from <a href="63">VI.3</a>):
\r
779 <pre> ( cd /tmp ; ls -A | xargs -n 250 srm -r ; )
\r
782 Also a $USER/tmp directory should be created for all users under the CFS
\r
783 /home protection and a TMPDIR variable set to this directory.
\r
787 See section IX. for all these scripts ...
\r
796 <bold>* VII. NETWORK CONNECTIONS</bold>
\r
800 This is a very specialized area of this document. I write here a few ways
\r
801 how someone can protect some of their data being transfered on the internet.
\r
805 The basic prerequisites are as following:
\r
806 You've got an external POP3 and SMTP (mail relayer) where you get and send
\r
807 your email. When your go on irc, you also don't like your real hostname
\r
808 being printed on the channels.
\r
812 Your external mail server should be in another country, because if maybe
\r
813 some official agencies think you're doing something illegal (and I'm sure
\r
814 you won't) it's harder to get a search warrant. It's also harder because
\r
815 companies or individuals that try to get your data would need to invest more
\r
816 time, work and money to get it.
\r
820 You can tunnel your SMTP and POP3 via ssh to the external mail server.
\r
822 For POP3 this is easy, but for SMTP this is a bit harder.
\r
824 Just as an example, irc traffic can be tunneled through this as well,
\r
825 but dcc stuff won't work (one way doesn't work, the other would reveal
\r
826 your ip address to the sender and the data is not encrypted on any part
\r
829 Note that you can also use redirectors and proxies to accomplish further
\r
830 redirecting for other protocols (www, irc, ftp proxies etc.)
\r
834 Thats all. All mail traffic (and as you can see below, irc traffic too) is
\r
835 being crypted between you and your mail/proxy server.
\r
839 sendmail.cf (important parts):
\r
840 <pre> DSsmtp:[127.0.0.1]
\r
841 DjTHE_DOMAIN_NAME_OF_YOUR_EMAIL
\r
842 DMTHE_DOMAIN_NAME_OF_YOUR_EMAIL
\r
843 - Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
\r
844 + Msmtp, P=[IPC], F=mDFMuXk, S=11/31, R=21, E=\r\n, L=990,
\r
846 (add the "k" switch to the smtp option config line)
\r
851 ~user/.fetchmailrc:
\r
852 <pre> poll localhost protocol POP3:
\r
853 user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here
\r
854 mda "/usr/sbin/sendmail -oem USER_LOCAL"
\r
856 (enter the corresponding USER_* and PASSWORD in here)
\r
860 The ssh commandline which tunnels the traffic for POP3, SMTP and irc:
\r
861 <pre> ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \
\r
862 25:localhost:25 your_mail_server.com
\r
867 That's all. I won't tell you more. Use your brain ;-)
\r
876 <bold>* VIII. HIDING PRIVACY SETTINGS</bold>
\r
878 <bold>*** 1. Mount is your friend</bold>
\r
882 Take a look at the following commands:
\r
885 drwxr-x--- 1 root root 1024 Mar 28 14:53 admin
\r
886 drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh
\r
887 drwxr-x--- 1 user users 1024 Mar 28 11:22 user
\r
888 # mount -t ext2 /dev/hda11 /home # or a ramdisk, doesn't matter
\r
891 # : whoops, where are the homedirs ?
\r
895 drwxr-x--- 1 root root 1024 Mar 28 14:53 admin
\r
896 drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh
\r
897 drwxr-x--- 1 user users 1024 Mar 28 11:22 user
\r
898 # : ah, yeah there they are again ...
\r
901 This is a nice feature to hide your crypted data and binaries.
\r
902 Just put your files into e.g. /usr/local/bin and /usr/local/crypt
\r
903 and mount a decoy filesystem over /usr/local. If you then have got
\r
904 a process started in your boot scripts which opens a file on the decoy
\r
905 filesystem, the filesystem can't be unmounted until the process is killed.
\r
906 This way, it's much harder for someone to detect your data!
\r
913 <bold>*** 2. Removable Medias</bold>
\r
917 An even better possibility is: put all your sensitive data on a removable
\r
918 media. Put your media in, mount it, it run the startscript from it
\r
919 to activate all the privacy stuff. This way you made it one step harder
\r
920 for someone to get to know whats going on.
\r
926 <bold>*** 3. ???</bold>
\r
930 Any other ideas? Think about it! (and maybe send me your ideas ;-)
\r
939 <bold>* IX. EXAMPLE CONFIGURATION AND SCRIPTS</bold>
\r
942 <a href="anonymous-unix-0.9.tar.gz">Click here</a> to download the
\r
943 <bold>anonymous-unix-0.9.tar.gz</bold> tools!
\r
952 <bold>* X. FINAL COMMENTS</bold>
\r
955 <bold>*** 1. Where to get the tools mentioned in this text</bold>
\r
959 - Crypto Filesystems
\r
961 CFS (Cryptographic File System) <a href="http://www.replay.com">http://www.replay.com</a><br>
\r
962 TCFS (Transparent CFS) <a href="ftp://mikonos.dia.unisa.it/pub/tcfs">ftp://mikonos.dia.unisa.it/pub/tcfs/</a><br>
\r
963 SFS (Stegano File System) <a href="http://www.linux-security.org/sfs">http://www.linux-security.org/sfs</a><br>
\r
964 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
969 THC's secure_delete package <a href="http://www.thc.org">http://www.thc.org</a><br>
\r
970 secure-linux kernel patch <a href="http://www.false.com/security">http://www.false.com/security</a><br>
\r
971 syslog-ng <a href="http://www.balabit.hu/products/syslog-ng.htm">http://www.balabit.hu/products/syslog-ng.htm</a><br>
\r
972 ssylog <a href="http://www.core-sdi.com/ssyslog">http://www.core-sdi.com/ssyslog</a><br>
\r
975 - The example Linux Distribution
\r
977 SuSE Linux Distribution <a href="http://www.suse.com">http://www.suse.com</a><br>
\r
982 <bold>*** 2. Additional thoughts</bold>
\r
986 The following problems are still present:
\r
988 - If an attacker can gain access to the system without rebooting
\r
989 and in time before data is wiped, unmounted, etc. these countermeasures
\r
990 are worthless.</ul>
\r
992 - If a really well funded organisation is trying to decrypt your
\r
993 data via brute force/dictionary or good electronic microscopes
\r
994 and technical staff with excellent knowhow, your wiping won't
\r
995 help you very much.</ul>
\r
997 - The solution for /var/spool/mail and /var/spool/mqueue etc. is far
\r
998 away from being perfect. Remember this. Ideas welcome.</ul>
\r
1000 - The configuration of your system daemons can only be secured if
\r
1001 you are present at the console after a reboot. That's the price.</ul>
\r
1003 - It is not very hard to detect the privacy stuff done. This might
\r
1004 bring you in trouble in countries like China or Iran. Removable
\r
1005 medias might help, or try a crypto filesystem with stegano support.</ul>
\r
1008 Secure your system against unauthorized (from your point of view) access
\r
1009 and use strong passwords.
\r
1015 <A NAME="103"></A>
\r
1016 <bold>*** 3. Greetings (what would the world be without greets?)</bold>
\r
1020 What would the world be without love and greetings? ;-)
\r
1024 Greets to individuals (in alphabetic order):
\r
1026 Doc Holiday, Froody, Fyodor, plasmoid, pragmatic, rookie,
\r
1027 Solar Designer, Tick, Wilkins.</ul>
\r
1031 <ul> ADM, THC (of course ;-) and arF</ul>
\r
1034 Greets to channel members:
\r
1035 <ul> #bluebox, #hack, #hax, #!adm and #ccc</ul>
\r
1040 <A NAME="104"></A>
\r
1041 <bold>*** 4. How to contact me for updates or comments</bold>
\r
1045 Please send me any further ideas you've got to make this documentation
\r
1046 better! Did I wrote bad bad english in some part? Could I rephrase parts
\r
1047 to make it easier to understand? What is wrong? What's missing? <a
\r
1048 href="mailto:vh@reptile.rug.ac.be>Email me!</a>
\r
1050 Tell me (best with a corrected diff) and I'll update this text.
\r
1055 Please use my public pgp key below.
\r
1063 <a href="mailto:vh@reptile.rug.ac.be">van Hauser / THC - [The Hacker's Choice]</a>
\r
1068 THC's Webpage -> <a href="http://www.thc.org">http://www.thc.org</a>
\r
1070 (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
1075 Type Bits/KeyID Date User ID
\r
1076 pub 2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>
\r
1078 -----BEGIN PGP PUBLIC KEY BLOCK-----
\r
1081 mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU
\r
1082 SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L
\r
1083 XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC
\r
1084 meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc
\r
1085 QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq
\r
1086 s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU
\r
1087 SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD
\r
1088 /3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn
\r
1089 CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYnOkUXgUQdPo69B04dl
\r
1090 C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN
\r
1091 1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ
\r
1092 PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ
\r
1093 2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X
\r
1094 lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/
\r
1095 Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI
\r
1096 o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==
\r
1098 -----END PGP PUBLIC KEY BLOCK-----
\r
projects / oweals / thc-archive.git / blob