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.

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:

SARA: Open Source (pending) network assessment tools for security auditing
TARA: Corporate derived security system auditing tool based on Tiger
ARC Search: ARC-developed program to search for evidence of hacker activity

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	SARA
Correct Serious Problems	SARA
Review Potential Problems	SARA

Internal Auditing	Verifying the security configuration from the "inside"
Run Automated Checklists	TARA
Run ARC Hacker Search program	ARC
Confirm patches are up to date	Administrator Action

"rhosts" files:	Remotelogin utilities
Check hosts.equiv	TARA
Check all .rhosts	TARA
Check .netrc	TARA

Passwords:	User authentication
Check for password aging	Administrator Action
Remove old accounts	Administrator Action
Check accounts with no passwords	TARA, SARA, ARC
Check password security provisions	Administrator Action

Super User:	Protecting system privileges
Check root access limits	TARA
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	SARA
Identify non-required standalone services	SARA
Check Web services	TARA
Limit access to services	Administrator Action

Important Actions

NFS:	Network File System
Confirm that it is needed or disable	Administrator Action
Confirm suid is disabled	TARA
Confirm portmapper isn't "buggy"	SARA
Review exports and netgroup	TARA, SARA
Review system permissions	TARA
Confirm the nobody/nogroup IDs	TARA

Other

Miscellaneous	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:

Critical (Red): Compromise of accounts and/or large amounts of data.
Serious (Yellow): Compromise of data and/or simplify hacker's job.
Possible (Brown): Possible compromise target. Not enough information is known.

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):

Built-in report writer (by subnet or by database) [SARA]
FTP bounce
Mail relaying
Built-in summary table generator [SARA]
Gateway to external programs (e.g., NMAP) [SARA]
CGI-BIN vulnerability testing (Unix and IIS) [SARA]
SSH buffer overflow vulnerabilities [SARA]
Current Sendmail vulnerabilities [SARA]
IMAPD/POPD buffer overflow vulnerabilities [SARA]
Current FTP and WU-FTP vulnerabilities [SARA]
Tooltalk buffer overflow vulnerabilities [SARA]
Netbus, Netbus-2, and Back Orifice vulnerabilities [SARA]
Improved Operating System fingerprinting [SARA]
Firewall-aware [SARA]
Probing for non-password accounts
NFS file systems exported to arbitrary hosts
NFS file systems exported to unprivileged programs
NFS file systems exported via the portmapper
NIS password file access from arbitrary hosts
REXD access from arbitrary hosts
X server access control disabled
Arbitrary files accessible via TFTP
Remote shell access from arbitrary hosts
Writeable anonymous FTP home directory

Internal SecurityAuditing

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.

The ARC Search Program scans the host's local drives for many common hacker programs that might be installed on the target system.

Texas A&M University's Tiger scripts is the basis for TARA. These are similar to the Computer Oracle and Protection System (COPS), but expands on it. From the TIGER documentation:

"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:

cron entries

mail aliases

NFS exports
inetd entries
PATH variables
.rhosts & .netrc files
Specific file & directory access permissions
File system scans to locate unusual files
Digital signatures are used to detect alterations to key binaries and also to report binaries for which (updated) security patches exist.
Pathnames embedded in any files reported by most of the other checks are also checked.

rhosts and hosts.equiv

User account .rhosts files should not contain machine names not located at NIH. Use one of the internal auditing programs mentioned below to scan for insecure .rhosts entries.

Remove /etc/hosts.equiv and /.rhosts unless you have some overriding need for them. Since some system intrusions involve creating one of these files where none existed before, you can confound attempts to create them by creating a directory of the same name.

For instance:

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

Check if ruserok() ignores .rhosts files which are group or world readable. If it does not ignore such files then make corrections, if possible. Remove all .rhosts entries for root if at all possible. Set /.rhosts so that no other machine is equivalent.

Test the functionality of the /etc/hosts.equiv file for the ability to use the "* -user name" syntax to deny trusted logins from any system and username pair. If this syntax does not work, then a source code patch to the ruserok() routine will be necessary. If a patch is not available, the system name can not be placed in the /etc/hosts.equiv file. Verify that /etc/hosts.equiv has no ambiguous entries. This means that the fully qualified name is first and any aliases second rather than the reverse. Make sure that there are NO '+' entries.

