Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Thinking About Security—An Audit

A security audit has three basic parts, each with many issues to think about. First, you need to develop a plan, a set of security aspects to be evaluated. Second, you need to consider the tools available for evaluating the security aspects and choose ones that are suitable for your system. The third part of a security audit is knowledge gathering—not only how to use the system, but what the users are doing with the system, break-in methods for your system, physical security issues, and much more. The following sections look at each of these three pieces of the audit and offer some direction about where to go for more information.

A Security Plan

The plan can be as complex as a formal document or as simple as a few notes scribbled on the back of a dinner napkin. Regardless of the complexity, the plan should at least list what aspects of the system you are going to evaluate and how. This means asking two questions:

To answer these questions, a few more questions might be necessary concerning the following areas:

A more detailed plan can be developed based on discussion of these topics. As always, there will trade-offs; for example, privacy of data could mean that only certain people can log on to the system, which affects system access for the users. System availability is always in conflict with change control. For example, when do you change that failing hard drive on a 24/7 system? The bottom line is that your detailed plan should include a set of goals, a way of tracking the progression of the goals (including changes to the system), and a knowledge base of what types of tools are needed to do the job.

Security Tools

Having the right tools always makes the job easier—especially when you are dealing with security issues. A number of tools are available on the Internet, including tools that check passwords and system security and protect your system. Some major UNIX-oriented security organizations assist the UNIX/Red Hat Linux user groups in discussing, testing, and describing tools available for use. CERT, CIAC, and the Linux Emergency Response Team are excellent sources of information for both beginning and advanced system administrators.

The following list introduces many of the available tools. This should be a good excuse, however, to surf the Net and see what else is available.

cops A set of programs; each checks a different aspect of security on a UNIX system. If any potential security holes do exist, the results are either mailed or saved to a report file.
courtney A satan detector. courtney gives the system administrator an early warning of possible network intrusions by detecting and identifying satan's network probing.
crack A program designed to find standard UNIX eight-character DES-encrypted passwords by standard guessing techniques.
deslogin A remote login program that can be used safely across insecure networks.
freestone A portable, fully functional firewall implementation.
ipfilter A free packet filter that can be incorporated into any of the supported operating systems, providing IP packet-level filtering per interface.
kerberos A network authentication system for use on physically insecure networks. It allows entities communicating over networks to prove their identities to each other while preventing eavesdropping or reply attacks.
merlin Takes a popular security tool (such as tiger, tripwire, cops, crack, or spi) and provides it with an easy-to-use, consistent graphical interface, simplifying and enhancing its capabilities.
opie Provides a one-time password system for POSIX-compliant, UNIX-like operating systems.
Plugslot Ltd. PCP/PSP UNIX network security and configuration monitor.
rsaref A cryptographic toolkit providing various functions for the use of digital signatures, data encryption, and supporting areas (PEM encoding, random number generation, and so on).
satan The security analysis tool for auditing networks. In its simplest (and default) mode, satan gathers as much information about remote hosts and networks as possible by examining such network services as finger, NFS, NIS, ftp, tftp, and rexd.
openssh Secure shell—a remote login program.
tcp wrappers Can monitor and control remote access to your local tftp, exec, ftp, rsh, telnet, rlogin, finger, and systat daemon.
tiger Scans a system for potential security problems.
tis firewall toolkit Includes enhancements and bug fixes from version 1.2 and new proxies for HTTP/Gopher and X11.
tripwire Monitors system for security break-in attempts.
xroute Routes X packets from one machine to another.

As you can see, quite a few tools exist for your use. If you want a good reason for looking at these tools, keep in mind that people trying to break into your system know how to—and do—use these tools. This is where the knowledge comes in.

The expiration of the patent on the RSA public key algorithm and the relaxation of U.S. export controls on encryption software has given Red Hat the opportunity to provide robust tools for security. These include the rpms for openssh (the tool mentioned above as a secure replacement for telnet) and openssl, which is used for adding ssl support to Apache via the mod_ssl rpm.

Knowledge Gathering

Someone once said a little knowledge goes a long way. As stated in the chapter opening, all the bells and whistles can be there, but they do no good if they are not active. It is therefore important that the system staff, the users, and the keepers of the sacred root password all follow the security procedures put in place—and that they gather all the knowledge necessary to adhere to those procedures.

I was at the bank the other day, filling out an application for a car loan. The person assisting me at the bank was at a copy machine in another room (I could see her through the window). Another banking person, obviously new, could be heard from his office, where he was having problems logging in to the bank's computer. He came out and looked around for the bank employee helping me. When he did not see her, I got his attention and pointed him toward the copy area. He thanked me and went to her and asked for the system's password because he could not remember it. She could not remember the password. He went back to his desk, checked a list of telephone numbers hanging on the wall by his phone, entered something into the computer, and was in. About that time, the bank person assisting me came out of the copy area, stuck her head in his office, and said that she recalled the password. He said he had it. She asked if he had done with the password what they normally do. He looked at his phone list and said yes. She left and returned to me at her desk.

This scenario is true. The unfortunate thing about it, besides the fact that at least two customers—the person with the employee trying to log in to the system and I—saw the whole thing, is that they didn't know, nor did they care, that others might be listening. To them it was business as usual. What can be learned from this? Don't write down passwords!

Not only should passwords not be written down, they should not be easily associated with the user. I'll give you two examples that illustrate this point. The first involves a wonderful man with whom I worked on a client site. He has three boys. As a proud father, he talks about them often. When referring to them individually, he uses their first names. When referring to them collectively, he calls them "three boys." His password (he uses the same password for all his accounts) is threeboys.

The second example comes from one of the sweetest people I have met in the industry. On this woman's desk is a little stuffed cow named Chelsea. I do not remember the significance of the name, but I remember that she really likes dairy cows. Her password is—you guessed it—chelsea. These passwords are probably still threeboys and chelsea.

File security is another big issue. The use of umask (file creation masks) should be mandated. It should also be set to the maximum amount possible. Changing a particular file to give someone else access to it is easy. Knowing who is looking at your files is difficult, if not impossible. The sensitivity of the data, of course, would certainly determine the exact level of security placed on the file. In extremely sensitive cases, such as employees' personnel records, encryption of the files might also be necessary.

After an audit has been done, you should have an excellent idea about what security issues you need to be aware of and which issues you need to track. The next section shows you how to track intruders.

Share ThisShare This

Informit Network