Discussion

The "/etc/security/mkuser.sys.custom" is called by "/etc/security/mkuser.sys" to customize the new user account when a new user is created, or a user is logging into the system without a home directory. An improper "/etc/security/mkuser.sys.custom" script increases the risk that non-privileged users may obtain elevated privileges. It must not exist unless it is needed.

Fix Text

Remove the "/etc/security/mkuser.sys.custom" file using the following command: # rm /etc/security/mkuser.sys.custom

Check Content

Check if the "/etc/security/mkuser.sys.custom" file exists: # ls /etc/security/mkuser.sys.custom If the above command shows the file exists, this is a finding.

Discussion

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary accounts are used, the operating system must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours. To address access requirements, many operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

Fix Text

From the command prompt, execute the following command to set the expiration time to 72 hours from now: # chuser expires=1218103116 tmp_user From the command prompt, execute the following command: # lsuser -a expires tmp_user The above command should yield the following output: tmp_user expires=1218103116

Check Content

From the command prompt, execute the following command: # lsuser -a expires tmp_user The above command should yield the following output: tmp_user expires=0 Or tmp_user expires=1215103116 The "expires" value is in "MMDDhhmmyy" form, or the value is "0". If "expires" value is "0", or the expiration time is greater than "72" hours from the user creation time, this is a finding.

Discussion

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-force attacks, is reduced. Limits are imposed by locking the account. Satisfies: SRG-OS-000021-GPOS-00005, SRG-OS-000329-GPOS-00128

Fix Text

From the command prompt, execute the following command to configure the number of unsuccessful logins resulting in account lockout for "default:" stanza in "/etc/security/user" file: # chsec -f /etc/security/user -s default -a loginretries=3 From the command prompt, execute the following command to configure the number of unsuccessful logins resulting in account lockout for all users who have loginretries values that are 0 or greater than 3: # chsec -f /etc/security/user -s [user_name] -a loginretries=3

Check Content

From the command prompt, execute the following command to check the system default value for the maximum number of tries before the system will lock the account: # lssec -f /etc/security/user -s default -a loginretries The above command should yield the following output: default loginretries=0 If the default value is "0" or greater than "3", this is a finding. From the command prompt, execute the following command to check all active accounts on the system for the maximum number of tries before the system will lock the account: # lsuser -a loginretries ALL | more The above command should yield the following output: root loginretries=3 user1 loginretries=2 If a user has values set to "0" or greater than "3", this is a finding.

Discussion

Operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to DoS attacks.

Fix Text

From the command prompt, execute the following command to set "maxulogs=10" for the "default:" stanza in the "/etc/security/user" file: # chsec -f /etc/security/user -s default -a maxulogs=10 For each user account whose "maxulogs" value is greater than "10", or their "maxulogs" value is not set, or the values are set to "0", execute the following command to set "maxulogs=10": # chuser maxulogs=10 [user_name]

Check Content

From the command prompt, execute the following command to display maxulogs values for all the user account: # lsuser -a maxulogs ALL The above command should yield the following output: root maxulogs=10 user_1 maxulogs=10 If the above command shows any user account that does not have the "maxulogs" attribute set, or its value is "0", or its value greater than "10", this is a finding.

Discussion

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted.

Fix Text

Note: Depending on which version of GSKit is installed on AIX, the GSK commands that are used to manage the Key Database (KDB) have different names. The possible GSK commands are: gsk8capicmd (used below), gsk8capicmd_64 and gsk7cmd. Create a key database with DoD PKI or DoD-approved certificate using one of the following commands: # gsk8capicmd -keydb -create -db <KDB_FILE> -pw <KDB_PASSWORD> -type cms -stash Edit "/etc/security/ldap/ldap.cfg" and add or edit the "ldapsslkeyf" setting to reference a KDB file containing a client certificate issued by DoD PKI or a DoD-approved external PKI. Install a certificate signed by a DoD PKI or a DoD-approved external PKI using the following command: # gsk8capicmd -cert -add -db <KDB_FILE> -pw <KDB_PASSWORD> -file <CERT_FILE> -label <CERT_LABEL> Remove un-needed CA certificates using one of the following commands: # gsk8capicmd -cert -delete -db <KDB_FILE> -pw <KDB_PASSWORD> -label <CERT_LABEL> Restart LDAP client using command: # /usr/sbin/restart-secldapclntd

Check Content

If LDAP authentication is not used on AIX, this is Not Applicable. Note: Depending on which version of GSKit is installed on AIX, the GSK commands that are used to manage the Key Database (KDB) have different names. The possible GSK commands are: gsk8capicmd (used below), gsk8capicmd_64 and gsk7cmd. Check if the system is using LDAP authentication: # grep LDAP /etc/security/user If no lines are returned, this requirement is not applicable. Check if the useSSL option is enabled: # grep '^useSSL' /etc/security/ldap/ldap.cfg useSSL:yes If "yes" is not the returned value, this is a finding. Verify a certificate is used for client authentication to the server: # grep -i '^ldapsslkeyf' /etc/security/ldap/ldap.cfg ldapsslkeyf:/tmp/key.kdb If no line is found, this is a finding. Identify the Key Database (KDB), and its password, by asking the ISSO/SA. If no Key Database exists on the system, this is a finding. List the certificate issuer with GSK command: # gsk8capicmd -cert -list CA -db <KDB_FILE> -pw <KDB_PASSWORD> Make note of the client Key Label: # gsk8capicmd -cert -details -showOID -db <KDB_FILE> -pw <KDB_PASSWORD> -label <Key Label> If the certificate is not issued by DoD PKI or a DoD-approved external PKI, this is a finding The IBM GSK Database should only have certificates for the client system and for the LDAP server. If more certificates are in the key database than the LDAP server and the client, this is a finding.

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.

Fix Text

To remove the clear-text password for "bindpwd", do the following two steps: Edit "/etc/security/ldap/ldap.cfg" to remove the "bindpwd" line and save the change; Re-config the LDAP client using the "mksecldap" command: # mksecldap -c -h <LDAP_HOST:LDAP_PORT> -A <auth_type> -D <Default_Entry> -d <BASE_DN> -a <BIND_USER> -p <BIND_PASSWORD> -k <KDB_FILE> -w <KDB_PASSWORD> Note: Depending on which version of GSKit is installed on AIX, the GSK commands that are used to manage the Key Database (KDB) have different names. The possible GSK commands are: "gsk8capicmd" (used below), "gsk8capicmd_64" and "gsk7cmd". To use the stashed password for SSL key database (KDB), do the following two steps: Edit "/etc/security/ldap/ldap.cfg" to remove the "ldapsslkeypwd" line and save the change; Run the "gsk8capicmd" to create a stashed password file for the SSL KDB: # gsk8capicmd -keydb -stashpw -db <KDB_FILE> -pw <KDB_PASSWORD>

Check Content

Examine the LDAP configuration file "/etc/security/ldap/ldap.cfg" for possible clear-text password for "bindpwd". From the command prompt, run the following command: # grep ^bindpwd: /etc/security/ldap/ldap.cfg The above command should yield the following output: bindpwd:{DESv2}57AEE2BCED 764373462FC7B62736D9A If the returned entry has an unencrypted password (the output line does not start with "bindpwd:{DES"), this is a finding. Examine the LDAP configuration file "/etc/security/ldap/ldap.cfg" for using stashed password for SSL key database (KDB). Check for "ldapsslkeypwd" in LDAP config file using the follow command: # grep '^ldapsslkeypwd' /etc/security/ldap/ldap.cfg If the command returned a line, this is a finding.

Discussion

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following: 1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and 2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.

Fix Text

Edit user accounts to provide unique name for each account by editing the following files: /etc/passwd /etc/security/passwd /etc/security/user /etc/group

Check Content

From the command prompt, run the following command to check that there are no duplicate account names: # usrck -n ALL If any duplicate account names are found, this is a finding.

Discussion

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Lack of authentication and identification enables non-organizational users to gain access to the application or possibly other information systems and provides an opportunity for intruders to compromise resources within the application or information system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following: 1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and 2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Satisfies: SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062

Fix Text

Edit user accounts to provide unique names and UIDs for each account by editing the following files: /etc/passwd /etc/group /etc/security/passwd /etc/security/user

Check Content

From the command prompt, run the following command to ensure there are no duplicate UIDs: # usrck -n ALL If any duplicate UIDs are found, this is a finding.

Discussion

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following: 1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and 2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.

Fix Text

For every user who has "SYSTEM=NONE", run the following command to set their "SYSTEM" value to "compat": # chuser SYSTEM=compat [user_name]

Check Content

Examine the "SYSTEM" attribute values for all users in the "/etc/security/user" file by running the following command: # lsuser -a SYSTEM ALL The above command should yield the following output: root SYSTEM=compat daemon SYSTEM=compat bin SYSTEM=compat sys SYSTEM=compat If the command displays SYSTEM=NONE for a user, this is a finding.

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

Direct login to shared or application accounts can be prevented by setting the "rlogin=false" in the accounts stanza of the "/etc/security/user" file. From the command prompt, run the following command to set "rlogin=false" for a shared account: # chuser rlogin=false [shared_account]

Check Content

Obtain a list of Shared/Application/Default/Utility accounts from the ISSO/ISSM. Shared/Application/Default/Utility accounts can have direct login disabled by setting the "rlogin" parameter to "false" in the user’s stanza of the "/etc/security/user" file. From the command prompt, run the following command to check if shared account has "rlogin=true": # lsuser -a rlogin [shared_account] <shared_account> rlogin=true If a shared account is configured for "rlogin=true", this is a finding.

Discussion

A replay attack may enable an unauthorized user to gain access to the operating system. Authentication sessions between the authenticator and the operating system validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A privileged account is any information system account with authorizations of a privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators. Satisfies: SRG-OS-000112-GPOS-00057, SRG-OS-000113-GPOS-00058

Fix Text

If the SSH server package is not installed, install "openssh.base.server" package from AIX DVD Volume 1 using the following command (assuming that the DVD device is /dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log openssh.base.server After the installation, set up the SSH server accordingly. If the SSH daemon is not running, run the following command to start it: # startsrc -s sshd

Check Content

Run the following command to check if SSH server package is installed: # lslpp -i |grep -i ssh openssh.base.server 6.0.0.6201 If package "openssh.base.server" is not installed, this is a finding. Run the following command to check if SSH daemon is running: # lssrc -s sshd The above command should yield the following output: Subsystem Group PID Status sshd ssh 4325532 active If the "Status" is not "active", this is a finding.

Discussion

Emergency accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Emergency accounts are different from infrequently used accounts (i.e., local login accounts used by the organization's system administrators when network or normal login/access is not available). Infrequently used accounts are not subject to automatic termination dates. Emergency accounts are accounts created in response to crisis situations, usually for use by maintenance personnel. The automatic expiration or disabling time period may be extended as needed until the crisis is resolved; however, it must not be extended indefinitely. A permanent account should be established for privileged users who need long-term maintenance accounts. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

Fix Text

From the command prompt, run the following command to set the "expires" value to "72" hours from now: # chuser expires=1228093516 <emergency_user> The "expires" value parameter is a 10-character string in the MMDDhhmmyy form, where MM = month, DD = day, hh = hour, mm = minute, and yy = last 2 digits of the years 1939 through 2038. All characters are numeric.

Check Content

Obtain a list of emergency accounts from the ISSO/ISSM and then run this command against each of the identified accounts: # lsuser -a expires <emergency_user> The above command should yield the following output: <emergency_user> expires=0 Or <emergency_user> expires=1215103116 The "expires" value parameter is a 10-character string in the MMDDhhmmyy form, where MM = month, DD = day, hh = hour, mm = minute, and yy = last 2 digits of the years 1939 through 2038. All characters are numeric. If the Value parameter is 0, the account does not expire. If "expires" value is "0", or the expiration time is greater than "72" hours from the user creation time, this is a finding.

Discussion

The "/etc/security/mkuser.sys" script customizes the new user account when a new user is created, or a user is logging into the system without a home directory. An improper "/etc/security/mkuser.sys" script increases the risk that non-privileged users may obtain elevated privileges.

Fix Text

Edit the script /etc/security/mkuser.sys to contain the following: # This file is no longer user customizable. To have a customized mkuser.sys script # create a file /etc/security/mkuser.sys.custom and the /etc/security/mkuser.sys # will run this script instead of the original mkuser.sys script. export PATH=/usr/bin:/usr/sbin:$PATH # # Check the number of arguments first # if [ $# -ne 4 ] then exit 1 fi # # If a customer mkuser.sys.custom script exists # then execute it instead and exit passing all arguments # and returning the return code from mkuser.sys.custom # if [ -x /etc/security/mkuser.sys.custom ] then /etc/security/mkuser.sys.custom $* exit $? fi # # Create the named directory if it does not already exist # and set the file ownership and permission # if [ ! -d $1 ] then last=$1 while [ 1 ] do dir=`dirname $last` if [ -d $last ] then break elif [ -d $dir ] then mkdir -p $1 chown -R bin:bin $last chmod -R 755 $last break else last=$dir fi done chgrp "$3" $1 chown $2 $1 fi # # Copy the user's default .profile if it does not already # exist and change the file ownership, etc. # if [ `basename $4` != "csh" ] && [ ! -f $1/.profile ] then cp /etc/security/.profile $1/.profile chmod u+rwx,go-w $1/.profile chgrp "$3" $1/.profile chown $2 $1/.profile else if [ `basename $4` = "csh" ] && [ ! -f $1/.login ] then echo "#!/bin/csh" > "$1"/.login echo "set path = ( /usr/bin /etc /usr/sbin /usr/ucb \$HOME/bin /usr/bin/X11 /sbin . )" >> "$1"/.login echo "setenv MAIL \"/var/spool/mail/\$LOGNAME\"" >> "$1"/.login echo "setenv MAILMSG \"[YOU HAVE NEW MAIL]\"" >> "$1"/.login echo "if ( -f \"\$MAIL\" && ! -z \"\$MAIL\") then" >> "$1"/.login echo " echo \"\$MAILMSG\"" >> "$1"/.login echo "endif" >> "$1"/.login chmod u+rwx,go-w $1/.login chgrp "$3" $1/.login chown $2 $1/.login fi fi

Check Content

Use the "cat" command to show the content of "/etc/security/mkuser.sys" script: # cat /etc/security/mkuser.sys The cat command should display the following: # This file is no longer user customizable. To have a customized mkuser.sys script # create a file /etc/security/mkuser.sys.custom and the /etc/security/mkuser.sys # will run this script instead of the original mkuser.sys script. export PATH=/usr/bin:/usr/sbin:$PATH # # Check the number of arguments first # if [ $# -ne 4 ] then exit 1 fi # # If a customer mkuser.sys.custom script exists # then execute it instead and exit passing all arguments # and returning the return code from mkuser.sys.custom # if [ -x /etc/security/mkuser.sys.custom ] then /etc/security/mkuser.sys.custom $* exit $? fi # # Create the named directory if it does not already exist # and set the file ownership and permission # if [ ! -d $1 ] then last=$1 while [ 1 ] do dir=`dirname $last` if [ -d $last ] then break elif [ -d $dir ] then mkdir -p $1 chown -R bin:bin $last chmod -R 755 $last break else last=$dir fi done chgrp "$3" $1 chown $2 $1 fi # # Copy the user's default .profile if it does not already # exist and change the file ownership, etc. # if [ `basename $4` != "csh" ] && [ ! -f $1/.profile ] then cp /etc/security/.profile $1/.profile chmod u+rwx,go-w $1/.profile chgrp "$3" $1/.profile chown $2 $1/.profile else if [ `basename $4` = "csh" ] && [ ! -f $1/.login ] then echo "#!/bin/csh" > "$1"/.login echo "set path = ( /usr/bin /etc /usr/sbin /usr/ucb \$HOME/bin /usr/bin/X11 /sbin . )" >> "$1"/.login echo "setenv MAIL \"/var/spool/mail/\$LOGNAME\"" >> "$1"/.login echo "setenv MAILMSG \"[YOU HAVE NEW MAIL]\"" >> "$1"/.login echo "if ( -f \"\$MAIL\" && ! -z \"\$MAIL\") then" >> "$1"/.login echo " echo \"\$MAILMSG\"" >> "$1"/.login echo "endif" >> "$1"/.login chmod u+rwx,go-w $1/.login chgrp "$3" $1/.login chown $2 $1/.login fi fi If the "cat" command shows the script as different than the content listed above, this is a finding.

Discussion

The /usr/lib/security/mkuser.default file contains the default primary groups for regular and admin users. Setting a system group as the regular users' primary group increases the risk that the regular users can access privileged resources.

Fix Text

Set the default primary groups for regular to be "staff". # chsec -f /etc/security/mkuser.default -s user -a pgrp=staff

Check Content

Check the default primary group for regular users: # lssec -f /etc/security/mkuser.default -s user -a pgrp The above command should yield the following output: user pgrp=staff If the above command shows that the primary group (pgrp) is not "staff", this is a finding.

Discussion

Restricting permissions will protect the files from unauthorized modification.

Fix Text

Change the owner of public directories to "root" or an application account using the following command: # chown root </public/directory> Note: Replace "root" with an application user as necessary.

Check Content

Check the ownership of system files, programs, and directories by running the following command: # ls -lLa /etc /bin /usr/bin /usr/lbin /usr/ucb /sbin /usr/sbin If any of the system files, programs, or directories are not owned by a system account, this is a finding. Note: For this check, the system-provided "ipsec" user is considered to be a system account.

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) using command: # chmod o-w <device file>

Check Content

Find all device files existing anywhere on the system using commands: # find / -type b -print | xargs ls -l > devicelistB # find / -type c -print | xargs ls -l > devicelistC Look at devicelistB and devicelistC files to check the permissions on the device files and directories above the subdirectories containing device files. If any of the device files or their parent directories are world-writable, excepting device files specifically intended to be world-writable, such as "/dev/null", this is a finding.

Discussion

Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Operating system functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Fix Text

Edit the "/etc/ssh/sshd_config" file to add or update the following line: PrintLastLog yes. Restart sshd service: # stopsrc -s sshd # startsrc -s sshd

Check Content

Verify the SSH daemon is configured to display last login information using command: # cat /etc/ssh/sshd_config | grep -i ^PrintLastLog PrintLastLog yes If "PrintLastLog" is not set to "yes", this is a finding.

Discussion

A user's "ttys" attribute controls from which device(s) the user can authenticate and log in. If the "ttys" attribute is not specified, all terminals can access the user account.

Fix Text

From the command prompt, run the following command to set "ttys=ALL" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a ttys=ALL Run the following command to recheck "ttys" values for all users: # lsuser -a ttys ALL For each interactive user who does not have "ttys=ALL", set the value of "ttys" to "ALL" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a ttys=ALL

Check Content

Verify that the default "ttys" value is set for all users: # lssec -f /etc/security/user -s default -a ttys default ttys=ALL If the value returned is not "ttys=ALL", this is a finding. From the command prompt, run the following command to check "ttys" attribute value for all accounts: # lsuser -a ttys ALL The above command should yield the following output: root ttys=ALL user1 ttys=ALL user2 ttys=ALL user3 ttys=ALL If any interactive user account does not have "ttys=ALL", this is a finding.

Discussion

All systems are vulnerable if terminals are left logged in and unattended. Leaving system terminals unsecure poses a potential security hazard. To lock the terminal, use the lock command.

Fix Text

Install "bos.rte.security" fileset from the AIX DVD Volume 1 using the following command (assuming that the DVD device is mounted to /dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log bos.rte.security

Check Content

Check the system to determine if "bos.rte.security" is installed: # lslpp -L bos.rte.security Fileset Level State Type Description (Uninstaller) ---------------------------------------------------------------------------- bos.rte.security 7.2.1.1 C F Base Security Function If the "bos.rte.security" fileset is not installed, this is a finding. Check if lock command exist using the following command: # ls /usr/bin/lock The above command should display the following: /usr/bin/lock If the above command does not show that "/usr/bin/lock" exists, this is a finding.

Discussion

All systems are vulnerable if terminals are left logged in and unattended. Leaving system terminals unsecure poses a potential security hazard. If the interface is AIXwindows (CDE), use the xlock command to lock the sessions.

Fix Text

Install "X11.apps.clients" fileset from the AIX DVD Volume 1 using the following command (assuming that the DVD is mounted to/dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log X11.apps.clients

Check Content

If AIX CDE (X11) is not used, this is Not Applicable. Check the system to determine if "X11.apps.clients" is installed: # lslpp -L X11.apps.clients If the "X11.apps.clients" fileset is not installed, this is a finding. Check if "xlock" command exists using the following command: # ls /usr/bin/X11/xlock The above command should display the following: /usr/bin/X11/xlock If the above command does not show that "/usr/bin/X11/xlock" exists, this is a finding.

Discussion

Limiting the root account direct logins to only system consoles protects the root account from direct unauthorized access from a non-console device. A common attack method of potential hackers is to obtain the root password. To avoid this type of attack, disable direct access to the root ID and then require system administrators to obtain root privileges by using the su - command. In addition to permitting removal of the root user as a point of attack, restricting direct root access permits monitoring which users gained root access, as well as the time of their action. Do this by viewing the /var/adm/sulog file. Another alternative is to enable system auditing, which will report this type of activity. To disable remote login access for the root user, edit the /etc/security/user file. Specify False as the rlogin value on the entry for root.

Fix Text

From the command prompt, run the following command to set "rlogin=false" for the root stanza in "/etc/security/user": # chsec -f /etc/security/user -s root -a rlogin=false

Check Content

Check the remote login ability of the root account using command: # lsuser -a rlogin root root rlogin=false If the "rlogin" value is not "false", this is a finding.

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

Use the following command to change the owner to "root" for public directories: # chown root [public_dir]

Check Content

Check the ownership of all public directories using command: # 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.

Discussion

If a web browser flaw is exploited while running as a privileged user, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy. These exceptions may include HTTP(S)-based tools used for the administration of the local system, services, or attached devices. Examples of possible exceptions are HP’s System Management Homepage (SMH), the CUPS administrative interface, and Sun's StorageTek Common Array Manager (CAM) when these services are running on the local system.

Fix Text

Enforce policy requiring administrative accounts use web browsers only for local service administration.

Check Content

Inspect the root account home directory for a ".netscape" or a ".mozilla" directory using the following commands: # find /home/root -name .netscape # find /home/root -name .mozilla If none exists, this is not a finding. If a file exists, verify with the root users and the ISSO the intent of the browsing. If a file exists and use of a web browser has not been authorized, this is a finding.

Discussion

To centralize the management of privileged account crontabs, of the default system accounts, only root may have a crontab.

Fix Text

Remove default system accounts (such as bin, sys, adm, or lpd) from the "cron.allow" file, or add those accounts to the "cron.deny" file.

Check Content

Check the "cron.allow" and "cron.deny" files for the system using commands: # more /var/adm/cron/cron.allow # more /var/adm/cron/cron.deny If the "cron.allow" file exists and is empty, this is a finding. If a default system account (such as bin, sys, adm, or lpd) is listed in the "cron.allow" file, or not listed in the "cron.deny" file, this is a finding.

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, perform one of the following. Remove the world-writable permission on the directory. Run command: # chmod o-w <path> -OR- Remove the world-writable directory from the executable search path. 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: # ls -ld `echo $PATH | sed "s/:/ /g"` drwxr-xr-x 33 root system 8192 Nov 29 14:45 /etc drwxr-xr-x 3 bin bin 256 Aug 11 2017 /sbin drwxr-xr-x 4 bin bin 45056 Oct 31 12:59 /usr/bin drwxr-xr-x 1 bin bin 16 Aug 11 2017 /usr/bin/X11 drwxr-xr-x 2 bin bin 4096 Aug 11 2017 /usr/java7_64/bin drwxr-xr-x 4 bin bin 4096 Feb 17 2017 /usr/java7_64/jre/bin drwxr-xr-x 8 bin bin 49152 Oct 31 12:59 /usr/sbin drwxrwxr-x 2 bin bin 4096 Aug 11 2017 /usr/ucb If any of the directories in the "PATH" variable are world-writable, this is a finding.

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 GID for non-system accounts that have reserved GIDs as their primary GIDs using the following command: # chuser pgrp=<non_reserved_group_name> <non_system_user_name>

Check Content

From the command prompt, run the following command: # more /etc/passwd root:!:0:0::/root:/usr/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: nobody:!:4294967294:4294967294::/: invscout:*:6:12::/var/adm/invscout:/usr/bin/ksh srvproxy:*:203:0:Service Proxy Daemon:/home/srvproxy:/usr/bin/ksh esaadmin:*:7:0::/var/esa:/usr/bin/ksh sshd:*:212:203::/var/empty:/usr/bin/ksh doejohn:*:704:1776::/home/doej:/usr/bin/ksh Confirm all accounts with a primary 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.

Discussion

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

Fix Text

Using the "usermod" command, change the UID numbers for non-system accounts with reserved UIDs (those less or equal to 128): # usermod -u <uid> [user_name]

Check Content

Check the UID assignments of all accounts using: # more /etc/passwd root:!:0:0::/root:/usr/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: nobody:!:4294967294:4294967294::/: invscout:*:6:12::/var/adm/invscout:/usr/bin/ksh srvproxy:*:203:0:Service Proxy Daemon:/home/srvproxy:/usr/bin/ksh esaadmin:*:7:0::/var/esa:/usr/bin/ksh sshd:*:212:203::/var/empty:/usr/bin/ksh doej:*:704:1776::/home/doej:/usr/bin/ksh Confirm all accounts with a UID of 128 and below are used by a system account. If a UID reserved for system accounts (0-128) is used by a non-system account, this is a finding.

Discussion

The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded.

Fix Text

Edit the "root" user's initialization files and remove any definition of "LDR_PRELOAD".

Check Content

Verify the "LDR_PRELOAD" environment variable is empty or not defined for the "root" user using command: # env | grep LDR_PRELOAD If a path is returned, this is a finding.

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

Configure a password for any interactive account with a blank password by running the following command: # passwd [user_name]

Check Content

Verify no interactive accounts have blank passwords by running the following command: # pwdck -n ALL If any interactive account with a blank password is found, this is a finding.

Discussion

Users' home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources.

Fix Text

Use the following command to change protections for the root home directory: # chmod 0700 /root.

Check Content

Check the mode of the root home directory by running the following commands: # ls -ld `grep "^root" /etc/passwd | awk -F":" '{print $6}'` The above command should yield the following output: drwx------ 22 root system 4096 Sep 06 18:00 /root If the mode of the directory is not equal to "0700", this is a finding.

Discussion

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

Fix Text

Remove the extended ACL from the "root" account's home directory using command: # acledit ~root Change extended attributes to disabled.

Check Content

Verify the "root" account's home directory has no extended ACL using command: # aclget ~root * * ACL_type AIXC * attributes: base permissions owner(root): rwx group(system): --- others: --- extended permissions disabled If extended permissions are enabled, the directory has an extended ACL, and this is a finding.

Discussion

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."

Fix Text

From the command prompt, run the following command to set the DoD banner to herald for the default stanza in the "/etc/security/login.cfg" file: # chsec -f /etc/security/login.cfg -s default -a herald="You are accessing a U.S. Government (USG) Information System (IS) that\n\ris provided for USG-authorized use only.\n\r\n\rBy using this IS (which includes any device attached to this IS), you\n\rconsent to the following conditions: \n\r\n\r-The USG routinely intercepts and monitors communications on this IS\n\rfor purposes including, but not limited to, penetration testing, COMSEC\n\rmonitoring, network operations and defense, personnel misconduct (PM),\n\rlaw enforcement (LE), and counterintelligence (CI) investigations. \n\r\n\r-At any time, the USG may inspect and seize data stored on this IS. \n\r\n\r-Communications using, or data stored on, this IS are not private, are\n\rsubject to routine monitoring, interception, and search, and may be\n\rdisclosed or used for any USG-authorized purpose. \n\r\n\r-This IS includes security measures (e.g., authentication and access\n\rcontrols) to protect USG interests--not for your personal benefit or\n\rprivacy. \n\r\n\r-Notwithstanding the above, using this IS does not constitute consent\n\rto PM, LE or CI investigative searching or monitoring of the content\n\rof privileged communications, or work product, related to personal\n\rrepresentation or services by attorneys, psychotherapists, or clergy,\n\rand their assistants. Such communications and work product are private\n\rand confidential. See User Agreement for details.\n\r\n\rlogin:"

Check Content

Check the herald is set to have the Standard Mandatory DoD Notice and Consent Banner: # lssec -f /etc/security/login.cfg -s default -a herald The above command should display the herald setting like this: default herald="You are accessing a U.S. Government (USG) Information System (IS) that\n\ris provided for USG-authorized use only.\n\r\n\rBy using this IS (which includes any device attached to this IS), you\n\rconsent to the following conditions: \n\r\n\r-The USG routinely intercepts and monitors communications on this IS\n\rfor purposes including, but not limited to, penetration testing, COMSEC\n\rmonitoring, network operations and defense, personnel misconduct (PM),\n\rlaw enforcement (LE), and counterintelligence (CI) investigations. \n\r\n\r-At any time, the USG may inspect and seize data stored on this IS. \n\r\n\r-Communications using, or data stored on, this IS are not private, are\n\rsubject to routine monitoring, interception, and search, and may be\n\rdisclosed or used for any USG-authorized purpose. \n\r\n\r-This IS includes security measures (e.g., authentication and access\n\rcontrols) to protect USG interests--not for your personal benefit or\n\rprivacy. \n\r\n\r-Notwithstanding the above, using this IS does not constitute consent\n\rto PM, LE or CI investigative searching or monitoring of the content\n\rof privileged communications, or work product, related to personal\n\rrepresentation or services by attorneys, psychotherapists, or clergy,\n\rand their assistants. Such communications and work product are private\n\rand confidential. See User Agreement for details.\n\r\n\rlogin:" If the herald string is not set, or it does not contain the Standard Mandatory DoD Notice and Consent Banner listed above, this is a finding.

Discussion

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."

Fix Text

Edit the "Xresources" file to configure the system to display one of the DoD login banners (based on the character limitations imposed by the system) prior to, or as part of, the graphical desktop environment login process. For "Dtlogin", change the variable "Dtlogin*greeting.labelString:" in "Xresources" file. # cp /usr/dt/config/C/Xresources /etc/dt/config/en_US/Xresources # vi /etc/dt/config/en_US/Xresources Set variable "Dtlogin*greeting.labelString" as the following: Dtlogin*greeting.labelString: You are accessing a U.S. Government (USG) Information System (IS) that\nis provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you\nconsent to the following conditions: \n\n-The USG routinely intercepts and monitors communications on this IS\nfor purposes including, but not limited to, penetration testing, COMSEC\nmonitoring, network operations and defense, personnel misconduct (PM),\nlaw enforcement (LE), and counterintelligence (CI) investigations. \n\n-At any time, the USG may inspect and seize data stored on this IS. \n\n-Communications using, or data stored on, this IS are not private, are\nsubject to routine monitoring, interception, and search, and may be\ndisclosed or used for any USG-authorized purpose. \n\n-This IS includes security measures (e.g., authentication and access\ncontrols) to protect USG interests--not for your personal benefit or\nprivacy. \n\n-Notwithstanding the above, using this IS does not constitute consent\nto PM, LE or CI investigative searching or monitoring of the content\nof privileged communications, or work product, related to personal\nrepresentation or services by attorneys, psychotherapists, or clergy,\nand their assistants. Such communications and work product are private\nand confidential. See User Agreement for details. Save the above change to "Xresources" file.

Check Content

If AIX CDE (X11) is not used, this is Not Applicable. Check if file "/etc/dt/config/en_US/Xresources" exists: # ls /etc/dt/config/en_US/Xresources If the file does not exist, this is a finding. Check if the "Dtlogin*greeting.labelString" is set to the Standard Mandatory DoD Notice and Consent Banner: # grep "Dtlogin*greeting.labelString" /etc/dt/config/en_US/Xresources The above command should display the following: Dtlogin*greeting.labelString: You are accessing a U.S. Government (USG) Information System (IS) that\nis provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you\nconsent to the following conditions: \n\n-The USG routinely intercepts and monitors communications on this IS\nfor purposes including, but not limited to, penetration testing, COMSEC\nmonitoring, network operations and defense, personnel misconduct (PM),\nlaw enforcement (LE), and counterintelligence (CI) investigations. \n\n-At any time, the USG may inspect and seize data stored on this IS. \n\n-Communications using, or data stored on, this IS are not private, are\nsubject to routine monitoring, interception, and search, and may be\ndisclosed or used for any USG-authorized purpose. \n\n-This IS includes security measures (e.g., authentication and access\ncontrols) to protect USG interests--not for your personal benefit or\nprivacy. \n\n-Notwithstanding the above, using this IS does not constitute consent\nto PM, LE or CI investigative searching or monitoring of the content\nof privileged communications, or work product, related to personal\nrepresentation or services by attorneys, psychotherapists, or clergy,\nand their assistants. Such communications and work product are private\nand confidential. See User Agreement for details. If the "Dtlogin*greeting.labelString" variable is not set, or the label string does not contain the Standard Mandatory DoD Notice and Consent Banner, this is a finding.

Discussion

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."

Fix Text

Create file "/etc/motd.ssh" to contain the following: "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." Modify "/etc/ssh/sshd_config" to contain the following line: Banner /etc/motd.ssh Restart the SSH daemon by running the following commands: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check if file "/etc/motd.ssh" exists: # ls /etc/motd.ssh If the file does not exist, this is a finding. Check if "/etc/motd.ssh" contains The Standard Mandatory DoD Notice and Consent Banner: # cat /etc/motd.ssh The above command should display the following Standard Mandatory DoD Notice and Consent Banner: "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." If the Standard Mandatory DoD Notice and Consent Banner is not displayed by the "cat" command, this is a finding. Check if /etc/motd.ssh is used as banner file in SSH config file: # grep -i "Banner /etc/motd.ssh" /etc/motd.ssh If the above grep command does not find "Banner /etc/motd.ssh" in the "/etc/motd.ssh" file, this is a finding.

Discussion

Display of a standardized and approved use notification before granting access to the publicly accessible operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."

Fix Text

From the command prompt, run the following command to set the DoD banner to herald for the default stanza in /etc/security/login.cfg: # chsec -f /etc/security/login.cfg -s default -a herald="You are accessing a U.S. Government (USG) Information System (IS) that\n\ris provided for USG-authorized use only.\n\r\n\rBy using this IS (which includes any device attached to this IS), you\n\rconsent to the following conditions: \n\r\n\r-The USG routinely intercepts and monitors communications on this IS\n\rfor purposes including, but not limited to, penetration testing, COMSEC\n\rmonitoring, network operations and defense, personnel misconduct (PM),\n\rlaw enforcement (LE), and counterintelligence (CI) investigations. \n\r\n\r-At any time, the USG may inspect and seize data stored on this IS. \n\r\n\r-Communications using, or data stored on, this IS are not private, are\n\rsubject to routine monitoring, interception, and search, and may be\n\rdisclosed or used for any USG-authorized purpose. \n\r\n\r-This IS includes security measures (e.g., authentication and access\n\rcontrols) to protect USG interests--not for your personal benefit or\n\rprivacy. \n\r\n\r-Notwithstanding the above, using this IS does not constitute consent\n\rto PM, LE or CI investigative searching or monitoring of the content\n\rof privileged communications, or work product, related to personal\n\rrepresentation or services by attorneys, psychotherapists, or clergy,\n\rand their assistants. Such communications and work product are private\n\rand confidential. See User Agreement for details.\n\r\n\rlogin:"

Check Content

Check the herald is set to have the Standard Mandatory DoD Notice and Consent Banner: # lssec -f /etc/security/login.cfg -s default -a herald The above command should display the herald setting like this: default herald="You are accessing a U.S. Government (USG) Information System (IS) that\n\ris provided for USG-authorized use only.\n\r\n\rBy using this IS (which includes any device attached to this IS), you\n\rconsent to the following conditions: \n\r\n\r-The USG routinely intercepts and monitors communications on this IS\n\rfor purposes including, but not limited to, penetration testing, COMSEC\n\rmonitoring, network operations and defense, personnel misconduct (PM),\n\rlaw enforcement (LE), and counterintelligence (CI) investigations. \n\r\n\r-At any time, the USG may inspect and seize data stored on this IS. \n\r\n\r-Communications using, or data stored on, this IS are not private, are\n\rsubject to routine monitoring, interception, and search, and may be\n\rdisclosed or used for any USG-authorized purpose. \n\r\n\r-This IS includes security measures (e.g., authentication and access\n\rcontrols) to protect USG interests--not for your personal benefit or\n\rprivacy. \n\r\n\r-Notwithstanding the above, using this IS does not constitute consent\n\rto PM, LE or CI investigative searching or monitoring of the content\n\rof privileged communications, or work product, related to personal\n\rrepresentation or services by attorneys, psychotherapists, or clergy,\n\rand their assistants. Such communications and work product are private\n\rand confidential. See User Agreement for details.\n\r\n\rlogin:" If the herald string is not set, or it does not contain the Standard Mandatory DoD Notice and Consent Banner listed above, this is a finding.

Discussion

While LDAP client's authentication type is ldap_auth (server-side authentication), the client sends password to the server in clear text for authentication. SSL must be used in this case.

Fix Text

Edit the "/etc/security/ldap/ldap.cfg" file to have the following line: useSSL:yes Configure the LDAP server and LDAP client to use the SSL according to AIX LDAP documentation. Restart the client daemon: # restart-secldapclntd

Check Content

Run the following command to check if "authtype" is "ldap_auth": # grep -iE "^authtype:[[:blank:]]*ldap_auth" /etc/security/ldap/ldap.cfg The above command should yield the following output: authtype:ldap_auth Run the following command to check if SSL is not used in the "/etc/security/ldap/ldap.cfg" file: # grep -iE "^useSSL:[[:blank:]]*yes" /etc/security/ldap/ldap.cfg The above command should yield the following output: useSSL:yes If the first command displays "authtype:ldap_auth" but the second command does not display "useSSL:yes", this is a finding.

Discussion

If cached authentication information is out-of-date, the validity of the authentication information may be questionable.

Fix Text

Edit the "/etc/security/ldap/ldap.cfg" file to set the following two keywords to have value of "900": usercachetimeout groupcachetimeout Restart LDAP client using command: # /usr/sbin/restart-secldapclntd

Check Content

If LDAP authentication is not required, this is Not Applicable. Verify the "/etc/security/ldap/ldap.cfg" file to see if the following two keywords have a value that is greater than "900" seconds: # grep -i usercachetimeout /etc/security/ldap/ldap.cfg usercachetimeout: 900 # grep -i groupcachetimeout /etc/security/ldap/ldap.cfg groupcachetimeout: 900 If any of the above keywords does not exist, is commented out, or any value of the above keywords are greater than "900", this is a finding.

Discussion

A plus (+) in system accounts files causes the system to lookup the specified entry using NIS. If the system is not using NIS, no such entries should exist.

Fix Text

Edit "/etc/passwd", "/etc/security/passwd", and/or "/etc/group" files and remove entries containing a plus (+).

Check Content

Check system configuration files for plus (+) entries using the following commands: # cat /etc/passwd | grep -v "^#" | grep "\+" # cat /etc/security/passwd | grep -v "^#" | grep "\+" # cat /etc/group | grep -v "^#" | grep "\+" If the "/etc/passwd", "/etc/security/passwd", and/or "/etc/group" files contain a plus (+) and do not define entries for NIS+ netgroups or LDAP netgroups, this is a finding.

Discussion

Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive and tape drive, when used for backups) within an operating system. This requirement addresses protection of user-generated data, as well as operating system-specific configuration data. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate, in accordance with the security category and/or classification of the information.

Fix Text

Install "clic.rte" fileset if it is not installed using command: # installp -aXYqg -d /dev/cd0 clic.rte Run the follow command to initialize and enable EFS on the system: # efsenable -a To create a new EFS-enabled JFS2 file system and mount the file system, using the following commands: # crfs -v jfs2 -g rootvg -m /fs2 -a size=100M -a efs=yes # mount /fs2 To enable EFS on a JFS2 file system (like, /fs3), run the following command: chfs -a efs=yes /fs3

Check Content

If the organization does not require to encrypt the data at rest this is Not Applicable. Check if the "clic.rte" fileset is installed: # lslpp -l |grep clic The above command should yield the following output: clic.rte.kernext 4.10.0.1 COMMITTED CryptoLite for C Kernel clic.rte.lib 4.10.0.1 COMMITTED CryptoLite for C Library clic.rte.kernext 4.10.0.1 COMMITTED CryptoLite for C Kernel If the "clic.rte" fileset is not installed, this is a finding. To check if a JFS2 file system (mounted as /fs2_mnt) is EFS-enabled, use the following command: # lsfs -q /fs2_mnt Name Nodename Mount Pt VFS Size Options Auto Accounting /dev/fslv00 -- /fs2_mnt jfs2 262144 -- no no (lv size: 262144, fs size: 262144, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v2, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no) If the above command shows "EFS: no", this is a finding.

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144

Fix Text

Edit /etc/ntp.conf Configure ntp server by adding the following line: server server_ipaddr Set maxpoll to <value> <=16 by adding the maxpoll <value>. Restart the ntp daemon. # stopsrc -s xntpd # startsrc -s xntpd

Check Content

Check if time synchronization application "ntpd" is running using the command: # lssrc -s xntpd Subsystem Group PID Status xntpd tcpip 4784536 active If "ntpd" is showing "inoperative", this is a finding. Check that "ntp" server is configured using command: # grep server /etc/ntp.conf server 10.110.20.10 If the command returns no output, this is a finding. Check the poll interval is less than 24 hours using command: # grep maxpoll /etc/ntp.conf maxpoll=16 If "maxpoll" is set to larger than "16" (2^16 seconds ~= 18hr), this is a finding.

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/exports" and set the "anon=-1" option for all exported file systems without it. Re-export the file systems using command: # exportfs -a

Check Content

Check if the "anon" option is set correctly for exported file systems. List exported file systems using command: # exportfs -v /home/doej rw,anon=-1,access=doej Note: Each of the exported file systems should include an entry for the "anon=" option set to "-1" or an equivalent (60001, 60002, 65534, or 65535). If an appropriate "anon=" setting is not present for an exported file system, this is a finding.

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/filesystems" 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 not using the "nosuid" option using command: # lsfs -v nfs Name Nodename Mount Pt VFS Size Options Auto Accounting /home/doej -- /mount/doej nfs 786432 -- yes no If the "mounted" file systems do not have the "nosuid option", this is a finding.

Discussion

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, operating systems need to provide users with the ability to manually invoke a session lock so users may secure their session should the need arise for them to temporarily vacate the immediate physical vicinity.

Fix Text

Install, or re-install, bos.rte.security fileset from the AIX DVD Volume 1 using the following command (assuming that the DVD device is /dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log bos.rte.security

Check Content

Check if the "lock" command exists by using the following command: # ls /usr/bin/lock The above command should display the following: /usr/bin/lock If the above command does not show that "/usr/bin/lock" exists, this is a finding. Check if the "xlock" command exists by using the following command: # ls /usr/bin/X11/xlock The above command should display the following: /usr/bin/X11/xlock If the above command does not show that "/usr/bin/xlock" exists, this is a finding.

Discussion

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. The operating system session lock event must include an obfuscation of the display screen so as to prevent other users from reading what was previously displayed. Publicly viewable images can include static or dynamic images, for example, patterns used with screen savers, photographic images, solid colors, a clock, a battery life indicator, or a blank screen, with the additional caveat that none of the images convey sensitive information.

Fix Text

From the command prompt, run the following script to set the default timeout parameters "dtsession*saverTimeout:" and "dtsession*lockTimeout:" as "15" minutes: # AIX7-00-001101_Fix.sh Note: This script is included in the STIG package.

Check Content

If CDE (X11) is not used on AIX, this is Not Applicable. Ensure that the screen saver and session timeout are not disabled. From the command prompt, run the following script: # AIX7-00-001101_Check.sh Note: This script is included in the STIG package. The above script should yield the following output: Checking config file /etc/dt/config/C/sys.resources... Missing config file /etc/dt/config/C/sys.resources Checking config file /etc/dt/config/POSIX/sys.resources... dtsession*saverTimeout: 15 dtsession*lockTimeout: 30 Checking config file /etc/dt/config/en_US/sys.resources... dtsession*saverTimeout: 15 dtsession*lockTimeout: 25 If the result of the script shows any config file missing, or any of the "dtsession*saverTimeout" or "dtsession*lockTimeout" values is greater than "15", this is a finding.

Discussion

If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. Some maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.

Fix Text

Disable telnet by executing the following command: # stopsrc -t telnet

Check Content

From the command prompt, execute the following to check if "telnetd" is enabled. # lssrc -t telnet | grep active If the above command returns output, this is a finding.

Discussion

If LDAP authentication is used, SSL must be used between LDAP clients and the LDAP servers to protect the integrity of remote access sessions.

Fix Text

Configure the LDAP client on AIX to use the SSL. Edit /etc/security/ldap/ldap.cfg to have the following line: useSSL:yes Restart the client daemon: # secldapclntd.

Check Content

Run the following command to check if ldap_auth is used: # grep -iE "^authtype:[[:blank:]]*ldap_auth" /etc/security/ldap/ldap.cfg If the command has no output, this is Not Applicable. Run the following command to check if SSL is used: # grep -iE "^useSSL:[[:blank:]]*yes" /etc/security/ldap/ldap.cfg useSSL:yes If the command has no output, this is a finding.

Discussion

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI-certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates.

Fix Text

Note: Depending on which version of GSKit is installed on AIX, the GSK commands that are used to manage the Key Database (KDB) have different names. The possible GSK commands are: gsk8capicmd (used below), gsk8capicmd_64 and gsk7cmd. Create a key database with DoD PKI or DoD-approved certificate using one of the following commands: # gsk8capicmd -keydb -create -db <KDB_FILE> -pw <KDB_PASSWORD> -type cms -stash Edit "/etc/security/ldap/ldap.cfg" and add or edit the "ldapsslkeyf" setting to reference a KDB file containing a client certificate issued by DoD PKI or a DoD-approved external PKI. Install a certificate signed by a DoD PKI or a DoD-approved external PKI using the following command: # gsk8capicmd -cert -add -db <KDB_FILE> -pw <KDB_PASSWORD> -file <CERT_FILE> -label <CERT_LABEL> Remove un-needed CA certificates using one of the following commands: # gsk8capicmd -cert -delete -db <KDB_FILE> -pw <KDB_PASSWORD> -label <CERT_LABEL> Restart LDAP client using command: # /usr/sbin/restart-secldapclntd

Check Content

Note: Depending on which version of GSKit is installed on AIX, the GSK commands that are used to manage the Key Database (KDB) have different names. The possible GSK commands are: gsk8capicmd (used below), gsk8capicmd_64 and gsk7cmd. Check if the system is using LDAP authentication: # grep LDAP /etc/security/user If no lines are returned, this requirement is not applicable. Check if the useSSL option is enabled: # grep '^useSSL' /etc/security/ldap/ldap.cfg useSSL:yes If "yes" is not the returned value, this is a finding. Verify a certificate is used for client authentication to the server: # grep -i '^ldapsslkeyf' /etc/security/ldap/ldap.cfg ldapsslkeyf:/tmp/key.kdb If no line is found, this is a finding. Identify the Key Database (KDB), and its password, by asking the ISSO/SA). If no Key Database exists on the system, this is a finding. List the certificate issuer with IBM GSK: # gsk8capicmd -cert -list CA -db <KDB_FILE> -pw <KDB_PASSWORD> Make note of the client Key Label: # gsk8capicmd -cert -details -showOID -db <KDB_FILE> -pw <KDB_PASSWORD> -label <Key Label> If the certificate is not issued by DoD PKI or a DoD-approved external PKI, this is a finding. The IBM GSK Database should only have certificates for the client system and for the LDAP server. If more certificates are in the key database than the LDAP server and the client, this is a finding.

Discussion

FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general purpose computing system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. AIX must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. OpenSSL FIPS object module is a cryptographic module that is designed to meet the requirements for FIPS 140-2 validation by CMVP and is compatible with OpenSSL libraries. The 2.0.13 FIPS object module version has been FIPS validated and certified by CMVP for multiple AIX versions on Power 7 and Power 8 platforms under certificate #2398. IBM has released a FIPS capable OpenSSL (Fileset VRMF: 20.13.102.1000), which is OpenSSL 1.0.2j version with 2.0.13 object module. The fileset is available in Web Download Pack. Satisfies: SRG-OS-000120-GPOS-00061, SRG-OS-000478-GPOS-00223, SRG-OS-000396-GPOS-00176

Fix Text

Use the following command to uninstall the old version of OpenSSL that is not FIPS 140-2 certified, then install OpenSSL VRMF 20.13.102.1000: # smitty install

Check Content

Run the following command to determine the version of OpenSSL that is installed: # lslpp -l | grep -i openssl openssl.base 20.13.704.1776 COMMITTED Open Secure Socket Layer If the OpenSSL version is older than "20.13.102.1000", this is a finding.

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Fix Text

From the command prompt, run the following command to set "minupperalpha=1" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a minupperalpha=1 For each user who has "minupperalpha=0", set its "minupperalpha" to "1" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a minupperalpha=1

Check Content

From the command prompt, run the following command to check the system default "minupperalpha" attribute value: # lssec -f /etc/security/user -s default -a minupperalpha The above command should yield the following output: default minupperalpha=1 If the default "minupperalpha" value is not set, or its value is less than "1", this is a finding. From the command prompt, run the following command to check "minupperalpha" attribute value for all accounts: # lsuser -a minupperalpha ALL The above command should yield the following output: root minupperalpha=2 user2 minupperalpha=2 user3 minupperalpha=1 If any user's "minupperalpha" value is less than "1", this is a finding.

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Fix Text

From the command prompt, run the following command to set "minloweralpha=1" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a minloweralpha=1 For each user who has "minloweralpha=0" set its "minloweralpha" to "1" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a minloweralpha=1

Check Content

From the command prompt, run the following command to check the system default "minloweralpha" attribute value: # lssec -f /etc/security/user -s default -a minloweralpha default minloweralpha=1 If the "default minloweralpha" value is not set, or its value is less than "1", this is a finding. From the command prompt, run the following command to check "minloweralpha" attribute value for all accounts: # lsuser -a minloweralpha ALL root minloweralpha=1 user2 minloweralpha=2 user3 minloweralpha=1 If any user's "minloweralpha" value is less than "1", this is a finding.

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Fix Text

From the command prompt, run the following command to set "mindigit=1" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a mindigit=1 For each user who has "mindigit=0" set its "mindigit" to "1" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a mindigit=1

Check Content

From the command prompt, run the following command to check the system default "mindigit" attribute value: # lssec -f /etc/security/user -s default -a mindigit default mindigit=1 If the default "mindigit" value is not set, or its value is less than "1", this is a finding. From the command prompt, run the following command to check mindigit attribute value for all accounts: # lsuser -a mindigit ALL root mindigit=1 user2 mindigit=2 If any user's "mindigit" value is less than "1", this is a finding.

Discussion

If the operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. If the password length is an odd number then number of changed characters must be rounded up. For example, a password length of 15 characters must require the change of at least 8 characters.

Fix Text

From the command prompt, run the following command to set "mindiff=8" (assume that the password is at least 15-character long) for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a mindiff=8 For each user who has "mindiff" value less than "8", set its "mindiff" value to "8" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a mindiff=8

Check Content

From the command prompt, run the following command to check the system default "mindiff" attribute value: # lssec -f /etc/security/user -s default -a mindiff default mindiff=8 If the default "mindiff" value is not set, or its value is less than "8", this is a finding. From the command prompt, run the following command to check "mindiff" attribute value for all accounts: # lsuser -a mindiff ALL root mindiff=9 user1 mindiff=8 user2 mindiff=8 user3 mindiff=10 If any user's "mindiff" value is less than "8", this is a finding.

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.

Fix Text

If OpenSSH server is not installed, install it from the from AIX DVD Volume 1 using the following command (assuming that the DVD device is /dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log openssh.base.server Start SSH server if it is not started: # startsrc -s sshd Enable SSH on the system and use it for all remote connections used to attain root access. Disable direct root remote login: # chsec -f /etc/security/user -s root -a rlogin=false

Check Content

Determine if root has logged in over an unencrypted network connection: # last | grep "root " | egrep -v "reboot|console" | more root pts/1 10.74.17.76 Jul 4 16:44 - 17:39 (00:54) Next, determine if the SSH daemon is running: # ps -ef |grep sshd root 3670408 6029762 0 Jan 24 - 0:00 /usr/sbin/sshd If root has logged in over the network and SSHD is not running, this is a finding.

Discussion

Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Fix Text

From the command prompt, run the following command to set "minage=1" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a minage=1 For each user who has "minage=0" set its "minage" to "1" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a minage=1

Check Content

From the command prompt, run the following command to check the system default "minage" attribute value: # lssec -f /etc/security/user -s default -a minage default minage=1 If the default "minage" value is not set, or its value is less than "1", this is a finding. From the command prompt, run the following command to check "minage" attribute value for all accounts: # lsuser -a minage ALL root minage=1 user1 minage=1 user2 minage=2 If any user's "minage" value is less than "1", this is a finding.

Discussion

Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.

Fix Text

From the command prompt, run the following command to set "maxage=8" (56 days) for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a maxage=8 For each user who has "maxage" value great than "8", set its "maxage" to "8" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a maxage=8

Check Content

From the command prompt, run the following command to check the system default "maxage" attribute value: # lssec -f /etc/security/user -s default -a maxage default maxage=8 If the default "maxage" value is not set, or its value is great than "8", or its value is set to "0", this is a finding. From the command prompt, run the following command to check "maxage" attribute value for all accounts: # lsuser -a maxage ALL root maxage=8 user1 maxage=8 user2 maxage=8 If any user does not have "maxage" set, or its "maxage" value is greater than "8", or its value is set to "0", this is a finding.

Discussion

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.

Fix Text

From the command prompt, run the following command to set "histsize=5" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a histsize=5 For each user who has "histsize" value less than "5", set its "histsize" to "5" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a histsize=5

Check Content

From the command prompt, run the following command to check the system default "histsize" attribute value: # lssec -f /etc/security/user -s default -a histsize default histsize=5 If the default "histsize" value is not set, or its value is less than "5", this is a finding. From the command prompt, run the following command to check "histsize" attribute value for all accounts: # lsuser -a histsize ALL root histsize=5 user1 histsize=5 user2 histsize=5 user3 histsize=6 If any user does not have "histsize" set, or its "histsize" value is less than "5", this is a finding.

Discussion

The default legacy password hashing algorithm, crypt(), uses only the first 8 characters from the password string, meaning the user's password is truncated to eight characters. If the password is shorter than 8 characters, it is padded with zero bits on the right. The crypt() is a modified DES algorithm that is vulnerable to brute force password guessing attacks and also to cracking the DES-hashing algorithm by using techniques such as pre-computation. With the Loadable Password Algorithm (LPA) framework release, AIX implemented a set of LPAs using MD5, SHA2, and Blowfish algorithms. These IBM proprietary password algorithms support a password longer than 8 characters and Unicode characters in passwords.

Fix Text

From the command prompt, run the following command to set system wide password algorithm to "ssha512" so that it supports passwords longer than 8-character: # chsec -f /etc/security/login.cfg -s usw -a pwd_algorithm=ssha512 For each users who have hashed passwords in "/etc/security/passwd" file that does not start with "{ssha512}", run passwd commands to reset the users' passwords so that they have to change their passwords in the next login: # passwd [user_name]

Check Content

From the command prompt, run the following command to check system wide password algorithm: # lssec -f /etc/security/login.cfg -s usw -a pwd_algorithm usw pwd_algorithm=ssha512 If the "pwd_algorithm" is not set to "ssha512", or "ssha256", this is a finding.

Discussion

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Fix Text

From the command prompt, run the following command to set "minlen=15" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a minlen=15 For each user who has "minlen" value less than "15", set its "minlen" to "15" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a minlen=15

Check Content

From the command prompt, run the following command to check the system default "minlen" attribute value: # lssec -f /etc/security/user -s default -a minlen default minlen=15 If the default "minlen" value is not set, or its value is less than "15", this is a finding. From the command prompt, run the following command to check "minlen" attribute value for all accounts: # lsuser -a minlen ALL root minlen=15 user1 minlen=20 user2 minlen=15 user3 minlen=15 If any users have "minlen" value less than "15", this is a finding.

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.

Fix Text

From the command prompt, run the following command to set "minspecialchar=1" for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a minspecialchar=1 Run the following command to re-check "minspecialchar" values for all users: # lsuser -a minspecialchar ALL For each user who has "minspecialchar=0", set its "minspecialchar" to "1" by running the following command from command prompt: # chsec -f /etc/security/user -s [user_name] -a minspecialchar=1

Check Content

Run the following command to check the system default value for "minspecialchar" attribute: # lssec -f /etc/security/user -s default -a minspecialchar The above command should yield the following output: default minspecialchar=0 If the default value is "0", or the default value is empty, this is a finding. From the command prompt, run the following command to check "minspecialchar" attribute value for all accounts: # lsuser -a minspecialchar ALL The above command should yield the following output: root minspecialchar=1 user1 minspecialchar=1 user2 minspecialchar=2 user3 minspecialchar=1 If any account has "minspecialchar=0", or the "minspecialchar" value is not set, this is a finding.

Discussion

Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial login. Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.

Fix Text

Use the following command to force a temporary user (<tmp_user>) to change password at next login: # chsec -f /etc/security/passwd -s <tmp_user> -a "flags=ADMCHG"

Check Content

To force a temporary user to renew their password at next login, admins can set the "flags" attribute of the user to contain "ADMCHG" flag. To check the "flags" attribute for a temporary user (<tmp_user>), using the following command: # lsuser -a flags <tmp_user> If the above command displays a "no" value for the "flags" attribute, or the value of the attribute does not contain "ADMCHG", this is a finding.

Discussion

If the operating system allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.

Fix Text

From the command prompt, run the following command to set "dictionlist" attribute for the default stanza in "/etc/security/user": # chsec -f /etc/security/user -s default -a dictionlist="/etc/security/ice/dictionary/English" From the command prompt, run the following command to set "dictionlist" attribute for users who have an empty "dictionlist" attribute: # chsec -f /etc/security/user -s [user_name] -a dictionlist="/etc/security/ice/dictionary/English"

Check Content

From the command prompt, run the following command to check if the default "dictionlist" attribute is set: # lssec -f /etc/security/user -s default -a dictionlist The above command should yield the following output: dictionlist="/etc/security/ice/dictionary/English" If the above command shows an empty string for default "dictionlist" attribute, this is a finding. From the command prompt, run the following command to check if "dictionlist" attribute is set for all users: # lsuser -a dictionlist ALL The above command should yield the following output: root dictionlist=/etc/security/ice/dictionary/English daemon dictionlist=/etc/security/ice/dictionary/English bin dictionlist=/etc/security/ice/dictionary/English sys dictionlist=/etc/security/ice/dictionary/English If any user's "dictionlist" attribute is empty, this is a finding.

Discussion

Systems must employ cryptographic hashes for passwords using the SHA-2 family of algorithms or FIPS 140-2 approved successors. The use of unapproved algorithms may result in weak password hashes that are more vulnerable to compromise.

Fix Text

Set the system wide password algorithm to "ssha256" or "ssha512" by running the following command: # chsec -f /etc/security/login.cfg -s usw -a pwd_algorithm=ssha512 Change the passwords for all accounts using non-compliant password hashes by running the following command: $ passwd [user_name]

Check Content

Verify that the system wide password algorithm is set to {ssha256} or {ssha512} by running the following command: # lssec -f /etc/security/login.cfg -s usw -a pwd_algorithm usw pwd_algorithm=ssha512 If the "pwd_algorithm" is not set to "ssha256" or "ssha512", this is a finding. Verify no password hashes in /etc/passwd by running the following command: # cat /etc/passwd | cut -f2,2 -d":" ! ! ! ! * * * * If there are password hashes present, this is a finding. Verify all password hashes in "/etc/security/passwd" begin with {ssha256} or {ssha512} by running commands: # cat /etc/security/passwd | grep password password = {ssha512}06$e58YOawe/7UhChqh$hZEWlP4040jarX1NeOujmcxd.7qerUvjW9lM9djJsDITtdjFvVpLX.r04xieOWrbH0qb0SJJ98a0tmgZBzPP.. password = {ssha512}06$Y6ztvMxKGdITxPex$B81/GDTEPt0xwp.BX1VhY9mAPaWHXdNoLI9D0T6dBExgo6r87X0etnfjxWODT73.udrbAY.F4HzaBR68lN5/.. password = {ssha512}06$iIXQQqs.mdGpC9Wu$cXSajikWYKAUacbF50FNlFgYYSgTklGf4uhXb1J/GyBGF5j5aWa4YG5Ah2uaAHv/Jmbmx.7yBm8iXz9Pz1LM.. password = {ssha512}06$3Sw24rPVdqDFFCIl$d1dZs7GYmTXnD9i270SxozIBxN0pqq/bNn0YbyKeDq0o6Y.j9qfkeH373DwkHBWgrifNcgj/K0pVyzjMg6QN.. If any password hashes are present not beginning with {ssha256} or {ssha512}, this is a finding.

Discussion

Use default SNMP password increases the chance of security vulnerability on SNMP service.

Fix Text

Edit "/etc/snmpd.conf" config file to remove or change all the default passwords that are used in the file. Restart snmpd: # stopsrc -s snmpd # startsrc -s snmpd

Check Content

Inspect "/etc/snmpd.conf" to find all the passwords that are used in the config file: # grep -v "^#" /etc/snmpd.conf | grep -E "public|private|password" If any results are returned, default passwords are being used and this is a finding.

Discussion

Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.

Fix Text

Use the "chsec" command to set "maxrepeats" to "3" for the default stanza: # chsec -f /etc/security/user -s default -a maxrepeats=3 Use the "chsec" command to set "maxrepeats" to "3" for all the users who have "maxrepeats" values that are greater than "3", or its value is set to "0": # chuser maxrepeats=3 [user_name]

Check Content

Check system default for "maxrepeats" attribute: # lssec -f /etc/security/user -s default -a maxrepeats default maxrepeats=3 If the default "maxrepeats" is greater than "3", or its value is not set, or its value is set to "0", this is a finding. Check the "maxrepeats" setting for all users using: # lsuser -a maxrepeats ALL The above command should yield the following output: root maxrepeats=3 daemon maxrepeats=3 bin maxrepeats=3 sys maxrepeats=3 If the "maxrepeats" setting for any user is greater than "3", or its value is set to "0", this is a finding.

Discussion

Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Operating system functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Fix Text

From the command prompt, run the following command to set "rlogin=false" for all users (user_name) who are not authorized to login remotely: # chsec -f /etc/security/user -s [user_name] -a rlogin=false

Check Content

For users who are authorized to remote login through SSH, etc., this is Not Applicable. Ask ISSO/SA to obtain a list of users who are not authorized to remotely log in to AIX system. From the command prompt, run the following command to check if remote login is disabled for all individual users who are not authorized to remotely login to AIX: # lsuser -a rlogin ALL root rlogin=true daemon rlogin=true bin rlogin=true sys rlogin=true adm rlogin=true If "rlogin=true" for any user who should not login remotely, this is a finding.

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 not containing approved setuid files, increases the opportunity for unprivileged users to attain unauthorized administrative access.

Fix Text

For each NFS file systems that does not contain approved "setuid" or "setgid" files, add the "nosuid" option, along with other mount options, to the "options" field in "/etc/filesystems" using the following command: # chfs -a options=ro,bg,hard,intr,nosuid,sec=sys <NFS_mount_point> Note that the other mount options (other than the nosuid options) may be different among NFS mounts.

Check Content

Obtain a list of NFS file systems that contain approved "setuid" or "setgid" files from the ISSO/ISSM. Check the "nosuid" mount option is used on all NFS file systems that do not contain approved "setuid" or "setgid" files: # mount | grep -E "options|nfs|---" node mounted mounted over vfs date options -------- --------------- --------------- ------ ------------ --------------- ausgsa.ibm.com /gsa/ausgsa/projects/a/aix/71 /mnt_1 nfs3 Nov 05 14:11 ro,bg,hard,intr,nosuid,sec=sys ausgsa.ibm.com /gsa/ausgsa/projects/a/aix/72 /mnt_2 nfs3 Nov 05 14:12 ro,bg,hard,intr,sec=sys If the NFS mounts do not show the "nosuid" setting in their "options" fields, along with other mount options, this is a finding.

Discussion

The nodev (or equivalent) mount option causes the system to not handle device files as system devices. This option must be used for mounting any file system not containing approved device files. Device files can provide direct access to system hardware and can compromise security if not protected.

Fix Text

Edit "/etc/filesystems" and add the "options = nodev" to all entries for remote or removable media file systems, and file systems containing no approved device files.

Check Content

Identify any file system mounted from removable media, network shares, or file systems not containing any approved device files: # cat /etc/filesystems /: dev = /dev/hd4 vfs = jfs2 log = /dev/hd8 mount = automatic check = false type = bootfs vol = root free = true /home: dev = /dev/hd1 vol = "/home" mount = true check = true free = false vfs = jfs2 log = /dev/hd8 10.17.76.74:/opt/nfs /home/doejohn vfs = nfs log = /dev/hd8 mount = true options = nodev account = false If any file system mounted from removable media, network shares, or file systems not containing any approved device files is not using the "nodev" option, this is a finding.

Discussion

Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in AIX audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016

Fix Text

Reset the audit system with the following command: # /usr/sbin/audit shutdown Start the audit system with the following command: # /usr/sbin/audit start

Check Content

Check if audit is turned on by running the following command: # audit query | grep -i auditing auditing on The command should yield the following output: auditing on If the command shows "auditing off", this is a finding. The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail Note: The default log file is "/audit/trail". Use the following command to display the audit events: # /usr/sbin/auditpr -i <audit log file> -helRtcp event login status time command process --------------- -------- ----------- ------------------------ ------------------------------- -------- PROC_Delete root OK Wed Oct 31 23:01:37 2018 audit 9437656 FILE_Close root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Open root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Read root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Close root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 PROC_Create root OK Wed Oct 31 23:01:44 2018 ksh 12976466 FILE_Close root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Open root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Read root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Close root OK Wed Oct 31 23:01:44 2018 ksh 9437658 PROC_Execute root OK Wed Oct 31 23:01:44 2018 ls 9437658 FILE_Open root OK Wed Oct 31 23:01:44 2018 ls 9437658 If event type is not displayed, this is a finding. More information on the command options used above: -e the audit event. -l the login name of the user. -R the audit status. -t the time the record was written. -c the command name. -p the process ID.

Discussion

Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as operating system components, modules, device identifiers, node names, file names, and functionality. Associating information about where the event occurred within AIX provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.

Fix Text

Reset the audit system with the following command: # /usr/sbin/audit shutdown Start the audit system with the following command: # /usr/sbin/audit start

Check Content

Verify audit event detailed information is displayed: The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail Note: The default log file is /audit/trail. Use the following command to display the audit events: # /usr/sbin/auditpr -i <audit log file> -v event login status time command wpar name --------------- -------- ----------- ------------------------ ------------------ ------------- ------------------------- FS_Chdir root OK Sat Aug 26 19:31:37 2017 ps Global change current directory to: /dev FS_Chdir root OK Sat Aug 26 19:31:47 2017 ps Global change current directory to: /dev FS_Chdir root OK Sat Aug 26 19:31:57 2017 ps Global change current directory to: /dev FS_Chdir root OK Sat Aug 26 19:32:07 2017 ps Global change current directory to: /dev FS_Chdir root OK Sat Aug 26 19:32:17 2017 ps Global change current directory to: /dev If event detailed information is not displayed, this is a finding. More information on the command options used above: - v detailed information for the event

Discussion

Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. In addition to logging where events occur within AIX, AIX must also generate audit records that identify sources of events. Sources of operating system events include, but are not limited to, processes and services. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know the source of the event. Satisfies: SRG-OS-000040-GPOS-00018, SRG-OS-000255-GPOS-00096

Fix Text

Reset the audit system with the following command: # /usr/sbin/audit shutdown Start the audit system with the following command: # /usr/sbin/audit start

Check Content

Verify the audit event "process id" is displayed: The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail Note: The default log file is /audit/trail. Use the following command to display the audit events: # /usr/sbin/auditpr -i <audit log file> -helRtcp event login status time command process --------------- -------- ----------- ------------------------ ------------------ ------------- -------- PROC_Delete root OK Wed Oct 31 23:01:37 2018 audit 9437656 FILE_Close root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Open root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Read root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Close root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 PROC_Create root OK Wed Oct 31 23:01:44 2018 ksh 12976466 FILE_Close root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Open root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Read root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Close root OK Wed Oct 31 23:01:44 2018 ksh 9437658 PROC_Execute root OK Wed Oct 31 23:01:44 2018 ls 9437658 FILE_Open root OK Wed Oct 31 23:01:44 2018 ls 9437658 If user id or process id is not displayed, this is a finding. More information on the command options used above: -e the audit event. -l the login name of the user. -R the audit status. -t the time the record was written. -c the command name. -p the process ID.

Discussion

Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Fix Text

Reset the audit system with the following command: # /usr/sbin/audit shutdown Start the audit system with the following command: # /usr/sbin/audit start

Check Content

Verify the audit event "status" is displayed: The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail Note: The default log file is /audit/trail. Use the following command to display the audit events: # /usr/sbin/auditpr -i <audit log file> -helRtcp event login status time command process --------------- -------- ----------- ------------------------ ------------------ ------------- -------- PROC_Delete root OK Wed Oct 31 23:01:37 2018 audit 9437656 FILE_Close root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Open root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Read root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 FILE_Close root OK Wed Oct 31 23:01:37 2018 auditbin 12255562 PROC_Create root OK Wed Oct 31 23:01:44 2018 ksh 12976466 FILE_Close root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Open root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Read root OK Wed Oct 31 23:01:44 2018 ksh 9437658 FILE_Close root OK Wed Oct 31 23:01:44 2018 ksh 9437658 PROC_Execute root OK Wed Oct 31 23:01:44 2018 ls 9437658 FILE_Open root OK Wed Oct 31 23:01:44 2018 ls 9437658 If audit status is not displayed, this is a finding. More information on the command options used above: -e the audit event. -l the login name of the user. -R the audit status. -t the time the record was written. -c the command name. -p the process ID.

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Fix Text

Reset the audit system with the following command: # /usr/sbin/audit shutdown Start the audit system with the following command: # /usr/sbin/audit start

Check Content

Verify the audit daemon is configured for full-text recording of privileged commands: The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail Note: The default log file is /audit/trail. Use the following command to display the audit events: # /usr/sbin/auditpr -i <audit log file> -v event login status time command wpar name --------------- -------- ----------- ------------------------ ------------------ ------------- ------------------------- S_PASSWD_READ root OK Sat Aug 26 19:35:00 2017 cron Global audit object read event detected /etc/security/passwd S_PASSWD_READ root OK Sat Aug 26 19:35:00 2017 cron Global audit object read event detected /etc/security/passwd CRON_Start root OK Sat Aug 26 19:35:00 2017 cron Global event = start cron job cmd = /usr/sbin/dumpctrl -k >/dev/null 2>/dev/nul l time = Sat Aug 26 19:35:00 2017 FS_Chdir root OK Sat Aug 26 19:35:00 2017 cron Global change current directory to: / If the full-text recording of privileged command is not displayed, this is a finding. More information on the command options used above: - v detailed information for the event

Discussion

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Fix Text

Ensure the "/etc/security/audit/config" file contains the following line: freepsace = <value> where <value> is greater than 25%* filesystem capacity Reset the audit system with the following command: # /usr/sbin/audit shutdown Start the audit system with the following command: # /usr/sbin/audit start

Check Content

Check if "freespace" is configured for the audit subsystem: # grep -E freespace* /etc/security/audit/config freespace = 65536 If the above command returns empty, or if the value is less than 25% of the filesystem size, this is a finding.

Discussion

The ability to specify the event criteria that are of interest provides the individuals reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded. Events of interest can be identified by the content of specific audit record fields, including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required, for example, locations selectable by general networking location (e.g., by network or subnetwork) or selectable by specific information system component. The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. The ability to perform on-demand audit review and analysis, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports, as needed, to better handle larger-scale or more complex security incidents. If the audit reduction capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack, or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports. This requires operating systems to provide the capability to customize audit record reports based on all available criteria. Satisfies: SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137

Fix Text

Re-install the "bos.rte.security" fileset from the base media. Use "installp" command (assume cd is mounted). # installp -aXYqg -d /dev/cd0 bos.rte.security

Check Content

The application file "/usr/sbin/auditselect" provides the audit filtering function. Check if it exists: # ls -l /usr/sbin/auditselect -r-sr-x--- 1 root audit 36240 Jul 4 1776 /usr/sbin/auditselect If the "/usr/sbin/auditselect" file does not exist, this is a finding

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix Text

Set the owner of the audit log file to "root". # chown root <auditlog file>

Check Content

Check the log files under the audit logging directory have correct ownership. The default log file is /audit/trail. The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail # ls -l <auditlog dir> total 240 -rw-rw---- 1 root system 0 Feb 23 08:44 bin1 -rw-rw---- 1 root system 0 Feb 23 08:44 bin2 -rw-r----- 1 root system 116273 Feb 23 08:44 trail If any file's ownership is not "root", this is a finding.

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix Text

Set the group of the audit log file to "system". # chgrp system <auditlog file>

Check Content

Check the log files under the audit logging directory have correct group ownership. The default log file is /audit/trail. The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail # ls -l <auditlog dir> total 240 -rw-rw---- 1 root system 0 Feb 23 08:44 bin1 -rw-rw---- 1 root system 0 Feb 23 08:44 bin2 -rw-r----- 1 root system 116273 Feb 23 08:44 trail If any file's group ownership is not "system", this is a finding.

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix Text

Set the permission of the audit log file to "660". # chmod 660 <auditlog file>

Check Content

Check the log files under the audit logging directory have correct permissions. The default log file is /audit/trail. The log file can be set by the "trail" variable in /etc/security/audit/config. # grep trail /etc/security/audit/config trail = /audit/trail # ls -l <auditlog dir> total 240 -rw-rw---- 1 root system 0 Feb 23 08:44 bin1 -rw-rw---- 1 root system 0 Feb 23 08:44 bin2 -rw-r----- 1 root system 116273 Feb 23 08:44 trail If any file has a mode more permissive than "660", this is a finding.

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoD has defined the list of events for which AIX will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful login attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logins from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions. Satisfies: SRG-OS-000062-GPOS-00031, SRG-OS-000004-GPOS-00004, SRG-OS-000051-GPOS-00024, SRG-OS-000064-GPOS-00033, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000277-GPOS-00107, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000327-GPOS-00127, SRG-OS-000327-GPOS-00127, SRG-OS-000364-GPOS-00151, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000472-GPOS-00217, SRG-OS-000473-GPOS-00218, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000476-GPOS-00221, SRG-OS-000477-GPOS-00222

Fix Text

Use the "stig_audit_config.txt" file to configure the AIX audit process. Edit the /etc/security/audit/objects file and add or update the following lines to the listed values: /etc/security/environ: w = "S_ENVIRON_WRITE" /etc/security/group: w = "S_GROUP_WRITE" /etc/group: w = "S_GROUP_WRITE" /etc/security/limits: w = "S_LIMITS_WRITE" /etc/security/login.cfg: w = "S_LOGIN_WRITE" /etc/security/passwd: r = "S_PASSWD_READ" w = "S_PASSWD_WRITE" /etc/security/user: w = "S_USER_WRITE" /etc/security/audit/config: w = "AUD_CONFIG_WR" Restart the audit process: # /usr/sbin/audit shutdown # /usr/sbin/audit start Note: There are multiple default "classes" defined in the "/etc/security/audit/config" file. The only audit class that is required by this document is the "stig_aud_class". All other defined classes can be removed at the discretion of the organization.

Check Content

Ensure that auditing is properly configured. Run the "stig_audit_check.sh" script. If any results are returned from the script, this is a finding. Verify that the file "/etc/security/audit/objects" includes the following objects: /etc/security/environ: w = "S_ENVIRON_WRITE" /etc/security/group: w = "S_GROUP_WRITE" /etc/group: w = "S_GROUP_WRITE" /etc/security/limits: w = "S_LIMITS_WRITE" /etc/security/login.cfg: w = "S_LOGIN_WRITE" /etc/security/passwd: r = "S_PASSWD_READ" w = "S_PASSWD_WRITE" /etc/security/user: w = "S_USER_WRITE" /etc/security/audit/config: w = "AUD_CONFIG_WR" If any of the objects listed above are missing from "/etc/security/audit/objects", this is a finding.

Discussion

If auditing is enabled late in the start-up process, the actions of some start-up processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created.

Fix Text

To start auditing at system startup, add the following line to the /etc/rc file, just prior to the line reading dspmsg rc.cat 5 'Multi-user initialization completed': /usr/sbin/audit start Symmetrically add the '/usr/sbin/audit shutdown' command to /etc/rc.shutdown.

Check Content

Check if /etc/rc contains the following line: /usr/sbin/audit start # grep "audit start" /etc/rc /usr/sbin/audit start If a result is not returned, this is a finding.

Discussion

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Fix Text

For each audit tool in: /usr/sbin/audit /usr/sbin/auditbin /usr/sbin/auditcat /usr/sbin/auditconv /usr/sbin/auditmerge /usr/sbin/auditpr /usr/sbin/auditselect /usr/sbin/auditstream Set the owner to "root". # chown root <audit tool> For /usr/sbin/auditldap Set the owner to "root". # chown root /usr/sbin/auditldap

Check Content

Check the following audit tools are owned by "root": /usr/sbin/audit /usr/sbin/auditbin /usr/sbin/auditcat /usr/sbin/auditconv /usr/sbin/auditmerge /usr/sbin/auditpr /usr/sbin/auditselect /usr/sbin/auditstream /usr/sbin/auditldap # ls -l /usr/sbin/audit*|grep -v ldap -r-sr-x--- 1 root audit 64926 Mar 30 2016 /usr/sbin/audit -r-sr-x--- 1 root audit 41240 Mar 30 2016 /usr/sbin/auditbin -r-sr-x--- 1 root audit 40700 Mar 30 2016 /usr/sbin/auditcat -r-sr-x--- 1 root audit 13072 Mar 30 2016 /usr/sbin/auditconv -r-sr-x--- 1 root audit 11328 Mar 30 2016 /usr/sbin/auditmerge -r-sr-x--- 1 root audit 53466 Mar 30 2016 /usr/sbin/auditpr -r-sr-x--- 1 root audit 33128 Mar 30 2016 /usr/sbin/auditselect -r-sr-x--- 1 root audit 29952 Mar 30 2016 /usr/sbin/auditstream -r-x------ 1 root security 12204 Mar 30 2016 /usr/sbin/auditldap If any above file's ownership is not "root", this is a finding.

Discussion

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Fix Text

For each audit tool in: /usr/sbin/audit /usr/sbin/auditbin /usr/sbin/auditcat /usr/sbin/auditconv /usr/sbin/auditmerge /usr/sbin/auditpr /usr/sbin/auditselect /usr/sbin/auditstream Set the group to "audit". # chgrp audit <audit tool> For /usr/sbin/auditldap: Set the group to "security". # chgrp security /usr/sbin/auditldap

Check Content

Check the following audit tools are group-owned by "audit": /usr/sbin/audit /usr/sbin/auditbin /usr/sbin/auditcat /usr/sbin/auditconv /usr/sbin/auditmerge /usr/sbin/auditpr /usr/sbin/auditselect /usr/sbin/auditstream # ls -l /usr/sbin/audit*|grep -v ldap -r-sr-x--- 1 root audit 64926 Mar 30 2016 /usr/sbin/audit -r-sr-x--- 1 root audit 41240 Mar 30 2016 /usr/sbin/auditbin -r-sr-x--- 1 root audit 40700 Mar 30 2016 /usr/sbin/auditcat -r-sr-x--- 1 root audit 13072 Mar 30 2016 /usr/sbin/auditconv -r-sr-x--- 1 root audit 11328 Mar 30 2016 /usr/sbin/auditmerge -r-sr-x--- 1 root audit 53466 Mar 30 2016 /usr/sbin/auditpr -r-sr-x--- 1 root audit 33128 Mar 30 2016 /usr/sbin/auditselect -r-sr-x--- 1 root audit 29952 Mar 30 2016 /usr/sbin/auditstream If any above file's are not group-owned by "audit", this is a finding. Verify that "/usr/sbin/auditldap" group-owned by "security": # ls -l /usr/sbin/auditldap -r-x------ 1 root security 12204 Mar 30 2016 /usr/sbin/auditldap If the group-owner of "/usr/sbin/auditldap" is not "security", this is a finding.

Discussion

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Fix Text

For each audit tool in: /usr/sbin/audit /usr/sbin/auditbin /usr/sbin/auditcat /usr/sbin/auditconv /usr/sbin/auditmerge /usr/sbin/auditpr /usr/sbin/auditselect /usr/sbin/auditstream Set the permission to "4550". # chmod 4550 <audit tool> For /usr/sbin/auditldap: Set the permission to "500". # chmod 500 /usr/sbin/auditldap

Check Content

Check the following audit tools are set to "4550" or less permissive: /usr/sbin/audit /usr/sbin/auditbin /usr/sbin/auditcat /usr/sbin/auditconv /usr/sbin/auditmerge /usr/sbin/auditpr /usr/sbin/auditselect /usr/sbin/auditstream # ls -l /usr/sbin/audit*|grep -v ldap -r-sr-x--- 1 root audit 64926 Mar 30 2016 /usr/sbin/audit -r-sr-x--- 1 root audit 41240 Mar 30 2016 /usr/sbin/auditbin -r-sr-x--- 1 root audit 40700 Mar 30 2016 /usr/sbin/auditcat -r-sr-x--- 1 root audit 13072 Mar 30 2016 /usr/sbin/auditconv -r-sr-x--- 1 root audit 11328 Mar 30 2016 /usr/sbin/auditmerge -r-sr-x--- 1 root audit 53466 Mar 30 2016 /usr/sbin/auditpr -r-sr-x--- 1 root audit 33128 Mar 30 2016 /usr/sbin/auditselect -r-sr-x--- 1 root audit 29952 Mar 30 2016 /usr/sbin/auditstream If any above file's permission is greater than "4550", this is a finding. Verify that "/usr/sbin/auditldap" is set to "500" or less permissive: # ls -l /usr/sbin/auditldap -r-x------ 1 root security 12204 Mar 30 2016 /usr/sbin/auditldap If the permission of "/usr/sbin/auditldap" is greater than "500", this is a finding.

Discussion

Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.

Fix Text

Turn on Trusted Execution and check the integrity of audit tools. # /usr/sbin/trustchk -p TE=ON CHKEXEC=ON If audit tool integrity data is missing from "/etc/security/tsd/tsd.dat", re-install the "bos.rte.security" fileset from AIX DVD using the installp command (assume the DVD is mounted to /dev/cd0): # installp -aXYqg -d /dev/cd0 bos.rte.security

Check Content

Verify that Trusted Execution (TE) is "on" and "CHKEXEC" is "on" by running the following command: # trustchk -p TE=ON CHKEXEC=ON CHKSHLIB=OFF CHKSCRIPT=OFF CHKKERNEXT=OFF STOP_UNTRUSTD=OFF STOP_ON_CHKFAIL=OFF LOCK_KERN_POLICIES=OFF TSD_FILES_LOCK=OFF TSD_LOCK=OFF TEP=OFF TLP=OFF If the result show "TE=OFF" or "CHKEXEC=OFF", this is a finding. Verify that TSD (Trusted Signature Database) contains all the audit tools and their signatures by running the following command: # awk '/\/usr\/sbin\/audit/ {print; for(i=1; i<=10; i++) {getline; print}}' /etc/security/tsd/tsd.dat |grep -E "\/usr\/sbin\/audit|cert_tag|signature|hash_value" /usr/sbin/auditselect: cert_tag = 00d3cbd2922627b209 signature = 8f6044a166ad7d1256a2798432dcb06b528eb6c515f4d2d0af90dd17e6ba05665bd8d39ee8f15e8872e90d3b52e0e25c7be9d62c9c5d71cd16b662fb8511f168b6facb4105cc0e9c19c316e37459ad739b75b6037827f3ba60896eeeec62cf47e7514b10d4813c48cacd76b75dc5b0e1a87f7cd10552992021efb5b44eb33a1a hash_value = 002e02eda12663a2c9478e1b5154cc97452c07a68a8b9d5a6ca3408b008d95bb /usr/sbin/auditstream: cert_tag = 00d3cbd2922627b209 signature = 3d5a678962b684208f3996262a997d8838012c1625d83b7df75d9bb3a83065819ae476a21ada2ec7afd683828d9ce5c9d3eb829ed907d11fc2713d895419cbec5855e96b4a3b36a4f5b3c44a801555727b1ca799026262120b18fe2d93f53da8e95f6560c0cf5ea73dccd7daa9ec3df7e24ede0201b9d632becfb58a8f81fee4 hash_value = 5c434a89bf2fb50a2c21734a5ecd3c4e0a92c34d6685633d59a93caf1684e515 /usr/sbin/auditpr: cert_tag = 00d3cbd2922627b209 signature = 8356f57d227a85037620ec6f357204a9dd3ceeb89fab2ea8b4dea5529a37d290e111a46e9deca8ebd86b37c50b8b2d27599d09a02353081db9f7140780ace0d9986c8f7265d3d91eed7a2502050a6342c79cf1fd6c9b2633e353fdc3603de3b6fc341b2b7a0c6eb286155ae9542bdbbcc29eba84a50f1f8c4f6f5924403f6556 hash_value = 34bf3b145327d33f810e939d15ae084711dcd0eb7e7f3ebcb135f5ff7b3ba776 /usr/sbin/auditcat: cert_tag = 00d3cbd2922627b209 signature = abf001ee98c5e81ec730552cd26473221ee14694a7fea06d97ae030f1b8603bafdb3f4917cb50c87c90fc8ff03e8762b05c6b21d1907a05288736fa820fd4a05d38f236fec5cfc3813aeb5b0618294effe0356ac26be0e6701398cf181fb38897c5a2496154bba3eab513caaa74a9abb230ad6948190d24907a107d8968a0c27 hash_value = 78febbeb1e7e4ca1ed4015fb147d27bd451814ed8c81429b42ee9e2f8301bf58 /usr/sbin/auditbin: cert_tag = 00d3cbd2922627b209 signature = 9bb3fde97a70dd3ee93ecf556cf13e3981d1f0794c7a253701e011956574754eb17922525092f38a3b0f9375aef8fadfe3cb6e47f6aa7424e3449910af6cc6e1754f6fe8c2fb20867af7f9a048485ea2dfcd7b8f718d350d21ec2ffe394423f4c513b22ff9a654f1ef55f6e679424ad0e630404fcfd707ed91d542d64564c601 hash_value = 2deb07bbdf5b744168bb9484b25c0e61813b546f0dd0555d9b9ebcb8cf17272d /usr/sbin/auditldap: cert_tag = 00d3cbd2922627b209 signature = ab3ea5ba592ef8d1576f632c6154e10a172fbdad1c6379954a48d76bd2c365848a208dfa698e828008fa73b60daf0ad0ab9ad08035f9df2d39ac21a67873cfac3eb07103858903c47e5d1e264ace01de9599ff3c966b12d8cbc6c2b6e3c97f8c56b7a5a4fa33f15bbe472319266854f83fad57917d9dd0c09383fd2b5df41e6d hash_value = f929ca078995a6b2a28d1247e9837e03d06fa2c5b12a6c86e679201192694c8c /usr/sbin/auditconv: cert_tag = 00d3cbd2922627b209 signature = ab7a0e0e5aa62ec741db601cc1609bf7db6006705a3d6b7001b3aa4da5ab6bcfecea569d6891b67088b2033045fdf6532a24433711c74fcffc92744884f0f14211a7625c168f11d4b3de2e7083e57a5063933c0eea5b92c6ab9ea1b131ca8fe85143f616887e4d60cfb534da8b3a920c428279ea8eee04bf57ad70da3c69104c hash_value = 0d2a989fa77df6984348f5c66d20af1e71aebd5a0d9f85551873563ee9d851d7 /usr/sbin/audit: cert_tag = 00d3cbd2922627b209 signature = 2b6ed42788eca469aaaf960d4ea9956793182cdbf6b8570ded724762701354f62d003a3ed99db9b4fbb670c5864c9a641d485083789840c71005bbdcc4659dbbfbec0e8c63c8223be9e54f46240e3a5ebed8647fbd9e0e9f2db0d046e0cd73e72c87977c9dc394b61027c2856a27db0e51afb05e07c2d4f8ea3bc33564f2e7a6 hash_value = 0c5d10f7c7cefec133bee45bd0d30933b18041438a7c7b15b8aa7de60ce208af /usr/sbin/auditmerge: cert_tag = 00d3cbd2922627b209 signature = 64e0f95c1efa90f34b6ddd370fc0a277db2858b01b993a2f32eb9f0c86e6d901675f67f42158015ceafa37507a0bc36bbd58aca6685464f8b43edb099db670aa497db349c51fc0ed6066da43e2eb5529af8bbdd0c30b66b22158261c224213fc406ffee36e4df476107f867d8f7c09c24e4318a13e2b279d200a9fa4a8b515e4 hash_value = 6b4a1d1288a1d7e987ad14b395d0067890574a09956171bb32b9a022dc975015 If any of the cert_tag, signature, or hash values is missing or “= VOLATILE", this is a finding.

Discussion

If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost. This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting.

Fix Text

Create a role "auditadm" that is assigned with security related authorization with the following commend: # mkrole authorizations="aix.security.audit,aix.security.user.audit,aix.security.role.audit" auditadm

Check Content

Verify that an audit admin role has been configured to include the authorizations for auditing, namely "aix.security.audit,aix.security.user.audit,aix.security.role.audit": # lsrole ALL |grep "aix.security.audit" |grep "aix.security.user.audit" |grep "aix.security.role.audit" auditadm authorizations=aix.security.audit,aix.security.user.audit,aix.security.role.audit rolelist= groups= visibility=1 screens=* dfltmsg=Audit Administrator msgcat=role_desc.cat msgnum=15 msgset=1 auth_mode=INVOKER id=16 If the above command has no output, this is a finding.

Discussion

In order to ensure operating systems have a sufficient storage capacity in which to write the audit logs, operating systems need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of AIX.

Fix Text

Increase the size of the file system hosting the audit logs (by 1GB). # chfs -a size=+1G <root of file system for audit logs>

Check Content

Check the file system size where the log file resides is greater than the organizationally defined size of audit logs for one week (1GB). Find out where the audit log resides: # grep trail /etc/security/audit/config trail = /audit/trail Find out the available space in the file system hosting the audit logs. # df /audit/trail Filesystem 512-blocks Free %Used Iused %Iused Mounted on /dev/hd4 1966080 1792872 9% 3913 2% / If the "512-blocks" multiplied by "Free" is less than the required size for the audit logs, this is a finding.

Discussion

The report generation capability must support on-demand review and analysis in order to facilitate the organization's ability to generate incident reports, as needed, to better handle larger-scale or more complex security incidents. If the report generation capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack, or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. Report generation must be capable of generating on-demand (i.e., customizable, ad hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective. Satisfies: SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140

Fix Text

Use the installp command to install a fileset (assume cd is mounted). # installp -aXYqg -d /dev/cd0 bos.rte.security

Check Content

Check to see if the application for generating audit reports exists ("/usr/sbin/auditpr"): # ls -l /usr/sbin/auditpr -r-sr-x--- 1 root audit 54793 Feb 14 2017 /usr/sbin/auditpr If the file does not exist, this is a finding.

Discussion

If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by AIX include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.

Fix Text

Change time zone setting to either UCT or GMT, then reboot the system for the setting to take effect. # chtz UCT Or change time zone to GMT # chtz GMT then # reboot

Check Content

Check the time zone setting by the following command: # echo $TZ UCT If the result is not UCT or GMT, this is a finding.

Discussion

Rotate audit logs daily to preserve audit file system space and to conform to the DoD/DISA requirement. If it is not rotated daily and moved to another location, then there is more of a chance for the compromise of audit data by malicious users.

Fix Text

Configure a cron job or other automated process to rotate the audit logs on a daily basis.

Check Content

Check for any "crontab" entries that rotate audit logs: # crontab -l 30 23 * * * /root/logrotate.sh #Daily log rotation script If such a cron job is found, this is not a finding. Otherwise, query the SA. If there is a process automatically rotating audit logs, this is not a finding. If the SA manually rotates audit logs, this is a finding. If the audit output is not archived daily, to tape or disk, this is a finding. Review the audit log directory. If more than one file is there, or if the file does not have today's date, this is a finding.

Discussion

The exec service is used to execute a command sent from a remote server. The username and passwords are passed over the network in clear text and therefore insecurely. Unless required the rexecd daemon will be disabled. This function, if required, should be facilitated through SSH.

Fix Text

Disable the "rexecd" entry in "/etc/inetd.conf" using command: # chsubserver -r inetd -C /etc/inetd.conf -d -v 'exec' -p 'tcp6' Reload the inetd process: # refresh -s inetd

Check Content

Determine if the "rexec" daemon is running by running the following command: # grep "^exec[[:blank:]]" /etc/inetd.conf If the above grep command returned a line that contains "rexecd", this is a finding.

Discussion

This telnet service is used to service remote user connections. This is historically the most commonly used remote access method for UNIX servers. The username and passwords are passed over the network in clear text and therefore insecurely. Unless required the telnetd daemon will be disabled. This function, if required, should be facilitated through SSH.

Fix Text

Disable the "telnet" entry in "/etc/inetd.conf" using command: # chsubserver -r inetd -C /etc/inetd.conf -d -v 'telnet' -p 'tcp6' Reload the inetd process: # refresh -s inetd

Check Content

Determine if the "telnet" daemon is running by running the following command: # grep -v '^#' /etc/inetd.conf | grep telnet If an entry is returned, this is a finding.

Discussion

The ftp service is used to transfer files from or to a remote machine. The username and passwords are passed over the network in clear text and therefore insecurely. Remote file transfer, if required, should be facilitated through SSH.

Fix Text

Disable "ftp" daemon entry in "/etc/inetd.conf" using command: # chsubserver -r inetd -C /etc/inetd.conf -d -v 'ftp' -p 'tcp6' Reload the inetd process: # refresh -s inetd

Check Content

Determine if the "ftp" daemon is running by running the following command: # grep "^ftp[[:blank:]]" /etc/inetd.conf If an entry is returned like the following line, the "ftp" daemon is running: ftp stream tcp6 nowait root /usr/sbin/ftpd ftpd If the above grep command returned a line that contains "ftpd", this is a finding.

Discussion

sudo command does not require reauthentication if NOPASSWD tag is specified in /etc/sudoers config file, or sudoers files in /etc/sudoers.d/ directory. With this tag in sudoers file, users are not required to reauthenticate for privilege escalation.

Fix Text

Edit "/etc/sudoers" using "visudo" command to remove all the "NOPASSWD" tags: # visudo -f Editing a sudo config file that is in "/etc/sudoers.d/" directory and contains the "NOPASSWD" tags, use "visudo" the command as follows: # visudo -f /etc/sudoers.d/<config_file_name>

Check Content

If sudo is not used on AIX, this is Not Applicable. Run the following command to find the "NOPASSWD" tag in "/etc/sudoers" file: # grep NOPASSWD /etc/sudoers If there is a "NOPASSWD" tag found in "/etc/sudoers" file, this is a finding. Run the following command to find the "NOPASSWD" tag in one of the sudo config files in "/etc/sudoers.d/" directory: # find /etc/sudoers.d -type f -exec grep -l NOPASSWD {} \; The above command displays all sudo config files that are in "/etc/sudoers.d/" directory and they contain the "NOPASSWD" tag. If above command found a config file that is in "/etc/sudoers.d/" directory and contains the "NOPASSWD" tag, this is a finding.

Discussion

sudo command does not require reauthentication if !authenticate option is specified in /etc/sudoers config file, or config files in /etc/sudoers.d/ directory. With this tag in sudoers, users are not required to reauthenticate for privilege escalation.

Fix Text

Edit "/etc/sudoers" using "visudo" command to remove all the "!authenticate" options: # visudo -f /etc/sudoers Editing a sudo config file that is in "/etc/sudoers.d/" directory and contains "!authenticate" options, use the "visudo" command as follows: # visudo -f /etc/sudoers.d/<config_file_name>

Check Content

If sudo is not used on AIX, this is Not Applicable. Run the following command to find "!authenticate" option in "/etc/sudoers" file: # grep "!authenticate" /etc/sudoers If there is a "!authenticate" option found in "/etc/sudoers" file, this is a finding. Run the following command to find "!authenticate" option in one of the sudo config files in "/etc/sudoers.d/" directory: # find /etc/sudoers.d -type f -exec grep -l "!authenticate" {} \; The above command displays all sudo config files that are in "/etc/sudoers.d/" directory and they contain the "!authenticate" option. If above command found a config file that is in "/etc/sudoers.d/" directory and that contains the "!authenticate" option, this is a finding.

Discussion

If a system has no default gateway defined, the system is at increased risk of man-in-the-middle, monitoring, and Denial of Service attacks.

Fix Text

Set a default gateway for IPv4 using: # route add 0 <ip address of gateway>

Check Content

Check the system for an IPv4 default route using command: # netstat -r |grep default default 10.11.20.1 UG 1 1811 en0 - - If a default route is not defined, this is a finding.

Discussion

IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers.

Fix Text

Disable IPv4 forwarding on the system by running command: # no -p -o ipforwarding=0

Check Content

From the command prompt, run the following command: # no -o ipforwarding ipforwarding = 0 If the value returned is not "0", this is a finding.

Discussion

If a system has no default gateway defined, the system is at increased risk of man-in-the-middle, monitoring, and Denial of Service attacks.

Fix Text

Configure an IPv6 default route on the system: # smitty route

Check Content

If the system is a router, this is Not Applicable. If the system does not use IPv6, this is Not Applicable. Determine if the system has a default route configured for IPv6 by running: # netstat -r | grep default default 10.11.20.1 UG 1 1823 en0 - - If a default route is not defined, this is a finding.

Discussion

If the system is configured for IP forwarding and is not a designated router, it could be used to bypass network security by providing a path for communication not filtered by network devices.

Fix Text

Disable IPv6 forwarding on the system: # /usr/sbin/no -p -o ip6forwarding=0

Check Content

From the command prompt, run the following command: # /usr/sbin/no -o ip6forwarding ip6forwarding = 0 If the value returned is not "0", this is a finding.

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify AIX or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Fix Text

Change the owner of the system log file(s) to a system account: # chown [system_account] /path/to/system-log-file

Check Content

Check the owner of log files: # ls -lL /var/log /var/log/syslog /var/adm /var/adm: total 376 drw-r----- 2 root system 256 Jan 24 12:31 SRC drwx------ 4 root system 256 Jan 24 07:28 config -rw-r----- 1 root system 1081 Jan 24 09:05 dev_pkg.fail -rw-r----- 1 root system 250 Jan 24 09:05 dev_pkg.success -rw------- 1 root system 64 Jan 24 09:43 sulog drwxr-xr-x 3 root system 256 Jan 24 12:28 sw drwx------ 2 root system 256 Jan 24 08:06 wpars -rw-r----- 1 adm adm 7517448 Apr 29 14:10 wtmp /var/log: total 8 drwxr-xr-x 2 root system 256 Jan 24 08:44 aso -rw-r----- 1 root system 603 Jan 24 10:30 cache_mgt.dr.log If any of the log files are not owned by a system account, this is a finding.

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify AIX or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Fix Text

Change the group of the system log file(s) to a system group: # chgrp [system_group] /path/to/system-log-file

Check Content

Check the group of log files: # ls -lL /var/log /var/log/syslog /var/adm /var/adm: total 376 drw-r----- 2 root system 256 Jan 24 12:31 SRC drwx------ 4 root system 256 Jan 24 07:28 config -rw-r----- 1 root system 1081 Jan 24 09:05 dev_pkg.fail -rw-r----- 1 root system 250 Jan 24 09:05 dev_pkg.success -rw------- 1 root system 64 Jan 24 09:43 sulog drwxr-xr-x 3 root system 256 Jan 24 12:28 sw drwx------ 2 root system 256 Jan 24 08:06 wpars -rw-r----- 1 adm adm 7517448 Apr 29 14:10 wtmp /var/log: total 8 drwxr-xr-x 2 root system 256 Jan 24 08:44 aso -rw-r----- 1 root system 603 Jan 24 10:30 cache_mgt.dr.log If any of the log files have group other than a system group, this is a finding.

Discussion

Restricting permissions will protect the files from unauthorized modification.

Fix Text

Change the group owner of system files to a system group by running the following command: # chgrp sys /path/to/system/file Note: System groups other than "sys" may be used.

Check Content

Check the group ownership of system files, programs, and directories run the following command: # ls -lLa /etc /bin /usr/bin /usr/lbin /usr/ucb /sbin /usr/sbin If any system file, program, or directory is not group-owned by a system group, this is a finding. Note: For this check, the system-provided "ipsec" group is also acceptable.

Discussion

Failure to give ownership of sensitive files or utilities to system groups may provide 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-bit" and the ownership of "/etc/inetd.conf": # chmod 644 /etc/inetd.conf # chown root:system /etc/inetd.conf

Check Content

Check the ownership of "/etc/inetd.conf": # ls -l /etc/inetd.conf | awk '{print $1 " " $3 " " $4 " " $9}' The above command should yield the following output: -rw-r--r-- root system /etc/inetd.conf If it does not, this is a finding.

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 owner of the "crontab" directory: # chown root /var/spool/cron/crontabs

Check Content

Check the owner of the "crontab" directory using command: # ls -ld /var/spool/cron/crontabs drwxrwx--- 2 bin cron 256 Jan 25 12:33 /var/spool/cron/crontabs If the owner of the "crontab" directory is not "root" or "bin", this is a finding.

Discussion

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

Fix Text

Change the group owner of the audio device using command: # chgrp system <audio device>

Check Content

Check the group owner of audio devices using commands: # /usr/sbin/lsdev -C | grep -i audio aud0 Available USB Audio Device # ls -lL /dev/*aud0 cr--r--r-- 1 root system 16, 0 Jan 24 07:25 aud0 If the group owner of an audio device is not "root", "sys", "bin", or "system", this is a finding.

Discussion

A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system account, unauthorized modifications could result in the failure of time synchronization.

Fix Text

Change the ownership of the file to root using command: # chown root /etc/ntp.conf

Check Content

Check the ownership of /etc/ntp.conf using command: # ls -al /etc/ntp.conf The above command should yield the following output: -rw-r----- 1 root system 993 Aug 25 18:26 /etc/ntp.conf If the file is not owned by root, this is a finding.

Discussion

A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system group, unauthorized modifications could result in the failure of time synchronization.

Fix Text

Change the group owner of the files in "/etc/news" to "system" using: # chgrp system /etc/ntp.conf

Check Content

Check "/etc/ntp.conf" file group ownership: # ls -al /etc/ntp.conf The above command should yield the following output: -rw-r----- 1 root system 993 Aug 25 18:26 /etc/ntp.conf If the file is not group-owned by "system", this is a finding.

Discussion

The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Fix Text

Change the owner of the "/etc/group" file to "root": # chown root /etc/group

Check Content

Verify the "/etc/group" file is owned by "root" using command: # ls -l /etc/group The above command should yield the following output: -rw-r--r-- 1 root security 387 Sep 06 11:40 /etc/group If the file is not owned by "root", this is a finding.

Discussion

The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Fix Text

Change the group of the "/etc/group" file to "security": # chgrp security /etc/group

Check Content

Verify the "/etc/group" file is group-owned by "security" using command: # ls -l /etc/group The above command should yield the following output: -rw-r--r-- 1 root security 387 Sep 06 11:40 /etc/group If the file is not group-owned by "security", this is a finding.

Discussion

System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.

Fix Text

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

Check Content

Check the ownership of each user's home directory listed in the "/etc/passwd file": # cut -d: -f6 /etc/passwd | xargs ls -lLd drwxr-xr-x 21 root system 4096 Jan 29 09:58 / drwxr-xr-x 4 bin bin 45056 Jan 24 12:31 /bin drwxr-xr-x 2 doejohn staff 256 Jan 25 13:18 /home/doejohn drwxr-xr-x 2 sshd system 256 Aug 11 2017 /home/srvproxy drwx------ 2 root system 256 Jan 30 12:54 /root drwxrwxr-x 4 bin bin 256 Mar 23 2017 /usr/sys drwxrwxr-x 15 root adm 4096 Jan 24 12:26 /var/adm drwxr-xr-x 6 root system 4096 Jan 24 07:34 /var/adm/invscout drwxr-xr-x 8 esaadmin system 256 Jan 24 09:02 /var/esa If any user's home directory is not owned by the assigned user, this is a finding.

Discussion

If the Group Identifier (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 users home directories to the primary group of the assigned user: # 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 using command: # cut -d: -f6 /etc/passwd | xargs ls -lLd drwxr-xr-x 21 root system 4096 Jan 29 09:58 / drwxr-xr-x 4 bin bin 45056 Jan 24 12:31 /bin drwxr-xr-x 2 doejohn staff 256 Jan 25 13:18 /home/doejohn drwxr-xr-x 2 sshd system 256 Aug 11 2017 /home/srvproxy drwx------ 2 root system 256 Jan 30 12:54 /root drwxrwxr-x 4 bin bin 256 Mar 23 2017 /usr/sys drwxrwxr-x 15 root adm 4096 Jan 24 12:26 /var/adm drwxr-xr-x 6 root system 4096 Jan 24 07:34 /var/adm/invscout drwxr-xr-x 8 esaadmin system 256 Jan 24 09:02 /var/esa If any user's 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.

Discussion

If the Group Identifier (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 of a file not group-owned by a group where the home directory's owner is a member using command: # chgrp [user's primary group] [file with bad group ownership]

Check Content

Check the contents of user home directories for files group-owned by a group of which the home directory's owner is not a member. List the user accounts: # cut -d : -f 1 /etc/passwd root daemon bin sys adm uucp nobody invscout snapp ipsec srvproxy esaadmin sshd doejohn dirtjoe For each user account, get a list of group names for files in the user's home directory: # find < users home directory > -exec ls -lLd {} \; Obtain the list of group names associated with the user's account: # lsuser -a groups < user name > doejohn groups=staff Check the group name lists: # cat /etc/group system:!:0:root,srvproxy,esaadmin staff:!:1:ipsec,srvproxy,esaadmin,sshd,doejohn bin:!:2:root,bin sys:!:3:root,bin,sys adm:!:4:bin,adm mail:!:6: security:!:7:root cron:!:8:root audit:!:10:root ecs:!:28: nobody:!:4294967294:nobody,lpd usr:!:100:dirtjoe perf:!:20: shutdown:!:21: invscout:!:12:invscout snapp:!:13:snapp ipsec:!:200: sshd:!:201:sshd If there are group names in the file list not present in the user list, 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 by running the following command: # 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.

Check Content

Check the mode of library files by running the following command: # ls -lLR /usr/lib /lib If any of the library files have a mode more permissive than "0755", this is a finding.

Discussion

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

Fix Text

Run the following command to un-install the samba packages: # installp -ug samba*

Check Content

Run the following command to check if samba packages are installed on AIX: # lslpp -l samba* If the above command shows that samba packages are installed, this is a finding.

Discussion

A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. File permissions more permissive than 0640 for time synchronization configuration file may allow access and change the config file by system intruders or malicious users, could result in the failure of time synchronization.

Fix Text

Change the mode of the "ntp.conf" file to "0640" or less permissive: # chmod 0640 /etc/ntp.conf

Check Content

Determine the mode of the ntp.conf file: # ls -l /etc/ntp.conf The above command should yield the following output: -rw-r----- 1 root system 993 Aug 25 18:26 /etc/ntp.conf If the mode is more permissive than "0640", this is a finding.

Discussion

The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Fix Text

Change the mode of the "/etc/group" file to "0644": # chmod 0644 /etc/group

Check Content

Verify the "/etc/group" file has the mode "0644" using command: # ls -l /etc/group The above command should yield the following output: -rw-r--r-- 1 root security 387 Sep 06 11:40 /etc/group If the file does not have mode "0644" or less permissive, this is a finding.

Discussion

The AIX Encrypted File System (EFS) is a J2 filesystem-level encryption through individual key stores. This allows for file encryption in order to protect confidential data from attackers with physical access to the computer. User authentication and access control lists can protect files from unauthorized access (even from root user) while the operating system is running. Operating systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). Satisfies: SRG-OS-000480-GPOS-00227, SRG-OS-000405-GPOS-00184, SRG-OS-000404-GPOS-00183

Fix Text

Install "clic.rte" filesets from AIX DVD Volume 1 using the following commands (assuming that the DVD device is /dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log clic.rte.lib # installp -aXYgd /dev/cd0 -e /tmp/install.log clic.rte.kernext Run the follow command to initialize and enable EFS on the system: # efsenable -a To create a new EFS-enabled JFS2 file system and mount the file system, using the following commands: # crfs -v jfs2 -g rootvg -m /fs2 -a size=100M -a efs=yes # mount /fs2 To enable EFS on a JFS2 file system (like, /fs3), run the following command: chfs -a efs=yes /fs3

Check Content

If the organization does not require to encrypt the data at rest, this is Not Applicable. Check if "clic.rte" fileset is installed: # lslpp -l |grep clic The above command should yield the following output: clic.rte.kernext 4.10.0.1 COMMITTED CryptoLite for C Kernel clic.rte.lib 4.10.0.1 COMMITTED CryptoLite for C Library clic.rte.kernext 4.10.0.1 COMMITTED CryptoLite for C Kernel If the "clic.rte.lib", or the "clic.rte.kernext", fileset is not installed, this is a finding. To check if a JFS2 file system (mounted as /fs2_mnt) is EFS-enabled, use the following command: # lsfs -q /fs2_mnt Name Nodename Mount Pt VFS Size Options Auto Accounting /dev/fslv00 -- /fs2_mnt jfs2 262144 -- no no (lv size: 262144, fs size: 262144, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v2, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no) If the above command shows "EFS: no", this is a finding.

Discussion

Without protection of the transmitted or received information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174

Fix Text

If the SSH server package is not installed, install "openssh.base.server" package and config the SSH daemon. If the ssh demon is not "active", run the following command to start it: # startsrc -s sshd

Check Content

Run the following command to check if SSH server package is installed: # lslpp -l | grep -i ssh openssh.base.client 6.0.0.6201 COMMITTED Open Secure Shell Commands openssh.base.server 6.0.0.6201 COMMITTED Open Secure Shell Server openssh.man.en_US 6.0.0.6201 COMMITTED Open Secure Shell If package "openssh.base.server" is not installed, this is a finding. Run the following command to check if the SSH daemon is running: # lssrc -s sshd | grep active sshd ssh 3670408 active If "sshd" is "inoperative", this is a finding.

Discussion

Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Fix Text

Remove the symlink of "/var/adm/wtmp" file by using the following command: # rm /var/adm/wtmp The "/var/adm/wtmp" file will be created when the system logs event for successful or failed login.

Check Content

Check if the file "/var/adm/wtmp" is a symlink by using the following command: # ls -al /var/adm/wtmp The above command should yield the following output: -rw-rw-r-- 1 adm adm 45360 Sep 05 15:00 /var/adm/wtmp If the file "/var/adm/wtmp" is a symlink, this is a finding.

Discussion

Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyberattacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Fix Text

Remove the symlink of "/etc/security/failedlogin" file by using the following command: # rm /etc/security/failedlogin The "/etc/security/failedlogin" file will be created when system logs event for a failed login.

Check Content

Check if the file "/etc/security/failedlogin" is a symlink by using the following command: # ls -al /etc/security/failedlogin The above command should yield the following output: -rw------- 1 root system 648 Sep 05 14:59 /etc/security/failedlogin If the file "/etc/security/failedlogin" is a symlink, this is a finding.

Discussion

Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password.

Fix Text

Edit the "/etc/ssh/sshd_config" file to have the following line and save the change: PermitRootLogin no Restart SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Determine if the SSH daemon is configured to disable root logins: # grep -iE "PermitRootLogin[[:blank:]]*no" /etc/ssh/sshd_config | grep -v \# If the above command displays a line, the root login is disabled. If the root login is not disabled, this is a finding.

Discussion

The /etc/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 SMIT to change the "/etc/passwd" shell entry.

Check Content

Confirm the login shells referenced in the "/etc/passwd" file are listed in the "/etc/security/login.cfg" file's "shells =variable" in the usw stanza by running commands: # more /etc/security/login.cfg | grep shells | grep -v '*' shells = /bin/sh,/bin/bsh,/bin/csh,/bin/ksh,/bin/tsh,/bin/ksh93,/usr/bin/sh,/usr/bin/bsh,/usr/bin/csh,/usr/bin/ksh,/usr/bin/tsh # more /etc/shells /bin/csh /bin/ksh /bin/psh /bin/tsh /bin/bsh /usr/bin/csh /usr/bin/ksh /usr/bin/psh /usr/bin/tsh /usr/bin/bsh 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 shells stanza. If a shell referenced in "/etc/passwd" is not listed in the shells stanza, excluding the above mentioned shells, this is a finding.

Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.

Fix Text

Add or edit the following line in the "/etc/ssh/sshd_config" file to support "Protocol 2" only: Protocol 2 Save the change to /etc/ssh/sshd_config Restart ssh daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

From the command prompt, run the following command: # grep ^Protocol /etc/ssh/sshd_config The above command should yield the following output: Protocol 2 If the above command does not show the ssh server supporting "Protocol 2" only, this is a finding.

Discussion

Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific operating system functionality where the system owner, data owner, or organization requires additional assurance.

Fix Text

Add or update the following lines in "/etc/ssh/sshd_config": ClientAliveInterval 300 ClientAliveCountMax 0 Restart sshd: # stopsrc -s sshd # startsrc -s sshd

Check Content

Run the following command to check if "ClientAliveInterval" and "ClientAliveCountMax" are set for SSH server: # grep -E "^ClientAliveInterval|^ClientAliveCountMax" /etc/ssh/sshd_config ClientAliveInterval 300 ClientAliveCountMax 0 If "ClientAliveCountMax" is not set or its value is not "0", this is a finding. If "ClientAliveInterval" is not set, or its value is not "300" (5-minutes), this is a finding.

Discussion

Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Fix Text

Edit the "/etc/ssh/sshd_config" file and add or change the "KerberosAuthentication" value of the setting to "no". Refresh sshd: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for the Kerberos authentication setting: # grep -i KerberosAuthentication /etc/ssh/sshd_config | grep -v '^#' If the setting is present and set to "yes", this is a finding.

Discussion

GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.

Fix Text

Edit "/etc/ssh/sshd_config" and remove the "GSSAPIAuthentication" setting or change the value to "no". Refresh sshd: # stopsrc -s sshd # startsrc -s sshd

Check Content

Ask the SA if GSSAPI authentication is used for SSH authentication to the system. If so, this is not applicable. Check the SSH daemon configuration for the GSSAPI authentication setting: # grep -i GSSAPIAuthentication /etc/ssh/sshd_config | grep -v '^#' GSSAPIAuthentication no If the setting is not set to "no", this is a finding.

Discussion

Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).

Fix Text

Obtain the file that contains all the public keys that need to be revoked from ISSO/SA and save the file in /etc/ssh/ directory. Edit the "/etc/ssh/sshd_config" file to allow "RevokedKeys" to point to the revoked key file obtained above. Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

If public keys are not used for SSH authentication, this is Not Applicable. Run the following command: # grep "^RevokedKeys" /etc/ssh/sshd_config RevokedKeys /etc/ssh/RevokedKeys.txt If the command does not find the "RevokedKeys" setting, or the value for "RevokedKeys" is set to "none", this is a finding.

Discussion

DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.

Fix Text

Edit the "/etc/ssh/sshd_config" file and add/edit the following line to contain FIPS 140-2 approved ciphers: MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96 Restart SSH daemon: # stopsrc -s sshd # startsrc -s sshd Note: If the "MACs" configuration contains any ciphers that are not FIPS 140-2 approved, they should be removed from the configuration file.

Check Content

Check the SSH daemon configuration for allowed MACs by running the following command: # grep -i macs /etc/ssh/sshd_config | grep -v '^#' MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96 If no lines are returned, or the returned MAC list contains any MAC that is not FIPS 140-2 approved, this is a finding.

Discussion

The SSH daemon must be configured for IP filtering to provide a layered defense against connection attempts from unauthorized addresses.

Fix Text

Add appropriate IP restrictions for SSH to the "/etc/hosts.deny" and/or "/etc/hosts.allow" files. TCP Wrappers can be installed from the AIX Expansion Pack by installing fileset "netsec.options.tcpwrappers" using the following command (assume AIX Expansion Pack is mounted on /dev/cd0): # installp -aXYgd /dev/cd0 -e /tmp/install.log netsec.options.tcpwrappers

Check Content

Check the TCP wrappers configuration files to determine if SSHD is configured to use TCP wrappers using commands: # grep sshd /etc/hosts.deny sshd : ALL # grep sshd /etc/hosts.allow sshd : 10.10.20.* If no entries are returned, the TCP wrappers are not configured for SSHD, this is a finding.

Discussion

If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.

Fix Text

Edit the "/etc/ssh/sshd_config" file and add (or modify) the following line: Compression no Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for the Compression setting by running: # grep -i Compression /etc/ssh/sshd_config | grep -v '^#' Compression no If the setting is not present, or it is not set to "no", this is a finding.

Discussion

SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.

Fix Text

Edit the "/etc/sshd/sshd_config" file and add the following line: UsePrivilegeSeparation yes Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for the "UsePrivilegeSeparation" setting using command: # grep -i UsePrivilegeSeparation /etc/ssh/sshd_config | grep -v '^#' UsePrivilegeSeparation yes If the setting is not present or the setting is "no", this is a finding.

Discussion

If reverse name checking is off, SSH may allow a remote attacker to circumvent security policies and attempt to or actually login from IP addresses that are not permitted to access resources.

Fix Text

Edit the "/etc/sshd/sshd_config" file and add the following line: VerifyReverseMapping yes Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for the "VerifyReverseMapping" setting using command: # grep -i VerifyReverseMapping /etc/ssh/sshd_config | grep -v '^#' VerifyReverseMapping yes If the setting is not present or the setting is "no", this is a finding.

Discussion

If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.

Fix Text

Edit the "/etc/sshd/sshd_config" file and add or change the "StrictModes" setting to "yes". Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for the "StrictModes" setting using command: # grep -i StrictModes /etc/ssh/sshd_config | grep -v '^#' StrictModes yes If the setting is missing or is set to "no", this is a finding.

Discussion

X11 forwarding over SSH allows for the secure remote execution of X11-based applications. This feature can increase the attack surface of an SSH connection and should not be enabled unless needed.

Fix Text

Edit the "/etc/sshd/sshd_config" file to add the following line and save the change: X11Forwarding no Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

If X11 forwarding has been authorized for use, this is Not Applicable. Check the SSH daemon configuration for the "X11Forwarding" directive using command: # grep -i X11Forwarding /etc/ssh/sshd_config | grep -v '^#' X11Forwarding no If the setting is not present or the setting is "yes", this is a finding.

Discussion

SSH TCP connection forwarding provides a mechanism to establish TCP connections proxied by the SSH server. This function can provide similar convenience to a Virtual Private Network (VPN) with the similar risk of providing a path to circumvent firewalls and network ACLs.

Fix Text

Edit the "/etc/sshd/sshd_config" file to add the following line and save the change: AllowTcpForwarding no Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

If TCP forwarding is approved for use by the ISSO, this is not applicable. Check the SSH daemon configuration for the "AllowTcpForwarding" directive using command: # grep -i AllowTcpForwarding /etc/ssh/sshd_config | grep -v '^#' AllowTcpForwarding no If the setting is not present or the setting is "yes", this is a finding.

Discussion

When password authentication is allowed, PermitEmptyPasswords specifies whether the server allows login to accounts with empty password strings. If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

Fix Text

Edit "/etc/ssh/sshd_config" and add or edit the "PermitEmptyPasswords " line as: PermitEmptyPasswords no Save the change and restart ssh daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for allowed empty passwords using command: # grep -i PermitEmptyPasswords /etc/ssh/sshd_config | grep -v '^#' PermitEmptyPasswords no If no lines are returned, or the returned "PermitEmptyPasswords" directive contains "yes", this is a finding.

Discussion

Trust .rhost file means a compromise on one host can allow an attacker to move trivially to other hosts.

Fix Text

Edit "/etc/ssh/sshd_config" and add or update the "IgnoreRhosts " line as: IgnoreRhosts yes Save the change and restart ssh daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for allowed ".rhosts" using command: # grep -i IgnoreRhosts /etc/ssh/sshd_config | grep -v '^#' IgnoreRhosts yes If no lines are returned, or the returned "IgnoreRhosts" directive is not set to "yes", this is a finding.

Discussion

SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.

Fix Text

Edit "/etc/ssh/sshd_config" and add or update the "HostbasedAuthentication" line as: HostbasedAuthentication no Save the change and restart ssh daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for allowed host-based authentication using command: # grep -i HostbasedAuthentication /etc/ssh/sshd_config | grep -v '^#' HostbasedAuthentication no If no lines are returned, or the returned "HostbasedAuthentication" directive contains "yes", this is a finding.

Discussion

If SSH permits rhosts RSA authentication, a user may be able to log in based on the keys of the host originating the request and not any user-specific authentication.

Fix Text

Edit the "/etc/ssh/sshd_config file", add the following line, and save the change: RhostsRSAAuthentication no Restart the SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for the "RhostsRSAAuthentication" setting by running: # grep -i RhostsRSAAuthentication /etc/ssh/sshd_config | grep -v '^#' The above command should yield the following output: RhostsRSAAuthentication no If the setting is present and set to "yes", this is a finding.

Discussion

The SSH daemon should only listen on the approved listening IP addresses. Otherwise the SSH service could be subject to unauthorized access.

Fix Text

Edit the SSH daemon config file and add/modify the "ListenAddress" network addresses: # vi /etc/ssh/sshd_config Restart SSH daemon: # stopsrc -s sshd # startsrc -s sshd

Check Content

From the command prompt, run the following command to check if "ListenAddress" is defined in SSH config file: # grep -i ListenAddress /etc/ssh/sshd_config | grep -v '^#' ListenAddress 10.17.76.74 If no configuration is returned, or if a returned listen configuration contains addresses not permitted, this is a finding.

Discussion

If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed, which would result in query failure or DoS. Data origin and integrity authentication must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching Domain Name System (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Information systems that use technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity of response data. This is not applicable if DNSSEC is not implemented on the local network. Satisfies: SRG-OS-000399-GPOS-00178, SRG-OS-000400-GPOS-00179, SRG-OS-000401-GPOS-00180, SRG-OS-000402-GPOS-00181

Fix Text

Add the following line to the "/etc/resolv.conf" file: nameserver <nameserver_IPAddress>

Check Content

Run "nslookup" command at the prompt: #nslookup <host_name> Server: 10.18.12.40 Address: 10.18.12.40#53 If the Server output does not point to an authorized nameserver IPAddress, this is a finding. Verify the nameserver is configured in "/etc/resov.conf": # grep -i nameserver /etc/resolv.conf nameserver 10.18.12.40 If the "nameserver" entry is not found in "/etc/resolv.conf" or does not match the ipaddress from the "nslookup" command, this is a finding.

Discussion

This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.

Fix Text

Assign the "root" account a password using passwd command while logged on as "root": # passwd

Check Content

Verify that the "root" account has a password assigned: # cut -d: -f1,2 /etc/passwd | grep root root:! If the "root" account is not listed with an "!", this is a finding.

Discussion

If a user cannot explicitly end an operating system session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users need to be aware of whether or not the session has been terminated. Information resources to which users gain access via authentication include, for example, local workstations and remote services. Logoff messages can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions, including, for example, remote login, information systems typically send logoff messages as final messages prior to terminating sessions.

Fix Text

Create the ".bash_logout" file if it does not exist. Add the following two lines to ".bash_logout" to display a logout message and sleep for "5" seconds: echo "You are being disconnected." sleep 5

Check Content

Identify any users that are using the BASH shell: # cut -d: -f1,7 /etc/passwd | grep -i bash doejohn:/bin/bash If no users are assigned the BASH shell, this is Not Applicable Verify that each BASH shell user has a ".bash_logout" file: # for home in `cut -d: -f6 /etc/passwd`; do ls -alL $home/.bash_logout; done -rwxr----- 1 doejohn staff 297 Jan 29 09:47 /home/doejohn/.bash_logout If a user does not have their ".bash_logout" file, this is a finding. Verify that each ".bash_logout" file identified above contains a logout message: # cat <user_home_directory>/.bash_logout echo "You are being disconnected." sleep 5 If the ".bash_logout" file is not configured to display a logout message, this is a finding.

Discussion

If a user cannot explicitly end an operating system session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users need to be aware of whether or not the session has been terminated. Information resources to which users gain access via authentication include, for example, local workstations and remote services. Logoff messages can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions, including, for example, remote login, information systems typically send logoff messages as final messages prior to terminating sessions.

Fix Text

Create the ".logout" file if it does not exist. Add the following two lines to ".logout" to display a logout message and sleep for "5" seconds: echo "You are being disconnected." sleep 5 Create, or modify, ".profile" to include the following line: trap '$HOME/.logout' EXIT

Check Content

Verify users have a ".logout" file in their home directory: # for home in `cut -d: -f6 /etc/passwd`; do ls -alL $home/.logout; done -rwxr----- 1 root system 297 Jan 29 09:47 /root/.logout -rwxr----- 1 doejohn staff 297 Jul 4 00:47 /home/doejohn/.logout If an interactive user does not have their ".logout" file, this is a finding. Verify that each ".logout" file identified above contains a logout message: # cat <user_home_directory>/.logout echo "You are being disconnected." sleep 5 If the ".logout" file does not display a logout message, this is a finding. Verify each users' ".profile" file calls "$HOME/.logout" while logging out: # grep "trap '$HOME/.logout' EXIT " <user_home_directory>/.profile trap '$HOME/.logout' EXIT If the ".profile" file does not call "$HOME/.logout", this is a finding.

Discussion

If a user cannot explicitly end an operating system session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users need to be aware of whether or not the session has been terminated. Information resources to which users gain access via authentication include, for example, local workstations and remote services. Logoff messages can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions, including, for example, remote login, information systems typically send logoff messages as final messages prior to terminating sessions.

Fix Text

Create the ".logout" file if it does not exist. Add the following two lines to ".logout" to display a logout message and sleep for "5" seconds: echo "You are being disconnected." sleep 5

Check Content

Check if users have their "$HOME/.logout" files. If a user does not have their ".logout" file, or the ".logout" file does not display a logout message, this is a finding.

Discussion

If a remote log host is in use and it has not been justified and documented, sensitive information could be obtained by unauthorized users without the administrator’s knowledge. Satisfies: SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224

Fix Text

Edit the /etc/syslog.conf file to include a documented and approved remote log host.

Check Content

Examine the "syslog.conf" file for any references to remote log hosts using command: # grep -v "^#" /etc/syslog.conf | grep '@' @<loghost> Ask ISSO/SA for a list of valid remote syslog servers justified and documented using site-defined procedures. Destination locations beginning with "@" represent log hosts. If the log host name is a local alias, such as log host, consult the "/etc/hosts" or other name databases as necessary to obtain the canonical name or address for the log host. Determine if the host referenced is a syslog host documented using site-defined procedures. If a loghost is not defined, not documented, or is commented out this is a finding.

Discussion

Unintentionally running a syslog server accepting remote messages puts the system at increased risk. Malicious syslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information in to the system's logs, or could fill the system's storage leading to a Denial of Service.

Fix Text

Change the "syslogd" arguments in the src subsystem control and restart the "syslogd" daemon using the following commands: # chssys -s syslogd -a '-R' # stopsrc -s syslogd # startsrc -s syslogd

Check Content

Verify "syslogd" is running with the "-R" option using command: # ps -ef | grep syslogd | grep -v grep The above command should yield the following output: root 4063356 3342368 0 Sep 11 - 0:01 /usr/sbin/syslogd -R If the "-R" option is not present with the syslogd process, this is a finding.

Discussion

Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Fix Text

Configure the access restriction program to log every access attempt. Ensure the implementation instructions for TCP_WRAPPERS are followed, so system access attempts are logged into the system log files. If an alternate application is used, it must support this function. Edit the "/etc/syslog.conf" file by writing the following to the file. auth.info /var/log/messages # touch /var/log/messages # refresh -s yslogd

Check Content

Normally, TCPD logs to the "mail" facility in "/etc/syslog.conf". Determine if syslog is configured to log events by TCPD. Procedure: # more /etc/syslog.conf Look for entries similar to the following: mail.debug /var/adm/maillog mail.none /var/adm/maillog mail.* /var/log/mail auth.info /var/log/messages The above entries would indicate mail alerts are being logged. If no entries for "mail" exist, then TCPD is not logging and this is a finding.

Discussion

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Fix Text

Set the owner audit configuration files to "root". # chown root /etc/security/audit/*

Check Content

Check that all the audit configuration files under /etc/security/audit/* have correct ownership. # ls -l /etc/security/audit/* -rw-r----- 1 root audit 37 Oct 10 2016 /etc/security/audit/bincmds -rw-r----- 1 root audit 2838 Sep 05 16:33 /etc/security/audit/config -rw-r----- 1 root audit 26793 Oct 10 2016 /etc/security/audit/events -rw-r----- 1 root audit 340 Oct 10 2016 /etc/security/audit/objects -rw-r----- 1 root audit 54 Oct 10 2016 /etc/security/audit/streamcmds If any file's ownership is not "root", this is a finding.

Discussion

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Fix Text

Set the group of the audit configuration files to "audit". # chgrp audit /etc/security/audit/*

Check Content

Check that all the audit configuration files under /etc/security/audit/* have group ownership. # ls -l /etc/security/audit/* -rw-r----- 1 root audit 37 Oct 10 2016 /etc/security/audit/bincmds -rw-r----- 1 root audit 2838 Sep 05 16:33 /etc/security/audit/config -rw-r----- 1 root audit 26793 Oct 10 2016 /etc/security/audit/events -rw-r----- 1 root audit 340 Oct 10 2016 /etc/security/audit/objects -rw-r----- 1 root audit 54 Oct 10 2016 /etc/security/audit/streamcmds If any file's group ownership is not "audit", this is a finding.

Discussion

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Fix Text

Change the permission of the audit configuration files to "640". # chmod 640 /etc/security/audit/*

Check Content

Check that all the audit configuration files under /etc/security/audit/* have correct permissions. # ls -l /etc/security/audit/* -rw-r----- 1 root audit 37 Oct 10 2016 /etc/security/audit/bincmds -rw-r----- 1 root audit 2838 Sep 05 16:33 /etc/security/audit/config -rw-r----- 1 root audit 26793 Oct 10 2016 /etc/security/audit/events -rw-r----- 1 root audit 340 Oct 10 2016 /etc/security/audit/objects -rw-r----- 1 root audit 54 Oct 10 2016 /etc/security/audit/streamcmds If any file has a mode more permissive than "640", this is a finding.

Discussion

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled.

Fix Text

From the command prompt, run the following script to set the default timeout parameters "dtsession*saverTimeout:" and "dtsession*lockTimeout:" as "15" minutes: for file in /usr/dt/config/*/sys.resources; do etc_file=`echo $file | sed -e s/usr/etc/` echo "\nupdating config file "$etc_file"..." if [[ ! -f $etc_file ]]; then dir=`dirname $file | sed -e s/usr/etc/` mkdir -p $dir echo 'dtsession*saverTimeout: 15' >> $dir/sys.resources echo 'dtsession*lockTimeout: 15' >> $dir/sys.resources else cp $etc_file $etc_file.bak cat $etc_file | grep -v 'dtsession\*saverTimeout:' > $etc_file.sav cat $etc_file.sav | grep -v 'dtsession\*lockTimeout:' > $etc_file echo 'dtsession*saverTimeout: 15' >> $etc_file echo 'dtsession*lockTimeout: 15' >> $etc_file fi done

Check Content

If CDE (X11) is not used on AIX, this is Not Applicable. From the command prompt, run the following script: for file in /usr/dt/config/*/sys.resources; do etc_file=`echo $file | sed -e s/usr/etc/` echo "\nChecking config file "$etc_file"..." if [[ ! -f $etc_file ]]; then echo "Missing config file "$etc_file else cat $etc_file |grep 'dtsession\*saverTimeout:' cat $etc_file |grep 'dtsession\*lockTimeout:' fi done The above script should yield the following output: Checking config file /etc/dt/config/C/sys.resources... Missing config file /etc/dt/config/C/sys.resources Checking config file /etc/dt/config/POSIX/sys.resources... dtsession*saverTimeout: 15 dtsession*lockTimeout: 30 Checking config file /etc/dt/config/en_US/sys.resources... dtsession*saverTimeout: 15 dtsession*lockTimeout: 25 If the result of the script shows any config file missing, or any of the "dtsession*saverTimeout" or "dtsession*lockTimeout" values are greater than "15", this is a finding.

Discussion

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at AIX level, and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that AIX terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Fix Text

Edit the "/etc/ssh/sshd_config" file and add or update the following lines: ClientAliveInterval 300 ClientAliveCountMax 0 Restart SSH daemon. # stopsrc -s sshd # startsrc -s sshd

Check Content

Check the SSH daemon configuration for "ClientAliveInterval" setting with the following command. # grep ClientAliveInterval /etc/ssh/sshd_config ClientAliveInterval 300 If the variable "ClientAliveInterval" is commented out or not set to "300", this is a finding. Check the SSH daemon configuration setting for "ClientAliveCountMax" setting with the following command. # grep ClientAliveCountMax /etc/ssh/sshd_config ClientAliveCountMax 0 If the variable "ClientAliveCountMax" is commented out or not set to "0" this is a finding.

Discussion

Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. If a maintenance session or connection remains open after maintenance is completed, it may be hijacked by an attacker and used to compromise or damage the system. Some maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific operating system functionality where the system owner, data owner, or organization requires additional assurance. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at AIX level, and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that AIX terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. Satisfies: SRG-OS-000279-GPOS-00109, SRG-OS-000163-GPOS-00072, SRG-OS-000126-GPOS-00066

Fix Text

Add or update the following line in the "/etc/profile" file: readonly TMOUT=600; readonly TIMEOUT=600; export TMOUT TIMEOUT

Check Content

Check if "TMOUT" and "TIMEOUT" environment variables are set to "600" (in seconds) in "/etc/profile" file: # grep -E " TMOUT|TIMEOUT" /etc/profile readonly TMOUT=600; readonly TIMEOUT=600; export TMOUT TIMEOUT If they are not set in "/etc/profile" file, are commented out, or their values are greater than "600", this is a finding.

Discussion

If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.

Fix Text

Change the permissions for the SSH private host key files: # chmod 0600 /etc/ssh/*key

Check Content

Check the permissions for SSH private host key files: # ls -lL /etc/ssh/*key The above command should yield the following output: -rw------- 1 root system 668 Jan 18 2017 /etc/ssh/ssh_host_dsa_key -rw------- 1 root system 227 Jan 18 2017 /etc/ssh/ssh_host_ecdsa_key -rw------- 1 root system 965 Jan 18 2017 /etc/ssh/ssh_host_key -rw------- 1 root system 1675 Jan 18 2017 /etc/ssh/ssh_host_rsa_key If any file has a mode more permissive than "0600", this is a finding.

Discussion

The listed applications permit the transmission of passwords in plain text. Alternative applications such as SSH, which encrypt data, should be use instead.

Fix Text

Use the chmod command to remove all permissions on these commands: # chmod ugo= /usr/bin/rcp # chmod ugo= /usr/bin/rlogin # chmod ugo= /usr/bin/rsh # chmod ugo= /usr/bin/rexec # chmod ugo= /usr/bin/telnet

Check Content

From the command prompt, execute the following commands: # ls -l /usr/bin/rcp | awk '{print $1}' # ls -l /usr/bin/rlogin | awk '{print $1}' # ls -l /usr/bin/rsh | awk '{print $1}' # ls -l /usr/bin/telnet | awk '{print $1}' # ls -l /usr/bin/rexec | awk '{print $1}' Each of the above commands should return with the following permissions: ---------- If the permissions are more permissive, this is a finding.

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify AIX or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Fix Text

Change the mode of the system log file(s) to "0640" or less permissive: # chmod 0640 /path/to/system-log-file

Check Content

Check the mode of log files: # ls -lL /var/log /var/log/syslog /var/adm /var/adm: total 376 drw-r----- 2 root system 256 Jan 24 12:31 SRC drwx------ 4 root system 256 Jan 24 07:28 config -rw-r----- 1 root system 1081 Jan 24 09:05 dev_pkg.fail -rw-r----- 1 root system 250 Jan 24 09:05 dev_pkg.success -rw------- 1 root system 64 Jan 24 09:43 sulog drwxr-xr-x 3 root system 256 Jan 24 12:28 sw drwx------ 2 root system 256 Jan 24 08:06 wpars /var/log: total 8 drwxr-xr-x 2 root system 256 Jan 24 08:44 aso -rw-r----- 1 root system 603 Jan 24 10:30 cache_mgt.dr.log If any of the log files have modes more permissive than "0640", this is a finding. NOTE: Do not confuse system logfiles with audit logs. Any subsystems that require less stringent permissions must be documented.

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify AIX or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Fix Text

Remove the extended ACL(s) from the system log file(s): # acledit <system_log_file> Set "extended permissions" to "disabled".

Check Content

With the assistance of the system administrator, identify all of the system log files. For each system log file identified, verify that extended ACL's are disabled: #aclget <system_log_file> * * ACL_type AIXC * attributes: base permissions owner(root): rw- group(system): r-- others: r-- extended permissions disabled If "extended permissions" is set to "enabled" and is not documented, this is a finding.

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

Remove the extended ACL(s) from the system command file(s) and set the extended permissions to disabled by running the following command: # acledit [command-path ]/[ command-file]

Check Content

Verify all system command files have no extended ACLs by running the following commands: # aclget /etc # aclget /bin # aclget /usr/bin # aclget /usr/lbin # aclget /usr/ucb # aclget /sbin # aclget /usr/sbin If any of the command files have extended permissions enabled, this is a finding.

Discussion

Unauthorized access could destroy the integrity of the library files.

Fix Text

Remove the extended ACL(s) from the system library file(s) and disable extended permissions using the follow script: find /usr/lib/security /usr/lib/methods/ -type f | while read file do aclget -o /tmp/111.acl $file > /dev/null 2>&1 if [ $? -eq 0 ]; then grep -e "[[:space:]]enabled$" /tmp/111.acl > /dev/null 2>&1 if [ $? -eq 0 ]; then echo "Removing ACL from "$file cat /tmp/111.acl | head -n9 > /tmp/222.acl echo " disabled" >> /tmp/222.acl aclput -i /tmp/222.acl $file fi fi done

Check Content

The following system library directories need to be checked: /usr/lib/security/ /usr/lib/methods/ Determine if any system library file has an extended ACL by running the follow script: find /usr/lib/security /usr/lib/methods/ -type f | while read file do aclget -o /tmp/111.acl $file > /dev/null 2>&1 if [ $? -eq 0 ]; then grep -e "[[:space:]]enabled$" /tmp/111.acl > /dev/null 2>&1 if [ $? -eq 0 ]; then echo "$file has ACL" fi fi done If the above script yield any output, this is a finding.

Discussion

File permissions more permissive than 0600 for /etc/news/passwd.nntp may allow access to privileged information by system intruders or malicious users.

Fix Text

Change the mode of all the found passwd.nntp files that have mode more permissive than "0600" using command: # chmod 0600 <passwd.nntp_file>

Check Content

If NNTP is not being used, this is Not Applicable. Check passwd.nntp file permissions using command: # find / -name passwd.nntp -exec ls -lL {} \; The above command may yield the following output: -rw------- 1 root system 19 Oct 16 10:46 /etc/news/passwd.nntp If a "passwd.nntp" file has a mode more permissive than "0600", this is a finding.

Discussion

The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Fix Text

Remove the extended ACL from the "/etc/group" using command: # acledit /etc/group

Check Content

Check the ACL of the "/etc/group" file: # aclget /etc/group The above command should yield the following output: * * ACL_type AIXC * attributes: base permissions owner(root): rw- group(security): r-- others: r-- extended permissions disabled If the extended ACL are not "disabled", this is a finding.

Discussion

The ldd command provides a list of dependent libraries needed by a given binary, which is useful for troubleshooting software. Instead of parsing the binary file, some ldd implementations invoke the program with a special environment variable set, which causes the system dynamic linker to display the list of libraries. Specially crafted binaries can specify an alternate dynamic linker which may cause a program to be executed instead of examined. If the program is from an untrusted source, such as in a user home directory, or a file suspected of involvement in a system compromise, unauthorized software may be executed with the rights of the user running ldd.

Fix Text

Disable the "ldd" command by removing its permissions using command: # chmod 0000 <path to ldd>

Check Content

Consult vendor documentation concerning the "ldd" command. If the command provides protection from the execution of untrusted executables, this is not a finding. Determine the location of the system's "ldd" command: # find / -name ldd If no file exists, this is not a finding. Check the permissions of the found "ldd" file: # ls -lL <path to ldd> ---------- 1 bin bin 6289 Feb 28 2017 /usr/bin/ldd If the file mode of the file is more permissive than "0000", this is a finding

Discussion

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

Fix Text

Edit "/etc/exports" and add "ro" and/or "rw" options (as appropriate) specifying a list of hosts or networks which are permitted access. Re-export the file systems: # /usr/sbin/exportfs -a

Check Content

Check the permissions on exported NFS file systems by running command: # exportfs -v /export/shared -ro,access=10.17.76.74 If the exported file systems do not contain the "rw" or "ro" options specifying a list of hosts or networks, this is a finding.

Discussion

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

Fix Text

Change the mode of interactive users' home directories to "0750" or less permissive using the following command: # chmod 0750 <home directory>

Check Content

Check the home directory mode of each interactive user in "/etc/passwd": #cut -d : -f 6 /etc/passwd | xargs -n1 ls -ld | more drwxr-xr-x 20 root system 4096 Jan 28 13:46 / drwxr-xr-x 33 root system 8192 Jan 28 13:51 /etc lrwxrwxrwx 1 bin bin 8 Jan 24 07:23 /bin -> /usr/bin drwxrwxr-x 4 bin bin 256 Mar 23 2017 /usr/sys drwxrwxr-x 15 root adm 4096 Jan 24 12:26 /var/adm drwxr-xr-x 2 root sys 4096 Jan 24 08:43 /usr/lib/uucp drwxr-xr-x 6 root system 4096 Jan 24 07:34 /var/adm/invscout drwxr-xr-x 3 ipsec ipsec 256 Jan 24 08:43 /etc/ipsec drwxr-xr-x 2 sshd system 256 Aug 11 2017 /home/srvproxy drwxr-xr-x 8 esaadmin system 256 Jan 24 09:02 /var/esa drwxr-x--- 2 doejohn staff 256 Jan 25 13:18 /home/doejohn If an interactive user's home directory's mode is more permissive than "0750", this is a finding. NOTE: Application directories are allowed and may need "0755" permissions (or greater) for correct operation.

Discussion

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

Fix Text

Remove the extended ACL from the user home directory and disable extended permissions: # acledit <directory>

Check Content

Verify user home directories have no extended ACLs using command: # cat /etc/passwd | cut -f 6,6 -d ":" | xargs -n1 aclget * * ACL_type AIXC * attributes: base permissions owner(root): rwx group(system): r-x others: r--- extended permissions disabled If extended permissions are not disabled, this is a finding.

Discussion

Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

Fix Text

Run the following command to turn on the all parts of Trusted Execution (TE): # trustchk -p TE=on CHKEXEC=on CHKKERNEXT=on

Check Content

Run the following command to show the current status of the "TE", "CHKEXEC", and "CHKKERNEXT" on the system: # trustchk -p 2>&1 | egrep -e "TE=|CHKEXEC|CHKKERNEXT" The above command should yield the following output: TE=ON CHKEXEC=ON CHKKERNEXT=ON If "TE", "CHKEXEC", or "CHKKERNEXT" is "OFF", this is a finding.

Discussion

Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Fix Text

In "/etc/inetd.conf", comment out the "tftp" entry: # chsubserver -r inetd -C /etc/inetd.conf -d -v 'tftp' -p 'udp' Restart inetd: # refresh -s inetd

Check Content

From the command prompt, execute the following command: # grep "^tftp[[:blank:]]" /etc/inetd.conf If there is any output from the command, it is a finding.

Discussion

Control of program execution is a mechanism used to prevent execution of unauthorized programs. Some operating systems may provide a capability that runs counter to the mission or provides users with functionality that exceeds mission requirements. This includes functions and services installed at AIX-level. Some of the programs, installed by default, may be harmful or may not be necessary to support essential organizational operations (e.g., key missions, functions). Removal of executable programs is not always possible; therefore, establishing a method of preventing program execution is critical to maintaining a secure system baseline. Methods for complying with this requirement include restricting execution of programs in certain environments, while preventing execution in other environments; or limiting execution of certain program functionality based on organization-defined criteria (e.g., privileges, subnets, sandboxed environments, or roles). The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. Verification of white-listed software occurs prior to execution or at system startup. This requirement applies to operating system programs, functions, and services designed to manage system processes and configurations (e.g., group policies). Satisfies: SRG-OS-000368-GPOS-00154, SRG-OS-000370-GPOS-00155

Fix Text

Run the following command to turn on Trusted Execution: # trustchk -p TE=ON

Check Content

Run the following command to show the current status of the "TE" running on the system: # trustchk -p The above command should yield the following output: TE=ON If the output is "TE=OFF", this is a finding.

Discussion

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Fix Text

Run the following command to commit any applied components: # installp -c all

Check Content

Run the following command to check any installed components that are in APPLY state: # lslpp -cl | grep :APPLIED: If the command returns any entries, this is a finding.

Discussion

Limiting the number of login attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.

Fix Text

From the command prompt, run the following command to set "logindelay=4" for the default stanza in "/etc/security/login.cfg": # chsec -f /etc/security/login.cfg -s default -a logindelay=4

Check Content

From the command prompt, run the following command to check the default "logindelay" value: # lssec -f /etc/security/login.cfg -s default -a logindelay The above command should yield the following output: default logindelay=4 If the above command displays the "logindelay" value less than "4", this is a finding.

Discussion

Configuring a supplemental group for users permitted to switch to the root user prevents unauthorized users from accessing the root account, even with knowledge of the root credentials.

Fix Text

Use the "chsec" command to only allow users in the adm group to su to root: # chsec -f /etc/security/user -s root -a sugroups=adm

Check Content

Examine the "sugroups" of the root user. Generally only users in the adm group should have su to root capacity. Run the following command: # lsuser -a sugroups root root sugroups=system,staff,security If "sugroups" is blank or "ALL", this is a finding.

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 for each GID referenced without a corresponding group by running "mkgroup" command.

Check Content

Verify that there are no GIDs referenced in "/etc/passwd" that are not defined in "/etc/group": # cut -d: -f4 /etc/passwd 0 1 2 3 4 203 204 # cut -d: -f3 /etc/group 0 1 2 3 4 203 204 If there are GID's listed in the "/etc/passwd" file that are not listed in the "/etc/group" file, this is a finding.

Discussion

Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.

Fix Text