Don't forget to check the .netrc file as it has similar effects to FTP access. Wherever possible, remove the .netrc!

Improve Password Security

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

Review your password policy to confirm that some type of password aging is in place. Password aging should be in accordance with the CIO's policy guidelines.

Periodically review the accounts on your system. Determine which accounts are no longer active and remove them.

Implement shadow password and group files to restrict access to the encrypted password information. If an intruder can get a copy of your /etc/passwd file which contains encrypted passwords, then (s)he can use a password cracking program on a remote (possibly more powerful) host to test guessed passwords against each password entry. Shadow password and group files protect the encrypted passwords.

Test the passwd program to see what kind of password construction rules are enforced. If strict password construction rules are not enforced then install npasswd or passwd+.

Run a password cracking program such as crack to check for poor passwords.

Protect Superuser Access

Do not allow direct root logins, except maybe from the console, if it is in a physically secure location. Only terminals marked as secure in the file /etc/ttytab file will allow any user with UID = 0 to login directly. At all other terminals the user will need to login as a normal user and then su to root. Marking terminals as unsecured is a good idea, although not necessary.

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

Limit the users who are allowed to su to root. If in the /etc/group file or NIS map the wheel group (group 0) is not a null user list, only the members listed are allowed to su to root, all other users will be denied, even when they enter the correct root password.

For new Linux systems, the file /etc/securetty controls remote root access. If any entry has the value ttyp, then remote root logins are possible. For newer SunOS and IRIX, systems, remote root access is controlled by /etc/default/login. If the entry, #CONSOLE=xxxxx is found, then remote root logins are possible.

Log and monitor su activity. su information can be logged in a separate file by editing /etc/syslog.conf:

#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 sulog by looking at the file, or having it mailed to you.

Use a program such as sudo in place of su to avoid giving people unrestricted root access.

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.

Review which network services you wish to provide to other systems

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.

Edit the file /etc/inetd.conf and disable (by placing a "#" in column 1) all services which you don't plan to use. Remember: You need to not only protect against known vulnerabilities, but also the possibility that some newlydiscovered vulnerability will affect your system. If a particular service is not enabled, no one can use it to break into your system.

For those services you wish to provide, consider restricting their use to known friendly sites, and/or logging their use. This can sometimes be done by substituting a more secure daemon program for the one provided by your vendor, running the existing daemon in conjunction with TCP Wrappers, or using William LeFebvre's securelib, which allows an access control list to be created for socket bind requests from remote hosts. securelib has libc replacements for the socket functions accept, recvfrom, and recvmsg which are installed in your libc.so shared library.

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

ftp - If you don't plan to set up an incoming FTPserver, disable this. If you do need to run an FTPserver, consider using an FTPdaemon that has added logging and accesscontrol features such as the wuarchive ftpd.

telnet, shell, login, exec - Allows users from other systems to log into your machine. This is useful, but the more useful something is, the more likely that someone will find a way to exploit it. If you have no need to login remotely, disable it. If you do need to allow remote logins, consider using a one-time password system or ssh if possible.

comsat - This is a daemon which is used to notify users of newlyarrived email. There are alternate means of doing the same thing, and there are occasional rumors of security problems with comsat. Unless you have some overwhelming need for this, turn it off.

talk - Allows users to communicate by typing at eachother's terminals. Cute, but usually not needed. If you want to use it, consider using the TCPwrapper package.

uucp - Disable this if you don't use uucp. While you're at it, you may as well turn off execute permission on the uucp-related shell commands.

tftp - Trivial File Transfer Protocol: This is FTP without any security. This should be needed only if your system will be used for booting workstations. If this is the case, you must invoke the daemon with the -s flag, as in:

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.

finger - This hands out information on who is loggedin, or people's phone numbers and offices. Unfortunately this information can be used by a potential intruder to find accounts to attack. You may wish to disable this, run a custom finger daemon, or use the TCP Wrapper package on it.

systat, netstat - These give out information about your system. The comments for finger apply to these.

time - Probably safe.

echo, discard, daytime, chargen - These are used for testing, and are generally safe, though there have been reports of TCP packets with forged IP source addresses being used to trick a system into sending echo packets to itself, causing a packet storm on the local ethernet segment.

