Essential System Administration, Third Edition

Security discussions often begin by considering the kinds ofthreats facing a system. I'd like to come at this issue from a slightly different angle by focusing first on what needs to be protected. Before you can address any security-related issue on your system, you need to be able to answer the following questions:

• What are you trying to protect?

• What valuable asset might be lost?

If you can answer these questions, you've gone a long way toward identifying and solving potential security problems. One way to approach them is to imagine discovering one morning that your entire computer system/network was stolen during the previous night. Having this happen would upset nearly everyone, but for many different reasons:

• Because of the monetary cost: what is valuable is the computer as a physical object (loss of equipment).

• Because of the loss of sensitive or private data, such as company secrets or information about individuals (one type of loss of data).

• Because you can't conduct business: the computer is essential to manufacturing your product or providing services to your customers (loss of use). In this case, the computer's business or educational role is more important than the hardware per se.

Of course, in addition to outright theft, there are many other causes of all three kinds of losses. For example, data can also be stolen by copying it electronically or by removing the medium on which it is stored, as well as by stealing the computer itself. There is also both physical and electronicvandalism. Physical vandalism can mean broken or damaged equipment (as when thieves break into your office, get annoyed at not finding any money, and pour the cup of coffee left on a desk into the vents on the computer and onto the keyboard). Electronic vandalism can consist of corrupted or removed files or a system overwhelmed by so many garbage processes that it becomes unusable; this sort of attack is called a denial of service attack.

Depending on which of these concerns are relevant to you, different kinds of threats need to be forestalled and prepared for. Physical threats include not only theft but also natural disasters (fires, burst pipes, power failures from electrical storms, and so on). Data loss can be caused by malice or accident, ranging from deliberate theft and destruction to user errors to buggy programs wreaking havoc. Thus, preventing data loss means taking into account not only unauthorized users accessing the system and authorized users on the system doing things they're not supposed to do, but also authorized users doing things they're allowed to but didn't really mean or want to do. And occasionally it means cleaning up after yourself.

Once you've identified what needs to be protected and the potential acts and events from which it needs to be protected, you'll be in a much better position to determine what concrete steps to take to secure your system or site.

For example, if theft of the computer itself is your biggest worry, you need to think more about locks than about how often to make users change their passwords. Conversely, if physical security is no problem but data loss is, you need to think about ways to prevent data loss from both accidental and deliberate acts and to recover data quickly should loss occur despite all your precautions.

The final complication is that security inevitably corresponds inversely withconvenience: the more secure a system is, the less convenient it is to use, and vice versa. You and your organization will need to find the right set of trade-offs for your situation. For example, isolated systems are easier to make secure than those on networks, but few people want to have to write a tape to transfer files between two local systems.

The key to a well-secured system is a combination of policies that:

• Prevent every possible relevant threat, to the extent that they can be prevented and they can't always and the extent that you, your users, and your organization as a whole are willing to accept (or impose) the inconveniences that these security measures entail.

• Plan and prepare for what to do when the worst happens anyway. For example, the best backup plans are made by imagining that tomorrow morning you come in and all your disks have had head crashes. It's helpful to imagine that even the impossible can happen. If it's important that certain people not have access to the root account, don't leave root logged in on an unattended terminal, not even on the console in the locked machine room where these users can never get in. Never is almost always sooner than you think.

Threats can come from a variety of sources. External threats range from electronic joy-riders who stumble into your system more or less at random to crackers who have specifically targeted your system (or another system that can be reached by a route including your system). Internal threats come from legitimate users attempting to do things that they aren't supposed to do, with motivations ranging from curiosity and mischievousness to malice and industrialespionage. You'll need to take different steps depending on which threats are most applicable to your site.

In the end, good security, like successful system administration in general, is largely a matter of planning and habit: designing responses to various scenarios in advance and faithfully and scrupulously carrying out the routine, boring, daily actions required to prevent and recover from the various disasters you've foreseen. Although it may seem at times like pounds, rather than ounces, of prevention are needed, I think you'll find that they are far less burdensome than even grams of cure.

7.2.1 Security Policies and Plans

Many sites find written security policies and plans helpful. By "security policy," I mean a written statement for users of what constitutes appropriate and unacceptable uses of their accounts and the data associated with them. I'll refer to a written description of periodic security-related system administration activities as a "security plan." At some sites, the computer security policy is part of a more comprehensive security policy; similarly, an administrative security plan is often part of a more general disaster-recovery plan.

7.2.1.1 Security policies

Security policies are most effective when users read, understand, and agree to abide by them at the time they receive their computer accounts, usually by signing some sort of form (retaining a copy of the written policy for future reference). For employees, this usually occurs when they are hired, as part of the security briefing they attend sometime during the first few days of employment. In an educational setting, students can also be required to sign the written security policy when they receive their accounts. During my brief stint in academia, one of my tasks was to create and deliver aBITNET security presentation for students wanting network access; if I were a system administrator at a university now, I'd recommend requiring a general computersecurity awareness session before a student receives an account for the first time.

