File: intro.sgml

package info (click to toggle)
harden-doc 3.19%2Bnmu1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, bullseye, sid
  • size: 15,332 kB
  • sloc: xml: 11,790; sh: 52; makefile: 16
file content (1108 lines) | stat: -rw-r--r-- 46,293 bytes parent folder | download | duplicates (8)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108

<chapt>
<p>
       ,  ,
  ,    .  ,   
    , -      
 ,   .    
        .
  ,        
-,     .  
       
.  ,     
   /.

<p>
 ,   HOWTO     . 
         .   
           .
          ( 
  ),    ,
           .
Obviously, you must consider both issues.
# In addition this document just gives a overview of what you can do to increase
# the security of your Debian GNU/Linux
# installation. Many parts of this HOWTO can be transferred to other
# distributions.
<p>
    ,   ,   
 <url name="" id="mailto:ar@rhwd.net">,      
  HOWTO. 


<sect>    HOWTO
<p>
       Securing Debian HOWTO  
 :
<list>
<item><url name="Textonly" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/S
ecuring-Debian-HOWTO.txt">
<item><url name="HTML" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Secur
ing-Debian-HOWTO.html">
<item><url name="HTML, tarred &amp; gzipped" id="http://joker.rhwd.de/doc/Secur
ing-Debian-HOWTO/Securing-Debian-HOWTO.tar.gz">
<item><url name="SGML" id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Secur
ing-Debian-HOWTO.sgml">
</list>

<sect> / 
<p>
    .      
  HOWTO,    ,    .
but in my opinion this should not stay the case. I grew up and live with free
software, it is part of my everyday use and I guess yours, too. I encourage
everybody to send me feedback, hints additions or any other suggestions, you
might have.

If you think, you can maintain a certain section or paragraph better than me,
then write this to me and you are welcome to do it. Especially if you find a
section marked as FIXME, what means I did not have the time yet or the needed
knowledge about the topic, drop me a mail immediately.

The topic of this HOWTO makes is quite clear, that it is important to keep
uptodate, and you can help to keep the quality of this HOWTO up, so do it.

<sect> 
<p>
 Debian GNU/Linux          
.         Linux   ,  
  ,       ,   
      (    
 ,   HOWTO).


<sect>TODO
<p>
<list>
<item>suidmanager/dpkg-statoverrides
<item>lpr and lprng
<item>Switching off the gnome IP things
<item>LKM, linux kernel modules, bad and good ones
</list>


<sect>
<p>
<list>
<item>Alexander Reelsen,    
<item>Robert van der Meulen,    quota    
<item>Ethan Benson,     PAM     
<item> ,       HOWTO
<item>  Debian
</list>



<chapt>    

<sect>  BIOS
<p>
        , 
  BIOS     .  ,   
    ,      .
<p>
    -   .     ,
   ,       .
    ,    ,   
    .


<sect>    
<p>
         .
    -       
 :

<list>
<item> ,       ,
, /home  /tmp,   .     
  (DoS)      
"/"     . (-    , 
   ,     
 ).

<item> ,    , .,
/var ( /var/log).   Debian    /var 
,  ,     (  apt) 
  /var/apt/cache/archives.

<item> ,      .
   File Hierarchy Standard -   /opt  /usr/local. 
        .
</list>


<sect>  
<p>
    -    
  .


<sect>   MD5 
<p>
    ,       .
 ,       /etc/shadow.   
     root    root,  
      ,    
- .       
     'shadowconfig'.  ,  
  ,       MD5 . 
   ,      
    .


<sect>   
<p>
       .   -
     .     - 
,    ,    update-commands,
.. 'update-inetd'       .

# This section needs a list of services,and what they do and the risk level
# involved, as newbies don't have a clue.



<chapt> 

<sect>  LILO  GRUB
<p>
           
,   
"&lt;---&gt; init=/bin/sh"    .
         
        ,  .
      ,    .
<p>
   ,     .  
      ,     
 .
<p>
 LILO      /etc/lilo.conf  
 "password"  "restricted",     .

<example>
image=/boot/2.2.14-vmlinuz
   label=Linux
   read-only
   password=hackme
   restricted
</example>

<p>
  lilo.
  "restricted"  lilo t  
, regardless of whether LILO was passed parameters. 
       lilo, .., 
