Multilayered Security

John R. Wetsch

The focus of any security implementation is to control access, protect data, and secure system resources. A comprehensive security plan must be scalable from standalone systems to distributed client/server systems, and must address security issues at network, system, application, data, and physical levels or layers. Each or these layers provides a method of access to your system. From the point of view of users accessing the system, they first come through the network layer, then enter your system through the system layer, then go through applications, find data, and possibly have physical access to your system hardware. Multilayered security protects the system at each level, provides a security overlap between layers, and helps you build a comprehensive security view of your system.

The Network Layer

The network layer is complex, ranging from a simple modem connection to a particular flavor of network implementation. With only modem connections to your system, your security may start with a fundamental login and password authentication at your server. A more advanced implementation would use the security features incorporated into some network operating systems (NOS).

Generally, the network layer is the weakest security layer. All types of users will be moving through your network to gain access to your system. To strengthen your network layer, implementing a firewall may be appropriate. The concept of a firewall is to stop or slow the progress of an intruder in your system, similar to a physical firewall that is designed to slow the progress of a fire through a building.

A firewall strategy segments access to your servers, restricting users to specific servers or LAN systems. You can implement a simple firewall on a networked system that will allow you to control access to key areas. Assume, for instance, an ethernet TCP/IP environment consisting of two LAN systems. The first LAN system (machine name: alpha) is dedicated to development, while the other system is a production system (machine name: beta). In this scenario the goal is to keep the nonsystem users out of the development system but allow the development users to access both systems.

You would begin by adding to your network a front-end server (machine name: firewall) that all users would log into. In each user's .profile you would add either

rlogin alpha

for a developer or

rlogin beta

for a production system users. All users would now be routed to the LAN system they need. To ensure that users are logged off the system when they exit, add the statement

kill -9 0

after the rlogin statement. You could implement further segmentation of resources by using the Network File System (NFS), if you have this installed. The goal here is to give users the resources they need but nothing more. The last lines of .profile should now read:

rlogin machine-name   #where machine-name is alpha or beta
kill -9 0             #Exits the user from the shell and removes
#user processes

You may wonder why I chose to use

kill -9 0

after rlogin rather than to exec the rlogin from the firewall system. An

exec rlogin hostname

is more concise and is in fact more secure, as it removes the possibility that the kill command could be ignored. I have successfully implemented both scenarios and I suspect that

exec rlogin hostname

is more commonly used for these purposes. However, my aim here was to make the usage of shells consistent across all platforms in an attempt to be generic, and the

kill -9 0

implementation can also be used in the environment where shell access is restricted.

The System Layer

The system layer begins with login and password authentication. In the system layer, the system administrator can fully employ the tools available in the operating system to monitor and control user access. In most texts on UNIX security the systems layer is dealt with in considerable detail. In these texts you learn how to set up system accounting, sample scripts, and other UNIX utilities that can be used to assist in system security.

Security at the system layer begins by knowing the key areas of your system and addressing each area as it pertains to your environment. The following serves as a checklist of this area and can be established as follows:

1. Know your bits. 2. Establish a password strategy. 3. Set up user environment. 4. Keep tabs on your key files. 5. Establish system accounting. 6. Establish system checking procedures. 7. Watch your overhead.

Knowing your bits involves setting user and group IDs, sticky bits, and umask properly. The umask, which is used to set the default permissions on files, can also be used by shell users to set their default permissions. A sticky bit lets administrators limit write access to a file to the superuser and the file owner.

Knowing your key file areas is important, too. The device directory is /dev; /bin is used for public access to UNIX commands; /etc contains configuration files and other executables; / is, of course, your root directory. Once you know how your UNIX environment should be set and where your key files are, you can write and activate a simple check utility using crontab.

The checksys script (Listing 1) assumes that you've set up a directory called /etc/checkfil, accessible only to the superuser, and cd'd into it. The script simply accesses your key directories and writes ls -l listings to a file. The script then runs a diff against a master file you create prior to running the command and then saves the output of the diff command to a separate file. By using cat on the diff output, you can find any changes to files made since the master was created. If the diff output looks good, you can update your master by running rm master and then mv checkfil master. With a regular run of checksys, you will be aware of what files change regularly. You will also be able to tell if permissions and bit settings to key files have been changed.

