UNIX and Linux Security

Checklist v3.0
AusCERT public release
2007-07-25

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.

Contents
1. A. Determine Appropriate Security
2. B. Installation
3. C. Patch and Update
4. D. Minimise
5. E. Secure Base OS
6. F. Secure Major Services
7. G. Add Monitoring Capability
8. H. Connect to Net
9. I. Test Backup/Rebuild Strategy
10. J. Maintain

1. References

A. Determine Appropriate Security

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.

More formal risk management frameworks are available to assist

with this, such as OCTAVE (http://www.cert.org/octave).

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

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

Installation - general notes: Solaris, HP-UX, AIX

C. Apply all Patches and Updates

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:

1. from a CD containing the patches, or

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

For those operating systems that do not come with an MD5

tool, a free implementation is available at
http://www.fourmilab.ch/md5

Red Hat / Fedora, Solaris

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).
Patching - general notes: HP-UX

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

FreeBSD, AIX

D.1.2 Minimise inetd/xinetd

• If none of the services in the inetd configuration are needed

then disable inetd completely,
• Otherwise, disable all non-needed services in the
configuration.

Solaris, HP-UX

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.
• Remove or disable tftpd
Do not use tftpd (trivial file transfer protocol) unless
unavoidable.

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.

Solaris, AIX

D.2 Disable all unnecessary startup scripts

The way startup scripts are used to start services when the system
boots is different on different variants of UNIX. See your vendor's
documentation for specific details.

On BSD style systems, the file rc.conf or rc.conf.local can be edited

to change which services will be started. Some systems have further
startup scripts located in /usr/local/etc/rc.d/

On System V style systems, the services to be started each have a

script with an entry under /etc/init.d or /etc/rc.d/init.d

Use ps at this stage to view the processes running by default.

Understand the purpose of each process and disable it in the startup
scripts if it is not needed.

Solaris, AIX

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)
• add the users who must use this program to the new group.

Never allow SetUID shell scripts.

Debian, Solaris OpenBSD

D.4 Other minimisation

If a graphical user interface is not required on this computer then

consider not installing the X window system, as well as desktop
environments such as CDE, Gnome and KDE.

The reason is that these are large, complex software systems with
components that must run with privileged access to the computer's
hardware.

If IPv6 is not being used, then consider also turning off the IPv6
stack.

OpenBSD

Minimise - general notes: Solaris, HP-UX, AIX

E. Secure Base OS

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.

Solaris, HP-UX, FreeBSD, OpenBSD

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.

Consider requiring that users physically identify themselves before

granting any requests regarding accounts (e.g., before creating a
user account or resetting passwords).

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.

IRIX

E.2.3 Root account

E.2.3.1 Root password

Restrict the number of people who know the 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:
 1. For accountability. This is particularly important if there is
more than one person who logs on to this computer.
2. 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)

HP-UX, FreeBSD, AIX

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.

HP-UX, AIX, IRIX

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

Verify that all accounts have passwords. (i.e. the password field is
not empty) Check NIS+ passwords too, if you have them.

Debian

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

HP-UX AIX

E.3.1.6 Password ageing and password history

Consider enforcing password aging, so that users will need to
change passwords after a certain maximum period of time.

• Be aware that using too short a change period will probably

just result in users circumventing policy by writing passwords
down.
• Consider enforcing a password history, so that users do not re-
use recently used passwords.
• Note that if using a history, a minimum period between
password changes may also be necessary, so that people do
not rapidly cycle through passwords to get around the
history/ageing restrictions.

HP-UX

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:

% ldd /usr/bin/login
/usr/bin/login:
libutil.so.5 => /lib/libutil.so.5 (0x28077000)
libpam.so.3 => /usr/lib/libpam.so.3 (0x28083000)
libc.so.6 => /lib/libc.so.6 (0x2808a000)

Note the libpam.so.3, this shows the program is linked with PAM.

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.

Linux, Solaris, OpenBSD

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 example
find / -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, using
find / -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.

Solaris

E.4.1.2 Protect programs used by root

Any binary that might get run as root, as well as all parent
directories of that binary, must be owned by root and also not be
writable by any other user or group. This means:

• any program used by system startup scripts

• any program used by daemons
• any program used in root cron jobs
• any program in root's PATH
• any program used in root's shell startup scripts
• any program executed in turn by the programs above.
o as well as all parent directories of these programs.
Ensure that root's PATH is secure, as described in section E.2.4.

Ensure root's login files do not source any other files not owned by
root or which are group or world writable.

Ensure root cron job files do not source any other files not owned by
root or which are group or world writable.

Check the contents of the following files for the root account. Any
programs or scripts referenced in these files should have the
permissions recommended above:

• ~/.login, ~/.profile, ~/.bashrc, ~/.cshrc and similar shell

initialization files;
• ~/.logout and similar session cleanup files;
• 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.

HP-UX

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.

• system binaries and key configuration files can be made

immutable,
• log files can be made append-only.

Linux, FreeBSD

E.4.3 Role Based Access Control

Consider using Role Based Access Control (RBAC) to split the role of
root, if available for your system. (See OS specific footnotes)

This reduces the risk of a frequently used all-powerful root account

that can control the whole machine if compromised.

In an environment with multiple system administrators, RBAC can

also give the ability to split administration powers among several
people if desired.

Linux, Solaris, HP-UX, AIX

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.

Linux

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.

AIX

E.5.3 Non-execute memory protection

Install and turn on non-executable stack protection if available for

your operating system. This makes buffer overflow bugs more
difficult for attackers to exploit.

Some implementations also provide non-execute protection for

other memory regions such as the heap, or provide broader
protection ensuring that memory regions are not both writable and
executable.
Solaris, HP-UX, AIX

E.5.4 Umask for startup scripts

Ensure that any startup scripts use a umask of 022 or better. This
should already be the case for vendor-supplied startup scripts.

E.5.5 .netrc files

~/.netrc is a file used by ftp and by rexec to automate file transfers

and remote execution.

Do not use .netrc files. Instead use SSH and scp, or rsync over SSH if
automated file transfers or execution are required.

Secure Base OS - general notes: Linux, Solaris, HP-UX, FreeBSD,

OpenBSD, AIX

F. Secure Major Services

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.

Linux, Solaris, FreeBSD

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.

HP-UX

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_config do use:

Protocol 2 (the SSH 1 protocol had weaknesses)

ListenAddress 192.168.45.3 (bind to one address only)
PermitRootLogin no
Listen 222 (consider using an alternate port)
PermitEmptyPasswords no
AllowUsers one two@host1 three

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

