This appendix is intended to assist AIX administrators in setting up servers and users on AIX networks. The following topics describe how server options and features should be configured to adequately secure the network.

The Trusted Computing Base ("TCB") is responsible for enforcing the information security policies of the system. AIX servers must be set up in TCB mode. The TCB Software consists of the kernel (operating system) and configuration files for controlling system functions.

The TCB function is optionally enabled at installation time. To install this function select yes on the option install TCB from the Installation and Settings menu. This function enables the trusted path, trusted shell, and system integrity checking.

The "tcbck" command audits the security state of TCB by reading the /etc/security/sysck.cfg file. This file includes a description of all TCB files, configuration files, and trusted commands.

Note: If the Installed Trusted Computing Base option was not selected during the initial installation, the tcbck command will be disabled. The command can only be enabled during a system installation. If this was not initially set, then the operating system must be reinstalled to set the command.

The tcbck command should be run to check the file system any time you suspect the system integrity might have been compromised. To do this, issue the following command:

• tcbck -t tree

Each User must be assigned a unique user ID.

Add, change or delete users using the System Manager ("SMIT") interface. This interface helps reduce possible errors that can occur when changes are executed from the command line.

The Real Name field in the /etc/passwd file should remain blank because this file is world readable.

Each user ID must have the associated user's mil name and password(s) which are contained in the /etc/passwd and /etc/security/password files.

AIX provides password restrictions that can be set by the system administrator. These allow the administrator to constrain the passwords chosen by users and to force password changes regularly. Set each user account to the following default restrictions:

• maxage: Maximum number of weeks that can pass before a password must be changed: 8
• minlen: Minimum password length must be: 6
• minalpha: Minimum number of alphabetic characters a password must contain: 1
• maxrepeats: Maximum number of times a character can appear in a password: 2
• histexpire: Number of weeks that a user will not be able to reuse a password: 52
• histsize: Number of previous passwords that cannot be reused: 6
• dictionlist: List of dictionary files checked when a password is changed: Yes (The dictionary file contains passwords that are not allowable.)
• maximum number of login attempts: This is the maximum number of login attempts a user my incorrectly try to log on to the system: 5
• password expiry warning 5 days

The root ID should have it's own home directory. Create a directory called /root and move the login files from the /home/root directory. Make sure that only the root ID can read this directory.'

Exceptions – approved by Director of IT Security

On the ADS systems, the default setting for maxage is set to zero (0). This is so that the Warehouse workers’ passwords do not expire. They do not have any admin level authority on the AIX system and password expiration handling with the guns could result in a negative impact to productivity. Additionally, to ensure 24x7 support of this critical platform, the Chicago administration team is exempt from regular password changes. All user and admin login activity is reported on, reviewed and approved monthly by the appropriate RDC and management personnel. For all other users, the maxage setting is set to 8 weeks as specified above. All other settings match the above definitions.

User passwords are located in the /etc/passwd file. This password file is encrypted, however it can still be vulnerable to hackers. If the user's actual password is left in this file it can possibly be seen by hackers using encryption tools. TCB automatically creates a "shadow" password file.

Any default IDs (like daemon, bin, adm, uucp, Ip, etc.) in the password file used for file or' process ownership should be disabled by putting an * in the password field in the shadow password file. Also, change the home directory to /dev/null.

The shadow password file:

1. Maintains encrypted passwords

2. Replaces passwords in the etc/passwd file with an "*"

3. Can be read only by root

The root ID should not have a "." in its search path. Only secured directories should be in the root ID’s search path. If system users are searching the current directory they should have the "." at the end of their search path.

Each user account has a set of default attributes that were assigned when the user was created. If there is a need to restrict a user's access with more than password restrictions, the following attributes may be changed from their default settings.

• ttys: Limits identified accounts to physically secured areas
• expires: Manages student, guest, or temporary accounts. It can also be use to turn off accounts, (ex. When a user leaves for vacation, medical leave, etc.)
• logintimes: Restricts when a user can log into the system

Access to write to user home directories must be limited only to the user.

To prevent damage from trojan horses and unauthorized changes to data and programs, files and directories should not have write permission for the group "other." The umask settings below will prevent this problem by default. However, applications and users should not change the permissions to grant write permission to the group "other."

The implemented UMASK. should be 022. This will create the following accesses:

• The default umask for directories must be set to 750, which grants access of dwrxr-x— (user - all access, group – read and execute).
• The default umask for files must be set to 640, which grants access of rw- -r- — (user - read and write, group – read only).

Each user must be required to log in to the system. The user is logged into that account, and acquires the access rights and privileges of the account. Only the system administrator should have the ability to change the system login script.

After installation of a new system, change the root password as soon as you log onto the new system. The system console should have the system key set in the normal position, and the key removed and stored in a secure location.

The cron daemon runs commands that are scheduled according to the crontab file entries. This command should be limited to root, system administrators, and key personnel which specifically require this access only.

To prevent access to the crontab command, use the cron.allow file. The cron.allow file only allows users whose login name appears in this file to use the crontab command. The cron.deny file should be deleted.

The root ID must only be accessed from the system console or remote system administrators.

Direct login as the root ID should only be performed in an emergency. Normal security and system administration should be performed by switching user to root by using the "su" command. This will associate the use of root capabilities to a specific user ID.

The original operating system diskettes/CDs must be stored in a secure location, separate from the ADC server. (A locked drawer near the server would also suffice.) This will prevent unauthorized personnel from restarting AJX from the operating system disks.

Only system administrators should be able to boot the system in single user mode (run-level = S).

Setuid programs can be exploited by hackers. (A setuid to root program would grant the user root access.) Do not add additional setuid programs to a trusted system unless business software requires such programs. All existing setuid programs must be secured so that only the administrator has write access.

Key system directories and files must be configured to restrict access to the maximum extent possible without adversely affecting operations. The following list contains the major sub-directories of the root system with the recommended access settings:

drwx r-x - -x root system /

dr-x r-x - -x root system /etc

dr-x r-x - -x root system /dev

dr-x r-x - -x root sbin /sbin

dr-x r-x - -x root bin /usr/bin

dr-x r-x - -x root sbin /usr/sbin

AIX trusted systems allow auditing to help administrators detect and analyze security breaches. Administrators should log failed login attempts, failed security updates, off-hour access attempts, failed system file access attempts, root ID and Security Administrator ID activity when reviewing the logs.

Audit log files must be maintained for 6 months to comply with standards. Due to the size of audit logs, the administrator should consider keeping the online log for 24 hours and retain the other audit records offline.

Remote access should be tightly controlled. The rlogin command allows the local host to connect to a remote host. The rexec command makes it possible to execute commands interactively, on a remote host when logged in using riogin. The rsh and remsh commands make it possible to execute batch commands on the remote host when logged in using riogin. The riogin command is considered a non-trusted command and should be disabled unless it is specifically needed.

If remote access is not needed for a server, the "r" services (such as riogin, remsh, rexec and rsh) should be disabled. If remote access is required, tight controls must be applied to the /etc/hosts.equiv, $HOME/.rhosts and $HOME/.netrc files.

Maintain a copy of the following items at the offsite storage location as defined in the Disaster Recovery Standards:

• Operating system diskettes, CDs or tapes
• Either a tape containing 'savevg' (smit savevg) information or documentation detailing disk allocation, volume group, logical volume and jfs information
• Backup/restore tape software
• At least two of the most recent full system backups (no more than 1 week old)
• Incremental backups performed since the full system backup
• Access/override codes to restore on foreign CPU