UNIX System Security Checklist

The below checklist is a recommendation for a generalized secure UNIX system configuration. It is intended to provide technical guidance to the user, not a specification that must be adhered to in all circumstances (some recommendations may not be applicable or practical in some situations). As with all IT systems, it is ultimately the responsibility of the system owner/user to make sure that the system is managed and operated in a secure manner.

General Instructions

This checklist is intended for the system administrator of one or more UNIX systems. Where possible automated tools have been identified that will greatly simplify the execution of this checklist. Tools include:

The checklist is divided into several categories with links to descriptive text that explains the action and the need for it. For each item, a recommended method is provided. For instance, areas that TARA supports are annotated with "TARA". Items that require manual intervention are designated by "Administrator Action". These items are a decided as a function of organizational policy (e.g., password aging, access control), and system familiarization (expired accounts, usage, super-user privileges).


Critical Actions

External Auditing:

Verifying the security configuration from the "outside"

Correct Critical Problems


Correct Serious Problems


Review Potential Problems




Internal Auditing

Verifying the security configuration from the "inside"

Run Automated Checklists


Run ARC Hacker Search program


Confirm patches are up to date

Administrator Action



"rhosts" files:

Remote­login utilities

Check hosts.equiv


Check all .rhosts


Check .netrc





User authentication

Check for password aging

Administrator Action

Remove old accounts

Administrator Action

Check accounts with no passwords


Check password security provisions

Administrator Action



Super User:

Protecting system privileges

Check root access limits


Check who is using it

Administrator Action

Confirm password is "bulletproof"

Administrator Action



Network Services:

Remote access from 'the world'

Identify non-required services from inetd


Identify non-required standalone services


Check Web services


Limit access to services

Administrator Action

Important Actions


Network File System

Confirm that it is needed or disable

Administrator Action

Confirm suid is disabled


Confirm portmapper isn't "buggy"


Review exports and netgroup


Review system permissions


Confirm the nobody/nogroup IDs




Other Things to Consider

Tighten up login banners

Administrator Action

Install secure shell (ssh)

Administrator Action

Consider one-time passwords

Administrator Action

Don't forget SMB emulators

Administrator Action




External Auditing Software

These are programs that examine other systems to evaluate what possible entry points they present to the outside world. You should be careful when using them that you have the permission of the administrators of the scanned systems, since they may perceive an unauthorized scan as an attack.

Current network security audit programs include:

Each program ranks the problem found by level of severity. SARA categorizes a problem in the following way:

For each type of problem found, these packages offer a tutorial that explains the problem and what its impact could be. The tutorial also explains what can be done about the problem: correct an error in a configuration file, install a bugfix from the vendor, use other means to restrict access, or simply disable service. All major vulnerabilities uncovered by any of these auditors should be corrected before continuing! Here's a summary of current list of capabilities (The [SARA] indicator specifies the given feature is new or improved under SARA):

These are programs that are run on the system to evaluate its security with respect to a canned checklist. There is some overlap between what these programs do and this checklist.

"This is a set of Bourne shell scripts, C programs and data files which are used to perform a security audit of UNIX systems. . . . TIGER has one primary goal: report ways root can be compromised. Paths into root are all checked to see if anyone other than root can alter that path. "

Some things that are checked:


For instance:

mkdir /.rhosts
touch /.rhosts/x
chmod 0 /.rhosts/x
chmod 0 /.rhosts

Password security is the first and most powerful line of defense. Password security on Unix systems can be improved by doing the following:

Example /etc/ttytab:

console "/usr/etc/getty std.9600"  sun     on  local   unsecure
ttya    "/usr/etc/getty std.9600"  vt100   off local	unsecure
ttyd0   "/usr/etc/getty std.19200" dialup  on	unsecure
tty00   "/usr/etc/getty std.9600"  unknown off local	unsecure
ttyp0    none                      network off         unsecure
#To log all un-successful, su failed, and root logins to local file
auth.notice             /var/log/authlog
#To send only su failed, and root logins to the loghost machine
auth.warning            ifdef(`LOGHOST', /var/log/authlog, @loghost)

On a regular basis monitor the su­log by looking at the file, or having it mailed to you.

Quoting from the README file from sudo version 1.3.1:

Sudo is a program designed to allow a sysadmin to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow people to get their work done.

Listener Services

The Internet services daemon, usually called inetd, controls most -- but not all -- of the services your system provides to the rest of the world. If you are connected to the Internet, you should interpret the phrase "rest of the world" quite literally.

Here's a quick rundown of the more common inetd services:


tftp    dgram   udp    wait   root   in.tftpd -s /tftpboot

If you don't, tftp can be used to retrieve any file from your system, anonymously. Also make all the files in the bootfile directory read-only.


Standalone Services

Many services are not controlled by inetd but rather are spawned during the boot process. These so called standalone daemons do not use inetd so TCP Wrappers will have no effect. Review in the process status display (ps -aux or ps -def) what daemons are running. If you see any that you think that you may not need, kill it and see what happens (be sure that you are the only user). If you decide that you don't need it, rename it in one of the /etc/rc*.d directories. For instance, if you do not want sendmail, rename the S80Sendmail file in /etc/rc.d to disable.S80Sendmail.



TCP Wrappers

Weitze Venema's TCP Wrapper package permits you to specify an access­control list to restrict each network service you support -- such as telnet or FTP -- by site, domain or username, and log all network service requests. It also lets you specify arbitrary actions -- such as fingering the client site or generating email -- to be executed in response to a network request. You can also run a non­standard process in place of the regular daemon for specific sites.

NFS is a notorious security problem. If you must NFS mount a remote file system, be sure to:

    • Mount it with the nosuid option. On the mount command supply the arguments:

-o nosuid

or use the keyword nosuid in the options field of the /etc/fstab file.

    • Mount it read­only if possible. On the mount command supply the arguments:

-o ro

or use the keyword ro in the options field of the /etc/fstab file.

If you must export file systems via NFS:

    • Export file systems only when necessary, and then only to hosts that require them.
    • Export only to fully qualified host­names.
    • Ensure that export lists do not exceed 256 characters. If you use aliases, the list should not exceed 256 characters AFTER the aliases have been expanded.
There is a bug in some implementations of NFS where an export list longer than 256 characters causes the server to export your file­systems unrestricted to the entire world, without giving any warning that it is doing so.


echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem  /dev/null 2&1

Some NFS clients to which you may be attempting to provide service, may not be able to cope with this, in which case you won't be able to do it.


showmount -e

to determine if what you think you're exporting is what you're really exporting.

If you won't be running NFS, you shouldn't run the NFS daemon, or the mount­daemon. By insuring that the file /etc/exports doesn't exist, /etc/rc.local will not start nfsd or mountd.

Verify that a safe uid is assigned to 'nobody' and 'nogroup'. Several utilities (NFS, rdist) which transfer files or permissions between systems do so by comparing the numeric user­id. When one of these utilities is attempting access between two systems that have different word­sizes, the truncation or sign­extension rules which apply to the particular hardware come into play, which may inappropriately equivalence two user­ids. Some Unix installations use -2 as the user­id for nobody and nogroup. Since negative numbers are subject to such hardware­dependent mangling, you should use a number such as 65534 (binary 1111111111111110) or 32767 (binary 0111111111111111).

From the README file:

"Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp.
Additionally, ssh provides secure X connections and secure forwarding of arbitrary TCP connections. "

A banner should be placed on your system so that users will see it either before log­in or right after they have logged­on.

This may not seem an important security measure, but if you ever wind up prosecuting a system break­in in court, this will help in establishing that the intruder was aware that they were trespassing.

The banner should state:

Caveat: This is an ill­defined legal area, with few precedent­setting cases to determine what will stand up in court and what won't. We advise that you consult your legal staff before deciding on the exact wording of your banner.

An example is:

THIS UNITED STATES GOVERNMENT COMPUTING SYSTEM IS FOR AUTHORIZED OFFICIAL USE ONLY. Unauthorized use or use for other than official U. S. Government business is a violation of Federal Law (18 USC).

Individuals using this computing system are subject to having all of their activities on this system monitored and recorded without further notice. Auditing of users may include keystroke monitoring.

Any individual who uses this system expressly consents to such monitoring and is advised that information about their use of the system may be provided to Federal law enforcement or other authorities if evidence of criminal or other unauthorized activity is found.

This should be modified as appropriate for your situation.

Ordinarily, when you log­in you are asked for an account­name and a password. If this information is compromised -- as for instance if someone is monitoring your connection -- it can be used to gain access to your account. With a one­time password system your password will be different each time you log­in. If one of these passwords is discovered by someone else, it will be useless to them. There are several commercial One­Time Password systems available, but there are also a few freely available systems.

With both these (and similar) systems, you are not expected to memorize a long list of passwords. You can either generate them on the fly, using a laptop or other local computer to which you have direct (console) access, or carry a paper list of passwords. The systems can be configured to allow you to log­in using a regular re­usable password when you are logging­in locally, using a trusted channel.


Service Message Block (SMB) emulators, such as SAMBA, provide the functionality of Windows NT file/print servers on Unix platforms. With this capability comes the danger of improperly secured file shares. You should insure that the shares (for SAMBA, defined in smb.conf) are properly restricted. If your SMB emulator if intended only for your workgroup, you can restrict access by setting the hosts_allow entry in smb.conf.