UNIX Security Checklist v2.0

download cert_unix_security_checklist_v2.0.zip (51 Kb)



This document has been published jointly by The Australian Computer Emergency Response Team (AusCERT) and the CERT Coordination Center (CERT/CC) and details steps to improve the security of Unix Operating Systems. We encourage system administrators to review all sections of this document and if appropriate modify their systems accordingly to fix potential weaknesses.

The most current version of this document is available from:


While this document details security procedures for UNIX based systems, it should not be used as a tool for recovering from a system compromise. For information regarding recovering from a system we encourage you to review the "Steps for Recovering from a UNIX or NT System Compromise" document, available from:


It is our intention to continue to update this checklist. Any comments should be directed via email to auscert@auscert.org.au and cert@cert.org. Before using this document, ensure you have the latest version. New versions of this checklist will be placed in the same area and should be checked for periodically.

If possible, apply this checklist to a system before attaching it to a network. In addition, we recommend that you use the checklist on a regular basis as well as after you install any patches or new versions of the operating system, with consideration given to the appropriateness of each action to your particular situation.




AusCERT and CERT/CC advise 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 an application program or tool within this document does not constitute endorsement by AusCERT, The University of Queensland, or CERT/CC.



Table of Contents:

Section I. The First Step

Section II. The Basic Operating System

Section III. Major Services

Section IV. Specific Operating Systems

Section V. Appendixes



Section I. The First Step

1.0 Patches



Section II. The Basic Operating System

2.0 Network Services

2.1 /etc/inetd.conf

2.2 tcp_wrapper

2.3 fingerd

2.4 "r" Commands

2.5 /etc/hosts.equiv

2.6 $HOME/.rhosts

2.7 /etc/netgroup

2.8 /etc/services

2.9 /etc/hosts.lpd

2.10 /etc/login.access

2.11 /etc/login.conf

2.12 /etc/login.defs

2.13 PAM (Pluggable Authentication Modules)

2.14 cron

2.15 Secure terminals

2.16 RPC

2.17 Trivial FTP (tftp)

2.18 Majordomo

2.19 UUCP

2.20 REXD



3.0 Networking Administration

3.1 Packet Filtering

3.2 Denial of Service Attacks

3.3 Encryption and Strong Authentication



4.0 File system security

4.1 General

4.2 Startup and Shutdown Scripts

4.3 External File Systems/Devices

4.4 File Permissions

4.5 Files Run by root

We recommend that any script or binary to be executed by root should be owned by root and should not be world or group writable. Additionally, this file should only be located in a directory for which every parent directory is owned by root and is not group or world writable.

4.6 Bin Ownership

Many systems ship files and directories owned by bin (or sys). This varies from system to system and may have serious security implications.

4.7 Tiger

4.8 Tripwire

4.9 The Coroner's Toolkit



5.0 Account Security

5.1 Policy

5.2 Administration

5.3 Special Accounts

5.4 root Account

5.5 .netrc Files

5.6 GCOS Field

5.7 Authentication



6.0 System Monitoring


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.

6.1 Account Security

6.2 Log Files

6.3 Network Security



Section III. Major Services

7.0 Name Service

7.1 BIND

7.2 Alternatives



8.0 Electronic Mail

8.1 Sendmail

8.2 Alternatives (qmail and postfix)




9.0 Web Security

9.1 General Configuration

9.2 Freely Available Servers

9.3 Client Configuration



10.0 FTP: ftpd and anonymous ftp

10.1 General Server Configuration

10.2 Incoming Directories

10.3 Freely Available Servers

10.4 Anonymous FTP Only



11.0 File Services

11.1 NFS

When using NFS, you implicitly trust the security of the NFS server to maintain the integrity of the mounted files.

NOTE: A "web of trust" is created between hosts connected to each other via NFS. That is, you are trusting the security of any NFS server you use.

11.2 Alternatives



12.0 X Window System

Access to your X server may be controlled through either a host-based or user-based method. The former is left to the discretion of the Systems Administrator at your site and is useful as long as all hosts registered in the /etc/Xn.hosts file have users that can be trusted, where "n" represents your X server's number.

This may not be possible at every site, so a better method is to educate each and every user about the security implications (see references below). Better still, when setting up a user, give them a set of X security related template files, such as .xserverrc and .xinitrc. These are located in the users home directory.

You are strongly advised to read the section on X window system security referred to in the X Window System Administrators Guide (B.1.4).

12.1 X Security - General

12.2 Problems with xdm

DO not use any version of X11 prior to release 6 as it resolved security problems that existed in earlier versions. If necessary, obtain the source for X11R6 and compile and install it on your system. This may be obtained from:




Section IV. Specific Operating Systems

13.0 BSD-derived Operating Systems

13.1 BSD/OS

13.2 FreeBSD

13.3 NetBSD

13.4 OpenBSD



14.0 Linux Distributions

14.1 Caldera OpenLinux

14.2 Debian GNU/Linux

Security information for Debian GNU/Linux, including links to security bulletins, patches and updates can be found at:


14.3 Mandrake Linux

14.4 RedHat Linux

14.5 Slackware Linux

14.6 SuSE Linux

Security information for SuSE Linux, including links to advisories, patches, and updates can be found at:


14.7 TurboLinux

Security information for TurboLinux, including links to advisories, patches, and updates can be found at:


14.8 Others

For other distributions of Linux, please refer to your vendor's website. A useful starting point for finding Linux distribution vendor's sites is:




15.0 Solaris

15.1 Patches

15.2 IP Forwarding and Source Routing

This is particularly relevant if you are using your Sun server as a bastion host or dual homed system.

15.3 Stack Execution

15.4 NFS Port Monitoring

15.5 Framebuffers /dev/fbs

15.6 Security Bulletins

15.7 Sun BluePrints

15.8 Solaris Security Toolkit (JASS)



16.0 IRIX

16.1 Patches

16.2 Default Account Security

16.3 Security Advisories



17.0 Hewlett Packard UNIX (HP-UX)

17.1 Patches



18.0 Digital/Compaq Tru64 UNIX

18.1 Patches



19.0 AIX

19.1 Patches

19.2 Security Advisories



Section V. Appendixes

A. Useful security tools

There are many freely available tools that provide a good mechanism for checking the security of your system. The list below is not a complete list, and you should NOT rely on these to do ALL of your work for you. They are intended to be only a guide. It is envisaged that you may write some site specific tools to supplement these. It is also envisaged that you may look around on HTTP or FTP servers for other useful tools.

AusCERT and CERT/CC have not formally reviewed, evaluated or endorsed the tools described herein. The decision to use these tools is the responsibility of each user or organisation.

A.1 System Monitoring Tools



A.2 General Purpose Tools



A.3 Network Monitoring Tools



A.4 Network Access Control Tools



B. References


B.1 Bibliography



B.2 On-line references



C. List of commands by flavour



C.1 Restart inetd

BSD commands

     # /bin/ps -aux | /bin/grep -E "inetd|^USER" | /bin/grep -v grep
     # /bin/kill -HUP <inetd-PID>

SVR4 commands

     # /bin/ps -ef | /bin/grep inetd | /bin/grep -v grep
     # /bin/kill -HUP <inetd-PID>

C.2 Ascertain which services are registered with the portmapper

     # /usr/bin/rpcinfo -p

C.3 Rebuild alias maps

     # /usr/bin/newaliases

If you run NIS (YP), you will then need to rebuild your maps to have the change take effect over all clients:

     # (cd /var/yp; /usr/bin/make aliases)

C.4 Printing the umask value for each user

Use the following shell script:


    HOMEDIRS=`cat /etc/passwd | awk -F":" 'length($6) > 0 {print $6}' | sort -u`
    FILES=".cshrc .login .profile"

    for dir in $HOMEDIRS
   	    for file in $FILES
       	    grep -s umask /dev/null $dir/$file

C.5 Set sendmail log level to 9

Include lines describing the log level (similar to the following two) in the options part of the general configuration information section of the sendmail configuration file:

     # log level

The log level syntax changed in sendmail 8.7 to:

     # log level
     O LogLevel=9

C.6 Set syslog log level for mail messages

Include lines describing the logging required (similar to the following two) in the syslog.conf file:

     mail.info                       /dev/console
     mail.info                       /var/adm/messages

For the change to take effect, you must then instruct syslog to reread the configuration file.

BSD commands
Get the current PID of syslog:

     # /bin/ps -aux | /bin/grep syslogd | /bin/grep -v grep

Then tell syslog to reread its configuration file:

     # /bin/kill -HUP <syslog-PID>

SVR4 commands
Get the current PID of syslog:

     # /bin/ps -ef | /bin/grep syslogd | /bin/grep -v grep

Then tell syslog to reread its configuration file:

     # /bin/kill -HUP <syslog-PID>

NOTE: In the logs, look for error messages like:
- mail to or from a single pipe ("|")
- mail to or from an obviously invalid user (e.g., bounce or blah)

C.7 (Rebuilding and) restarting sendmail(8)

To rebuild the frozen configuration file, firstly do:

     # /usr/lib/sendmail -bz

NOTE: The above process does not apply to sendmail v8.x which does not support frozen configuration files.

