Discussion

Single user mode access must be strictly limited to privileged users. The ability to boot to single user mode allows a malicious user the opportunity to modify, compromise, or otherwise damage the system.

Fix Text

For Trusted Mode: If single user boot authentication is disabled, use the System Administration Manager (SAM) or the System Management Homepage (SMH) to enable single user boot (for root only) authentication. For SMSE: Note: There may be additional package/bundle updates that must be installed to support attributes in the /etc/default/security file. Use the SAM/SMH interface (/etc/default/security file) and/or the userdbset command (/var/adm/userdb/* files) to update the attribute. See the below example: BOOT_AUTH=1 Note: Never use a text editor to modify any /var/adm/userdb database file. The database contains checksums and other binary data, and editors (vi included) do not follow the file locking conventions that are used to control access to the database. If manually editing the /etc/default/security file, save any change(s) before exiting the editor."

Check Content

Check the /tcb/files/auth/system/default entry. # grep “:d_boot_authenticate” /tcb/files/auth/system/default If the returned entry looks like “:d_boot_authenticate@:”, single user boot authentication is disabled, and this is a finding. For SMSE: Check the setting for BOOT_AUTH is set to N=1. # grep BOOT_AUTH /etc/default/security /var/adm/userdb/* If BOOT_AUTH=0, then single user boot authentication is disabled, and this is a finding.

Responsibility

System Administrator

IA Controls

IAIA-1, IAIA-2

Discussion

Shared accounts (accounts where two or more people log in with the same user identification) do not provide identification and authentication. There is no way to provide for non-repudiation or individual accountability.

Fix Text

Use the switch user (su) command from a named account login to access shared accounts. Maintain audit trails identifying the actual user of the account name. Document requirements and procedures for users/administrators to log into their own accounts first and then switch user (su) to the account that must be shared.

Check Content

Use the last command to check for multiple accesses to an account from different workstations/IP addresses. If users log directly onto accounts, rather than using the su command from their own named account to access them, this is a finding (such as logging directly on to Oracle). Also, ask the SA or the IAO if shared accounts are logged into directly or if users log on to an individual account and switch user to the shared account. # last <unix account>

Responsibility

System Administrator

IA Controls

IAIA-1

Discussion

A unique user name is the first part of the identification and authentication process. If user names are not unique, there can be no accountability on the system for auditing purposes. Multiple accounts sharing the same name could result in the Denial of Service to one or both of the accounts or unauthorized access to files or privileges.

Fix Text

Determine if the duplicate accounts have the same or different UIDs. # cat /etc/passwd | cut -f 1,1 -d “:” | sort | uniq -d If the UIDs are different, the account name must be changed. If the UIDs are the same, disable/remove one of the two (or more) password file entries via the SAM/SMH interface.

Check Content

Verify the consistency of the assigned home directories in the authentication database. For Trusted Mode: # authck -av For SMSE: # pwck If any duplicate account names are found, this is a finding.

Responsibility

System Administrator

IA Controls

IAIA-1, IAIA-2

Discussion

Accounts sharing a UID have full access to each others' files. This has the same effect as sharing a login. There is no way to assure identification, authentication, and accountability because the system sees them as the same user. If the duplicate UID is 0, this gives potential intruders another privileged account to attack.

Fix Text

Determine if the duplicate UIDs are associated with the same or a different account name. # cat /etc/passwd | grep <non-uniqueUID> or, for multiple non-unique UIDs: # cat /etc/passwd | egrep “<non-uniqueUID1>|<non-uniqueUID2>|,non-uniqueUIDn>“ If the account names are unique, the UIDs must also be modified to be unique. If the account names are the same, disable/remove one of the two (or more) password file entries via the SAM/SMH interface. .

Check Content

Verify the consistency of the assigned home directories in the authentication database. For Trusted Mode: # authck -av For SMSE: # pwck If a non-unique UID is found in the password file, this is a finding.

Responsibility

System Administrator

IA Controls

IAIA-1, IAIA-2

Discussion

Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.

Fix Text

Edit /etc/issue and add one of the DoD login banners (based on the character limitations imposed by the system). DoD Login Banners: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." OR "I've read & consent to terms in IS user agreem't."

Check Content

NOTE: This will virtually always require a manual review. Access the system console and make a login attempt. Check for either of the following login banners based on the character limitations imposed by the system. An exact match is required. If one of these banners is not displayed, this is a finding. "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." OR "I've read & consent to terms in IS user agreem't."

Responsibility

System Administrator

IA Controls

ECWM-1

Discussion

Monitoring and recording successful and unsuccessful logins assists in tracking unauthorized access to the system. Without this logging, the ability to track unauthorized activity to specific user accounts may be diminished.

Fix Text

Verify that login logs are handled correctly in the /etc/syslog.conf file. Verify that service startup scripts for syslog and (w/b)tmp (if present) are enabled. NOTE: Also examine the syslog.conf file for any references to remote log hosts if last/lastb produce no results. # cat /etc/syslog.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v '^#' | grep "\@"

Check Content

List the logged successful logons to determine if successful logons are being logged. # last -R | more List the logged unsuccessful logons to determine if unsuccessful logons are being logged. # lastb -R | more If logs do not contain successful and unsuccessful logins, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

Disabling accounts after a limited number of unsuccessful login attempts improves protection against password guessing attacks.

Fix Text

For Trusted Mode: Use the SAM/SMH interface or edit the /tcb/files/auth/system/default file and update the u_maxtries attribute. See the below example: :u_maxtries#3: If manually editing the file, save any change(s) before exiting the editor. For SMSE: Note: There may be additional package/bundle updates that must be installed to support attributes in the /etc/default/security file. Use the SAM/SMH interface (/etc/default/security file) and/or the userdbset command (/var/adm/userdb/* files) to update the attribute. See the below example: AUTH_MAXTRIES=2 Note: Never use a text editor to modify any /var/adm/userdb database file. The database contains checksums and other binary data, and editors (vi included) do not follow the file locking conventions that are used to control access to the database. If manually editing the /etc/default/security file, save any change(s) before exiting the editor.

Check Content

For Trusted Mode: The u_maxtries attribute in the /tcb/files/auth/system/default file controls whether an account is locked after too many consecutive authentication failures. An account is locked after “N” consecutive authentication failures. Check the global setting for u_maxtries is set to N=3. # grep u_maxtries /tcb/files/auth/system/default If the u_maxtries attribute is not set to 3, this is a finding. For SMSE: The AUTH_MAXTRIES attribute in the /etc/default/security configuration file controls whether an account is locked after too many consecutive authentication failures. An account is locked after N+1 consecutive authentication failures. Check the setting for AUTH_MAXTRIES is set to N=2. # grep AUTH_MAXTRIES /etc/default/security /var/adm/userdb/* If the attribute AUTH_MAXTRIES is not set to 2, this is a finding.

Responsibility

System Administrator

IA Controls

ECLO-1, ECLO-2

Discussion

Enforcing a delay between consecutive failed login attempts increases protection against automated password guessing attacks.

Fix Text

For Trusted Mode: Use the SAM/SMH interface to ensure that the t_logdelay setting is 4. For SMSE: There is no fix, however, there are attack mitigations to minimize risk (see mitigations).

Check Content

For Trusted Mode: Check the t_logdelay setting. # more /tcb/files/auth/system/default Verify the value of the t_logdelay variable. If the value is less than 4, this is a finding. For SMSE: By default, PAM executes a built-in, 3 second standard delay if user authentication fails. This delay cannot be extended. The “nodelay” parameter disables the built-in delay. Ensure that the “nodelay” parameter is not found in the /etc/pam.conf file. The HP-SMSE environment does not meet the failed authentication 4 second minimum delay requirement. This check will always result in a finding.

Responsibility

System Administrator

Mitigations

GEN000480

Mitigation Control

Attack mitigations to minimize risk: 1. Ensure that the “nodelay” parameter is not found in the /etc/pam.conf file. 2. In the file /opt/ssh/etc/sshd_config, the “MaxAuthTries” attribute must be explicitly set to “1”. This attribute controls the maximum number of authentication attempts permitted per SSH daemon connection. 3. In the file /opt/ssh/etc/sshd_config, the “MaxStartups” attribute must be explicitly set to an organization defined value of “10” (the default) or less. This attribute controls the maximum number of unauthenticated connections to the SSH daemon. 4. IPFilter DCA mode is disabled by default, and must be explicitly enabled. Set the following attribute in the /etc/rc.config.d/ipfconf file: DCA_START=1 The below /etc/opt/ipf/ipf.conf file rule specifies a connection limit of “<limit>“ for all hosts when attempting to connect to port “<sshd port>“. The “<sshd port>“ and “<limit>“ must be set to organization defined values. Per vendor documentation, this rule must be the next-to-last rule in /etc/opt/ipf/ipf.conf. The final rule in the file must define the default connection limit. See the below example for the last 2 line entries in /etc/opt/ipf/ipf.conf (note that the double quotes are for emphasis only): “pass in proto tcp from any to any port = <sshd port> keep limit <limit>“ “block in from any to any” Save the file before exiting the editor. The system should not require restarting for the new rule(s) to take effect.

Discussion

If an application is providing a continuous display and is running with root privileges, unauthorized users could interrupt the process and gain root access to the system.

Fix Text

Configure the system so the owner of a session requiring a continuous screen display, such as a network management display, is not root. Ensure the display is also located in a secure, controlled access area. Document and justify this requirement and ensure the terminal and keyboard for the display (or workstation) are secure from all but authorized personnel by maintaining them in a secure area, in a locked cabinet where a swipe card, or other positive forms of identification, must be used to gain entry.

Check Content

NOTE: This will virtually always require a manual review. If there is an application running on the system that is continuously in use (such as a network monitoring application), ask the SA what the name of the application is. Execute ps -ef | more to determine which user owns the process(es) associated with the application. If the owner is root, this is a finding.

Responsibility

System Administrator

IA Controls

PESL-1

Discussion

If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. If the root user is configured without a password, the entire system may be compromised. For user accounts not using password authentication, the account must be configured with a password lock value instead of a blank or null value.

Fix Text

For Trusted Mode: Use the System Administration Manager (SAM) or the System Management Homepage (SMH) to disable null passwords and immediately expire the password for any account with a null password, forcing the user to create a password on the very next login. Alternatively, the account may also be disabled. Protected password database files are maintained in the /tcb/files/auth hierarchy. This directory contains other directories each named with a single letter from the alphabet. User authentication profiles are stored in these directories based on the first letter of the user account name. Verify that SAM/SMH has now disabled null passwords for all accounts. # grep “:u_nullpw@:” /tcb/files/auth/[a-z,A-Z] For SMSE: Use the SAM/SMH interface (/etc/default/security file) and/or the userdbset command (/var/adm/userdb/* files) to update the attribute(s). See the below example: LOGIN_POLICY_STRICT=1 ALLOW_NULL_PASSWORD=0 Note: Never use a text editor to modify any /var/adm/userdb database file. The database contains checksums and other binary data, and editors (vi included) do not follow the file locking conventions that are used to control access to the database. If manually editing the /etc/default/security file, save any change(s) before exiting the editor. Use the System Administration Manager (SAM) or the System Management Homepage (SMH) to immediately expire the password for any account with a null password, forcing the user to create a password on the very next login. Alternatively, the account may also be disabled.

Check Content

For Trusted Mode: Verify that user accounts do not have blank passwords. # cd /tcb/files/auth && grep “u_pwd=::” */* If any user account with a blank password is found, this is a finding. For SMSE: Inspect the password (2nd) field in the /etc/shadow file. # cat /etc/shadow If any user account in the /etc/shadow file contains a null password field, this is a finding.

Responsibility

System Administrator

IA Controls

IAIA-1, IAIA-2

Discussion

If an account has an UID of 0, it has root authority. Multiple accounts with an UID of 0 afford more opportunity for potential intruders to compromise a privileged account.

Fix Text

Remove or change the UID of accounts other than root that have UID 0.

Check Content

Check the system for duplicate UID 0 assignments by listing all accounts assigned UID 0. # cat /etc/passwd | cut -f 1,3 -d ":" | grep ":0" If any accounts other than root are assigned UID 0, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Changing the root home directory to something other than / and assigning it a 0700 protection makes it more difficult for intruders to manipulate the system by reading the files root places in its default directory. It also gives root the same discretionary access control for root's home directory as for the other plain user home directories.

Fix Text

The root home directory should be something other than / (such as /roothome). # mkdir /rootdir # chown root /rootdir # chgrp root /rootdir # chmod 700 /rootdir # cp -r /.??* /rootdir/. Edit the passwd file and change the root home directory to /rootdir. The cp -r /.??* command copies all files and subdirectories of file names that begin with "." into the new root directory, which preserves the previous root environment. Ensure you are in the "/" directory when executing the "cp" command.

Check Content

Determine if root is assigned a home directory other than / by listing its home directory. # cat /etc/passwd | grep "^root" | cut -f 6,6 -d ":" If the root user home directory is /, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Permissions greater than 0700 could allow unauthorized users access to the root home directory.

Fix Text

The root home directory will have permissions of 0700. Do not change the protections of the / directory. Use the following command to change protections for the root home directory: # chmod 0700 /rootdir.

Check Content

Check the mode of the root home directory. Procedure: # cat /etc/passwd | grep "^root" | cut -f 6,6 -d ":" # ls -lLd <root home directory> If the mode of the directory is not equal to 0700, this is a finding. If the home directory is /, this check will be marked Not Applicable.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, two consecutive colons, or a single period, this is interpreted as the current working directory. Entries starting with a slash (/) are absolute paths.

Fix Text

Edit the root user's local initialization files and remove any relative path entries that have not been documented with the ISSO. Edit the root user’s local initialization files and remove any empty entry that is defined.

Check Content

To view the root user's PATH, log in as the root user, and execute: # env | grep PATH This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/), or has not been documented with the ISSO, this is a finding.

Responsibility

System Administrator

Discussion

If the root search path contains a world-writable directory, malicious software could be placed in the path by intruders and/or malicious users and inadvertently run by root with all of root's privileges.

Fix Text

For each world-writable path in root's executable search path, do one of the following: 1. Remove the world-writable permission on the directory. Procedure: # chmod o-w <path> 2. Remove the world-writable directory from the executable search path. Procedure: Identify and edit the initialization file referencing the world-writable directory and remove it from the PATH variable.

Check Content

Check for world-writable permissions on all directories in the root user's executable search path. Procedure: # ls -ld `echo $PATH | sed "s/:/ /g"` If any of the directories in the PATH variable are world-writable, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Limiting the root account direct logins to only system consoles protects the root account from direct unauthorized access from a non-console device.

Fix Text

If the /etc/securetty file does not exist, create the file containing only the word console and ensure correct file properties. # echo “console” > /etc/securetty

Check Content

Check the /etc/securetty file contents. # more /etc/securetty If /etc/securetty does not exist, or has contents other than console or /dev/null, this is a finding.

Responsibility

System Administrator

Discussion

Reserved GIDs are typically used by system software packages. If non-system groups have GIDs in this range, they may conflict with system software, possibly leading to the group having permissions to modify system files.

Fix Text

Change the primary group GID numbers for non-system accounts with reserved primary group GIDs (those less or equal to 99). # usermod -g <new_group> <user>

Check Content

Confirm all accounts with a GID of 99 and below are used by a system account. If a GID reserved for system accounts (0 - 99) is used by a non-system account, this is a finding. The vendor-supplied system default group "users" (gid=20) is considered an exception to this check. # cat /etc/passwd | cut -f 1,4 -d ":"

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If a user is assigned the GID of a group not existing on the system, and a group with that GID is subsequently created, the user may have unintended rights to the group.

Fix Text

Add a group to the system (edit /etc/group) for each GID referenced without a corresponding group.

Check Content

Determine if any GIDs referenced in /etc/passwd are not defined in /etc/group. Procedure: # cat /etc/passwd | cut -f 4,4 -d ":" | sort | uniq With the above GIDs, manually execute the following command for every GID from above. Note that this command is expected to return line entry information from /etc/group. # grep -n <GID> /etc/group If any GIDs referenced in /etc/passwd and not defined in /etc/group are returned, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

Without a host-based intrusion detection tool, there is no system-level defense when an intruder gains access to a system or network. Additionally, a host-based intrusion detection tool can provide methods to immediately lock out detected intrusion attempts.

Fix Text

Install a host-based intrusion detection tool.

Check Content

A few applications providing host-based network intrusion protection are: - Dragon Squire by Enterasys Networks - ITA by Symantec - Hostsentry by Psionic Software - Logcheck by Psionic Software - RealSecure agent by ISS - Swatch by Stanford University Ask the SA or IAO if a host-based intrusion detection application is loaded on the system (where <daemon name> is the name of the primary application daemon) to determine if the application is loaded on the system. # find / -name <daemon> | xargs -n1 ls -lL Determine if the application is active on the system. # ps -ef | grep <daemon name> If no host-based intrusion detection system is installed on the system, this is a finding.

Responsibility

System Administrator

IA Controls

ECID-1

Discussion

Timely patching is critical for maintaining the operational availability, confidentiality, and integrity of Information Technology (IT) systems. However, failure to keep operating system and application software patched is a common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced system administrators to keep abreast of all the new patches. When new weaknesses in an operating system exist, patches are usually made available by the vendor to resolve the problems. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses present in the unpatched software. The lack of prompt attention to patching could result in a system compromise.

Fix Text

Use a web browser to access the vendor's support website. Follow the instructions to set up an account with a login and a password. Once this is done it is possible to download the needed patches. Use SMH or # swinstall to apply the patches.

Check Content

Obtain the list of available security patches from HP. Alternatively, obtain, install, and use HP's Patch Tool Bundle to compile a list of superseded patches based on the installed software Product Bundle Patch list(s): # show_patches -s Verify the available security patches have been installed on the system. To list patches installed on the system, use the swlist utility. Example: # swlist -l fileset If there are security patches available and applicable for the system that have not been installed, this is a finding.

Responsibility

System Administrator

Discussion

Discretionary access control is undermined if users, other than a file owner, have greater access permissions to system files and directories than the owner.

Fix Text

Change the mode of files with uneven permissions so owners do not have less permissions than group or world users.

Check Content

Check system directories for uneven file permissions. Procedure: # ls -lL /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin Uneven file permissions exist if the file owner has less permissions than the group or other user classes. If any of the files in the above listed directories contain uneven file permissions, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Unowned files and directories may be unintentionally inherited if a user is assigned the same UID as the UID of the unowned files.

Fix Text

All directories and files (executable and data) will have an identifiable owner and group name. Either trace files to an authorized user, change the file's owner to root, or delete them. Determine the legitimate owner of the files and use the chown command to set the owner and group to the correct value. If the legitimate owner cannot be determined, change the owner to root (but make sure none of the changed files remain executable because they could be Trojan horses or other malicious code). Examine the files to determine their origin and the reason for their lack of an owner/group.

Check Content

Check the system for files with no assigned owner. Procedure: # find / -nouser -print If any files have no assigned owner, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Restricting permission on daemons will protect them from unauthorized modification and possible system compromise.

Fix Text

Change the mode of the network services daemon. # chmod 0755 <path>/<daemon>

Check Content

Check the mode of network services daemons. # ls -lLa /usr/lbin If the mode of a network services daemon is more permissive than 0755, this is a finding. NOTE: Network daemons that may not reside in these directories (such as httpd or sshd) must also be checked for the correct permissions.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the system log files are not protected, unauthorized users could change the logged data, eliminating its forensic value.

Fix Text

Change the mode of the system log files to 0640 or less permissive. # chmod 0640 <path>/<system-log-file> NOTE: Do not confuse system log files with audit logs.

Check Content

Check the mode of log files. # ls -lLR /var/log /var/log/syslog /var/adm /var/opt Note that some of the above directories will contain more than just system log files. For example: /var/adm/sa, /var/adm/sw, etc. Any non-system log files contained within the above directories should be excluded from this requirement. If any of the system log files have modes more permissive than 0640, this is a finding.

Responsibility

System Administrator

IA Controls

ECTP-1

Discussion

If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files.

Fix Text

Change the mode of skeleton files with incorrect mode. # chmod 0444 <skeleton file>

Check Content

Check skeleton files permissions. # ls -alL /etc/skel If a skeleton file has a mode more permissive than 0444, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

NIS/NIS+/yp files are part of the system's identification and authentication processes and are, therefore, critical to system security. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

Change the ownership of NIS/NIS+/yp files to root, sys, or bin. Consult vendor documentation to determine the location of the files. Procedure (example): # chown root <filename>

Check Content

Check NIS file ownership. Procedure: # ls -lLa /var/yp/<nis domainname> If the file ownership is not root, sys, or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

NIS/NIS+/yp files are part of the system's identification and authentication processes and are, therefore, critical to system security. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

Change the group owner of the NIS files to root, sys, bin, or other. # chgrp root <filename>

Check Content

Check NIS file ownership. # ls -alLR /var/yp/`domainname` If the file group owner is not root, sys, bin (the default), or other, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

NIS/NIS+/yp files are part of the system's identification and authentication processes and are, therefore, critical to system security. Unauthorized modification of these files could compromise these processes and the system.

Fix Text

Change the mode of NIS/NIS+/yp command files to 0755 or less permissive. Procedure (example): # chmod 0755 <filename>

Check Content

Check NIS file mode. Procedure: # grep -i NIS_DOMAIN /etc/rc.config.d/namesvrs # ls -lLa /var/yp/<NIS_DOMAIN> If the file's mode is more permissive than 0755, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If manual pages are compromised, misleading information could be inserted, causing actions possibly compromising the system.

Fix Text

Change the mode of manual page files to 0644 or less permissive. Example: # chmod 0644 <path>/<manpage>

Check Content

Check the mode of the manual page files. # find `env | grep MANPATH | cut -f 2,2 -d "=" | tr ':' ' ' ` -type f \( -perm -100 -o -perm -030 -o -perm -003 \) -exec ls -al {} + If any manual page file mode is more permissive than 0644, this is a finding.

Discussion

Unauthorized access could destroy the integrity of the library files.

Fix Text

Change the mode of library files to 0755 or less permissive. Procedure (example): # chmod 0755 <path>/<library-file> NOTE: Library files should have an extension of ".a" or ".so" (a=archive, so=shared object) extension, possibly followed by a version number.

Check Content

Check the mode of library files. Procedure: # ls -lLR /usr/lib /lib If any of the library files have a mode more permissive than 755, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

Restricting permissions will protect system command files from unauthorized modification. System command files include files present in directories used by the operating system for storing default system executables and files present in directories included in the system's default executable search paths.

Fix Text

Change the mode for system command files to 755 or less permissive. # chmod 755 <filename>

Check Content

Check the permissions for files in /etc, /bin, /usr/bin, /usr/lbin, /sbin, and /usr/sbin. # ls -lL /etc /bin /usr/bin /usr/lbin /sbin /usr/sbin If any file listed has a mode more permissive than 755, this is a finding. Note: Elevate to Severity Code I if any file is listed as world-writable.

Security Override Guidance

Elevate to Severity Code I if any file listed world-writable.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Restricting permissions will protect the files from unauthorized modification.

Fix Text

Change the owner of system files, programs, and directories to a system account. Procedure: # chown root <path>/<system file> (A different system user may be used in place of root.)

Check Content

Check the ownership of system files, programs, and directories. Procedure: # ls -lLa /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin If any of the system files, programs, or directories are not owned by a system account, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Restricting permissions will protect the files from unauthorized modification.

Fix Text

Change the group owner of system files to a system group. Procedure: # chgrp root <path>/<system file> (System groups other than root may be used.)

Check Content

Check the group ownership of system files, programs, and directories. Procedure: # ls -lLa /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin If any system file, program, or directory is not owned by a system group, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

For Trusted Mode: # chown root /tcb # chown root /tcb/files /tcb/files/auth # chown root /tcb/files/auth/[a-z]/* For SMSE: # chown root /etc/shadow

Check Content

For Trusted Mode: Check the ownership of the /etc/shadow file. # ls -lL /etc/shadow If the /etc/shadow file exists and is not owned by root, this is a finding. NOTE: /etc/shadow should not exist if the system is in Trusted Mode. Check the ownership of the TCB auth files and directories. # ls -lLd /tcb /tcb/files /tcb/files/auth # ls -lL /tcb/files/auth/[a-z,A-Z]/* If the owner of any of the /tcb files and directories is not root, this is a finding. For SMSE: Check the /etc/shadow file. # ls -lL /etc/shadow If the /etc/shadow file exists and is not owned by root, this is a finding.

Responsibility

System Administrator

Discussion

If the passwd file is writable by a group owner or the world, the risk of passwd file compromise is increased. The passwd file contains the list of accounts on the system and associated information.

Fix Text

Change the mode of the passwd file to 0444. # chmod 0444 /etc/passwd Document all changes.

Check Content

Check the mode of the /etc/passwd file. Procedure: # ls -lL /etc/passwd If /etc/passwd has a mode more permissive than 0444, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. The file also contains password hashes which must not be accessible to users other than root. The Trusted Mode /tcb tree requires modes more permissive than the shadow file.

Fix Text

For Trusted Mode: # chmod 0555 /tcb # chmod 0771 /tcb/files /tcb/files/auth # chmod 0664 /tcb/files/auth/[a-z]/* For SMSE: # chmod 0400 /etc/shadow

Check Content

For Trusted Mode: Check the TCB auth files and directories. # ls -lLd /tcb /tcb/files /tcp/files/auth # ls -lL /tcb/files/auth/[a-z,A-Z]/* If the mode of /tcb directory is more permissive than 0555, this is a finding. If the mode of /tcb/files or /tcb/files/auth directories is more permissive than 0771, this is a finding. If the mode of any of the /tcb/files/auth/[a-z]/* is more permissive than 0664, this is a finding. For SMSE: Check the /etc/shadow file. # ls -lL /etc/shadow If the /etc/shadow file has a mode more permissive than 0400, this is a finding. NOTE: The /etc/shadow file will not exist if the system is in Trusted Mode.

Responsibility

System Administrator

Discussion

All files with the setuid bit set will allow anyone running these files to be temporarily assigned the UID of the file. While many system files depend on these attributes for proper operation, security problems can result if setuid is assigned to programs that allow reading and writing of files, or shell escapes. Only default vendor-supplied executables should have the setuid bit set.

Fix Text

Document the files with the suid bit set or unset the suid bit on the executable.

Check Content

Files with the setuid bit set will allow anyone running these files to be temporarily assigned the user or group ID of the file. If an executable with setuid allows shell escapes, the user can operate on the system with the effective permission rights of the user or group owner. List all setuid files on the system. Procedure: # find / -perm -4000 -exec ls -l {} \; | more NOTE: Executing these commands may result in large listings of files; the output may be redirected to a file for easier analysis. Ask the SA or IAO if files with the suid bit set have been documented. If any undocumented file has its suid bit set, this is a finding.

Responsibility

System Administrator

IA Controls

ECPA-1

Discussion

All files with the setgid bit set will allow anyone running these files to be temporarily assigned the GID of the file. While many system files depend on these attributes for proper operation, security problems can result if setgid is assigned to programs that allow reading and writing of files, or shell escapes.

Fix Text

All files with the sgid bit set will be documented in the system baseline and authorized by the Information Systems Security Officer (ISSO). Locate all sgid files with the following command: find / -perm -2000 -exec ls -lL {} \; Ensure sgid files are part of the operating system software, documented application software, documented utility software, or documented locally developed software. Ensure none are text files or shell programs.

Check Content

Locate all setgid files on the system. Procedure: # find / -perm -2000 If the ownership, permissions, location, and ACLs of all files with the setgid bit set are not documented, this is a finding.

Responsibility

System Administrator

IA Controls

ECPA-1

Discussion

Files with the setuid bit set will allow anyone running these files to be temporarily assigned the UID of the file. While many system files depend on these attributes for proper operation, security problems can result if setuid is assigned to programs that allow reading and writing of files, or shell escapes.

Fix Text

Establish a weekly automated or manual process to generate a list of suid files on the system and compare it with the prior list. To create a list of suid files: # find / -perm -4000 > suid-file-list

Check Content

NOTE: This will virtually always require a manual review. Determine if a weekly automated or manual process is used to generate a list of suid files on the system and compare it with the prior list. If no such process is in place, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

Files with the setgid bit set will allow anyone running these files to be temporarily assigned the group id of the file. While many system files depend on these attributes for proper operation, security problems can result if setgid is assigned to programs that allow reading and writing of files, or shell escapes.

Fix Text

Establish a weekly automated or manual process to generate a list of sgid files on the system and compare it with the prior list. To create a list of sgid files: # find / -type f -perm -2000 -exec ls -lL {} \; >> sgid-file-list

Check Content

NOTE: This will virtually always require a manual review. Determine if a weekly automated or manual process is used to generate a list of sgid files on the system and compare it with the prior list. If no such process is in place, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

The "nosuid" mount option causes the system to not execute setuid files with owner privileges. This option must be used for mounting any file system not containing approved setuid files. Executing setuid files from untrusted file systems, or file systems that do not contain approved setuid files, increases the opportunity for unprivileged users to attain unauthorized administrative access.

Fix Text

Edit /etc/fstab and add the nosuid mount option to all file systems mounted from removable media or network shares, and any file system not containing approved setuid or setgid files.

Check Content

Check /etc/fstab and verify the nosuid mount option is used on file systems mounted from removable media, network shares, or any other file system not containing approved setuid or setgid files. Each file system line entry must contain a device specific file and may additionally contain all of the following fields, in the following order: mount directory, type, options, backup frequency, pass number (on parallel fsck) and comment. # cat /etc/fstab | grep -v "^#" If the "nosuid" mount option is not used on file systems mounted from removable media, network shares, or any other file system that does not contain approved setuid or setgid files, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Failing to set the sticky bit on the public directories allows unauthorized users to delete files in the directory structure. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage (e.g., /tmp) and for directories requiring global read/write access.

Fix Text

Set the sticky bit on all public directories. Procedure: # chmod 1777 <world writeable directory>

Check Content

Verify all world-writable directories have the sticky bit set. Procedure: # find / -type d -perm -002 ! -perm -1000 -exec ls -lLd {} \; | tee wwlist If the sticky bit is not set on a world-writable directory, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

If a public directory has the sticky bit set and is not owned by a privileged UID, unauthorized users may be able to modify files created by others. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage (e.g., /tmp) and for directories requiring global read/write access.

Fix Text

Change the owner of public directories to root or an application account. Procedure: # chown root <public directory>

Check Content

Check the ownership of all public directories. Procedure: # find / -type d -perm -1002 -exec ls -ld {} \; If any public directory is not owned by root or an application user, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The umask controls the default access mode assigned to newly created files. An umask of 077 limits new files to mode 700 or less permissive. Although umask can be represented as a 4-digit number, the first digit representing special access modes is typically ignored or required to be 0. This requirement applies to the globally configured system defaults and the user defaults for each account on the system.

Fix Text

Edit local and global initialization files containing umask and change them to use 077 instead of the current value.

Check Content

Check global initialization files for the configured umask value. # grep umask /etc/* | grep -v ":#" | grep "umask [0-9]" Check local initialization files for the configured umask value. Procedure: # grep umask /userhomedirectory/.* If the system and user default umask is not 077, this is a finding. NOTE: If the default umask is 000 or allows for the creation of world-writable files this becomes a Severity Code I (CAT I) finding.

Security Override Guidance

If the default umask is 000 or does not restrict the world-writable permission, this becomes a CAT I finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Vendor accounts and software may contain backdoors that will allow unauthorized access to the system. These backdoors are common knowledge and present a threat to system security if the account is not disabled.

Fix Text

For Trusted Mode and SMSE: Use the System Administration Manager (SAM) or the System Management Homepage (SMH) to lock/disable or remove any enabled default system accounts.

Check Content

Account/password locking is typically accomplished with the asterisk (*). System logins that never had a password use a double exclamation mark (!!) and accounts that have been locked have the valid password entry invalidated by a single exclamation mark (!) prefix. For Trusted Mode: Protected password database files are maintained in the /tcb/files/auth hierarchy. This directory contains other directories each named with a single letter from the alphabet. User authentication profiles are stored in these directories based on the first letter of the user account name. Next check if default system accounts (such as those for sys, bin, uucp, nuucp, daemon, smtp) have been disabled. # grep “u_pwd=“ /tcb/files/auth/[a-z,A-Z]/* If any default system accounts (such as those for sys, bin, uucp, nuucp, daemon, smtp) have not been disabled, this is a finding. For SMSE: Check if default system accounts (such as those for sys, bin, uucp, nuucp, daemon, smtp) have been disabled. # cat /etc/shadow If any default system accounts (such as those for sys, bin, uucp, nuucp, daemon, smtp) have not been disabled, this is a finding.

Responsibility

System Administrator

IA Controls

IAAC-1

Discussion

Without auditing, individual system accesses cannot be tracked and malicious activity cannot be detected and traced back to an individual account.

Fix Text

Turn on the auditing system. The system will use existing current and next audit trails (if configured). # audsys -n Alternatively, use the HP SMH to configure and enable auditing on the system.

Check Content

Determine if auditing is enabled. # audsys If the audit service is not running, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

Failure to give ownership of system audit log files to root provides the designated owner and unauthorized users with the potential to access sensitive information.

Fix Text

As root, change the ownership. # chown root <audit directory> # chown root <audit file>

Check Content

Inspect the auditing configuration file, /etc/rc.config.d/auditing, to determine the filename and path of the audit logs. The entries should appear similar to the following: PRI_AUDFILE=/var/.audit/file1 SEC_AUDFILE=/var/.audit/file2 # egrep “PRI_AUDFILE|SEC_AUDFILE” /etc/rc.config.d/auditing For each audit log directory/file, check the ownership. # ls -lLd <audit directory> # ls -lLa <audit file> If any audit log directory/file is not owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECTP-1

Discussion

If a user can write to the audit logs, audit trails can be modified or destroyed and system intrusion may not be detected. System audit logs are those files generated from the audit system and do not include activity, error, or other log files created by application software.

Fix Text

As root, change the permissions. # chmod 0750 <audit directory> # chmod 0640 <audit file>

Check Content

Inspect the auditing configuration file, /etc/rc.config.d/auditing, to determine the filename and path of the audit logs. The entries should appear similar to the following: PRI_AUDFILE=/var/.audit/file1 SEC_AUDFILE=/var/.audit/file2 # egrep “PRI_AUDFILE|SEC_AUDFILE” /etc/rc.config.d/auditing For each audit log directory/file, check the permissions. # ls -lLd <audit directory> # ls -lLa <audit file> If any audit log file has permissions greater than 0640 (0750 for directories), this is a finding.

Responsibility

System Administrator

IA Controls

ECTP-1

Discussion

If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Fix Text

Edit /etc/rc.config.d/auditing and add -e open to the end of the AUDEVENT_ARGS1 parameter.

Check Content

Check the system audit configuration to determine if failed attempts to access files and programs are audited. # grep -i audevent_args1 /etc/rc.config.d/auditing | grep open If no results are returned, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Fix Text

Edit /etc/rc.config.d/auditing and add -e delete to the end of the AUDEVENT_ARGS1 parameter.

Check Content

Check the system audit configuration to determine if failed attempts to access files and programs are audited. # grep -i audevent_args1 /etc/rc.config.d/auditing | grep delete If no results are returned, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Fix Text

Edit /etc/rc.config.d/auditing and add -e admin and -e removable to the end of the AUDEVENT_ARGS1 parameter.

Check Content

Check the auditing configuration of the system. # grep -i audevent_args1 /etc/rc.config.d/auditing | grep admin # grep -i audevent_args1 /etc/rc.config.d/auditing | grep removable If no results are returned for either of these commands, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Fix Text

Edit /etc/rc.config.d/auditing and add -e login to the end of the AUDEVENT_ARGS1 parameter.

Check Content

Check the system's audit configuration. # grep -i audevent_args1 /etc/rc.config.d/auditing | grep login If no results are returned, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Fix Text

Edit /etc/rc.config.d/auditing and add -e moddac to the end of the AUDEVENT_ARGS1 parameter.

Check Content

Check the system's audit configuration. The term moddac is code for MODify Dicscretionary Access Control (i.e., chown, chmod, etc.). # grep -i audevent_args1 /etc/rc.config.d/auditing | grep moddac If no results are returned, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

Failure to give ownership of sensitive files or utilities to root provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

Change the ownership of the inetd.conf file to root or bin. # chown root <file or directory>

Check Content

Check the ownership of the xinetd.d directory, the (x)inetd.conf file and any files identified by the configuration file includedir stanza. # find / -type d -name xinetd.d | xargs -n1 ls -lLd # find / -type f -name inetd.conf -o -name xinetd.conf | xargs -n1 ls -lL # grep includedir <PATH>/xinetd.conf If any of the above named files, included files or directories are not owned by root or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system.

Fix Text

Change the mode of the (x)inetd.conf file. # chmod 0440 <file>

Check Content

Check the mode of the (x)inetd.conf file and any files identified by the configuration file includedir stanza: # find / -type f -name inetd.conf -o -name xinetd.conf | xargs -n1 ls -lL # grep includedir <PATH>/xinetd.conf # ls -lL <includedir files from previous command> If any of the above file mode are more permissive than 0440, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

Change the ownership of the services file to root or bin. # chown root /etc/services

Check Content

Check the ownership of the services file. NOTE: The typical ownership of the services file is bin. # ls -lL /etc/services If the services file is not owned by root or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The services file is critical to the proper operation of network services and must be protected from unauthorized modification. Unauthorized modification could result in the failure of network services.

Fix Text

Change the mode of the services file to 0444 or less permissive. # chmod 0444 /etc/services

Check Content

Check the mode of the services file. NOTE: The typical default mode of the services file is 0444. # ls -lL /etc/services If the services file has a mode more permissive than 0444, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the mesg -n or mesg n command is not placed into the system profile, messaging can be used to cause a Denial of Service attack.

Fix Text

Edit /etc/profile or another global initialization script, and add the mesg -n command.

Check Content

Check global initialization files for the presence of mesg -n or mesg n. Procedure: # grep "mesg" /etc/.login /etc/profile /etc/bashrc /etc/csh.login /etc/csh.cshrc If global initialization files exist and do not contain mesg -n or mesg n, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

Having the "+" character in the hosts.lpd (or equivalent) file allows all hosts to use local system print resources.

Fix Text

Remove the "+" entries from the hosts.lpd (or equivalent) file.

Check Content

Look for the presence of a print service configuration file. The hosts.lpd file is not used on HP, only inetd.sec, hosts.equiv, and/or the system (lp) .rhosts will apply. When rlpdaemon is started via inetd, access control is provided via the fileinetd.sec to allow or prevent a host from making print requests. When rlpdaemon is started at boot via a run command file, all requests must come from one of the machines listed in the file /etc/hosts.equiv or /var/spool/lp/.rhosts. Procedure: First, determine the rlpdaemon startup method: 1) Print services started via inetd? # cat /etc/inetd.conf | grep -v "^#" | grep -c rlpdaemon If the above command return value is 1, check the services file. # cat /etc/services | grep -v "^#" | grep printer | grep -c spooler If the above command return value is 1, check the inetd.sec file. # cat /var/adm/inetd.sec | grep -v "^#" | tr '\011' ' ' | tr -s ' ' | grep printer | grep allow | grep -c "\+" If the above command return value is 1, this is a finding. 2) The rlpdaemon is started as a service, and not via inetd. Verify neither the /etc/hosts.equiv nor /var/spool/lp/.rhosts contains a "+": # cat /etc/hosts.equiv | grep -v "^#" | grep -c "\+" # cat /var/spool/lp/.rhosts | grep -v "^#" | grep -c "\+" If the return value of either of the above two command(s) is 1, this is a finding. If none of the files are found, this check should be marked not a finding. Otherwise, examine the configuration file. # more <print service file> Check for entries containing a "+" or "_" character. If any are found, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Failure to give ownership of the hosts.lpd file to root, bin, sys, or lp provides the designated owner, and possible unauthorized users, with the potential to modify the hosts.lpd file. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers.

Fix Text

Change the owner of the /etc/hosts.lpd file (or equivalent) to root, lp, or another privileged UID. # chown root <print service configuration file>

Check Content

Locate any print service configuration file(s) on the system. HP vendor documentation identifies the following names and locations of print service configuration files on the system that can be checked via the following commands: # ls -lL /var/spool/lp/.rhosts # ls -lL /var/adm/inetd.sec # ls -lL /etc/hosts.equiv If no print service configuration file is found, this is not a finding. Check the ownership of the print service configuration file(s). # ls -lL <print service configuration file> If the owner of the file is not root, sys, bin, or lp, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Excessive permissions on the hosts.lpd (or equivalent) file may permit unauthorized modification. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers.

Fix Text

Change the mode of the /etc/hosts.lpd file (or equivalent) to 0644 or less permissive. Procedure: # chmod 0644 <print service configuration file>

Check Content

Locate any print service configuration file(s) on the system. HP vendor documentation identifies the following names and locations of print service configuration files on the system that can be checked via the following commands: # ls -lL /var/spool/lp/.rhosts # ls -lL /var/adm/inetd.sec # ls -lL /etc/hosts.equiv If no print service configuration file is found, this is not a finding. Check the mode of the print service configuration file. # ls -lL <print service configuration file> If the mode of the print service configuration file is more permissive than 0644, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the aliases file is not owned by root, an unauthorized user may modify the file to add aliases to run malicious code or redirect e-mail.

