-
Notifications
You must be signed in to change notification settings - Fork 10
/
Anonymizing.Unix.Systems.html
1101 lines (947 loc) · 34.8 KB
/
Anonymizing.Unix.Systems.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Anonymous Unix Systems</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<center>
<h1>
---[ Anonymizing UNIX Systems ]---
<br>
version 0.9
</h1>
<br><br>
<table border=3 cellpadding=7 cellspacing=3>
<tr><td>Author: <I><a href="mailto:[email protected]">van Hauser</a> /
THC</I><br>
</td></tr>
</table>
</center>
<br><br><br><br>
<ul>
I. <A HREF="#1">THE AUDIENCE</A><ul></ul><br>
II. <A HREF="#2">GOAL</A><ul></ul><br>
III. <A HREF="#3">PREREQUISITES</A><ul></ul><br>
IV. <A HREF="#4">USER DATA</A><br>
<ul> 1. <A HREF="#41">Sensitive user data</A><br>
2. <A HREF="#42">Protecting /home directories</A><br>
3. <A HREF="#43">Traceable user activity</A><br>
4. <A HREF="#44">Protecting /var/spool/mail/user files</A></ul><br>
V. <A HREF="#5">SYSTEM DATA</A><br>
<ul> 1. <A HREF="#51">Sensitive system data</A><br>
2. <A HREF="#52">Traceable system activity</A><br>
3. <A HREF="#53">Logging - important and dangerous</A><br>
4. <A HREF="#54">Protecting system configs</A><br>
5. <A HREF="#55">Computer Memory and sensitive /proc interfaces</A></ul><br>
VI. <A HREF="#6">DELETE(D) DATA AND SWAP</A><br>
<ul> 1. <A HREF="#61">How to delete files in a secure way</A><br>
2. <A HREF="#62">How to wipe free disk space</A><br>
3. <A HREF="#63">How to handle swap data</A><br>
4. <A HREF="#64">How to handle RAM</A><br>
5. <A HREF="#65">Temporary data - it is evil</A></ul><br>
VII. <A HREF="#7">NETWORK CONNECTIONS</A><ul></ul><br>
VIII. <A HREF="#8">HIDING PRIVACY SETTINGS</A><br>
<ul> 1. <A HREF="#81">Mount is your friend</A><br>
2. <A HREF="#82">Removable Medias</A><br>
3. <A HREF="#83">???</A></ul><br>
IX. <A HREF="#9">EXAMPLE CONFIGURATION AND SCRIPTS</A><br>
X. <A HREF="#10">FINAL COMMENTS</A><br>
<ul> 1. <A HREF="#101">Where to get the tools mentioned in this text</A><br>
2. <A HREF="#102">Additional thoughts</A><br>
3. <A HREF="#103">Greetings (what would the world be without greets?)</A><br>
4. <A HREF="#104">How to contact me for updates or comments</A></ul><br>
</ul>
<br><br>
<center>
--------------------
</center><br><br><br><br>
<A NAME="1"></A>
<bold>* I. THE AUDIENCE</bold>
<br>
<br>
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.
<br>
<br>
Thanks to Solar Designer, Fyodor, typo, tick, pragmatic, mixter and
doc holiday for comments, critics and ideas.
<br>
Special thanks to rookie who had the original idea writing this paper
but through personal problems couldn't do it himself.
<br>
<br>
<br>
<br>
<A NAME="2"></A>
<bold>* II. GOAL</bold>
<br>
<br>
Our goal is to provide solutions to the following statements:
<br>
<br>
<ul>
(1) The solution should be simple and easy<br>
(2) All user data should be inaccessible by anyone except their owner<br>
(3) Nobody should be able to reconstruct what is happening on the system<br>
</ul>
Maybe you see contradictions ;-)
<br>
<br>
<br>
<br>
<A NAME="3"></A>
<bold>* III. PREREQUISITES</bold>
<br>
<br>
It is important to state the prerequisites for this project:
<br>
<ul>
- The system should be secure. No remote vulnerabilities (and hopefully
no local ones either)<br>
- The system administator(s) must be trusted and willing to set this up<br>
- The operating system to achieve this is a UNIX<br>
</ul>
Note that the solutions presented do not 100% fit internet servers.
<br>
However it's (nearly, bah ;-) perfect for enduser systems.
<br>
<br>
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.
<br>
The Linux distribution we use is the SuSE Linux Distribution 6.0
<br>
Debian is better but more complicated for beginners. And I dislike
redhat for it's missing security.
<br>
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!
<br>
<br>
<br>
<br>
<A NAME="4"></A>
<bold>* IV. USER DATA</bold>
<br>
<A NAME="41"></A>
<bold>*** 1. Sensitive user data</bold>
<br>
<br>
What is sensitive user data? Well *any* data from a user account.
This includes:
<ul>
- utmp/wtmp/lastlog data (login times and duration plus login hosts)<br>
- history files (what commands you typed in your session)<br>
- your emails<br>
- temporary files from applications like mailers, browsers etc.<br>
- applications and their configuration<br>
- your own data (documents, porn pics, confidental data)<br>
- time stamps on your data (when were you accessing/editing which data)<br>
- on multiuser systems: what users CURRENTLY are doing.. this includes
process listing, and network connections as well as utmp (which is
already covered by another category). -> make proc more restrictive.<br>
</ul>
<br>
We are trying to protect all this data.
<br>
Note that utmp/wtmp/lastlog data and mail (mqueue/mail/fax/lpd) is handled
in the SYSTEM DATA section.
<br>
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 ...
<br>
<br>
<br>
<A NAME="42"></A>
<bold>*** 2. Protecting /home directories</bold>
<br>
<br>
Most important for protecting user data is protecting the users' /home
directories.
<br>
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.
<br>
<br>
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)
<br>
<br>
To enable CFS we must put these six lines in a rc2.d script:
<pre> 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
</pre>
Additionaly we have to put this entry into /etc/exports:
<pre> /tmp/.tmp localhost
</pre>
<br>
<br>
Okay. This starts the sunrpc with the mountdaemon which are necessary
for CFS to be started and used.
<br>
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.
<br>
We create (this example is for bash) the file /.profile with the following
contents:
<pre> cattach /crypt/$USER $USER || exit 0
export HOME=/home/$USER
cd $HOME
if test -f $HOME/.profile; then
. $HOME/.profile
fi
</pre>
<br>
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.
<br>
<br>
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.
<br>
Thank god, this is easy too, we create a /home/user/.bash_logout script:
<pre> # 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
</pre>
<br>
Thats all. From now on, the users' homedirectories are safe.
<br>
<br>
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.
<br>
<br>
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).
<br>
<br>
You'll find all these scripts with error checking, user creating, stop
scripts and config files etc. in section IX. EXAMPLE CONFIGURATION
<br>
<br>
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").
<br>
<br>
<br>
<A NAME="43"></A>
<bold>*** 3. Traceable user activity</bold>
<br>
<br>
[Warning, this section shows first how to perform simple electronic forensics]
<br>
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.
<br>
If the systems doesn't have many users, someone might even tell what you
did.
<br>
<br>
Example: The earliest access time for a crypted file in your homedir
can be seen by:
<pre>
ls -altur /crypt/$USER | head -1 # shows the logout file
ls -altu /crypt/$USER | more # with some brain you'll find
# the login time
</pre>
<br>
then you also have the duration of the session.
<br>
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).
<br>
<br>
This insight will now make it possible to check what commands were run:
<br>
Let's say the login time as 22 hours ago, so you run:
<pre>
find / -type f -atime 0 -ls # shows the accessed files
find / -type f -mtime 0 -ls # shows the modified files
</pre>
<br>
(this can be done with directories too)
<br>
<br>
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.
<br>
<br>
To protect against this is also very easy:
<br>
Create the file /usr/local/bin/touch_them and make it executable with
the following contents:
<pre>
find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch
</pre>
<br>
Then put the following line into /etc/crontab:
<pre>
50 * * * * root /usr/local/bin/touch_them
</pre>
<br>
finally you change the 4th row of all lines in /etc/fstab which have the
keyword "ext2" in their third (the filesystem type) row:
<pre> defaults (or anything else)
</pre>
should become
<pre> defaults,noatime (the old value is kept, and noatime is appended)
</pre>
<br>
example:
<pre> /dev/hda1 / ext2 defaults 1 1
</pre>
becomes
<pre> /dev/hda1 / ext2 defaults,noatime 1 1
</pre>
<br>
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.
<br>
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!
<br>
<br>
<br>
<A NAME="44"></A>
<bold>*** 4. Protecting /var/spool/* files</bold>
<br>
<br>
/var/spool/mail :
<br>
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.
<br>
<br>
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 <a
href="#102">X.2</a>:
Additional thoughts)
<br>
<br>
/var/spool/{mqueue|fax|lpd} :
<br>
Well, all you can do is try to flush the queues when shutting down.
<br>
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)
<br>
<br>
You can also create a whole crypted /var partition, but that would require
someone at the console while booting the system - every time.
<br>
<br>
<br>
<br>
<A NAME="5"></A>
<bold>* V. SYSTEM DATA</bold>
<br>
<A NAME="51"></A>
<bold>*** 1. Sensitive system data</bold>
<br>
<br>
What is sensitive system data? *Anything* which gives conclusion on incoming
and outgoing data, configuration files, logs, reboots and shutdowns.
<br>
<br>
This includes:
<ul>
- utmp/wtmp/lastlog data (boot, reboot, shutdown times + user times)<br>
- ppp dialup script<br>
- sendmail and tcp wrapper configurations<br>
- proxy cache data (e.g. squid web/ftp proxy)<br>
- syslog messages<br>
- /var/spool/* data {mqueue|fax|lpd|mail}<br>
- temporary files from daemons<br>
- time stamps on data (when were what data accessed/edited)<br>
</ul>
<br>
How to prevent time stamp forensica, see section <a href="43">IV.3</a>
<br>
How to protect /var/spool/* data, see section <a href="44">IV.4</a> for an incomplete
solution.
<br>
<br>
<A NAME="52"></A>
<bold>*** 2. Traceable system activity</bold>
<br>
<br>
(prevent of time stamp forensic is handled in section <a href="43">IV.3</a>)
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 <a href="53">V.3</a>: Logging.
All you have to do is this, and only *once* :
<pre> cd /var
mv run log
ln -s log/run run
</pre>
<br>
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.
<br>
<br>
<A NAME="53"></A>
<bold>*** 3. Logging - important and dangerous</bold>
<br>
<br>
Logging is important to trace problems like misconfigurations.
<br>
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.
<br>
We try to find a balance between this.
<br>
Our solution: Write all log data to one special directory.
<br>
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.
<br>
<br>
<br>
Now we put the following commands into /sbin/init.d/boot.local:
<pre> 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
</pre>
After your next reboot it behaves like described above.
<br>
<br>
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.
<br>
<br>
You can also create a whole crypted /var partition, but that would require
someone at the console while booting the system - every time.
<br>
<br>
<br>
<A NAME="54"></A>
<bold>*** 4. Protecting system configs</bold>
<br>
<br>
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.
<br>
<br>
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.
<br>
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.)
<br>
Now create a small shellscript which starts these daemons with a command
line option to use the config files in your "admin" homedir.
<br>
<br>
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.
<br>
<br>
<br>
<A NAME="55"></A>
<bold>*** 5. Computer Memory and sensitive /proc interfaces</bold>
<br>
<br>
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)
<br>
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 <a href="64">VI.4</a>
<br>
<br>
<br>
<br>
<A NAME="6"></A>
<bold>* VI. DELETE(D) DATA AND SWAP</bold>
<br>
<A NAME="61"></A>
<bold>*** 1. How to delete files in a secure way<</bold>
<br>
<br>
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.
<br>
<br>
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.
<br>
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.
<br>
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.
<br>
<br>
To use one of these tools for deletion just set an alias in /etc/profile:
<pre> alias rm=srm # or wipe or shred
</pre>
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.
<br>
<br>
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:
<pre> chattr +s filename(s)
</pre>
<br>
<br>
[Note that it is *still* possible for a well funded organisation to get your
data. Don't rely on this! See section <a href="64">VI.4</a> !]
<br>
<br>
<br>
<A NAME="62"></A>
<bold>*** 2. How to wipe free disk space</bold>
<br>
<br>
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.
<br>
The solution: You use a wiper program which cleans all unused data
from the disk partitions.
<br>
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.
<br>
Put this in the "stop" part of a late rc2.d script:
<pre> sfill -llf /tmp 2> /dev/null
sfill -llf /var/spool 2> /dev/null
</pre>
<br>
<br>
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.
<br>
<br>
Again, if you can't install the secure_delete package for any reason,
you can also use this solution (slower and not as secure):
<pre> dd if=/dev/zero of=/tmp/cleanup
sync
rm /tmp/cleanup
</pre>
<br>
<br>
<br>
<A NAME="63"></A>
<bold>*** 3. How to handle swap data</bold>
<br>
<br>
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.
<br>
<br>
Again there is only one tool which helps you out here, "sswap" from THC's
secure_delete package ;-)
<br>
Put this line after the "swapoff" line in /sbin/init.d/halt:
<pre> sswap -l /dev/XXXX # the device for your swap, check /etc/fstab
</pre>
<br>
<br>
<br>
<A NAME="64"></A>
<bold>*** 4. How to handle RAM</bold>
<br>
<br>
In section <a href="55">V.5</a> 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.
<br>
To ensure, that the memory is cleaned, use the smem utility.
<br>
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:
<pre> smem -ll
</pre>
<br>
<br>
<br>
<A NAME="65"></A>
<bold>*** 5. Temporary data - it is evil</bold>
<br>
<br>
After you have secured/anonymized/privatized your system so far everything's
ready - or did you forget something?
<br>
Remember what we told you in section <a href="61">VI.1</a>, 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.
<br>
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.
<br>
Put this line in the stop part of a late rc2.d script (before sfill
from <a href="63">VI.3</a>):
<pre> ( cd /tmp ; ls -A | xargs -n 250 srm -r ; )
</pre>
Also a $USER/tmp directory should be created for all users under the CFS
/home protection and a TMPDIR variable set to this directory.
<br>
<br>
See section IX. for all these scripts ...
<br>
<br>
<br>
<br>
<A NAME="7"></A>
<bold>* VII. NETWORK CONNECTIONS</bold>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
You can tunnel your SMTP and POP3 via ssh to the external mail server.
<br>
For POP3 this is easy, but for SMTP this is a bit harder.
<br>
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)
<br>
Note that you can also use redirectors and proxies to accomplish further
redirecting for other protocols (www, irc, ftp proxies etc.)
<br>
<br>
Thats all. All mail traffic (and as you can see below, irc traffic too) is
being crypted between you and your mail/proxy server.
<br>
<br>
sendmail.cf (important parts):
<pre> 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,
</pre>
(add the "k" switch to the smtp option config line)
<br>
<br>
~user/.fetchmailrc:
<pre> poll localhost protocol POP3:
user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here
mda "/usr/sbin/sendmail -oem USER_LOCAL"
</pre>
(enter the corresponding USER_* and PASSWORD in here)
<br>
<br>
The ssh commandline which tunnels the traffic for POP3, SMTP and irc:
<pre> ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \
25:localhost:25 your_mail_server.com
</pre>
<br>
<br>
That's all. I won't tell you more. Use your brain ;-)
<br>
<br>
<br>
<br>
<A NAME="8"></A>
<bold>* VIII. HIDING PRIVACY SETTINGS</bold>
<A NAME="81"></A>
<bold>*** 1. Mount is your friend</bold>
<br>
<br>
Take a look at the following commands:
<pre># 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 ...
</pre>
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!
<br>
<br>
<br>
<A NAME="82"></A>
<bold>*** 2. Removable Medias</bold>
<br>
<br>
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.
<br>
<br>
<A NAME="83"></A>
<bold>*** 3. ???</bold>
<br>
<br>
Any other ideas? Think about it! (and maybe send me your ideas ;-)
<br>
<br>
<br>
<br>
<A NAME="9"></A>
<bold>* IX. EXAMPLE CONFIGURATION AND SCRIPTS</bold>
<br>
<br>
<a href="anonymous-unix-0.9.tar.gz">Click here</a> to download the
<bold>anonymous-unix-0.9.tar.gz</bold> tools!
<br>
<br>
<br>
<br>
<A NAME="10"></A>
<bold>* X. FINAL COMMENTS</bold>
<br>
<A NAME="101"></A>
<bold>*** 1. Where to get the tools mentioned in this text</bold>
<br>
<br>
- Crypto Filesystems
<ul>
CFS (Cryptographic File System) <a href="http:https://www.replay.com">http:https://www.replay.com</a><br>
TCFS (Transparent CFS) <a href="ftp:https://mikonos.dia.unisa.it/pub/tcfs">ftp:https://mikonos.dia.unisa.it/pub/tcfs/</a><br>
SFS (Stegano File System) <a href="http:https://www.linux-security.org/sfs">http:https://www.linux-security.org/sfs</a><br>
Crypto Loopback Filesystem <a href="ftp:https://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/">ftp:https://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/</a><br>
</ul>
- Tools
<ul>
THC's secure_delete package <a href="http:https://www.thc.org">http:https://www.thc.org</a><br>
secure-linux kernel patch <a href="http:https://www.false.com/security">http:https://www.false.com/security</a><br>
syslog-ng <a href="http:https://www.balabit.hu/products/syslog-ng.htm">http:https://www.balabit.hu/products/syslog-ng.htm</a><br>
ssylog <a href="http:https://www.core-sdi.com/ssyslog">http:https://www.core-sdi.com/ssyslog</a><br>
</ul>
- The example Linux Distribution
<ul>
SuSE Linux Distribution <a href="http:https://www.suse.com">http:https://www.suse.com</a><br>
</ul>
<br>
<A NAME="102"></A>
<bold>*** 2. Additional thoughts</bold>
<br>
<br>
The following problems are still present:
<ul>
- If an attacker can gain access to the system without rebooting
and in time before data is wiped, unmounted, etc. these countermeasures
are worthless.</ul>
<ul>
- If a really well funded organisation is trying to decrypt your
data via brute force/dictionary or good electronic microscopes
and technical staff with excellent knowhow, your wiping won't
help you very much.</ul>
<ul>
- The solution for /var/spool/mail and /var/spool/mqueue etc. is far
away from being perfect. Remember this. Ideas welcome.</ul>
<ul>
- The configuration of your system daemons can only be secured if