"Best Practice" Standard for IBM AIX
This document describes minimum recommended configuration
settings for IBM AIX to reduce risk of
inadvertent or unauthorized access and configuration modification.
Get the latest copy from the
Best Practice Standards homepage.
- This standard applies to all IBM AIX systems
within the Organization.
- This standard applies to all employees, contractors, consultants,
temporaries, and other employees at the Organization.
- This standard applies to all Organization locations, divisions,
subsidiaries and affiliates.
The following processes and procedures are outside of the current document scope:
- Change Management process
- Account Management process
- Patch Management process
- Release Management process
- Physical Security
Any exceptions to this standard must be approved by the IT Manager and documented.
- Controls provide reasonable assurance that logical access to the system is only granted to properly authorized individuals.
- Controls provide reasonable assurance that logical access controls prevent inadvertent or unauthorized use of the system .
- Controls provide reasonable assurance that logical access to systems is monitored and misbehavior activity will be detected and reported.
Background/Description:
The latest NOS from the vendor contains necessary feature
improvements and security fixes. However, keeping the production servers
up-to-date with NOS without proper testing may affect application and
service availability. Also, additional cost may be involved to purchase
new license. Thus, it requires additional intensive testing and owner's approval.
The production version may be not the latest one but should be reasonably recent.
Expected result:
Since August 2004 IBM released AIX 5L 5.3
(version checked on Feb 2006).
Related Risk:
Low
Impact:
Outdated NOS may have "well-known" vulnerabilities or
security feature limitations. Often vendor discontinues supporting an
outdated NOS. However, keeping the production servers
up-to-date with NOS without proper testing may affect application and
service availability. Also, additional cost may be involved to purchase
a new license. Thus, it requires additional intensive testing and owner's
approval. The production version may be not the latest one but should be
reasonably recent.
Recommendations:
Consider NOS upgrade.
Manual Assessment:
Use command: uname -v.
Background/Description:
IBM provides maintenance packages every four to six month with
problem specific fixes and critical fixes. Thus, applying of such updates
will increase system availability and protection. However, these updates
should be intensively tested first for compatibility with installed
applications and current system configuration as well as approved by the
system owner. Thus, the installed patches and hot-fixes may be not the
latest ones but reasonably recent.
Warning: some patches re-enable default configuration. So, perform
security hardening verification and hardening after patch installation.
Expected result:
Check the
IBM web site for the latest AIX Maintenance Level (ML)
(updates are too frequent for automated verification).
Test requires manual verification:
Verify the latest maintenance level from the IBM web site
Related Risk:
Medium
Impact:
Outdated NOS may have "well-known" vulnerabilities or
security feature limitations. Often vendor discontinues supporting an
outdated NOS. However, keeping the production servers
up-to-date with NOS without proper testing may affect application and
service availability. Also, additional cost may be involved to purchase
a new license. Thus, it requires additional intensive testing and owner's
approval. The production version may be not the latest one but should be
reasonably recent.
Recommendations:
Review and install the latest patches and fixes recommended by the vendor.
Manual Assessment:
To determine the maintenance level use command: oslevel -r.
Background/Description:
User ID equal to 0 gives unlimited access to all system resources.
Usually, root is the most protected account with highest administrative privileges.
But these privileges are granted by UID=0. So, if other account, with less protection,
has the same level of privileges, an attacker may use this account to obtain highest
administrative privileges to the system.
If root-equivalent account is required, it should be approved by management and documented.
Expected result:
Only root has UID=0.
Related Risk:
Medium
Impact:
Accounts with UID=0 may be used by an attacker to obtain administrative
privilege access to the system.
Recommendations:
Review and remove unnecessary privileges.
Manual Assessment:
Check /etc/passwd for other accounts with UID=0
(third field in the file /etc/passwd).
Or use command:
$awk -F: '$3==0 {print $1}' /etc/passwd
Background/Description:
Usually, only root has highest administrative privileges on the system.
Remote access to the root account should be restricted to prevent remote password guessing
attacks and track who used the account. So, the root account should be available only from
a console, or other user could switch to it using the "su" command.
Warning: Tested configuration affects only commands telnet and
rlogin. Restricting remote root access over other protocols such as
SSH could be different.
Expected result:
Remote access to root is restricted (rlogin=false).
Related Risk:
Medium
Impact:
1. Remote password guessing attack could be initiated against the root account.
2. There will be no accountability for authorized administrators on who used the root account.
Recommendations:
Restrict access to root to a console only and "su" command.
Manual Assessment:
In the file /etc/security/user for root's stanza should
contain attribute "rlogin=false".
Background/Description:
For IBM AIX you can specify special list of groups which are
allowed switch to root using "su" command. Only system administrators
should be members of such groups. Possible values: a list of valid
groups separated by commas, ALL, or *.
Expected result:
Only one group is authorized switch ("su") to root. Members of
this group are authorized system administrators.
Test requires manual verification:
Verify that only authorized system
administrators are members of this group(s).
Related Risk:
Medium
Impact:
Without proper restriction any local AIX account may switch ("su")
to root. Or local password guessing attack could be initiated against
the root account.
Recommendations:
Restrict "su" rights only to a special group. Only authorized system
administrators should be members of this group.
Manual Assessment:
In the file /etc/security/user root's stanza should
have an attribute "sugroups=group_name".
Background/Description:
Group "security" has special advanced account management privileges.
Members of this group should be only authorized individual with related job requirements.
Expected result:
All members of the group are authorized and have relevant job requirements.
Test requires manual verification:
Verify that only authorized individuals are members of group 'security'
Related Risk:
Medium
Impact:
Unauthorized person obtains excessive account administration
rights through group membership. These rights could be abused.
Recommendations:
Only authorized individuals should be member of group 'security'.
Manual Assessment:
Check group members in the file /etc/group.
Background/Description:
IBM AIX allows to set specific user account settings such as password length to each account.
Forcing users to change passwords frequently (quarterly, monthly or even more often) ensures that a valid password in the wrong hands will eventually become unusable.
Expected result:
"Best practice" account settings are:
Minimum password length (characters) - minlen = 6
Password must meet complexity requirements - minalpha = 1, minother = 1
Maximum password age (weeks) - maxage = 6
Minimum password age (weeks) - minage = 1
The number of invalid login attempts before a user is not allowed to login - loginretries = 5
Number of previous passwords which cannot be reused - histsize = 5
Default file permission - umask = 027
Test requires manual verification:
yes
Related Risk:
Medium
Impact:
Unauthorized person could obtains access to the system using password setting weaknesses
or a dictionary attack.
Recommendations:
Update account settings for user account.
Manual Assessment:
Check account settings in the file /etc/security/user.
Background/Description:
All accounts should have meaningful description for better account management
and housekeeping.
Expected result:
All enabled accounts have meaningful description for better account
management and housekeeping.
Related Risk:
Housekeeping
Impact:
Account description improves account management and auditing.
Recommendations:
Update description for identified accounts.
Manual Assessment:
Check account description in the file /etc/passwd.
Background/Description:
IBM AIX has build-in integrity checking programs such as usrck,
pwdck, grpck and tcbck. On a well maintained
system this programs should show no warnings.
Expected result:
No account integrity warnings.
Related Risk:
Housekeeping
Impact:
These warnings are a sign of account management inconsistency.
Recommendations:
Review output of commands usrck, pwdck,
grpck and tcbck and address these warnings.
Manual Assessment:
Review output of commands usrck, pwdck,
grpck and tcbck.
Background/Description:
Critical UNIX files should be protected from unauthorized access and modification.
Correct permission or access rights (list, read, write, execute) should be granted to owner,
group and special group "everyone". The special group "everyone" represents all valid accounts
on the UNIX system.
Expected result:
The following settings are expected:
Related Risk:
Medium
Impact:
Improper permission may give unauthorized access to critical security files.
Recommendations:
Verify permission and set it up as per vendor recommendations and best security practices.
Manual Assessment:
Check file permission on specified files with command ls -al.
Background/Description:
The file /etc/hosts.equiv can be used by the system administrator to indicate
trusted hosts. Each trusted host is listed in the file, one host per line. If a user attempts to remotely
log in (using rlogin) or execute a command (using rsh) from one of the systems listed in hosts.equiv, and
that user has an account on the local system with the same login name, access is permitted without requiring
a password.
When a new Unix system is installed, the default /etc/hosts.equiv file should be deleted unless
it is actually required and approved by the IT Manager.
Residual risk will be reduced if the file is empty.
Expected result:
There is no file /etc/hosts.equiv on the system.
Related Risk:
Low
Impact:
Unauthorized person could access the system from a trusted host. If a user attempts to remotely
log in (using rlogin) or execute a command (using rsh) from one of the systems listed in hosts.equiv, and
that user has an account on the local system with the same login name, access is permitted without requiring
a password.
Recommendations:
Delete the file /etc/hosts.equiv.
Manual Assessment:
Check the file /etc/hosts.equiv using command cat /etc/hosts.equiv.
Background/Description:
Sometimes files hosts.equiv are stored in different places on the system.
These files do not create a direct risk of a trusted host access, but is not a good system housekeeping practice.
It is recommended to remove such files.
Expected result:
There are no hosts.equiv files on the system.
Related Risk:
Housekeeping
Impact:
Unauthorized person may see trusted host setting from such files and use this information for further attacks.
Also, it is not a good system housekeeping practice to keep these files on a system.
Recommendations:
Delete identified files hosts.equiv.
Manual Assessment:
Search for files hosts.equiv using command find / -name 'hosts.equiv' -exec ls -l {}.
Background/Description:
A user configurable file $HOME/.rhosts is similar to /etc/hosts.equiv and
lists all of the hosts which are to be implicitly trusted by the local host. This file is located in the
user`s home directory. This file is consulted by the r-commands (rlogin, rsh, rcp and rcmd). If a user attempts to remotely
log in (using rlogin) or execute a command (using rsh) from one of the systems listed in .rhosts, and
that user has an account on the local system with the same login name, access is permitted without requiring
a password.
Expected result:
There are no .rhosts files on the system.
Related Risk:
Low
Impact:
Unauthorized person could access the system from a trusted host. If a user attempts to remotely
log in (using rlogin) or execute a command (using rsh) from one of the systems listed in .rhosts, and
that user has an account on the local system with the same login name, access is permitted without requiring
a password.
Recommendations:
Remove files .rhosts.
Manual Assessment:
Find .rhosts files using command find / -name '.rhosts' -print.
Background/Description:
A user file $HOME/.netrc is similar to $HOME/.rhosts.
It may be created by any user in his or her home directory. This file allows certain users
to connect to your host with
ftp or rexec without supplying a password.
Expected result:
There are no .netrc files on the system.
Related Risk:
Low
Impact:
Unauthorized person could access the system from a trusted host. Users
to connect to your host with ftp or rexec
without supplying a password.
Recommendations:
Remove files .netrc.
Manual Assessment:
Find .netrc files using command find / -name '.netrc' -print.
Background/Description:
Unnecessary network services could be a remote entry point to an unauthorized person due to
improper configuration or known vulnerabilities. Best industry practices recommend disabling all unnecessary
services such as rusersd, rstatd, rwalld, shell, comsat, tftp, netstat, login, talk, finger, time, exec,
uucp, sysstat, echo, name, discard, daytime, chargen, sprayd, and bootps.
Note: This test reviews enabled
services only in /etc/inetd.conf. Other unnecessary services could be enabled using different options.
Expected result:
Only authorized network services are running.
Test requires manual verification:
yes
Related Risk:
Medium
Impact:
Unauthorized person could access the system via improper configured or vulnerable network services.
Recommendations:
Disable all unnecessary network services.
Manual Assessment:
Check list of enabled network services in the file /etc/inetd.conf and verifying
output of the command netstat -an.
Background/Description:
UDP echo and chargen network services could be misused to launch a
well known "UDP Flood" Denial-of-Service (DoS) attack. To initiate the attack an attacker sends a spoofed
package on the internal network to a broadcast address using echo or chargen ports or to two hosts looping
these network services. See more details at CERT Advisory CA-1996-01 - "When a connection is established between two UDP services,
each of which produces output, these two services can produce a very high number of packets that can lead
to a denial of service on the machine(s) where the services are offered. Anyone with network connectivity
can launch an attack; no account access is needed.
For example, by connecting a host's chargen service
to the echo service on the same or another machine, all affected machines may be effectively taken out of
service because of the excessively high number of packets produced. In addition, if two or more hosts are
so connected, the intervening network may also become congested and deny service to all hosts whose traffic
traverses that network."
Note: This test checks UDP echo and chargen services only in /etc/inetd.conf.
These services could be enabled using other options.
Expected result:
UDP echo and chargen services are not enabled.
Related Risk:
Medium
Impact:
UDP echo and chargen services could be used to launch a well-known Denial-of-Service (DoS) attack.
Anyone with network connectivity can launch an attack; no account access is needed.
Recommendations:
Disable all unnecessary network services.
Background/Description:
If a user or group account was deleted on a UNIX system, it is possible that some files
owned by this user or group become orphans. If a new user/group will be created with same UID/GID, these
files will become accessible by this new account. Thus, confidential information may become available for
an unauthorized person.
Expected result:
There are no files without owner/group on the system.
Related Risk:
Housekeeping
Impact:
Newly created user ID/group with same UID/GID as for these orphan files may have access to them.
Recommendations:
Assign files without owner/group to a valid user/group based on job requirements.
Manual Assessment:
Find files without owner/group using command
find / \( -nouser -o -nogroup \) -type f -exec ls -l {} \;.
Background/Description:
Files with "world-write" permission could be changed by anyone with a logon privileges on the system.
These files could include logs, executable programs and scripts, data, etc. Often this happened because of
wrong UMASK settings. There is a well known unauthorized privilege escalation when an attacker modifies a
world-writable script to run a malicious program or obtain higher privileges.
Expected result:
There are no world-writable files on the system.
Test requires manual verification:
yes
Related Risk:
Medium
Impact:
An attacker could modify a world-writable script to run a malicious program or obtain higher privileges
or modify a log file to hide unauthorized activity.
Recommendations:
Remove "world-write" permission from files.
Manual Assessment:
Find world-writable files using command
find / -perm -0002 -type f -exec ls -l {} \;.
Background/Description:
An *nix system could be configured to log important system messages locally or remotely.
These messages could be used for troubleshooting or security investigation and damage assessment in an event
of a security incident. Regular review of system messages is crucial for the security and health conditions
of a system. The main configuration file is /etc/syslog.conf. This file specifies rules for logging.
Every rule consists of two fields, a selector field and an action field.
Expected result:
Logging is enabled.
Test requires manual verification:
yes
Related Risk:
Medium
Impact:
Lack of logging of important system events prevents from ability to perform troubleshooting or
investigate a security incident.
Recommendations:
Enable system logging to a local and remote systems to preserve integrity of logs.
Manual Assessment:
Verify rules in the file /etc/syslog.conf. Lines starting with a hash mark ("#")
are comments and should be ignored.