chmod 600 /etc/lilo.conf.
# is this Debian's default? if so say so or remove this , jfs
<p>
   GRUB  LILO,   /boot/grub/menu.lst
     .     
       :

<example>
timeout 3
password hackme
</example>


<sect>   
<p>
  MBR  Debian   2.2     MBR 
     :
<list>
<item>   shift     MBR 
<item>  F,       ,  
        .
</list>

    :

<tt>lilo -b /dev/hda</tt>

 LILO   MBR.     
"boot=/dev/hda"  lilo.conf.   ,   
   mbr:

<tt>install-mbr -i n</tt>
# is this install-mbr /dev/hda ?? jfs

# check whether this really is true as of 2.2 or was it 2.1?
INFO: The bootdisks as of Debian 2.2 do NOT install the mbr, but only LILO


<sect>  
<p>
   ext2      
        /etc/fstab.  
   fstab   /tmp:
<example>/dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2</example>
<p>
 <tt>nosuid</tt>    setuid  setgid, 
<tt>noexec</tt>       , 
 <tt>nodev</tt>  .   , 
<list>
<item>    ext2
<item> 
</list>
 <tt>noexec</tt>     , 
 :
<example>
alex@joker:/tmp# mount | grep tmp
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
alex@joker:/tmp# ./date
bash: ./date: Permission denied
alex@joker:/tmp# /lib/ld-linux.so.2 ./date
Sun Dec  3 17:49:23 CET 2000
</example>
<p>
         
  /tmp.      ,       .

<sect>PAM - Pluggable Authentication Modules
<p>
PAM (  )    
,     . , 
     PAM,    
.     Debian 2.2     .
 ,  Debian   2.2    PAM.
  PAM       
   /etc/pam.d/.

PAM       ,  
      .     
  Berkeley   passwd,      
    .      ,  
     .  .    
     .    
  "requisite",      , 
     .

,   , -    MD5   PAM,  
        .  
          /etc/pam.d/ 
   ,  'login'  'ssh'.

<example>
password   required     pam_cracklib.so retry=3 minlen=12 difok=3
password   required     pam_unix.so use_authtok nullok md5
</example>

,     ?     PAM,
    ,    
   12 ,      3  
     3 .   
     md5    
 .  use_authtok      
.

 ,        
  ,   /etc/pam.d/login  
 :

<tt>auth     requisite  pam_securetty.so</tt>

    ,       
   /etc/security/access.conf.
Last but not least the following line should be enabled if you want to set
up user limits.

<tt>session  required   pam_limits.so</tt>

This restricts the system resources that users are allowed.
For example, you could restrict the number of concurrent logins users may have.

Now edit the file /etc/pam.d/passwd and change the first line. You should add
the option "md5" to use md5 passwords, change the minimum length of password
from 4 to 6 (or more) and set a maximum length, if you desire. The resulting
line will look something like:

<tt>password   required   pam_unix.so nullok obscure min=6 max=11 md5</tt>

If we want to protect su, so that only some people can use it to become  on
your system, we need to add a new group "wheel" to your system (that
is the cleanest way, since no file has such a group permission yet). Add 
and the other users that should be able to "su" to the  user to this group.
Then add the following line to /etc/pam.d/su:

<tt>auth        requisite   pam_wheel.so group=wheel debug</tt>

This makes sure that only people from the group wheel can use to su to become
. If others try, they will get a message telling them access is denied.

Last, but not least, create /etc/pam.d/other and enter the following lines:

<example>
auth     required       pam_securetty.so
auth     required       pam_unix_auth.so
auth     required       pam_warn.so
auth     required       pam_deny.so
account  required       pam_unix_acct.so
account  required       pam_warn.so
account  required       pam_deny.so
password required       pam_unix_passwd.so
password required       pam_warn.so
password required       pam_deny.so
session  required       pam_unix_session.so
session  required       pam_warn.so
session  required       pam_deny.so
</example>

These lines will provide a good default configuration for all applications
that support PAM (access is denied by default).


<sect>The limits.conf file
<p>
You should really take a serious look into this file. Here you can define
user resource limits. If you use PAM, this file is not valid and you should use
/etc/security/limits.conf instead.
<tt>FIXME: Get a good limits.conf up here</tt>


<sect>Customize /etc/inetd.conf
<p>
You should stop all unneeded services on your system, like echo. charges, disca
rd,
daytime, time, talk, ntalk and the HIGHLY insecure considered r-services
(rsh, rlogin and rcp. Use ssh instead). After
disabling those, you should check if you really need the inetd daemon.
Many people prefer to use daemons instead of calling services
via inetd. Denial of Service possibilities exist against
inetd, which can increase the machine's load tremendously. If you still want to
 run some
kind of inetd service, switch to a more configurable inet daemon like xinetd or
rlinetd.
<p>
You can do this editing the inetd.conf directly, but Debian provides an
alternative to this: <tt>update-inetd</tt>. You could remove the telnet
daemon by do:
<example>
# /usr/sbin/update-inetd --disable telnet
# /etc/init.d/inetd restart
</example>


<sect>Edit /etc/login.defs
<p>
The next step is to edit the basic configuration and action upon user login.

<tt>FAIL_DELAY          10</tt>

This variable should be set to a higher value to make it harder using the
terminal to log in using brute force style. If a wrong password is typed in,
he has to wait for 10 seconds to get a new login prompt, what is quite time
consuming when you test passwords. Pay attention to the fact, that this
setting is useless if using program other than getty, such as mingetty.

<tt>FAILLOG_ENAB        yes</tt>

If you enable this variable, failed logins will be logged. It is important to
keep track of them to catch someone who tries a brute force attack.

<tt>LOG_UNKFAIL_ENAB    yes</tt>

If you set the variable "FAILLOG_ENAB" to yes, then you should also set yes to
this variable. This will record unknown usernames if the login failed. If you
do this, make sure the logs have to the proper permissions (640 for example,
with an appropriate group setting such as adm), because users often
accidentally enter their password as the username and you do not want others
to see it.

<tt>SYSLOG_SU_ENAB      yes</tt>

This one enables logging of <tt>su</tt> attempts to syslog. Quite important on 
serious
machines but note that this can create privacy issues as well.

<tt>SYSLOG_SG_ENAB      yes</tt>

The same as SYSLOG_SU_ENAB but applies to the <tt>sg</tt> call.

<tt>MD5_CRYPT_ENAB      yes</tt>

As stated above, md5 sum passwords greatly reduce the problem of
dictionary attacks, because it is very difficult to perform a crack
against MD5 hashed passwords. At least it is hard to do successfully.
If you are using slink, read the docs about MD5 before enabling this option.
Otherwise this is set in PAM.

<tt>PASS_MAX_LEN        50</tt>

If MD5 passwords are activated in your PAM configuration,
then this variable should be set to the same value as used there.


<sect>Editing /etc/ftpusers
<p>
This file contains a list of users who are not allowed to log into the host
using ftp. Only use this file if you really want to allow ftp (which is not
recommended in general, because it uses cleartext passwords). If your daemon
supports PAM, you can also use this allow and deny users for certain services.


<sect>Using tcp wrappers
<p>
TCP wrappers were developed when there were no real packet filters
available and access control was needed. The TCP wrappers allow
you to allow or deny a service for a host or a domain and define a default
allow or deny rule.
If you want more informations look into the manpage hosts_access(5).

Now, here comes a small trick and probably the smallest intrusion
detection system available. In general you should have a decent firewall
policy as a first line and tcp wrappers as the second line of defense.
One little trick is to set up a spawn command in /etc/hosts.deny that
sends mail to  whenever a denied service triggers wrappers:

<example>
ALL: ALL: spawn ( \
  echo -e "\n\
  TCP Wrappers\: Connection refused\n\
  By\: $(uname -n)\n\
  Process\: %d (pid %p)\n\
  User\: %u\n\
  Host\: %c\n\
  Date\: $(date)\n\
" | /bin/mail -s "Connection to %d blocked" root)
</example>

<em>Beware</em>: The above printed example can easily be DoSed by doing
lots of connections in a short period of time. Many emails mean a lot of
file I/O by sending only a few packets.

