15.2 Securing the Host Computer

only for RuBoard - do not distribute or recompile

Here are some of the ways you might go about defending your computer system from these individuals.

15.2.1 Security Through Policy

It's tempting to approach host security as a checklist of do's and don't's for computers and networks. After all, to damage a computer, an attacker must have access. So in theory, to operate a secure system, all you need to do is to block all of the venues by which an attacker can get access, and the resulting system will be secure.

In practice, however, it has proved nearly impossible to have a computer that offers services over the network and yet still denies all access to attackers. Often access comes through unintended holes, such as a carelessly coded CGI script (see Chapter 16), or a buffer overflow attack that is known to the attacker but not the computer's operators.

Instead of approaching host security as a laundry list of specific technical action items, it's better to look at the kinds of practices that make computers less secure, and then explore the specific policy initiatives that you can implement to improve your security outlook.

For more than a decade, there have been nine widespread practices on the Internet that make host security far worse than it needs to be. These practices are:

Failure to think about security as a fundamental aspect of system setup and design (establishing policy)
Purchase and configuration of computing systems based on issues of cost or compatibility rather than on the desired functionality and security needs
Transmitting of plaintext, reusable passwords over networks
Failure to use security tools properly, if they are used at all
Failure to obtain and maintain software that's free of all known bugs and security holes
Failure to track security developments and take preventative action
Lack of adequate logging
Lack of adequate backup procedures
Lack of adequate system and network monitoring

Security is defined by policy. In some environments, every user is allowed to install or modify the organization's web pages. In others, only a few users are allowed to even read the pages. In some environments, any user can shut down or reboot the system. In others, it requires signed authorization from the CIO to so much as replace a file.

Policy helps users understand what is allowed. Policy guides administrators and managers in making choices about system configuration and use. Policy helps designers create systems that realize the organization's goals. The most basic security is a clear statement of what actions are allowed and disallowed, and by whom. Standards and guidelines should include the answers to these questions:

Who is allowed access, what is the nature of that access, and who authorizes such access?
Who is responsible for security, for upgrades, for backups, and for maintenance?
What kinds of material are allowed on served pages?
Which sites and external users are to be allowed access to pages and data served?
What kinds of testing and evaluation must be performed on software and pages before they are installed?
How will complaints and requests about the server and page content be handled?
How should the organization react to security incidents?
How and when should the policy itself be updated?
Who is allowed to speak to members of the press, law enforcement, and other entities outside the organization in the event of questions or an incident?

We recommend that your policy documents be written and made available to everyone associated with your organization. Care given to the development of the policy can head off lots of potential problems.

15.2.2 Keeping Abreast of Bugs and Flaws

The Internet is a powerful tool for transmitting information. In a matter of minutes, news of the latest security flaw can be sent around the world and read by thousands or hundreds of thousands of individuals who may be eager to exploit it. Some of these individuals may attempt to break into your computer with their new knowledge. Sometimes they may be successful.

Thus, if you administer a computer that is connected to the Internet, it is important that you monitor bulletins issued by your vendor and that you install security-related patches as soon as they are made available. Most vendors have mailing lists that are specifically for security-related information.

Another source of information are FIRST^[6] teams such as the CERT/CC (Computer Emergency Response Team, Coordination Center) at the Software Engineering Institute. The CERT/CC collects reports of computer crime, provides the information to vendors, and distributes information from vendors regarding vulnerabilities of their systems. Experience over time, however, has shown that CERT/CC and many other response teams do not make information available in a timely fashion. We suggest that you monitor announcements from the response teams, but that you don't depend on them as your primary information source.

^[6] Forum of Incident Response and Security Teams, the worldwide consortium of major computer incident response groups. Visit http://www.first.org for more information.

Most software vendors maintain their own mailing lists of patches and announcements. You would be well-advised to subscribe to the lists of all your component vendors, including those of your routers and switches. If your ISP has a list, be sure to be on that one, too.

As a backup, you might also subscribe to one or two of the security-related mailing lists, such as nt-security, bugtraq, and firewalls.

Before you install any patch, be sure it is an authentic patch provided by your vendor. You can often check a file's digital signatures and cryptographic checksum to determine the authenticity and integrity of a patch before you install it. Also, be very wary of applying patches found in mailing lists and on bulletin boards: at worst, they may be planted to trick people into installing a new vulnerability. At best, they are often produced by inexperienced programmers whose systems are unlike yours, so their solutions may cause more damage than they fix. Caveat emptor!

15.2.3 Choosing Your Vendor

Today there are many choices for organizations setting up web-based services. Should your computer run Windows, Mac OS, Unix, or a "free" Unix-like operating system? Should your computer system use an "industry-standard" Intel-compatible microprocessor, or a SPARC, PowerPC, or another processor? Should you purchase the computer with or without support? What level of support is appropriate?

Many purchase decisions are based on factors such as the cost of the system, the reputation of the vendor, and the experience of the person making the purchase. Few organizations base their purchase decisions on the security of the underlying system.

Some vendors and platforms have better security pedigrees than the others, because different manufacturers value code quality and security differently. But the size of the user base also affects the security that a system will provide even relatively secure systems can become "unsecure" in the face of a large number of well-funded adversaries who widely publicize their findings.

Considering the importance of a reliable computing platform, it is amazing how many organizations will continue to purchase software from vendors whose products have suffered repeated security vulnerabilities. One of the biggest threats to the security of your system is the presence of software faults or bugs. These can cause your web server or client to crash, corrupt your information, or, worst of all, allow outsiders unauthorized access.It is stunning to see how many organizations are willing to operate mission-critical systems on "beta" or "pre-beta" software releases. It is difficult to understand Chief Information Officers who say that they know the product that they are purchasing is buggy, filled with vulnerabilities, and likely to increase the costs of their operations, but they feel that they have no choice but to purchase the software because "everybody else" is buying the same software.

As a large number of web sites are based on Windows NT running on Intel-compatible microprocessors, there is an incredibly high incentive for attackers to find vulnerabilities with this configuration.^[7] For this reason, some organizations have decided to deploy uncommon configurations such as OpenBSD running on Solaris SPARC computers simply because fewer attackers have experience with these systems.

^[7] There are other reasons why Microsoft products seem to be a favorite of attackers. These include the large numbers of vulnerabilities that keep being discovered, the complexity of the software which makes the software difficult for administrators to secure, and the simple fact that Microsoft is disliked by many people.

While the underlying operating system is important, equally important are the applications and the customized software that are layered on top of this base. A secure underlying system can be made vulnerable by a single vulnerable script that was written by a consultant to provide additional functionality.

Some steps that you should follow before specifying and deploying a new system include:

Determine which vendors have the best reputation for producing bug-free, well-documented software. Vendors place different levels of emphasis on code quality and security. Find out what specific measures your vendors use to assure high security such as the security criteria that they employ, data flow analysis, code audits, and/or penetration testing. Ask the vendors for copies of their metrics and test evaluations from reviews. You might also check the historical trends associated with the discovery and reporting of security flaws in software by that vendor. One source may be found at http://www.securityfocus.com/cgi-bin/vulns.pl. (Because of the evolution in generally accepted methods of flaw discovery and reporting, we suggest that you don't use figures before 1997 or so in your evaluation, as they may not be reliable.)
Investigate how your proposed vendors respond to reports of security or performance-relevant faults in their products. Is your proposed vendor timely and open in dealing with problems? Some vendors have a history of ignoring users unless there is significant bad press from complaints or incidents. These vendors should be avoided.
Explore the importance your vendor attributes to good design, with issues of security, safety, and user interfaces. Systems resistant to attacks and user mistakes are much better to use in situations where you need dependable operation.
Determine whether your organization would be better off using "old-generation" software for which the problems are presumably well-known, or "leading-edge" software that offers new features.
Choose the system with the least number of features that does what you want well. Hardware is relatively inexpensive: buying a system to devote to a reduced configuration for a web server (for example) may be a better purchase than a clone of one of your standard systems that results in a massive break-in.

Here are some things to request or require when shopping for software and systems:

Proof that good software engineering practices were followed in the design, coding, and testing of the software.
Documentation showing the results of testing the software and system in environments similar to yours. Ideally, testing should include both operational testing and stress testing.
A written statement of the vendor's policy for accepting, documenting, and responding to reports of faults in the product.
A written statement of how the vendor notifies customers of newly fixed security flaws. (The most responsible vendors release notices through FIRST teams and through customer mailing lists; the least responsible vendors never announce fixes, or bury them in lists of other bug fixes in obscure locations.)
Examples of previous notifications and bug fixes.

Although the computer industry is beginning to take computer security seriously, more change is needed. It is still the case that no software vendor will warrant its products against losses related to unsecured code not even the vendors of security products. Typically, losses are limited to the cost of the media upon which the product was distributed.

A few insurance companies are now issuing policies to cover losses from break-ins and defacements of web sites. You should investigate these policies to see if there are different rates for different systems. As time goes on, rates should adjust to reflect the configurations that present less risk (and thus warrant smaller premiums).^[8]

^[8] As of late 2001, at least one insurance company charges higher premiums to customers using Windows and/or IIS as platforms.

To date, the major force for change appears to be public humiliation in the news media. One approach that still needs to be attempted is product liability lawsuits. In the meantime, if you add your voice to those of others requiring better security, you not only help raise awareness, but you should be able to protect yourself somewhat by making a better platform choice.

15.2.4 Installation I: Inventory Your System

Once you have decided upon a vendor, hardware platform, and software, you need to install everything. Installation is an extremely important process. Frequently, mistakes made during installation can come back to haunt you after you have brought your system online and gone on to other projects. So take your time and be certain of what you are doing.

First, it's important to inventory all of your systems. Write down the serial numbers, the amount of RAM, the kinds of processors, option cards, and other hardware configuration options. Make sure that you have copies of this information in at least two locations one easy way to do so is to type the information into a spreadsheet and email a copy to yourself at home. This information will be useful for diagnosing performance issues. If you suffer a theft or loss, it will be useful for insurance purposes, too.

You should also inventory your software. For each product, note the vendor, the distribution, and the release. If you have software that comes with activation codes, it may be useful to record these as well. However, if you record the activation codes, you should attempt to secure them, because the distribution of activation codes could be considered software piracy by some vendors. (Distribution of more than ten activation codes with intent to defraud may be a felony under U.S. law.)

Be sure that you save all of the original packing material, documentation, blow-in inserts, and other information that comes with your computers and software. This can be critical if you are returning the equipment or need to relocate it. It is also surprising how many companies put vital information on seemingly innocuous printouts. Frequently, last minute inserts can be security or safety warnings, so be sure to at least glance at every piece of paper that you receive with your hardware and software.

15.2.5 Installation II: Installing the Software and Patches

Before you start to install the software for your computer, check the web site of each vendor to make sure you have all of the security patches and bug fixes for the version of the software that you intend to install. It is a good idea to read the release notes for both the base operating system and the patches. Some vendors distribute patches that must be installed in a particular order installing the patches out of order can sometimes result in security vulnerabilities being reintroduced!

Next it is time to start installing your software. If at all possible, you should disconnect your computer from the Internet at the start of the installation procedure and not connect it until you are finished. There are many recorded cases of computers connected to the Internet being compromised between the time that the computer's base operating system was installed and the time that the patches were going to be installed. Unfortunately, it is increasingly difficult to install updates and register without software being connected to the Internet.

Once you have made sure that your computer is not connected to the Internet, install the computer's base operating system, any operating system patches, then the application programs and the application patches. Keep a notebook and record every specific action that you take. Such a log can be immensely useful if you are going to be installing several computers and hope to delegate the activity to others.

At this point, before any further work is done, you should make a complete backup of the computer system. This backup will be invaluable if your computer is compromised by an attacker or a hardware failure.

After your first backup is finished, you can make any local customizations that are required. You should then make a second backup of your computer system onto a different tape, CD, or disk.

Finally, make sure that all of the distribution software and the backups are stored in a place that is safe and will not be forgotten. Make sure that physical access to the computer is restricted. You may also wish to remove the floppy disk drive or CDs to make it more difficult for a person who has physical access for a brief period of time to compromise your server.

only for RuBoard - do not distribute or recompile