Within the system layer, the system administrator must also establish a password strategy. This includes addressing such areas as password length and password aging, establishing policies for setting up user accounts, setting policy on deactivating users who do use the system, and removing user accounts. Other considerations of password restrictions include the minimum time between password changes, and whether you want users to choose their own passwords or have the system generate passwords.

Setting up your system environment is equally important. You'll need to think through what paths you want your users to access directly, how many login attempts you'll allow, how much idleout time is required before automatic logoff, whether to set a ulimit that will ration disk space and prevent an errant process from filling up your disk.

Finally, set up your system accounting to allow you to track usage of your system. For all of these areas you must establish procedures that will allow you to maintain and track all security implementations. Without these procedures your files will get away from you and become unmanageable. In essence, keep track of your overhead. Any security implementation requires additional work and system tracking. Security must be done daily!

Application Layer

With system layer security in place, the system administrator must address the matter of application security. Do all users need access to the shell? In the network layer example, I posited that development users probably need shell access but production system users only need access to their applications.

In a single application environment you could simply enter a startup to the application in the .profile, between the rlogin statement and the kill statement. The result would be that when users attach to a machine and log in, they come directly into the application. When they exit the application, the kill statement forces them off the system.

It's more likely that users will require access to several applications. A user interface can help these users without letting them drop to a shell. If you are not using a GUI, then you can implement a simple menu script. The menxshell script in Listing 2 is a menu shell that will allow you to set up submenus or directly access applications.

System administrators can use a menu system to make the system work better for their users. However, administrators must be beware of backdoors to some restricted applications. For instance, assume you allow users to access vi through the menu. Once the vi editor is invoked, the user can enter shell commands using the ! operator. Know the extent and limitations of your applications.

Finally, from the application layer the system administrator can invoke the particular security features of an application, For instance, if you must administer a database, you will need to consider such database security features as transaction logging; privileges on tables and fields, including add, modify, or delete; and access to specific data views.

The Data Layer

The data layer requires protection of the data on your system as well as your system's resources. At this layer you will address backup and restore strategies. This would include making a complete system backup; establishing policies and procedures for daily, weekly, and monthly backup types; and selecting the appropriate backup utilities, such as tar, cpio, or an off-the-shelf package, to standardize your backup environment. The goal of the administrator here is to be able to restore any files lost, destroyed, or damaged.

You may also decide to implement a Redundant Array of Inexpensive Disks (RAID) technology such as disk mirroring. Overall, you must evaluate the environment to determine the best method to ensure data reliability.

The Physical Layer

Implementing the various components of the network, system, and data layers is not enough if your physical layer is not secure. Protecting the physical layer entails securing both your hardware and your licensed software. You must ask how secure the system environment is. Can anyone approach your equipment, see a blinking light, and press a button? Is there a contingency plan in case of fire, theft, or system breakdown? Is your data layer's backup media stored in a secure location?

At the physical layer, you'll need to set up a disaster recovery plan that addresses what needs to be done if any of the layers fail. If a plan is already in place, you should make sure the plan is current and reflects the environment.

Implementation

The layered approach to system security gives administrators a means of addressing user entry into their systems. It allows administrators to collect all of the information required to write a security plan. Good system procedures are nothing if they are not enforced with good policy. Any security feature implemented must be maintained.

A security system should consist of at least three basic documents. The first document is a security plan that provides the basis for the security methods and physical environment. The second document is a disaster recovery plan that takes care of contingencies. The third document is a policy and procedures manual that details any procedures developed and in use. Before putting together any of the documents, the administrator needs a risk analysis to assess risks and costs of downtime to the organization.

No system is 100 percent secure. The extent of any assessment is dependent on the complexity of the system. The goal of layered security is to ensure that the administrator has completely addressed system security issues.

Within your organization, implement the security plan as you would any other company policy. Enforce the security plan. A security plan that incorporates a layered approach should, at a minimum, cover the following: