|
Unix Security Handbook |
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.
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 the type of configuration, select Standard LVM configuration or LVM configuration with VxFS (Journaled file system). These configurations provide a more flexible partitioning scheme.
Please note that the VxFS filesystem does not support access controls lists (ACLs).
Your basic configuration should match the following:
Primary Swap Size [ 256Mb ->] Secondary Swap Size [ None ->] Software Selection [ Minimal system, networking (Eng.) ->] Software Language [ English ->] Locale Setting [ default (C) ->] File System file name length [ Long ->] /home Configuration [ None ->] How many disks in root group [ One ->] Make volatile dirs separate [ True ->] Create /export volume [ False ->]
The following partition table is appropriate for a machine loaded with a Minimal system, networking (Eng.) software selection:
/ 72 megabytes /stand 48 megabytes (swap) 256 megabytes /local_home ??? megabytes (rest of the disk) /tmp 100 megabytes /usr 200 megabytes /var 148 megabytes
The /var partition is large to accommodate extra logging and audint inforation. You may want to scale the swap space as appropriate for your hardware, but extra swap space helps prevent "denial-of-service" attacks. [2]
The local_home partition will be used to hold third-party software. You may need to create additional partitions or add additional drives as required by your application. [1]
When prompted Do you want to interact with SD-UX swinstall? answer Yes. This will allow you to install additional software components.
With the swinstall utility mark the following additional software sets which are located within the HPUXEngCR700 product. Re-marking a subproduct installs all modules (manuals, etc) within that subproduct.
Accounting -> B.10.20 Accounting InternetSrvcs -> B.10.20 General network applications and daemons MailUtilities -> B.10.20 User mail agents and related tools Networking -> B.10.20 HP-UX_10.0_LanLink_Product NonHP-Terminfo -> B.10.20 Non HP terminfo files OS-Core -> B.10.20 Core Operating System SecurityMon -> B.10.20 SecurityMon SystemAdmin -> B.10.20 HP-UX System Administration Tools TextEditors -> B.10.20 TextEditors TextFormatters -> B.10.20 TextFormatters
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 swlist -l product on a secure system:
Accounting B.10.20 Accounting DCE-Core B.10.20 HP DCE/9000 Core Client Software InternetSrvcs B.10.20 General network applications and daemons LVM B.10.20 LVM MailUtilities B.10.20 User mail agents and related tools NFS B.10.20 ONC/NFS; Network-File System,Information Services,Utilities Networking B.10.20 HP-UX_10.0_Lanlink_Product NonHP-Terminfo B.10.20 Non HP terminfo files OS-Core B.10.20 Core Operating System ProgSupport B.10.20 ProgSupport SW-DIST B.10.20 HP-UX Software Distributor SecurityMon B.10.20 SecurityMon Streams B.10.20 HP-UX_10.0_Streams_Product Streams-TIO B.10.20 HP-UX_10.0_Streams-TIO_Product SystemAdmin B.10.20 HP-UX System Administration Tools TextEditors B.10.20 TextEditors TextFormatters B.10.20 TextFormatters
If you have any products that are not listed above, remove them with the swremove command. You may need to use the -x autoreboot=true option if the product requires rebooting the machine upon removal.
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 removing all extraneous startup files from /sbin/rc2.d. Remove everything from /sbin/rc2.d except the following files:
S008net.sd S230ptydaemon S525rarpd S710hparray S120swconfig S300nettl S550ddfa S730cron S200clean_ex S320hpether S565OspfMib S760auditing S204clean_tmps S340net S610rbootd S800spa S206clean_adm S500inetd S660xntpd S880swcluster S220syslogd S520rdpd S700acct
You may have additional files depending on your hardware configuration and software requirements.
Remove all the files in /sbin/rc3.d and /sbin/rd4.d
In order to insure that all of the startup scripts run with the proper umask, create and execute the following script: [2]
umask 022 # make sure umask.sh gets created with the proper mode echo "umask 022" > /sbin/init.d/umask.sh for d in /sbin/rc?.d do ln /sbin/init.d/umask.sh $d/S000umask.sh done
Remove crontab files. You should remove all files from /var/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 /var/adm/syslog/mail.log *.info;mail.none /var/adm/syslog/syslog.log *.alert /dev/console *.alert root *.emerg *
Note: Tabs must be used to separate the fields.
This will log mail entries to /var/adm/syslog/mail.log and everything else to /var/adm/syslog/syslog.log.
Set the permissions on the log files as follows:
chmod 600 /var/adm/syslog/*.log
Disable IP forwarding and turn on random TCP packet sequence numbering by adding the following two lines to /sbin/init.d/net:
########## # main # ########## case $1 in start_msg) print "Configure LAN interfaces" exit $OKAY ;; stop_msg) print "Unconfigure LAN interfaces" exit $OKAY ;; stop) exit $OKAY ;; start) /usr/contrib/bin/nettune -s ip_forwarding 0 /usr/contrib/bin/nettune -s tcp_random_seq 2 ;; # fall through
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 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
If it does not look like this. Go back and make sure that the recommended files have been removed from /etc/rc*.d.
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 /etc/mail/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 "sys", "uucp", " nuucp", and "listen". The cleanest way to shut them down is to disable them using sam.
Disable rlogin/rsh access by removing /etc/hosts.equiv, /.rhosts, and all of the "r" commands in /etc/inetd.conf.
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 /usr/sbin.
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 /usr/sbin/tcpd /usr/lbin/ftpd telnet stream tcp nowait root /usr/sbin/tcpd /usr/lbin/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/bin/ppl /usr/sbin/swinstall /usr/sbin/swinstall /usr/sbin/swacl /usr/sbin/swconfig /usr/sbin/swcopy /usr/sbin/swlist /usr/sbin/swremove /usr/sbin/swverify /usr/sbin/swreg /usr/sbin/swmodify /usr/sbin/lvchange /usr/sbin/lvcreate /usr/sbin/lvdisplay /usr/sbin/lvextend /usr/sbin/lvdisplay /usr/sbin/lvextend /usr/sbin/lvlnboot /usr/sbin/lvreduce /usr/sbin/lvremove /usr/sbin/lvrmboot /usr/sbin/pvchange /usr/sbin/pvcreate /usr/sbin/pvdisplay /usr/sbin/pvmove /usr/sbin/acct/accton /usr/sbin/lanadmin /usr/sbin/landiag /usr/lbin/expreserve /usr/lbin/exrecover
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 these:
/usr/bin/netstat /usr/sbin/wall
Create a master list of the remaining setuid/setgid programs on your system and check that the list remains static over time.
The file system defaults can be tailored to make your system more secure. The "ro" option is a software switch to prevent filesystem modifications. [1]
The "nosuid" option causes the suid bit on all programs on that partition to be ignored. This option should never be applied to anonymous FTP areas or to the filesystem where /tmp resides. [1]
Since root is mounted before /etc/fstab is available, the root partition can not be mounted with the nosuid option set.
The following is an example of a secure /etc/fstab:
/dev/vg00/lvol3 / hfs defaults 0 1 /dev/vg00/lvol1 /stand hfs nosuid 0 1 /dev/vg00/lvol4 /local_admin hfs nosuid 0 2 /dev/vg00/lvol5 /tmp hfs defaults 0 2 /dev/vg00/lvol6 /usr hfs ro 0 2 /dev/vg00/lvol7 /var hfs nosuid 0 2
All filesystems should be mounted either "nosuid" or "ro" (read-only) with the exception of FTP areas. [1]
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]
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 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 -efYou may have additional processes if: [1]
Try the following as root on the securehost:
# touch /usr/bin/should-fail touch /usr/bin/should-fail cannot createReasons 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]
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/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: |
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: /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/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/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 $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: /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 /.Xdefaultsand 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. |
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 |
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 /etc/mail/aliases. |
|
Step 1 |
Type the following command: vi /etc/mail/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/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 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/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:
|
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: /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,roAnd follow the following criteria:
|
|
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:
|
|
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 /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/passwdAny files within the /tcb directory should not be readable or writeable by anyone other than root. |
|
Comments: |