Read an Excerpt
Chapter 24: System Security
Security is one of the hottest topics in my system debate. How do you make your site more secure? How do you keep the hackers out of your system? How do you make sure your data is safe from intruders? How do you keep your company's secrets a secret?
Your system is as secure as its weakest point. This is an old saying, and one that is still true. I ant reminded of an Andy Griffith TV show in which the town drunk (Otis) is sleeping off another episode in the jail. After he is sober, Otis looks around at the bars on the windows, the barred walls, and the gate. "A pretty secure jail:' I thought, until the he pushed open the door, said good-bye to Barney, and left. So much for the security!
Many times, systems are as secure as that jail. All the ban and locks are in place, but the door is left open. This chapter takes a look at some of the bars and locks and explains how to lock the door. More importantly, though, it explains how, to conduct a security audit and where to go to get more information.
Security comes in many forms. Passwords and file permissions are your first two lines of defense. After that, things get difficult. Security breaches take many form, To understand your particular system and the security issues relevant to your system, you should first develop a security audit.
Thinking About Security-An Audit
A security audit has three basic parts, each with many things 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 to your system. The third partof 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 Java receipt. 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:
- What types of security problems could we have?
- Which ones can we (or should we) attempt to detect or fix?
To answer these questions, a few more questions might be necessary concerning the following areas:
- Change control and tracking
- Data integrity, including backups
- Physical security
- Privacy of data
- System access
- System availability
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 7x24 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.
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, check 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 the beginning and advanced system administrator.
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.
As you can see, a few tools exist for your use. If you want a second 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.
|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 we either mailed or saved to a report file.|
|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|
|findsuid.tar.Z ||Finds changes in setuid (set user ID) and setgid (set group ID) files.|
|freestone ||A portable, fully functional firewall implementation.|
|gabriel ||A satan detector. gabriel gives the system administrator an early warning of possible network intrusions by detecting and identifying satan's network probing.|
|ipfilter ||A free packet filter that can be i operating systems, providing IP packet-level filtering per interface.|
|ipfirewall ||An IP packet-filtering tool, similar to the packet-filtering facilities provided by most commercial routers.|
|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 replay attacks.|
|merlin || Takes a popular security tool (such as tiger, tripwire, cops, crack, of spi) and provides it with an easy-to-use, consistent graphical interface, simplifying and enhancing its capabilities.|
|npasswd ||passwd replacement with password sanity check.|
|obvious-pw.tar.Z ||An obvious password detector.|
|opie ||Provides a one-time password system for POSIX-compliant, UNIX-like operating systems.|
|pcheck.tar.Z ||Checks format of /etc/passwd; verifies o,t default shell and passwd fields.|
|Plugslot Ltd.|| PCP/PSP UNIX network security and configuration monitor.|
|rsaeuro||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).|
|rscan||Allows system administrators to execute complex (or simple) scanner scripts on one (or many) machines and to create clear. formatted reports in either ASCII or HTML.|
|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.|
|ssh||Secure shell-a remote login program.|
|tcp wrappers||Can monitor rat, 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 X 11.|
|tripwire ||Monitors system run security break-in attempts.|
|xp-beta ||An application gateway of XI I protocol. It is designed to be used at a site that has a firewall and uses SOCKS or CERN WWW Proxy.|
|xroute || Routes X packets from one machine to another|
Someone once said a little knowledge goes a long way. As stated in the chapter opening, A 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 anot room (I could see her through the window). Another banking person, obviously new, could be beard 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, my bank person 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 front the Middle East with whom I worked on a client site. He has threeboys. As a proud father, he talks about them often. When referring to them individually, he uses their first names, When referring to them cumulatively, 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 of 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.
Danger, Will Robinson, Danger!I used to love watching Lost in Space. On that show was a life-sized iobot that would declare, "Danger, Will Robinson, danger!" when there was some danger. Unfortunately, no such robot warns of danger on our systems, (Although some tools exist, they are nowhere near as consistent as that robot was!)If you have a lot of extra disk space, you can turn on auditing, which records all user connects and disconnects from your system. If you don't rely on auditing, you should scan the logs often. A worthwhile alternative might be to write a quick summary script that gives an account of the amount of time each user is on the system.Unfortunately, there are too many holes to block them all. Measures can be placed to plug the biggest, but the only way to keep a system secure is by locking a computer in a vault, allowing no one access to it and no connectivity outside the vault. The bottom line is that users who want into your system, and are good enough, can get in. What you have to do is prepare for the worst. . .