Painless AIX

John E. Canavan

For the novice system administrator or someone just learning UNIX, the topic of AIX system security can be somewhat intimidating. AIX is such a robust, but complex, operating system that it takes time to fully comprehend its capabilities and inner workings. However, there are measures that even the beginning administrator can take to strengthen the security of any AIX system. Because of AIX's unique design, many of these measures are easily implemented and don't require a great deal of knowledge. The measures described below are rudimentary and are not to be considered all-inclusive, but they are a good starting point.

Restricting Root

One of the things that system administrators fear most is a cracker gaining root access to a system over the network. AIX's design makes it very easy to prevent this. This is done through the AIX System Management Interface Tool (SMIT). SMIT allows users to perform system administration and management commands without having to know the command-line syntax. Using the SMIT interface (which is a hierarchy of menus) information is entered into several options. The dialog then executes a shell script to perform the system management function. With SMIT, you can assign attributes that control the environment for a particular account, when it logs into the system. For example, by using SMIT you can restrict the ability of an account to rlogin or su. You can also prevent someone from gaining access over the network to accounts such as root by restricting the ability to log into the root account to specific devices.

Using the SMIT utility, you can restrict the root account to specific tty devices. The steps to restrict the root account are as follows:

1. Go into SMIT by typing in the command smit.
2. Select the "Security & Users" option.
3. Select the "Users" option.
4. Select "Change/Show Characteristics of a User".

You will then need to provide an account name. Enter the account name root. A menu listing will then display the attributes of the root account. Arrow down the list until you reach the attribute Valid TTYs. In the field to the right, you would enter the valid ttys for the root account. For example, /dev/tty0,/dev/tty1 could be entered in the field. That would require anyone who wanted to log into the root account to use either tty0 or tty1. Once you have entered the tty devices that you wish to restrict the root logins to, press F10 to exit.

By restricting the root account in this way, even if someone had access to root's password, they could not login to the root account if they didn't have physical access to the specific tty devices. They certainly couldn't login over a network connection. Restricting the root account to specific tty devices also prevents someone from using the su command to switch to the root account. One of the nice things about this configuration is that if someone tries to login to the root account over the network, they won't get any descriptive error message. It will simply appear as if they've entered an incorrect password.

There is a tradeoff here between convenience and security. Restricting root login to specific tty devices means you must have a serial connection to those devices. This can be an inconvenience if you are not at one of those specified devices and you need root access to your system. However, I think the fact that no one else can get root access to the system without access to those specific devices is a security measure worth the inconvenience.

failedlogin File

Another simple measure you can take is monitoring the failedlogin log file that normally resides in the /etc/security directory. This log will display every failed attempt to log into the system. The log also shows the device type of the attempted connection, so you can tell whether it was from a tty or over the network. This may alert you to the first indications of someone probing your system. If the attempted login was over the network, the log also displays the IP address from which the connection originated.

Some system administrators question the wisdom of using the failedlogin log file feature. They believe that the log file may inadvertently record the password for an account, if the account name and password are entered out of sequence. This is a possibility, but in practice I have never known it to be an issue.

It is a good idea to print the failedlogin log file every day for review, then clear the log file after printing. This can be set up automatically in the crontab. The crontab can be set up to run a script file that would look something like:

string /etc/security/failedlogin > /dev/lp0
rm /etc/security/failedlogin
touch /etc/security/failedlogin
chmod 666 /etc/security/failedlogin

In this example, starting with the first line, the failedlogin log file is printed using the string command on the log file and redirecting it to a line printer device at /dev/lp0. The log file is deleted using the rm command and then recreated using the touch command. Finally, the permissions for the file are changed, so that all processes can write to it.

The printout from the log file would look something like this:

bernie
pts/16
124.34.45.132
UNKNOWN
tty5
UNKNOWN
pts/23
124.34.45.206

In the above example, there are three entries in the log file. The first one is for the account bernie, originating from IP address 124.34.45.123. Since it is a network connection, it has a pseudo device number (pts/16). For the next entry, the account is unknown, and it came from device tty5, which is a physical device on the system. The next entry is again a network connection, and it originated from IP address 124.34.45.206.

If you have multiple entries for a single account, it may be an indication that something is wrong. If you have unfamiliar IP addresses attempting to connect to your system, that is also something that should be investigated. They both could be indications that someone is probing your system.

The sulog

Another useful log to review regularly is the sulog. Like most versions of UNIX, AIX records failed attempts to spawn another process and switch to another user with the su command. This is recorded in the sulog log file. Entries in this log file may be from someone who is probing your system and attempting to gain privileged access. Any entry in this log should be investigated to determine whether it is legitimate. The contents of the sulog would look something like the following:

SU      04/10        15:06 - tty1/0 oper1 - root

In this example, the log shows that the account "oper1" attempted to su to root at 3:06 p.m. on April 10. In this case, it may not be unusual for the operator to su to root. If however, the log shows someone attempting to su to root who should not be attempting such a function, you should investigate the occurrence. You should also investigate if you see an account in the log with multiple consecutive entries.

The printing of the sulog log file can also be automated. The crontab could be set up to run a script file that prints the sulog every night. The script file could be set up as follows:

cat /usr/adm/sulog > /dev/lp0
rm /usr/adm/sulog
touch /usr/adm/sulog

The wtmp File

Another useful log is the wtmp log. This file records information for every account that logs in and out of your system. It gives you the time and duration of the login. You can also determine whether the connection was from a tty, telnet, or rlogin connection, or was an ftp connection. I find the fact that it distinguishes telnet and rlogin connections from ftp connections to be very useful. In the environment where I work, almost no one should be connecting to our systems using ftp. As a result, when an ftp connection shows up on the log, it stands out as an item to be investigated.

For network connections, the wtmp log file will also display the IP address from which the connection originated. That too can be very useful for tracking down the individual responsible for the connection. The wtmp file is stored in a binary format. Thus, you must use the last command to display its contents. Below is an example of a typical wtmp printout using the last command:

bernie  pts/20  124.35.46.132   Mon Apr 13 14:30 - 16:29 (01:59)
oper2   ftp/31  124.35.46.205   Mon Apr 13 14:30 - 16:29 (01:59)
oper1   pts/54  124.35.46.206   Mon Apr 13 14:35 - 14:45 (00:10)
sally   tty3                    Mon Apr 13 15:30 -16:25 (00:55)
frank   pts/18  124.35.46.184   Mon Apr 13 14:18 -14:39 (00:21)

Four of the entries in this example are network connections that list IP addresses. The fifth is from a tty connection, so there is no IP address listed. One of the four network connections (oper2) used ftp. You can tell that by the device type (ftp/31).

Printing of the wtmp can be automated in the crontab file as follows:

last > /dev/lp0

The wtmp file will continue to grow if it is not periodically cleared out. I generally print the file every day, and clear it once a week. I recommend retaining hard copy printouts of the wtmp file in the event they are ever needed to determine when a particular account last accessed your system. This can be useful information if your system is ever compromised.

Using the Profile

Since the wtmp log resides on the system's disk storage, it is possible that if someone were to gain privileged access to your system, they could alter the wtmp file. As an alternative or in conjunction with the wtmp log, you can use a who am I command in the system-wide /etc/profile file to print an entry whenever someone logs into the system.

The system-wide /etc/profile usually executes whenever someone logs into the system. There are a few exceptions such as ftp connections. Putting a who am I statement in /etc/profile, that redirects its output to a printer device, will give you a real-time hard copy log that can not be altered or circumvented. Placing the statement in /etc/profile is simple using vi. Simply edit the /etc/profile file and insert the statement:

who am I > /dev/tty10

Typically, the printout will be as follows:

bernie   pts/20  Apr 13 14:30    124.35.46.132
oper1    pts/54  Apr 13 14:35    124.35.46.206
sally    tty3    Apr 13 15:30
frank    pts/18  Apr 13 14:18    124.35.46.184

The who am I command statement displays much the same information as the wtmp file. The major difference is that who am I only shows the login time and not the logout and duration of the connection. One word of caution, if the printer device you specify in the redirect of who am I statement is out of paper, jammed, or offline, your users may not be able to login.

I maintain hard copy printouts from both the wtmp log and the who am I statement in /etc/profile.

Using the Hosts File

If you work in an environment where your system is on a relatively large network (several hundred nodes or more), but only a limited number of specific users should be accessing your system, you can use the /etc/hosts file to distinguish the legitimate connections from those that may be probing your system. This will only work for users who connect to the system over an IP network using ftp, telnet, rlogin, or some other remote terminal IP session, but can still be very useful.

Where I work, there are thousands of systems and users on a corporate network, but only about a hundred have a legitimate reason to be accessing the systems for which my group is responsible. We have used the /etc/hosts file to make it easier to distinguish the IP addresses of possible intruders from the IP addresses of our legitimate users. You can do this by adding an entry into the /etc/hosts file for each system that is authorized to connect to your system. Each system entry will include the IP address and the alias for the system. Below is an example of what the /etc/hosts file entries might look like for the IP addresses used in the log file examples above.