Fix Text

Change the owner of the /etc/mail/aliases file (or equivalent) to root. # chown root /etc/mail/aliases

Check Content

Find the aliases file on the system and check the ownership. # ls -lL /etc/mail/aliases If the file is not owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Excessive permissions on the aliases file may permit unauthorized modification. If the alias file is modified by an unauthorized user, they may modify the file to run malicious code or redirect e-mail.

Fix Text

Change the mode of the aliases file (or equivalent) to 0644. # chmod 0644 /etc/mail/aliases

Check Content

Find the aliases file on the system. Procedure: # ls -lL /etc/mail/aliases If the aliases file exists with a mode more permissive than 0644, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If a file executed through a mail aliases file is not owned and writable only by root, it may be subject to unauthorized modification. Unauthorized modification of files executed through aliases may allow unauthorized users to attain root privileges.

Fix Text

Edit the /etc/mail/aliases file Locate the entries executing a program. They will appear similar to the following line: alias: "|/usr/local/bin/ls" (or some other program name) Ensure root owns the programs and the directory(ies) they reside in by using the chown command to change owner to root. For a directory entry: # chown root <entry> For a file entry (change BOTH the directory and file, where/as necessary: # chown root <entry> # chown root `dirname <entry>`

Check Content

Examine the aliases file for any utilized directories or paths. # cat/etc/mail/aliases | cut -f 2,2 -d ":" | grep "|" For example, the alias file entry will look like: msgs: "|/usr/bin/msgs -s" The entry must be an absolute path name: # ls -lLd `dirname <entry>` # ls -lL <entry> If the file or parent directory is not owned by root, this a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If a file executed through a mail alias file has permissions greater than 0755, it can be modified by an unauthorized user and may contain malicious code or instructions possibly compromising the system.

