|
HP-UX Security Guide |
This document provides instruction on building a secure computing platform with HP-UX 9.07. 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.
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]
During the installation process, answer the questions as they pertain to your site. You will want to mark the machine as not being networked during the installation process.
When prompted for Root Swap space size enter 250150 You may want to scale the swap space as appropriate for your hardware, but extra swap space helps prevent "denial-of-service" attacks. The minimum amount of space space is 2 x the amount of memory installed.
When prompted for the filesets to load, choose Select Filesets for a Minimum System.
From the next panel, select Modify/View Partitions and Filesets ...
Select the following filesets: Marking a fileset with y installs all modules (manuals, etc) within that subproduct.
Selected Name Partition Description n GRAPHICS Graphics Products y NET-CORE Berkeley Sockets, NetIPC, TCP/IP y NETWORKING Networking Link Layer Software p NLS Native Language Support y OS-ADMIN Recommended Administration Cmds y OS-CORE Recommended System Core p OS-FEATURES Selectable OS Features y ACCOUNTING System Accounting y AUDIT HP Security Monitering Utility y CMDS-AUX Auxiliary HP-UX commands y EDITORS Text Editors- vi and ex y LP-SPOOL Printer Management Utilities y MAILERS System Mail Utilities y MIN-CLIENT Minimal Client Environment y NONHPTERM Terminfo, Non-HP Terminals p PROG-LANGUAGES Programming Languages y C-MIN Restricted C compiler n REFERENCE-DOC Reference Manual Pages p SHARED-LIBS Runtime Shared Libraries y CORE-SHLIBS HP-UX Run-Time Libraries n SRB-90WS Software Release Bulletin n SSB-90WS Software Release Bulletin n SoftBenchFW SoftBench Framework/Core n WINDOWS Windowing ProductsOnly the listed sub-filesets should be selected for partial filesets, which are marked with a p. All other sub-filesets should not be selected.
Using some other machine, access http://us-support.external.hp.com to get a copy of the patch matrix:
On the HP Electronic Support Center main screen, select the hyperlink "Support Information Digests".
On the "Welcome to HP's Support Information Digests" screen, under the heading "Register Now", select the appropriate hyperlink "Americas and Asia-Pacific", or "Europe".
On the "New User Registration" screen, fill in the fields for the User Information and Password and then select the button labeled "Submit New User".
On the "User ID Assigned" screen, select the hyperlink
"Support Information Digests".
** Note what your assigned user ID and password are for
future reference.
You should now be on the "HP Support Information Digests Main" screen. You might want to verify that your email address is correct as displayed on the screen. From this screen, you may also view/subscribe to the digests, including the security bulletins digest.
To get a patch matrix of current HP-UX and BLS security patches referenced by either Security Bulletin or Platform/OS, click on following screens in order:
You can ftp the patches from ftp://us-support.external.hp.com/hp-ux_patches. You will need to put the tar files on tape to move them to your secure server.
Install the patches and reboot your machine before continuing on to the next section.
The Minimal system. still provides many services that which are insecure or unnecessary. This section details which services are a danger to your system.
The following is the output from ls -l /system on a secure system:
02-USER C-INC LANG-MIN NETIPC SAM ACCOUNTNG C-MIN LANG-SHLIBS NETTRACELOG SLIP-RUN AMERICAN CMDS-AUX LSSERVER-ADMIN NFS-INC SRC-CNTL ARPA-AUX CMDS-MIN MAILERS NFS-RUN SYS-ADMIN ARPA-INC CORE-SHLIBS MIN-CLIENT NLS-CORE TEXT-FMT ARPA-RUN EDITORS NCSNCK-RUN NONHPTERM TOOL AUDIT KERN-BLD NET PROG-AUX UX-CORE BSDIPC-SOCKET LAN NETINET PROG-MIN
If you have any products other then man pages (-MAN) that are not listed above, remove them with the rmfn -l
Processes are started at boot time by adding and removing files in /sbin/rc[0-4].d (the files in /etc/rc[0-4].d being hard links to files in /sbin/init.d). Many of these startup scripts run processes that you absolutely do not want running on your secure server: NFS is a prime example. [2]
Consider disabling the following services in /etc by moving them to another directory such as /etc/disabled:
snmpd portmap
Remove crontab files. You should remove all files from /usr/spool/cron/crontabs except the root file.
In order to log as much information about your system, configure /etc/syslog.conf with the following:
mail.debug /usr/spool/mqueue/syslog *.info;mail.none /usr/adm/syslog *.alert /dev/console *.alert root *.emerg *
Note: Tabs must be used to separate the fields.
This will log mail entries to /usr/spool/mqueue/syslog and everything else to /usr/adm/syslog.
Set the permissions on the log files as follows:
chmod 600 /usr/adm/syslog /usr/spool/mqueue/syslog
Disable IP forwarding. Create /etc/ipforward with the following :
ipforwarding/W 0 ipforwarding?W 0
# Disable ipforwarding adb -w /hp-ux /dev/kmem < /etc/ipforwarding
When you are done, reboot your machine. Always test boot file changes thoroughly. When the machine comes back up, the output of ps -ef should look like this:
UID PID PPID C STIME TTY TIME COMMAND root 0 0 0 Dec 31 ? 0:07 swapper root 1 0 0 08:26:42 ? 0:00 init root 2 0 0 08:26:41 ? 0:00 vhand root 3 0 0 08:26:41 ? 0:00 statdaemon root 7 0 0 08:26:41 ? 0:00 unhashdaemon root 10 0 0 08:26:42 ? 0:00 syncdaemon root 6 0 0 08:26:42 ? 0:00 sockregd root 164 1 0 08:27:10 console 0:00 -sh root 173 164 4 08:28:31 console 0:00 ps -ef root 74 1 0 08:27:01 ? 0:00 /etc/syncer root 101 83 0 08:27:05 ? 0:00 /etc/netfmt -f /usr/adm/nettl.LOG root 124 1 0 08:27:06 ? 0:00 /etc/cron root 81 1 0 08:27:01 ? 0:00 /etc/nktl_daemon 0 0 0 -1 0 1 -2 root 110 1 0 08:27:05 ? 0:00 /etc/inetd root 83 1 0 08:27:04 ? 0:00 /etc/ntl_reader 0 1 1 1 1000 /usr root 103 1 0 08:27:05 ? 0:00 /etc/rlbdaemon root 141 1 0 08:27:07 ? 0:00 /etc/syslogd root 126 1 0 08:27:06 ? 0:00 /etc/ptydaemon
If it does not look like this. Go back and make sure that the recommended filesets have been removed and services have been disabled from /etc.
Because the /usr/sbin/sendmail daemon is not running, you should add the following line to root's crontab file:
0 * * * * /usr/sbin/sendmail -qThis entry will invoke sendmail every hour to process any queued mail.
Replace /usr/lib/sendmail.cf with the following:
# Minimal client sendmail.cf ### Defined macros # The name of the mail hub DRmailhost # The local official domain name Dj$w # Whom errors should appear to be from DnMailer-Daemon # Formatting of the UNIX from line DlFrom $g $d # Separators Do.:%@!^=/[] # From of the sender's address Dq<$g> # Spool directory OQ/usr/spool/mqueue ### Mailer Delivery Agents # Mailer to forward mail to the hub machine Mhub, P=[IPC], S=0, R=0, F=mDFMuCX, A=IPC $h # Sendmail requires these, but are not used Mlocal, P=/bin/mail, F=rlsDFMmnuP, S=0, R=0, A=mail -d $u Mprog, P=/bin/sh, F=lsDFMeuP, S=0, R=0, A=sh -c $u ### Rule sets S0 R@$+ $#error $: Missing user name R$+ $#hub $@$R $:$1 forward to hub S3 R$*<>$* $n handle <> error address R$*<$*>$* $2 basic RFC822 parsing
This configuration should be sufficient for servers where no local mail deliv ery is required.
This section details how to lock down network and filesystem access controls.
Disable network root logins with the following command:
echo "console" > /etc/securetty
Disable use of ftp by root by adding "root" to /etc/ftpusers.
Use sam to convert your system to a Trusted System:
You need to convert to a Trusted System before proceeding. The conversion process does the following things: 1. Creates a protected database on the system for storing security information. 2. Moves user passwords in "/etc/passwd" to this database. 3. Replaces all password fields in "/etc/passwd" with "*". For more details, refer to the "System Security" chapter of the "System Administration Tasks" manual. Do you want to convert to a Trusted System now?
Remove, lock, or comment out unnecessary accounts, including "daemon", "bin", "adm", "uucp", "lp", "hpdb", and "nobody". The cleanest way to shut them down is to disable them using by replacing the user's password with an asterisk (*) in /.secure/etc/passwd.
Disable rlogin/rsh access by removing /etc/hosts.equiv, /.rhosts, and all of the "r" commands in /etc.
Install TCP Wrappers from ftp://ftp.cert.org/pub/tools/tcp_wrappers TCP Wrappers add host authentication and logging features to services started by inetd.
Install the TCP Wrappers binary tcpd in /etc.
Replace /etc/inetd.conf with the following:
# # /etc/inet/initd.conf # # To re-configure the running inetd process, edit this file, then # send the inetd process a SIGHUP. # ftp stream tcp nowait root /etc/tcpd /etc/ftpd telnet stream tcp nowait root /etc/tcpd /etc/telnetd
The /etc/hosts.allow should contain the hosts that are allowed to access administrative services on this machine:
ALL: 10.0.20.41,10.0.20.56
The /etc/hosts.deny file should contain a mail command that will be sent to the administrator when a connection is refused:
ALL: ALL: /usr/bin/mailx -s "%d: connection attempt from %c" admin@domain
More information about these files can be found in the hosts_access(5) man page.
Be sure to set the permissions on the host access files as follows:
chmod 600 /etc/hosts.allow /etc/hosts.deny
Remove write group permissions for /etc via the chmod -R g-w /etc command.
Set permissions on /etc/utmp via the chmod 644 /etc/utmp command.
Many of the setuid and setgid programs on HP-UX are used only by root, or by the user or group-id to which they are set. Evaluate all files with the setuid and setgid bit set to determine if this is required for users to get work done.
The command to find all set-uid programs in the system is:
# find / -perm -4000and remove the set-uid bit from appropriate files, such as:
/usr/lib/expreserve /usr/lib/exrecover /usr/lib/acct/accton /usr/bin/landiag /usr/bin/ppl
Likewise, obtain a list of set-gid files on your system via the command:
find / -perm -2000 -printand remove the set-gid bit from appropriate files, including:
/usr/bin/netstat
Create a master list of the remaining setuid/setgid programs on your system and check that the list remains static over time.
This section contains a series of 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.
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: RootReasons you might not receive mail: [1]Date: Mon Aug 11 10:48:17 PDT 1997 To: admin@domain Subject: in.telnetd: connection attempt from badhost
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]
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]
Check what processes are running:
UID PID PPID C STIME TTY TIME COMMAND root 0 0 0 Dec 31 ? 0:07 swapper root 1 0 0 08:26:42 ? 0:00 init root 2 0 0 08:26:41 ? 0:00 vhand root 3 0 0 08:26:41 ? 0:00 statdaemon root 7 0 0 08:26:41 ? 0:00 unhashdaemon root 10 0 0 08:26:42 ? 0:00 syncdaemon root 6 0 0 08:26:42 ? 0:00 sockregd root 164 1 0 08:27:10 console 0:00 -sh root 173 164 4 08:28:31 console 0:00 ps -ef root 74 1 0 08:27:01 ? 0:00 /etc/syncer root 101 83 0 08:27:05 ? 0:00 /etc/netfmt -f /usr/adm/nettl.LOG root 124 1 0 08:27:06 ? 0:00 /etc/cron root 81 1 0 08:27:01 ? 0:00 /etc/nktl_daemon 0 0 0 -1 0 1 -2 root 110 1 0 08:27:05 ? 0:00 /etc/inetd root 83 1 0 08:27:04 ? 0:00 /etc/ntl_reader 0 1 1 1 1000 /usr root 103 1 0 08:27:05 ? 0:00 /etc/rlbdaemon root 141 1 0 08:27:07 ? 0:00 /etc/syslogd root 126 1 0 08:27:06 ? 0:00 /etc/ptydaemon
The following secuirty checklist items are from the DII COE Security Checklist [3].
Objective 5.1.0:
Ensure the audit subsystem is enabled and is configured securely. |
|
Step 1 |
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. |
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/bin/sam |
Step 2 | Select "Auditing and Security." |
Step 3 | Select "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/bin/sam |
Step 2 |
Select "Auditing and Security." |
Step 3 |
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). |
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 -l "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 /etc/syslogd |
|
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 9 1995 /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 /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. |
Comments: |
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. |
Objective 5.3.0:
Verify that cron has been securely configured. |
|
Step 1 |
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 {} \; |
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 -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). |
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 -l /usr/lib/cron/log /usr/bin/more /usr/lib/cron/log |
Expected Results:
The cron log is not world or group writable, and the cron jobs logged have been approved. |
|
Comments: |
Objective 5.3.1:
Verify that the expreserve and exrecover executables are secure. |
|
Step 1 |
Execute the following command: ls -l /usr/lib/expreserve /usr/lib/exrecoverCheck 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/lib/expreserve /usr/lib/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 $PATHYou 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: /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 /.Xdefaultsand on any executable that is referenced in the file being viewed, execute the command: ls -l |
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 / /etc/ /bin /usr /usr/bin /usr/lib |
|
Expected Results:
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 | ||
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 /usr/tmp /usr/mail /usr/preserve |
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: /bin/find / -perm -4 ! \( -perm -6022 \) \ \( -type f -o -type d \) \ ! -user root -group 0 -exec ls -l {} \; |
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: /bin/find /sbin \( -perm -2 -o -perm -20 \) -exec ls -l {} \; |
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 /etc. |
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: /bin/find / \( -type c -o -type b \) -exec ls -l {} \; \ | 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 /etc/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: /bin/find /dev ! \( -type l -o -type c -o -type b \) \ -exec ls -l {} \; |
Expected Results:
All files in /dev are special files. |
|
Step 3 |
As root, execute the following command: /bin/find / \( -type c -o -type b \) ! -user root -exec ls -l {} \; |
Expected Results:
There are no special device files owned by root that should not be owned by root. |
|
Comments: |
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 /etc/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 |
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:
|
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 /usr/lib/aliases. |
|
Step 1 |
Type the following command: vi /usr/lib/aliasesSearch 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 foundOR the decode alias line appears as follows: #decode: "|/usr/bin/uudecode" |
|
Comments:
After modifying the /etc/mail/aliases file you need to execute /usr/bin/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 HP Sendmail (/16.2) ready at Thu, 28 Aug 1997 10:21:10 -0700 |
|
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 unrecognizedIf 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/lib/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: /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: /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:
|
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/exportsand for each shared filesystem run the following command: /bin/find filesystem \( -perm -2 -o -perm -20 \) -exec ls -l {} \; |
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,roAnd follow the following criteria:
|
|
Step 2 |
Execute the following command and ensure that the owner and permissions of the exports file are correct: /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:
|
|
Comments: |
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 /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 {} \; |
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/passwdAny files within the /.secure directory should not be readable or writeable by anyone other than root. |
|
Comments: |