UNIX System Administrator's OS Handbook











Main Table of Contents


1.0 PATCHES
 
2.0 NETWORK SECURITY
 
3.0 FTPD & ANONYMOUS FTP
 
4.0 PASSWORD AND ACCOUNT SECURITY
 
5.0 FILE SYSTEM SECURITY
 
6.0 SECURITY AND X-WINDOWS
 
7.0 ADMINISTRATIVE ACTIONS
 






Section 1.0 Patches

Topic:Patches
 
Subtopic:Latest Patches
 
Test Objective 1.0Verify the appropriate operating system patches have been applied.
 
Operating environment SRS
Requirement:
AusCert reference 1.0
 
Rationale: 

#Required ActionExpected ResultsComments X
1From the command line as root type:

#showrev -a
Be sure to check the Operating System Vendor's web site for the latest patches. showrev displays revision information for the current hardware and software. With no arguments, showrev shows the system revision information including hostname, hostid, release, kernel architecture, application architecture, hardware provider, domain, and kernel version. The -a option prints all system revision information available. Window system and patch information are added.

Some patches may re-enable default configurations. For this reason, it is important to go through this checklist after installing any new patches or packages. In addition, a log should be maintained of all installed patches.
 












SECTION 2.0 NETWORK SECURITY

Table of Contents

2.1 Trusted Hosts
 
2.2 rhost files
 
2.3 NFS
- Verify files on server are not world-writeable or group writeable
- Ensure filesystems are mounted with nosuid option
- Verify appropriate entries are in the exports file
 
2.4
 
Security Terminals
 
2.6 Network Services
- Penetration - Is rusersEnabled?
- Penetration - Is rexdEnabled?
- Trivial FTP - Is It Enabled and Securely Configured?
- Trivial FTP - Verify Trivial FTP Is Not Running With Privileges
- Vulnerability UUCP - Verify Known Bugs Are Haven Been Fixed
- UUCP Disabled -
- Vulnerability - Determine if finger and fingerd Are Disabled -
 
2.7 File Permissions
 
2.8 Security Utility
 
2.9 Mail Aliases
 
2.10 Penetration Test
- Verify sendmail Does Not Support The "wiz" Command
- Verifysendmail Does Not Support the "debug" Command
- Verify sendmail Does Not Support the "kill" Command
- Verify sendmail -d bug Does Not Exist
 
2.11 WWW-HTTP
- Verify http Server Client and Server Processes Do Not Run as Root
Verify That http Server Daemon Is Not Run As Root






Section 2.0 Network Security

Topic:Network Security
 
Subtopic:Trusted Hosts
 
Test Objective 2.1Check 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.
 
Operating environment SRS Requirement:AusCert reference 2.3
Rationale:

One of the most convenient features of the UNIX networking software is the concept of "trusted" hosts. The software allows the specification of other hosts (and possibly users) who are to be considered trusted - remote logins and remote executions from these hosts will be permitted without requiring the user to enter a password. This is very convenient, because users do not have to type their password every time they use the network. Unfortunately, for the same reason, the concept of a trusted host is also extremely insecure.

The file /etc/hosts.equiv can be used by the system administrator to indicate trusted hosts. Each trusted host is listed in the file, one host per line. If a user attempts to login or execute a command remotely from one of the systems listed in hosts.equiv, and that user has an account on the local system with the same login name, access is permitted without requiring a password.