Fix Text

Use the chmod command to change the access permissions for files executed from the aliases file. For example: # chmod 0755 <path/file>

Check Content

Examine the aliases file on the system for any utilized directories or paths. # cat /etc/mail/aliases | cut -f 2,2 -d ":" | grep "|" Check the permissions for any file paths referenced. # ls -lL <path/file> If any file referenced from the aliases file has a mode more permissive than 0755, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If Sendmail is not configured to log at level 9, system logs may not contain the information necessary for tracking unauthorized use of the sendmail service.

Fix Text

Edit the sendmail.cf file, locate the entry (and where necessary uncomment it and/or create it) and modify/set it to 9.

Check Content

The sendmail.cf log level option line will typically appear as follows: O LogLevel=N Check if Sendmail logging is set to level 9 via the following command: # cat /etc/mail/sendmail.cf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v "^#" | \ grep -i loglevel | tr '\011' ' ' | tr -d ' ' | cut -f 2,2 -d "=" If logging is not set, i.e., line is missing or commented, this is a finding. If logging is set to less than 9, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

If informational and more severe SMTP service messages are not logged, malicious activity on the system may go unnoticed.

Fix Text

Edit the syslog.conf file and add a configuration line specifying an appropriate destination for critical "mail" syslogs, for example: mail.crit /var/adm/messages mail.* /var/adm/messages *.* /var/adm/messages *.crit /var/adm/messages

Check Content

The syslog.conf file critical mail logging option line will typically appear as one of the following examples: mail.crit /var/adm/messages mail.* /var/adm/messages *.* /var/adm/messages *.crit /var/adm/messages Check the syslog configuration file for mail.crit logging configuration. # cat /etc/syslog.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v "^#" | egrep -i "mail.crit|mail.\*|\*.crit|\*.\*" If syslog is not configured to log critical sendmail messages, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If the SMTP service log file is not owned by root, then unauthorized personnel may modify or delete the file to hide a system compromise.

Fix Text

Change the ownership of the sendmail log file. # chown root <sendmail log file>

Check Content

Locate any Sendmail log files by checking the syslog configuration file. # cat /etc/syslog.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v "^#" | \ egrep -i "mail.info|mail.debug|mail.\*|\*.info|\*.debug|\*.\*" | cut -f 2,2 -d " " | uniq | xargs -n1 ls -lL Identify any log files configured for the "mail" service at any severity level, or those configured for all services. Check the ownership of these log files. If any mail log file is not owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the SMTP service log file is more permissive than 0644, unauthorized users may be allowed to change the log file.

Fix Text

Change the mode of the SMTP service log file. # chmod 0644 <sendmail log file>

Check Content

Check the mode of the SMTP service log file. # cat /etc/syslog.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v "^#" | egrep -i "mail.info|mail.debug|mail.\*|\*.info|\*.debug|\*.\*" | cut -f 2,2 -d " " | uniq | xargs -n1 ls -lL Check the configuration to determine which log files contain logs for mail. # ls -lL <sendmail log file> If any Sendmail log file permissions are greater than 0644, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If this file does not exist, then unauthorized accounts can utilize FTP.

Fix Text

Create a /etc/ftpd/ftpusers (or equivalent) file containing a list of /etc/passwd accounts not authorized for FTP.

Check Content

Check for the existence of the ftpusers file. This file is normally located in the /etc/ftpd directory. # ls -lL /etc/ftpd/ftpusers OR alternatively # find / -type f -name ftpusers -exec ls -lL {} \; If the ftpusers file does not exist, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If the file does not contain the names of all accounts not authorized to use FTP, then unauthorized use of FTP may take place.

Fix Text

Add accounts not allowed to use FTP to the /etc/ftpd/ftpusers (or equivalent) file.

Check Content

Check the contents of the ftpusers file. # more /etc/ftpd/ftpusers OR alternatively # find / -type f -name ftpusers -exec ls -lL {} \; If the system has accounts not allowed to use FTP and not listed in the ftpusers file, this is a finding.

Responsibility

System Administrator

Discussion

If the file ftpusers is not owned by root, an unauthorized user may modify the file to allow unauthorized accounts to use FTP.

Fix Text

Change the owner of the ftpusers file to root. # chown root /etc/ftpd/ftpusers

Check Content

Check the ownership of the ftpusers file. # ls -lL /etc/ftpd/ftpusers If the ftpusers file is not owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Excessive permissions on the ftpusers file could permit unauthorized modification. Unauthorized modification could result in Denial of Service to authorized FTP users or permit unauthorized users to access the FTP service.

Fix Text

Change the mode of the ftpusers file to 0640. # chmod 0640 /etc/ftpd/ftpusers

Check Content

Check the permissions of the ftpusers file. # ls -lL /etc/ftpd/ftpusers If the ftpusers file has a mode more permissive than 0640, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The -l option allows basic logging of connections. The verbose (on HP) and the debug (on Solaris) allow logging of what files the ftp session transferred. This extra logging makes it possible to easily track which files are being transferred onto or from a system. If they are not configured, the only option for tracking is the audit files. The audit files are much harder to read. If auditing is not properly configured, then there would be no record at all of the file transfer transactions.

Fix Text

