HP-UX Security Guide

This document provides instruction on building a secure computing platform with HP-UX 10.20. Topics covered include installing the operating system, removing nonessential components, access controls, and network services. The last section provides a checklist for periodically auditing your system.

Contents:

1.0 Installing HP-UX
1.1 Hardware setup
1.2 System configuration
1.3 Disk partitioning
1.4 Loading additional packages
1.5 Loading patches
2.0 Stripping down the operating system
2.1 Boot files
2.2 Network services
3.0 Access controls
3.1 Network access controls
3.2 Filesystem access controls
4.0 Testing your system
4.1 Telnet
4.2 FTP
4.3 Processes
4.4 Filesystems
Appendix
A.1 References
A.2 Software


1.0 Installing HP-UX

This section describes the steps required to partition the drives and install the smallest possible OS image. "Reduced size implies less services and greater security, but also a loss of convenience. Choose security over convenience-- if in doubt about the necessity of a service, turn it off and see what breaks." [1]


1.1 Hardware setup


1.2 System configuration


1.3 Disk partitioning


1.4 Loading additional packages


1.5 Loading patches


2.0 Stripping down the operating system


2.1 Boot files


2.2 Network services



3.0 Access controls

This section details how to lock down network and filesystem access controls.

3.1 Network access controls


3.2 Filesystem access controls



4.0 Testing your system

This section contains a series to procedures to test your system's configuration. At this point you will want to connect your secure system to the network. You will also want to create an admin user and add them to the sysadmin group. [1]

4.1 Telnet

Telnet to the secure machine from one of the machines listed in /etc/hosts.allow:

adminhost% telnet securehost
	[...]
login: admin	
password: (not echoed)
Last login: Mon Aug 11 08:32:28 from /dev/console
$
This may fail for the following reasons: [1]

Telnet to the secure host from a machine that is not listed in /etc/hosts.allow:

badhost% telnet securehost
Trying 10.0.36.4...
Connected to securehost.domain.
Escape character is '^]'.
Connection closed by foreign host.
badhost%
This should generate a mail message as follows:
From: Root 
Date: Mon Aug 11 10:48:17 PDT 1997
To: admin@domain
Subject: in.telnetd: connection attempt from badhost
Reasons you might not receive mail: [1]

Telnet the secure machine from one of the machines listed in /etc/hosts.a allow:

adminhost% telnet securehost
 [...]
login: root 
password: (not echoed)
Not on system console
Connection closed by foreign host.
adminhost%
Reason root could log in: [1]

4.2 FTP

Start an FTP session from one of the machines listed in /etc/hosts.a llow:>

	adminhost% ftp securehost
	Connected to securehost.domain.
	220 FTP server ready.
	Name (adminhost:user): root
	Password: (not echoed)
	530 User root access denied.
	Login failed.
Reasons FTP login could succeed: [1]

4.3 Processes

Check what processes are running:

 UID   PID  PPID  C    STIME TTY       TIME COMMAND
root     0     0  0 15:41:22 ?         0:02 swapper
root     1     0  0 15:41:24 ?         0:00 init
root     2     0  0 15:41:22 ?         0:00 vhand
root     3     0  0 15:41:22 ?         0:00 statdaemon
root     4     0  0 15:41:22 ?         0:00 unhashdaemon
root     7     0  0 15:41:22 ?         0:00 ttisr
root    13     0  0 15:41:24 ?         0:00 lvmkd
root    14     0  0 15:41:24 ?         0:00 lvmkd
root    15     0  0 15:41:24 ?         0:00 lvmkd
root    16     0  0 15:41:24 ?         0:00 lvmkd
root    17     0  0 15:41:24 ?         0:00 nvsisr
root    18     0  0 15:41:24 ?         0:00 supsched
root    19     0  0 15:41:24 ?         0:00 strmem
root    20     0  0 15:41:24 ?         0:00 strweld
root   506     1  0 15:41:57 console   0:00 -sh
root   310     1  0 15:41:44 ?         0:00 /usr/sbin/ptydaemon
root   301     1  0 15:41:44 ?         0:00 /usr/sbin/syslogd -D
root   342     1  0 15:41:50 ?         0:00 /usr/lbin/ntl_reader 0 1 1 1 1000 /var/adm/nettl /var/adm/co
root   329     1  0 15:41:46 ?         0:00 /usr/lbin/nktl_daemon 0 0 0 0 0 1 -2
root   224     1  0 15:41:42 ?         0:00 /usr/sbin/syncer
root   393     1  0 15:41:53 ?         0:00 /usr/sbin/inetd
root   343   342  0 15:41:50 ?         0:00 /usr/sbin/netfmt -C -F -f /var/adm/nettl.LOG00 -c /var/adm/c
root   468     1  0 15:41:55 ?         0:00 /usr/sbin/cron
root   540   506  4 15:42:17 console   0:00 ps -ef
You may have additional processes if: [1]

