Introduction

This document has been published by the Australian Computer Emergency
Response Team (AusCERT). It provides a checklist of steps to improve the security
of UNIX and Linux systems. We encourage system administrators to review all
sections of this document and if appropriate modify their systems to fix
potential weaknesses.

The checklist is structured to follow the lifecycle of a system, from
planning and installation to recovery and maintenance.
Sections A to G of the checklist are best applied to a system before it is
connected to the network for the first time. In addition, the checklist can be
reapplied on a regular basis, to audit conformance.

No two organisations are the same, so in applying the checklist consideration
should be given to the appropriateness of each action to your particular
situation. Rather than enforcing a single configuration, this checklist will
identify the specific choices and possible security controls that should be
considered at each stage.

Operating system specific footnotes throughout the document offer some
additional information to help with applying these steps on specific
UNIX and Linux variants.

The most current version of this document is available at
http://www.auscert.org.au/1935
We will continue to update this checklist. Any comments should be directed
via email to auscert@auscert.org.au.

Before using this document, please ensure you have the latest version.
New versions of this checklist will be available via the URL listed above and
should be checked for periodically.

Disclaimer
AusCERT advises that this information is provided without warranty -
sites should ensure that actions and procedures taken from information in this
document are verified and in accordance with security policies that are in place
within their organisation. Listing of software products or tools within this
document does not constitute endorsement by AusCERT or The University of
Queensland.

Apply your organisation's information security policy to guide the
decisions made in this section.

A.1 Computer role

First decide on and document the role of this computer. This means
specifying exactly which services the computer will provide.

Example computer roles are:

email server and email virus/spam scanner

user workstation for word processing, email and web browsing

combined web server / database server

A.2 Assess security needs of each kind of data handled

The security measures appropriate for this computer will depend greatly
on what information will be stored on it, or pass through it.

For Internet connected computers, even for unimportant data, a certain
baseline level of security will be required, to stop this computer being
used as a platform to attack further into the network or other
external networks.

The following steps will help to determine the security needs of this
system:

1. Data on this system

Considering the computer role, identify each kind of information
that will be handled by this computer. Examples are:

office emails

client personal data

private keys and certificates

source code being developed in-house

The list should also identify information such as user passwords,
which may be typed into this computer but which also give access
to other systems that use the same password.
2. Threats

Consider the potential threats to each kind of information
identified above. Which classes of attacker will be motivated to
read, modify or disable each of these kinds of data?

Consideration of the threat should include both targeted and
indiscriminate attacks.

Targeted attacks:
Targeted attacks refer to those where attackers may specifically target
your business or your customers. Depending on the kind of information
processed, threats may include malicious changes by a disgruntled insider,
a denial of service attack for the purpose of extortion, or industrial
espionage or sabotage.

Indiscriminate attacks:
All computers on the Internet are subject to these threats.
Some organisations believe that their systems will not be of
interest to attackers; this is incorrect. Attackers are interested
in controlling your computers for a number of reasons, including
to launch attacks on other organisations, to send spam, or to
capture users' authentication credentials.

3. Impacts if threats are realised

For each of the threat scenarios, estimate the impact on your
organisation if the attack is realised.
The cost may be measured in money / time / reputation

4. Determine acceptable risk

Based on the potential impacts, determine what level of risk can
be accepted. Such determination of risk acceptance levels should be done
in conjunction with senior management.

Making explicit the threats and impacts in this way will highlight
what the priorities should be for protecting each kind of information on
the system.

For organisations with little dependence on IT and no critical data
these steps can be done informally. Otherwise, consider doing the
assessment in writing, integrated with the risk assessment for the
overall network.

In the Australian context, guidelines for information security risk
management are provided by HB 231:2004, available from Standards
Australia.

A.3 Trust relationships

Identifying trust relationships will determine whether the security
of this computer is appropriate relative to other computers.
For example, a secure configuration is useless if a UNIX server is
managed from day to day using a workstation controlled by an attacker.

Below are three questions to ask to determine the trust relationships:

1. Which systems does this computer trust?
These will include the following:

Workstations used to administer this computer e.g. by SSH or web interface;

Authentication servers (e.g. kerberos or LDAP servers);

Backup servers (e.g. during a restore).

Those systems must be made at least as secure as this computer.

2. Which computers trust integrity of data served up by this computer?
For example:

Authentication clients, if this is an authentication server;

Computers that may be administered from this computer;

Workstations, if this is a file server.

This computer must be made at least as secure as those systems.

3. Which computers trust this computer to maintain confidentiality of data?
These may include:

Peer VPN endpoints;

Database clients.

This computer must be made at least as secure as those systems.

A.4 Uptime requirements and impact if these are not met

Consider how reliable this computer is expected to be, and what the
impact will be if these uptime requirements are not met.

This can include issues such as the following:

Will work in the organisation be affected if this computer fails?

Are specific service levels required by contract?

Will business be lost if customers cannot access a web site?

These uptime requirements will also influence the Backup/Rebuild
Strategy chosen later in section I.

A.5 Determine minimal software packages required for role

From the role determined in A.1, document which programs are needed to
fully implement this role. This includes any extra libraries or
support software that the main software needs.

Later in this checklist, installed software will be minimised to
just the software determined here.

A.6 Determine minimal net access required for role

Document which TCP and UDP port numbers this computer will need to
communicate on to perform its role, including the direction (in or
outbound).

Where appropriate, also record which specific computers this one will be communicating
with for each service.

Later in this checklist, network access will be restricted to only this
required access.

B.1 Install from trusted media

If installing the operating system from downloaded ISO images,
Use a trustworthy computer to check the integrity of the
install CDs after they are burnt, using a hash (MD5/SHA1/other) or
detached PGP signature.
An example command to check the MD5 hash of a CD under Linux would be:dd if=/dev/cdrom bs=64k | md5sum

If using MD5 or SHA1 hashes, make sure that the list of hashes
itself comes from a trusted source (either digitally signed (preferably)
or from a trusted SSL authenticated web site).

B.2 Install while not connected to the Internet

Install the operating system while not connected to the Internet.
For a network installation of multiple machines, it is preferable to
use an isolated staging network during the initial installation.

B.3 Use separate partitions

Creating separate partitions for different parts of the filesystem allows:

more flexibility in applying different mount options to
different parts of the hierarchy, to restrict the use of files (as described below in E.5.2);

avoiding denial of service by disk space exhaustion (e.g. log files);

hard links are prevented from crossing partition boundaries.

Use separate partitions for /, /usr, /var, /tmp
and /home. Good planning of the partition scheme
is essential.

B.4 Install minimal software

When making selections during the installation process, install only
the software sets required for this computer's role, as determined in A.5

Ensuring the latest patches and updates are applied is crucial to
security as UNIX systems with unpatched public vulnerabilities are
quickly compromised by attackers.

C.1 Initially apply patches while offline

After the first install, consider applying patches and updates while
disconnected from the network, either:

from a CD containing the patches, or

on a trusted staging network disconnected from the Internet.

If updating directly over the Internet is really necessary, then
first install and configure a restrictive host firewall (see H.1) on
the new system, allowing only the connections required for updating.
(Often DNS plus one of HTTP, HTTPS or SSH outbound is all that is
required.) In this case, after the initial updating is complete, the host
can then be disconnected from the network until the remaining steps in
sections D to H have been completed to bring the system to the
appropriate level of security.

Do also patch and update any third party software installed.

C.2 Verify integrity of all patches and updates

Before installing any patches or updates that have been downloaded, check
that they have not been modified.

On some systems, digital signatures on patches or updates may be verified
automatically by the package tool.

Patches or updates for some other systems may be PGP signed. These
signatures can be verified using GnuPG, available with your system or from
http://www.gnupg.org

If a digital signature is not available but an MD5 or SHA hash is, then
use this to verify the integrity of the patch/update.

C.3 Subscribe to mailing lists to keep up to date

Ensure that you are subscribed to the "announce" and "security"
mailing lists for each vendor of software that you use to ensure that
you have rapid notification of future patches and security updates (see J.1).