# Could this example be more interesting? 
# It also relates to the next sectionjfs
#<example>
#ALL: ALL: spawn ( \
#  /usr/local/sbin/send_syslog %u %c %d )
#</example>
#  Whit send_syslog as:
##!/usr/bin/perl -w
#
#use Sys::Syslog qw(:DEFAULT setlogsock);
#
#$user=shift(@ARGV) || 'unkown';
#$host=shift(@ARGV) || 'unkown';
#$service=shift(@ARGV) || 'unkown';
#setlogsock('unix');
#openlog("alert",'', 'user');
#syslog('warning', 'Connection from %s at %s to %s blocked.', ($user, $host, $service) );
#closelog();
#
#exit 0;

<sect>The importance of logs and alerts
<p>How log and alerts are treated is an important issue in a secure system.
It is easily to see that, even if the system is perfectly configured and,
supposedly, 99% secure. If the 1% comes to happen, if there are no security
measures in place to, first, detect this and, second, raise alarms. The system
is not secured at all.

<sect1>Configuring where alerts are sent
<p>Debian comes with a standard syslog configuration (in /etc/syslog.conf)
that logs messages to the appropiate files depending on the system facility. 
If you intend to maintain a secure system you should be wary of where this
messages are sent so they do not go unnoticed.
<p>For example, sending messages to the console also is an interesting setup
useful for many production-level systems. But for many such systems it
is important to also add a new machine that will serve as loghost (receives logs from
all other systems). 

<p>'s mail should be considered also, many security controls (like snort) send
alerts to 's mailbox. This mailbox usually points to the first user created in
the system (check /etc/aliases). Take care to send 's mail to some place where
it will be read (either locally or remotely).

# Note: it would be interesting to tell how a Debian system can send SNMP traps
# related to security problems, jfs
# check: snmptraglogd, snmp and snmpd

<sect1>Using a loghost
<p>
A loghost is a host which collects syslog data remotely over the network. If
one of your machines is cracked, the intruder is not able to cover his tracks,
unless he hacks the loghost as well. So, the loghost should be especially secur
e.
Making a machine a loghost is simple. Just start the
syslogd with 'syslogd -r' and a new loghost is born. Next configure
the other machines to send data to the loghost. Add an entry like the
following to <tt>/etc/syslog.conf</tt>:<p>

<example>facility.level            @your_loghost</example>

facility should be one of authpriv, cron, daemon, kern, lpr, mail, news,
syslog, user, uucp and local1 up to local7. level should be alert, crit, err,
warning, notice, info debug. If you want to log everything remote, just write:

<example>*.*                       @your_loghost</example>

into your syslog.conf. Logging remotely as well as locally is the best
solution (the attacker might presume to have covered their tracks after deletin
g the local
log files). See the syslog(3),
syslogd(8) and syslog.conf(5) manpage for additional information.


<sect1>Logfile permissions
<p>
It is not only important to decide how alerts are used but also who
has access to them, i.e. can read or modify the logfiles (if not
using a remote loghost). Since, in the event of an intrusion, even
with security alerts in place, if an attacker is able to change them
security goes back to nil
<p>
# It should be explained why after installation this is not
# already done, jfs
Some logfile permissions are not perfect after the installation. First
/var/log/lastlog and /var/log/faillog do not need to be readable by normal
users. In the lastlog file you can see who logged in the lasttime and in
the faillog you see a summary of failed logins. The author recommends
chmod'ing both to 660. Take a brief look over your log files and
decide very carefully which logfiles you make read/writeable for a user with
another UID than 0 and a group other than 'adm' or ''.

<p>
I want to emphasize that the apache logfile permissions are really screwed due
to the fact that the apache user owns the apache log files. If a user gets a
shell with a back door in apache, they can easily remove the logfiles.
# This is quite personal, IMHO, since this is due to the fact that 
# 's priviledges are dropped on startup. I prefer an attacker to erase
# a service's logfiles than to erase all of my system's logs. Anyhow, this
# can be improved by changing user permissions after rotation

<sect>Setting up setuid check
<p>
Debian provides a cron job that runs daily in <tt>/etc/cron.daily/standard</tt>
this cron job will run the <tt>/usr/sbin/checksecurity</tt> script
that will store information of this changes.

# What is the defaul for this in cron package? jfs

<p>In order for this check to be made you must set in <tt>/etc/checksecurity.conf</tt>:
<example>
CHECKSECURITY_DISABLE="FALSE"
</example>


# Is this sent to root? jfs