A good computer security policy will cover these areas:

• Who is allowed to use the account (generally no one but the user herself). Don't forget to consider spouses, significant others, and children as you formulate this item.

• Password requirements and prohibitions (don't reveal it to anyone, don't use a password here that you have ever used anywhere else and vice versa, etc.). It may also be worth pointing out that no one from the computing/system administration staff will ever ask for it by phone or in person, nor will anyone from a law enforcement agency.

• Proper and improper use of local computers and those accessed via the Internet. This can include not only prohibitions against hacking but also whether personal use of an account is allowed, whether commercial use of a university account is permitted, policies abouterotic/pornographic images being kept or displayed online, and the like.

• Conditions under which the user can lose her account. This item can also be somewhat broader and include, for example, when a job might be killed (when the system needs to go down for maintenance, when a job is overwhelming the system, and so on).

• Rules about what kinds of use are allowed on which computers (for example, when and wheregame-playing is allowed, where large jobs should be run, etc.).

• Consent to monitoring of all aspects of account activity by system administration staff as needed for system/network security, performance optimization, general configuration, and/or accounting purposes.

• Policies concerning how printed output is to be disposed of, whether it can leave the building or site, and similar policies for tapes and other media.

Some sites will need more than one policy for different classes of users. When you formulate or revise a written security policy, it may be appropriate to run it by your organization's legal department.

7.2.1.2 Security plans

Formulating or revising a security plan is often a good way to assess and review the general state of security on a system or network. Such a plan will address some or all of the following issues:

• General computer access policies: the general classes of users present on the system, along with the access and privileges that they are allowed or denied. Describing this will include noting the purpose and scope of the various user groups.

• Optional system security features that are in effect (password aging and other restrictions, user account retirement policies, and so on).

• Preventative measures in effect (for example, the backup schedule, actions to be performed in conjunction with operating system installations and upgrades, and the like).

• What periodic (or continuous) system monitoring is performed and how it is implemented.

• How often complete system security audits are performed and what items they encompass.

• Policies and strategies for actively handling and recovering from security breaches.

Like any policy or procedure, the security plan needs to be reviewed and updated periodically.

7.2.2 Unix Lines of Defense

At an individual system level, Unix offers three basic ways of preventing security problems:

• A variety of network security mechanisms designed to prevent unauthorized connections from being accepted (where unauthorized can be defined based on one or more characteristics: connection source, type of connection, service requested, and the like).

• Passwords are designed to prevent unauthorized users from obtaining any access to the system, even via allowed channels.

• File permissions are designed to allow only designated users access to the various commands, files, programs, and system resources.

In theory, network protection filters out all unauthorized connections, passwords prevent the bad guys from getting on the system in the allowed ways, and proper file permissions prevent normal users from doing things they aren't supposed to do. On a system that is isolated both physically and electronically, theory pretty well matches reality, but the picture becomes much more complicated once you take networking into account. And the various kinds of security mechanisms can interact. For example, network access often bypasses the normal password authentication procedures. For these reasons, in the end, your system is only as secure as the worst-protected system on the network.

Permissions, passwords, and network barriers are useful only as part of an overall security strategy for your system. I find it helpful to think of them in the context of the various "lines of defense" that could potentially be set up to protect your system from the various losses it might experience.

7.2.2.1 Physical security

The first line of defense is physical access to your computer. The most security-conscious installations protect their computers by eliminating all network and dialup access and strictly limiting who can get physically near the computers. At the far extreme are systems in locked rooms (requiring a password be entered on a keypad in addition to the key for the door lock), isolated in restricted access areas of installations with guarded entrances (usually military or defense-related). To get onto these systems, you have to get into the site, into the right building, past another set of guards in the secure part of that building, and finally into the computer room before you even have to worry about having a valid password on the system. Such an approach effectively keeps out outsiders and unauthorized users; thus, security threats can come only from insiders.

Although this extreme level of physical security is not needed by most sites, all administrators face some physical security issues. Some of the most common include:

• Preventing theft andvandalism by locking the door or locking the equipment to a table or desk. If these are significant threats for you, you might also need to consider other aspects of the computer's physical location. For example, the best locks in the world can be basically worthless if the door has a glass window in it.

• Limiting access to the console and the CPU unit to prevent someone from crashing the system and rebooting it to single-user mode. Even if your system allows you to disable single-user-mode access without a password, there still may be issues here for you. For example, if your system is secured by a key position on its front panel, but you keep the key in the top middle drawer of your desk (right next to your file-cabinet keys) or inserted in the front panel, this level of security is effectively stripped away.

