Implementing and Maintaining AIX Security Policies

{LANG_NAVORIGIN} Operating System
Andre Derek Protas 03/25/2005

Security Policy

A server has many types of security features implemented. There are two main approaches for stopping intruders and exploits: security policy to maintain the integrity of the system and server hardening features to avoid malicious penetrations and exploits. Both are equally important but separate fields. Security policies (like all features of security) must be universally applied to the entire subnet, if not the entire network. By ensuring that all possible nodes are secure, the likelihood of intrusion is substantially decreased.

Hardware Passwords

• Summary:
  • Booting from CD is a very powerful tool, especially when diagnosing problems with a system. But, there has been new technology with boot CD’s that allow root access to any machine that is booted from it. These CD’s commonly run a version of Linux that is loaded on a ram-drive. Many times rootkits (hacking tools) come precompiled.
• Reference:
  • www.knoppix.net
• Default Security:
  • None
• Standard Security:
  • BIOS Password: Configuring the BIOS should only be done by administration. Ensure that boot from CD is disabled.
• Enhanced Security:
  • Power-On Password: With the threat of Live CD’s (Knoppix), systems should not be turned on unless proper authorization is given. These live CD’s load into a RAM drive and boot off of that drive. They leave no trace, and immediately grant root access to any of the mounted drives. If a person had physical access to a computer, all it takes is a Live CD in the system when it is booting and that person now has root access no matter what other security features may have been implemented.

Login Control

• Summary:
  • Numerous setting are supplied and can be tailored to the desired security level. The following are the most important values to edit:
    • sak_enabled: Setting this value to true will require that a certain key sequence (CTRL+X then CTRL+R) is required prior to opening up secure communication. This is similar to the windows “CTRL+ALT+DEL” sequence necessary to login.
    • -logintimes: Specifies certain login times (throughout the day) that a user can login.
    • -logindisable: Set to the number of times a bad password is received before that login is rejected.
    • -logininterval: Specifies the amount of time given for login disable. For instance, if set to a minute, and logindisable is set to 4. If, within 1 minute, there are 4 bad logins, the account will be disabled.
    • -loginreenable: Time until the user login is reenabled.
    • -logindelay: Great way to combat DoS or brute force attacks. If set to 5, after the first login, the terminal will wait 5 seconds until the next request. If another failed login, the terminal will wait 5*2 seconds. If a third failed login, 5*3 seconds. Each time the user on the other end is having to wait longer and longer, which will tend to frustrate programs such as L0phtcrack or John the Ripper.
• Location of File
  • /etc/security/login.conf
• Reference:
  • AIX Security Manual (page 17)
• Default Security:
  • sak_enabled: false
  • logintimes: none
  • logindisable: 0
  • logininterval:0
  • loginreenable: 0
  • logindelay: 0
• Standard Security:
  • sak_enabled: false
  • logintimes: none
  • logindisable: 4
  • logininterval:60
  • loginreenable: 30
  • logindelay: 5
• Enhanced Security:
  • sak_enabled: true
  • logintimes: specified values
  • logindisable: 3
  • logininterval: 300
  • loginreenable: 360
  • logindelay: 10

System Resource Control

• Summary:
  • Poorly written code (or perhaps well written code if there is malicious intent) many times will use a process that drains the CPU and paging resources. By calling this process over and over, the CPU and paging are increased so high that connections start to become lost with other processes, possibly resulting in DoS. System resource control is used to restrict the CPU and paging resources from becoming too heavily burdened. There is a hard limit and a soft limit. The user has control of reducing both limits, but only increasing the soft limit to the hard limit threshold. The hard limit may only be increased by the root user.
• Location of File:
  • /etc/security/limits.
• Reference:
  • AIX Security Supplement (page 146).
• Default Security:
  • The AIX Environment already has decent sized hard limits implemented.
• Standard Security:
  • Change the system resource limits so that users are only limited to the resources they need, as well as ensuring that services do not exceed their expected limits of resources.

Global .profile Files

• Summary:
  • A standard .profile file can be used to describe a $PATH other than what is valid. This can be especially dangerous for users with higher privelages. Because of this, system administrators are urged to create protected .profile files for their users. These files should only be writeable by root to protect them from being tampered with.
• Location of File:
  • /etc/security/.profile (for root)
  • $HOME/.profile (for each user)
• Reference:
  • AIX Security Manual (page 18)
• Default Security:
  • User configurable .profile.
• Standard Security:
  • Global .profile files for users based upon their groups to ensure that $PATH stays valid.
• Enhanced Security:
  • Enforce automatic logoff in .profile security file. By ensuring automatic logoff, idle sessions will be terminated. Suggestion: 10 minute automatic logoff period.
  • Append: TMOUT = 600; TIMEOUT = 600; export readonly TMOUT TIMOUT.

Password Strengthening

• Summary:
  • A week password can be broken via brute-force attacked very quickly. The proper precautions are necessary to ensure that all passwords created are strong enough to last through a brute-force attack until the terminal is logged off. The following variables may be configured:
    • dictionlist: Verifies passwords do not include certain strings.
    • maxrepeats: Maximum number of characters that can be repeated in passwords.
    • maxexpired: Maximum number of weeks beyond maxage that an expired password can be changed by the user.
    • maxage: Maximum number of weeks beyond maxage that an expired password can be changed by the user.
    • histsize: Number of password iterations allowed.
    • histexpire: Number of weeks before password can be reused.