4.4 Filesystems

Try the following as root on the securehost:

# touch /usr/bin/should-fail
touch /usr/bin/should-fail cannot create
Reasons the file creation would succeed: [1]

Check the suid option; as root on securehost:

# cd /var/tmp
# cp /usr/bin/ps .
# chmod 4111 ps
# ^D
$ /usr/bin/ps -ef
	 UID   PID  PPID  C    STIME TTY      TIME CMD
	root     0     0  0   Jul 31 ?        0:01 sched
	root     1     0  0   Jul 31 ?        0:49 /etc/init -
	root     2     0  0   Jul 31 ?        0:09 pageout
		[...]

$ /var/tmp/ps -ef
	  UID  PID  PPID  C    STIME TTY      TIME CMD
 	admin    0     0  0 12:31:23 pts/7    0:00 -sh
$	
Reasons the output is the same: [1]


5.0 Security checklist

The following secuirty checklist items are from the DII COE Security Checklist [3].

5.1 Audit functions

Objective 5.1.0:

Ensure the audit subsystem is enabled and is configured securely.

Step 1

Invoke SAM by executing:

/usr/sbin/sam

Select "Auditing and Security."

Select "Audited Events."

The upper portion of the window indicates if auditing is on or off.

Expected Results:

Verify that auditing is enabled. If auditing is not turned on, select "Actions" then "Turn Auditing On" from the pull down menus.

Comments:

Auditing tasks can be completed manually with the following commands:

  audsys: Start/Stops auditing, displays audit file information.
  audusr: Selects users to be audited.
audevent: Display audit event status.
 audomon: Sets audit file size parameters.
  audisp: Displays the audit record.

Objective 5.1.1:

Ensure auditing is configured to collect useful events (login, logout, use of privileged commands, export of media, unauthorized access attempts to files...).

Step 1

Invoke SAM by executing:

/usr/sbin/sam
Step 2 Select "Auditing and Security."
Step 3 Select "Audited Events."
Expected Results:

At a minimum the following options should be selected:

      admin - Logs all administrative and privileged events.
      login - Logs all logins and logouts.
 modacccess - Logs all access modifications other than DAC.
     moddac - Logs all modifications of object's Discretionary
              Access Controls.
Comments:

Objective 5.1.2:

Identify any users for whom auditing has been disabled.

The audit flag is on for all existing users at initial conversion to a trusted system. Auditing for individual users can be disabled.

Step 1

Invoke SAM by executing:

/usr/sbin/sam
Step 2

Select "Auditing and Security."

Step 3

Select "Audited Users." Determine if auditing is enabled for all users. If not, identify those accounts that do not have auditing enabled (denoted with "No" in the "Login Audited" column).

Expected Results:

Auditing should be enabled for all users.

Comments:

Objective 5.1.3:

Verify the audit data is protected by the system so that access to its is limited to only those authorized to view the audit data.

Step 1

By default, HP-UX stores its log files in /.secure/etc/auditfile1 and /.secure/etc/auditfile2. Check the /etc/rc.config.d/auditing file which contains the audit parameters. Determine the filename of each audit file. Execute the following for each filename as a non-privileged user:

ls -ldb "filename"
more "filename"
Expected Results:

Each command should cause an error message to be returned.

Comments:

Objective 5.1.4:

Verify that syslogd is running and is configured securely.

Step 1

Execute the following command:

ps -eaf | grep syslog
Expected Results:

Output should resemble the following:

ps -eaf | grep syslog
root   309     1  0 16:23:24 ?         0:00 /usr/sbin/syslogd -D
Step 2

Execute the following command:

ls -l /etc/syslog.conf
Expected Results:

The configuration is not world or group writable and owned by root:

-r--r--r--   1 root       bin            257 Jun 10  1996 /etc/syslog.conf

Step 3

Execute the following command:

/usr/bin/more /etc/syslog.conf
Expected Results:

The configuration file should resemble the following:

mail.debug              /var/adm/syslog/mail.log
*.info;mail.none        /var/adm/syslog/syslog.log
*.alert                 /dev/console
*.alert                 root
*.emerg                 *

This will log mail entries to /var/adm/syslog/mail.log and everything else to /var/adm/syslog/syslog.log.

Comments:

5.2 Availability

Objective 5.2.0:

Verify that the system is backed up on a regular basis.

Step 1

View the crontab file to determine whether the system is backed up automatically on a scheduled basis. From the system log book or the System Administrator, determine when the last backup was performed and if backups are regularly performed. Determine if the backup tapes were labeled correctly.

Expected Results:

Backups are regularly performed either by cron jobs or by operational procedures.

Comments:

In the case of Legato Networker, the Legato software maintains its own job queue. In this case verify that the software is running and that backups are scheduled.


5.3 Permissions

Objective 5.3.0:

Verify that cron has been securely configured.

Step 1

Perform the following commands:

/usr/bin/more /var/spool/cron/crontab.root
/usr/bin/find /var/spool/cron/crontabs -type f -exec ls -ldb {} \; \
-exec /usr/bin/more {} \;
/usr/bin/find /var/spool/cron/atjobs -type f -exec ls -ldb {} \; \
-exec /usr/bin/more {} \;
Expected Results:

All user crontab files are owned by the correct user and group. All files that are referenced in a users crontab file, or that are referenced by files in the crontab file are not world or group writable, and the cron job tasks are appropriate.

Comments:

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

Step 2

Perform an ls -ldb and more on each file referenced in each crontab file to verify that none of the files are world writable (check directories in the path of the referenced files also).

Expected Results:

All files that are referenced in the crontab file, or that are referenced by files in the crontab file are not world or group writable and contain valid entries.

Step 3

Execute the following commands:

ls -ldb /var/adm/cron/log
/usr/bin/more /var/adm/cron/log
Expected Results:

The cron log is not world or group writable, and the cron jobs logged have been approved.

Step 4

Execute the following commands:

ls -ldb /var/adm/cron/cron.allow
/usr/bin/more /var/adm/cron/cron.allow
ls -ldb /var/adm/cron/cron.deny
/usr/bin/more /var/adm/cron/cron.deny
Expected Results:

The cron.allow and cron.deny files are owned by root, are not world writable, and contain the correct entries.

Comments:

Objective 5.3.1:

Verify that the expreserve and exrecover executables are secure.

Step 1

Execute the following command:

ls -l /usr/lbin/expreserve /usr/lbin/exrecover
Check to see if expreserve or exrecover is suid root.

Expected Results:

The suid bit should not be set on expreserve or exrecover If the suid bit is set, execute the following command:

chmod -s /usr/lbin/expreserve /usr/lbin/exrecover
Comments:

Objective 5.3.2:

Verify root's search path is correct.

A search path should never contain the current directory. This is especially true of the superuser account. More generally, a search path should never include a directory that is writable by other users.

Step 1

As root, execute the following command:

echo $PATH
You may also want to review the root search path in the /.profile, /.cshrc, and /.login files.
Expected Results:

Root's search path does not include the current directory (".").

Step 2

As root, execute the following command:

ls -ldb `echo $PATH | sed 's/:/ /g'`
Expected Results:

None of the directories in the search path should be world writable.

Comments:

Objective 5.3.3:

Ensure the file systems are configured correctly and securely.

Step 1

Execute the following command:

/usr/bin/df -t | /usr/bin/more
Expected Results:

All filesystems should be appropriately partitioned so that no filesystem is approaching 100% full.

Comments:

Objective 5.3.4:

Verify root's startup files are only writable by root.