If automatic update checks and/or automatic application of updates are
available, also consider whether using this is appropriate for your situation.

Some other steps recommended to be ready for future patching are
described in section J (Maintain).

After the initial installation is complete, minimise the amount of software that is
present by uninstalling or disabling the unneeded software packages, leaving a
minimal set of software. Ideally, only the software that will be used in performing
the computer's role, as decided in A.1 above, should remain.

Check the dependencies between software packages to determine which
libraries and helper software are also required for the role.

D.1 Minimise network services

D.1.1 Locate services and remove or disable

Use netstat to find all listening network services.

Also use the ps command to view which processes are running by
default on startup.

Preferably uninstall any services that are not required

Otherwise disable them by editing or removing the relevant
startup scripts

D.1.2 Minimise inetd/xinetd

D.1.3 Minimise portmapper and RPC services

Disable the portmap service completely unless it is
necessary for the system to perform its role. Usually a machine that does
not use NFS or NIS/NIS+ does not need portmap, however there are some other
software packages that may need it such as FAM (on IRIX or Linux), mcserv, dracd
and several Solaris specific services.

Disable any non-required services that are registered with the
portmapper on start up.

To check for registered RPC services, use the command:
/usr/bin/rpcinfo -p

On systems that track software package dependencies, that gives an even more
convenient way to identify any packages that depend on the portmapper.

See also section F.7 for advice on configuring RPC.

D.1.4 Notes on particular network services

Remove or disable the "r" commands
This includes rlogind, rshd, rcmd, rexecd, rbootd, rquotad,
rstatd, rusersd, rwalld and rexd. These services are inadequately
authenticated. It is better to remove these and use SSH and scp instead.

Note the special case of rsync, which is not one of
the traditional "r" commands. rsync is useful and while by default
it provides authentication of connections and transferred data, its native authentication is
not strong so where rsync is required it is recommended to run it over SSH.

Remove or disable fingerd
Remove or disable fingerd if present. Apart from the possibility
of a software vulnerability, fingerd allows an attacker to enumerate
usernames on the system and to determine the timing and frequency of
system administrator logins.

If tftpd is required for the computer's role, create a separate
partition to store the files to be served by tftp and limit the
tftp daemon to the directory where this partition is mounted.

Ensure that the files in the tftp area are not writable, unless
this is required for the system's role.

TFTP is not authenticated, so to protect devices using TFTP,
it is highly recommended only to allow it over a trusted network,
such as a trusted management network for configuring network devices
and not over the main LAN.

Disable SNMP daemon
If present by default, disable any SNMP daemon unless this is
really required for the role of the computer.

D.3 Minimise SetUID/SetGID programs

Programs which are SetUID or SetGID are good candidates for removal
because any bugs in these programs are likely to have a security impact,
allowing an attacker who already has access to the system to elevate priveleges
and increase their control.
The steps below are particularly important for multi-user systems, such as
web hosting servers with multiple accounts.

Locate SetUID/SetGID programs using a command such as
find / -perm +6000 -ls

Preferably uninstall them if not needed

Otherwise disable the SUID or SGID bit, so that the program is only given
the privileges of the user running it. Note that in some cases this can mean
that the program will then only work when run by root.

If SetUID/SetGID programs really need to be used by other users,
then consider restricting who can run them by group membership:

create a new group for this program

change the group ownership of the binary to this new group

change the permissions of the binary to deny execute
permission for Others (chmod o-rx)

E.1 Physical, console and boot security

Check that physical access to the computer is restricted
appropriately. Regardless of what configuration is used, an
attacker with physical access to the computer can in most cases
take full control of the system.

That said, the following controls should be considered to increase
the difficulty of the walk-in attack:

Disable booting from any removable media by configuring the
BIOS or EEPROM.

Set a password to prevent changes to these BIOS or EEPROM settings.

Ensure the boot loader does not allow booting to single user mode
without a password.

Consider disabling any special hotkeys that drop the console into
a debugging mode.

For situations where access is public, such as an internet cafe or
shared computer lab, these measures are essential. For other situations
these measures can be considered based on physical security.

E.2 User Logons

E.2.1 Account Administration

Consider having a paper User Registration Form for each user on the system.
This form includes a section that the user signs, stating that they have
read your security policy or acceptable use policy and what the consequences
are if they contravene the policy.

Have a documented process for when staff leave, to ensure that dormant
accounts can not occur.

Have a process for staff transfers and role changes, to ensure that
appropriate changes are made to the user's authorisation and access
rights on the system.

Note when disabling accounts:
In general, besides setting the accounts to disabled or deleting
them entirely it is also necessary to:

search for and remove all files owned by that UID (in case the
UID gets reallocated to a new user);

check that the accounts have no cron or
at jobs;

use ps to check for and kill any processes running under that UID.

E.2.2 Special accounts

Ensure that there are no shared accounts other than root.
(i.e. more than one person should not know the password to an
account)

Disable any guest accounts (accounts that can be used without
any authentication) and do not create guest accounts.
(Note: Even now, some systems come preconfigured with guest accounts.)

Disable any default vendor accounts shipped with the
operating system that can be logged in to. This may need to be
rechecked after an upgrade.
Note that default accounts may sometimes be added during installation
of third-party software applications, so these should be checked for
after installation.

Disable accounts with no password which execute a single command,
for example sync.

Ensure non-functional login shells (such as
/bin/false or /sbin/nologin)
are assigned to system accounts such as bin and daemon. There is no need
to remove the default system accounts but it is important that they can
not be logged in to.

E.2.3 Root account

E.2.3.1 Root password

E.2.3.2 No direct root logins

Consider not allowing root to directly log in over the network.
Instead, require first to log on as an ordinary user, then use sudo
or else su to root.

Reasons:

For accountability. This is particularly important if there
is more than one person who logs on to this computer.

It also makes an attacker do more work to get to root.

Secure terminals:
The relevant configuration file may be called /etc/ttys,
/etc/default/login,
/etc/security or
/etc/securetty depending on the system.
See the manual pages for file format and usage information.

Check that the secure option is removed from any local
entries that don't need root login capabilities. The secure
option should be removed from console if you do not want users
to be able to reboot in single user mode. [Note: This does not
affect usability of the su command.]

If it is not already the default, consider using a special group (such
as the wheel group on BSD systems) to restrict
which users can use su to become root.

E.2.4 PATH advice

Check that the current directory "." is not in the PATH.
Note that an empty string is interpreted to mean the same as "." so also make sure
the PATH does not contain any empty strings.
For example, the following PATH is insecure:/sbin:/bin:/usr/sbin::/usr/bin
This PATH advice is especially important for the root account.

Ensure that directories writable by other users are not
specified before system directories in a user's PATH, and check
that no files in the PATH of a user can be modified by other
users.

Do specify absolute path names when writing scripts and cron jobs.
(e.g. /bin/su, /bin/find, /bin/passwd.)
This is to ensure that even if scripts get run in an environment
with a different PATH, they can not be tricked into executing a
malicious program. One way to address this is explicitly to set the
PATH variable at the start of the script,
giving it a minimal list of directories.

Note: when using su, it is good practice to use the dash parameter, i.e.
"/bin/su -" to reset the environment.
While this does not give any significant protection if the user
account were compromised, it does prevent bad environment variables
from being unintentionally inherited by the privileged shell.

E.2.5 User session controls

Consider enforcing disk usage quotas on user accounts, by enabling
quota support for individual users or by using the resource-limits
PAM module where available.

Consider using the resource limiting features of a user's logon
shell to restrict the maximum memory/processes/CPU time used.
For sh style shells (sh, bash, ksh) use the ulimit command.
For csh style shells (csh, tcsh) use the limit command.

Evaluate the other facilities provided by your operating system
to put conditions on user logon access, limit remote access,
control user resource usage and enforce other policies on user
sessions such as logging/accounting. These features vary
significantly between different UNIX variants, so check the
documentation for your system.

