<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.