All startup files should be protected so only the user can write to them. It is particularly important that the startup files the superuser uses are not writable by others.

Step 1

As root, execute the following commands from root's home directory and verify from the output that the files listed are writable only by root:

ls -l /.login
ls -l /.profile
ls -l /etc/profile
ls -l /.cshrc
ls -l /.kshrc
ls -l /.emacs
ls -l /.exrc
ls -l /.forward
ls -l /.rhosts
ls -l /.dtprofile
ls -l /.Xdefaults
Expected Results:

Permissions of each file is 600 or 400 and are owned by root.

Comments:

Depending on the system configuration, all of the files listed above may not exist.

Step 2

As root, execute the following commands from root's home directory:

/usr/bin/more /.login
/usr/bin/more /.profile
/usr/bin/more /etc/profile
/usr/bin/more /.cshrc
/usr/bin/more /.kshrc
/usr/bin/more /.emace
/usr/bin/more /.exrc
/usr/bin/more /.forward
/usr/bin/more /.rhosts
/usr/bin/more /.dtprofile
/usr/bin/more /.Xdefaults
and on any executable that is referenced in the file being viewed, execute the command:
ls -ldb

Expected Results:

Permissions of all files referenced in the listed files are 600 or 400 and are owned by root.

Comments:

Objective 5.3.5:

Verify all root executables are owned by root and are not world or group writable.

Step 1

Executable the following command:

ls -ldb / /sbin /etc/ /usr /usr/bin /usr/sbin /usr/lbin
Expected Results:

Listed files are owned by root and are not world or group writable:

drwxr-xr-x  20 root       root          3072 Aug 25 14:42 /
dr-xr-xr-x  16 root       bin           2048 Aug 26 09:27 /etc/
dr-xr-xr-x  13 root       bin           2048 Aug 25 14:53 /sbin
dr-xr-xr-x  18 root       bin           1024 Jun 10  1996 /usr
dr-xr-xr-x   3 root       bin           6144 Aug 25 14:53 /usr/bin
dr-xr-xr-x   7 root       bin           1024 Aug 25 14:53 /usr/lbin
dr-xr-xr-x   5 root       bin           4096 Aug 25 14:53 /usr/sbin
Comments:

All executables run by root should be owned by root, should not be world or group writable, and should be located in a directory where every directory in the path is owned by root and is not group or world writable.


Objective 5.3.6:

Identify all world-writable files on the system and verify their need.

World-writable file, directories, and devices represent a potential security hole in a system.

Step 1

As root, execute the following commands:

/bin/find / -type f \( -perm 2 -o -perm 20 \) -exec ls -ldb {} \;
/bin/find / -type d \( -perm 2 -o -perm 20 \) -exec ls -ldb {} \;
Expected Results:

There are no unexpected world writable files or directories. Files should be world writable only if there is a legitimate requirement.

Comments:

The following files and directories may safely remain world-writable:

/tmp
/var/tmp
/var/preserve
/var/mail

Objective 5.3.7:

Verify that all world-readable, but not world or group writable, non-setuid/setgid system file and directories are owned by root.

Step 1

As root, execute the following command:

/usr/bin/find / -perm -4 ! \( -perm -6022 \) \
\( -type f -o -type d \) \
! -user root -group 0 -exec ls -ldb {} \;
Expected Results:

Any output from this command indicates a file or directory that should be changed to root ownership.

Comments:

Objective 5.3.8:

Verify the startup and shutdown scripts are valid and are protected.

Step 1

As root, execute the following command:

/usr/bin/find /sbin \( -perm 2 -o -perm -20 \) -exec ls -ldb {} \;
Expected Results:

There should be no output indicating that the /sbin directory and its contents are group or world writable.

Step 2

Review all startup and shutdown scripts and configuration files in the /sbin/rc[1-4].d directories.

Expected Results:

Any task performed in the startup script is performed securely. Any service started or task performed is approved. Any directory that contains a script, executable, or configuration file that is executed in the rc scripts during boot or shutdown is not writable by a user other than root.

Comments:

Objective 5.3.9:

Identify the suid and sgid files on the system and verify their need.

Step 1

As root, execute the following command:

/bin/find / -type f \( -perm -4000 -o -perm -2000 \) \
-exec ls -l {} \;
Expected Results:

Verify that all of the programs listed should have the suid or setgid bit set.

Comments:

Objective 5.3.10:

Identify the suid and sgid files on the system and verify their need.

Step 1

As root execute the following command:

/usr/bin/find / \( -type c -o -type b \) -exec ls -ldb {} \; \
| grep -v "/dev/"
Expected Results:

There should be no output from this command indicating that there are device files outside the /dev directory.

Comments:

Any device outside the /dev directory is suspicious

The /usr/sbin/ncheck -s command can be used to display special files and files with the suid bit set.

Step 2

As root, execute the following command:

/usr/bin/find /dev ! \( -type l -o -type c -o -type b \) \
-exec ls -ldb {} \;
Expected Results:

All files in /dev are special files.

Step 3

As root, execute the following command:

/usr/bin/find / \( -type c -o -type b \) ! -user root -exec ls -ldb {} \;
Expected Results:

There are no special device files owned by root that should not be owned by root.

Comments:

Objective 5.3.11:

Verify that filesystems are mounted securely.

Step 1

Execute the following command:

/usr/bin/more /etc/fstab
Expected Results:

With the exception of / and /tmp, all file systems should be mounted "readonly" or "nosuid".

Comments:

Refer to section 3.2 for more details.


5.4 Services

Objective 5.4.0:

Verify that only required network services are provided by the system.

Step 1

Execute the following commands:

ls -l /etc/inetd.conf
/usr/bin/more /etc/inetd.conf
Expected Results:

The permissions do not allow group/world write and file is owned by root. No unnecessary services are enabled.

Comments:

Comment out or remove any unnecessary network services. Most systems require only telnet and ftp.

TCP Wrappers should be installed on the system to provide host authentication and logging features.


Objective 5.4.1:

Verify that logins are configured securely. Root should only be allowed to login directly from the console.

Step 1

Execute the following commands:

ls -l /etc/securetty
/usr/bin/more /etc/securetty
Expected Results:

The permissions do not allow group/world write and the file is owned by root. The file should contain a single entry, console. Any other entries should be scrutinized.

Comments:

If this files does not exist, create it as root with the following command:

cat "console" > /etc/securetty

Objective 5.4.2:

Verify that the FTP users file contains the appropriate accounts.

The /etc/ftpusers file contains a list of users who are not allowed to use FTP to access any files. This file should contain all accounts that are not used by actual users.

Step 1

Execute the following commands:

ls -l /etc/ftpusers
/usr/bin/more /etc/ftpusers
Expected Results:

The permissions do not allow group/world write and the file is owned by root. Typical accounts that should be included are root, uucp, news, bin, ingress, nobody, and daemon.

Comments:

If this file is missing, all users will be able to access the system via FTP.


Objective 5.4.3:

Determine if finger is enabled on the system. If enabled, verify that it is securely configured.

The finger service should not be enabled unless absolutely necessary.

Step 1

Execute the following command:

finger @localhost
Expected Results: An error message indicates that the finger daemon is not enabled.
Step 2

If the finger daemon is enabled, execute the following command:

finger 2323412378219837921987328@localhost
Expected Results:

Login information on users currently logged on the system are provided.

Comments:

There is a bug in some releases that allows finger to dump all known user finger profiles to the requester.


Objective 5.4.4:

Determine whether TFTP is enabled on the system and if enabled, verify that it has been securely configured.

TFTP is used to allow diskless clients to boot from the network. If this machine is not configured as a boot server, TFTP should be disabled.

Step 1

As an unprivileged user, execute the following commands:

% tftp
tftp> connect localhost
tftp> get /etc/passwd testfile
tftp> quit
% ls -l testfile
% more testfile
% rm testfile
Expected Results:

If tftp does not respond with "Error Code 2:Access Violation" and instead transfers the file, the version of tftp should be replaced or configured correctly.

Comments:

The path (/tftpboot) should be included in the command line arguments passed to tftpd in the /etc/inetd.conf file if tftp is enabled.


Objective 5.4.5:

Verify that TFTP does not run with privileges

Step 1

Execute the following command:

ls -l /usr/bin/tftp
Expected Results:

