Implementing and Maintaining AIX Security Policies

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

Introduction

This paper is meant to serve as an introductory guide to the basic security and server hardening functions present in AIX. Many of the features and functions shown throughout this guide are applicable to AIX 4.3 and above, but are more directed toward AIX 5.2. Since security is and will always remain a major issue in server environments, it is crucial that system administrators have a strong working knowledge of security policy implementation and hardening features. This knowledge can be applied to new systems, or to bring older systems up to date.

All administrators should have a thorough understanding of what is presently installed and running on their system. But, with the wide range of server applications, administration specialization is often necessary. Therefore, it is imperative that at least one primary and one secondary administrator per team maintain a strong working knowledge of security. By staffing administrators with security emphasis, the system will be maintained with the newest updates, programs, and patches that deal with security or server hardening issues.

Keep in mind that security is defined on a server-by-server basis. Administrators should not implement any of these security features without personal research as some may cause software conflicts. Each feature must be fully understood and the system checked to ensure that the server will properly handle the security change. All tests should be made on a Proof of Concept box prior to production, as well as making sure all changes have gone through Change Management prior to implementation. Also, a backup of important files with a well-documented backout plan should always be utilized, especially when dealing with larger installs of security features on production servers.

Network security is very sturdy but should not be relied upon to the point of ignoring stand- alone security or server hardening features. Do not depend only on network security to safeguard the servers. This is the last line of defense, not the first. Many times networking can be bypassed internally within a company, or externally by accessing one vulnerable machine present on the network and running telnet/rsh to another server. One vulnerable node is very likely to be able to take down an entire network. Network security is very powerful, but should be used as a supplement, not a crutch.

Although much of the responsibility for security tends to lie with a dedicated security team, each administrator should have a basic knowledge of security practices and exploits for their own production systems. "Ethical Hacking" is strongly recommended on servers prior to production rollout. By performing "attacks" on one's own system, the same information that intruders discover will be revealed to the administrators. If the amount of information available is minimized by filling holes identified with these tools, the intruder will have nearly no information with which to launch an attack and will be "pinging in the dark". Of course, these measures must be granted with written authorization via change management and must not affect production servers.

Security, as many people mislabel it, is not a game of cat and mouse. The intruders are very intelligent and deserve respect for their knowledge of security and general computing. They should be respected as equal, not inferior. A security-minded administrator would use the appended list of computer exploit websites created by these people to have a better understanding the resources available to parties who may exercise these vulnerabilities.

“If ignorant both of your enemy and yourself, you are certain to be in peril”
-Sun Tzu

Environment Analysis

There are certain considerations that must be taken into account before any implementation can begin upon an AIX server. What version of operating system exists on the system? Where will the server be located? What programs will be running on this server? These are but three of the many questions that need to be answered to direct the path of a security policy. Depending on the answer to many of these questions, the level of security can be determined. For instance, if a server is simply running audits for other servers and is not a production machine, it would seem to not require very much security. On the other hand, if it is running these audits, it is most likely to have the same subnet as the other servers. Because of the possibility of jumping from node to node, high security precautions must be implemented on this example system to ensure that the production servers are not exploited.

Here are a few sample questions that need to be answered prior to the start of building a security framework.

Is the server in an open environment accessible by more than system administrators?

• If this is true, the server may be physically vulnerable to Knoppix Live CD’s or other threats.

Is there proprietary information stored on the server dealing with a sensitive material?

• Data needs to be secured and encrypted, as well as server security protecting these files from possible copying and removal.

Is the server on the same subnet as production servers?

• One node can bring down an entire network.

If a production server, does the client want high security?

• If a client knows that the information on the server is sensitive to their business, they may request higher security.

Does the Client interface with the server using their own system?

• Client computers should not be trusted to remain secure and should be ready to be physically disconnected if there are signs of vulnerability. Work with the client to help them secure their own systems by advising them of security updates/patches.

Do more than administrators log into the server?

• When more than administrators are permitted to log in, a server may be vulnerable to employees with access.

Are there people accessing the server that are not familiar with AIX/UNIX?

• Untrained users may accidentally damage a system without knowledge of how to recover.

If the answer yes to more than half of these questions, the higher echelon of security features outlined should be implemented. If the unit does not seem to require high security, implement the standard features and review the enhanced security features and evaluate if they would be useful for certain clients.




More Operating System tutorials and guides














Your IP address will be sent with this e-mail

From e-mail to e-mail