The v option enables more verbose logging, shows the accessed file names, and the logout timestamp. The syslog.conf file must be configured to log daemon.info and daemon.debug to a proper log file in which to capture the data. The output goes into the system log file. The log file is /var/adm/syslog. Edit the inetd.conf file. Locate the line that defines ftpd by typing /ftpd/cr. Add the v option where ftpd appears to the right of the pathname for ftpd. For instance: ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -v This is a requirement even when the system is using TCP_WRAPPERS and/or secure shell. The only time it is not a requirement is if the ftp daemon is not configured to run.

Check Content

Perform: # grep ftpd /etc/inetd.conf Check the line for ftpd to see if the -v options are invoked. If not, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

Due to the numerous vulnerabilities inherent in anonymous FTP, it is not recommended for use. If anonymous FTP must be used on a system, the requirement must be authorized and approved in the system accreditation package.

Fix Text

Configure the FTP service to not permit anonymous logins. Remove the user(s) ftp and/or anonymous from the /etc/passwd file.

Check Content

Attempt to log in with anonymous or ftp. The user can type any string of characters as a password. (By convention, the password is the host name of the user's host or the user's email address.) The anonymous user is then given access only to user ftp's home directory, usually called /home/ftp. If the login is successful, this is a finding.

Responsibility

Information Assurance Officer

IA Controls

ECSC-1

Discussion

Secure mode limits TFTP requests to a specific directory. If TFTP is not running in secure mode, it may be able to write to any file or directory and may seriously impair system integrity, confidentiality, and availability.

Fix Text

Edit /etc/inetd.conf and add one path argument, representing the TFTP root directory, to the tftpd command.

Check Content

Determine if the TFTP daemon is installed, started, and running in secure mode. # cat /etc/inetd.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v "^#" | cut -f 6,7 -d " " | grep -i tftp If the tftpd process is not configured with exactly one path argument (example: "/usr/lbin/tftpd tftpd"), this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If TFTP runs with the setuid or setgid bit set, it may be able to write to any file or directory and may seriously impair system integrity, confidentiality, and availability.

Fix Text

Change the mode of the TFTP daemon. # chmod 0755 /usr/lbin/tftpd

Check Content

Check the mode of the TFTP daemon. # ls -lL /usr/lbin/tftpd If the mode of the file is more permissive than 0755, this is a finding.

Responsibility

System Administrator

IA Controls

ECPA-1

Discussion

If TFTP has a valid shell, it increases the likelihood that someone could logon to the TFTP account and compromise the system.

Fix Text

Create a tftp user account if none exists. Assign a non-login shell to the tftp user account, such as /usr/bin/false. Assign/create the tftp user account home directory where/as necessary. Ensure the home directory is owned by the tftp user.

Check Content

Check the /etc/passwd file to determine if TFTP is configured properly. Procedure: # grep tftp /etc/passwd If a TFTP user account does not exist and TFTP is active, this is a finding. Check the user shell for the TFTP user. If it is not /bin/false or equivalent, this is a finding. Check the home directory assigned to the TFTP user. If no home directory is set, or the directory specified is not dedicated to the use of the TFTP service, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

.Xauthority files ensure the user is authorized to access the specific X Windows host. If .Xauthority files are not used, it may be possible to obtain unauthorized access to the X Windows host.

Fix Text

Ensure the X Windows host is configured to write .Xauthority files into user home directories. Edit the file. Ensure the line writing the .Xauthority file is uncommented.

Check Content

Check for .Xauthority files being utilized by looking for such files in the home directory of a user using X. Get a list of (non-system account) users and the associated home directories. # cat /etc/passwd | cut -f 1,6 -d ":" Inspect individual user home directories for the .Xauthority file. # find <f6 from the above command> -type f -name "\.Xauthority" -exec ls -lLa {} \; If the .Xauthority file does not exist, ask the SA if the user is using X Windows. If the user is utilizing X Windows and the .Xauthority file does not exist, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Due to numerous security vulnerabilities existing within NIS, it must not be used. Possible alternative directory services are NIS+ and LDAP.

Fix Text

Disable the use of NIS. Possible replacements are NIS+ and LDAP-UX.

Check Content

Perform the following to determine if NIS is active on the system. # ps -ef | grep -v grep | egrep "ypbind|ypserv" If NIS is found active on the system, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If users do not have a valid home directory, there is no place for the storage and control of files they own.

Fix Text