The program does not have the suid or setgid bits set.

Comments:

Objective 5.4.6:

Determine if anonymous FTP is enabled on the system. If anonymous FTP is enabled, verify that it has been securely configured.

Step 1

To ascertain whether you are running anonymous ftp, try to connect to the localhost using anonymous ftp. Be sure to give an RFC822-compliant username (e.g., your.name@some.com) as the password. Type the following commands to ascertain whether anonymous ftp is enabled:

 % ftp 
name (localhost:idname): anonymous
Expected Results:

If the error message "530 User anonymous unknown" (or similar error) is returned then anonymous ftp is disabled. If the system instead replies with the string "331 Guest login ok" (or similar message) and then prompts for a password, anonymous ftp access is enabled.

Comments:

Anonymous ftp should not be enabled unless there is a legitimate business need.

Step 2

If anonymous FTP is enabled, do the following:

  1. Verify that the ftp account has been created and has been disabled by placing an asterisk (*) in the password field (password entries are located in /tcb/files/auth/?/user_name).
  2. Verify that the account has been given a special home directory, such as /local_ftp
  3. Verify that the ftp user owns its home directory and that it is not writable by anyone.
  4. Verify that the directory ftp/bin is owned by the super-user and not writable by anyone. Verify that a copy of the ls program is in this directory.
  5. Verify that the directory ftp/etc is owned by the super-user and not writable by anyone. Verify that copies of the password and group files are in this directory, with all the password fields changed to asterisks (*). Note: The only account that must be present is "ftp."

Expected Results:
Comments:

If anonymous ftp is required, it is suggested that wu-ftpd be used instead. Wu-ftpd adds additional access and logging features to ftpd.

Wu-ftp can be obtained from ftp://wuarchive.wustl.edu/packages/wuarchive-ftpd/


Objective 5.4.7:

Verify the "decode" and "uudecode" aliases have been removed from the aliases file /etc/mail/aliases.

Step 1

Type the following command:

vi /etc/mail/aliases
Search for decode by typing "/decode" and press return.

Expected Results:

A message should be printed to the bottom of the window as follows:

Pattern not found
OR the decode alias line appears as follows:
#decode: "|/usr/bin/uudecode"

Comments:

After modifying the /etc/mail/aliases file you need to execute /usr/sbin/newaliases for the changes to take effect.


Objective 5.4.8:

Verify sendmail is current.

Vulnerabilities in sendmail are discovered frequently. Install vendor supplied sendmail patches or compile and install the most recent version from ftp://ftp.sendmail.org/ucb/src/sendmail/.

Step 1

Execute the following command:

telnet localhost 25
Expected Results:

The sendmail banner and version number will be displayed:

220 hostname ESMTP Sendmail 8.7.1/8.7.1; Tue, 26 Aug 1997 09:52:05

Step 2

Try each of the following commands while connected to sendmail:

wiz
debug
kill
Expected Results:

Each of the commands should result in the following:

500 Command unrecognized
If any of the commands resulted in a different response, sendmail should be replaced with the current version.

Step 3

From a command shell, execute the following command:

/usr/sbin/sendmail -d23937476383
Expected Results:

This command does not cause a segmentation fault.

Comments:

On some versions of sendmail it is possible to get root access by supplying greater than normal address space ranges that are used in its array index to the -d flag. If this causes a segmentation fault then you'll likely have a bug in your version of sendmail. The problem is that numbers in this range may skip the range checks and result in accessing negative indexes into the debug array. Hence it is possible to write to locations in memory before the debug array.


Objective 5.4.9:

Verify netrc files are not used.

Step 1

As root, execute the following command:

/usr/bin/find / -name .netrc -exec ls -ld {} \; -exec more {} \;
Expected Results:

There should NOT be any output from this command. Any output indicates the existence of a .netrc file on the system. The file path, permissions and contents are listed.

Comments:

The .netrc file should not exist on a secure system. If the responsible security officer has approved the use of .netrc files for a specific purpose: Do not store password information in .netrc files. Set permissions on .netrc files to disallow read and write access by group and world ( i.e. 600).


Objective 5.4.10:

Determine if any rhost files are used on the system.

