[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

Security Guide

Login Control

Potential hackers can get valuable information from the default AIX login screen, such as the host name and the version of the operating system. This information would allow them to determine which exploitation methods to attempt. For security reasons you may want to change the login screen defaults as soon as possible after a system installation. This section discusses the following topics:

The KDE and GNOME desktops share some of the same security issues. For more information about KDE and GNOME, refer to the AIX 5L Version 5.2 Installation Guide and Reference.

For information about users, groups, and passwords, refer to the Users, Roles, and Passwords chapter.

Setting Up Login Controls

Set up login controls in the /etc/security/login.cfg file to make it harder to attack a system with password guessing as follows:

Table 4. Attributes and Recommended Values for the /etc/security/login.cfg file.
Attribute Applies to PtYs (Network) Applies to TTYs Recommended Value Comments
sak_enabled Y Y false The Secure Attention key is rarely needed. See Using the Secure Attention Key.
logintimes N Y Specify allowed login times here.
logindisable N Y 4 Disable login on this terminal after 4 consecutive failed attempts.
logininterval N Y 60 Terminal will be disabled when the specified invalid attempts have been made within 60 seconds.
loginreenable N Y 30 Re-enable the terminal when it was autmatically disabled after 30 minutes.
logindelay Y Y 5 The time in seconds between login prompts. This will be multiplied with the number of failed attempts, for example 5,10,15,20 seconds when 5 is the initial value.

Be aware, that these port restrictions work mostly on attached serial terminals, not on pseudo-terminals used by network logins. You can specify explicit terminals in this file, for example:

/dev/tty0:
        logintimes = 0600-2200
        logindisable = 5
        logininterval = 80
        loginreenable = 20

Changing the Login Screen Welcome Message

To prevent displaying certain information on login screens, edit the herald parameter in the /etc/security/login.cfg file. The default herald contains the welcome message that displays with your login prompt. To change this parameter, you can either use the chsec command or edit the file directly.

The following example uses the chsec command to change the default herald parameter:

# chsec -f /etc/security/login.cfg -a default -herald 
"Unauthorized use of this system is prohibited.\n\nlogin: "

For more information about the chsec command, see the AIX 5L Version 5.2 Commands Reference, Volume 1.

To edit the file directly, open the /etc/security/login.cfg file and update the herald parameter as follows:

default:
herald ="Unauthorized use of this system is prohibited\n\nlogin:"
 sak_enable = false
 logintimes = 
 logindisable = 0
 logininterval = 0
 loginreenable = 0
 logindelay = 0
Note
Set the logindisable and logindelay variables to a number greater than 0 (# > 0) to make the system more secure.

Changing the Common Desktop Environment Login Screen

This security issue also affects the Common Desktop Environment (CDE) users. The CDE login screen also displays, by default, the host name and the operating system version. To prevent this information from being displayed, edit the /usr/dt/config/$LANG/Xresources file, where $LANG refers to the local language installed on your machine.

In our example, assuming that $LANG is set to C, copy this file into /etc/dt/config/C/Xresources. Next, open the /usr/dt/config/C/Xresources file and edit it to remove welcome messages that include the host name and operating system version.

For more information about CDE security issues, see Managing X11 and CDE Concerns.

Tightening System Default Login Parameters

Edit the /etc/security/login.cfg file to set up base defaults for many login parameters, such as those you might set up for a new user (number of login retries, login re-enable, and login internal).

Securing Unattended Terminals

All systems are vulnerable if terminals are left logged in and unattended. The most serious problem occurs when a system manager leaves a terminal unattended that has been enabled with root authority. In general, users should log out any time they leave their terminals. Leaving system terminals unsecure poses a potential security hazard. To lock your terminal, use the lock command. If your interface is AIXwindows, use the xlock command.

Enforcing Automatic Logoff

Another valid security concern results from users leaving their accounts unattended for a lengthy period of time. This situation allows an intruder to take control of the user's terminal, potentially compromising the security of the system.

To prevent this type of potential security hazard, you can enable automatic logoff on the system. To do this, edit the /etc/security/.profile file to include an automatic logoff value for all users, as in the following example:

TMOUT=600 ; TIMEOUT=600 ; export readonly TMOUT TIMEOUT

The number 600, in this example, is in seconds, which is equal to 10 minutes. However, this method will only work from the shell. If the user is in a application, for example vi, this will not work.

While the previous action allows you to enforce an automatic logoff policy for all users, system users can bypass some restrictions by editing their individual .profile files. To completely implement an automatic logoff policy, take authoritative action by providing users with appropriate .profile files, preventing write-access rights to these files.

Managing X11 and CDE Concerns

This section discusses potential security vulnerabilities involved with the XII X server and the Common Desktop Environment (CDE).

Removing the /etc/rc.dt File

Although running the CDE graphical user interface (GUI) is convenient for users, security issues are associated with it. For this reason, do not run CDE on servers that require a high level of security. The best solution is to avoid installing CDE (dt) file sets. If you have installed these file sets on your system, consider uninstalling them, especially /etc/rc.dt script, which starts CDE.

For more information about CDE, see the AIX 5L Version 5.2 System Management Guide: Operating System and Devices.

Preventing Unauthorized Monitoring of Remote X Server

An important security issue associated with the X11 server is unauthorized silent monitoring of a remote server. The xwd and xwud commands can be used to monitor X server activity because they have the ability to capture keystrokes, which can expose passwords and other sensitive data. To solve this problem, remove these executable files unless they are necessary under your configuration, or, as an alternative, change access to these commands to be root only.

The xwd and xwud commands can be found in the X11.apps.clients file set.

If you do need to retain the xwd and xwud commands, consider using OpenSSH or MIT Magic Cookies. These third-party applications help prevent the risks that are created by running the xwd and xwud commands.

For more information on OpenSSH and MIT Magic Cookies, refer to each application's respective documentation.

Enabling and Disabling Access Control

The X server allows remote hosts to use the xhost + command to connect to your system. Ensure that you specify a host name with the xhost + command, because it disables access control for the X server. This allows you to grant access to specific hosts, which eases monitoring for potential attacks to the X server. To grant access to a specific host, run the xhost command as follows:

# xhost + hostname

For more information about the xhost command, see the AIX Commands Reference, Volume 6.

Disabling User Permissions to Run the xhost Command

Another way to ensure that the xhost command is being used appropriately is to restrict execution of this command to super user authority only. To do this, use the chmod command to change the permissions of /usr/bin/X11/xhost to 744.

chmod 744/usr/bin/X11/xhost

Ensure that you specify a host name with the xhost command because it disables access control for the X server. This allows you to grant access to specific hosts, which eases monitoring for potential attacks to the X server.

If you do not specify a host name, access will be granted to all hosts.

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]