To restart sendmail(8), you should kill *all* existing sendmail(8) processes by sending them a TERM signal using kill, then restart sendmail(8).

BSD commands
Get the pid of every running sendmail process:

     # /bin/ps -aux | /bin/grep sendmail | /bin/grep -v grep

Kill every running sendmail process and restart sendmail:

     # /bin/kill <pid>     #pid of every running sendmail process
     # /usr/lib/sendmail -bd -q1h

SVR4 commands
Get the pid of every running sendmail process:

     # /bin/ps -ef | /bin/grep sendmail | /bin/grep -v grep

Kill every running sendmail process and restart sendmail:

     # /bin/kill <pid>     #pid of every running sendmail process
     # /usr/lib/sendmail -bd -q1h

C.8 Test whether ftpd supports SITE EXEC

For normal users:

     % ftp localhost 21
     USER username
     PASS password

For anonymous users:

     % ftp localhost 21
     USER ftp
     PASS username@domainname.au

You should see the response "5nn error return" (e.g., "500 'SITE EXEC' command not understood"). If your ftp daemon has SITE EXEC enabled, make sure you have the most recent version of the daemon. Older versions of ftpd allow any user to gain shell access using the SITE EXEC command. Use QUIT to end the telnet session.

C.9 Ascertain whether anonymous FTP is enabled

     % ftp localhost
     Connected to localhost
     220 hostname FTP server ready
     Name (localhost:username):  anonymous
     331 Guest login ok, send username as password
     Password:  user@domain.au
     230 Guest login ok, access restrictions apply.
     Remote system type is UNIX.
     Using binary mode to transfer files.

C.10 Ensure that '*' in the password field is correctly implemented

C.11 Find .exrc files

    # /bin/find /  -name '.exrc' -exec /bin/cat {} \; -print

See also C.19.

C.12 Find .forward files

    # /bin/find / -name '.forward' -exec /bin/cat {} \; -print

See also C.19.

C.13 Remove execute permission on /usr/lib/expreserve

    # /bin/chmod 400 /usr/lib/expreserve

C.14 Set ownership and permissions for /tmp correctly

     # /bin/chown root /tmp
     # /bin/chgrp 0 /tmp
     # /bin/chmod 1777 /tmp

NOTE: This will NOT recursively set the sticky bit on sub-directories below /tmp, such as /tmp/.X11-unix and /tmp/.NeWS-unix; you may have to set these manually or through the system startup files.

C.15 Find group and world writable files and directories

     # /bin/find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \;

     # /bin/find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \;

See also C.19.

C.16 Find files with the SUID or SGID bit enabled

     # /bin/find / -type f \( -perm -004000 -o -perm -002000 \) \
       -exec ls -lg {} \;

See also C.19.

C.17 Find normal files in /dev

     # /bin/find /dev -type f -exec ls -l {} \;

See also C.19.

C.18 Find block or character special files

     # /bin/find / \( -type b -o -type c \) -print | grep -v '^/dev/'

See also C.19.

C.19 Avoid NFS mounted file systems when using /bin/find

     # /bin/find / \( \! -fstype nfs -o -prune \) <expression>

As an example, <expression> could be

     -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \;



D. Abbreviated Checklist

It is intended that this short version of the checklist be used in conjunction with the full checklist as a progress guide (mark off the sections as you go so that you remember what you have done so far).

Section I. The First Step

Section II. The Basic Operating System

Section III. Major Services

Section IV. Specific Operating Systems



E. Unix Security Checklist - The Essentials

Before You Begin


  • Don't attach the machine to an insecure network until all steps in this document have been addressed - preferably, perform all installations on the machine while it is completely isolated from any network. This may be facilitated by the use of patches stored on a CD or file server located within an isolated staging network.


  • Retrieve the latest patch list from your vendor and retrieve any recommended security patches not included with your system. Some patches may re-enable default configurations so it is important to go through this checklist after installing any new patches or packages. Information about where to obtain operating system patches or packages is available in the USC at Section IV. Patches for software applications not supplied by the operating system vendor should be obtained directly from the software vendor's web site.


  • Ensure that software patches and packages are only downloaded from a reliable source (i.e. direct from the vendor or a trusted mirror). This also applies to the operating system if it is publicly-available or open-source.


  • Verify the cryptographic digital signature of any signed downloaded files to ensure integrity. Don't use a file whose signature doesn't match its contents! Information about PGP/GnuPG is available in the USC at A.2.10 PGP/GnuPG.


  • Verify the md5 checksum, when possible, of any downloaded patches with a utility like md5(1) or md5sum(1). Information about obtaining an MD5 utility is available in the USC at A.2.6 MD5.


  • Subscribe to the vendor's security update mailing list for your particular operating system. Information for individual vendors is available in the USC at Section IV.


  • Subscribe to security advisory mailing lists from your local incident response team (if you have one). These mailing lists are typically low volume and provide invaluable information for system and security administrators. Information on subscribing to mailing lists is available in the USC at B.2.3 Mailing Lists.



Before the System is "Live"

Step One - Patches


  • Check for last-minute updates for your system that need to be performed subsequent to installation.


  • Install security patches retrieved before installation.


  • Check for the availability of a hardening script package for your particular system. Information on hardening scripts is available in the USC at Section IV - Specific Operating Systems.



Step Two - System Configuration


  • For more detailed information, refer to the USC at 2.0 Network Services


  • Disable any services which you do not absolutely require, by commenting out individual lines in /etc/inetd.conf with a "#" character, then reenabling essential services only. See 2.1 /etc/inetd.conf.


  • Unless "r" commands (i.e. rsh, rlogin) are required, remove or empty the file /etc/hosts.equiv.


  • If "r" commands are required, consider replacing them with secure alternatives, such as ssh. See A.2.13 ssh in the USC for more information.


  • Configure tcp_wrappers in /etc/inetd.conf to provide greater access and logging on enabled services if using the inetd daemon. See 2.2 tcp_wrapper. If using Xinetd, ensure that it is correctly configured in /etc/xinetd.conf. See 2.1 /etc/inetd.conf.


  • Edit /etc/hosts.allow to include this entry as the first uncommented line AFTER any configuration lines allowing connections for any specific services required:



  • Edit /etc/hosts.deny to include this entry as the first uncommented line in the file:



  • Verify that you have disabled any unnecessary startup scripts under /etc, /etc/rc.d or /etc/init.d (or startup script directory for your system) and disabled any unneeded services from starting in these scripts.


  • Remove unneeded accounts/groups and disable interactive login access to system accounts.


  • After restarting the machine, check for running network services by issuing the command netstat -a. Ensure that only required services are running and listening for connections. This helps in preventing security compromises on possibly unknown and unpatches services.


  • On systems that implement the /etc/login.access file, consider modifying this file to disallow remote access to privileged accounts. An example to disallow non-local logins to privileged accounts (group wheel):

    -:wheel:ALL EXCEPT LOCAL

    See also 2.10 /etc/login.access


  • Ensure that the terminal security file (for example, /etc/securetty or /etc/ttys) is configured to deny privileged (root) access from any external connections. See 2.15 Secure Terminals.


  • Check that the configuration files for PAM (/etc/pam.conf, /etc/pam.d/*) are secure. See 2.13 PAM (Pluggable Authentication Modules)


  • Ensure that the file /etc/ftpusers contains the names of all system accounts, as well as root. See 5.3 Special accounts


  • Prevent lpd and syslogd from listening for network connections if possible. Caution should be exercised to ensure outbound connections are still allowed if required for your system configuration. This may be accomplished with command-line arguments and/or tcp_wrappers - refer to your system's info or man pages.


  • Clear /etc/hosts.lpd if not required. If the host is a print server, ensure that only fully qualified domain names are specified ie. hostname.domainname. See 2.9 /etc/hosts.lpd



Step Three - Network Options


  • At a minimum, make use of any built-in firewalling utility that the operating system provides. For example: Linux has ipchains and iptables (See A.4.2.4 and A.4.2.5), BSD has ipfw (See A.4.2.1), Sun Solaris includes a "light" version of their SunScreen product with Solaris 8 (See A.4.2.6).


  • Ensure that the host is configured against IP spoofing and attacks with kernel and firewall rules. See 3.1 Packet Filtering and 3.2 Denial of Service Attacks.


  • If you wish to remotely administer your host, don't use unencrypted channels to do so (like telnet). Configure your host to use encrypted communications with a utility like SSH. See 3.3 Encryption and Strong Authentication



Step Four - System Monitoring and Additional Tools


  • Implement and maintain utilities for intrusion detection. At a minimum, implement a file integrity checker to monitor file-system changes. More information is available in the USC at 4.0 File System Security


  • Additional information on security and monitoring tools is available in the USC at Appendix A



Step Five - Final Updates


  • Ensure you implement a procedure to regularly parse and check system log outputs for unusual activity.


  • Make a backup of the completed system before putting it on a production network. This allows you a clear path to restore the system to an operational state. You should also implement a continuing backup policy.


  • Create and maintain a logbook for each system. This allows you to document any changes made to system configurations.


Revision History
Oct 8, 2001
Initial Release