<sect>Using su
<p>
If you really need to become the super user on your system, eg for installing
packages or adding users, you can use the command <tt>su</tt> to change your
identity. You should try to avoid any login as user  and instead use su.
Actually, the best solution is to remove su and switch to sudo, as it has
more features than su. However, su is more common as is used on many other Unix
es.




<sect>Using sudo
<p>
sudo allows the user to execute defined commands under another users identity,
even as . If the user is added to /etc/sudoers and authenticates himself
correctly, he is able to run commands which have been defined in
/etc/sudoers. Violations, such as incorrect passwords or trying to run a
program you don't have permission for, are logged and mailed to .


<sect>Using chroot
<p>
ch is one of the most powerful possibilities to restrict a daemon or a
user or another service. Just imagine a jail around your target, where the
target cannot escape from (normally, but there are still a lot of conditions
that allow one to escape out of such a jail). If you do not trust a user, you c
an
create a change  environment for him. This can use quite a bit of disk spac
e
as you need to copy all needed executables, as well as libraries, into the jail
.
Even if the user does something malicious, the scope of the damage is limited t
o
the jail.  A good example for this case is, if you do not authenticate against
/etc/passwd but LDAP or MySQL instead. So your ftp-daemon needs a binary and
perhaps a few libraries. A chrooted environment would be an excellent security
improvement, if a new exploit is known for this ftp-daemon. It is then only
possible to exploit the UID of the ftp-daemon-user and nothing else. Of
course, many other daemons could benefit from this as well.
<p>
As an additional  , the Debian default BIND (the name-service) is not
shipped chrooted per default, in fact no daemons come chrooted. I hope this
will change in the woody release.


<sect>Configuring some kernel features
<p>
<tt>FIXME - Content missing</tt>
Many features of the kernel can be modified while running by echoing something
into the /proc file system or by using sysctl. By entering <tt>sysctl -A</tt> y
ou
can see what you can configure and what the options are. Only in
rare cases do you need to edit something here, but you can increase
security that way as well.

<tt>net/ipv4/icmp_echo_ignore_broadcasts = 0</tt>

This is a 'windows emulator' because it acts like windows on broadcast
ping if this is set to 1. Otherwise, it does nothing.

<tt>net/ipv4/icmp_echo_ignore_all = 0</tt>

If you don't want to block ICMP on your firewall, enable this.


<sect>Do not use software depending on svgalib
<p>
SVGAlib is very nice for console lovers like me, but in the past it has been
proven several times, that it is very insecure. Exploits against zgv were
released, and it was simple to become . Try to prevent using SVGAlib
programs wherever possible.


<sect>Secure file transfers
<p>
Copying files in a secure manner from a host to another can be achieved by
using 'scp' which is included in the ssh package. It works like rcp but is
encrypted completely, so the bad guys cannot even find out WHAT you copy.


<sect>Using quotas
<p>
Having a good quota policy is important, as it keeps users from filling
up the hard disk(s).
<p>
You can use two different quota systems - user quota and group quota. As you
probably figured out, user quota limits the amount of space a user can take
up, group quota does the equivalent for groups. Keep this in mind when you're
working out quota sizes.
<p>

There are a few important points to think about in setting up a quota
system:

<list>
<item>Keep the quotas small enough, so users do not eat up your disk space
<item>Keep the quotas big enough, so users do not complain or their mail quota
keeps them from accepting mail over a longer period
<item>Use quotas on all user-writable areas, on /home as well as on /tmp.
</list>
<p>
Every partition/directory users have full write access should be quota enabled.
So find out those partitions and directories and calculate a valuable quota
size, which concatenates usability and security.

So, now you want to use quotas. First of all you need to check whether you
enabled quota support in your kernel. If not, you will need to recompile it.
After this, control whether the package 'quota' is installed. If not you will
need this one as well.

Enabling quota for the respective filesystems is as easy as modifying the
'defaults' setting to 'defaults,usrquota' in your /etc/fstab file. If you need
group quota, substitute 'usrquota' to 'grpquota'. You can also use them both.
Then create empty quota.user and quota.group files in the s of the
filesystems you want to use quotas on (e.g. <tt>touch /home/quota.user</tt>,
<tt>touch /home/quota.group</tt> for a /home filesystem).

Restart quota by doing <tt>/etc/init.d/quota stop;/etc/init.d/quota
start</tt>. Now quota should be running, and quota sizes can be set.