Consider configuring user login sessions to log out automatically
after a certain period of inactivity, in particular for the root
user. To do this, set the appropriate variable in your shell's
startup files.
For csh: set -r autologout=15 (15 minutes)
For bash: typeset -r TMOUT=900 (15 minutes = 900 seconds)

E.3 Authentication

E.3.1 Password authentication

E.3.1.1 Evaluate two-factor authentication

Consider the benefit and cost of using one-time password sheets,
security tokens or smart cards instead of relying on reusable
passwords alone.

Passwords do not scale well in a network because lack of
trust between domains requires different passwords.
In practice this results in users either choosing bad passwords, reusing
passwords with multiple systems or companies, or writing them down.
The various forms of two-factor authentication offer an answer to this.

E.3.1.2 Shadow passwords

Most UNIX systems now use a shadow password scheme by default.
A few may not - see notes below. Using the shadow password scheme
is important because it ensures that the password hashes are not
world readable. This prevents simple dictionary and brute force
attacks being applied to get the passwords from the hashes.

Enable password shadowing if it is not on by default. See OS
specific footnotes for details.

E.3.1.3 Ensure all accounts have passwords or are disabled.

E.3.1.4 Password Policy

Have a clear password policy for your organisation. See the AusCERT
Advisory SA-93.04
for guidelines on developing password policies.

E.3.1.5 Enforce password complexity

Check if your operating system has a built-in way to configure
requirements on password complexity, such as minimum password lengths,
requirements for numbers and symbols, etc.

For PAM systems this can be done by a PAM module.
If your PAM enabled system does not have such a module, you can
use the pam_passwdqc module available from
http://www.openwall.com/passwdqc/ which supports
Linux, Solaris, FreeBSD and HP-UX.

For a multi-user system which does not have any mechanism for
enforcing difficult passwords, password auditing is discussed in
section J.7.3

E.3.2 One-time passwords

Evaluate the use of one-time passwords for remote connections.
In certain situations this mechanism can be more secure than
public key authentication or reusable passwords.

For example, a malicious trojan on a client machine can easily
capture passwords, secret keys and their passphrases to obtain ongoing
remote access to an account. In contrast, where one-time passwords
are used a trojan would have to hijack a legitimate session, and the
attacker will then have to go to more trouble to maintain ongoing access
to the compromised account.

Notes if using one-time passwords:

Generate the master key or password lists while logged on at the
console of a trustworthy machine.

Ensure users are aware they must not store password lists on or
near their computer.

Minimise the number of one-time passwords printed and given to
each user at any one time.

OPIE is a commonly used free implementation, available at
http://inner.net/opie
PAM modules implementing one-time passwords are also available.

E.3.3 PAM Pluggable Authentication Modules

On many UNIX systems, PAM is the main framework for authentication,
and will be operational by default.
PAM is provided by default on Linux, FreeBSD, Solaris, HP-UX and
AIX.

To find out if a given executable uses PAM, execute the
command ldd <path to executable file>. For example, the
resulting output for /usr/bin/login on a FreeBSD 6.x
system:

Depending on the system, PAM may be configured with the
file /etc/pam.conf or with individual configuration
files in /etc/pam.d/. PAM is very flexible and it is possible to
require more than one authentication method.

Check that PAM is configured to deny access by default - a
misconfigured service may result in an attempt to authenticate
using a less secure mechanism, or even no authentication at all.
If contemplating any change to the PAM configuration be careful that the
effect is understood, so as not to leave the system in an insecure state.

Enforce your password policy using PAM, as discussed in E.3.1

Consider enforcing user resource limits with PAM: This may be done
using the pam_limits.so module with configuration in
/etc/limits.conf where available.

E.3.4 NIS / NIS+

Do not use NIS. It is inherently insecure on an untrusted network.
It is for this reason and others that NIS was superceded by the more
secure NIS+.

Use LDAP instead to achieve the same goal of centralized directory
services. If only authentication is required, then Kerberos can be
considered as another alternative.

NIS+ is much more secure than NIS, but is only fully implemented on
a few UNIX variants. Sun has announced End of Feature status
for NIS+, and suggests that customers migrate to LDAP.

E.3.5 LDAP

LDAP is a protocol for accessing online directory services. In
the special case where LDAP is used to distribute authentication
data the security of the LDAP server and its configuration become
critical.

For authentication to the LDAP server itself consider using
client-side certificates or Kerberos. Alternatively, as a bare minimum
use SASL DIGEST-MD5 authentication.

Verify that communication with the LDAP server is protected by TLS,
so that data is not transmitted in the clear.

For the UNIX system's authentication data, if supported by the
LDAP server use SHA1 (preferably) or MD5 password hashes rather than
the weaker UNIX crypt hashes or plaintext passwords.

Ensure that LDAP access controls are correct for all attributes
that contain authentication credentials or other sensitive data.
In particular, password hashes should not be readable by other users,
whether authenticated or not.

E.4 Access Control

E.4.1 File Permissions

E.4.1.1 Permissions for key files and directories

Ensure that system configuration and runtime files are owned by root
and are not writable by other users. A few examples of such files are:

startup scripts (rc.* and init.d files),

any firewall configuration files,

/etc/profile, /etc/hosts.allow, /etc/mtab,

/etc/utmp, /var/adm/wtmp (or /var/log/wtmp),

/etc/syslog.pid (or /var/run/syslog.pid)

Ensure that log files (usually located in /var/log/ or
/var/adm) are only writable by root.

Ensure that the files holding the kernel and any kernel modules are
owned by root, have group ownership set to group id 0 and permissions that
prevent them being written to by any non-root users.

Ensure that there are no unexpected world writable files or directories on your
system. Use the find command to locate these, for examplefind / -type d -perm +2 -ls will locate world writable directories.

Ensure the sticky-bit is set on /tmp, /var/tmp and any
other world-writable directories that exist. This is often denoted by a "t" in the last column
of permissions when listing with ls -ld

Make a list of the non-root-owned directories outside of the user home area, usingfind / -path /home -prune -o -type d ! -uid 0 -ls
and ensure that there is nothing unexpected. In particular
/etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp
and /var/tmp should all be owned by root.

Some systems ship files and directories owned by user "bin" (or "sys").
This varies from system to system and may have security implications,
especially if filesystems are exported with NFS.
Change all non-setuid files and all non-setgid files
and directories owned by "bin" that are world readable but not
world or group writable to be owned by root instead, with group
ownership by group id 0.

Program configuration files in the home directory such as .vimrc and .exrc;

crontab and at entries;

scripts and programs on NFS partitions;

/etc/rc* and similar system startup and shutdown scripts.

If any programs or scripts run by these files use further programs or
scripts then those also need to be secure.

Do not allow any shell scripts to be SetUID.

E.4.1.3 Protect directories written to by root

The advice in this section also applies to protecting other daemon
or server accounts.

Any predictably named files created by scripts, daemons,
server processes, or cron jobs MUST be in a directory that is
non-writable by less privileged users and groups. This includes
directories used for logging.

Otherwise, a symlink attack may be used to escalate privileges
from unprivileged user to a more privileged one, such as root.

Scripts and programs that need to create files in a directory
writable by others, such as /tmp, must take
special precautions to create the file atomically.
If your organisation's system administration scripts need to use
temporary files, refer to the
Secure Programming for Linux and Unix HOWTO
for a discussion on doing this securely in shell scripts, Perl and C.

E.4.1.4 Group membership

There are two different schemes in use for arranging UNIX
groups, and these lead to different recommendations for
home directory permissions and umask.

1. Traditional group scheme
In this scheme most users belong to a common group by default,
such as the group "users".
This is the default on OpenBSD, Slackware, ...

2. User Private Group scheme
In this scheme a separate group is created in /etc/groups for
each user. The user should be the only member of that group.
This scheme makes working on group projects easier, as users do
not need to use the umask command when working in a common
project directory.
This is the default on FreeBSD, Red Hat, Debian, ...

Do not use the legacy feature of password protected groups.
It is insecure because the /etc/group file is not shadowed, so
hashes are world readable.

E.4.1.5 umask for users

A user's umask determines the default permissions on new files
created by the user. Note that unlike file permissions, the
umask shows which permission bits are not allowed, e.g. a umask
of 777 means no access.

Ensure the umask for each user is set to a restrictive value
within the user's shell startup scripts. The appropriate umask
will depend on whether a User Private Group scheme is used.
If the traditional group scheme is being used, ensure a
umask of 077 or 027 is set in the users' shell startup scripts.

A weaker umask of 007 is acceptable if the User Private Group
scheme is being used.

E.4.1.6 Permissions for user home directories

Ensure user home directories are owned by the user, and
are not writable by any other user or group.

If the traditional group scheme is in use, the group ownership
on home directories may be set to the common group, so
ensure that the directory is not group-writable.

If the User Private Group scheme is in use, the group ownership
on home directories should be set to the user's private group.

For either scheme, consider setting permissions on home
directories to 700 to prevent other people from viewing the contents
by default.

E.4.2 Filesystem attributes

Consider using file attributes if your operating system supports them.

E.4.4 sudo

The sudo utility is available for practically all UNIX variants and can
help minimise the need to use the root account.

For systems administered by more than one person, sudo can also be helpful
to split the power of root to some extent if full Role Based Access Control is
not available.

sudo allows users or groups of users to execute specific authorized
commands as another user, such as the root user. It requires unprivileged
users to enter their own user password in order to execute privileged commands.
This enables administrative tasks to be distributed among different users,
while limiting the distribution of the root password.

Also, sudo can be configured to log each access (or attempted access) to commands
by users, enabling some auditing of users' privileged actions.

Exercise caution when configuring sudo. Even if a user is only granted access
to execute one specific program with root privileges, if that program can
be made to spawn a shell or run other commands (e.g. many text editors can
do this), then the user can execute arbitrary commands as root using their
sudo access, and this usage may not be logged. It can be difficult to determine
which programs may grant unintended access or privilege escalation. This is why
permitting an extremely limited set of commands is preferable.

E.4.5 Consider mandatory access control features

Mandatory access control allows all accesses to data on the system to be
controlled by a site policy rather than user discretion.
Depending on which policy model is used, this can be aimed at preventing
an attacker from leaking confidential information from the system, or
at preventing an attacker from making unauthorised changes, even after
subverting software on the system.

Mandatory access control implementations usually also provide more
reliable and fine-grained auditing of access events.

Some operating systems offer mandatory access control and
data labelling as optional features.

Other operating systems instead have a separate "trusted"
version which implements these features.

Consider the benefits and costs of installing and enabling these
trusted operating system features if available. Note that some of these
controls may impact software compatibility and usability, so enforcing
these will not be useful to all organisations.

For systems where mandatory access control is enabled by default,
verify that the current configuration is the appropriate one for
your situation.

E.5 Other

E.5.1 Cron

Ensure that the permissions for root's crontab are set to 600 and
that the owner is set to root.

Consider not allowing regular users to add cron jobs.

E.5.2 Mount options

Choosing to use separate partitions as recommended in section B.3 now
allows flexibility for mount options.

Configure the mount options nosuid, nodev
and noexec for /var
and /tmp in your /etc/fstab
or vfstab file.

For user home partitions, use nosuid and
nodev and consider using noexec.

Mount external filesystems with the nosuid and
nodev options. This includes both removable media
such as CDs and USB drives as well as network filesystems. Consider also using
the noexec and read-only options for these filesystems
where practical.

F.1 Confinement

Server processes can be confined with reduced access to the system, so
that if the software misbehaves or is compromised the damage is limited.
The facilities available to do this vary on different UNIX systems.

F.1.1 Running under an unprivileged account

Ensure that services run under unprivileged accounts where possible.

Many services do this automatically, however some will run as root
by default and will need to be configured manually.

F.1.2 using chroot jails

chroot jails are the most common confinement mechanism, available
on almost all UNIX and Linux systems. The chroot(2) system call is
used to confine the daemon to a small subtree of the real filesystem
and it appears to that process to be the root directory. Any libraries
that the daemon requires will also need to be put inside the chroot
directory structure.

The software and files deployed within the chroot environment can
then be minimized to those only needed by that specific service.

Many daemons now have a built-in configuration option to chroot
themselves to a specified directory after starting, which is more
convenient than manually using the chroot command in a startup script.

Be aware that chroot is not foolproof - if an attacker is able to
gain root privileges within the chroot jail, then there are potentially
several ways they may break out.

F.1.3 Other confinement mechanisms

Several operating systems provide their own more advanced mechanisms
for confining processes. See the OS specific footnotes for details on
Solaris Containers and privileges, FreeBSD jails and SE Linux Type
Enforcement.

F.2 tcp_wrappers

The primary way to restrict accesses to the host's services by IP address
is to use a host firewall, discussed in section H.1. However, many UNIX and
Linux systems also provide a second control, in the form of tcp_wrappers.
This may already be in use on your system by default.

tcp_wrappers does provide some extra flexibility if needed; it can be
configured to require reverse DNS lookups or ident (RFC931) lookups,
allows automatic execution of scripts when conditions are met, and can
also provide improved logging for services that do not have adequate
access logs of their own.

There are two ways that tcp_wrappers may be used on the system:

It is possible to explicitly "wrap" a service, by running
the program tcpd to accept connections
which are then passed to the actual network service.

More commonly though, the vendor has already compiled
network services to use the libwrap library.
In this case the relevant daemon will enforce the tcp_wrappers restrictions
when accepting connections.

The main configuration file for tcp_wrappers is /etc/hosts.allow
Explicitly list host IPs which are allowed access to the services in this file.
At the bottom of the file put all:all:deny to
deny all other IP addresses. The rules in this file work on a
"first match wins" basis.

The file /etc/hosts.deny may also be used,
though this is no longer required.If /etc/hosts.deny
is present, put all:all in this file.

F.3 Other general advice for services

F.3.1 Configure services to listen on one interface only.

Instead of allowing services to listen on a wildcard network interface,
configure them to listen on only one specific IP address where possible.

If the service is only required for use on the local host, then it should
listen only on the loopback interface where possible, with address 127.0.0.1

F.3.2 Adding SSL to existing services

If this UNIX or Linux system provides services that involve sensitive data,
but the built-in encryption or authentication of the software is inadequate,
then consider using stunnel to secure these services.

stunnel is a free tool that can be used to add TLS (or SSL) authentication
and encryption capabilities to any existing client and server that
uses TCP. For example, it can be used to secure access to POP3, or to
secure an existing in-house application that communicates using TCP.

If required, client access to the wrapped service can also be
authenticated using client-side certificates.

stunnel packages may be available from the OS vendor, or otherwise
by downloading source from
http://www.stunnel.org/

F.4 SSH

Do not log in via SSH from an insecure workstation. Contrary to popular
belief, public key cryptography will not protect you in doing this.
Where SSH is used, a trust relationship is implied - the SSH server
computer trusts the security of the SSH client computer.

Be aware that when doing X-forwarding through SSH, the trust
relationship is also reversed - the workstation running the X display
must also trust the computer running each X program. This is due to
the cross-client X attacks described below in F.9.3

Suggested configuration options for the OpenSSH sshd implementation:

In the configuration file sshd_configdo use:

Protocol 2 (the SSH 1 protocol had weaknesses)ListenAddress 192.168.45.3 (bind to one address only)PermitRootLogin noListen 222 (consider using an alternate port)PermitEmptyPasswords noAllowUsers one two@host1 three

Disable other authentication options. In particular, do not use:

RhostsAuthenticationHostBasedAuthenticationRhostsRSAAuthentication (not good for accountability)

Where SSH is used by scripts, configure SSH on the server side to
allow execution of a certain single command only. This is achieved using a
command= directive in the authorized_keys file.

