2. Basic Security Policy

Much of this document is concerned with security-related software --- that is, software added to the basic operating-system. However, in this section we consider steps which should be taken towards securing a system which do not involve such software: removing unnecessary services --- software listening for connections from remote hosts; ensuring (vendor-supplied) patches and updates are applied; and chrooting services.

2.1. Services

Unnecessary Services: NFS, Sendmail and Others

Any service --- daemon listening on a port for requests for sessions from remote hosts --- potentially opens a door for a would-be intruder, for example, through buffer overflows. As a general rule, therefore, run services which listen on TCP and UDP ports, like NFS, Sendmail (or other mail delivery agent) and FTP only if you really need to.

An alarming number of Unix/Linux installations run an equally alarming number of services by default. To change this quickly and easily (without uninstalling anything) simply edit: on older versions of Linux, /etc/inetd.conf; on newer versions of Linux, the xinetd configuration; on Solaris, /etc/inetd.conf.

Of course, applying all available patches and making use of the security-related software mentioned below, will make your system "quite secure", but nothing is as good as simply eliminating crackable services.

Port numbers below 1024; dropping root privileges

On most Unix systems, a programme needs to have root privileges to run a service on a port number less than 1024 (e.g., SMTP on port 25; telnet on 23; HTTP on 80). However, once a programme has bound to a given port (below 1024) there is not usually any reason why root privileges need to be maintained --- most programmes then drop these privileges and run as, for example, nobody, a user with almost no privileges. Apache can do this and does on most systems.

Some email servers do not give up root privileges after initialisation, the classic example being sendmail. Through buffer-overflows it is sometimes possible to trick a daemon listening on a port into running arbitrary code with the daemon's uid --- if this is root then the intruder can potentially take control of the system.

In short, if it is possible to run a service without root privilege, do so!

Wrapping Services

One can further reduce the probability of a system being compromised through a security hole in a service by wrapping daemons.

chrooting Services

The chroot command forces a program to run under a subset of the file system, without allowing access from it to any other parts of the file system --- anonymous ftp is commonly handled this way. For example,
    chroot /var/local/ftpd ftpd

Unfortunately setting up, for example, a web-server chrooted is not as simple as it might seem --- all files that the daemon (in this case it could be httpd) need must be accessible within the subset of the file system: configuration files (which might reside in /etc), shared-object files (which could be in /usr/lib)... Guides for chrooting a web-server can be found below.

More

2.2. Updates and Patches

As security holes are found in software, they are fixed and patches and updates posted --- get these and install them; unpatched systems are a mine of opportunity to a potential intruder. There are many web sites to watch, including those from RedHat and Solaris, where patches and updates are posted for download and installation.

2.2.1. RedHat Linux

2.2.2. SuSE Linux

YaST2 has an on-line update module. You don't need to register to run this. You need to run this as root.

2.2.3. Debian Linux

Debian has had apt-get for years. Simply run apt-get [-u] update and sit back.

2.2.4. Solaris

2.2.5. Other

...previousup (conts)next...



About this document:

Produced from the SGML: /home/isd/public_html/_unix_security/_reml_grp/unix_security_survey.reml
On: 10/11/2004 at 9:49:32
Options: reml2 -i noindex -l long -o html -p multiple