The only secure way to manage .rhosts files is to completely disallow them on the system. The system administrator should check the system often for violations of this policy.

Step 1

As root, execute the following command:

/usr/bin/find / -name .rhosts -exec ls -ldb {} \; -exec more {} \;
Expected Results:

There should be no output from this command. Output means that an .rhosts file has been found. Users should not have an .rhosts file.

Comments:

Cron should be used to periodically check for, report the contents of, and remove .rhosts files.

If there is a genuine need for .rhosts files (e.g., running backups over a network unattended) and their use has been approved by responsible security officer:

  1. The first character of any .rhosts file is not '-'.
  2. The permissions of all .rhosts files are set to 600.
  3. The owner of each .rhosts file is the accounts owner.
  4. No .rhosts file contains the symbol "+" on any line.
  5. Usage of netgroups within .rhosts does not allow unintended access to this account.
  6. No .rhosts files use '!' or '#'.


Objective 5.4.11:

Verify the files on the server are not world-writable or group-writable.

Because the NFS server maps root to nobody, you can protect files and directories on your server by setting their owner to root and making them not world-writable or group-writable.

Step 1

Browse the /etc/exports file using the following command:

/usr/bin/more /etc/exports
and for each shared filesystem run the following command:
/usr/bin/find filesystem \( -perm -2 -o -perm -20 \) -exec ls -ldb {} \;

Expected Results:

No files should be listed.

Comments:

Objective 5.4.12:

Verify the appropriate entries are in the exports file.

The root= keyword specifies the list of hosts that are allowed to have super-user access to the files in the named file system. The access= keyword specifies the list of hosts (separated by colons) that are allowed to mount the named file system. If no access= keyword is specified for a file system, any host anywhere on the network may mount that file system via NFS.

Step 1

View the /etc/exports file with the following command:

/usr/bin/more /etc/exports

Expected Results:

The entries in the /etc/exports file should be similar to the entry below:

/usr/stuff -access=bear:dog,anon=-65534,ro
And follow the following criteria:
  1. Only necessary filesystems are exported.
  2. Only authorized hosts are given access to the exported filesystems.
  3. All entries use fully qualified hostnames (Preferably an ip address).
  4. Filesystems are shared using "anon=-1" to disallow accesses that are not accompanied by a user ID.
  5. The NFS server is not self-referenced, either by name or by specification of a 'localhost' entry.
  6. File systems to be exported are shared as read-only, except where specifically approved by the responsible security officer.
  7. Only the minimum access necessary is given on the exported filesystem.
  8. File systems to be exported are shared non-setuid.
  9. The "root = " option should not be used.
  10. Access should be granted by netgroup or host.
Step 2

Execute the following command and ensure that the owner and permissions of the exports file are correct:

/usr/bin/ls -l /etc/exports

Expected Results:

The file /etc/exports has permissions 644 and is owned by root.

Comments:

Objective 5.4.13:

Verify the "+" line in the /etc/passwd file for each NIS client has been correctly entered.

The plus sign tells UNIX programs that scan a system database file (such as /etc/passwd or /etc/group) to ask the NIS Server for the remainder of the file. Verify that the "+" line in the /etc/passwd file on each NIS client has been correctly entered. Verify that the "+" line has not been added to the /etc/passwd file on the NIS master server.

Step 1

Login to each NIS client, and browse the /etc/passwd file. The following line should be found:

+:*:0:0:::
Verify that the following line has not been accidentally added instead; if it has, anyone can log into the system by providing a "+" at the login prompt:
+::0:0:::

Expected Results:

The NIS server and clients should be correctly configured.

Comments:

Objective 5.4.14:

Check the /etc/hosts.equiv file to verify that the default setting of "trust all hosts" has been changed. If there are individual entries in this file, verify that all entries are appropriate.

Step 1

Execute the following command:

ls -l /etc/hosts.equiv; /usr/bin/more /etc/hosts.equiv
Expected Results:

The following response is displayed:

/etc/hosts.equiv: No such file or directory 
/etc/hosts.equiv: No such file or directory
Comments:

Check for the presence of /etc/hosts.equiv after each operating system or patch installation.

Step 2

If the responsible security officer has approved the use of a /etc/hosts.equiv file for a specific purpose execute the following command:

ls -l /etc/hosts.equiv; /usr/bin/more /etc/hosts.equiv
Expected Results:
  1. The owner of /etc/hosts.equiv is root.
  2. The permissions of /etc/hosts.equiv are set to 600.
  3. The first character of /etc/hosts.equiv is not '-'.
  4. The /etc/hosts.equiv file does not contain a line with only a "+" (a plus sign).
  5. The /etc/hosts.equiv file lists only a small number of trusted hosts, and all hosts listed are within your domain or under your management.
  6. The /etc/hosts.equiv file does not include '!' or '#'.
  7. All hosts in /etc/hosts.equiv are specified using IP addresses to mitigate DNS spoof attacks.
  8. Use netgroups in /etc/hosts.equiv for easier management.
Comments:

5.5 Authentication

Objective 5.5.0:

Verify there are no accounts on the system that have not been used within a reasonable amount of time.

Step 1

Type in and run the following script to determine which users have not logged in within the last month:

#!/bin/sh
date
uname -a
PATH=/bin:/usr/bin;export PATH
umask 077
THIS_MONTH=`date | /usr/bin/awk '{print $2}'`
/usr/bin/last | /usr/bin/grep $THIS_MONTH | /usr/bin/awk '{print $1}' \
| /usr/bin/sort -u > users1$$
cat /etc/passwd | /usr/bin/awk -F: '{print $1}' | /usr/bin/sort -u \
> users2$$
/usr/bin/comm -13 users[12]$$
/usr/bin/rm -f users[12]$$
Expected Results:

No user login account names should be returned. If any user names are returned these should be considered dormant accounts and should be disabled or deleted.

Comments:

Objective 5.5.1:

Verify there are no duplicate GIDs.

Step 1

Review the file /etc/group file.

Expected Results:

There should not be duplicate GIDs.

Comments:

Objective 5.5.2:

Verify the installation-provided user IDs do not have default passwords.

Several accounts come with a UNIX computer system. (These accounts are normally at the beginning of the /etc/passwd file and have names like bin, lib, uucp, and news.) Either disable these accounts or change their passwords.

Step 1 Inspect the /etc/passwd file for installation-provided user IDs.
Expected Results:

The installation provided accounts should either be disabled or have been assigned passwords.

Comments:

Objective 5.5.3:

Verify there are no duplicate UIDs.

Step 1

Review the /etc/passwd file.

Expected Results:

There should not be duplicate UIDs. If there are duplicate UIDs, the accounts should be disabled.

Comments:

Objective 5.5.4:

Verify there are no group or guest accounts on the system.

Guest accounts present a security hole. By their nature, these accounts are rarely used, some are always used by people who should only have access to the machine for the short period of time that they are guests. The most secure way to handle guest accounts is to install them on an as-needed basis, and delete them as soon as the people using them leave. Guest accounts should never be given simple passwords such as "guest" or "visitor," and should never be allowed to remain in the password file when they are not being used.

Step 1

Browse the /etc/passwd file to determine if there is a guest account. If so, try simple passwords such as "guest" and "visitor".

Expected Results:

Guest accounts should not exist.

Comments:

Objective 5.5.5:

Verify password file permissions.

Step 1

Perform the following:

/usr/bin/ls -l /etc/passwd
/usr/bin/find /tcb \( -perm 2 -o -perm -20 \) -exec ls -ldb {} \;
/usr/bin/find /tcb \( -perm 4 -o -perm -40 \) -exec ls -ldb {} \;
/usr/bin/find /tcb ! -user root -exec ls -ldb {} \;
Expected Results:

From the three commands there should be only one line of output:

-r--r--r--   1 root     sys          576 Apr 27 15:31 /etc/passwd
Any files within the /tcb directory should not be readable or writeable by anyone other than root.
Comments:


Appendix

A.1 References

  1. Securing Solaris: A Cookbook Approach. SANS '97 Course Book, by Hal Pomeranz of Deer Run Associates.
  2. The Solaris Security FAQ. by Peter Galvin; SunWorld Online
  3. DII COE Security Checklist Version 2.0; 27 June 1997; Defense Intelligence Agency

A.2 Software


SaberNet.net