Many UNIX and Linux systems are compromised by attackers through SSH, by simply
using a dictionary attack on passwords.
It is strongly recommended to use public key authentication instead of passwords.
If password authentication must be used with SSH, verify that a strong
password policy is in effect, as described in E.3.1.

F.5 Printing

There are several different default printing systems supplied with
UNIX and Linux systems. The three most common of these are BSD style
lpr (also found on AIX), LPRng and CUPS.

In general, prevent the printing service from listening to the network
unless necessary for this computer's role.

If a network printing service is part of this computer's role,
then do not rely solely on IP addresses for authentication (for instance
the hosts.lpd file with lpd or LPRng is based
only on IP address.)

F.6 RPC/portmapper

Look for the specific facilities provided by your operating system
for securing RPC access with authentication and/or encryption. The
security features available vary greatly between UNIX variants.

Be aware that some older portmapper/rpcbind daemons may forward RPC
requests from remote hosts, and make them appear to come from the
localhost.

F.7 File services NFS/AFS/Samba

F.7.1 NFS

Filter NFS traffic at the router, blocking TCP/UDP on port 111 and
TCP/UDP on port 2049. This will help prevent machines not on the local
subnet from accessing file systems exported by this host.

Be aware of the trust relationships implied by the current NFS configuration,
to determine what impact an attacker may have if they compromised or
spoofed the identity of either the server or the client. This is particularly
relevant if NFS sessions are only being authenticated by IP address.

Configure NFS to use TCP rather than UDP. This is supported by all NFS 3
implementations.

Consider tunnelling NFS over SSH or stunnel to provide authentication
and encryption.

Configure statd, mountd and lockd to bind to a fixed port number if
possible so that configuring a host firewall is more straightforward.

Confirm NFS is configured to accept mount requests only from ports
less than 1024. This is configured by default on some NFS implementations,
and may be set by the 'secure' option on exports in others.

Verify that you run a portmapper or rpcbind that does not forward
mount requests from clients. With older portmappers a malicious remote
NFS client could ask the host's portmapper daemon to forward requests
to the mount daemon, which would then process the request as if it
came directly from the local host. If a file system is exported to
the local machine this then gives the remote client unauthorised
access to the file system.

Configure /etc/exports or
/etc/dfs/dfstab to export the minimum set of
file systems that need to be exported.

Export file systems read-only (-ro) whenever possible. See the
manual page for exports or dfstab for more information.

Check that any important exported files that clients should not be
able to modify are owned by root, and not owned by bin or any other
account.

Ensure that file systems are exported with the root_squash or
-maproot option, to map root to an unprivileged user. Without this,
an attacker controlling root on one of the clients will also be able
to access the server as root.

Confirm that no file systems are exported unintentionally to the
world. Invoke showmount -e to verify what
is currently being exported. If required, add -access=192.168.50.3
option or equivalent in /etc/exports to restrict access by IP.
If you must specify hostnames instead of IPs, then export to fully
qualified domain names only (i.e. use 'machinename.domainname.com'
rather than abbreviating it to 'machinename').

F.7.2 Samba

The Samba service provides filesystem and printer shares using the CIFS
protocol that is also used in Microsoft Windows.

If users in your environment authenticate to Active Directory for
other services, then consider pointing to the same AD server for
Samba authentication, settingsecurity = ADS
See the Samba HOWTO for further details on implementing this:
HOWTO

Otherwise, configure your shares for user-level security using thesecurity = user
parameter. In current versions of Samba this is the default.

Restrict access to the Samba service with the parameters:hosts allow =
hosts deny =

Protect the Samba services with firewall rules to ensure they
can not be accessed from hosts outside the local network. Samba uses
ports 137 and 138 (UDP) and ports 139 and 445 (TCP).

F.8 Email service

Check that your Mail Transport Agent (mail server software) is configured
not to relay mail from unauthenticated hosts. This helps to prevent your mail
server from being misused to send bulk spam. The open relay testing page at
http://www.abuse.net/relay.html
can assist in testing this.

F.8.1 Sendmail

On most UNIX and Linux systems the default MTA will be Sendmail. This
section provides configuration recommendations specifically for Sendmail,
though the same configuration goals can be applied to other MTAs.

If this computer is not a mail server, then:

Disable SMTP connections from other computers by addingAddr=127.0.0.1 to each DAEMON_OPTIONS macro that is in your config.
For example:DAEMON_OPTIONS(`Name=IPv4, Family=inet, Addr=127.0.0.1')
DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Addr=::1')
FEATURE(`no_default_msa')
DAEMON_OPTIONS(`Name=MSA, Port=587, Address=127.0.0.1')

Consider disabling the daemon mode altogether by removing the -bd
option from the startup script. This will still allow most local
Mail User Agents to invoke the sendmail binary to send mail.
In this case, do use a -q30m option to ensure queued outbound
messages are still processed.

If it is really necessary to relay mail from roaming users outside
your local address range, then configure Sendmail to require SMTP AUTH
for these connections.

In both cases:

If you do not require emails to be piped to other programs for processing
then disable prog mailer functionality withMODIFY_MAILER_FLAGS(`LOCAL', `-|')

If you do require piping email to programs, use smrsh to limit
the programs that can be executed to only those programs linked in the smrsh
configuration directory. This can be turned on with FEATURE(`smrsh', `/usr/libexec/smrsh')
(The location of the smrsh binary may vary on different systems.)

Consider setting sendmail logging to a minimum log level of 10.
This will help detect attempted exploitation of sendmail
vulnerabilities as well as logging each connection and the
username used in each SMTP AUTH. To do this use: define (`confLOG_LEVEL', `10')

/etc/mail/aliases
check that any programs executed from this file are owned by
root, have permissions 755 and are stored in the smrsh configuration
directory, e.g. /etc/smrsh

Remember that it is necessary to regenerate sendmail.cf
and/or *.db files and then restart sendmail for
any changes to take effect.

F.8.2 Mail server MTA choices

Sendmail is the most fully featured MTA software. On the other hand it
is also a large and complex program. The complexity leaves more scope
for security vulnerabilities through misconfiguration or software flaws.

If this computer accepts email from other systems, and Sendmail's extra
functionality is not required, then consider the benefits and costs of using
an alternative to Sendmail with a more simple and privilege-separated design.

qmail is a replacement for sendmail designed with security and correctness
as a primary goal, but implementing a more limited set of features. It is available at:
http://cr.yp.to/qmail.html

Postfix is another Mail Transport Agent that has been designed to
avoid common security problems. Postfix's homepage is:
http://www.postfix.org

F.9 The X Window System

F.9.1 Restrict access to the X server

Consider configuring workstations to disable listening
for incoming X sessions over the network. On many operating systems
this is done by using the -nolisten tcp
option in the script that starts the X server. Alternatively, on some
systems this may be set in the configuration file for xdm, gdm or kdm.

Use the X magic cookie authentication mechanism
MIT-MAGIC-COOKIE-1 or better. With logins under the control of xdm,
authentication can be enabled for all displays by editing the
xdm-config file to include the line
DisplayManager*authorize: true
This may or may not be the default on your system.

If granting access to the display from another machine, use
the xauth command in preference to the
xhost command.

Do not use host based access control. Remove all instances of
the xhost command from the system-wide
Xsession file, from
user .xsession files, and from any
application programs or shell scripts that use X.

F.9.2 Protect any X traffic

If X is used across the network, then encrypt and authenticate
all X network traffic. Using the X Forwarding feature of SSH is the
most straightforward way to achieve this. (See section F.4)

F.9.3 Avoid cross-client X attacks

Note that in most X servers there is little to protect one
X client program from another. This allows any X client program to
capture keystrokes and screenshots of other X client programs and
also to inject input to other programs.

Therefore if some X applications are less trusted than others,
consider the risk of this for your environment and separate the use
of applications appropriately.
For example, consider not typing the root password while in X,
instead using the console (or a separate logical X display).

Secure X servers included with B level trusted operating systems
such as Trusted Solaris are designed to eliminate this issue.

F.9.4 X display managers

If the system is configured to provide a graphical login screen,
the display manager (such as xdm, gdm or kdm) is the program that does this.

xdm may bypass the normal getty and login functions, which means
that quotas for the user, ownership of /dev/console
and possibly other preventive measures put in place by you may be ignored.

Desktop environments that are available for UNIX may provide
different X display managers (e.g. gdm from Gnome and kdm from KDE).

Ensure familiarity with the man pages for xauth and
Xsecurity. This information will be useful in configuring the security you
require. The chapter on X Window System security in the
X Window System Administrator's Guide is also a good reference.

F.10 DNS service

F.10.1 BIND

For most UNIX systems, BIND will be the default domain name server
software provided.

Turn off dynamic updates unless they are really required, for example
to support Active Directory.

Consider applying the security practices detailed in the
following documents:

F.10.2 DNS server choices

BIND is the DNS server software that provides the most comprehensive set
of DNS features. On the other hand it is also a large and complex piece of
software. The complexity leaves more scope for security vulnerabilities
through misconfiguration or software flaws.

If BIND's extra functionality is not required, then consider the benefits
and costs of using an alternative with a more simple design such as djbdns.

djbdns is a set of DNS server software designed with security as a
primary goal, but implementing a more limited set of features. It provides
separate programs for the DNS cache and DNS server roles. djbdns is available at:
http://cr.yp.to/djbdns.html

F.11 WWW service

F.11.1 General configuration

Consider running the web server in a chroot jail (see section F.2.1).
Some systems supply the web server in this configuration by default.
Example steps for chrooting Apache on Linux and Solaris can
be found at
http://penguin.triumf.ca/chroot.html. A simpler way to chroot
Apache is now provided by the mod_security's SecChrootDir
option, as described
here.

Consider configuring the web server to disallow
automatic directory listing if an index.html file is
not present in the directory.

Consider configuring the web server to not follow
symbolic links. This prevents a user with access to
the web server's document tree from making other
documents, outside the tree, available via symbolic
links.

Consider running the web server on a dedicated computer that is
not relied on for other services.

F.11.2 Web applications

This section applies to dynamic web content including all web applications,
CGI and server-side scripting languages such as PHP, Perl or Python.

If using ready-made web applications such as content management systems,
portals or discussion forums, be careful in choosing high quality software
and be especially vigilant in keeping these up to date. Known vulnerabilities
in PHP web applications are some of the most common ways that UNIX and Linux
web servers are compromised.

Ensure that any default or example scripts included with an application
of framework are removed if not needed.

Consider monitoring changes to scripts and web applications using a
file integrity checking program such as Tripwire. (See section G.5.1)

For any web site developed in-house or by contract, ensure all
developers doing web programming understand the specific issues of secure web
programming. In particular the OWASP Guide to Building Secure Web Applications,
available at
http://www.owasp.org/index.php/OWASP_Guide_Project is indispensible.

Set minimal filesystem permissions, especially on the directories
containing scripts. The permissions required by different applications and
frameworks vary. Preferably the unprivileged account running
the httpd should not have permission to write to the script area.

F.11.3 TLS / SSL

Use TLS (Transport Layer Security) or its predecessor SSL
(Secure Socket Layer) to provide authentication and encryption
where appropriate.

Confirm that sensitive form data is not submitted unencrypted.

Confirm that the private key file can not be read by the
unprivileged account that the httpd process runs as (usually www or nobody).

SSL version 2.0 is insecure and should be disallowed.

For logon pages, it is recommended to use SSL not only for the
form submission, but also for the logon page itself, as this makes
it easier to instruct users not to submit their password to an
unauthenticated site.

F.11.4 Static-only webserver

If serving static pages is all that is required, consider running
more cut-down and minimal web server software.

F.12 Squid proxy

Avoid providing an open proxy
Configure access controls so that only authorised clients can
make requests through the proxy.

Note that Squid ACLs use the first rule that matches. If none match,
the last rule checked is used inverted. So to avoid unintended access
it is best to put a catch-all deny rule last:http_access deny all

Listen on a single interface
If this computer has more than one network interface, specify the
interface's IP address with a configuration line:http_port 192.168.0.7:8080
to cause squid to only listen on that interface.

Disable unused protocols
If you are not using the inter-cache and management protocols,
then turn them off by setting the port to 0, as in the following
configuration lines:snmp_port 0
htcp_port 0
icp_port 0

Deny proxy to localhost
To ensure that a remote attacker cannot connect to other ports on
the local computer via the Squid proxy, include access rules similar
to the following:acl to_localhost dst 127.0.0.1/8
deny to_localhost

Secure squid files
Check that squid logs and cache files are not world readable.
These can contain data from proxy users that should remain
confidential.

F.13 CVS

Use SSH to authenticate and encrypt all CVS access.

Do not use CVS pserver functionality.

Create a UNIX account on the computer for each CVS user, and limit
their SSH session so it is only able execute the command "cvs server".

Why this provides better security than cvs pserver:

cvs does not need to run as root

Access control is enforced by the operating system, not by cvs.

Be aware that CVS access control is per-directory, rather than per-file.
(The CVS manual in section 2-2-2 describes the access control model.)

Use LockDir in CVSROOT/config
to have read only directories where appropriate.

F.14 Web browsers

Do not allow external programs to spawn automatically for any
type of downloaded content. This includes not allowing browsers to
automatically launch multimedia viewers, shells, script interpreters
or macro processors.

Instead configure the browser to prompt before opening external
programs. This can be achieved using the helper application
preferences for the browser.

Consider disabling Java and JavaScript in the web browser.

Do not run a web browser as root.

F.15 FTP service

Do not run an FTP service unless there is no alternative.

If the purpose is to provide unauthenticated access or public
access it is better to use a simple HTTP server such as publicfile
(see section F.11.4).

If authenticated access is required, it is better to use sftp.
An sftp server is included as part of OpenSSH, which is available
either as packages from your OS vendor, or as source from
http://openssh.com/. Several free
graphical clients are available to support Windows users, including
WinSCP (http://winscp.net/).

F.15.1 General configuration

Ensure that your FTP server does not have the SITE EXEC
command, or that this command is disabled correctly.
Test with:

% telnet localhost 21
USER username
PASS password
SITE EXEC

If it is correctly disabled, you should receive an error response like500 'SITE EXEC' command not understood
Then type QUIT to end the session.

Ensure that you have set up the file /etc/ftpusers.
This file specifies those users that are not allowed to connect to your ftpd.
This should include, as a minimum, the entries: root, bin, uucp, ingres,
daemon, news, nobody and ALL vendor supplied accounts.

Use chroot to confine the ftp daemon. (See section F.1.2)

Check all default configuration options on your FTP server.
Not all versions of ftp daemons are configurable. If you have a
configurable version of ftp (e.g., WU-FTP) then make sure that
all delete, overwrite, rename, chmod and umask options (there may
be others) are not allowed for guests and anonymous users.
In general, anonymous users should not have any unnecessary
privileges.

Ensure there are no shells, interpreters or system commands in
~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directories.
It may be necessary to keep some commands, such as uncompress,
in these locations. Consider the inclusion of each command on a case by
case basis and be aware that the presence of such commands may
make it possible for local users to gain unauthorised access. Be
wary of including commands that can execute arbitrary commands.
For example, some versions of tar may
allow you to execute an arbitrary file.

Ensure that you use an invalid password and user shell for
the ftp entry in the system password file and the shadow password
file (if you have one). It should look something like:

ftp:*:400:400:Anonymous
ftp:/home/ftp:/bin/false

where /home/ftp is the anonymous FTP area.

Set the permissions of the FTP home directory ~ftp/
to 555 (read nowrite execute), and check that this directory is owned
by root (ftp).

Make sure that you do not have a copy of your real
/etc/passwd file as
~ftp/etc/passwd. Create one from scratch
with permissions 444, owned by root. It should not contain the names
of any accounts in your real password file.
It should contain only root and
ftp. These should be dummy entries with disabled
passwords e.g.:

root:*:0:0:Ftp maintainer::
ftp:*:400:400:Anonymous ftp::

The password file is used only to provide uid to username
mapping for ls listings within ftp.

Make sure that you do not have a copy of your real
/etc/group file as
~ftp/etc/group. Create one
from scratch with permissions 444, owned by root.

Ensure the files ~ftp/.rhosts and
~ftp/.forward do not exist.

Set the login shell of the ftp account to a
non-functional shell such as /bin/false.

Ensure no files or directories are owned by the ftp
account or have the same group as the ftp account.
If they are, it may be possible for an intruder to replace them with a
trojan version.

Ensure no files or directories in the FTP area are world writable.

Ensure that the directories ~ftp/etc and
~ftp/bin are owned by root with permissions 111.

Ensure that any files in ~ftp/bin are
owned by root with permissions 111.

Ensure that files in ~ftp/etc are
owned by root with permissions 444.

Ensure that there is a mail alias for ftp to avoid mail bounces.

Ensure the mail spool file for the ftp daemon account is owned by
root with permissions 400. (Depending on the system this will be
in a location such as /var/mail/ftp or
/usr/spool/mail/ftp )

Never mount disks from other machines to the ~ftp hierarchy
unless they are mounted read-only.

F.15.2 Anonymous FTP

To ascertain whether you are running anonymous FTP, try
to connect to the localhost with username "anonymous",
and give a well formed email address as the password.

To disable anonymous FTP, move or delete all files in ~ftp/
and then remove the "ftp" user account from the system.

Ensure that if you want to use anonymous FTP you have
configured your server correctly. In general, anonymous users
should not be allowed to create directories, delete anything,
change the file system in any way (for instance change the
permissions of a file) or upload files. If you intend to allow
anonymous users to upload files, read the section below about
upload directories.

Limit the number of anonymous connections allowed, and
also the number of times a single IP can be logged in at once.
Anonymous users should only be allowed to have one session active
at a time - otherwise you make a DoS attack easier.

Verify that the anonymous ftp user account can only read
information in public areas.

F.15.3 Upload directories

Preferably, check that you do not have any writable directories as
this is safest. If you must have writable directories to allow upload,
we recommend that you limit the number to one, for instance an 'upload'
directory.

Ensure that the writable directory is not also readable.
Directories that are both writable and readable are likely to be
misused.

Check that any writable directories are owned by root and have
permissions 1733. (note sticky bit set)

Put writable directories on a separate partition if possible.
This will help to prevent denial of service through disk exhaustion.

DISCLAIMER: We recommend you consult your organisation's security and
privacy polices, as well as any laws for your area before implementing any
of the suggestions in this section.

G.1 syslog configuration

Consider using syslog's remote logging feature to send logs to a
separate logging computer.
Remote logging ensures that even if the UNIX system is compromised,
attackers cannot simply modify the log files to cover their tracks.

Consider protecting the network logging stream with authentication and
encryption, for example by tunnelling it over SSH with netcat.

If logging over the network, do log to local files as well.

Unless this computer is a log server, ensure that syslog will not
accept incoming log packets over the network. On some systems this is
the default. On others it may be implemented by starting syslog with
the -t option (nolisten).

Consider increasing the level of logging provided by syslog.

Make sure that the messages of the LOG_AUTH
facility at level LOG_INFO and above get logged.

For email, enable a minimum level of "info" for mail messages to be
logged by syslog.

Check that there is a reliable mechanism for log rotation. If there
is not, you may need to replace an existing logging daemon with a more
secure or full-featured one.

Check that all login attempts are logged, both successful and
unsuccessful. There may be several different ways to log in, such as
at the console, through X and through SSH.

Consider protecting your log files with filesystem attributes if
possible, to make them append-only. See section E.4.2 for details.

G.2 Monitoring of logs

G.2.1 Process for log monitoring

Logs and audit trails are only of limited use unless people are
actively monitoring them. Decide on a specific time period
within which people will monitor the logs.

Consider automatically emailing logs or log extracts to the
internal email addresses of the relevant people. Check that
the sensitivity of information contained in the logs is
appropriate to distribute this way.

G.2.2 Automated log monitoring tools

Automated tools cannot replace human judgement, but they make
the process of people monitoring the logs much more efficient by
providing different filtered and processed views on the logs,
and alerting automatically based on defined patterns.

Automating to some degree is highly recommended as otherwise it
is unlikely that the human component of the log monitoring task
will actually be done.

Two example programs are swatch and logsentry. Further information
on log monitoring and available tools is available at
http://loganalysis.org

Ensure any automated reporting facilities provided by your
operating system are turned on, and are sending output to an
appropriate user for reading. (e.g. FreeBSD / OpenBSD daily scripts)

Regularly monitor logs for both successful and unsuccessful logins,
and uses of su and sudo.

Regularly check for repeated access failures.

G.3 Enable trusted audit subsystem if available

On many platforms a more comprehensive audit subsystem is optionally
available. The benefit is to allow more dependable and configurable
logging of a wider range of security events.

Enable the trusted system audit features if available for your platform.

For some commercial UNIX variants, specialized server monitoring tools
are also available from the vendor.

G.4.2 Process accounting

Consider turning on process accounting, if available for your system.
Process accounting allows the kernel to keep records of each command
run, the user and the time, exit codes, as well as what amount of
system resources (CPU, memory, disk I/O) were used.

Check that process accounting log files are owned by root and have
permissions 600.

G.4.3 lsof

lsof is a tool for monitoring open system files that can be useful
in checking current activity on the system. lsof may be included
with your operating system, and is also available from the source at
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/

G.5 Host-based intrusion detection

G.5.1 File integrity checker

Have a system administration procedure in place to check and
update the database at least weekly to reflect legitimate changes.
Without this any real security alerts may be lost amidst the
noise of legitimate changed files.

Consider storing the integrity checker binary, its database and
configuration file on hardware write-protected media, and using a
binary that is statically linked.

Consider running the integrity checker from a bootable CD. This
is the most tamper-proof option, but is not appropriate in many
cases because it involves downtime while the check is run.

G.5.2 Antivirus / malware detection

Antivirus products that run on UNIX systems are often aimed at
detecting Windows malware that passes through a UNIX email or
file server. However several companies also produce antivirus software
specifically targeting known UNIX malware.

In particular where UNIX is deployed on desktop workstations,
consider the use of antivirus / malware detection software to
detect content-based attacks on the clients.

Depending on the operating system, free tools may also be available
to check for known trojaned binaries or malicious kernel modules that
may be installed by an attacker after compromising the system. The
chkrootkit tools available from www.chkrootkit.org
are able to detect some of the most common rootkits. Chkrootkit runs on
Linux, *BSD, Solaris, HP-UX and Mac OS X.

G.6 Network intrusion detection

G.6.1 Signature matching IDS

Snort is one open source network IDS which performs real-time traffic
analysis and packet logging. It can use protocol analysis and content
searching/matching to detect a variety of known attacks, based on
configured signatures. Snort is available at:
http://www.snort.org/

Do not run a signature matching network IDS tool or protocol
analyser in promiscuous mode on the server itself. Instead use a
separate computer/device. This protects your server and network from
vulnerabilities in the IDS software itself.

Consider connecting the IDS to the network to be monitored via a
read-only network tap or a spanning port on the switch.

G.6.2 ARP monitoring

Consider using an ARP monitoring tool to detect ARP spoofing attacks
within your LAN.
One such tool is arpwatch, available at
http://www-nrg.ee.lbl.gov/

H.1.2 Design host firewall

Do not assume that there is an internal network whose
computers are trusted.
The point of the host firewall is to ensure that when one of the
other computers on your internal network is compromised, and the
attacker is then able to launch attacks directly from the local LAN,
they will still be unable to contact all of the services on this
computer. Therefore, design the host firewall by assuming that the
internal computers are already compromised, and may seek to attack this
system.

Restrict incoming network connections to the minimum set of
TCP/UDP port numbers required for this computer's role, as determined
in section A.6

Consider also restricting outgoing connetions to the minimum set of
destination port numbers required for the computer's role. If this
computer is compromised, this can make it more difficult for
(the less sophisticated) malicious software to connect back out to
an attacker to receive instructions.

Where a service on this computer only needs to communicate with specific
hosts, consider making this explicit in the firewall rules, restricting
that port number to only communicate with the specified hosts.

Ensure that the following ports can NOT be accessed over the network:

TCP port 25 (SMTP, unless this host is a mail server),

UDP and TCP port 111 (portmap),

TCP port 587 (mail submission agent)

TCP ports 6000-6010 (the X Window System),

and any other services that are for use on the local computer only.

If the IPv6 stack on this computer has not been disabled, then verify that
the firewall rules correctly handle IPv6 packets coming from the local LAN.
Some firewall configurations ignore IPv6. Even on an IPv4 network this may give
unintended access if the attacker already controls another point on the LAN.

Packet filtering can be difficult to implement correctly. For more
information on firewalls and packet filtering, the following
references may be of use:

H.1.3 Weak end system

For computers with more than one network interface, be aware of the
"weak end system" model used by most UNIX operating systems (RFC1122).
This means that on hosts with more than one network interface, even if a
service only binds to the IP address of one interface, this will
not protect it from packets that are received on a different
interface but addressed to that IP.

This is particularly important where second network cards are used to
provide a separate management network.

To address this, either:

Turn off weak ES behaviour (see OS specific footnotes) or,

add explicit host firewall rules to block packets coming into one
interface but addressed to the IP address of another interface.

H.2 Position this computer behind a border firewall.

Position the UNIX system on a protected subnet, with at least a
separate firewall device sitting between it and the open Internet.

H.3 Network stack hardening/sysctls

The kernel's network settings can be tuned and made more secure,
usually using the sysctl command or configuration file. The details
of how to do this are very specific to each operating system.
It is recommended to check the following settings:

Disable IP source routing.

Disable ICMP redirects.

Disable forwarding/routing of IP packets unless this computer is a
router. See OS specific footnotes for details.

If your OS provides syncookies to mitigate SYN-flood denial of service,
then ensure that this feature is turned on. Syncookies are available
on Linux, Solaris and FreeBSD.

Consider configuring shorter state timeouts and increasing the size of
state tables to make the system more resistant to denial of service.

For servers, consider configuring a static IP address on the host
itself, rather than using a static IP allocation through DHCP.

On critical computers, consider using a static ARP cache to prevent
ARP spoofing attacks from the local LAN.

H.4 Connect to network for the first time

I.1 Backup/rebuild strategy

When an intrusion or suspected intrusion is detected, your options in
responding will depend critically on whether you have an effective
backup/rebuild strategy in place beforehand.

With a rebuild process that is largely automated, it is possible to
either swap in a new hard disk and rebuild the server, or rapidly deploy
a replacement server, allowing the compromised machine to be taken
off the network quickly while maintaining uptime.

This ability to disconnect the computer rapidly reduces the risk of
further intrusion to other systems, and at the same time preserves
evidence on the hard disk at an early stage. But it depends on an
effective restore and rebuilding process already being in place.

Depending on the uptime requirements determined in section A.4 for
this system, consider whether a replacement hard disk or a full
replacement server is appropriate for your situation.

Protect the confidentiality and integrity of the backups themselves,
as the information in the backups is usually as sensitive as the
original system. For example, the authentication information in the
backup is often sufficient to compromise the original system remotely.
For integrity, the aim is that an attacker compromising this system
can only alter future backups, and not past backups.

I.2 TEST backup and restore

The implementation of the restore/rebuild system is not complete until
it has been tested out in practice.
Schedule a full restore/rebuild of the system to verify that the
process works and is sufficiently fast.

I.3 Allow separate restore of software and data

Consider having business data backed up and restorable separately from
executable programs.

After a compromise, this allows more flexibility, for example to
restore today's data but with the system and software backup from
three weeks ago.

I.4 Repatch after restoring

Repatch the system immediately after restoring from backup, to ensure
that all the patches and software updates released between the time that
backup was made and the present are applied.

I.5 Process for intrusion response

After an intrusion or suspected intrusion has taken place, it may be
necessary to liaise with law enforcement, and/or investigate what
has happened, and determine if other systems on your network have
been affected.

I.5.1 Documented process

Have a documented response process in place before any incident
occurs.

If it is decided that police investigation is desirable, it is
recommended to contact law enforcement at the earliest possible
stage in the process, and to coordinate any actions with them first.

As part of your process, record in writing any steps taken in
investigating an incident.

It is usually important to determine how the attacker broke in, since
if you clean and restore the system without knowing this then the
attacker may simply re-enter the system via the same vulnerability.

I.5.2 Forensic tools

Any investigation is best done on a forensically sound image
of the affected hard disk, rather than on the original disk.
If law enforcement involvement is desired, then it is recommended to
leave the disk imaging to law enforcement, and to avoid altering the system
in any way before this is done.

In other cases, consider having the capability to make a forensically
sound image of an affected hard disk, using dd or similar tools on a
second, clean system. This will require having spare hard disks available
ahead of time to create the image.

I.5.3 Malware detection tools

For some incidents it may be useful to apply known-malware detection
as described in section G.5.2 as a quick way to confirm that the
system was compromised. Of course, a failure to detect known malware
does not indicate that the system was clean.

J.2 Software inventory

Maintain an up-to-date list of software installed on each system,
with version numbers. This list includes the base OS and each piece
of third party software.

This is significant, as when a vulnerability advisory is released, it is
easy to check whether the versions on your systems are affected.

J.3 Rapid patching

The window of time between vulnerabilities being publicly announced
and widespread exploitation is now very short. Design your patching and
update process aiming to allow critical patches to be applied within
48 hours of patch release.

For important systems, maintain a test environment where patches can
be trialled first before deploying to production systems.

Be aware that installing patches/updates can sometimes re-enable
services that you have disabled.

J.4 Secure administrative access

J.4.1 Strongly authenticated access only

Only administer the computer at the console, or else over the
network using tools that are properly encrypted and authenticated,
such as SSH or a web interface protected by SSL. Do not assume
that a corporate internal network is secure.

J.4.2 Administer only from a secure workstation

Ensure workstations used to administer a UNIX or Linux server are
as least as secure as the server itself. Otherwise keystroke logging
can steal your SSH private key passphrase and all administrative
passwords. Public key cryptography will not protect against this.

Consider allocating system administrators two separate workstations,
one for administering the systems, and the other for general work
such as email, web browsing and document creation.

J.5 Log book for all sysadmin work

Maintain a log book to record all significant system administration
work on the system.

J.6 Configuration change control with CVS

Consider using a CVS server on a separate computer to manage the
configuration files such as those in /etc and
/usr/local/etc. This also makes rebuilding the
system more efficient.
See section F.14 for secure use of CVS.

J.7 Regular audit

Design and put into action a process to re-assess the security of the
system at regular intervals.

J.7.1 Re-apply this checklist

Periodically re-check the system against this checklist, and
ensure that the system is still in conformance with your security
policy.

In particular, re-check at this time that the software installed
is only the minimal set decided on.

J.7.2 Check for dormant accounts

Regularly audit the system for dormant accounts and disable any
that have not been used for a specified period of time, in
accordance with your site's security policy.

At this stage also audit the password files for unauthorised
additions or inconsistencies.

J.7.3 Audit weak passwords

Where appropriate, consider regularly applying a password
cracking program such as "John the Ripper" to check for weak
passwords.

This is especially worth considering for a multi-user
system which does not have any mechanism for enforcing difficult passwords.
John the Ripper is available from: http://www.openwall.com/john/

J.7.4 Apply network scan/audit tools

Use network port scanning and vulnerability scanning tools
from a separate computer to check periodically that open network
ports are as expected, and that no well known vulnerabilities are
detected.