• Location of File:
  • /etc/security/user
• Reference:
  • AIX Security Manual (page 39)
• Default Security:
  • dictionlist: NA
  • maxrepeats: 8
  • maxexpired: -1
  • maxage: 0
  • histsize: 0
  • histexpire: 0
• Standard Security:
  • dictionlist: NA
  • maxrepeats: 4
  • maxexpired: 4
  • maxage: 16
  • histsize: 20
  • histexpire: 26
• Enhanced Security:
  • dictionlist: /usr/share/dict/words
  • maxrepeats: 2
  • maxexpired: 2
  • maxage: 4
  • histsize: 20
  • histexpire: 52

No null Passwords

• Summary:
  • Passwords have the ability to be null if the user decides not to use one. This is a very dangerous practice and can easily lead to exploitation. Also, some of the standard users (pre-installed) do not have passwords. These should either be removed (refer to “Unnecessary Accounts”) or should be forced to have an associated password.
• Location of File:
  • /etc/passwd
• Reference:
  • Is Your AIX Environment Secure?, Shiv Dutta
• Default Security:
  • None. The system does not force the use of a password.
• Standard Security:
  • Use a script to check for null passwords in the password file.
    • awk -F: '{if ($2 == "") print $1}' /etc/passwd
• Enhanced Security:
  • Enforce the previous command in a crontab to be implemented daily.
  • Daily review the logs of the script from the crontab to ensure that there are no null passwords.

Physical Security

• Summary:
  • Typical physical security measures must be maintained. Servers should always be locked up and users should only have access to the servers they must have access to. Having monstrous server rooms with an insecure door is a deathtrap. Also, magnetic-badge locks must be implemented on every possible access to a server room. There should also be human-monitoring systems on all entrances and the server room itself (either camera or person).
• Reference:
  • The Art of Deception, Kevin Mitnick
• Standard Security:
  • Badge readers, camera installations, human surveillance.
• Enhanced Security:
  • Biometrics.
  • www.thumbdrive.com/productinfo.htm

wall

• Summary:
  • The wall command can be used to broadcast text to all users that are logged in. This could also possibly used as a social engineering tool for those who are unfamiliar with the wall command.
• Location of File:
  • /bin/wall
• Reference:
  • AIX Security Supplement (p 135)
• Default Security:
  • None. The system does not secure the wall command.
• Standard Security:
  • Ensure the wall command is only executable by the administration group.

Trusted Computing Base

• Summary:
  • By using the TCB, the root user is able to designate use of the trusted communication path to ensure that only verified users are using those programs in the TCB. The TCB must be installed during the original configuration (cannot be added after install).
• Location of File:
  • /etc/security/sysck.cfg
• Reference:
  • AIX Security Manual (page 3)
  • http://www.unet.univie.ac.at/aix/aixbman/admnconc/tcb.htm
• Default Security:
  • The TCB will not be installed automatically when installing the AIX operating system.
• Standard Security:
  • Configure the TCB (with all options) on the initial Base Operating System (BOS) installation.
• Enhanced Security:
  • Thoroughly audit all of the programs to be put into the TCB. Ensure that sensitive programs are placed here, and any exploitable programs are not. Run Tripwire on the /etc/security/sysck.cfg to ensure the file is not tampered with.

User Control Admin

• Summary:
  • There should be two administrators (plus root) that should be allowed to change users. By allowing two administrators besides root (redundancy), root access is no longer necessary to change/make users. The less often root is used, the better, as it has full control and can be very detrimental to a machine if used inproperly.
• Location of Files:
  • /etc/security/user
  • /etc/security/limits
  • /etc/security/audit/config
  • /etc/security/lastlog
• Reference:
  • AIX Security Manual (page 27)
• Default Security:
  • Root access is required each time user updating is necessary.
• Standard Security:
  • Create two administrative users that have control over the users. These administrators should not have access to any other root permissions, just the user control.

Distributed Authority

• Summary:
  • Many times root access is overused. Root, the all powerful superuser, should only be used in times where multipermission access is necessary. It should not have to be used every time a CD needs to be mounted, or a common script to be run. The more people that use and know the password to root, the higher the possibility of unauthorized activities. Root should be kept as secure as possible by a senior administrator.
  • Separate users should share the power of root. For instance, one user could be the user for making other users. Another user could be the authority when it comes to changing file permissions. By having these jobs segregated, a typical user, if granted access to one of these other accounts for necessity, will not gain root access.
• Location of File:
  • /etc/security/user
• Default Security:
  • root access or nothing.
• Standard Security:
  • Three separate users to break root authority into three sections. One for user control, one for file-system maintenance, and another for other typical commands (such as mount). These accounts should be dispersed to different administrators to maintain checks and balances.
• Enhanced Security:
  • Create more accounts with certain root privileges. The more accounts with root-type permissions for certain aspects of the system, the better. That ensures that not one account has full permissions (unless root is necessary).

Your IP address will be sent with this e-mail

From e-mail to e-mail