124.35.46.132   STATION1
124.35.46.105   ADMIN2
124.35.46.206   ADMIN1
124.35.46.184   STATION2

Including these entries in the /etc/hosts file will change the information displayed on the failedlogin file, the sulog, the wtmp file, and the printout from the who am I command in the /etc/profile file.

If a system with an entry in the /etc/hosts file shows up in the failedlogin log file, it will display with its alias where the IP address would be.

Below are two examples of the failedlogin log file. On the left, is an example of what the log would look like without the entries in the /etc/hosts file. On the right, is an example of the log with the entries in the /etc/hosts file. For the right-hand example, there is an entry in the /etc/hosts file for IP address 124.35.46.132, so the alias displays in the log file instead of the IP address. Since there is no entry on the hosts file for IP address 124.35.46.205, the IP address displays on the log printout. This makes it very easy to distinguish known IP addresses from unknown intruders.

bernie                 bernie
pts/16                 pts/16
124.34.45.132          STATION1
unknown                unknown
tty5                   tty5
unknown                unknown
pts/23                 pts/23
124.35.46.205          124.34.45.205

Below is an example of what the wtmp file might look like with the entries in the /etc/hosts file.

bernie  pts/20  STATION1        Mon Apr 13 14:30 - 16:29 (01:59)
oper2   ftp/31  124.35.46.205   Mon Apr 13 14:30 - 16:29 (01:59)
oper1   pts/54  ADMIN1          Mon Apr 13 14:35 - 14:45 (00:10)
sally   tty3                    Mon Apr 13 15:30 -16:25   (00:55)
frank   pts/18  STATION2        Mon Apr 13 14:18 -14:39   (00:21)

For IP addresses loaded in the hosts file with aliases, the aliases show in the log in place of the IP address. Thus, when you do see an IP address in your log, you know it came from a system that does not normally connect to your system.

Below is a sample printout from the who am I command in /etc/profile. Again, the IP address for the system without an entry in the hosts file stands out.

bernie  pts/20  Apr 13 14:30    STATION1
oper1   pts/54  Apr 13 14:35    ADMIN1
sally   tty3    Apr 13 15:30
John    pts/33  Apr 13 15:33    146.35.48.145
frank   pts/18  Apr 13 14:18    STATION2

This is not fool proof; it can be circumvented by IP spoofing.

Obviously, this scheme will not work in an environment where you are using DHCP. It is not scalable, because it becomes difficult to manage with large numbers of entries. It only works well with a limited number of systems, say 100 or 200. If a hacker gets your /etc/hosts file, they will be able to get the IP addresses of the other systems. However, if they've gotten the /etc/hosts file, they already have access to your system, so you have already been compromised.

Conclusion

All the measures described above are preliminary measures toward securing and monitoring your system. As stated previously, these are just rudimentary steps. These have helped us identify when our systems were being probed by another system on the corporate network. We have also taken other measures to safeguard and firewall our systems. You must determine which measures are necessary for your system, based upon your environment. These measures are no substitute for a firewall, but having a firewall is no excuse for not monitoring your system. If your systems are in an environment where the network is potentially hostile, then additional measures are certainly in order. Consider using some of the tools that are available on the Web, such as the TCPwrapper program. This is a program that allows you much more control over services and a greater capability to log events.

Even if your system sits on a secure or trusted network or behind a firewall, you should secure and monitor your system. Network security begins at the individual system level. You have no idea if the next system administrator down the line is doing their job properly. They could be hanging dial-up connections off their system without proper security measures. A network is only as secure as the individual systems on that network.

Listed below are some Web sites that are good resources for AIX information.

Institute of Theoretical Physics's AIX Newsgroup Archive at the University of Duisburg (Germany) at:

http://www.thp.uni-duisburg.de/cuaix/cuaix.html

This site is very useful because it gives you the ability to easily search the archives using topics or key words.

A good site with precompiled binaries for AIX 3.xx and 4.xx is UCLA's AIX Public Domain Software Library. It can be found at:

http://aixpdslib.seas.ucla.edu/aixpdslib.html

Emory University's Emerson Center for Scientific Computation AIX FAQs at:

http://euch6h.chem.emory.edu/services/aix-faq/

Ohio State University's AIX FAQ at:

http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top.html

About the Author

John Canavan works at Chevron Federal Credit Union where he is responsible for directing the financial institution's information technology unit. He can be reached via email at: jcnv@chevron.com.