RhostsAuthentication
HostBasedAuthentication
RhostsRSAAuthentication (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').

Solaris

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, setting
security = ADS
See the Samba HOWTO for further details on implementing this:
HOWTO

Otherwise, configure your shares for user-level security using the

security = user
parameter. In current versions of Samba this is the default.

Require at least NTLM2 authentication as a bare minimum, with

lanman auth = no
ntlm auth = no
restrict anonymous = 2
guest ok = no

Consider using stronger client authentication methods. Samba

supports better authentication through Kerberos or Pluggable
Authentication Modules (PAM).

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 adding

Addr=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 this IS a mail server, then:

• Ensure familiarity with Sendmail access control and anti-spam

control features. See
http://www.sendmail.org/m4/anti_spam.html for an overview.

• 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 with
MODIFY_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:

Secure BIND Template By Rob Thomas

http://www.cymru.com/Documents/secure-bind-template.html

Securing an Internet Name Server By Cricket Liu

http://www.linuxsecurity.com/resource_files/server_security/securing
_an_internet_name_server.pdf

Chroot-BIND HOWTO By Scott Wunsch

http://www.losurs.org/docs/howto/Chroot-BIND.html for BIND version
9.x or http://www.losurs.org/docs/howto/Chroot-BIND8.html for BIND
version 8.x.

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

Apache is the most common web server on Unix systems. If you are
using Apache, implement the security recommendations outlined in
http://httpd.apache.org/docs/misc/security_tips.html

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.

The most common vulnerabilities exploited are listed in the OWASP

Top Ten at http://www.owasp.org/index.php/OWASP_Top_Ten_Project

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.

publicfile is a simple, read-only HTTP and FTP server designed with

security as a primary goal. It is available from:
http://cr.yp.to/publicfile.html

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:

1. cvs does not need to run as root

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

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

HP-UX

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.

Ensure that the anonymous ftp user account cannot create files or
directories in ANY directory unless required.
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.

G. Add Monitoring Capability

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.

OpenBSD, AIX

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.

Linux, Solaris, HP-UX, AIX

G.4 Monitor running processes

G.4.1 Availability of servers

Do actively monitor the running status of server processes on your

machines - tools are available that make it possible to do this
remotely. Some examples of these are:

• Argus system monitoring software http://argus.tcp4me.com/

• Big Brother http://www.bb4.org
• Nagios http://www.nagios.org/

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.

Regularly monitor process accounting log files for activity of interest.

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

Consider using a file integrity checker for intrusion detection,

providing monitoring for unexpected filesystem changes.

When using a 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.

An example file integrity checker is the open source Tripwire,

available from http://sourceforge.net/projects/tripwire/
AIX, Solaris

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.

Host-based intrusion detection - notes: HP-UX

G.6 Network intrusion detection

G.6.1 Signature matching IDS

Consider deploying a signature matching network intrusion

detection system, aimed at detecting attempted and successful
network attacks.

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/

Monitoring - general notes: OpenBSD

H. Connect to Net

H.1 First put in place a host firewall.

H.1.1 Identify host firewall software

Most UNIX operating sytems provide a packet filtering host firewall

system, either as part of the base install, or as an option you can
install.

On a minority of systems, a reasonable host firewall is already

configured by default on newly installed systems, though this can
usually be tightened further.

Linux, Solaris, HP-UX, FreeBSD, OpenBSD, AIX, IRIX

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:

Internet Firewalls FAQ

http://www.interhack.net/pubs/fwfaq/

Building Internet Firewalls, Second Edition

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:

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

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

Solaris, FreeBSD

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.

Linux, Solaris, HP-UX, FreeBSD, OpenBSD, AIX

Further information on adjusting network parameters is provided in

the following documents:
UNIX IP Stack Tuning Guide v2.7 (Rob Thomas) - covers AIX, Solaris,
HP-UX, Linux, FreeBSD and IRIX.
http://www.cymru.com/Documents/ip-stack-tuning.html

TCP/IP Stack Hardening - covers AIX, FreeBSD, HP-UX, Linux, Solaris

and IRIX.
http://www.cromwell-intl.com/security/security-stack-hardening.html

H.4 Connect to network for the first time

It is recommended to connect the computer to the network for the

first time at this stage.

I. Test Backup/Rebuild Strategy

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.

Implement a backup, restore and rebuilding process that satisfies

your security policy.

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.
One suggested response procedure is described in the document
Steps for Recovering from a UNIX or NT System Compromise Your
procedure should be tailored to meet your specific requirements.

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.

It is beyond the scope of this document to detail sound handling of

the digital evidence. Some of the issues involved are mentioned in
the document Collecting Electronic Evidence After a System
Compromise

Autopsy is one free forensic filesystem analysis tool for UNIX

systems. It may be used to examine images of storage devices from
a compromised system, and generate a timeline of recent file
access.

If using this tool, run it only on an image copy of the original hard
disk, on a non-networked machine.

Autopsy is available at http://www.sleuthkit.org/autopsy/desc.php

Solaris

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

J.1 Mailing lists

Notifications of patch releases and security updates are generally

done via mailing lists.

Subscribe to the vendor "announce" list as well as any security

mailing lists for your specific operating system.

Subscribe to the appropriate security/updates mailing list for each

third party software package installed.

Also subscribe to security advisory mailing lists from your local

incident response team (if you have one available).

AusCERT Security Bulletins are available at

http://www.auscert.org.au/1

US-CERT Vulnerability Notes are available at

http://www.kb.cert.org/vuls/

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.

nmap is a port scanning tool available from:

http://www.insecure.org/nmap/

Nessus is a vulnerability scanning tool available from:

http://www.nessus.org
OpenVAS is a vulnerability scanning tool available from:
http://www.openvas.org

Index of OS Specific Footnotes

1. i. Linux
2. ii. Solaris
3. iii. HP-UX
4. iv. FreeBSD
5. v. OpenBSD
6. vi. AIX
7. vii. IRIX