Ensure the audit subsystem is enabled and is configured securely.

Invoke SAM by executing:

/usr/bin/sam

Select "Auditing and Security."

Select "Events."

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

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

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.

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

Invoke SAM by executing:

/usr/bin/sam

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.

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.

Invoke SAM by executing:

/usr/bin/sam

Select "Auditing and Security."

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

Auditing should be enabled for all users.

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.

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 -l "filename"

more "filename"

Each command should cause an error message to be returned.

Verify that syslogd is running and is configured securely.

Execute the following command:

ps -eaf | grep syslog

Output should resemble the following:

ps -eaf | grep syslog

root   309     1  0 16:23:24 ?         0:00 /etc/syslogd

Execute the following command:

ls -l /etc/syslog.conf

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

-r--r--r--   1 root       bin            257 Jun  9  1995 /etc/syslog.conf

Execute the following command:

/usr/bin/more /etc/syslog.conf

The configuration file should resemble the following:

mail.debug              /usr/spool/mqueue/syslog

*.info,mail.none        /usr/adm/syslog

*.alert                 /dev/console

*.alert                 root

*.emerg                 *

This will log mail entries to /usr/spool/mqueue/syslog and everything else to /usr/adm/syslog.

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

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.

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

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.

Verify that cron has been securely configured.

Perform the following commands:

/bin/find /usr/spool/cron/crontabs -type f -exec ls -ldb {} \; \

-exec /usr/bin/more {} \;

/bin/find /usr/spool/cron/atjobs -type f -exec ls -ldb {} \; \

-exec /usr/bin/more {} \;

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.

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

Perform an ls -l 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).

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.

Execute the following commands:

ls -l /usr/lib/cron/log

/usr/bin/more /usr/lib/cron/log

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

Verify that the expreserve and exrecover executables are secure.

Execute the following command:

ls -l /usr/lib/expreserve /usr/lib/exrecover

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

chmod -s /usr/lib/expreserve /usr/lib/exrecover

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.

As root, execute the following command:

echo $PATH

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

As root, execute the following command:

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

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

Ensure the file systems are configured correctly and securely.

Execute the following command:

/bin/df -t | /usr/bin/more

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

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.

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

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

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

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

ls -l

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

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

Executable the following command:

ls -ldb / /etc/ /bin /usr /usr/bin /usr/lib

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

drwxr-xr-x  15 root     root        1024 Aug 28 08:39 /

drwxr-xr-x   3 root     root        2048 May 23  1995 /bin

drwxr-xr-x  13 root     root        4096 Aug 28 09:13 /etc/

dr-xr-xr-x  22 root     bin         1024 Aug 28 07:46 /usr

dr-xr-xr-x   2 root     bin         5120 Aug 28 09:13 /usr/bin

dr-xr-xr-x  25 root     bin         2048 Aug 28 09:47 /usr/lib

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.

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.

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 {} \;

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

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

/tmp

/usr/tmp

/usr/mail

/usr/preserve

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

As root, execute the following command:

/bin/find / -perm -4 ! \( -perm -6022 \) \

\( -type f -o -type d \) \

! -user root -group 0 -exec ls -l {} \;

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

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

As root, execute the following command:

/bin/find /sbin \( -perm -2 -o -perm -20 \) -exec ls -l {} \;

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

Review all startup and shutdown scripts and configuration files in /etc.

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.

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

As root, execute the following command:

/bin/find / -type f \( -perm -4000 -o -perm -2000 \) \

-exec ls -l {} \;

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

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

As root execute the following command:

/bin/find / \( -type c -o -type b \) -exec ls -l {} \; \

| grep -v "/dev/"

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

Any device outside the /dev directory is suspicious

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

As root, execute the following command:

/bin/find /dev ! \( -type l -o -type c -o -type b \) \

-exec ls -l {} \;

All files in /dev are special files.

As root, execute the following command:

/bin/find / \( -type c -o -type b \) ! -user root -exec ls -l {} \;

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

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

Execute the following commands:

ls -l /etc/inetd.conf

/usr/bin/more /etc/inetd.conf

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

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.

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

Execute the following commands:

ls -l /etc/securetty

/usr/bin/more /etc/securetty

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.

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

cat "console" > /etc/securetty

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.

Execute the following commands:

ls -l /etc/ftpusers

/usr/bin/more /etc/ftpusers

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.

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

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.

Execute the following command:

finger @localhost

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

finger 2323412378219837921987328@localhost

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

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

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.

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

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.

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

Verify that TFTP does not run with privileges

Execute the following command:

ls -l /etc/tftp

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

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

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

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.

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

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 /.secure/etc/passwd).
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."

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/

Verify the "decode" and "uudecode" aliases have been removed from the aliases file /usr/lib/aliases.

Type the following command:

vi /usr/lib/aliases

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

Pattern not found

#decode: "|/usr/bin/uudecode"

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

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

Execute the following command:

telnet localhost 25

The sendmail banner and version number will be displayed:

220 hostname HP Sendmail (/16.2) ready at Thu, 28 Aug 1997 10:21:10 -0700

Try each of the following commands while connected to sendmail:

wiz

debug

kill

Each of the commands should result in the following:

500 Command unrecognized

From a command shell, execute the following command:

/usr/lib/sendmail -d23937476383

This command does not cause a segmentation fault.

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.

Verify netrc files are not used.

As root, execute the following command:

/bin/find / -name .netrc -exec ls -ld {} \; -exec more {} \;

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.

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

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.

As root, execute the following command:

/bin/find / -name .rhosts -exec ls -ldb {} \; -exec more {} \;

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

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

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.

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

/usr/bin/more /etc/exports

/bin/find filesystem \( -perm -2 -o -perm -20 \) -exec ls -l {} \;

No files should be listed.

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.

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

/usr/bin/more /etc/exports

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

/usr/stuff -access=bear:dog,anon=-65534,ro

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.

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

/bin/ls -l /etc/exports

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

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.

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

+:*:0:0:::

+::0:0:::

The NIS server and clients should be correctly configured.

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.

Execute the following command:

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

The following response is displayed:

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

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

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

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

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.

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

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]$$

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.

Verify there are no duplicate GIDs.

Review the file /etc/group file.

There should not be duplicate GIDs.

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.

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

Verify there are no duplicate UIDs.

Review the /etc/passwd file.

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

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.

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

Guest accounts should not exist.

Verify password file permissions.

Perform the following:

/usr/bin/ls -l /etc/passwd

/bin/find /.secure \( -perm -2 -o -perm -20 \) -exec ls -l {} \;

/bin/find /.secure \( -perm -4 -o -perm -40 \) -exec ls -l {} \;

/bin/find /.secure ! -user root -exec ls -l {} \;

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