Provided adequate care is taken to allow only local hosts in the hosts.equiv file, a reasonable compromise between security and convenience can be achieved. Nonlocal hosts (including hosts at remote sites of the same organization should never be trusted. Also, if there are any machines at your organization that are installed in "public" areas you should not trust these hosts.


#Required ActionExpected ResultsCommentsX
1

Execute the following command:

%ls -ldgb /etc/hosts.equiv; /bin/more
/etc/hosts.equiv

The following response is displayed:

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

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

 
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 -ldgb /etc/hosts.equiv; /bin/more /etc/hosts.equiv

- The owner of /etc/hosts.equiv is root.
- The permissions of /etc/hosts.equiv are set to 600.
- The first character of /etc/hosts.equiv is not '-'.
- /etc/hosts.equiv does not contain a line with only a "+" (a plus sign).
- /etc/hosts.equiv lists only a small number of trusted hosts, and all hosts listed are within your domain or under your management.
- /etc/hosts.equiv does not include "!" or"#".
- All hosts in /etc/hosts.equiv are specified using IP addresses to mitigate DNS spoof attacks.
- Use netgroups in /etc/hosts.equiv for easier management.
- Ensure there are no machine name/user name pairs in the hosts.equiv.

The /etc/hosts.equiv file contains a list of trusted hosts, one per line. If a user attempts to log in remotely (using rlogin) or to remotely execute a command (using rsh) from one of the hosts listed in this file, and if that user has an account on the local system with the same login name, the system allows the user to log in without a password. The /etc/hosts.equiv file may have several entries. It should be verified that each entry is appropriate. A line of the form +@host-group makes all of the hosts in the network group hostgroup trusted; likewise, a line which has the form -@anotherhostgroup makes all of the hosts in the networkgroup anotherhostgroup specifically not trusted. The file is scanned from the beginning to the end; the scanning stops after the first match. A single line of + in the hosts.equiv file indicates that every known host is trusted. This can create a serious security problem. It is recommended that the /etc/hosts.equiv file be removed altogether, or that the file be replaced with a correctly configured one.

 

Topic:Network Security
 
Subtopic:.rhost files
 
Test Objective 2.2Determine if any rhost files are used on the system.
 
Operating environment SRS Requirement:AusCert reference 2.5
 
Rationale:

The .rhosts file is similar in concept and format to the hosts.equiv file, but allows trusted access only to specific host-user combinations, rather than to hosts in general. Each user may create a .rhosts file in his home directory, and allow access to his account without a password. Most people use this mechanism to allow trusted access between accounts they have on systems owned by different organizations that do not trust each other's hosts in hosts.equiv. Unfortunately, this file presents a major security problem: while hosts.equiv is under the system administrator's control and can be managed effectively, any user may create a .rhosts file granting access to whomever he chooses, without the system administrator's knowledge.

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.


#Required ActionExpected ResultsCommentsX
1

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 a .rhosts file has been found. Users should not have a .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:

the first character of any .rhosts file is not "-".

The permissions of all .rhosts files are set to 600

The owner of each .rhosts file is the account's owner

No .rhosts file contains the symbol "+" on any line

Usage of netgroups within .rhosts does not allow unintended access to this account

 
2

Comment out the entries for rshd and rlogind in the inetd.conf file

There would be no output. The commands that open .rhosts files are now disabled.  

Topic:Network Security
 
Subtopic:NFS
 
Test Objective 2.3Verify the files on the server are not world-writeable or group-writeable.
 
Operating environment SRS Requirement:AusCert reference 2.6
 
Rationale:

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-writeable or group-writeable.


#Required ActionExpected ResultsCommentsX
1

Browse the /etc/dfs/dfstab file using the following command:

#vi /etc/dfs/dfstab

and for each shared filesystem run the following command:

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

No files should be listed.Any lines starting with "share -F nfs" should also have -"o ro" in the same line. This is the option for "read only" and will insure that they are not "world-writeable". 

Topic:Network Security
 
Subtopic:NFS
 
Test Objective 2.3Ensure filesystems are mounted with the nosuid option and read-only where practical. If read-only is not practical, verify system files and user home directories are not mounted.
 
Operating environment SRS Requirement:AusCert reference 2.6
 
Rationale:

In some versions of UNIX, it is possible to turn off the SUID and SGID bits on mounted filesystems by specifying the nosuid option with the mount command. If available, this option should always be specified when a filesystem is mounted unless there is an overriding reason to import SUID or SGID files from the mounted filesystem.

One of the best ways to protect sensitive files and directories is to mount them on read-only disks. It is recommended that the following directories be mounted as read-only partitions: /, /usr/bin, /bin, /etc, /lib, /usr/lib, /usr/ucb (if it exists), /usr/include, /usr/src, /usr/etc (if it exists).


#Required ActionExpected ResultsCommentsX
1

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

#vi /etc/vfstab

The flag rw should only exist if a legitimate need exists and the flag nosuid should appear.

Each nfs entry in the /etc/vfstab file should appear similar to the following line:
#device
device mount
FS fsck mount
mount
#to mount
to fsck point
type pass at boot
options
Exporthost:/ExportDirPath
- /mountpoint
nfs - yes
ro,bg,nosuid

OR if mounting the filesystem from the command line use the following command:

example# mount -r -o nosuid,bg serv:/usr/src /usr/src

 

Topic:Network Security
 
Subtopic:NFS
 
Test Objective 2.3Verify the appropriate entries are in the exports file.
 
Operating environment SRS Requirement:AusCert reference 2.6
 
Rationale:

NFS is a distributed database system that is designed to allow several hosts to share files over the network. One of the most common uses of NFS is to allow diskless workstations to be installed in offices, while keeping all disk storage in a central location. As distributed by Sun, NFS has no security features enabled. This means that any host on the Internet may access your files via NFS, regardless of whether you trust them or not.

Fortunately, there are several easy ways to make NFS more secure. The more commonly used methods are described in this section, and these can be used to make your files quite secure from unauthorized access via NFS.

The file /etc/exports is perhaps one of the most important parts of NFS configuration. This file lists which file systems are exported (made available for mounting) to other systems.

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.

Obviously, this presents a major security problem, since anyone who can mount your file systems via NFS can then peruse them at his leisure. Thus, it is important that all file systems listed in exports have an access= keyword associated with them. Netgroups can also be specified.

Normally, NFS translates the super-user id to a special id called "nobody" in order to prevent a user with "root" on a remote workstation from accessing other people's files. This is good for security, but sometimes a nuisance for system administrators, since you cannot make changes to files as "root" through NFS.

The exports file also allows you to grant super-user access to certain file systems for certain hosts by using the root= keyword. Following this keyword, a colon-separated list of up to ten hosts may be specified.

Granting "root" access to a host should not be done lightly. If a host has "root" access to a file system, then the super-user on that host will have complete access to the file system, just as if you had given him the "root" password on the server. Untrusted hosts should never be given "root" access to NFS file systems.


#Required ActionExpected ResultsComments X
1

Use the following command to ensure that file systems are correctly exported:

/usr/bin/vi /etc/dfs/dfstab

This file will not exist if the computer being tested is not an NFS server.

Only necessary filesystems are exported.

Only authorized hosts are given access to the exported filesystems.

All entries use fully qualified hostnames (Preferably an ip address).

Filesystems are shared using "anon=-1" to disallow accesses that are not accompanied by a user ID.

The NFS server is not self-referenced, either by name or by specification of a 'localhost' entry.

File systems to be exported are shared as read-only, except where specifically approved by the responsible security officer.

Only the minimum access necessary is given on the exported filesystem.

File systems to be exported are shared non-setuid.

The "root = " option should NOT be used.

Access should be granted by netgroup or host.

Ensure that you never export file systems unintentionally to the world.
Review periodically what you currently have exported.
Run fsir and for all your file systems and rerun it periodically.
Ensure that the RPC portmapper does not allow proxy requests.

directory1 entry gives root access to client1 root. This should not be done unless absolutely necessary.
directory2 entry gives read and write access to all hosts. This should not be done.
directory3 entry gives read and write access to client1 and client2. Write access should be prohibited if not needed.
directory4 entry gives read only access to client1 and client2. This is the most desirable entry.
#!/bin/sh
share -F nfs -o- rw=client1:client2,root=client1 /directory1_to_exportshare -F nfs -o -rw, root=client1 /directory1_to_export share -F nfs -o -rw=client1:client2 /directory2_to_export share -F nfs -o ro=client1:client2 /directory3_to_export
 
2

Execute the following command and ensure that the owner and permissions of the dfstab file are correct:
#/usr/bin/ls -lg /etc/dfs/dfstab

Only necessary filesystems are exported.

Only authorized hosts are given access to the exported filesystems.

All entries use fully qualified hostnames (Preferably an ip address).

Filesystems are shared using "anon=-1" to disallow accesses that are not accompanied by a user ID.

The NFS server is not self-referenced, either by name or by specification of a 'localhost' entry.

File systems to be exported are shared as read-only, except where specifically approved by the responsible security officer.

Only the minimum access necessary is given on the exported filesystem.

File systems to be exported are shared non-setuid.

The "root = " option should NOT be used.

Access should be granted by netgroup or host.

Ensure that you never export file systems unintentionally to the world.
Review periodically what you currently have exported.
Run fsir and for all your file systems and rerun it periodically.

Ensure that the RPC portmapper does not allow proxy requests.
directory1 entry gives root access to client1 root. This should not be done unless absolutely necessary.

directory2 entry gives read and write access to all hosts. This should not be done.

directory3 entry gives read and write access to client1 and client2. Write access should be prohibited if not needed.

directory4 entry gives read only access to client1 and client2. This is the most desirable entry.

#!/bin/sh
share -F nfs -o- rw=client1:client2,root=client1 /directory1_to_export
share -F nfs -o -rw, root=client1 /directory1_to_export
share -F nfs -o -rw=client1:client2 /directory2_to_export
share -F nfs -o ro=client1:client2 /directory3_to_export

 
3Check to see if NFS port monitoring is enabled. Check to see if the line "set nfs:nfs_portmon = 1" is in the /etc/system file. If it is not, add it and reboot system.  

Topic:Network Security
 
Subtopic: 
 
Test Objective 2.4Ensure the first character in /etc/hosts.lpd does not contain a '-'. It may allow unauthorized access to the system.
 
Operating environment SRS Requirement:AusCert reference 2.7
 
Rationale: 

#Required ActionExpected ResultsComments X
1vi /etc/hosts. lpd Rearrange the order of entries in the hosts.lpd file so that the first line does not contain a leading '-' character.  
2INPUT NEEDED Remove hosts.lpd files containing only entries beginning with a '-' character. 


Topic:Network Security
 
Subtopic:Security Terminals
 
Test Objective 2.5Ensure the secure option is removed from all entries that do not require root login capabilities.
 
Operating environment SRS Requirement:

AusCert reference 2.8

 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Execute the following command as a privileged user:

vi /etc/default/login

Ensure the # sign has been removed from the line:

CONSOLE=/dev/console

By default, the # sign has been removed from this file.  
2Attempt to login into the workstation using the userid "root" from another workstation using telnet.Attempt should fail.  

Topic:Network Security
 
Subtopic:Permissions and Ownership
Test Objective 2.5Ensure the "secure terminals" file is configured correctly.
 
Operating environment SRS Requirement:AusCert reference 2.8
 
Rationale: 

#Required ActionExpected ResultsComments X
1

Ensure the "secure terminals" file is owned by root and the permissions are set to "rw-r--r--".

ls -al /etc/default/login

-r--r--r-- 1 root sys 1137 Feb
25 13:20 /etc/default/login
The default permissions, settings, and ownership are listed. The file should be owned by root and has the permission set to "rw-r--r--" 


Topic:Network Security
 
Subtopic:Network Services
 
Test Objective 2.6Verify the network services are appropriately configured and defined.
 
Operating environment SRS Requirement:AusCert reference 2.9
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Verify that the network services are configured securely by browsing the /etc/inetd.conf file using the following command:

#/usr/bin/vi /etc/inetd.conf

Unnecessary network services should be disabled.

A "#" starts each line identifying a disabled service. Verify that the following services are disabled: name, shell, login, exec, comsat, talk, uucp, finger, systat, netstat, admind, rquotad, rusersd, sprayd, walld, rstatd, rexd, and tftpd.

Services to be disabled include:
- name: obsolete name server protocol
- shell: allows remote user via rsh to run processes on this system
- login: allows remote user via rlogin
- exec: allows remote users access via rexec
- comsat: real-time intrusive notification to users that mail has arrived
- talk: remote chat protocol
- uucp: UNIX-to-UNIX copy over TCP
- finger: remote access to local user information
- systat: allows remote users to view the process table
- netstat: allows remote users to view the list of active network connections
- admind: allows remote users to execute remote administrative activities
- rquotad: provides disk quota information to NFS clients
- rusersd: provides local user information
- sprayd: allows remote users to send a stream of IP packets to the host and have them acknowledged
- walld: allows remote users to post messages to system users
- rstatd: allows remote users to view system information such as load
- rexd: obsolete remote execution server with no security
- tftpd: trivial ftp server.

 
2

Verify that the permissions of the /etc/inetd.conf file are correct using the following command:
#/bin/ls /etc/inetd.conf

The permissions are set to 600 and the owner is root.  
3

Use the following command to verify that only required and authorized network services are registered with the portmapper. The following command determines which services are registered with the Portmapper:

# /usr/bin/rpcinfo -p localhost

Only appropriate services are registered with portmapper. The following services are NOT listed: name, shell, login, exec, comsat, talk, uucp, finger, systat, netstat, admind, rquotad, rusersd, sprayd, walld, rstatd, rexd, rpc.cmsd, and rpc.ttdbserverd.  
4

Verify that the permissions and owner of the /etc/inet/services file are correct using the following command:

#/bin/ls /etc/inet/services

The permissions are set to 600 and the owner is root.  

Topic:Network Security
 
Subtopic:Penetration
 
Test Objective 2.6Determine whether rusers is enabled.
 
Operating environment SRS Requirement:AusCert reference 2.9
 
Rationale:The UNIX rusers command displays information about accounts currently active on a remote system. This may provide an attacker with account names or other information useful in mounting an attack (CERT Advisory CA-93:14).

#Required ActionExpected ResultsCommentsX
1

Type the following command from a networked host:
% rusers -a

If the error message ": RPC: Program not registered," then rusers is disabled. If instead, a list of user names and login information was generated, then a rusers server is running on the host.rusers should NOT be enabled unless there is a legitimate business need. 


Topic:Network Security
 
Subtopic:Penetration
 
Test Objective 2.6Determine whether rexd is enabled.
 
Operating environment SRS Requirement:AusCert reference 2.18
 
Rationale:The UNIX remote execution server rexd provides only minimal authentication and is easily subverted.

#Required ActionExpected ResultsCommentsX
1grep rexd inetd.conf#rexd/1 tli rpc/tcp wait root
/usr/sbin/rpc.rexd rpc.rexd
Make sure that # is the first char from the output of grep. If it is NOT, use the following steps to disable rexd: Edit the "/etc/inetd.conf" file using "vi." Add # in front of line with rexd. Save changes and exit vi. The workstation needs to be rebooted before changes will take effect. 

Topic:Network Security
 
Subtopic:Trivial FTP
 
Test Objective 2.6Determine whether Trivial FTP is enabled on the system and if enabled, verify that it has been securely configured.
 
Operating environment SRS Requirement:AusCert reference 2.10
 
Rationale:The TFTP is used to allow diskless hosts to boot from the network. Basically, TFTP is a stripped-down version of FTP - there is no user authentication. Because they are so stripped-down, many implementations of TFTP have security holes.

#Required ActionExpected ResultsComments X
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

If tftp does not respond with "File not found," and instead transfers the file, the version of tftp should be replaced with a newer one.The use of tftp does not require an account or password on the remote system. The -s options ensures that tftpd will only start with home directory and its root directory both /tftpboot. 

Topic:Network Security
 
Subtopic:Trivial FTP
 
Test Objective 2.6Verify that Trivial FTP does not run with privileges.
 
Operating environment SRS Requirement:AusCert reference 2.10
 
Rationale: 
#Required ActionExpected ResultsComments X
1

Type the following command:
% ls -lF /usr/bin/tftp
Verify that the file is not running SUID or SGID.

The tftp file should not have the SUID or SGID bits set.  
Topic:Network Security
 
Subtopic:Vulnerability - UUCP
 
Test Objective 2.6Vulnerability - UUCP
 
Operating environment SRS Requirement:AusCert reference 2.17
 
Rationale:UUCP is one of the oldest major subsystems of UNIX, and has had its share of security holes. All of the known security problems have been fixed in recent years. Unfortunately, there are still many old versions of UUCP in use.

#Required ActionExpected ResultsCommentsX
1

The mail system should not allow mail to be sent directly to a file. Test whether the system allows mail to be sent to a file with the command sequence:
$ mail /tmp/mailbug
this is a mailbug file test
^D

If the file mailbug appears in the /tmp directory, then the mailer is unsecure. If you resave the message, "saved as dead.letter", then UUCP software has passed this part of the test.If UUCP is unsecure, remove and replace the uucp software 
2

As a non-privileged user, execute the following command sequences:

$ /usr/bin/uux - mail 'root `/bin/touch /tmp/foo`'
this is a mailbug command test
^D
$ /usr/bin/uux - mail 'root & /bin/touch /tmp/foo'
this is another test
^D

Mail should be returned saying that `/bin/touch /tmp/foo` is an unknown user. If the mailer executed the touch, (a foo file will be created in the /tmp directory), then the uux program is unsecure.The UUCP system should not allow a command to be encapsulated in addresses to prevent system execution of commands encapsulated in addresses. 
3

As a non-privileged user, execute the following command sequences:
$ uux – mail 'root & /bin/touch /tmp/foo`'
this is another mailbug command test
^D
$ uux – mail 'root & /bin/touch /tmp/foo'
this is another test
^D

Mail should be returned saying that `/bin/touch /tmp/foo` is an unknown user. If the mailer executed the touch, (a foo file will be created in the /tmp directory), then the uux program is unsecure.The UUCP system should not allow a command to be encapsulated in addresses to prevent system execution of commands encapsulated in addresses. 

Topic:Network Security
 
Subtopic:UUCP Disabled
 
Test Objective 2.6Verify that UUCP is not enabled.
 
Operating environment SRS Requirement:AusCert reference 2.17
 
Rationale:UUCP is one of the oldest major subsystems of UNIX, and has had its share of security holes. All of the known security problems have been fixed in recent years. Unfortunately, there are still many old versions of UUCP in use.

#Required ActionExpected ResultsCommentsX
1

Use the following commands to ensure that uucp is not enabled or installed on the system:
#/usr/ucb/vi /etc/inetd.conf

The uucp entry in /etc/inetd.conf should NOT be enabled (i.e., the first character on the line for uucp should be a "#"). There my not be a UUCP entry in the file. This is OK.UUCP is one of the oldest major subsystems of UNIX, and has had its share of security holes. Although the design is not secure, the known security holes have been fixed in recent years. Unfortunately, there are still many old versions of UUCP in use. 
2

As root, execute the following command to ensure that uucp is not installed on the system:
/bin/find / \( -user uucp -o -name "*uu*" \) \
-exec ls –ldb {} \;

There should be no output from this command. These daemons handle UUCP file transfers and command executions and should not exist. If uucp is being used, verify that the UUCP programs are owned by uucp and not by root and have the proper permissions by executing the command below as root:

/bin/find / \( -name uuxqt -o -name uucico -o -name uusched -o -name in.uucpd -o -name uux -o -name uucp \) -exec ls -ldb {} \;

The uucp programs should run SUID uucp, not SUID root. Other than being able to read the spooled UUCP files, the uucp user doesn't have any special privileges. The output should appear similar to the output below:

# /bin/find / \( -name uuxqt -o -name uucico -o -name uusched -o -name in.uucpd -o -name uux -o -name uucp \) -exec ls -ldb {} \;
---s--x--x 1 uucp uucp 64240 Jul 15 1994 /usr/bin/uucp
---s--x--x 1 uucp uucp 68040 Jul 15 1994 /usr/bin/uux drwxr-xr-x
2 uucp uucp 512 Aug 20 16:47 /usr/lib/uucp
---s--x--x 1 uucp uucp 169096 Jul 15 1994 /usr/lib/uucp/uucico
---s--x--x 1 uucp uucp 32016 Jul 15 1994 /usr/lib/uucp/uusched
---s--x--x 1 uucp uucp 81040 Jul 15 1994 /usr/lib/uucp/uuxqt
-r-xr-xr-x 1 uucp uucp 8320 Jul 15 1994 /usr/sbin/in.uucpd
-rw-rw---- 1 uucp mail 376 Oct 14 23:45 /var/mail/uucp
-r--r--r-- 1 root sys 215 Aug 20 16:47 /var/spool/cron/crontabs/uucp
drwxr-xr-x 5 uucp uucp 512 Oct 14 23:45 /var/spool/uucp
drwxr-xr-x 7 uucp uucp 512 Aug 20 16:46 /var/uucp
drwxr-xr-x 2 uucp uucp 512 Aug 20 16:46 /var/uucp/.Log/uucico
drwxr-xr-x 2 uucp uucp 512 Aug 20 16:46 /var/uucp/.Log/uucp
drwxr-xr-x 2 uucp uucp 512 Oct 14 23:45 /var/uucp/.Log/uux
drwxr-xr-x 2 uucp uucp 512 Oct 14 23:45 /var/uucp/.Log/uuxqt
-rwxr--r-- 2 root sys 202 Jul 16 1994 /etc/init.d/uucp
drwxr-xr-x 2 uucp uucp 512 Aug 20 16:46 /etc/uucp
#

 
3Verify that the Permissions file is properly configured using the following command:
#/usr/bin/vi /etc/uucp/Permissions
If the uucp entry is enabled, the /etc/uucp/Permissions file should allow minimal access (an empty Permissions file provides minimal access). This file and or dir may not exist.The /etc/uucp/Permissions file specifies the permissions that remote computers have with respect to login, file access, and command execution. There are options that restrict the remote computer's ability to request files and its ability to receive files queued by the local machine. Another option is available that specifies the commands that a remote machine can execute on the local computer.

There are two types of Permissions file entries:
- LOGNAME Specifies the permissions that take effect when a remote computer logs into (calls) the local computer.
- MACHINE Specifies permissions that take effect when the local computer logs into (calls) a remote host.

When using the Permissions file to restrict the level of access granted to remote computers, the following issues should be considered:
- All login IDs used by remote computers to log in for UUCP communications must appear in one LOGNAME entry.
- Any site that is called whose name does not appear in a MACHINE entry, will have the following default permissions or restrictions:
- Local send and receive requests will be executed.
- The remote computer can send files to the local computer's /var/spool/uucppublic directory.
- The commands sent by the remote computer for execution on the local computer must be one of the default commands, usually rmail.

REQUEST Option When a remote computer calls the local computer and requests a file, this request can be granted or denied. The REQUEST options specifies whether the remote computer can request to set up file transfers from the local computer. The default value is REQUEST=no.

READ and WRITE Options These options specify the various parts of the file system that uucico can read from or write to. The default for both the READ and WRITE options is the uucppublic directory, /var/spool/uucppublic.
COMMANDS Option. The COMMANDS option in MACHINE entries can specify the commands that a remote computer can execute on the local computer. The COMMANDS option should be used with great care as misuse can compromise the security of a computer.

 
4Verify any UUCP jobs entered in crontab are run as the user uucp and the script file is owned by root.Jobs are run as user uucp and script files are owned by root.crontab should run all uucp scripts as the user uucp, rather than as the user root to prevent jobs from running with excessive privileges. However, the scripts themselves should be owned by root, not uucp, so they can't be modified by people using the uucp programs. 
5Determine if the system has enabled UUCP callback.UUCP callback is enabled if possible.Version 2 UUCP has a callback feature that can be used to enhance security. With callback, when a remote system calls the local computer, the system immediately hangs up on the remote system and calls back. No special callback hardware is required to take advantage of UUCP callback, because it is performed by the system software, not by the modem. Note that only one system out of each pair of communicating systems can have callback enabled. 
6

Verify uucp's home directory is in an appropriate directory using the following commands:
$grep uucp /etc/passwd
$ls -ld `grep uucp /etc/passwd \
| awk -F: 'length($6)>0 {print $6}'`

The uucp home directory should not be in a directory that is world writeable. The dir listed in /etc/passwd for UUCP my not exist. This is OK.The home directory for the uucp account should not be in the directory /usr/spool/uucp/uucppublic, or any other directory that can be written to by a uucp user. 
7

Use the following command to ensure that there is no.rhosts file in the uucp home directory:
#find `grep uucp /etc/passwd \
| awk -F: 'length($6)>0 {print $6}'` \
-name.rhosts -exec ls -ldb {} \;
Ensure that no uucp owned files or directories are world writeable.

There should be no output from this command.  
8

As root ensure that no uucp owned files or directories are world writeable using the following command:
find / -user uucp -perm -2 \
-exec ls -ldb {} \;

There is no output indicating no files on the system that are owned by uucp and world writeable.  

Topic:Network Security
 
Subtopic:Vulnerability
 
Test Objective 2.6Determine if finger and fingerd are enabled on the system. If enabled, verify finger is securely configured.
 
Operating environment SRS Requirement:AusCert reference 2.16
 
Rationale:

The "finger" service, provided by the finger program, allows you to obtain information about a user such as her full name, home directory, last login time, and in some cases when she last received mail and/or read her mail. The fingerd program allows users on remote hosts to obtain this information.

A bug in fingerd was also exercised with success by the Internet worm. If your version of fingerd is older than November 5, 1988, it should be replaced with a newer version.

The finger program has two uses: If finger is run with no arguments, the program prints the username, full name, location, login time, and office telephone number of every user currently logged into the local system. If finger is run with a name argument, the program searches through the /etc/passwd file and prints detailed information for every user with a first, last, or user name that matches the name you specified. finger makes it easy for intruders to get a list of the users on the system.


#Required ActionExpected ResultsCommentsX
1

Type in the following command:

user1>finger root@localhost

Error message indicates that the finger daemon is not enabled (e.g., "Connection Refused"). Output of information regarding root indicates that finger is enabled.Finger should NOT be enabled unless there is a legitimate need for it. Related services that should be considered for removal are systat and netstat. 
2

Execute the following command:

user1>finger @localhost

Only login information on users currently logged on the system is provided, or an error message indicates that the finger daemon is not enabled (e.g., "Connection Refused") will be displayed.There is a bug in some operating systems which allows a remote finger request to dump all known user finger profiles back out to the requester. The same hack in a different fashion on Solaris 4.1.x will give random users profile. 
3

Execute the following command:
user1>finger
23234123123123123@localhost

Only login information on users currently logged on the system are provided or an error message indicates that the finger daemon is not enabled (e.g., "Connection Refused") will be displayed.There is a bug in some operating systems which allows a remote finger request to dump all known user finger profiles back out to the requester. The same hack in a different fashion on Solaris 4.1.x  

Topic:Network Security
 
Subtopic:File Permissions
 
Test Objective 2.7Ensure that the permissions and ownership of the /etc/services file is configured properly.
 
Operating environment SRS Requirement:AusCert reference 2.11
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1ls -l /etc/services

Output should be displayed:
Input needed

The permissions on this file should be set to 644 and the owner should be root. 

Topic:Network Security
 
Subtopic:Security Utility
 
Test Objective 2.8Ensure the proper configuration of the tcp_wrapper utility.
 
Operating environment SRS Requirement:AusCert reference 2.12
 
Rationale:This software provides logging and access control to most network services. When a user tries to connect to your computer on a port, inetd looks up the port number in /etc/services, when it finds the port number it looks in the file /etc/inetd.conf for a corresponding service and runs the service. With tcp_wrappers inetd is tricked into running tcpd instead of the service that would normally be called. Tcpd then checks it's rules in the /etc/hosts.allow and /etc/hosts.deny files. It either accepts the connection and runs the service or denies the connection based on its rules.

#Required ActionExpected ResultsComments X
1
  1. Download the tcp wrappers source code.
  2. Untar-gz tcp_wrappers_7.6.tar.gz tar zxvf tcp_wrappers_7.6.tar.gz
  3. Compile and Install the wrappers program.

Now you will build and install the program.
cd tcp_wrappers_7.6
make REAL_DAEMON_DIR=/usr/sbin linux
make install <----you'll need to be logged on as root to run this command !

ftp://ftp.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.6.tar.gz  
2

Edit your /etc/hosts.allow and /etc/hosts.deny to limit access to your computer's network services.

The format of the hosts.allow/hosts.deny files is as follows:
service: hostname: banners if needed : options

Example /etc/hosts.allow looks like the following----> --------------------------------------------
in.fingerd: ALL : banners /usr/local/etc/banners/ : spawn (echo "Access from %u@%h using %d." | sendmail auth) : DENY
in.telnetd: .lamers.edu : spawn (echo "Access from %u@%h using %d." | sendmail auth : DENY
ALL: ALL : spawn (echo "Access from %u %h using %d." | sendmail auth)
In the first line "in.fingerd" is the service, the hostname is "ALL" which means the rule applies to all hosts , then we tell tcpd to display the banner to the user, and finally we tell tcpd to start (spawn) another program that emails the message "Access from some-user@some.host.com using in.fingerd" to the user "auth"..finally it tells tcpd the "DENY" access. For this to work you will need a user on your system called "auth", many people send it to "root" but then you have to be logged in as root to read it, also it clutters root's mailbox and makes it difficult to sort your tcpd mail from other "root" mail.

The second rule follows the same format as the first, it denies access to telnet to all users from "lamers.edu", and sends email to auth.

The third rule allows access to all users from everywhere but email's "auth" with details of the connection.

Each rule goes on it's own unbroken line.

"man 5 hosts_access" for more information.

 
3Edit your /etc/syslog.conf to use the syslog with tcpd.

Here are a few lines of a typical /etc/syslog.conf:

*.err;kern.debug;auth.notice;mail.crit/dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
mail.info /var/log/maillog

Here are a few lines of our edited /etc/syslog.conf:
*.err;kern.debug;auth.notice;mail.crit /dev/console

*.notice;kern.debug;lpr.info;mail.crit;news.err;auth.info /var/log/messages
mail.info /var/log/maillog

The difference is the added line for auth.info logging to /var/log/messages. 
4Edit /etc/inetd.conf to point your services to tcpd.

The following example has the original lines commented (#) out and our modified tcpd lines inserted.
#ftp stream tcp nowait root /usr/sbin/ftpd ftpd -l -a
ftp stream tcp nowait root /usr/sbin/tcpd ftpd -l -a
#telnet stream tcp nowait root /usr/sbin/telnetd telnetd
telnet stream tcp nowait root /usr/sbin/tcpd telnetd
#finger stream tcp nowait nobody /usr/sbin/fingerd fingerd -s

Linux differs from some *unix's in that the file locations aren't quite "standard", so when you install tcp_wrappers the "tcpd" file may be in the "/usr/libexec" directory, in which case you'll have to change "/usr/sbin/tcpd" to "/usr/libexec/tcpd" in the above example.

If everything is correct you can reboot or restart inetd and syslogd . 

Topic:Network Security
Subtopic:Mail Aliases
 
Test Objective 2.9Verify the "decode" and "uudecode" aliases have been removed from the aliases file (/etc/aliases or /usr/lib/aliases).
 
Operating environment SRS Requirement:AusCert reference 2.13
 
Rationale:The decode alias allows mail to be sent directly to the uudecode program. This is a security hole.

#Required ActionExpected ResultsCommentsX
1

Type the following command:
#vi /etc/aliases
Search for decode by typing "/decode" and press return.

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

Pattern not found

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

After modifying the /etc/aliases file the /etc/newaliases executable must be executed. 

Topic:Network Security
Subtopic:Penetration Test
 
Test Objective 2.10Verify that .
 
Operating environment
SRS Requirement:
Verify that sendmail does not support the "wiz" command
 
Rationale:A person who knows the wizard password can connect to the computer's sendmail daemon and start a shell without logging in.

#Required ActionExpected ResultsCommentsX
1

Type in the following commands:
% telnet localhost 25
wiz
quit

Sendmail should respond to the wiz command with "5nn error return" (e.g., "500 Command unrecognized"). Any response from the server indicating recognition of the command indicates a sendmail vulnerability and sendmail should be replaced.

The session should appear similar to the following:
user>telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ziggy. Sendmail 5.x/SMI-SVR4
ready at Fri, 18 Oct 1996 15:48:03 -
0400
wiz
500 Command unrecognized
quit
221 ziggysol24. closing connection
Connection closed by foreign host.
user>

  

Topic:Network Security
 
Subtopic:Penetration Test
 
Test Objective 2.10Verify that sendmail does not support the "debug" command..
 
Operating environment SRS Requirement:AusCert reference 2.14
 
Rationale 

#Required ActionExpected ResultsCommentsX
1

Type in the following command:
% telnet localhost 25
debug
quit

Sendmail should respond to the debug command with "5nn error return" (e.g., "500 Command unrecognized"). Any response from the server indicating recognition of the command indicates a sendmail vulnerability and sendmail should be replaced.

The session should appear similar to the following:

user>telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ziggy. Sendmail 5.x/SMI-SVR4
ready at Fri, 18 Oct 1996 15:48:03 -
0400
debug
500 Command unrecognized
quit
221 ziggysol24. closing connection
Connection closed by foreign host.
user>

  

Topic:Network Security
 
Subtopic:Penetration Test
 
Test Objective 2.10Verify that sendmail does not support the kill command.
 
Operating environment SRS Requirement:AusCert reference 2.14
 
Rationale: 

#Required ActionExpected Results CommentsX
1

Type in the following command:
% telnet localhost 25
kill
quit

Sendmail should respond to the kill command with "5nn error return" (e.g., "500 Command unrecognized"). Any response from the server indicating recognition of the command indicates a sendmail vulnerability and sendmail should be replaced.

The session should appear similar to the following:
user>telnet localhost 25
25 Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ziggy. Sendmail 5.x/SMI-SVR4
ready at Fri, 18 Oct 1996 15:48:03 -
0400
kill
500 Command unrecognized
quit
221 ziggysol24. closing connection
Connection closed by foreign host.
user>

  

Topic:Network Security
 
Subtopic:Penetration Test
 
Test Objective 2.10Verify that the sendmail -d bug does not exist.
 
Operating environment SRS Requirement:AusCert reference 2.14
 
Rationale: 

#Required ActionExpected Results CommentsX
1

From a command shell, execute the following command:
# /usr/lib/sendmail -d3294967296

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. 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. If a segmentation fault is caused, there is likely a bug in the sendmail executable. 

Topic:Network Security
 
Subtopic:WWW-HTTP
 
Test Objective 2.11Verify http client and server processes are not being run as root.
 
Operating environment SRS Requirement:AusCert reference 2.19
 
Rationale: 

#Required ActionExpected Results CommentsX
1

Use the following command to verify that the http client applications are not being run as root:

#/usr/bin/find / -name "*osaic*" \ -exec ls -ldb {} \;

#/usr/bin/find / -name \"*etscape*" \ -exec ls -ldb {} \;

#/usr/bin/find / -name "http*" \-exec ls -ldb {} \;

The file permissions on all http clients and servers listed are not owned by root and are not SUID.Check configuration. 

Topic:Network Security
 
Subtopic:WWW-HTTPD
 
Test Objective 2.11Verify the http server daemon is not being run as root, but as a specially created nonprivileged user such as "httpd."
 
Operating environment SRS Requirement:AusCert reference 2.19
 
Rationale: 






SECTION 3.0 FTPD & ANONYMOUS FTP

Table of Contents

#Required ActionExpected Results CommentsX
1

As root, execute the following command:

#/bin/find / -name "*http*" \-exec ls –ldb {} \;

File permission listing reveals that the owner of the http server daemon (usually httpd) is not root and not SUID, but as a specially created nonprivileged user such as "httpd."  
3.2 FTPD
 
- FTP - Verify FTP Users File Contains Appropriate Accounts
 
- FTP Vulnerability - Check For Early FTP Bug Allowing User Root Login
 
3.3 Anonymous FTP
 











Topic:FTPD & ANONYMOUS FTP
 
Subtopic:FTPD
 
Test Objective 3.2Verify the FTPD version is the latest available.
 
Operating environment SRS Requirement:AusCert reference 3.1
 
Rationale: 

#Required ActionExpected Results CommentsX
1#showrev -aContact the ftpd software vendor to determine the latest version available.showrev displays revision information for the current hardware and software. With no arguments, showrev shows the system revision information including hostname, hostid, release, kernel architecture, application architecture, hardware provider, domain, and kernel version. The -a option prints all system revision information available. 

Topic:FTPD & ANONYMOUS FTP
 
Subtopic:FTP
 
Test Objective 3.2Verify the FTP users file contains the appropriate accounts
 
Operating environment SRS Requirement:AusCert reference 3.2
 
Rationale:The /etc/ftpusers file contains a list of the 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.

#Required ActionExpected Results CommentsX
1

Type the following commands:
ls -lg /etc/ftpusers
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 uucp, news, bin, ingress, news, nobody, daemon, and root.The ftpusers file should contain a list of users who are not allowed access to the system using the File Transfer Protocol (FTP). If this file is missing, the list of users is considered to be empty, so that any user may use FTP to access the system if the other criteria for access are met. 

Topic:FTPD & ANONYMOUS FTP
 
Subtopic:FTP Vulnerability
 
Test Objective 3.2Check for an early FTP bug that allows user login as root.
 
Operating environment SRS Requirement:AusCert reference 3.2
 
Rationale:While looking at ftp, one should check for an older bug that was once widely exploited.

#Required ActionExpected Results CommentsX
1

From a networked host, type the following commands to check for an early FTP bug:
% ftp -n
ftp> open <localhost>
ftp> quote user ftp
ftp> quote user ftp

If the bug is not fixed, the user will now be logged in as root.The ftp bug should be fixed. 

Topic:FTPD & ANONYMOUS FTP
 
Subtopic:Anonymous FTP
 
Test Objective 3.3Determine whether anonymous FTP is enabled on the system. If anonymous FTP is enabled, verify that it has been securely configured.
 
Operating environment SRS Requirement:AusCert reference 3.2
 
Rationale:Anonymous FTP allows users who do not have an account on a machine to have restricted access in order to transfer from a specific directory. Because the anonymous FTP feature allows anyone to access the system (albeit in a very limited way), it should not be made available on every host on the network. If anonymous ftp is required, one machine should be chosen (preferably a server or standalone host) on which to allow this service.

 
#Required ActionExpected Results CommentsX
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., mcguire@ncr.disa.mil) as the password. Type the following commands to ascertain whether anonymous ftp is enabled:
% ftp <hostname>
name (localhost:idname): anonymous

If the error message "530 User anonymous unknown" is returned then anonymous ftp is disabled. NOTE: If this is the case, do not complete the rest of the steps for this test. If the system instead replies with the "string 331 Guest login ok" and then prompts for a password, anonymous ftp access is enabled and the rest of the test steps should be completed.Anonymous ftp should not be enabled unless there is a legitimate business need. 
2To determine if anonymous ftp is securely configured, verify that the ftp account has been created and has been disabled by placing an asterisk (*) in the password field. Verify that the account has been given a special home directory, such as /usr/ftp or /usr/spool/ftp.   
3To determine if anonymous ftp is securely configured, verify that the ftp account has been created and has been disabled by placing an asterisk (*) in the password field. Verify that the account has been given a special home directory, such as /usr/ftp or /usr/spool/ftp.   
4Verify that the directory ftp/bin is owned by the super-user and unwriteable by anyone. Verify that a copy of the ls program is in this directory.   
5Verify that the directory ftp/etc is owned by the super-user and unwriteable by anyone. Verify that copies of the password and group files are in this directory, with all the password fields changed to asterisks (*). Note that the only account that must be present is "ftp."   
6Verify that the directory ftp/pub is owned by "ftp" and world-writeable.  











SECTION 4.0 PASSWORD & ACCOUNT SECURITY

Table of Contents

4.1 Password Management - Verify Password Expiration Date and Minimum Length Set Appropriately
 
4.2 Account Security
 
4.3 Password Security
 
4.4 NIS, NIS+ and /etc/ Password Entries
 
4.5 Password Management - Enusre Authentication Data is Protected From Unauthorized Users
 
4.6 Password Management - Verify System Enforces User Accountability...
 
4.7 Accounts
 
4.8 Password Management - Ensure Installation-provided User IDs Have No Default Passwords
 
4.9 LOGIN
 
4.10 Path
 
4.11 .netrc files






Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Password Management
 
Test Objective 4.1Verify that the default password expiration and minimum password length are set appropriately.
 
Operating environment SRS Requirement:

AusCert reference 4.1

The IT Specialist/System Manager shall manage the creation, use and deletion of user IDs and password to prevent unauthorized access to the system.

Whenever possible, passwords shall be user generated under the supervision of access control software. In facilities where access control software is not available, the IT Specialist/System Manager shall create and distribute user passwords in a controlled manner, and in such a way that an audit record of password date and time of issuance, receipt, use, change, expiration and termination is maintained.

 
Rationale:Some systems allow the system administrator to set a "lifetime" for passwords. Users whose passwords are older than the time allowed are forced to change their passwords the next time they log in. If a user's password is exceptionally old, the system may prevent the user from logging in altogether.

#Required ActionExpected Results CommentsX
1

Review the following file:
/etc/default/passwd

The following parameters should be set to appropriate values:
ttys = all
logintimes = 0
logindisable = 0
loginreenable = 0
logininterval = 0
logindelay = 0
logintimeout = 60
maxage = 12
maxrepeat = 2
maxexpired = 4
histexpire = 52
histsize = 8
pwdwarntime = 5
pwdwarntime = 5
minother = 1
minlen = 6
mindiff = 3

ttys =Defines which terminal can access the user account.
Logintimes = times a user can login.
logindisable = port is locked after a number of failed logins.
loginreenable = time to re-enable the port.
logininterval = the time the port is blocked.
logindelay = time delay between unsuccessful attempts.
logintimeout = time between entering a user id and password.
maxage = force change after 12 weeks.
maxrepeat = max three repeated characters.
maxexpired = allow login 4 weeks after expired.
histexpire = prohibit reuse of password for 52 weeks.
histsize = prohibit reusing last 8 passwords.
pwdwarntime = start warning 5 days before expire.
minalpha = min number of alpha characters.
minother = min number of non-alpha characters.
minlen = min length of password.
mindiff = min characters difference to the previous password.
 
2

To determine the password aging set for individual users, execute the following command:

# logins -x

Password aging should be set appropriately.The -x option of the logins command prints an extended set of information about each selected user. The extended information includes home directory, login shell and password aging information, each displayed on a separate line. The password information consists of password status (PS for password, NP for no password or LK for locked). If the login is passworded, status is followed by the date the password was last changed, the number of days required between changes, and the number of days allowed before a change is required. The password aging information shows the time interval that the user will receive a password expiration warning message (when logging on) before the password expires. 

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Account Security
 
Test Objective 4.2Verify that the system configuration disables user accounts after 3 unsuccessful attempts.
 
Operating environment SRS Requirement:

IT Specialists/System Managers must limit unsuccessful logon attempts from any workstation to three. After three unsuccessful logon attempts, the system shall automatically lock out the workstation. Only the system staff shall be given the capability to reset a workstation after lockout.

 
Rationale: 

#Required ActionRequired Action CommentsX
1Input needed.

The following configuration settings are displayed:

Input needed.

  

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Password Security
 
Test Objective 4.3Verify that passwords are hidden from view when logging into the operating system.
 
Operating environment SRS Requirement:The IT Specialist/System Manager shall ensure that password file maintenance shall be restricted to the IT Specialist/System Manager, and passwords shall be screen-suppressed during logon and re-authentication.
 
Rationale: 

#Required ActionExpected Results CommentsX
1Login to the operating system.The password field will be screen-suppressed from view during the login process.  

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:NIS, NIS+ and /etc/password entries
 
Test Objective 4.4Ensure that NIS/NIS+ is either disable or configured properly.
 
Operating environment SRS Requirement:AusCert reference 4.3
 
Rationale:NIS/NIS+ provides distributed network access to information sources such as password, group and host information. It maintains this information in the form of NIS/NIS+ tables. NIS/NIS+ tables contain the administrative information normally supplied by local files (such as /etc/passwd). As with the standard Unix administration files, setting secure permissions on the NIS/NIS+ tables is of utmost importance in maintaining system security.

#Required ActionExpected Results CommentsX
1

To check the permissions on the NIS/NIS+ passwd table, sites can use:

# niscat -o passwd.org_dir
Object Name : passwd
Owner : myhost.mydomain.org.
Group : admin.mydomain.org.
Domain : org_dir.mydomain.org.
Access Rights : ----rmcdrmcd----
Time to Live : 12:0:0
Object Type : TABLE
Table Type : passwd_tbl
Number of Columns : 8
Character Separator : :
Search Path :
Columns :
[0] Name : name
Attributes :
(SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---------------
[1] Name : passwd Attributes : (TEXTUAL DATA) Access Rights : -----m----------
[2] Name : uid Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---------------
[3] Name : gid Attributes : (TEXTUAL DATA) Access Rights : r------
[4] Name : gcos Attributes : (TEXTUAL DATA) Access Rights : r---------------
[5] Name : home Attributes : (TEXTUAL DATA) Access Rights : r---------------
[6] Name : shell Attributes : (TEXTUAL DATA) Access Rights : r---------------
[7] Name : shadow Attributes : (TEXTUAL DATA) Access Rights : ----------------

This output shows two types of access rights associated with the NIS/NIS+ passwd table. First, the default access rights for the table, which are given at the start of the output (----rmcdrmcd----). Second, the access rights associated with each column.

In particular, sites should check the access rights on the columns of the NIS/NIS+ passwd table. It should be noted that it appears that individual entries of the passwd table are owned by individual users. The example access rights do not allow a user to modify any part of their passwd table entry besides their own passwd field. For many environments this is acceptable.

However, depending on the local site configuration and requirements, additional access rights may also be needed.

- Sites that have their NIS+ servers running in NIS compatibility mode to serve NIS clients may require (r)ead permission for nobody on the NIS+ passwd table.

- Sites that are using password aging may require additional access rights on the shadow column. The exact access rights will depend on the particular NIS+ version (including patches). Sites are encouraged to check their local documentation for more information.

  
2

Sites may set the access rights on the NIS+ passwd table, as shown in the above output, by issuing the following commands as root on the master NIS+ server.

To set the default access rights for the NIS+ passwd table:

# nischmod na-rmcd,og+rmcd passwd.org_dir

To set the column access rights on the NIS+ passwd table:

# nistbladm -u name=na-rmcd,n=r passwd.org_dir
# nistbladm -u passwd=na-rmcd,o=m passwd.org_dir
# nistbladm -u uid=na-rmcd,n=r passwd.org_dir
# nistbladm -u gid=na-rmcd,n=r passwd.org_dir
# nistbladm -u gcos=na-rmcd,n=r passwd.org_dir
# nistbladm -u home=na-rmcd,n=r passwd.org_dir
# nistbladm -u shell=na-rmcd,n=r passwd.org_dir
# nistbladm -u shadow=na-rmcd passwd.org_dir

After making any changes in access rights, AUSCERT recommends that sites verify the changes they have made using niscat(1), as shown previously.  
3Ensure that the only machines that have a '+' entry in the /etc/passwd files are NIS (YP) clients; NOT the NIS master server!

Try using NIS with the '*' in the password field for example:
+:*:0:0:::

With the '*' removed, try logging in again.

If NIS users cannot log in to that machine, remove the '*' and try the next test.

If NIS users can log in AND you can also log in unauthenticated as the user '+', then your implementation is vulnerable.

If NIS users can log in AND you cannot log in as the user '+', your implementation should not be vulnerable to this problem.

 
4

Ensure that /etc/rc.local or the equivalent startup procedure is set up to start ypbind with the -s option.

Input needed.

 This may not be applicable on all systems. Check your documentation. 
5

Ensure secure RPC is not enabled.

Input needed.


 

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Password Management
 
Test Objective 4.5Ensure authentication data is protected from being accessed by unauthorized users.
 
Operating environment SRS Requirement:

AusCert reference 4.4

The IT Specialist/System Manager must control access to specialized system software, utilities, and functionality that could be used to gain unauthorized access to application data and program code. The IT Specialist/System Manager must keep access to these resources to the minimum number of authorized users required to accomplish program objectives.

 
Rationale:It is no longer considered secure to place even encrypted passwords in the world-readable /etc/passwd file. As a result, numerous vendors have introduced shadow password files. These files have the same encrypted passwords, but the passwords are stored in special files that cannot be read by most users on the system .

#Required ActionExpected Results CommentsX
1ls -ld /etc/shadow

The following permissions are displayed:

-r-------- root sys /etc/shadow

  

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Password Management
 
Test Objective 4.6Verify the system enforces individual user accountability, a globally-unique valid userID and password is required for all users to access the system, and the user's identity is associated with all auditable actions performed.
 
Operating environment SRS Requirement:


AusCert reference 4.5

IT Specialists/System Managers must assign individual users a minimum three character user-ID. The user-ID shall be unique to each user and shall identify the user to the system. The assignment of more than one user or a phantom user to a user-ID is prohibited. The IT Specialist/System Manager shall ensure that each system user is assigned a valid and appropriate logon procedure to control the processing options available to the system user.

Simply put, accounts without passwords should not be allowed on any system. An account without a password is an easy target for an intruder and subjects the entire system to risk.

 
Rationale:The Administrator account has virtually unlimited user rights and cannot be locked out. Changing its name to one that is a closely held secret makes it more difficult for an attacker to determine the password.

#Required ActionExpected Results CommentsX
1

As root execute the following command:

# logins -p

There should be no output from this command. This indicates that all accounts have passwords.

NOTE: If a password of is assigned by root, this test does not work as the password field in /etc/shadow contains a value for the password. The only remedy for this is a dictionary search.

The logins -p command provides a list of login accounts that have no passwords. The output of this command can be used to make sure that all users on the system have a password. 

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Accounts
 
Test Objective 4.7Verify there are no guest accounts on the system.
 
Operating environment SRS Requirement:

AusCert reference 4.6

The IT Specialist/System Manager shall manage the creation, use and deletion of user IDs and password to prevent unauthorized access to the system.

 
Rationale: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.

#Required ActionExpected Results CommentsX
1

If NOT running NIS, browse the /etc/passwd file to determine if there is a guest account using the following command:

#/usr/bin/vi /etc/passwd

OR if running NIS, determine if there is a guest account on the system by executing the following command:

#/bin/niscat passwd.org_dir

Guest accounts should not exist.If a Guest account is present and has been approved for use, the Guest account should not have a trivial password. Try logging into the account using simple passwords such as "guest" and "visitor". 

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Password Management
 
Test Objective 4.8Verify the installation-provided userIDs do not have default passwords.
 
Operating environment SRS Requirement:

AusCert reference 4.6

The IT Specialist/System Manager shall manage the creation, use and deletion of user IDs and password to prevent unauthorized access to the system.

 
Rationale:Several accounts come pre-installed on a computer system. (For example, on a UNIX 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.

#Required ActionExpected Results Expected ResultsX
1

Attempt to log into each of the following IDs with its default password:

Userid: guest
Password: guest

Userid: root
Password: root
Userid: system
Password: manager

The default passwords should not be valid for the accounts.After installation be sure to change all default passwords, lock the account, or delete the account.

COPS, Tiger, and SPI check for common default passwords.

 

 
Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Login
 
Test Objective 4.9Verify the system prohibits direct login as a trusted user (e.g., root). Also verify the system requires trusted users to change their effective userID to gain access to root (e.g., su) and to reauthenticate before requesting access to privileged functions.
 
Operating environment SRS Requirement:AusCert reference 4.7
 
Rationale:

#Required ActionExpected Results CommentsX
1

Browse the following file:

/etc/default/login

The following line should be uncommented in the /etc/default/login file:

CONSOLE=/dev/console

This ensures that root can only log in at the system console, not from any remote terminal.

The file /etc/default/login is owned by root.

The file /etc/default/login has permissions 644.

An entry in the file /etc/default/login determines the root access restrictions. If the following command appears in the file, then root access is restricted to the console:

CONSOLE=/dev/console

Any user who tries to remotely log into the system must first login to his account, and then use the su command to become root. (Security, Performance, and Accounting Administration)

 

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:Path
 
Test Objective 4.10Verify root's search path is correct.
 
Operating environment SRS Requirement:AusCert reference 4.7
 
Rationale: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 writeable by other users.

#Required ActionExpected Results CommentsX
1

As root execute the following commands:

#echo $PATH

OR

review the root search path found in the /.profile, /.cshrc, and /.login files.

Root's search path does not include the current directory (specified by a ".").  
2

As root, execute the following command:

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

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

Topic:PASSWORD & ACCOUNT SECURITY
 
Subtopic:.netrc files
 
Test Objective 4.11Verify netrc files are not used.
 
Operating environment SRS Requirement:AusCert reference 4.8
 
Rationale: 

#Required ActionExpected Results CommentsX
1

As root execute the following command:

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

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

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

 










SECTION 5.0 FILE SYSTEM SECURITY

Table of Contents

5.1 .exrc files
 
5.2 .forward files
 
5.3 Permissions
 
5.4 Vulnerability - Expreserve
 
5.5 NFS
 
5.6 Unauthorized Device Files
 
5.8 Permissions
- Permissions - Verify Correct Settings on all "temp" Directions Permissions
 
5.9 Permissions - Identify all World-writeable Files on System
 
5.10 Permissions - Identify suid and sgid Files on System
 
5.11 User Environment Configuration
 
5.12 Privileged Accounts
- Verify Root Startup files Only Writeable By Root
- Verify Verify Root Executables Owned By Root and Not World or Group-writeable
 
5.13 Configuration










Topic:FILE SYSTEM SECURITY
 
Subtopic: .exrc files
 
Test Objective 5.1Ensure that there are no .exrc files on your system that have no legitimate purpose.
 
Operating environment SRS Requirement:AusCert reference 5.1
 
Rationale:These files may inadvertently perform commands that may compromise the security of your system if you happen to start either vi(1) or ex(1) in a directory which contains such a file.

#Required ActionExpected Results CommentsX
1

As root execute the following command:


# /bin/find / -name '.exrc' -exec /bin/cat {} \; -print

Any output indicates the existence of a .exrc file on the system. The file path, permissions and contents are printed. There should NOT be any unauthorized output from this command.The .exrc file should not exist on a secure system. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:.forward files
 
Test Objective 5.2Ensure that any .forward files in user home directories do not execute an unauthorized command or program.
 
Operating environment SRS Requirement:AusCert reference 5.1
 
Rationale:The mailer may be fooled into allowing a normal user privileged access.

#Required ActionExpected Results CommentsX
1

As root execute the following command:

# /bin/find / -name '.forward' -exec /bin/cat {} \; -print

 Review the output to ensure that all commands are authorized. Authorized programs may be restricted through use of smrsh.nbsp;

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.3Verify the startup and shutdown scripts are valid and protected.
 
Operating environment SRS Requirement:AusCert reference 5.2
 
Rationale: 

#Required ActionExpected Results CommentsX
1

As root, execute the following command:

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

There should be no output indicating that the /etc directory and its contents are not group or world writeable.  
2Review all startup and shutdown scripts and configuration files. These scripts are located in the /etc/init.d directory.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 bootup and shutdown is not writeable by a user other than root.Note: The startup files can be found in the "/etc/rc?.d" directories. The startup files in these directories are hard links to the files in /etc/init.d. The "/etc/rc?" files are scripts used to run the executables located in the "/etc/rc?.d" directories. There is no need to check them. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Vulnerability - Expreserve
 
Test Objective 5.4Verify that the expreserve executable is secure.
 
Operating environment SRS Requirement:AusCert reference 5.3
 
Rationale: 

#Required ActionExpected Results CommentsX
1

Type in the following commands:

#showrev -p
#find / -name "*preserve*" \-exec ls -lgdb {} \;

Check to see if the expreserve executable is setuid root. If not, the following procedure won't work:

  1. cd into to your home directory
  2. Create a file called "bin" containing the following lines:
    # (IFS= should be followed by a single space then return) IFS=' 'cp /bin/sh /the/path/to/your/home/directory/xyzzy chmod 4755 xyzzy
  3. After saving the file (and exiting the editor) Type:

    % chmod 755 bin
    % /bin/sh
  4. From this Bourne shell, type:

    IFS=/ vi
  5. You should be in vi. Type "a" (return) and then type a couple of lines of random text into the buffer.
  6. Type: <Escape> :preserve
  7. Next exit the editor using the command:

    <Escape> :wq
  8. Enter the command:

    % ls -l xyzzy
   
2

Check to see if the expreserve executable is setuid root. If not, the following procedure won't work:

  1. cd into the test working directory.
  2. Create a file called "bin" containing the following lines:

    # (IFS= should be followed by a single space then return)
    IFS=' '
    cp /bin/sh./xyzzy
    chmod 4755./xyzzy
  3. After saving the file (and exiting the editor) Type:
    % chmod 755 bin
    % /bin/sh
  4. From this Bourne shell, type:

    IFS=/ vi
  5. You should be in vi. Type "a" (return) and then type a couple of lines of random text into the buffer.
  6. Type: <Escape> :preserve
  7. Next exit the editor using the command:

    <Escape> :wq
  8. Enter the command:

    % ls -l xyzzy
There should not be a setuid root Bourne shell in the test working directory. If the ex command ":preserve" fails, instead you can run a shell from within vi with the command ":shell", from the shell get the pid of the editor and kill it with a hangup signalRemoval of executable permission will protect the system from this vulnerability, but will also mean that users who edit their files with either vi(1) or ex(1) and have their sessions interrupted, will not be able to recover their lost work. If the above workaround id implemented, please advise the users to regularly save their editing sessions. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:NFS
 
Test Objective 5.5Ensure filesystems are mounted with the nosuid option and read-only where practical. If read-only is not practical, verify system files and user home directories are not mounted.
 
Operating environment SRS Requirement:AusCert reference 5.4
 
Rationale:

In some versions of UNIX, it is possible to turn off the SUID and SGID bits on mounted filesystems by specifying the nosuid option with the mount command. If available, this option should always be specified when a filesystem is mounted unless there is an overriding reason to import SUID or SGID files from the mounted filesystem.

One of the best ways to protect sensitive files and directories is to mount them on read-only disks. It is recommended that the following directories be mounted as read-only partitions: /, /usr/bin, /bin, /etc, /lib, /usr/lib, /usr/ucb (if it exists), /usr/include, /usr/src, /usr/etc (if it exists).One of the best ways to protect sensitive files and directories is to mount them on read-only disks. It is recommended that the following directories be mounted as read-only partitions: /, /usr/bin, /bin, /etc, /lib, /usr/lib, /usr/ucb (if it exists), /usr/include, /usr/src, /usr/etc (if it exists).


Each nfs entry in the /etc/vfstab file should appear similar to the following line:

#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
Exporthost:/ExportDirPath - /mountpoint nfs - yes ro,bg,nosuid

OR if mounting the filesystem from the command line use the following command:
example# mount -r -o nosuid,bg serv:/usr/src /usr/src

#Required ActionExpected Results CommentsX
1

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

#vi /etc/vfstab

The flag rw should only exist if a legitimate need exists and the flag nosuid should appear. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Unauthorized Device Files
 
Test Objective 5.6Ensure no unauthorized device files are present on the system.
 
Operating environment SRS Requirement:AusCert reference 5.4
 
Rationale:The system's disks should be periodically scanned for unauthorized device files.

#Required ActionExpected Results CommentsX
1

As root, execute the following command:

#/bin/find / \( -type c -o -type \b \) -exec ls -lgdb {} \; | \grep -v "/dev/" | grep -v "/devices/"

There are no unexpected special files outside the /dev directory.

Any device outside the /dev and /devices directory should be viewed with GREAT suspicion.

NOTE: ncheck locates SUID files also. The -s parameter of the ncheck command displays special files and files with set-user-ID mode. This parameter can be used to discover concealed violations of security policy. The ncheck command would be run as root and executed as follows:
#/etc/ncheck -s

 
2

As root, execute the following command:

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

All files in /dev and /devices are special files.  
3

As root, execute the following command:

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

There are no special device files owned by root that should not be owned by root.Any device outside the /dev and /devices directory not owned by root and should be viewed with even GREATER suspicion. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.8Verify that permissions on VARIOUS files and directories are set correctly.
 
Operating environment SRS Requirement:AusCert reference 5.5
 
Rationale: 

#Required ActionExpected Results CommentsX
1

# /bin/chmod 644 /etc/utmp
# /bin/chmod 2755 /etc/sm
# /bin/chmod 2755 /etc/sm.bak
# /bin/chmod 644 /etc/state
# /bin/chmod 644 /etc/motd
# /bin/chmod 644 /etc/mtab
# /bin/chmod 644 /etc/syslog.pid

# /bin/chmod 644 /etc
# /bin/chown root /etc
# /bin/chmod 644 /usr/etc
# /bin/chown root /usr/etc
# /bin/chmod 644 /bin
# /bin/chown root /bin
# /bin/chmod 644 /sbin
# /bin/chown root /sbin
# /bin/chmod 644 /usr/sbin
# /bin/chown root /usr/sbin

# /bin/chown root /tmp
# /bin/chown root /var/tmp

# /bin/chgrp 0 /tmp
# /bin/chmod 1777 /tmp
# /bin/chmod 1777 /var/tmp

 DO consider removing read access to files that users do not need to access. ENSURE that the kernel (e.g., /vmunix) is owned by root, has group set to 0 (wheel on SunOS) and permissions set to 644. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.8Verify that permissions on all "temp" directories are set correctly.
 
Operating environment SRS Requirement:AusCert reference 5.5
 
Rationale: 

#Required ActionExpected Results CommentsX
1

Obtain a list of all temp directories on the system. A temp directory is any directory that is used to write scratch files. The main temp directories for Solaris 2.5.1 include: /tmp and /var/tmp /usr/tmp. Use the following command to check the permissions on any temp directories:

ls -l <temp dir name>

Output similar to the following should be displayed:

drwxrwxrwt 5 sys sys 846
Apr 15 13:11.

Note: The last character in the permissions, execute permission for "other", should be a "t", signifying that the sticky bit is set. If it is not set, execute the following command: "chmod +t <dir name>". Recheck the permissions on the directory. 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.9Identify all world-writeable files on the system and verify their need for world-write access.
 
Operating environment SRS Requirement:AusCert reference 5.5
 
Rationale:World-writeable files, directories, and devices represent a potential security hole in a system. It is important to periodically identify them and verify the need for world-write access. Notable files that may be world-writeable include: /tmp, /usr/tmp, and /dev/tty*

#Required ActionExpected Results CommentsX
1

As root, execute the following commands:

# /bin/find / -type f \( -perm \
-2 -o -perm -20 \) -exec ls -lgb {} \;

# /bin/find / -type d \( -perm \
-2 -o -perm -20 \) -exec ls -lgdb {} \;

There are no unexpected world writeable files or directories on your system. Files should be world-writeable only if there is a legitimate requirement.

COPS, Tiger, SPI all provide checking of file permissions.

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

/tmp and contents
/var/tmp and contents
/var/preserve
/var/mail
(and many more...)

 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.10Identify the SUID and SGID files on the system and verify their need for SUID and SGID privilege.
 
Operating environment SRS Requirement:AusCert reference 5.5
 
Rationale:

SUID and SGID files allow an unprivileged user to accomplish tasks that require privileges. When a SUID program is run, its effective UID becomes that of the user who created the program, rather than the user who is running it. When a SGID program runs, its effect GID becomes that of the creating user.

Shell scripts that have the setuid or setgid bits set on them are not secure, regardless of how many safeguards are taken when writing them. Setuid and setgid shell scripts should never be allowed on any UNIX system.


#Required ActionExpected ResultsCommentsX
1

As root, execute the following command:

#/bin/find / -type f \( -perm \
-4000 -o -perm -2000 \) \
-exec ls -lgdb {} \;

Verify that all of the programs listed as output should be SUID or SGID. Only authorized files should be SUID or SGID.Depending on the system configuration, the output may be lengthy. It may be easier to review if the output is piped to a file, which can then be printed and reviewed. There are a large number (about 90) SUID and SGID programs that are installed as part of Solaris 2.4. Tools such as COPS, Tiger, and SPI report SUID and SGID programs. 


Topic:FILE SYSTEM SECURITY
 
Subtopic:User Environment Configuration
 
Test Objective 5.11Verify the user environment is configured properly.
 
Operating environment SRS Requirement:

AusCert reference 5.5

The IT Specialist/System Manager must implement all application controls to ensure users are assigned access rights and privileges consistent with their functional responsibilities and authorities. Access rights and privileges must be based on need-to-know, separation of duties, and management authorization.

The IT Specialist/System Manager shall ensure that controls are implemented which limits access to files, programs, and data to users or groups of users with the same need-to-know. Need-to-know shall be based on functional responsibilities, operational requirements, supervisory responsibilities, or a combination of these factors.

The IT Specialist/System Manager controls and limits computer system access to individuals requiring system access in the performance of their official duties. The IT Specialist/System Manager must limit the access of system users to the minimum level necessary to perform their official duties.

 
Rationale:

SUID and SGID files allow an unprivileged user to accomplish tasks that require privileges. When a SUID program is run, its effective UID becomes that of the user who created the program, rather than the user who is running it. When a SGID program runs, its effect GID becomes that of the creating user.

Shell scripts that have the setuid or setgid bits set on them are not secure, regardless of how many safeguards are taken when writing them. Setuid and setgid shell scripts should never be allowed on any UNIX system.


#Required ActionExpected ResultsCommentsX
1

As root, execute the following shell script for printing the umask value for each user:

#!/bin/sh
date
uname -a
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb

HOMEDIRS=`cat /etc/passwd | awk -F: 'length($6)>0 {print $6}' | sort -u`
FILES=".cshrc.login.profile "for dir in $HOMEDIRS
do
echo "-----------------------------"
echo Home Directory being
checked is $dir
for file in $FILES
do
ls -ald $dir/$file
if [ -f $dir/$file ]
then
grep -s umask /dev/null
$dir/$file
fi
done
doneecho "-----------------------------"

The umask value for each user is set to something sensible like 027 or 077.This script DOES NOT work using NIS or NIS+! When a file or directory is created, it has a default set of permissions. These default permissions are determined by the value of umask in the system file /etc/profile, or in a user's.cshrc or.login file. By default, the system sets the permissions on a text file to 666, granting read and write permission to user, group, and others, and to 777 on a directory or executable. The value assigned by umask is subtracted from the default. This has the effect of denying permissions in the same way that chmod grants them. If possible, a.cshrc,.login, and.profile should be created for each user owned by root and readable by the user with correct environment  
2

Utilize the following shell script for viewing the account initialization files for each user:

#!/bin/sh
date
uname -a
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb

HOMEDIRS=`cat /etc/passwd | awk -F: 'length($6)>0 {print $6}' | sort -u`
FILES=".cshrc.login.profile.logout.mwmrc.Xsession.Xdefaults.exrc.forward.rhosts"
for dir in $HOMEDIRS
do
echo "-----------------------------"
echo Home Directory being
checked is $dir
checked is $dir
done
echo "-----------------------------"

All account initialization files in user $HOME, and the default files that are used if these files are not present, have been reviewed to ensure that only acceptable actions are taken. Acceptable actions include: set user terminal type, check for new e-mail, and set a proper umask (027 or 077). Any other actions should be explicitly approved by the responsible security officer.

All user account initialization files are owned by the user (or root) and have permissions 640.

This script DOES NOT work using NIS or NIS+! [Acceptable actions for.mwmrc and. Xsession TBD.]If possible, a.cshrc,.login, and.profile should be created for each user owned by root and readable by the user with correct environment settings.
3

Ensure the default account initialization files are secure. A shell script for viewing the files follows:

#!/bin/sh
date
#!/bin/sh
date
uname -a
echo ------------------------------
echo /etc/.profile
echo -----------------------------
ls -al /etc/.profile
cat /etc/.profile
echo ---------------------------
echo /etc/skel/local.cshrc
echo ----------------------------
ls -al /etc/skel/local.cshrc
cat /etc/skel/local.cshrc

echo ----------------------------
echo /etc/skel/local.login
echo -----------------------------
ls -al /etc/skel/local.login
cat /etc/skel/local.login
echo -----------------------------
echo /etc/skel/local.profile
echo -----------------------------
ls -al /etc/skel/local.profile
cat /etc/skel/local.profile

echo -----------------------------
echo /etc/profile
echo -----------------------------
ls -al /etc/profile
cat /etc/profile

echo ----------------------------
echo ----------------------------
echo Operating environment initialization files
echo ----------------------------
echo ----------------------------
echo /etc/csh.login
echo ----------------------------
ls -al /etc/csh.login
cat /etc/csh.login

echo ----------------------------
echo /etc/dt/config/sys.dtprofile
echo ----------------------------
ls -al /etc/dt/config/sys.dtprofile
cat /etc/dt/config/sys.dtprofile
echo ----------------------------
echo /h/USERS/local/sysadmin/Scripts/.cshrc
echo ----------------------------
ls -al /h/USERS/local/sysadmin/Scripts/.cshrc
cat /h/USERS/local/sysadmin/Scripts/.cshrc
echo ----------------------------
echo /h/USERS/local/sysadmin/Scripts/.login
echo ----------------------------
ls -al /h/USERS/local/sysadmin/Scripts/.login
cat /h/USERS/local/sysadmin/Scripts/.login

echo ----------------------------
echo /h/OPERATING environment/Scripts/.cshrc.OPERATING environment
echo ----------------------------
ls -al /h/OPERATING environment/Scripts/.cshrc.OPERATING environment
cat /h/OPERATING environment/Scripts/.cshrc.OPERATING environment

echo ---------------------------
echo /h/OPERATING environment/Scripts/.login
.OPERATING environment
echo ---------------------------
ls -al /h/OPERATING environment/Scripts/.login.
OPERATING environment
cat /h/OPERATING environment/Scripts/
.login.OPERATING environment

echo ---------------------------
echo /h/OPERATING environment/Scripts/
.xsession.OPERATING environment
echo ---------------------------
ls -al /h/OPERATING environment/Scripts/.
xsession.OPERATING environment
cat /h/OPERATINGenvironment/Scripts/.
xsession.OPERATING environment

echo ----------------------------
echo $OPERATING environment_HOME/Scripts
echo ----------------------------
ls -alg $OPERATING environment_HOME/Scripts
echo ----------------------------

All default account initialization files that are used if user account initialization files are not present have been reviewed to ensure that only acceptable actions are taken. Acceptable actions include: set user terminal type, check for new e-mail, and set a proper umask (027 or 077). Any other actions should be explicitly approved by the responsible security officer.

/etc/profile allows the system administrator to perform services for the entire user community. The file $HOME/.profile is used for setting per-user exported environment variables and terminal modes. Care must be taken in providing system-wide services in /etc/profile. 
4

As root, execute the following command:

/bin/find / -name ".exrc" -print -exec ls
-ld {} \; -exec /usr/bin/more {} \;

There are no.exrc files on the system or the "exrc" option for each user is set to "noexrc".The editing environment defaults to certain configuration options. When an editing session is initiated, vi attempts to read the EXINIT environment variable. If it exists, the editor uses the values defined in EXINIT, otherwise the values set in $HOME/.exrc are used. If $HOME/.exrc does not exist, the default values are used.

To use a copy of.exrc located in the current directory other than $HOME, set the exrc option in EXINIT or $HOME/.exrc. Options set in EXINIT can be turned off in a local.exrc only if exrc is set in EXINIT or $HOME/.exrc.


Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.12Verify the privileged user's account (e.g., root) and anything owned by that user is configured securely.
 
Operating environment SRS Requirement:

AusCert reference 5.6

The IT Specialist/System Manager must implement all application controls to ensure users are assigned access rights and privileges consistent with their functional responsibilities and authorities. Access rights and privileges must be based on need-to-know, separation of duties, and management authorization.

The IT Specialist/System Manager shall ensure that controls are implemented which limits access to files, programs, and data to users or groups of users with the same need-to-know. Need-to-know shall be based on functional responsibilities, operational requirements, supervisory responsibilities, or a combination of these factors.

The IT Specialist/System Manager controls and limits computer system access to individuals requiring system access in the performance of their official duties. The IT Specialist/System Manager must limit the access of system users to the minimum level necessary to perform their official duties.

 
Rationale: 

#Required ActionExpected ResultsCommentsX
1Type the following command:

find / -user root ! -group bin \
-type f \( -perm -2 -o -perm -20 \) \
-exec ls -lgdb {} \;
Permissions are such that no user is able to write to any file especially executable and SUID, SGID files.  
2Type the following command:

find / -user root ! -group bin ! -group \
sys -type d \( -perm -2 -o -perm \
-20 \) -exec ls -lgdb {} \;
Permissions are such that no user is able to write to any directory that should not be written to.  

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.12Verify root's startup files are only writeable by root
 
Operating environment SRS Requirement:AusCert reference 5.6
 
Rationale:

Various programs have methods of automatic initialization to set options and variables for the user. 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 writeable by others.


#Required ActionExpected ResultsCommentsX
1

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

#ls -ldb /.login
#ls -ldb /.profile
#ls -ldb /etc/profile
#ls -ldb /.cshrc
#ls -ldb /.kshrc
#ls -ldb /.emacs
#ls -ldb /.exrc
#ls -ldb /.forward
#ls -ldb /.rhosts
#ls -ldb /.dtprofile
#ls -ldb /.Xdefaults

Permissions of existing files is 600 or 400 and are owned by root.Depending on the system configuration, ALL of the files listed in "Required Actions" MAY NOT exist. The base operating system does not install with the listed files present, and the existence of any one of these files indicates an addition of the file by the System Administrator. 
2

As root, execute the following commands from root's home directory to VIEW the files listed below. Also, on any executable that is referenced in the file being viewed execute the "ls -ldb" command to check the permissions of the file.
#/usr/ucb/more /.login
#/usr/ucb/more /.profile
#/usr/ucbmore /etc/profile
#/usr/ucb/more /.cshrc
#/usr/ucb/more /.kshrc
#/usr/ucb/more /.emacs
#/usr/ucb/more /.exrc
#/usr/ucb/more /.forward
#/usr/ucb/more /.dtprofile
#/usr/ucb/more /.Xdefaults

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

Topic:FILE SYSTEM SECURITY
 
Subtopic:Permissions
 
Test Objective 5.12Verify all root executable files are owned by root and are not world or group writeable
 
Operating environment SRS Requirement:AusCert reference 5.6
 
Rationale:

System Administrators should be trained to type in full pathname of files to be executed and to ensure that any executable that is not located in a protected directory is safe to execute.


#Required ActionExpected ResultsCommentsX
1

Type in the following commands:

#ls -lgdb /etc /usr /usr/bin /usr/sbin
/usr/5bin

Listed directories are owned by root and are not world or group writeable.

All executables run by root should be located in a directory where every directory in the path is owned by root and is not group or world writeable. In particular, the following directories should not be group or world writeable: /bin, /etc, /usr/sbin, /usr/bin, /usr/5bin, /usr/ucb. System Administrators should be trained to type in full pathname of files to be executed and to ensure that any executable that is not located in the protected directories listed above are safe to execute.

 
2

As root, execute the following commands:

#find /etc -user root \( -perm \
-2 -o -perm -20 \) ! -type l \
-exec ls -lgdb {} \;
#find /usr/bin -user \
root \( -perm -2 -o -perm -20 \) \
! -type l -exec ls -lgdb {} \;
#find /usr/sbin -user root \( -perm \
-2 -o -perm -20 \) ! -type l \
-exec ls -lgdb {} \; #find /usr/5bin -user root \( -perm \
-2 -o -perm -20 \) ! -type l \
-exec ls -lgdb {} \;

There should be no files listed indicating that there are no world/group writeable root owned files.

All executables run by root should be owned by root and all executables run by root should not be world or group writeable.

 

Topic:FILE SYSTEM SECURITY
 
Subtopic:Configuration
 
Test Objective 5.13Determine if any development tools exist on the workstation. Verify development tools such as language compilers, linkers, and debuggers are adequately protected and can only be accessed by authorized users.
 
Operating environment SRS Requirement:

AusCert reference 5.7

The IT Specialist/System Manager must control access to specialized system software, utilities, and functionality that could be used to gain unauthorized access to application data and program code. The IT Specialist/System Manager must keep access to these resources to the minimum number of authorized users required to accomplish program objectives.

 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Verify that the development tools listed in the results are owned by a privileged user and cannot be accessed by an unprivileged user.

For each of the development tools listed, enter "ls -alg <development tool>".

find / -name gcc -exec ls -ld {} \;

The permissions on the tool executables should be 750. The development tools should be assigned to a specific developer's group.

Unprivileged users cannot access the development tools listed below:

/usr/bin/adb
/usr/bin/as
/usr/bin/bc
/usr/lib/compile
/usr/bin/cb
/usr/bin/cflow
/usr/bin/cxref
/usr/bin/dbxtool
/usr/bin/ld
/usr/bin/lex
/usr/bin/m4
/usr/bin/od
/usr/bin/rpcgen
/usr/bin/yacc
/usr/bin/dbx
/usr/bin/gcore
/usr/bin/sccs
/usr/bin/xstr
/usr/openwin/bin/cps
/usr/openwin/bin/makeafb
/usr/5lib/compile/usr/5bin/lint
/usr/5bin/od

Depending on the system configuration, the output may be lengthy. It may be easier to review if the output is piped to a file, which can then be printed and reviewed. There are a large number (about 90) SUID and SGID programs that are installed as part of Solaris 2.4. Tools such as COPS, Tiger, and SPI report SUID and SGID programs.For operational systems, development tools such as language compilers, linkers, and debuggers are not available on the system. If the responsible security officer has approved the use of specific development tools such as language compilers, linkers, and debuggers on an operational system for a specific purpose, the development tools can be accessed only by authorized users. 











SECTION 6.0 SECURITY AND X-WINDOWS

Table of Contents

6.1 Xdm
 
6.2 Permissions
 
6.3 X Magic Cookie
 
6.4
 
6.5 Xhost Utility










Topic:SECURITY AND X-WINDOWS
 
Subtopic:Xdm
 
Test Objective 6.1Verify that xdm is disabled or a later version than 10/95 is installed.
 
Operating environment SRS Requirement:AusCert reference 7.1
 
Rationale:

xdm bypasses the normal getty and login functions, which means that quotas for the user, ownership of /dev/console and possibly other preventive measures put in place may be ignored.


#Required ActionExpected ResultsCommentsX
1INPUT NEEDED 

You should consult your vendor and ask about potential security holes in xdm and what fixes are available.

If you are running a version of xdm earlier than October 1995 then you should update to a newer version. (Refer to CERT Vendor-Initiated Bulletin VB-95:08, see C.8)

 

Topic: SECURITY AND X-WINDOWS
 
Subtopic:Permissions
 
Test Objective 6.2Verify that permissions on all "temp" directories are set correctly.
 
Operating environment SRS Requirement:AusCert reference 7.2
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Obtain a list of all temp directories on the system. A temp directory is any directory that is used to write scratch files. The main temp directories for Solaris 2.5.1 include: /tmp and /var/tmp /usr/tmp. Use the following command to check the permissions on any temp directories:

ls -l <temp dir name>

Output similar to the following should be displayed:

drwxrwxrwt 5 sys sys 846
Apr 15 13:11.
Note: The last character in the permissions, execute permission for "other", should be a "t", signifying that the sticky bit is set. If it is not set, execute the following command: "chmod +t<temp dir name>". Recheck the permissions on the directory 

Topic: SECURITY AND X-WINDOWS
 
Subtopic:X magic cookie
 
Test Objective 6.3Verify that the X magic cookie mechanism is enabled..
 
Operating environment SRS Requirement:AusCert reference 7.2
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1INPUT NEEDED  DO use the X magic cookie mechanism MIT-MAGIC-COOKIE-1 or better. With logins under the control of xdm, you can turn on authentication by editing the xdm-config file and setting the DisplayManager*authorize attribute to true. When granting access to the screen from another machine, use the xauth command in preference to the xhost command. 

Topic:SECURITY AND X-WINDOWS
 
Subtopic:xhost utility
 
Test Objective 6.4Verify the systems listed in xhost are appropriate. Determine what release of X is used on the system.
 
Operating environment SRS Requirement:AusCert reference 7.2
 
Rationale:

X uses a system called xhost to provide a minimal amount of security for window system users. Each X Window Server has a built-in list of hosts from which it will accept connections; connections from all other hosts are refused. The design of the X Window System allows any client that successfully connects to the X Window Server to exercise complete control over the display. If a person can log into a system, they can capture another user's keystrokes no matter how the xhosts is set.

Release 4 of the X Window Protocol has a secure feature on the xterm command that makes the window change its color if it is not receiving its input directly from the keyboard. This is a partial fix, but it is not complete .


#Required ActionExpected ResultsCommentsX
1

Type the following command to produce a list of which hosts are listed in xhost:

% xhost

Only trusted hosts should be in list returned or the message "Access control enabled, only authorized clients can connect" will be returned.It is preferable that the xhost security not be used and that xauth or another security mechanism beused. 










SECTION 7.0 ADMINISTRATIVE ACTIONS

Table of Contents

7.1 Audit Configuration
Verify Auditing Configured and Operating Properly
 
7.2 Audit of Unsuccessful Login Attempts /Logging Privileged Commands
Logging Privileged Commands
 
7.3 Audit Log Retention
 
7.4 Accounts
 
7.5 Volume Restrictions
 
7.6 Path
 
7.7 Password Protections
 
7.8 Login Warning










Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:AUDIT Configuration
 
Test Objective 7.1Ensure the audit subsystem is enabled.
 
Operating environment SRS Requirement:IT Specialists/System Managers must activate the audit trail capabilities provided by the operating system and security software installed on Agency systems.
 
Rationale:

Operating systems generally maintain a number of log files that keep track of system, security, and application information. These log files form the basis of an operating system's auditing subsystem. Auditing can be enabled or disabled. It should always be enabled for a secure system.


#Required ActionExpected ResultsCommentsX
1

Type in the following command to verify if auditing is enabled:

#auditconfig -getcond

The -getcond option obtains the machine audit condition. The response is one of three possible conditions:
auditing - Auditing is enabled and turned on
no audit - Auditing is enabled but turned off
disabled - The audit module is not enabled
An error message with the format "auditconfig: error = Invalid argument(22)" indicates that the BSM option has not been enabled on the system and the auditconfig command cannot be used.

Basic Security Module should be installed and turned on. The -chkconf option of the auditconfig command checks the configuration of kernel audit events to class mappings and reports any inconsistencies. 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:AUDIT Configuration
 
Test Objective 7.1Verify that auditing is configured and operating properly.
 
Operating environment SRS Requirement:

IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months.

The audit trail must record at least the following events and any other events deemed appropriate by the Program Manager or EXO: Multiple logon failures; Logons during non-business hours; Program or file access denial; Addition, deletion, or modification of user or program access privileges; and Changes in file access restrictions.

The system operation log must contain a record of all normal daily operations, system power-ups and power-downs, media mounts and dismounts, backup and recovery operations, and general environmental conditions. Installation, removal or modification of system or application software must be noted in the log. Any unusual events or operating conditions must also be noted in the log. Logs shall be maintained, in the central system file for a minimum of six months from the date of the last entry.

 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Type in the following command:

#/usr/sbin/auditconfig -chkconf

The command "auditconfig -chkconf" should not display any audit mapping inconsistencies. If the mappings are consistent, then the command will execute without printing any message as in the following:

#/usr/sbin/auditconfig -chkconf

Basic Security Module should be installed and turned on.

The -chkconf option of the auditconfig command checks the configuration of kernel audit events to class mappings and reports any inconsistencies.

 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Audit of Unsuccessful login attempts
 
Test Objective 7.2Verify that unsuccessful login attempts are logged
 
Operating environment SRS Requirement:

IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months. The audit trail must record at least the following events and any other events deemed appropriate by the Program Manager or, EXO: Multiple logon failures; Logons during non-business hours; Program or file access denial; Addition, deletion, or modification of user or program access privileges; and Changes in file access restrictions.

IT Specialists/System Managers must limit unsuccessful logon attempts from any workstation to three. After three unsuccessful logon attempts, the system shall automatically lock out the workstation. Only the system staff shall be given the capability to reset a workstation after lockout.

 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Verify the following file exists:

/var/adm/loginlog

The /var/adm/loginlog file should exist on the host. Note: If this file does NOT exist on the host, skip the remainder of the steps for this test.Unsuccessful attempts to log into the system can be recorded. If the /var/adm/loginlog file does not exist, nothing is logged. 
2

Attempt to login using an invalid password on a VALID user account. Repeat this step 4 times for a total of 5 times. Browse the /var/adm/loginlog file.

An entry exists in the file detailing the unsuccessful login attempts.After a user makes five consecutive unsuccessful attempts to log in, all attempts are recorded in the file /var/adm/loginlog. If a user makes fewer than five unsuccessful login attempts, none of the attempts are logged. Note: Some environments, such as Operating environment or CSE-SS, will lock out the user on the fifth invalid login attempt. 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Logging Privileged Commands
 
Test Objective 7.2Verify use of privileged commands (e.g., su) is logged and that a message is displayed on the console.
 
Operating environment SRS Requirement:IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months. The audit trail must record at least the following events and any other events deemed appropriate by the Program Manager or EXO: Multiple logon failures; Program or file access denial; Addition, deletion, or modification of user or program access privileges; and Changes in file access restrictions.
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1

Type the following command:

vi /etc/default/su

The following lines should be uncommented (i.e., should not have a "#" in front of them):

SULOG=/var/adm/sulog
CONSOLE=/dev/console

Entries in the file /etc/default/su determine the default conditions of the su command. The following entry enables a log of each time the su command is used to change to another user:

SULOG=/var/adm/sulog
(Security, Performance, and Accounting Administration)

 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Audit Log Retention
 
Test Objective 7.3Verify that the audit logs are kept for the appropriate periods.
 
Operating environment SRS Requirement:

E551.5.3b para 5f.

IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months.

 
Rationale: 

#Required ActionExpected ResultsCommentsX
1INPUT NEEDED  System and security logs exist for the identified retention periods. 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Accounts
 
Test Objective 7.4Verify there are no accounts on the system that have not been used within a reasonable amount of time.
 
Operating environment SRS Requirement:AusCert reference 4.5a.
 
Rationale: 

#Required ActionExpected ResultsCommentsX
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 | awk '{print $2}'`
/bin/last | /bin/grep \
$THIS_MONTH | \
awk '{print $1}' | sort -u > users1$$
cat /etc/passwd | \
/bin/awk -F: '{print $1}' | \
/bin/sort -u > users2$$
/bin/comm -13 users[12]$$
/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.  

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Volume restrictions
 
Test Objective 7.5Verify that volume restrictions are established.
 
Operating environment SRS Requirement: 
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1INPUT NEEDED  Volume restrictions are implemented to limit available user resources. 


Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Use of absolute path names when root.
 
Test Objective 7.6AusCert reference 4.7
 
Operating environment SRS Requirement: 
 
Rationale:DO use absolute path names when root. This is to stop the possibility of root accidentally executing a trojan horse.

#Required ActionExpected ResultsCommentsX
1INPUT NEEDED e.g., /bin/su, /bin/find, /bin/passwdTo execute commands in the current directory, root should prefix the command with "./", e.g., ./command. 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Password Protection
 
Test Objective 7.7Ensure authentication data is protected from being accessed by unauthorized users.
 
Operating environment SRS Requirement:

The IT Specialist/System Manager shall ensure that password file maintenance shall be restricted to the IT Specialist/System Manager, and passwords shall be screen-suppressed during logon and re-authentication. The IT Specialist/System Manager must control access to specialized system software, utilities, and functionality that could be used to gain unauthorized access to application data and program code. The IT Specialist/System Manager must keep access to these resources to the minimum number of authorized users required to accomplish program objectives.

 
Rationale:It is no longer considered secure to place even encrypted passwords in the world-readable /etc/passwd file. As a result, numerous vendors have introduced shadow password files. These files have the same encrypted passwords, but the passwords are stored in special files that cannot be read by most users on the system .

#Required ActionExpected ResultsCommentsX
1ls -ld /etc/shadow

The following permissions are displayed:

-r-------- root sys /etc/shadow

Ensure that adequate protection is provided to the password file. 

Topic:ADMINISTRATIVE ACTIONS
 
Subtopic:Login Warning
 
Test Objective 7.8Verify a security warning is displayed prior to the login process indicating restrictions that apply to logins, the highest classification of information processed on the system, and that misuse is subject to applicable penalties.
 
Operating environment SRS Requirement:TBD
 
Rationale: 

#Required ActionExpected ResultsCommentsX
1Prior to login view the monitor. Review the /etc/motd file and verify that the text in the file contains the text that is the site approved warning to users logging on the system.A security warning is displayed prior to the login process indicating restrictions that apply to logins, the highest classification of information processed on the system, and that misuse is subject to applicable penalties.OPERATING environment does not use /etc/motd.