For Trusted Mode: Determine why the user is not assigned a home directory. Possible actions include: account deletion or disablement. If the account is determined to be valid, manually create the home directory if required (mkdir directoryname, copy the skeleton files into the directory, chown account name for the new directory and the skeleton files) and assign to the user in the /etc/passwd file or take corrective action via the HP SMH/SAM utility. For SMSE: Note: There may be additional package/bundle updates that must be installed to support attributes in the /etc/default/security file. Determine why the user is not assigned a home directory. Possible actions include: account deletion or disablement. If the account is determined to be valid, manually create the home directory if required (mkdir directoryname, copy the skeleton files into the directory, chown account name for the new directory and the skeleton files) and assign to the user in the /etc/passwd file or take corrective action via the HP SMH/SAM utility. Additionally, use the SAM/SMH interface (/etc/default/security file) and/or the userdbset command (/var/adm/userdb/* files) to update the ABORT_LOGIN_ON_MISSING_HOMEDIR attribute. See the below example: ABORT_LOGIN_ON_MISSING_HOMEDIR=1 Note: Never use a text editor to modify any /var/adm/userdb database file. The database contains checksums and other binary data, and editors (vi included) do not follow the file locking conventions that are used to control access to the database. If manually editing the /etc/default/security file, save any change(s) before exiting the editor.

Check Content

Verify the consistency of the assigned home directories in the authentication database. For Trusted Mode: # authck -av If any user is not assigned a home directory, this is a finding. For SMSE: # pwck If any user is not assigned a home directory, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If a user has a home directory defined that does not exist, the user may be given the / directory, by default, as the current working directory upon logon. This could create a Denial of Service because the user would not be able to perform useful tasks in this location.

Fix Text

Determine why the user home directory does not exist. Possible actions include: account deletion or disablement. If the account is determined to be valid, create the home directory either manually (mkdir directoryname, copy the skeleton files into the directory, chown account name for the new directory and the skeleton files) or via the HP SMH/SAM utility.

Check Content

Verify the consistency of the assigned home directories in the authentication database. For Trusted Mode: # authck -av If any assigned home directory does not exist, this is a finding. For SMSE: # pwck If any assigned home directory does not exist, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

Excessive permissions on home directories allow unauthorized access to user files.

Fix Text

Change the mode of user's home directory to 0750 or less permissive. Procedure (example): # chmod 0750 <home directory> NOTE: Application directories are allowed to and may need 0755 permissions (or greater) for correct operation.

Check Content

Check the home directory mode of each user in /etc/passwd. Procedure: # ls -lLd `cat /etc/passwd | cut -f 6,6 -d ":"` | more If a user's home directory mode is more permissive than 0750, this is a finding. NOTE: Application directories are allowed to and may need 0755 permissions (or greater) for correct operation.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If users do not own their home directories, unauthorized users could access user files.

Fix Text

Change the owner of a user's home directory to its assigned user. Procedure: # chown <user> <home directory>

Check Content

Check the ownership of each user home directory listed in the /etc/passwd file. Procedure: # ls -lLd <user home directory> OR # ls -lLd `cat /etc/passwd | cut -f 6,6 -d ":"` | more If any user home directory is not owned by the assigned user, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the GID of the home directory is not the same as the GID of the user, this would allow unauthorized access to files.

Fix Text

Change the group-owner for user home directories to the primary group of the assigned user. Procedure: # chgrp groupname directoryname (Replace examples with appropriate group and home directory.) Document all changes.

Check Content

Check the group ownership for each user in the /etc/passwd file. Procedure: # ls -lLd <user home directory> OR # ls -lLd `cat /etc/passwd | cut -f 6,6 -d ":"` | more If any user home directory is not group-owned by the assigned user's primary group, this is a finding. Home directories for application accounts requiring different group ownership must be documented using site-defined procedures.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Local initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.

Fix Text

Change the ownership of the startup and login files in the user's directory to the user or root, as appropriate. Examine each user's home directory and verify all filenames beginning with "." are owned by the owner of the directory or root. If they are not, use the chown command to change the owner to the user and research the reasons why the owners were not assigned as required.

Check Content

Check the ownership of local initialization files. Procedure: # ls -alL /<usershomedirectory>/.login # ls -alL /<usershomedirectory>/.cshrc # ls -alL /<usershomedirectory>/.logout # ls -alL /<usershomedirectory>/.profile # ls -alL /<usershomedirectory>/.bash_profile # ls -alL /<usershomedirectory>/.bashrc # ls -alL /<usershomedirectory>/.bash_logout # ls -alL /<usershomedirectory>/.env # ls -alL /<usershomedirectory>/.dtprofile # ls -alL /<usershomedirectory>/.dispatch # ls -alL /<usershomedirectory>/.emacs # ls -alL /<usershomedirectory>/.exrc # find /<usershomedirectory>/.dt ! -fstype nfs ! -user <username> -exec ls -ld {} \; If local initialization files are not owned by the home directory's user or root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Local initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.

Fix Text

Ensure user startup files have permissions of 0740 or more restrictive. Examine each user's home directory and verify all file names beginning with "." have access permissions of 0740 or more restrictive. If they do not, use the chmod command to correct the vulnerability. Procedure: # chmod 0740 .filename NOTE: The period is part of the file name and is required.

Check Content

Check the modes of local initialization files. Procedure: # ls -alL /<usershomedirectory>/.login # ls -alL /<usershomedirectory>/.cschrc # ls -alL /<usershomedirectory>/.logout # ls -alL /<usershomedirectory>/.profile # ls -alL /<usershomedirectory>/.bash_profile # ls -alL /<usershomedirectory>/.bashrc # ls -alL /<usershomedirectory>/.bash_logout # ls -alL /<usershomedirectory>/.env # ls -alL /<usershomedirectory>/.dtprofile (permissions should be 0755) # ls -alL /<usershomedirectory>/.dispatch # ls -alL /<usershomedirectory>/.emacs # ls -alL /<usershomedirectory>/.exrc # find /<usershomedirecotory>/.dt ! -fstype nfs \( -perm -0002 -o -perm -0020 \) -exec ls -ld {} \; (permissions not to be more permissive than 0755) If local initialization files are more permissive than 0740, the .dt directory is more permissive than 0755, or the .dtprofile file is more permissive than 0755, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the startup files are writable by other users, they could modify the startup files to insert malicious commands into the startup files.

Fix Text

Ensure all system startup files have mode 0755 or less permissive. Examine the rc files, all files in the rc1.d (rc2.d, and so on) directories, and in the /etc/init.d directory to ensure they are not world-writable. If they are world-writable, use the chmod command to correct the vulnerability, and research why they are world-writable. # chmod 755 startupfile

Check Content

Verify run control scripts have no extended ACLs. # ls -lLa /sbin/init.d/[a-z,A-Z,0-9]* If the permissions include a "+" the file has an extended ACL, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, two consecutive colons, or a single period, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths.

Fix Text

Edit the run control script and remove the relative path entries from the executable search path variable that are not documented with the ISSO. Edit the run control script and remove any empty entry that is defined.

Check Content

Verify the run control scripts search paths do not contain references to the current working directory or other relative paths that have not been authorized by the ISSO. # grep "PATH" /sbin/init.d/[a-z,A-Z,0-9]* | grep -v "_PATH" This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/), or has not been documented with the ISSO, this is a finding.

Responsibility

System Administrator

Discussion

World-writable files could be modified accidentally or maliciously to compromise system integrity.

Fix Text

Remove the world-writable permission from programs or scripts executed by run control scripts. Procedure: # chmod o-w <program or script executed from run control script>

Check Content

Check the permissions on the files or scripts executed from system startup scripts to see if they are world-writable. Create a list of all potential run command level scripts. # ls -l /etc/init.d/* | tr '\011' ' ' | tr -s ' ' | cut -f 9,9 -d " " OR # ls -l /sbin/init.d/* | tr '\011' ' ' | tr -s ' ' | cut -f 9,9 -d " " Create a list of world writeable files. # find / -perm -002 -type f >> worldWriteableFileList Determine if any of the world writeable files in worldWriteableFileList are called from the run command level scripts. Note: Depending upon the number of scripts vs world writeable files, it may be easier to inspect the scripts manually. # more `ls -l /etc/init.d/* | tr '\011' ' ' | tr -s ' ' | cut -f 9,9 -d " "` OR # more `ls -l /sbin/init.d/* | tr '\011' ' ' | tr -s ' ' | cut -f 9,9 -d " "` If any system startup script executes any file or script that is world-writable, this is a finding.

Responsibility

System Administrator

Discussion

Unencrypted passwords for remote FTP servers may be stored in .netrc files. Policy requires passwords to be encrypted in storage and not used in access scripts.

Fix Text

Remove the .netrc file(s). Procedure: # rm .netrc

Check Content

Check the system for the existence of any .netrc files. Procedure: # find / -name .netrc If any .netrc file exists, this is a finding.

Responsibility

System Administrator

IA Controls

IAIA-1, IAIA-2

Discussion

If users do not own the files in their directories, unauthorized users may be able to access them. Additionally, if files are not owned by the user, this could be an indication of system compromise.

Fix Text

Change the ownership of files and directories in user home directories to the owner of the home directory. Procedure: # chown <account-owner> <filename>

Check Content

For each user in the /etc/passwd file, check for the presence of files and directories within the user's home directory that are not owned by the home directory owner. # find /<usershomedirectory> ! -fstype nfs ! -user <username> ! \( -name .login -o -name .cshrc -o -name .logout -o -name .profile -o -name .bash_profile -o -name .bashrc -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc \) -exec ls -ld {} \; Or # ls -lLR `cat /etc/passwd | cut -f 6,6 -d ":"` | more If user home directories contain files or directories not owned by the home directory owner, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2

Discussion

Excessive permissions allow unauthorized access to user files.

Fix Text

Change the mode of files and directories within user home directories to 0750. Procedure: # chmod 0750 filename Document all changes.

Check Content

For each user in the /etc/passwd file, check for files and directories with a mode more permissive than 0750. NOTE the following exclusions/exemptions: HP installed users "hpsmh" and "cimsrvr". Note that some home directories "may" restrict access to their files. # find /<usershomedirectory> ! -fstype nfs ! \( -name .login -o -name .cshrc -o -name .logout -o -name .profile -o -name .bash_profile -o -name .bbashrc -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc \) \( -perm -0001 -o -perm -0002 -o -perm -0004 -o -perm -0020 -o -perm -2000 -o -perm -4000 \) -exec ls -ld {} \; Or # ls -lLR `cat /etc/passwd | cut -f 6,6 -d ":"` | more If user home directories contain files or directories more permissive than 0750, this is a finding.

Responsibility

Information Assurance Officer

IA Controls

ECLP-1

Discussion

The shells file (or equivalent) lists approved default shells. It helps provide layered defense to the security approach by ensuring users cannot change their default shell to an unauthorized, unsecure shell.

Fix Text

Create /etc/shells file containing a list of valid system shells. Consult vendor documentation for an appropriate list of system shells. Procedure: Typical installed shells include: /sbin/sh /usr/bin/sh /usr/bin/rsh /usr/bin/ksh /usr/bin/rksh /usr/bin/csh /usr/bin/keysh # echo "/sbin/sh" >> /etc/shells (Repeat as necessary for all existing shell programs.)

Check Content

Verify /etc/shells exists. # ls -l /etc/shells If the file does not exist, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

The shells file lists approved default shells. It helps provide layered defense to the security approach by ensuring users cannot change their default shell to an unauthorized, unsecure shell.

Fix Text

Use the chsh utility or edit the /etc/passwd file and correct the error by changing the default shell of the account in error to an acceptable shell name contained in the /etc/shells file. Alternatively, use the HP SMH to change the /etc/passwd shell entry.

Check Content

Confirm the login shells referenced in the /etc/passwd file are listed in the /etc/shells file. Procedure: # more /etc/passwd # more /etc/shells The /usr/bin/false, /bin/false, /dev/null, /sbin/nologin, (and equivalents), and sdshell will be considered valid shells for use in the /etc/passwd file, but will not be listed in the /etc/shells file. If a shell referenced in /etc/passwd is not listed in the shells file, excluding the above mentioned shells, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

Inactive user accounts pose a risk to systems and applications. Owners of Inactive accounts will not notice if unauthorized access to their account has been obtained. There is a risk that inactive accounts can potentially be exploited to obtain and maintain undetected access to a system and/or application. The operating system must track periods of user account inactivity and disable all inactive accounts. Non-interactive accounts on the system, such as application accounts, may be documented exceptions. Non-interactive accounts on the system, such as application accounts, may be documented exceptions. Non-interactive accounts on the system, such as application accounts, may be documented exceptions.

Fix Text

For Trusted Mode: Use the SAM/SMH interface to update the “u_llogin” (user last login) /tcb database attribute. See the /tcb database entry example below: :u_llogin#3024000: For SMSE: Note: There may be additional package/bundle updates that must be installed to support attributes in the /etc/default/security file. Use the SAM/SMH interface (/etc/default/security file) and/or the userdbset command (/var/adm/userdb/* files) to update the INACTIVITY_MAXDAYS attribute. See the below example: INACTIVITY_MAXDAYS=35 Note: Never use a text editor to modify any /var/adm/userdb database file. The database contains checksums and other binary data, and editors (vi included) do not follow the file locking conventions that are used to control access to the database. If manually editing the /etc/default/security file, save any change(s) before exiting the editor.

Check Content

For Trusted Mode: Verify that user accounts are locked after 35 days of inactivity. Note: The “u_llogin” attribute is stored in seconds: 86400 seconds/day * 35 days = 3024000 seconds. # cd /tcb/files/auth && cat */* | egrep “:u_name=|:u_llogin=“ If user account is not set to lock after 35 days of inactivity, this is a finding. For SMSE: Check the INACTIVITY_MAXDAYS setting. # grep INACTIVITY_MAXDAYS /etc/default/security /var/adm/userdb/* If INACTIVITY_MAXDAYS is set to 0 or greater than 35 for any user, this is a finding.

Responsibility

System Administrator

IA Controls

IAAC-1

Discussion

If shell files are owned by users other than root or bin, they could be modified by intruders or malicious users to perform unauthorized actions.

Fix Text

Change the ownership of any system shell not owned by root or bin: # chown root <path/shell>

Check Content

Check the ownership of the system shells. # cat /etc/shells | xargs -n1 ls -lL If any shell is not owned by root or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Shells with world/group-write permissions give the ability to maliciously modify the shell to obtain unauthorized access.

Fix Text

Change the mode of the shell. # chmod 0755 <shell>

Check Content

If /etc/shells exists, check the group ownership of each shell referenced. # cat /etc/shells | xargs -n1 ls -lL Otherwise, check any shells found on the system. # find / -name "*sh" | xargs -n1 ls -lL If a shell has a mode more permissive than 0755, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If an unauthorized device is allowed to exist on the system, there is the possibility the system may perform unauthorized operations.

Fix Text

Establish a weekly automated or manual process to create a list of device files on the system and determine if any files have been added, moved, or deleted since the last list was generated. A list of device files can be generated with this command: # find / -type b -o -type c -o -type n > device-file-list

Check Content

NOTE: This will virtually always be a manual review. Check the system for an automated job, or check with the SA, to determine if the system is checked for extraneous device files on a weekly basis. If no automated or manual process is in place, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

System device files in writable directories could be modified, removed, or used by an unprivileged user to control system hardware.

Fix Text

Remove the world-writable permission from the device file(s). # chmod o-w <device file> Document all changes.

Check Content

Find all device special files existing anywhere on the system. Types include: b=block, c=character, p=fifo. Example: # find / -type b -print >> devicelist # find / -type c -print >> devicelist # find / -type p -print >> devicelist Check the permissions on the directories above subdirectories that contain device files. If any device file, or directory containing device files, is world-writable, except device files specifically intended to be world-writable such as /dev/null, this is a finding. Note the following exception/exclusion list: /dev/pts/*, /dev/pty/*, /dev/ptym/*, the following in dev: full, zero, null, tty, ptmx, pty*, tcp, udp, ip, arp, udp6, tcp6, rawip6, ip6, rawip, rtsock, ipsecpol, ipseckey, sad, dlpi*, sasd*, ttyp*, ttyq*, ttyr*, strlog, telnetm, tlclts, asyncdsk, async, tlcots, tlcotsod, echo, beep, gvid0, gvid, poll, log, log.um, stcpmap, nuls, usctp6, sctp6, usctp, syscon, and sctp.

Responsibility

System Administrator

Discussion

System backups could be accidentally or maliciously overwritten and destroy the ability to recover the system if a compromise should occur. Unauthorized users could also copy system files.

Fix Text

Use the chmod command to remove the read/write bit(s) from the backup device files. # chmod o-r <b/u device file name> # chmod o-w <b/u device file name> # chmod g-r <b/u device file name> # chmod g-w <b/u device file name> Document all changes.

Check Content

Check the system for device files read/write enabled for users other than root or the backup user. Example: # find / \( -perm -0020 -o -perm -0040 -o -perm -0002 -o -perm -0004 \) -a \( -type b -o -type c -o -type n \) -exec ls -ld {} \; If any device files used for backup are read/write enabled for users other than root, this is a finding.

Responsibility

Information Assurance Officer

IA Controls

ECCD-1, ECCD-2

Discussion

If the NIS+ server is not operating in, at least, security level 2, there is no encryption and the system could be penetrated by intruders and/or malicious users.

Fix Text

Configure the NIS+ server to use security level 2.

Check Content

If the system is not using NIS+, this is not applicable. Check the system to determine if NIS+ security level two is implemented. Execute this command: # niscat cred.org_dir If the second column does not contain DES, the system is not using NIS+ security level two, and this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

Failure to give ownership of the NFS export configuration file to root provides the designated owner and possible unauthorized users with the potential to change system configuration which could weaken the system's security posture.

Fix Text

Change the owner of the /etc/dfs/dfstab file to root. # chown root /etc/dfs/dfstab

Check Content

Check the owner of the /etc/dfs/dfstab file. # echo `ls -lL /etc/dfs/dfstab` | sed -e 's/^[ \t]*//' | tr '\011' ' ' | tr -s ' ' | cut -f 3,3 -d " " If the /etc/dfs/dfstab configuration file is not owned by root or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Excessive permissions on the NFS share configuration file could allow unauthorized modification of the file, which could result in Denial-of-Service to authorized NFS shares and the creation of additional unauthorized shares.

Fix Text

# chmod 0644 /etc/dfs/dfstab

Check Content

# echo `ls -lL /etc/dfs/dfstab` | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | cut -f 1,1 -d " " If the file has a mode more permissive than 0644, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2, ECLP-1

Discussion

Failure to give ownership of sensitive files or directories to root provides the designated owner and possible unauthorized users with the potential to access sensitive information or change system configuration which could weaken the system's security posture.

Fix Text

Change the ownership of shared file systems not owned by root, or a system account. # chown root <path>

Check Content

Check for NFS shared file systems. # cat /etc/dfs/sharetab This will display all of the shared file systems. For each file system displayed, check the ownership. Check the owner of the NFS share configuration file. # echo ` ls -lLad <shared file system path>` | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' If the files and directories are not owned by root or a system account, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

When an NFS server is configured to deny remote root access, a selected UID and GID are used to handle requests from the remote root user. The UID and GID should be chosen from the system to provide the appropriate level of non-privileged access.

Fix Text

Edit /etc/dfs/sharetab and set the anon=-1 option for shares without it. Re-export the file systems.

Check Content

Check if the 'anon' option is set correctly for shared file systems. # cat /etc/dfs/dfstab Each of the shared file systems should include an entry for the 'anon=' option set to -1 or an equivalent (60001, 65534, or 65535). If an appropriate 'anon=' setting is not present for a shared file system, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

The NFS access option limits user access to the specified level. This assists in protecting shared file systems. If access is not restricted, unauthorized hosts may be able to access the system's NFS shares.

Fix Text

Edit /etc/dfs/dfstab and add ro and/or rw options (as appropriate) that specify a list of hosts or networks which are permitted access. Re-share the file systems via the following commands: # unshare <the file system entry that was modified> # share <the file system entry that was modified>

Check Content

Check the permissions on shared NFS file systems. Procedure: # cat /etc/dfs/sharetab If the shared file systems do not contain the "rw" or "ro" options that specify a list of hosts or networks, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system.

Fix Text

Edit /etc/dfs/dfstab and remove the root= option for all shares. Re-share the file systems.

Check Content

Determine if the NFS server is sharing with the root access option. # cat /etc/dfs/sharetab | grep "root=" If a share with the root option is found, this is a finding.

Responsibility

System Administrator

IA Controls

EBRP-1

Discussion

Enabling the nosuid mount option prevents the system from granting owner or group-owner privileges to programs with the suid or sgid bit set. If the system does not restrict this access, users with unprivileged access to the local system may be able to acquire privileged access by executing suid or sgid files located on the mounted NFS file system.

Fix Text

Edit /etc/fstab and add the nosuid option for all NFS file systems. Remount the NFS file systems to make the change take effect.

Check Content

Check the system for NFS mounts that do not use the nosuid option. # mount -v | grep " type nfs " | grep -v "nosuid" If the mounted file systems do not have the nosuid option, this is a finding.

Responsibility

System Administrator

IA Controls

ECPA-1

Discussion

Access control programs (such as TCP_WRAPPERS) provide the ability to enhance system security posture.

Fix Text

Edit /etc/inetd.conf and use tcpd to wrap active services.

Check Content

Locate the inetd.conf file (normally located within the /etc directory). # find /etc -type f -name inetd.conf Determine if TCP_WRAPPERS is used. The following example demonstrates one possible single inetd.conf line first without and then with the service tcp wrapped. telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd telnet stream tcp6 nowait root /usr/sbin/tcpd telnetd # cat <path>/inetd.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' |grep -v "^#" | grep tcpd If there are unwrapped active services listed, this is a finding.

Responsibility

System Administrator

IA Controls

EBRU-1

Discussion

If access attempts are not logged, then multiple attempts to log on to the system by an unauthorized user may go undetected.

Fix Text

Configure the access restriction program to log every access attempt. Ensure the implementation instructions for TCP_WRAPPERS are followed so logging of system access attempts is logged into the system log files. If an alternate application is used, it must support this function.

Check Content

Normally, tcpd logs to the mail facility in the syslog.conf file (normally located within the /etc directory). Determine if syslog is configured to log events by tcpd. # find /etc -type f -name syslog.conf # cat <path>/syslog.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' |grep -v “^#” | egrep “mail.debug|mail.info|mail.\*” Look for an entry similar to the following, indicating that mail alerts are being logged: mail.* /var/log/maillog If no entries for mail exist, then tcpd is not logging and this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-2, ECAR-3

Discussion

When operating in standard mode, account passwords are stored in the /etc/passwd file, which is world readable. By operating in either Trusted Mode or Standard Mode with Security Extensions, the system security posture is enhanced thru the addition of a secure, non-world readable password container other than /etc/passwd.

Fix Text

SAM/SMH must be used to convert standard mode HP-UX to Trusted Mode (optional for SMSE). For Trusted Mode only: The following command may be used to “manually” convert from Standard Mode to Trusted Mode (note that its use is not vendor supported): # tsconvert -c For SMSE only: The following command may be used to “manually” create the /etc/shadow file with information from the /etc/passwd file (use of this commend is vendor supported). # pwconv Note that additional software bundles and/or patches may be required in order to completely convert a standard mode system to SMSE.

Check Content

For Trusted Mode: Determine if the /tcb directory tree exists. # ls -lLd /tcb If the /tcb directory tree does not exist, this is a finding. For SMSE: Determine if the userdb directory tree and the /etc/shadow file exists. # ls -lL /var/adm/userdb # ls -lL /etc/shadow If both the /var/adm/userdb directory tree and the /etc/shadow file do not exist, this is a finding.

Responsibility

System Administrator

IA Controls

DCSW-1

Discussion

Root, sys, and bin are the most privileged group accounts, by default, for most UNIX systems. If a file as sensitive as /etc/securetty is not group-owned by a privileged group, it could lead to system compromise.

Fix Text

Change the group-owner of the /etc/securetty to root, bin, or sys. Example: # chgrp root /etc/securetty

Check Content

ls -lL /etc/securetty

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Failure to make root the owner of sensitive files and utilities may provide unauthorized owners the potential to access and/or change sensitive information or system configurations, thus weakening the overall security posture of a site.

Fix Text

Change the owner of the /etc/securetty file to root. # chown root /etc/securetty

Check Content

Check the ownership of the /etc/securetty file. ls -lL /etc/securetty If /etc/securetty is not owned by root, sys, or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Excessive permissions on the /etc/securetty file could result in unauthorized modification of the file. Changes to the file could reduce the system's security by specifying additional terminals permitted to accept root logins, or deny service by preventing root logins on authorized terminals.

Fix Text

Change the mode of the /etc/securetty file to 0640. Example: # chmod 0640 /etc/securetty

Check Content

Check the mode of the securetty file. Example: # ls -lL /etc/securetty If /etc/securetty has a mode more permissive than 0640, this is a finding.

Responsibility

System Administrator

IA Controls

ECCD-1, ECCD-2, ECLP-1

Discussion

The cron facility allows users to execute recurring jobs on a regular and unattended basis. The cron.allow file designates accounts allowed to enter and execute jobs using the cron facility. If neither cron.allow nor cron.deny exists, then any account may use the cron facility. This may open the facility up for abuse by system intruders and malicious users.

Fix Text

Create /var/adm/cron/cron.allow and/or /var/adm/cron/cron.deny with appropriate local content.

Check Content

Check for the existence of the cron.allow and cron.deny files. # ls -lL /var/adm/cron/cron.allow # ls -lL /var/adm/cron/cron.deny If neither file exists, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

A cron.allow file, readable and/or writable by other than root, could allow potential intruders and malicious users to use the file contents to help discern information, such as who is allowed to execute cron programs, which could be harmful to overall system and network security.

Fix Text

Change the mode of the cron.allow file to 0600. Procedure: # chmod 0600 /var/adm/cron/cron.allow

Check Content

Check mode of the cron.allow file. Procedure: # ls -lL /var/adm/cron/cron.allow If the file has a mode more permissive than 0600, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If cron executes group-writable or world-writable programs, there is a possibility that unauthorized users could manipulate the programs with malicious intent. This could compromise system and network security.

Fix Text

Remove the world-writable and group-writable permissions from the cron program file(s) identified. # chmod go-w <cron program file>

Check Content

List all cronjobs on the system. Procedure: # ls -lL /var/spool/cron/crontabs If cron jobs exist under any of the above directories, search for programs executed by cron. Procedure: # more <cron job file> Determine if the file is group-writable or world-writable. Procedure: # ls -lLa <cron program file> If cron executes group-writable or world-writable files, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

If cron programs are located in or subordinate to world-writable directories, they become vulnerable to removal and replacement by malicious users or system intruders.

Fix Text

Remove the world-writable permission from the cron program directories identified. Procedure: # chmod o-w <cron program directory>

Check Content

List all cronjobs on the system. Procedure: # ls -lL /var/spool/cron/crontabs If cron jobs exist under any of the above directories, search for programs executed by cron: Procedure: # more <cron job file> Determine if the directory containing programs executed from cron is world-writable. Procedure: # ls -lLd <cron program directory> If cron executes programs in world-writable directories, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured.

Fix Text

Change the mode of the crontab files. # chmod 0600 /var/spool/cron/crontabs/*

Check Content

Check the mode of the crontab files. # ls -lL /var/spool/cron/crontabs If any crontab file has a mode more permissive than 0600, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured.

Fix Text

Change the mode of crontab directories to 0755.

Check Content

Check the mode of the crontab directory. # ls -lLd /var/spool/cron/crontabs If the mode of the crontab directory is more permissive than 0755, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Incorrect ownership of the cron or crontab directories could permit unauthorized users the ability to alter cron jobs and run automated jobs as privileged users. Failure to give ownership of cron or crontab directories to root or to bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

Change the mode of the crontab directory. # chown root /var/spool/cron/crontabs

Check Content

Check the owner of the crontab directory. # ls -ld /var/spool/cron/crontabs If the owner of the crontab directory is not root or bin, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured. Failure to give group-ownership of cron or crontab directories to a system group provides the designated group and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.

Fix Text

Change the group owner of the crontab directories to root, sys, bin or other. # chown root /var/spool/cron/crontabs

Check Content

Check the group owner of the crontab directories. # ls -lLd /var/spool/cron/crontabs If the directory is not group-owned by root, sys, bin or other, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users.

Fix Text

Enable cron/logging on the system via: # /sbin/init.d/cron stop # mv <current cron log> <to a new location and new name> # /sbin/init.d/cron start # more /var/adm/cron/log Cron automatically handles its own logging function and (at least) the Start Time should be visible at the beginning of the new log file /var/adm/cron/log.

Check Content

# ls -lL /var/adm/cron/log If this file does not exist, or has a timestamp older than the last cron job, this is a finding.

Responsibility

System Administrator

IA Controls

ECAR-1, ECAR-2, ECAR-3

Discussion

Cron logs contain reports of scheduled system activities and must be protected from unauthorized access or manipulation.

Fix Text

Change the mode of the cron log file. # chmod 0600 /var/adm/cron/log

Check Content

Check the mode of the cron log file. # ls -lL /var/adm/cron/log If the mode is more permissive than 0600, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1, ECTP-1

Discussion

The at facility selectively allows users to execute jobs at deferred times. It is usually used for one-time jobs. The at.allow file selectively allows access to the at facility. If there is no at.allow file, there is no ready documentation of who is allowed to submit at jobs.

Fix Text

Create at.allow and/or at.deny files containing appropriate lists of users to be allowed or denied access to the at facility supported by the cron daemon.

Check Content

Check for the existence of at.allow and at.deny files. # ls -lL /var/adm/cron/at.allow # ls -lL /var/adm/cron/at.deny If neither file exists, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

On some systems, if there is no at.allow file and there is an empty at.deny file, then the system assumes everyone has permission to use the at facility. This could create an insecure setting in the case of malicious users or system intruders.

Fix Text

Add appropriate users to the at.deny file, or remove the empty at.deny file if an at.allow file exists.

Check Content

# more /var/adm/cron/at.deny If the at.deny file exists and is empty, this is a finding.

Responsibility

Information Assurance Officer

IA Controls

ECLP-1

Discussion

Default accounts, such as bin, sys, adm, uucp, daemon, and others, should never have access to the at facility. This would create a possible vulnerability open to intruders or malicious users.

Fix Text

Remove the default accounts (such as bin, sys, adm, and others) from the at.allow file.

Check Content

# more /var/adm/cron/at.allow If default accounts (such as bin, sys, adm, and others) are listed in the at.allow file, this is a finding.

Responsibility

System Administrator

IA Controls

ECPA-1

Discussion

Permissions more permissive than 0600 (i.e. read, write and execute for the owner) may allow unauthorized or malicious access to the at.allow and/or at.deny files.

Fix Text

Change the mode of the at.allow file. # chmod 0600 /var/adm/cron/at.allow

Check Content

Check the mode of the at.allow file. # ls -lL /var/adm/cron/at.allow If the at.allow file has a mode more permissive than 0600, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the at facility executes group- or world-writable programs, it is possible for the programs to be accidentally or maliciously changed or replaced without the owner's intent or knowledge. This would cause a system security breach.

Fix Text

Remove group-write and world-write permissions from files executed by at jobs. # chmod go-w <file>

Check Content

List the at jobs on the system. Procedure: # ls -lLa /var/spool/cron/atjobs For each at job file, determine which programs are executed. # more <at job file> Check each program executed by at for group- or world-writable permissions. # ls -lLa <at program file> If at executes programs that are group- or world-writable, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

If at programs are located in, or subordinate, to world-writable directories, they become vulnerable to removal and replacement by malicious users or system intruders.

Fix Text

Remove the world-writable permission from directories containing programs executed by at. # chmod o-w <at program directory>

Check Content

List any at jobs on the system. # ls -lLa /var/spool/cron/atjobs For each at job, determine which programs are executed by at. # more <at job file> Check the directory containing each program executed by at for world-writable permissions. # ls -lL <at program file directory> If at executes programs in world-writable directories, this is a finding.

Responsibility

System Administrator

IA Controls

DCSL-1

Discussion

Whether active or not, default SNMP passwords, users, and passphrases must be changed to maintain security. If the service is running with the default authenticators, then anyone can gather data about the system and the network using the information to potentially compromise the integrity of the system or network(s).

Fix Text

Change the default passwords. To change them, edit the /etc/SnmpAgent.d/snmpd.conf file. Locate the line system-group-read-community which has a default password of public and make the password something more random (less guessable). Do the same for the lines reading system-group-write-community, read-community, write-community, trap, and trap-community. Read the information in the file carefully. The trap is defining who to send traps to, for instance, by default. It will not be a password, but the name of a host.

Check Content

Check the SNMP configuration for default passwords. Locate and examine the SNMP configuration. # more /etc/SnmpAgent.d/snmpd.conf Alternatively: # cat /etc/SnmpAgent.d/snmpd.conf | grep -i community Identify any community names or user password configuration. If any community name or password is set to a default value such as public, private, snmp-trap, or password, or any value which does not meet DISA password requirements, this is a finding.

Responsibility

System Administrator

IA Controls

IAAC-1

Discussion

The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification.

Fix Text

Change the mode of the SNMP daemon configuration file to 0600. # chmod 0600 /etc/SnmpAgent.d/snmpd.conf

Check Content

Check the mode of the SNMP daemon configuration file. # ls -lL /etc/SnmpAgent.d/snmpd.conf If the /etc/SnmpAgent.d/snmpd.conf file has a mode more permissive than 0600, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

The ability to read the MIB file could impart special knowledge to an intruder or malicious user about the ability to extract compromising information about the system or network.

Fix Text

Change the mode of MIB files to 0640. # chmod 0640 <mib file>

Check Content

Check the modes for all MIB files on the system. # find / -type f -name *.mib -exec ls -lL {} \; If any file is returned without a mode 0640 or less permissive, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Inetd or xinetd logging and tracing allows the system administrators to observe the IP addresses connecting to their machines and to observe what network services are being sought. This provides valuable information when trying to find the source of malicious users and potential malicious users.

Fix Text

Edit the (x)inetd startup script to include the -l parameter for the internet daemon process.

Check Content

# ps -ef | grep -v grep | egrep -i "inetd|xinetd" If the -l logging parameter is not used, this is a finding. If the (x)inetd process is not running, this is not a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

The ability to boot from removable media is the same as being able to boot into single user, or maintenance, mode without a password. This ability could allow a malicious user to boot the system and perform changes possibly compromising or damaging the system. It could also allow the system to be used for malicious purposes by a malicious anonymous user.

Fix Text

Configure the system to only boot from system startup media. The system must first be rebooted in order to set primary and alternate boot paths for the desired system startup media.

Check Content

HP-UX 11-v3 may be booted from the following system startup media (must have been previously configured by root): • Hard drives • CD/DVD drives (for installation) • Tape drives (for installation) • USB directly connected drives (no hubs) Determine if the system is configured to boot from devices other than the system startup media. Verification should (optimally) be performed during IPL/ISL boot. In lieu of rebooting the system, ask the SA if the system is configured to boot from devices other than system startup media. If so, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

INN servers access Usenet newsfeeds and store newsgroup articles. INN servers use the Network News Transfer Protocol (NNTP) to transfer information from the Usenet to the server and from the server to authorized remote hosts. If this function is necessary to support a valid mission requirement, its use must be authorized and approved in the system accreditation package.

Fix Text

Disable the INN server.

Check Content

Check the domain name for NIS maps. Procedure: # domainname If the name returned is simple to guess, such as the organization name, building, or room name, etc., this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

SWAT is a tool used to configure Samba. As it modifies Samba configuration, which can impact system security, it must be protected from unauthorized access. SWAT authentication may involve the root password, which must be protected by encryption when traversing the network. Restricting access to the local host allows for the use of SSH TCP forwarding, if configured, or administration by a web browser on the local system.

Fix Text

Disable SWAT. # chmod 0000 <path>/swat OR # rm -i <path>/swat

Check Content

Determine if the CIFS (HP SAMBA) bundle is installed (SWAT is included). # swlist -l bundle | egrep -i "CIFS-CLIENT|CIFS-SERVER" If the HP bundle is not installed, this is not applicable. If the HP bundle is installed, ask the SA if the Samba Web Administration Tool (SWAT) has been configured to use SSL. If SWAT is not configured to use SSL, this is a finding.

Responsibility

System Administrator

IA Controls

EBRP-1

Discussion

The /etc/smb.conf file allows access to other machines on the network and grants permissions to certain users. If it is owned by another user, the file may be maliciously modified and the Samba configuration could be compromised.

Fix Text

Change the ownership of the smb.conf file. # chown root /etc/opt/samba/smb.conf

Check Content

Check the ownership of the /etc/smb.conf file. # ls -lL /etc/opt/samba/smb.conf If the smb.conf file is not owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the smb.conf file has excessive permissions, the file may be maliciously modified and the Samba configuration could be compromised.

Fix Text

Change the mode of the smb.conf file to 0644 or less permissive. # chmod 0644 /etc/opt/samba/smb.conf

Check Content

Check the mode of the smb.conf file. # ls -lL /etc/opt/samba/smb.conf If the smb.conf has a mode more permissive than 0644, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the smbpasswd file is not owned by root, the smbpasswd file may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.

Fix Text

Use the chown command to configure the smb passwd file. # chown root <path>/smbpasswd

Check Content

Check the ownership of the smbpasswd file. # ls -lL /var/opt/samba/private/smbpasswd If the smbpasswd file is not owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Samba increases the attack surface of the system and must be restricted to communicate only with systems requiring access.

Fix Text

Edit the smb.conf file and set the hosts option to permit only authorized hosts access Samba. An example might be: hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24 hosts deny = 0.0.0.0/0 The above will only allow SMB connections from the localhost and from the two private networks 192.168.2 and 192.168.3. All other connections will be refused as soon as the client sends its first packet.

Check Content

Examine the smb.conf file. # cat /etc/opt/samba/smb.conf | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v "^#" | egrep "^hosts|^ hosts allow|^hosts deny" If the hosts option is not present to restrict access to a list of authorized hosts and networks, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

The ability to change passwords frequently facilitates users reusing the same password. This can result in users effectively never changing their passwords. This would be accomplished by users changing their passwords when required and then immediately changing it to the original value.

Fix Text

For both Trusted Mode and SMSE: Use the SAM/SMH interface to ensure that password changes are restricted to no less than once every 24 hours. Use the SAM/SMH interface (/etc/default/security file) and/or the userdbset command (/var/adm/userdb/* files) to ensure that password changes are restricted to no less than once every 24 hours. See the below example: PASSWORD_MINDAYS=1 Note: Never use a text editor to modify any /var/adm/userdb database file. The database contains checksums and other binary data, and editors (vi included) do not follow the file locking conventions that are used to control access to the database. If manually editing the /etc/default/security file, save any change(s) before exiting the editor.

Check Content

For Trusted Mode: Check the “u_minchg” attribute in the users TS database entry. Individual user: # export PATH=$PATH:/usr/lbin # getprpw -r -m mintm <USER> All users: # logins -o -x | awk -F: '{print $1” “$10}' If the value is less than 1 for any user, this is a finding. For SMSE: Check the PASSWORD_MINDAYS attribute. # grep PASSWORD_MINDAYS /etc/default/security /var/adm/userdb/* If the attribute PASSWORD_MINDAYS is less than 1, this is a finding.

Responsibility

System Administrator

IA Controls

ECSC-1

Discussion

If a user accesses the root account (or any account) using an unencrypted connection, the password is passed over the network in clear text form and is subject to interception and misuse. This is true even if recommended procedures are followed by logging on to a named account and using the su command to access root.

Fix Text

Enable SSH on the system and use it for all remote connections used to attain root access.

Check Content

Perform the following to determine if root has logged in over an unencrypted network connection. The first command determines if root has logged in over a network. The second will check to see if the SSH daemon is running. Procedure: # last -R | grep "^root " | egrep -v "reboot|console" | more # ps -ef |grep sshd If the output from the last command shows root has logged in over the network and sshd is not running, this is a finding.

Responsibility

System Administrator

IA Controls

IAIA-1, IAIA-2

Discussion

Even though communications are encrypted, an additional layer of security may be gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account preserves the audit trail.

Fix Text

Edit the configuration file and set the PermitRootLogin option to no.

Check Content

Check the SSH daemon configuration. Note that keywords are case-insensitive and arguments (args) are case-sensitive. keyword=PermitRootLogin Required arg(s)=no Default arg values include: "yes" Note: When the default "arg" value exactly matches the required "arg" value (see above), the <keyword=arg> are not required to exist (commented or uncommented) in the ssh (client) or sshd (server) configuration file. While not required, it is recommended that the configuration file(s) be populated with all keywords and assigned arg values as a means to explicitly document the ssh(d) binary's expected behavior. Examine the file. # cat /opt/ssh/etc/sshd_config | tr '\011' ' ' | tr -s ' ' | sed -e 's/^[ \t]*//' | grep -v '^#' | grep -i "PermitRootLogin" If the return value is yes, without-password or forced-commands-only, this is a finding.

Responsibility

System Administrator

IA Controls

ECPA-1

Discussion

Globally accessible audio and video devices have proven to be another security hazard. There is software capable of activating system microphones and video devices connected to user workstations and/or X terminals. Once the microphone has been activated, it is possible to eavesdrop on otherwise private conversations without the victim being aware of it. This action effectively changes the user's microphone into a bugging device.

Fix Text

Change the mode of audio devices. # chmod 0660 <audio device>

Check Content

Check the mode of audio device files. Determine audio devices and class identifiers, i.e., audio should be listed as audio. # ioscan Determine audio device special files. # ioscan -fn -C <audio class ID from the above command output> Determine the device file mode. # ls -lL <device special file> If the mode of any audio device file is more permissive than 0660, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Globally accessible audio and video devices have proven to be another security hazard. There is software capable of activating system microphones and video devices connected to user workstations and/or X terminals. Once the microphone has been activated, it is possible to eavesdrop on otherwise private conversations without the victim being aware of it. This action effectively changes the user's microphone into a bugging device.

Fix Text

Change the owner of the audio device. # chown root <audio device>

Check Content

Check the owner of audio devices. Determine audio devices and class identifiers, i.e., audio should be listed as audio. # ioscan Determine audio device special files. # ioscan -fn -C <audio class ID from the above command output> Determine the device file mode. # ls -lL <device special file> If the owner of any audio device file is not root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the group-owner of the smb.conf file is not root or a system group, the file may be maliciously modified and the Samba configuration could be compromised.

Fix Text

Change the group owner of the "smb.conf" file. # chgrp root /etc/samba/smb.conf

Check Content

Check the group ownership of the smb.conf file. # find / -type f -name smb.conf | xargs -n1 ls -lL If the smb.conf file is not group-owned by root, bin, sys or other, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the smbpasswd file is not group-owned by root, it may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.

Fix Text

Use the chgrp command to ensure that the group owner of the smbpasswd file is root. # chgrp root <path>/smbpasswd

Check Content

Check smbpasswd ownership: # ls -lL /var/opt/samba/private/smbpasswd If the smbpasswd file is not group-owned by root, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

If the smbpasswd file has a mode more permissive than 0600, it may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.

Fix Text

Change the mode of the smbpasswd file to 0600. # chmod 0600 <path>/smbpasswd

Check Content

Check the mode of files maintained using smbpasswd. # ls -lL /var/opt/samba/private/smbpasswd If the smbpasswd file is more permissive than 0600, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

Without privileged group owners, audio devices will be vulnerable to being used as eaves-dropping devices by malicious users or intruders possibly listening to conversations containing sensitive information.

Fix Text

Change the group owner of the audio device. Procedure: # chgrp system <audio device>

Check Content

Check the group-owner of audio devices. Procedure: # /usr/sbin/ioscan -f # ls -lL <audio device file> If the group-owner of an audio device is not root, sys, bin, or system, this is a finding.

Responsibility

System Administrator

IA Controls

ECLP-1

Discussion

To ensure the root shell is available in repair and administrative modes, the root shell must be located in the / file system.

Fix Text

Change the root account's shell to one present on the / file system.

Check Content