Practical UNIX and Internet Security

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In today's world of international networks and electronic commerce, every computer system is a potential target. Rarely does a month go by without news of some major network or organization having its computers penetrated by unknown computer criminals. These intrusions have become especially sinister in recent years: computers have been turned into attack platforms for launching massive denial of service attacks, credit-card numbers have been plundered from databases and then used for fraud or extortion, hospital medical records have been accessed by children who then used the information to play malicious practical jokes on former patients, business records have been surreptitiously altered, software has been replaced with secret "back doors" in place, and millions of passwords have been captured from unsuspecting users. There are also reports of organized crime, agents of hostile nation states, and terrorists all gaining access to government and private computer systems, using those systems for nefarious purposes.

All attacks on computer systems are potentially damaging and costly. Even if nothing is removed or altered, system administrators must often spend hours or days analyzing the penetration and possibly reloading or reconfiguring a compromised system to regain some level of confidence in the system's integrity. As there is no way to know the motives of an intruder, and the worst must always be assumed.

People who break into systems simply to "look around" do real damage, even if they do not access confidential information or delete files.

Many different kinds of people break into computer systems. Some people are the equivalent of reckless teenagers out on electronic joy rides. Similar to youths who "borrow" fast cars, their main goal isn't necessarily to do damage, but to have what they consider to be a good time. Others are far more dangerous: some people who compromise system security are sociopaths—their goal is to break into as many systems as possible for the mere challenge of doing so. Others see themselves as being at "war" with rival hackers; woe to innocent users and systems who happen to get in the way of cyberspace "drive-by shootings!" Still others are out for valuable corporate information, which they hope to resell for profit or use for blackmail. There are also elements of organized crime, spies, saboteurs, terrorists, and anarchists.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Terms like security, protection, and privacy often have more than one meaning. Even professionals who work in information security do not agree on exactly what these terms mean. The focus of this book is not on formal definitions and theoretical models so much as it is on practical, useful information. Therefore, we'll use an operational definition of security and go from there.

COMPUTER SECURITY. A computer is secure if you can depend on it and its software to behave as you expect.

If you expect the data entered into your machine today to be there in a few weeks, and to remain unread by anyone who is not supposed to read it, then the machine is secure. This concept is often called trust : you trust the system to preserve and protect your data.

By this definition, natural disasters and buggy software are as much threats to security as unauthorized users are. This definition is obviously true from a practical standpoint. Whether your data is erased by a vengeful employee, a random virus, an unexpected bug, or a lightning strike—the data is still gone. That's why the word "practical" is in the title of this book—and why we won't try to be more specific about defining what "security" is, exactly. A formal definition wouldn't necessarily help you any more than our working definition, and would require detailed explanations of risk assessment, asset valuation, policy formation, and a number of other topics beyond what we are able to present here.

Our practical definition also implies that security is also concerned with issues of testing, quality assurance, hardware reliability, and even human factors. And in fact, these issues are increasingly of interest to security professionals. This book, however, does not address these topics in detail, as there are other books that cover these topics better than we could given the amount of space that we have available.

Instead, this book emphasizes techniques to help keep your system safe from other people—including both insiders and outsiders, those bent on destruction, and those who are simply ignorant or untrained. The text does not detail every specific security-related feature that is available only on certain versions of Unix from specific manufacturers: such information changes quite quickly, and reading a compilation of bugs, patches, and workarounds does not noticeably improve one's understanding of this field. Instead, this text attempts to teach the principles necessary to evaluate the data that you will get from more technical sources.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For most people, a computer is a tool for solving problems. When running a word processor, a computer becomes a machine for arranging words and ideas. With a spreadsheet, the computer is a financial-planning machine, one that is vastly more powerful than a pocket calculator. Connected to an electronic network, a computer becomes part of a powerful communications system.

At the heart of every computer is a master set of programs called the operating system. This is the software that communicates with the system hardware to control the computer's input/output systems, such as keyboards and disk drives, and that loads and runs other programs. The operating system is also a set of mechanisms and policies that help define controlled sharing of system resources.

Along with the operating system is (usually) a large set of standard utility programs for performing common functions such as copying files and listing the contents of directories. Although these programs are not technically part of the operating system according to some formal definitions, the popular notion of an operating system includes them. Whether they are part of the definition or not, they can have a dramatic impact on a computer system's security.

All of Unix can be divided into four parts:

The kernel: The kernel, or heart of the Unix system, is the operating system. The kernel is a special program that is loaded into the computer when it is first started. It controls all of the computer's input and output systems, allows multiple programs to run at the same time, and allocates the system's time and memory among them. The kernel includes the filesystem, which controls how files and directories are stored on the computer's storage devices (e.g., disks). The filesystem is one main mechanism by which security is enforced. Some modern versions of the Unix system allow user programs to load additional modules, such as device drivers, into the kernel after the system starts running.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Unix was developed in the 1970s to be an operating system for minicomputers that were being used simultaneously by several different people. Many of the features of the Unix environment can be traced back to this intended deployment environment.

In the three decades that have followed, Unix has been repurposed to many different kinds of deployment environments. One of the reasons for the operating system's success is that the design necessary to satisfy the original deployment requirements provided the operating system with great flexibility.

Today Unix is widely used in at least five different deployment environments:

Multiuser, shared systems: This is the original Unix deployment environment—a single computer that is simultaneously shared by several people. Shared systems are still common in universities, in some businesses, and among some Internet service providers. Thin-client Unix systems such as Sun Microsystems' SunRay systems make use of a shared system driving multiple client displays.

The key difference between the shared systems of the 1970s and the shared systems of today is merely size. In the 1970s, the typical shared Unix system had 32 or 64 KB of RAM, had a disk pack of perhaps 5 MB of storage, and comfortably supported between 3 and 5 simultaneous users. Today's typical multiuser systems have between 64 MB and 4 GB of RAM, hundreds of GBs of disk storage, and multiple cooperating CPUs, and can comfortably support between 3 and 500 simultaneous users. Larger servers may have more than 40 GB of RAM, disk storage in terabytes, and over 100 processors.
One-user Unix workstations: Unix workstations for the individual user were popularized in the 1980s by Sun Microsystems and Digital Equipment Corporation (now part of Hewlett-Packard). These workstations typically had large bitmapped displays running the X Window system, allowing a single person to open several windows for shell sessions or other processes. A one-user system could be entirely self-contained, or it can access resources such as disks and printers over the network.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we looked briefly at the questions that underlie computer security. What is computer security, and what are the threats to it? What is an operating system? What is a deployment environment? In the rest of the book, we'll explore all of these questions and your role in trying to answer them.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This is a book about Unix security. But before we can really plunge into the topic of our book—security—we need to explore what we mean by this word "Unix." After that, we'll discuss how notions of computer security play out in the Unix world. Figure 2-1 shows the many Unix variants, and their relationships, that we'll describe in this chapter.

Figure 2-1: Unix variants

The roots of Unix go back to the mid-1960s, when American Telephone and Telegraph, Honeywell, General Electric, and the Massachusetts Institute of Technology embarked on a massive project to develop an information utility. The goal was to provide computer service 24 hours a day, 365 days a year—a computer that could be made faster by adding more parts, much in the same way that a power plant can be made bigger by adding more furnaces, boilers, and turbines. The project, heavily funded by the Department of Defense Advanced Research Projects Agency ( ARPA, also known as DARPA), was called Multics.

Multics (which stands for Multiplexed Information and Computing Service) was designed to be a modular system built from banks of high-speed processors, memory, and communications equipment. By design, parts of the computer could be shut down for service without affecting other parts or the users. Although this level of processing is assumed for many systems today, such a capability was not available when Multics was begun.

Multics was also designed with military security in mind, both to be resistant to external attacks and to protect the users on the system from each other. By design, Top Secret, Secret, Confidential, and Unclassified information could all coexist on the same computer: the Multics system was designed to prevent information that had been classified at one level from finding its way into the hands of someone who had not been cleared to see that information. Multics eventually provided a level of security and service that is still unequaled by many of today's computer systems—including, perhaps, Unix.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The roots of Unix go back to the mid-1960s, when American Telephone and Telegraph, Honeywell, General Electric, and the Massachusetts Institute of Technology embarked on a massive project to develop an information utility. The goal was to provide computer service 24 hours a day, 365 days a year—a computer that could be made faster by adding more parts, much in the same way that a power plant can be made bigger by adding more furnaces, boilers, and turbines. The project, heavily funded by the Department of Defense Advanced Research Projects Agency ( ARPA, also known as DARPA), was called Multics.

Multics (which stands for Multiplexed Information and Computing Service) was designed to be a modular system built from banks of high-speed processors, memory, and communications equipment. By design, parts of the computer could be shut down for service without affecting other parts or the users. Although this level of processing is assumed for many systems today, such a capability was not available when Multics was begun.

Multics was also designed with military security in mind, both to be resistant to external attacks and to protect the users on the system from each other. By design, Top Secret, Secret, Confidential, and Unclassified information could all coexist on the same computer: the Multics system was designed to prevent information that had been classified at one level from finding its way into the hands of someone who had not been cleared to see that information. Multics eventually provided a level of security and service that is still unequaled by many of today's computer systems—including, perhaps, Unix.

Great plans, but in 1969 the Multics project was far behind schedule. Its creators had promised far more than they could deliver within their projected time frame. Already at a disadvantage because of the distance between its New Jersey laboratories and MIT, AT&T decided to pull out of the Multics Project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many years ago, Dennis Ritchie said this about the security of Unix: "It was not designed from the start to be secure. It was designed with the necessary characteristics to make security serviceable." In other words, Unix can be secured, but any particular Unix system may not be secure when it is distributed.

Unix is a multiuser, multitasking operating system. Multiuser means that the operating system allows many different people to use the same computer at the same time. Multitasking means that each user can run many different programs simultaneously.

One of the natural functions of such operating systems is to prevent different people (or programs) using the same computer from interfering with each other. Without such protection, a wayward program (perhaps written by a student in an introductory computer science course) could affect other programs or other users, could accidentally delete files, or could even crash (halt) the entire computer system. To keep such disasters from happening, some form of computer security has always had a place in the Unix design philosophy.

But Unix security provides more than mere memory protection. Unix has a sophisticated security system that controls the ways users access files, modify system databases, and use system resources. Unfortunately, those mechanisms don't help much when the systems are misconfigured, are used carelessly, or contain buggy software. Nearly all of the security holes that have been found in Unix over the years have resulted from these kinds of problems rather than from shortcomings in the intrinsic design of the system. Thus, nearly all Unix vendors believe that they can (and perhaps do) provide a reasonably secure Unix operating system. We believe that Unix systems can be fundamentally more secure than other common operating systems. However, there are influences that work against better security in the Unix environment.

The biggest problem with improving Unix security is arguably one of expectations. Many users have grown to expect Unix to be configured in a particular way. Their experience with Unix in academic, hobbyist, and research settings has always been that they have access to most of the directories on the system and that they have access to most commands. Users are accustomed to making their files world-readable by default. Users are also often accustomed to being able to build and install their own software, frequently requiring system privileges to do so. The trend in "free" versions of Unix for personal computer systems has amplified these expectations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If we can't change Unix and the environment in which it runs, the next best thing is to learn how to protect the system as best we can. That's the goal of this book. If we can provide information to users and administrators in a way that helps them understand the way things work, and how they can use safeguards within the Unix environment, then we should be moving in the right direction. After all, these areas seem to be where many of the problems originate.

Unfortunately, knowing how things work on the system is not enough. Because of the Unix design, a single flaw in a Unix system program can compromise the security of the operating system as a whole. This is why vigilance and attention are needed to keep a system running securely: after a hole is discovered, it must be fixed. Furthermore, in this age of networked computing, that fix must be made widely available, lest some users who have not updated their software fall victim to more up-to-date attackers.

Although this book includes numerous examples of past security holes in the Unix operating system, we have intentionally not provided the reader with an exhaustive list of the means by which a machine can be penetrated. Not only would such information not necessarily help to improve the security of your system, but it might place a number of systems running older versions of Unix at additional risk.

Be aware that even properly configured Unix systems are still very susceptible to denial of service attacks, in which one user can make the system unusable for everyone else by "hogging" a resource or degrading system performance. In most circumstances, however, administrators can track down any local person who is causing the interruption of service and deal with that person directly. We'll talk about denial of service attacks in Chapter 24.

In the early chapters of this book, we'll discuss basic issues of policy and risk. Before you start setting permissions and changing passwords, make sure you understand what you are protecting and why. You should also understand what you are protecting against. Although we can't tell you all of that, we can outline some of the questions you need to answer before you design your overall security plan.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we looked at how the history of Unix evolved from Multics to the system that it is today. With Unix, unlike with other operating systems, security was not added as an afterthought: secure multiuser operation has been a requirement since Unix was created. But our notion of what "secure operations" means has changed over time, and with those changes Unix developers have tried to keep pace.

Today, when the majority of Unix systems are effectively single-user workstations, Unix security depends far more often on code quality and administrative practices. That's good news, as it means that Unix is fundamentally securable. However, keeping a Unix system secure can be a lot of work.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Fundamentally, computer security is a series of technical solutions to nontechnical problems. You can spend an unlimited amount of time, money, and effort on computer security, but you will never solve the problem of accidental data loss or intentional disruption of your activities. Given the right set of circumstances—e.g., software bugs, accidents, mistakes, bad luck, bad weather, or a sufficiently motivated and well-equipped attacker—any computer can be compromised, rendered useless, or even totally destroyed.

The job of the security professional is to help organizations decide how much time and money need to be spent on security. Another part of that job is to make sure that organizations have policies, guidelines, and procedures in place so that the money spent is spent well. And finally, the professional needs to audit the system to ensure that the appropriate controls are implemented correctly to achieve the policy's goals. Thus, practical security is often a question of management and administration more than it is one of technical skill. Consequently, security must be a priority of your organization's management.

This book divides the process of security planning into five discrete steps:

Planning to address your security needs
Conducting a risk assessment or adopting best practices
Creating policies to reflect your needs
Implementing security
Performing audit and incident response

This chapter covers security planning, risk assessment, cost-benefit analysis, and policy-making. Implementation is covered by many of the chapters of this book. Audits are described in Chapter 21, and incident response in Chapter 22-Chapter 25.

There are two critical principles implicit in effective policy and security planning:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are many different kinds of computer security, and many different definitions. Rather than present a formal definition, this book takes a practical approach and discusses the categories of protection you should consider. Basically, we know a computer is secure if it behaves the way you expect it to. We believe that secure computers are usable computers and, likewise, that computers that cannot be used, for whatever the reason, are not very secure.

Within our broad definition of computer security, there are many different types of security that both users and administrators of computer systems need to be concerned about:

Confidentiality: Protecting information from being read or copied by anyone who has not been explicitly authorized by the owner of that information. This type of security includes not only protecting the information in toto, but also protecting individual pieces of information that may seem harmless by themselves but can be used to infer other confidential information.
Data integrity: Protecting information (including programs) from being deleted or altered in any way without the permission of the owner of that information. Information to be protected also includes items such as accounting records, backup tapes, file creation times, and documentation.
Availability: Protecting your services so they're not degraded or made unavailable (crashed) without authorization. If the systems or data are unavailable when an authorized user needs them, the result can be as bad as having the information that resides on the system deleted.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first step in improving the security of your system is to answer these basic questions:

What am I trying to protect and how much is it worth to me?
What do I need to protect against?
How much time, effort, and money am I willing to expend to obtain adequate protection?

These questions form the basis of the process known as risk assessment. Risk assessment is a very important part of the computer security process. You cannot formulate protections if you do not know what you are protecting and what you are protecting those things against! After you know your risks, you can then plan the policies and techniques that you need to implement to reduce those risks.

For example, if there is a risk of a power failure and if availability of your equipment is important to you, you can reduce this risk by installing an uninterruptable power supply (UPS).

Risk assessment involves three key steps:

Identifying assets and their value
Identifying threats
Calculating risks

There are many ways to go about this process. One method with which we have had great success is a series of in-house workshops. Invite a broad cross-section of knowledgeable users, managers, and executives from throughout your organization. Over the course of a series of meetings, compose your lists of assets and threats. Not only does this process help to build a more complete set of lists, it also helps to increase awareness of security in everyone who attends.

An actuarial approach is more complex than necessary for protecting a home computer system or very small company. Likewise, the procedures that we present here are insufficient for a large company, a government agency, or a major university. In cases such as these, many companies turn to outside consulting firms with expertise in risk assessment, some of which use specialized software to do assessments.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Time and money are finite. After you complete your risk assessment, you will have a long list of risks—far more than you can possibly address or defend against. You now need a way of ranking these risks to decide which you need to mitigate through technical means, which you will insure against, and which you will simply accept. Traditionally, the decision of which risks to address and which to accept was done using a cost-benefit analysis, a process of assigning cost to each possible loss, determining the cost of defending against it, determining the probability that the loss will occur, and then determining if the cost of defending against the risk outweighs the benefit. (See Cost-Benefit Examples sidebar for some examples.)

Risk assessment and cost-benefit analyses generate a lot of numbers, making the process seem quite scientific and mathematical. In practice, however, putting together these numbers can be a time-consuming and expensive process, and the result is numbers that are frequently soft or inaccurate. That's why the approach of defining best practices has become increasingly popular, as we'll discuss in a later section.

Determining the cost of loss can be very difficult. A simple cost calculation considers the cost of repairing or replacing a particular item. A more sophisticated cost calculation can consider the cost of out-of-service equipment, the cost of added training, the cost of additional procedures resulting from a loss, the cost to a company's reputation, and even the cost to a company's clients. Generally speaking, including more factors in your cost calculation will increase your effort, but will also increase the accuracy of your calculations.

For most purposes, you do not need to assign an exact value to each possible risk. Normally, assigning a cost range to each item is sufficient. For instance, the loss of a dozen blank diskettes may be classed as "under $500," while a destructive fire in your computer room might be classed as "over $1,000,000." Some items may actually fall into the category "irreparable/irreplaceable"; these could include loss of your entire accounts-due database or the death of a key employee.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Policy helps to define what you consider to be valuable, and it specifies which steps should be taken to safeguard those assets.

Policy can be formulated in a number of different ways. You could write a very simple, general policy of a few pages that covers most possibilities. You could also craft a policy for different sets of assets: for example, a policy for email, a policy for personnel data, and a policy on accounting information. A third approach, taken by many large corporations, is to have a small, simple policy augmented with standards and guidelines for appropriate behavior. We'll briefly outline this latter approach, with the reader's understanding that simpler policies can be crafted; more information is given in a number of books cited in Appendix C.

Policy plays three major roles. First, it makes clear what is being protected and why. Second, it clearly states the responsibility for that protection. Third, it provides a ground on which to interpret and resolve any later conflicts that might arise. What the policy should not do is list specific threats, machines, or individuals by name—the policy should be general and change little over time. For example:

Information and information-processing facilities are a critical resource for the Big Whammix Corporation. Information should be protected commensurate with its value to Big Whammix, and consistent with applicable law. All employees share in the responsibility for the protection and supervision of information that is produced, manipulated, received, or transmitted in their departments. All employees likewise share in the responsibility for the maintenance, proper operation, and protection of all information-processing resources of Big Whammix.

Information to be protected is any information discovered, learned, derived, or handled during the course of business that is not generally known outside of Big Whammix. This includes trade secret information (ours, and that of other organizations and companies), patent disclosure information, personnel data, financial information, information about any business opportunities, and anything else that conveys an advantage to Big Whammix so long as it is not disclosed. Personal information about employees, customers, and vendors is also considered to be confidential and worth protecting.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Formulating policy is not enough by itself. It is important to determine regularly if the policy is being applied correctly, and if the policy is correct and sufficient. This is normally done with a compliance audit. The term "audit" is overloaded; it is often used to mean (at least), a financial audit, an audit trail (log), a security audit of a system, and a compliance audit for policy.

A compliance audit is a set of actions carried out to measure whether standards set by policies are being met and, if not, why. Standards normally imply metrics and evaluation criteria that can be used by an auditor to measure this compliance. When standards are not met, it can be because of any of the following:

Personnel shortcomings

Insufficient training or lack of appropriate skills
Overwork
Malfeasance
Lack of motivation

Material shortcomings

Insufficient or inadequate resources
Inadequate maintenance
Overload/overuse

Organizational shortcomings

Lack of authority/responsibility

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

After reading through all the material in this chapter, you may have realized that your policies and plans are in good shape, or you may have identified some things to do, or you may be daunted by the whole task. If you are in that last category, don't decide that the situation is beyond your ability to cope! There are other approaches to formulating your policies and plans, and in providing security at your site: for example, through outsourcing, consultants, and contractors. Even if you are an individual with a small business at home, you can take advantage of shared expertise—security firms that are able to employ a group of highly trained and experienced personnel who would not be fully utilized at any one site, and share their talents with a collection of clients whose aggregate needs match their capabilities.

There are not enough information security experts available to meet all the needs of industry and government. Thus, there has been a boom in the deployment of consultants and outsourced services to help organizations of all sizes meet their information security needs. As with many other outsourced services, some are first-rate and comprehensive, others are overspecialized, and some are downright deficient. Sadly, the state of the field is such that some poor offerings are not recognized as such either by the customers or by the well-intentioned people offering them!

If you have not yet formulated your policies and built up your disaster recovery and incident response plans, we recommend that you get outside assistance in formulating them. What follows, then, is our set of recommendations of organizations that seek to employ outside security professionals for formulating and implementing security policies.

The first thing to do is decide what services you need:

Will you provide your own in-house security staff?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We'd like to close this chapter on policy formation with a few words about knowledge. In traditional security, derived largely from military intelligence, there is the concept of "need to know." Information is partitioned, and you are given only as much as you need to do your job. In environments where specific items of information are sensitive or where inferential security is a concern, this policy makes considerable sense. If three pieces of information together can form a damaging conclusion and no one has access to more than two, you can ensure confidentiality.

In a computer operations environment, applying the same need-to-know concept is usually not appropriate. This is especially true if you find yourself basing your security on the fact that something technical is unknown to your attackers. This concept can even hurt your security.

Consider an environment where management decides to keep the manuals away from the users to prevent them from learning about commands and options that might be used to crack the system. Under such circumstances, the managers might believe they have increased their security, but they probably have not. A determined attacker will find the same documentation elsewhere—from other users or from other sites. Extensive amounts of Unix documentation are as close as the nearest bookstore! Management cannot close down all possible avenues for learning about the system.

In the meantime, the local users are likely to make less efficient use of the machine because they are unable to view the documentation and learn about more efficient options. They are also likely to have a poorer attitude because the implicit message from management is "We don't completely trust you to be a responsible user." Furthermore, if someone does start abusing commands and features of the system, management may not have a pool of talent to recognize or deal with the problem. And if something should happen to the one or two users authorized to access the documentation, there is no one with the requisite experience or knowledge to step in or help out.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to understand what you mean by "security" before you can go about the task of securing a computer system. Traditionally, information security has meant ensuring confidentiality, data integrity, availability, consistency, control, and audit. But the relative importance of these items will be different for different organizations.

One way to grapple with these differences is to perform a detailed assessment of the risks that your organization faces, the impact that each risk could have, and the cost of defending against each risk. This is a long and involved process that few organizations are prepared to execute properly. For this reason, many organizations outsource their computer security work—the policy formation, the monitoring, or even the implementation. Other organizations adopt industry "best practices" and hope for the best.

No matter what you do, it's best if your decisions are informed by conscious policy choices, rather than by inertia, inattention, or incompetence.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Good account security is part of your first line of defense against system abuse. People trying to gain unauthorized access to your system often try to acquire the usernames and passwords of legitimate users. After an attacker gains initial access, he is free to snoop around, looking for other security holes to exploit to attain successively higher privileges. It's much easier to compromise a system from a local account than from outside.

Because most internal users are not malicious, many systems have better defenses against outsiders than against authorized users. Accordingly, the best way to keep your system secure is to keep unauthorized users out of the system in the first place. This means teaching your users what good account security means and making sure they adhere to good security practices.

This chapter explains the Unix user account and password systems. We'll explain these basic concepts, discuss the mechanics for picking and maintaining a good password, and finally show you how passwords are implemented in the Unix environment. In Chapter 19, we'll describe in detail how to protect your accounts from many different types of attacks.

Unfortunately, sometimes even good passwords aren't sufficient. This is especially true in cases where passwords travel across a network from one computer to another. Many passwords sent over the network can be sniffed —captured as they cross over a network. Although there are many ways to protect against sniffing, the best is to assume that it is going to happen and make sure that the information sniffed is useless. You can do that by assuring that all passwords sent over the network are encrypted, by using nonreusable passwords, or by eliminating the need to transmit passwords altogether through the use of public key encryption.

Every person who uses a Unix computer should have her own account. An account is identified by a user ID number (UID) that is associated with one or more

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Every person who uses a Unix computer should have her own account. An account is identified by a user ID number (UID) that is associated with one or more usernames (also known as account names ). Traditionally, each account also has a secret password associated with it to prevent unauthorized use. You need to know both your username and your password to log into a Unix system.

The username is an identifier: it tells the computer who you are. In contrast, a password is an authenticator: you use it to prove to the operating system that you are who you claim to be. A single person can have more than one Unix account on the same computer. In this case, each account would have its own username.

Standard Unix usernames may be between one and eight characters long, although many Unix systems today allow usernames that are longer. Within a single Unix computer, usernames must be unique: no two users can have the same one. (If two people did have the same username on a single system, then they would really be sharing the same account.) Traditionally, Unix passwords were also between one and eight characters long, although most Unix systems now allow longer passwords as well. Longer passwords are generally more secure because they are harder to guess. More than one user can theoretically have the same password, although if they do, that usually indicates that both users have picked a bad password.

A username can be any sequence of characters you want (with some exceptions), and does not necessarily correspond to a real person's name.

Some versions of Unix have problems with usernames that do not start with a lowercase letter or that contain special characters such as punctuation or control characters. Usernames containing certain unusual characters will also cause problems for various application programs, including some network mail programs. For this reason, many sites allow only usernames that contain lowercase letters and numbers and further require that all usernames start with a letter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although passwords are an important element of computer security, users often receive only cursory instructions about selecting them.

If you are a user, be aware that by picking a bad password—or by revealing your password to an untrustworthy individual—you are potentially compromising your entire computer's security. If you are a system administrator, you should make sure that all of your users are familiar with the issues raised in this section.

A bad password is any password that is easily guessed.

When picking passwords, avoid the following:

Your name, spouse's name, or partner's name
Your pet's name or your child's name
Names of close friends or coworkers
The name of your company, school, department, or group
Names of your favorite fantasy characters
Your boss's name
Anybody's name
The name of the operating system you're using
Information in the GECOS field of your passwd file entry (discussed later in this chapter)
The hostname of your computer
Your phone number or your license plate number
Any part of your Social Security number

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section describes how passwords are implemented inside the Unix operating system for both locally administered and network-based systems.

Traditionally, Unix uses the /etc/passwd file to keep track of every user on the system. The /etc/passwd file contains the username, real name, identification information, and basic account information for each user. Each line in the file contains a database record; the record fields are separated by a colon (:).

You can use the cat command to display your system's /etc/passwd file. Here are a few sample lines from a typical file:

root:x:0:1:System Operator:/:/bin/ksh
daemon:x:1:1::/tmp:
uucp:x:4:4::/var/spool/uucppublic:/usr/lib/uucp/uucico
rachel:x:181:100:Rachel Cohen:/u/rachel:/bin/ksh
arlin:x.:182:100:Arlin Steinberg:/u/arlin:/bin/csh

The first three accounts, root, daemon, and uucp, are system accounts, while rachel and arlin are accounts for individual users.

The individual fields of the /etc/passwd file have fairly straightforward meanings. Table 4-1 explains a sample line from the file shown above.

Table 4-1: Example /etc/passwd fields
Field	Contents
rachel	Username.
x	Holding place for the user's "encrypted password." Traditionally, this field actually stored the user's encrypted password. Modern Unix systems store encrypted passwords in a separate file (the shadow password file) that can be accessed only by privileged users.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

These days, many organizations have moved away from large time-sharing computers and invested in large client/server networks containing many servers and dozens or hundreds of workstations. These systems are usually set up so that any user can make use of any workstation in a group or in the entire organization. When these systems are in use, every user effectively has an account on every workstation. These systems provide for automatic account creation and password synchronization between some or many computer systems.

When you are working with a large, distributed system, it is not practical to ensure that every computer has the same /etc/passwd file. For this reason, there are now several different commercial systems available that make the information traditionally stored in the /etc/passwd file available over a network.

Five network authorization systems in use today are:

Sun Microsystems' Network Information System (NIS) and NIS+.
MIT Kerberos, which is now part of the OSF Distributed Computing Environment (DCE) and Microsoft's Windows XP. Kerberos clients are also included with Solaris, Linux, and several other Unix versions.
NetInfo, originally developed by NeXT Computer, now part of Mac OS X.
RADIUS, the Remote Authentication Dial-In User Service. Traditionally, RADIUS has been used by many ISPs to provide for authentication of dialup users. It has been extended to provide authentication for other devices (e.g., routers) and for password synchronization in a Unix environment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Because there are so many ways to authenticate users, it's convenient to have a unified approach to authentication that can handle multiple authentication systems for different needs. The Pluggable Authentication Modules (PAM) system is one such approach.

PAM was originally developed by Sun, and implementations are available for Solaris, FreeBSD, and especially Linux, where most PAM development is now centered. PAM provides a library and API that any application can use t

Table of Contents