Editing quotas for a specific user (say 'ref') can be done by
<tt>edquota -u ref</tt>. Group quotas can be modified with<tt>edquota -g
&lt;group&gt;</tt>.
Then set the soft and hard quota and/or inode quotas as needed.

For more information about quotas, read the quota man page, and the quota
mini-howto.


<sect>chattr/lsattr
<p>
These two commands are very useful, but they only work for the ext2 filesystem.
With 'lsattr' you can list the attributes of a file and with 'chattr' you can
change them. Note that attributes are not the same thing as permissions.
There are many attributes, but only the most important
for increasing security are mentioned here.

There are two flags which can only be set by the superuser.
First there is the 'a' flag. If set on a file, this file can only be opened
for appending. This attribute is useful for some of the files in /var/log/,
though you should consider they get moved sometimes due to the log rotation
scripts.

The second flag is the 'i' flag, short for immutable. If set on a file, it
can't be modified or deleted or renamed and no link be created to it.
If you do not want users to look into your config files you
could set this flag and remove readability. Furthermore it can give you a
little bit more security against intruders, because the cracker might be confus
ed 
by not being able to remove a file. Nevertheless, you should never assume that 
the
cracker is blind. After all, he got into your system.


<sect>Your filesystem integrity
<p>
Are you sure /bin/login on your hard drive is still the binary you installed
there some months ago? What if it is a hacked version, which stores the
entered password in a hidden file or mails it in cleartext version all over
the internet?

The only method to have some kind of protection is to check your files every
day/hour/month (I prefer daily) by comparing the actual and the old md5sum of
this file. Two files cannot have the same md5sum, so you're on the secure site
here, except someone hacked the algorithm to create md5sums on that machine,
what is, well, sticky. You really should consider this auditing of your
binaries as very important, since it is an easy way to recognize changes at
your binaries. Common tools used for this are sXid, AIDE (Advanced Intrusion
Detection Environment) and TripWire (non-free, the new version will be GPL).
<p>
Furthermore you can exchange your 'locate' package with 'slocate'. slocate
is a security enhanced version of GNU locate. When using slocate,
the user only sees the files he really has access to and you can exclude any
files or directories on the system.



<chapt>Securing services running on your system

<sect>Securing ssh
<p>
If you are still running telnet instead of ssh, you should take a break from th
is
manual and change this. Ssh should be used for all remote logins
instead of telnet. In an age where it is easy to sniff internet traffic
and get cleartext passwords, you should use only protocols which
use cryptography. So, perform an <tt>apt-get install ssh</tt> on your system no
w.
Encourage all the users on your system to use ssh instead of telnet, or
even better, uninstall telnet. In addition you should avoid logging
into the system using ssh as  and use alternative methods to become 
instead, like <tt>su</tt> or <tt>sudo</tt>. Finally, the sshd_config file,
/etc/ssh, should be modified to increase security as well:

<tt>PermitRootLogin No</tt>

Try not to permit Root Login wherever possible. If anyone wants to become 
via ssh, now two logins are needed and the  password cannot be brute
forced via SSH.

<tt>Listen 666</tt>

Change the listen port, so the intruder cannot be completely sure whether a
sshd daemon runs.

<tt>PermitEmptyPasswords no</tt>

Empty passwords make a mockery of system security.

<tt>AllowUsers alex ref</tt>

Allow only certain users to have access via ssh to this machine.

<tt>AllowGroups wheel admin</tt>

Allow only certain group members to have access via ssh to this machine.
AllowGroups and AllowUsers have equivalent directives for denying access to a
machine. Not surprisingly they are called "DenyUsers" and "DenyGroups".

<tt>PasswordAuthentication yes</tt>

It is completely your choice what you want to do. It is more secure only to
allow access to machine from users with ssh-keys placed in the
~/.ssh/authorized_keys file. If you want so, set this one to "no".

As a final note be aware, that these directives are from a OpenSSH
configuration file. Right now, there are three commonly used SSH
daemons, ssh1, ssh2 and OpenSSH by the OpenBSD people.
Ssh1 was the first ssh daemon available and it
is still the most commonly used (there are rumors that there is even a
windows port). Ssh2 has many advantages over ssh1
except it is released under an non-opensource license.
OpenSSH is completely free ssh daemon, which supports both ssh1 and
ssh2. OpenSSH is the version installed on Debian when the package
'ssh' is chosen.


<sect>Realize the insecurity of X over network
<p>
Today X-Terminals are being used by more and more companies where one
server is needed for a lot of workstations. This can be dangerous, because you
need to allow the file server to connect to the the clients (X server from
the X point of view. X switches the definition of client and server).
If you follow the (very bad)
suggestion of many docs, you type <tt>xhost +</tt> on your machine. This allows
 any X
client to connect to your system. For slightly better security, you can use the
 command 
<tt>xhost +hostname</tt> instead to only allow access from specific hosts.

A much more secure solution, though, is to use ssh to tunnel
X and encrypt the whole session. This is done automatically when you ssh
to another machine. Of course, even this can be disabled from
/etc/ssh/ssh_config.

For best security, if you do not need X access from other machines, is to switc
h off
the binding on tcp port 6000 simply by typing:

<tt>startx -- -nolisten tcp</tt>


<sect>The lpd and lprng issue
<p>
Imagine, you arrive at work, and the printer is spitting out endless amounts of
paper because someone is DoS'ing your line printer daemon. Nasty, isn't it?
So keep your printer servers specially secure.

<tt>FIXME. Content missing. (No lpr experience)</tt>


<sect> 
<p>
/  -       
.       POP3  IMAP,   
     ,      . 
    SSL (Secure Socket Layer).   - 
 ssh,          . 

  fetchmailrc:

<example>
poll my-imap-mailserver.org via "localhost"
  with proto IMAP port 1236
      user "ref" there with password "hackme" is alex here warnings 3600
    folders
      .Mail/debian
    preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
     my-imap-mailserver.org sleep 15 &lt;/dev/null &gt; /dev/null'
</example>

 preconnect -  .   ssh-  
 ,     
  localhost  1236    imap.   
 fetchmail  ssl.
<p>
         POP  
IMAP,   
<tt>apt-get install stunnel</tt>      :

<tt>stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd</tt>

       (-l)   (-d) 
  ssl (-p).




<sect> BIND
<p>
   Debian   , BIND,   
   .    BIND
 ID (UID)  . ,  BIND    
,  BIND      . 
,    PCMCIA-   . 
     README.Debian    named.
    ,   BIND,  
      .
<p>
  BIND   ,   
     (  nobody  nogroup ,
    , -    ).
        'named'.  :
<example>
# addgroup named
# adduser --system --ingroup named named
</example>
<p>
  <tt>/etc/init.d/bind</tt>     
 ,  
<p>
<tt>start-stop-daemon --start</tt>



<tt>start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named</tt>
<p>
   bind  '/etc/init.d/bind restart', 
  ,     syslog   :
<p>
<example>
Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named
</example>
<p>
!  named     .    
 BIND,     chroot (. 3.13).

# I'm not sure about this, shouldn't bind files be chown'ed to
# the groups created. This should be stated. jfs


<chapt>Before the compromise

<sect>Follow Debian security updates
<p>
As soon as new security bugs are revealed in packages, debian maintainers and
upstream authors generally patch them within days or even hours. After the bug 
is
fixed, a new package is provided on <url name="http://security.debian.org"
id="http://security.debian.org">. Put the following line in your sources.list
and you will get security updates automatically, whenever you update your syste
m.
<p>
<tt>deb http://security.debian.org/debian-security potato/updates main contrib 
non-free</tt>

Most people, who don't live in a country which prohibits importing
or using strong cryptography, should add this line as well:

<tt>deb http://security.debian.org/debian-non-US stable/non-US main contrib non
-free</tt>

If you want, you can add the deb-src lines to apt as well. See the apt manpage
for further details.


<sect>Exchange software
<p>
      ,   
     ,   FTP/Telnet/NIS/RPC. 
    ssh  telnet  ftp.

,     NIS, Network Information Service, 
     .  
   .

Last, but not least, disable RPC wherever possible. Many security
holes for this service are known and can be easily exploited.
On the other hand NFS services are quite
important in some networks, so find a balance of security and usability in a
network. Most of the DDoS (distributed denial of service) attacks use rpc
exploits to get into the system and act as a so called agent/handler.

 portmap  .   .   
 Debian   ,    <tt>update-rc.d portmap remove</tt>.
This in fact removes every symlink relating to portmap in /etc/rc${runlevel}.d/
(you could do this manually yourself) .
You could as well <tt>chmod 644 /etc/init.d/portmap</tt>, but that gives an error message
when booting. You can also
strip off the "start-stop-daemon" part in the <tt>/etc/init.d/portmap</tt> shell script.
 
  ,    telnet  ssh    ,
  ,       ! 
   ftp, telnet, pop, imap, http     
  ,  .    
  SSL-  : ftp-ssl, telnet-ssl, pop-ssl, https ...

        Unix.


<sect>   
<p>
   ,    .
   :
<p>
<list>
<item>OpenWall patch by Solar Designer.
     ,    ,
FIFOs  /tmp,  /proc,    ,
       .
 : <url name="http://www.openwall.com/linux/" 
id="http://www.openwall.com/linux/">

<item><em>LIDS - Linux intrusion detection system. : Huagang Xie &amp; Philippe
 Biondi</em>.
       Linux.  
    ,       
,  , ,   .    
      .   ,
   -,     -.
 : <url name="http://www.lids.org" id="http://www.lids.org">

<item><em>POSIX Access Control Lists (ACLs) for Linux</em>.
     Linux    (access 
control lists),       .
 : <url name="http://acl.bestbits.at/" id="http://acl.bestbits.at/">

<item><em>Linux trustees</em>.
This patch adds a decent advanced permissions system to your Linux kernel. All
the objects are stored in the kernel memory, which allows fast lookup
of all permissions.
 : <url name="http://www.braysystems.com/linux/trustees.html" id="http:/
/www.braysystems.com/linux/trustees.html">

<item><em>International kernel patch</em>.
This is a crypt-oriented kernel patch, therefore you have to pay
attention to your local laws regarding the use of cryptography. It basically ad
ds use of
encrypted file systems.
 : <url name="http://www.kerneli.org" id="http://www.kerneli.org">

<item><em>SubDomain</em>.
A kernel extension to create a more secure and easier to setup chroot
environment. You can specify the files needed for the chrooted service
manually and do not have to compile the services statically.
 : <url name="http://www.immunix.org/subdomain.html" id="http://www.immu
nix.org/subdomain.html">

<item><em>UserIPAcct</em>.
This is not really a security related patch, but it allows you to create
quotas for the traffic on your server per user. And you can fetch
statistics about the user traffic.
 : <url name="http://ramses.smeyers.be/useripacct" id="http://rsmeyers.3t
i.org/useripacct">
</list>


<sect>Genius/Paranoia Ideas, what you could do
<p>
This is probably the most unstable and funny section, since I hope that some
of the "duh. that sounds crazy"-ideas might be realized. Following here you
will find some - well, it depends on the point of view whether you say they
are genius, paranoid, crazy or secure - ideas to increase your security
rapidly but you will not come unscathed out of it.

<list>
<item>Playing around with PAM.
As said in the phrack 56 PAM article the nice thing with PAM is that "You are
limited only by what you can think of." It is true. Imagine  login only
possible with fingerprint or eyescan or cryptocard (hmm, why did I do an OR
conjunction and not AND here).

<item>Fascist Logging.
I would say everything we talked about logging above is "soft logging". If you
want to perform real logging, get a printer with fanfold paper and log
everything hard by printing on it. Sounds funny, but it's reliable and it
cannot be removed.

<item>CD distribution.
This idea is very easy to realize and extremely secure. Create a hardened
debian distribution, a damned good firewall, make an ISO of it and burn it on
CD. Make it bootable. Upshot of all this is a ro whole distribution with about
600 MB space for services and the fact to make it impossible for intruders to
get read write access on this system. Just make sure every data which should
get written, gets written over the wires. Anyway, the intruder cannot change
firewall rules, routing entries or start own daemons (he can, but reboot
and he has to hack into your system again to change them).

<item>Switch module capability off.
When you disable the usage of kernel modules at kernel compile time many
kernel based back doors are impossible to implement, since most of them are
based on installing modified kernel modules.
</list>


<chapt>After the compromise

<sect>General behavior
<p>
If you really want to clean up residual wastes, you should remove the
compromised host from your network and re-install the OS from scratch.
This might not have any effect if you do not know how the intruder got root.
In this case you must check everything: firewall/file integration/loghost logfi
les and so
on.