• Controlling environmental factors as much as realistically possible. This concern can include special power systems (backup generators, line conditioners, surge suppressors, and so on) to prevent downtime or loss of data, and fire detection and extinguishing systems to prevent equipment damage. It also includes simple, common-sense policies like not putting open cups of liquid next to a keyboard or on top of a monitor.

• Restricting or monitoring access to other parts of the system, like terminals, workstations, network cables (vulnerable to tapping and eavesdropping), and so on.

• Limiting access to backup tapes. If the security of your data is important to your system, backup tapes need to be protected from theft and damage as well (see Chapter 11). Keep in mind also that backup tapes contain sensitive system configuration data: the password and shadow password file, security key files, and so on.

7.2.2.2 Firewalls and network filters

Packet filtering and dedicated firewall systems represent an attempt to mitigate the risks associated with placing systems on a network. A firewall is placed between the Internet and the site to be protected; firewalls may also be used within a site or organization to isolate some systems from others (remember that not all threats are external). Packet filtering restricts the sort of network traffic that a system will accept.

We'll look at both of these topics in more detail later in this chapter.

7.2.2.3 Passwords

When someone gains access to the system, passwords form the next line of defense against unauthorized users and the risks associated with them. As I've said before, all accounts should have passwords (or be disabled). The weakness with passwords is that if someone breaks into an account by finding out its password, he has all the rights and privileges granted to that account and can impersonate the legitimate user in any way. File permissions form the next line of defense, against both bad guys who succeeded in breaking into an account and legitimate users trying to do something they're not supposed to. Properly set up file protection can prevent many potential problems. The most vulnerable aspects of file protection are the setuid and setgid access modes, which we'll look at in detail later in this chapter.

Some Unix versions also provide other ways to limit non-root users' access to various system resources. Facilities such as disk quotas, system resource limits, and printer and batch queue access restrictions protect computer subsystems from unauthorized use, including attacks by"bacteria" designed specifically to overwhelm systems by completely consuming their resources.^[1]

^[1] It seems that no new type of security threat is uncovered without acquiring a cute name. Bacteria, also known as rabbits, are programs whose sole purpose is to reproduce and thereby overwhelm a system, bringing it to a standstill. There are a few other creatures in the security jungle whose names you should know. Viruses are programs that insert themselves into other programs, often legitimate ones, producing noxious side effects when their host is later executed. Worms are programs that move from system to system over a network, sometimes leaving behind bacteria, viruses, or other nasty programs. Trojan horses are programs that pretend to do one thing while doing another. The most common type is a password-stealing program, which mimics a normal login sequence but actually records the password the user types in and then exits. The term is also applied to programs or commands embedded within certain types of files that get executed automatically when the file is processed (PDF files, PostScript files, and attachments to electronic mail messages). Back doors, also called trap doors, are undocumented, alternative entrances to otherwise legitimate programs which allow a knowledgeable user to bypass security features. Time bombs are programs designed to perform particular usually destructive actions at a specific date and time. Programs with time bombs may be benign or inactive until the designated moment. In practice, these creatures often work in concert with one another.

If someone succeeds in logging in as root (or breaks into another account with access to important files or other system resources), system security is irreparably compromised in most cases. When this happens, the administrative focus must shift from prevention to detection: finding out what has been done to the system (and repairing it) and determining how the system was compromised and plugging that gap. We'll look at both preventing and detecting security breaches in detail in the course of this chapter.

7.2.2.4 Encrypting data

There is one exception to the complete loss of security if the root account is compromised. For some types of data files,encryption can form a fourth line of defense, providing protection against root and other privileged accounts.

7.2.2.5 Backups

Backups provide the final line of defense against some kinds of security problems and system disasters. In these cases, a good backup scheme will almost always enable you to restore the system to something near its previous state (or to recreate it on new hardware if some part of the computer itself is damaged). However, if someone steals the data from your system but doesn't alter or destroy it, backups are irrelevant.

Backups provide protection against data loss and filesystem damage only in conjunction with frequent system monitoring, designed to detect security problems quickly. Otherwise, a problem might not be uncovered for a long time. If this occurs, backups would simply save the corrupted system state, making it necessary to go back weeks or months to a known clean state when the problem finally is uncovered and restore or re-create newer versions of files by hand.

7.2.3 Version-Specific Security Facilities

Every commercial Unix version we are considering offers an enhanced security facility of some sort, either as part of the normal operating system or as an optional layered product; we'll consider many of their features in the course of this chapter. The primary commands associated with these facilities are listed below as an aid to your own explorations of what is available on your systems (in other words, check these manual pages first). I've also listed some related facilities available on FreeBSD and SuSE Linux systems:

man -k secur (to match "secure" and "security") will also often yield information, as will consulting any security manual or manual chapters in the system documentation.