mountd - Part of the NFS system. Usually started from /etc/rc anyway.

rexd - This is the Remote Procedure Call mechanism. It has minimal authentication, so unless you really need it you should turn it off.

walld - This allows people to send messages to all logged in users. Useful, but easily abused. You'll probably want to disable it or restrict it with TCP Wrappers.

Tooltalk – (ttdbserverd) This is used by many common desktop elements. However, serious remote exploits may encourage disabling this feature. Experience has indicated little operational degradation by disabling this.

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 accesscontrol 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 nonstandard process in place of the regular daemon for specific sites.

The Network File System: NFS

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 readonly 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 hostnames.
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 filesystems unrestricted to the entire world, without giving any warning that it is doing so.

Explicitly list who you plan to export to in the /etc/exports file by using an access list:

-access=machine1:machine2:machine3

Export the directories readonly if this is feasible in your circumstance. Use the ro flag in /etc/exports.

Turn on port monitoring. This will cause the NFS mount daemon to refuse mount requests originating from highnumbered ( = 1024) ports. The significance of this is that there is a Unixwide convention that a nonroot process may not open a lownumbered port, thus if you enable port monitoring the theory is that your system will accept mount requests only from privileged processes. This is a convention only, and there is nothing to prevent an untrustworthy Unix system, or almost any other type of system from violating it. While enabling port monitoring is worthwhile because it's easy, it also doesn't buy you a whole lot of security. All that aside, here's how: The default /etc/rc.local sets up port monitoring only if the file /etc/security/passwd.adjunct exists. If you will be implementing passwordfile shadowing then you can skip over this step. If you will not be implementing shadowing and you will be exporting files then you should modify /etc/rc.local to do the following, regardless of whether the /etc/security/passwd.adjunct file exists:

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

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.

Insure that all system programs and system directories (including all parent directories all the way up to root) are owned by root, rather than some other user such as bin. The reason for this is that NFS treats numeric userids as equivalent between systems, except for root which it maps to nobody. If say, the executable files in /bin are owned by bin, a malicious sysadmin on another system could NFS mount this directory and overwrite the files.

If you have a firewall, do not pass TCP or UDP packets to ports 111 (the portmapper) or port 2049 (the NFS daemon) from outside your organization. Depending on the level of security you desire, you may decide to restrict the range of addresses from where you accept such packets to some trusted subset of your organization.

In order to protect yourself from a wellknown NFS attack, you must do at least one of the following, but preferably both:

Do NOT selfreference an NFS server in its own exports file either by name, or by the loopback address: localhost.

Use a portmapper that disallows proxy access. Be sure that you do this for every host that runs a portmapper. For Solaris 2.x, use a version of rpcbind that disallows proxy access.

Run the command:

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 mountdaemon. 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 userid. When one of these utilities is attempting access between two systems that have different wordsizes, the truncation or signextension rules which apply to the particular hardware come into play, which may inappropriately equivalence two userids. Some Unix installations use -2 as the userid for nobody and nogroup. Since negative numbers are subject to such hardwaredependent mangling, you should use a number such as 65534 (binary 1111111111111110) or 32767 (binary 0111111111111111).

Miscellaneous

Secure Shell

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

Login Banners

A banner should be placed on your system so that users will see it either before login or right after they have loggedon.

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

The banner should state:

Who owns the system.
Who is authorized to use the system.
The fact that unauthorized use is illegal/in violation of your policy/frowned upon.
If users' activities will be monitored, and what will be done with the data gathered by such monitoring.

Caveat: This is an illdefined legal area, with few precedentsetting 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.

OneTime Passwords

Ordinarily, when you login you are asked for an accountname 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 onetime password system your password will be different each time you login. If one of these passwords is discovered by someone else, it will be useless to them. There are several commercial OneTime Password systems available, but there are also a few freely available systems.

S/Key is perhaps the bestknown of these.

OPIE is a "new and improved" version of S/Key. The underlying algorithm is about the same, but the commandsyntax has been changed to make it more closely resemble the equivalent Unix commands they replace.

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 login using a regular reusable password when you are loggingin locally, using a trusted channel.

SMB Emulators

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.