Web based School

Previous Page Main Page Next Page

  • 44 — UNIX System Security

    • 44 — UNIX System Security

      How secure is your UNIX system? Consider this: In the three years 1991 through 1993, the Computer Emergency Response Team Coordination Center (CERT/CC) issued more than 60 advisories describing UNIX insecurities and ongoing cracking incidents. That's almost two per month for the last three years. Many of these advisories described serious security flaws that allowed unprivileged users to gain superuser access, or worse, allowed unauthorized users access to the computer. If you haven't done anything to improve the security of your UNIX system, it's probably vulnerable.

      The original developers of UNIX used it in a friendly, collegial environment that required only basic security features. Computer networks were a future dream. Since then UNIX has become one of the most popular operating systems in the world, installed on hundreds of thousands of networked computers. As it has evolved, security features have been added, but so have new facilities that have brought new security threats.

      Why would someone break in to your computer? It boils down to access to services and information. Computers provide a variety of attractive services, such as access to networks and other computers, computing time, and disk storage. Most people use computers to store and organize valuable information. This information has potential value to those who don't have it, and unscrupulous people will do whatever it takes to get it.

      Does your computer system contain information that someone else can use? Your company's trade secrets? A description of an academic research project or a grant proposal that you want to keep secret until it's in the mail? Most people can answer yes to these or similar questions—after all, you wouldn't be storing information on a computer if you didn't have something worth saving.

      This chapter can't tell you everything you need to know about UNIX system security. That would take an entire guide, and there are references to several "nuts and bolts" security guides in the section "Finding More Information" later in this chapter. This chapter does give you a broad overview of UNIX security concerns, help you evaluate your security needs, tell you about tools you can use to improve your system's security, and tell you how to get more information. It may also help keep your hair from turning various shades of gray.

      Kinds of Attacks and Their Consequences

      Although it may seem like a naive question, you should ask yourself why you care whether your system is attacked. What are the consequences if someone breaks in? If a cracker breaks in to your system, he may do the following:

      • Use system resources (disk space, CPU cycles, network bandwidth) you want for you or other users

      • Deny services to you or other users, either maliciously or because he's using the resources himself

      • Steal valuable information

      • Destroy files, either maliciously or to cover his tracks

      • Use your computers to break in to other sites

      • Cause you to lose staff time (read: money) in tracking him down and putting compromised systems back in order

      You must analyze your own situation and decide how important these consequences are to you. You may have CPU cycles and disk space to spare, no information to protect. You may not really care if other system administrators spit on the ground when they hear your name, and therefore decide to run a completely open system. On the other hand, you might lose your job if your company loses a contract because of industrial espionage. Most security needs fall somewhere between these two extremes, but you can see that security is a continuum, and you're in the best position to decide your own security requirements.

      All attacks depend on gaining initial access to the computer. You should put yourself in the cracker's shoes and think about how you could attack your own system. Is it used by you alone or by many people? Is it accessible via a phone line, or connected to a private or public network? If it's connected to a network, is the network physically secure? Are your computers locked up or in a public site? Where are your backup tapes stored? Can a cracker get access to them, thereby gaining access to your files without ever breaking into your computer? If you're responsible for administering a multiuser system, how wise are your users? What will they do if they receive a phone call from the "system administrator" asking for their passwords for "special maintenance?"

      These questions cover many—but not all—of the approaches a cracker might use to gain access to your computer or data. The attacks fall into four basic categories: physical security attacks; social engineering attacks; Dumpster-diving attacks; and network- and phone-based attacks.

      The point of any attack is to gain access to a legitimate user's account, or to exploit bugs in system programs to get a command shell without actually compromising an account.

      NOTE: Computer viruses are programs that attach themselves to other programs and replicate when the infected programs are executed. Some viruses are relatively benign, but some malware can erase or damage disk files. Viruses are a big problem in the MS-DOS and Macintosh world because personal computers lack the sophisticated memory and file protection mechanisms of mature operating systems like UNIX.

      Although a few theoretical UNIX viruses have been presented in academic journals, to date there have been no widespread outbreaks of UNIX viruses. There are plenty of things to worry about regarding the security of your UNIX system, but viruses are not one of them.

      Physical Security

      If your computer is locked in a room with a guard who checks IDs at the door, and isn't connected to a network or a phone line, you can skip to the next chapter. Unfortunately, computers are pretty useless when they're sitting in locked rooms, and most of them aren't. A cracker who gains physical access to your computer or the network to which it's attached may be able to tap the physical network and snoop legitimate users' passwords or data, reboot the computer with a different version of UNIX, or modify values in RAM memory to gain privileged access.

      The first type of attack is becoming difficult to prevent. Laptop computers now have pocket-size EtherNet cards that plug into PCMCIA slots, and there is free, public-domain software that captures all packets on an EtherNet and saves them on a computer's hard disk. A cracker can unplug one of your computers from the EtherNet, attach his laptop, record packets for a while, and analyze them later to find valid login names and passwords. Even worse, if your users log in to remote systems with ftp, telnet, or rlogin, the cracker doesn't need access to the physical network at your site—anyplace between your site and the remote one will do. One-time passwords, Kerberos, and encrypting EtherNet hubs can help solve these problems.

      Many workstations have a ROM-monitor mode that is entered by typing a special key combination. This mode suspends the normal operation of UNIX to allow you low-level access to the computer's hardware. It may allow you to reboot the computer or alter memory locations and resume running UNIX.

      If a cracker can boot an operating system of her choice and masquerade as the legitimate computer, she can do any number of bad things. If your workstations have CD-ROMs, floppy disks, or tape drives and can be booted from those devices, the door may be open. A cracker who can boot an operating system of his choice while retaining a computer's identity can trick that computer or others on your network into providing illicit access or services.

      A workstation that allows the user to change system memory while in ROM-monitor mode gives a cracker who has gained access to an unprivileged account the chance to promote it to the superuser account by changing the numeric user ID in RAM to 0.

      Most workstations provide a way to prevent users other than the system administrator from entering ROM-monitor mode such as a password. Check your system administration manual to ensure that you've enabled whatever ROM-monitor security features are available, and avoid buying workstations that allow unrestricted access to this mode.

      Social Engineering

      Social engineering is a euphemism for the phenomenon P.T. Barnum had in mind when he said "There's a sucker born every minute." More kindly, most people are trusting, and that trust can be exploited by system crackers.

      Social engineering might be a seemingly innocuous offer to "help set up your account," or the gift of a free program that purports to do one thing but does something else (a Trojan horse). Either offer gives the cracker the chance to alter a legitimate user's files so he can later gain access to the account. Another popular approach is to send e-mail to naive users, saying that system security has been compromised, and the victim must change her password to one specified by the cracker. Calling a legitimate user on the phone, claiming to be the system administrator, and asking for the user's password on a pretext is another example of social engineering. Social engineering approaches shouldn't be taken lightly—they are surprisingly effective.

      As you may guess, the best defense against social engineering is user and staff education. Your users should know, for instance, that since you have superuser privileges you never have any reason to ask for their passwords, and that any such request should be reported to you immediately. Part of the goal of a security policy (see the section "Security Policies" later in this chapter) is to educate your users.

      Dumpster-Diving Attacks

      Rummaging through your company's trash bins may produce good results for a cracker: unlisted modem numbers, lists of valid accounts, passwords, discarded diskettes or tapes, and other helpful information. You may want to review how your organization disposes of waste paper, storage media and used computer equipment, and make changes if you feel that crackers can get a helping hand from your discards.

      Network- and Phone-Based Attacks

      If your computer system is attached to a network it is both a more attractive target and easier to crack. Physical access to the computer is no longer necessary, since the cracker can connect with a modem or over the network. If you are connected to the Internet (network of networks), your system can be attacked from anyplace in the world.

      Physical network-based attacks like those described earlier in this chapter in the section "Physical Security" are a form of network-based attack. However, physical access to the network is not necessary for network or phone-based attacks—all you need is (legitimate or illegitimate) access to a computer on the Internet, or a terminal and a modem.

      Attacks of this kind fall into two general categories: breaking into a user or system account by guessing its password, and tricking a network server program into giving you information about the system (for instance, the password file) or into executing commands to give you access to the computer.

      You can thwart the first attack by ensuring that all system accounts (for example, the ftp account) have strong passwords or are shut off; and by educating, cajoling, and coercing your users into choosing good passwords, or switching to one of the one-time password schemes described in the section "User Authentication" later in this chapter.

      The second attack is harder to stop because it depends on something over which you have little control—the quality of vendor software. Your best defense is to keep abreast of current bugs by joining mailing lists, reading the appropriate USENET newsgroups, tracking CERT/CC and other advisories, and taking advantage of any security alerts your vendor may offer. This gives you the information you need to patch problems quickly. The various ways of keeping up with the crackers are explained later in this chapter in the section "Finding More Information."

      You may also want to run public-domain replacements for some vendor software, for instance the public-domain Version 8 sendmail program. (See Chapter 41, "Mail Administration.") Most public-domain programs come with complete source code, which allows you to fix bugs without waiting on the vendor. Further, the authors of public-domain programs are often quicker to fix bugs than vendors.

      Phone-based attacks either attempt to guess passwords, or (if you run it) trick a program like UUCP (UNIX to UNIX File Copy). The first problem is solved by the methods mentioned in the previous paragraph. Dial-back modems help with either attack and are covered in the section "Hardware Solutions" later in this chapter.

      Security Policies

      If your computer or network of computers is used by someone other than you, then you need a security policy (also known as a proper use policy.) Your security policy is your chance to do a little social engineering of your own, and it educates your users, garners support from management, and sets standards of proper behavior for users and system administrators.

      User education is important because security is often inconvenient and users are devious—they will thwart your best-laid plans unless they understand the reasons for the inconvenience. Many users may feel that their account security is a personal matter, similar to the choice of whether to wear seat belts while driving. However, a multiuser computer system is a community of sorts, and one weak account is all a cracker needs to compromise an entire system.

      Because security is inconvenient, you also need the support of management to enforce potentially unpopular security policies. Management will be more receptive to user inconvenience if you present evidence of the costs of a break-in, for instance an estimate of how much staff time it would take to restore your systems to a clean state after a break-in, or the cost to your company of theft of information.

      Finally, a security policy tells users how you expect them to use the system, the consequences of misuse, and what actions you may take to investigate alleged misuse.

      Not so long ago, a system administrator who suspected a user of the slightest wrongdoing would put on his shiny jackboots and stomp through users' files and electronic mailboxes like a hog rooting for truffles, looking for "evidence." If he found any, the user got booted from the system. Then came the ECPA (Electronic Communications Privacy Act) of 1986, a federal law that provides criminal penalties for invading the privacy of users of computer systems and networks.

      The ECPA legal waters are still murky because there hasn't yet been enough case law to clarify the intent of Congress. Since you probably don't want to be on the receiving end of such a clarification, you should act cautiously when gathering evidence. A security policy that clearly states what actions the systems administrator may take in investigating security incidents helps protect you from the possibly untoward consequences of "just doing your job." However, this is not legal advice—if you are concerned about how the ECPA may affect you, consult a lawyer, preferably one with expertise in computer law.

      Before developing a security policy you should answer the following questions: What information and resources are you protecting? Who may want to break in? What are the likely consequences of a break-in?

      If you don't know what you're protecting, you can't decide how strong your security profile should be. You have to have some idea of who the crackers may be because they come in all shapes and sizes. They vary from the kid in the basement with a Commodore 64, who wants to take your system for the computer equivalent of a joyride, to sophisticated industrial spies who may set up housekeeping on your system, covering their tracks by altering programs and log files. The consequences of a break-in depend on the value of the information and resources you're protecting, and the cost of recovery. Since a security policy usually imposes some inconveniences on your system's users and you want their cooperation in implementing it, you should tailor it to minimize inconvenience while maintaining the level of security your site needs.

      A large collection of security policies is available for anonymous ftp from the host ftp.eff.org in the directory pub/CAF/policies. The USENET newsgroup comp.admin.policy is another good resource for getting feedback on a security policy.

      User Authentication

      Authentication is a fancy name for identifying yourself as a valid user of a computer system, and it's your first defense against a break-in. Until recently, UNIX user authentication meant typing a valid login name and password. This is known as reusable password authentication, meaning that you enter the same password each time you log in. Reusable password authentication is too weak for some systems and will eventually be replaced by one-time password systems in which you enter a different password each login.

      Reusable passwords are strong enough for some sites as long as users choose good passwords. Unfortunately, many don't—research has shown that as many as 30%—50% of passwords on typical UNIX systems can easily be guessed. Your security policy should both require strong passwords and provide guidelines for choosing them.

      Picking Good Passwords

      Good passwords are 6—8 characters long, use a rich character set (upper- and lowercase letters, digits, punctuation, and control characters), are not in English or foreign-language dictionaries, and don't contain any public information about you, such as your name or license number. Detailed guidelines for choosing passwords are presented in the security guides mentioned in the section "Finding More Information" later in this chapter, but one good method is to take a random phrase and modify it in ingenious ways. For instance, the phrase "If pigs had wings" could yield the password "1fpiGzhw." This password is a combination of a misspelled word ("1f" standing for "if"), a misspelled word with odd capitalization ("pigZ"), and the first letters of two more words. It's as secure as a reusable password can be since it isn't found in any dictionary and uses a fairly rich vocabulary (the digit "1" and capitalization), and it's easy to remember (but not to type).

      Password choice is one of the areas in which users will deviously (and sometimes maliciously) thwart your security policies—some people can't be convinced that they should pick a good password. You have two alternatives for these recalcitrant users: proactive and retroactive password vetting.

      Password screening

      Retroactive password vetting puts you in the role of the cracker. You make your best effort to break your users' passwords, and if you succeed you notify the user and require her to change her password to something safer. The public domain program crack, written by Alec Muffett and available for anonymous ftp from ftp.cert.org and other sites, is one of the best. crack uses various tricks to permute login names and finger information into likely passwords and whatever word lists you specify. If you've got the disk space and CPU cycles you can feed crack the huge English and foreign-language word lists available for ftp from the host black.ox.ac.uk.

      The problem with crack and similar programs is that users hate being told that you've cracked their passwords—it's kind of like having a neighbor say, "By the way, I was rattling doorknobs last night and noticed that yours wasn't locked." However, crack is useful for gathering information you can use to make a case to management for stronger password security. For instance, if you can show that 30 percent of your users' passwords are easily guessed, you may be able to persuade your boss that proactive password screening is a good idea. And if you do plan to crack passwords, your users may react more positively if you make that clear in your security policy.

      Proactive password screening is more like a preemptive strike—if you prevent your users from choosing poor passwords, there's no reason to run crack. With proper education via your security policy users will react more positively (or at least less negatively) to being told they must choose a more secure password than to being told that you broke their current one. The passwd+ and npasswd programs screen passwords and can replace your standard passwd program. passwd+ is available for ftp from the host ftp.wustl.edu and others, and npasswd from ftp.luth.se.

      If you have source code for your system's passwd program you can modify it to call the cracklib library of C functions. cracklib is also authored by Alec Muffett and makes checks similar to crack. A password that gets by cracklib's screening is not likely to be guessed, especially by crack. cracklib is available from ftp.cert.org and other hosts.

      Password for System Accounts

      The system administrator must take special care in choosing a good password for her account and the superuser account. The superuser account must be protected because of the power it gives a cracker, and the system administrator's account because it can give access to the superuser account in many ways. For instance, if a system administrator's account is broken, the cracker can install a fake su program in his private bin directory that records the root password, removes itself, and then invokes the real su program. The system administrator account may have other special privileges that a cracker can make use of; for instance, membership in groups that allow you to read—or worse, write—system memory or raw disk devices, and permission to su to the superuser account. The systems administrator and root passwords should be changed often and should be as strong as you can make them.

      Password Aging

      SVR4 UNIX also provides password aging facilities. Password aging places a time limit on the life of a password. The longer you keep the same password, the better the chance that someone will crack it, either by guessing it, watching you type it, or by cracking it offline on another computer. Changing passwords every 1—6 months is sufficient for many sites, and password aging enforces that policy by requiring users to change their passwords when they expire. However, a poor implementation of password aging is worse than none at all. Users should be warned a few days in advance that their passwords will expire, because they may choose poor passwords if forced to choose on the spur of the moment.

      Shadow Passwords

      SVR4 UNIX also provides shadow passwords. UNIX passwords are encrypted in the password file, but access to the encrypted version is valuable because it allows a cracker to crack them on her own computer. A fast personal computer can try thousands of guesses per second, which is a huge advantage for the cracker. Without access to the encrypted passwords, the cracker must try each of her guesses through the normal login procedure, which at best may take five to ten seconds per guess.

      Shadow passwords hide the encrypted passwords in a file that is readable only by the superuser, thereby preventing crackers from cracking them offline. You should use them.

      One-time Passwords

      Reusable passwords may be a serious problem if your users use your site to connect to remote sites on the Internet or if your local network is not physically secure. On February 3, 1994, the CERT/CC issued advisory CA-94:01. Crackers had broken into several major Internet sites, gained superuser access, and installed software to snoop the network and record the first packets of telnet, ftp, and rlogin sessions, which contain login names and passwords. According to the CERT/CC advisory, "_all systems that offer remote access through rlogin, telnet, and FTP are at risk. Intruders have already captured access information for tens of thousands of systems across the Internet" (emphasis added).

      Internet programs such as telnet send unencrypted passwords over the network, making them vulnerable to snooping. The only way to truly solve this problem is to change the protocols so that user authentication doesn't require sending passwords over the network, but that won't happen soon.

      Reusable passwords are valuable precisely because they're reusable. One-time passwords get around this problem by requiring a new password for each use—the bad guys can sniff all they want, but it does them no good since the password that logs you in on Tuesday is different from the one you used Monday.

      Smart Cards

      Smart cards are one way to implement one-time passwords. Users are issued credit card—sized devices with numeric keypads and a PIN (personal identification number) that acts as the password for the card. When the user logs in to the computer it issues a challenge, which the user types into the smart card, along with her PIN. The smart card encrypts the challenge with other information such as the time, and displays a response, which the user types to the computer to log in. The computer generates a different challenge for each login. Each response is unique and can't be reused, so it doesn't matter if the challenge and response strings are sniffed. If the card is lost or stolen the login name and PIN are still required for the card to be used. Smart cards are a good solution to the reusable password problem, but they are too expensive for many sites.


      S/Key is a solution for sites that can't afford smart cards. S/Key generates a sequential list of unique passwords and uses a different one for each login, but without using a smart card. Suppose that you log in to your computer from home over a phone line, or perhaps from a commercial Internet service provider. Your home computer runs an S/Key program that takes the place of a smart card by producing a response to the computer's challenge string, which is also generated by S/Key. If you're using a terminal that can't run S/Key, or a computer that doesn't have S/Key installed, you can generate a list of passwords to be entered sequentially in future logins.

      S/Key also provides a duress password that you enter to let the computer know that the bad guys have a gun to your head, and that although you want access now, you also want to invalidate the current password sequence. This is also useful if you lose your list of passwords and want to invalidate them until you can generate a new one.

      The disadvantage of S/Key is that it may require you to carry around a list of valid passwords, which you could lose. However, as long as your login name doesn't appear on that list, a cracker still must guess that and the name of your computer. Further, since a list the size of a credit card can hold hundreds of passwords, and you only have to remember which one is next, the cracker still has to guess which of the passwords is next in the sequence. An advantage of S/Key is that it doesn't require a smart card. It's available for anonymous ftp from the hosts thumper.bellcore.com and crimelab.com.

      Equivalent Hosts and .rhosts Authentication

      UNIX provides two mechanisms for authenticating yourself to other hosts on a network after you've logged in to one. Suppose that your organization has 10 workstations, named ws1, ws2,_ws10. Since the workstations are all administered by you, one should be as trustworthy as another. If you log in to ws3 you would like to get access to ws5 without providing a password, since you already gave one when you logged in to ws3. You can do this for your account alone with a .rhosts file, and for all the accounts on the computer (except the superuser account) with the file /etc/hosts.equiv.

      A .rhosts file lists host/login name pairs that you want to give access to your account. Suppose that your main account mylogin is on the host money.corp.com, but sometimes you first login to the host lucre.corp.com and then use rlogin to get to money.corp.com. On money.corp.com you create a .rhosts in your home directory, readable and writable only by you and containing the line

      lucre.corp.com mylogin

      The .rhosts tells the rlogin daemon on money.corp.com that the account mylogin on the host lucre.corp.com should be allowed access without a password. You can add additional lines for other host/login name pairs, and the login name does not have to be the same on both hosts.

      TIP: While this is convenient, it carries a risk—if a cracker breaks into your account on lucre.corp.com, she can then break into your account at money.corp.com without a password. The .rhosts file also provides cracker clues. If your account on money.corp.com is broken, the cracker will see from your .rhosts the login name of your account on lucre.corp.com. On the other hand, .rhosts authentication avoids the problem of sending clear-text passwords over the network, which is an advantage if you're not using one-time passwords. You must decide whether the convenience outweighs the security risks.

      The file /etc/hosts.equiv does on a global level what .rhosts files do on the account level. The 10-workstation site example could create an /etc/hosts.equiv file like this on each workstation:

      ws1.corp.com ws2.corp.com [_] ws10.corp.com

      Now the ten workstations are mutually equivalent with respect to user authentication. Once you log in to one of the workstations, you can log in to any other without a password and without a .rhosts file. Again, while this may be convenient, when a single account on one of the 10 workstations is cracked, the other 9 are also compromised.

      .rhosts and the superuser account

      The superuser account (root) gets special treatment. Even if a host appears in /etc/hosts.equiv, root at that host is not considered equivalent unless the file /.rhosts also exists and contains a line for that site's root account. While this may be convenient for software distribution using rdist, consider carefully the security implications before you create a /.rhosts; passwordless software distribution is also convenient for crackers. For instance, if a cracker gains superuser access on ws1.corp.com, he can install a special version of the login program on that host, use rdist to send it to the other nine, and break into those, too. It may be better to forgo /.rhosts files and do your software distribution the hard way with ftp.

      .netrc authentication

      The .rhosts and /etc/hosts.equiv files only work with the so-called r-commands (rsh, rlogin, rdist, rcp). The telnet and ftp will still ask for a login name and password. However, you can use the .netrc file to automate ftp access. The .netrc should reside in your home directory on the host from which you run ftp. It contains a list of host names, login names, and passwords, all unencrypted. Because it holds clear text passwords, the .netrc file must be readable only by its owner. Because the password is unencrypted, a .netrc is a worse security risk than a .rhosts. It is useful for anonymous ftp access, though. For instance, if you often log in to the host ftp.cert.org to look at the CERT/CC advisories, you could create a .netrc containing the following lines:

      machine ftp.cert.org login anonymous password yourlogin@yourhost.domain

      This is safe since you're not divulging anything that isn't already public knowledge, that ftp.cert.org supports anonymous ftp.

      If possible, don't use .rhosts, .netrc, and /etc/hosts.equiv. Your security policy should specify whether your users are allowed to use the .rhosts and .netrc files. The COPS and chkacct programs (covered in the section "Security Tools" later in this chapter) check the security of your users' .rhosts and .netrc files.

      File System Security

      Despite your best efforts at establishing and implementing a good password security policy, your site may still be broken in to. Once a cracker has gained access to an account on your computer, his goal is to ensure continued access—if he's broken a user's password it may be changed to something more secure, or you might close whatever security hole he exploited to gain access. One way for crackers to ensure access is to install new accounts, or trapdoor versions of a system program such as login. Good file system security helps you prevent or detect these modifications and recover from a break-in.

      As distributed, most vendors' operating systems are not secure. System configuration files may be writable by users other than root, device files may have insecure file permissions, and programs and configuration files may be owned by users other than root. Configuration files writable by non-root accounts may allow a cracker to trick the system into granting additional privileges, or allow him to trick other computers on the same network. Device files that are readable or writable by users other than root may allow the cracker to alter system memory to gain additional privileges, snoop terminal or network traffic, or bypass the normal UNIX file protections to read files from or alter information on disk or tape storage. The cracker can alter files owned by users other than root even without breaking the superuser account. These are just a few of the ways vendors help make your life more interesting.

      Ideally you will both ensure that your newly installed UNIX system has proper file system security (intrusion prevention), and have a way to detect unauthorized file system changes (intrusion detection). There are several good tools for these jobs. You can use the COPS and TAMU Tiger programs to detect insecurities in newly installed systems, and the Tripwire and TAMU tiger packages can both detect subsequent file system modifications. These programs are covered later in this chapter in the section "Security Tools."

      Backup Policies

      You may not think of your system backups as a security tool. However, if crackers modify programs or destroy files, how will you recover? If you don't run Tripwire you may detect a break-in but not be able to tell which files the crackers changed. Your only recourse is to restore the system to its clean state from your backups. Even if you run Tripwire you must still be able to restore files that were removed or changed. Good backups are essential to both tasks. Backups may also be important as evidence in court proceedings.

      You should answer the following questions about your backup strategy:

      • Are your backups physically safe? Can a cracker get your backup tapes and alter them or get information from them? Shadow passwords are useless if a cracker can retrieve the encrypted passwords from a backup tape and crack them offline. A cracker who can alter a backup and trick you into reloading it can cause his own programs to be installed on your system.

      • Do you test your backups? Are you certain that you can restore your system? The worst time to find out there's a problem with your backup procedures is when you really need them. A good system administrator will periodically test-restore random files or entire file systems from her backup tapes to ensure that they will work in an emergency. This is especially important with 8mm helical scan tape systems because the tapes wear out after a few dozen passes.

      WARNING: 8mm helical scan tape backups (e.g., Exabyte) are based on video recording technology. If you drop a few bits on your video of Johnny's fourth birthday party, it's no big deal, but a few missing bits on your backup tape may render the remainder unreadable. Helical scan technology may result in data loss after only a few dozen passes over a tape. This includes reads, writes, and even retensioning passes—in fact, anything that moves the tape over the capstan.

      Further, tape formulations vary among manufacturers and even between production runs as vendors change their formulations. To make matters worse, buying "data grade" 8mm tapes may not guarantee better quality. Your best bet is to experiment with different brands of tapes to see which work the most reliably with your drives. Once you've found a brand that works well for you, buy it in bulk. You should also experiment to see how many read and write passes you can achieve before a tape goes bad. Cycle in new tapes as the old ones near their life expectancies.

      4mm digital auto tape (DAT) drives were designed from the ground up for date recording, and the prices of DAT drives are dropping. You can now buy a DAT drive that will hold up to 8 GB of compressed data for about $1,500. If you're thinking about replacing your existing 8mm helical scan drives you should go with 4mm DAT.

      • Do you keep your tapes forever? Tapes and other media wear out and should be replaced on a set schedule and disposed of in a way that thwarts dumpster-diving attacks.

      • Are your backups kept onsite? What will you do if there's a fire or other natural disaster? Consider storing archival backups offsite in a safe-deposit vault.

      • Is your backup schedule sufficient for your security needs? How often do you run partial and full backups, and what is the chance that a file you create Monday and remove Tuesday will appear on a backup tape? Depending on the value of the information you back up, you may want to revise your schedule to run backups more frequently.

      • Should you make periodic archival backups of the entire system on a read-only medium like a WORM (write-once, read-many) drive?

      Network Security

      Attaching your computer to a network presents a host of new security threats—networked computers may be attacked from any host on the network or by tapping into the physical network, and if you are connected to the Internet your computer can be attacked from sites anywhere in the world. Networking software also introduces new threats. Most Internet software protocols were not designed with security in mind, and network server programs often run with superuser privileges that make them fruitful grounds for system cracking.

      If you don't need a software service, do away with it. For instance, if you don't plan to use the UUCP software, remove both it and the UUCP account. However, you will want some network services, and you must ensure that those are as secure as you can make them. A few of the most important services are discussed in the following sections.


      FTP is the Internet File Transfer Protocol, implemented on UNIX systems by the client program ftp and the server program ftpd. The ftpd server runs with superuser privileges and has been a rich source of bugs.

      The ftpd server allows ftp clients to connect to a computer and transfer files back to the client computer. While the ftp protocol requires user authentication, most implementations also allow anonymous logins. There are two problems. First, normal ftp authentication sends passwords over the network in the clear, where they can be snooped. Second, if you run ftpd—and especially if you allow anonymous logins—crackers have a program to exploit that might give them superuser privileges.

      If you run ftpd, make sure you're running a fairly recent version. If your vendor doesn't provide a sufficiently bug-free ftpd, you may want to get a public-domain replacement. The BSD and Washington University (WU) replacements are available on ftp.uu.net and other hosts. The WU ftpd is based on the BSD version with many additional features, but new features sometimes mean new bugs—if you don't need the features, the BSD version may be better.

      Another possibility is to run ftpd in a chrooted environment. The chroot system call changes the root of the file tree from the directory / to one you specify. The process is trapped inside the directory tree below the new root, which allows you to insulate the rest of your file system from buggy software. You can use wrappers such as tcpd and netacl (described in the section "Program Wrappers" later in this chapter) to run a short program that changes to a secure directory and runs chroot before invoking ftpd.

      chroot is not a panacea. A chrooted environment must be set up carefully, or a knowledgeable cracker may break out of it. Device files in the chroot directory are a particular risk since access to raw devices isn't affected by chroot. That is, if you create a device file in the chroot directory that allows access to the raw disk, a cracker can still access files outside the chroot file tree.

      WARNING: The chroot system call won't solve all your problems. While it limits the cracker's access to the part of the UNIX file tree you specify in the chroot call, a good cracker may still break in. For instance, if a buggy setuid root program allows a cracker to get a shell with superuser permissions inside the chrooted directory, she can create device files with read and write permission on system memory or raw disks. A knowledgeable cracker could then add new accounts to the password file or break your system in any number of other ways. The moral is that you shouldn't feel safe just because you're running a setuid root program inside a chrooted directory. setuid root programs should always be carefully in-spected for bugs regardless of whether they're running in a restricted environment.


      The sendmail program is a mail router that implements the Simple Mail Transfer Protocol (SMTP). Because it is large, complex, and runs with superuser privileges, it has yielded a monotonous string of serious bugs. (The notorious Internet worm of November 1988 exploited a sendmail bug.) Worse, vendors often lag several versions behind the state of the art and fail to fix known bugs, or they add new, bug-producing "features."

      Your most secure option is to toss your vendor's sendmail and run Version 8 sendmail, available from ftp.cs.berkeley.edu and other hosts. Eric Allman, the original author, has resumed work on sendmail and rewritten much of the code, and is actively maintaining it. The serious bugs detailed in the CERT/CC advisory of November 4, 1993, were not present in Version 8 sendmail, and would probably have been fixed more promptly by Allman than by vendors, some of whom took up to two months to produce fixes. See Chapter 41 for instructions on installing Version 8 sendmail.

      For sites that need very high security, the TIS (Trusted Information Systems, Inc.) toolkit, available from the host ftp.tis.com, circumvents sendmail problems by providing an SMTP client, smap, that runs as an unprivileged user in a chrooted environment. smap implements a minimal version of SMTP and writes mail to disk for later delivery by smapd. smap also allows you to refuse mail that's too large, to prevent attackers from filling your disks.

      Network File System (NFS)

      NFS was invented by Sun Microsystems, which put the protocol specification in the public domain. This meant that anyone could write an NFS implementation that would interoperate with Sun's, and many vendors did. NFS is useful and popular, but does not offer strong security. It opens you to many attacks, and if you don't need it, you shouldn't run it.

      If you run NFS, carefully read your vendor's documentation and make sure you've enabled all security features. Keep exported file systems to a minimum, and export them with the minimal set of permissions. The guides mentioned in the section "Finding More Information" later in this chapter provide cookguide procedures for safely administering NFS.

      Network Information System (NIS)

      Sun Microsystems also created NIS (previously known as YP, or yellow pages). As with NFS, several vendors besides Sun have implemented NIS on their computers.

      NIS allows you to share system administration data over the network, which is convenient if you have many hosts to administer. For instance, if you have a cluster of 50 workstations using the same password file, you can create a single copy and use NIS to share it among the workstations.

      Although NIS is convenient, it is not secure. A poorly administered NIS may allow crackers to gather information about your site remotely, for instance by requesting your password file for offline cracking. As before, if you don't need it, don't run it. If you do need it, make sure that your NIS domain name isn't easily guessed, and refer to your vendor's documentation and one of the "nuts and bolts" guides for detailed instructions on safe NIS administration.


      Although the finger program seems innocuous, it may be another you can do without. finger is the client, and fingerd the server. The client program is safe, but the server can give crackers information about your site. In particular, the time of last login is often included in finger output, which helps crackers find unused accounts to break. finger's output format may also give clues to the kind of operating system you run. Since many crackers work from checklists of bugs particular to certain versions of UNIX, this information is valuable. Also, if your password policy doesn't prevent your users from choosing bad passwords, finger information may provide clues to crackers.

      You should run fingerd as an unprivileged user—the login nobody is a good choice.

      The Trivial File Transfer Protocol (TFTP)

      TFTP is used by diskless workstations to load UNIX from a file server. It's called "trivial" because the normal security checks of FTP have been removed—accounts and passwords are not required. Some versions of the TFTP server allow crackers to grab any file on the system—for instance the shadow password file for offline cracking. Recent versions of the TFTP server offer better security by only allowing files to be retrieved from a specific directory. If you don't need TFTP service, disable it, and if you do, make sure you're using all its security features. Secure versions of the TFTP daemon are available from ftp.uu.net and other hosts.

      Intrusion Detection

      Despite your best efforts, your site may be cracked. How will you know when it happens? Sophisticated system crackers go to great lengths to cover their tracks.

      If you administer a single computer, it helps to get to know it and your users. Run ps periodically to get an idea of what jobs are usually running, and look for unusual ones. Use sa to see what typical job mix your users run. Is a user who normally does only word processing suddenly compiling programs? Is an account being used while a user is on vacation? Either might indicate a break-in.

      This kind of monitoring is very limited, though. You can't be logged in all the time, and if you have more than one computer to administer, this approach is impractical. How can you detect the telltale signs of crackers automatically?

      Account auditing helps detect whether crackers have created new accounts. If you run a small system you may be able to print the entire password file and periodically compare it to the system password file. If you have too many users for this to be practical, you can store the current password file on a read-only medium (for example, a floppy disk that you can write-protect) and use diff to look for new, unauthorized accounts. Account auditing should also ensure that inactive or idle accounts are removed.

      Message Digests

      Message digests, also known as file signatures, are the preferred way to alert you when crackers alter files. A message digest is a cryptographic signature specific to a file—if the file changes, the signature changes, and if the signature is strong enough, it's not possible for a cracker to create another file with the same signature. If you compute a message digest for all your important system files, and a cracker changes one, you'll find out.

      The public-domain Tripwire software automates detection of file system alterations. You can ftp Tripwire from ftp.cs.purdue.edu. Tripwire computes up to five different signatures for each file you specify. It reports deleted files and new files. You can configure it to ignore files you know will change, such as system log files.

      If possible you should install Tripwire just after you've installed your vendor's operating system, before you install user accounts and connect it to a network. If you're installing Tripwire on an existing system, put it in single-user mode or detach it from the network, and then install Tripwire and compute the file signatures. If you can, keep Tripwire, its configuration file, and its database of file signatures offline or on read-only media.

      Files change all the time on UNIX systems, and if you don't configure it correctly Tripwire may become your UNIX equivalent of "the boy who cried wolf." For instance, the /etc/password file signature changes whenever a user changes her password. The danger is that warnings of illicit changes to files will be buried in the noise of valid changes. Spend some time configuring Tripwire until the signal-to-noise ratio is high enough that you won't miss valid reports.

      Tripwire's message digests vary in their cryptographic strength. Read the documentation carefully and make sure you're using digests strong enough for your site's security needs.

      C2 Auditing

      The National Computer Security Center (NCSC) publishes the Trusted Computer Systems Evaluation Criteria (TCSEC, or Orange guide) to specify the security standards computers must meet for certification at various levels for government use. The C2 level is one that vendors commonly claim to meet. Among other things, C2 security requires that audit events be logged to help track intrusions. For example, if the user joe runs the su command and becomes root at 14:23 on February 10, 1994, this information is recorded in an audit file.

      Many other fairly routine events are audited, and audit logs become huge. The problem on large systems with many users is winnowing the chaff from the wheat, and few tools are available to automate the process. However, if you run a small system and you have time to inspect the logs, C2 auditing may help you discover intrusions.

      Note that there is a difference between offering "C2 security features" (as many vendors claim) and actually being certified at a TCSEC level by the NCSC. The former is marketing hype, and the latter a lengthy process that leads to official certification. This doesn't mean that uncertified "C2 features" aren't valuable, but you should know the difference.

      Program Wrappers

      A wrapper is a program that offers additional security by surrounding a less secure program and running it in a more secure environment, making additional checks before running it, or logging information about who uses it.

      For instance, suppose that you usually log in to your computer yourhost.zorch.com, but sometimes log in to zach.glop.org and then telnet to yourhost.zorch.com. Running a telnet server on yourhost.zorch.com makes it possible for anyone on the Internet to attempt a break-in. Since you know that the only Internet host that should have access is zach.glop.org, you can put a wrapper around telnetd that checks incoming connections and refuses ones from other hosts.

      The tcpd wrapper is available from ftp.cert.org and other sites. tcpd sits between the Internet daemon inetd and the programs that inetd runs. For instance, instead of having inetd run telnetd directly, you can configure it to run tcpd. Based on the rules you give, tcpd can start telnetd or reject the connection request. For instance, in the previous example it could reject telnet connections from all hosts other than zach.glop.org. In either case it can log the attempt. tcpd can be used for any program run by inetd. The TIS firewalls toolkit provides a similar program, netacl (Network Access Control), available from ftp.tis.com.

      Disaster Recovery

      If you discover a break-in, what should you do? That depends on what the cracker is doing, whether you intend to catch and prosecute him, and how disruptive he is. You may want to monitor the cracker's activities to see how he got in, and gather information about other sites he may be using (or cracking from your site) so you can notify those sites' system administrators. You should also notify CERT/CC. (See the section "Finding More Information" later in this chapter.) Depending on your security needs and what you know about how the cracker got in, you may need to restore changed files, change the superuser and system administrator passwords, audit (your password file), install a secure version of a broken program or change system configuration files to remove insecurities, or even restore your entire system from the vendor's original distribution media and your own backups.

      This list is not exhaustive, but it shows a broad range of post-intrusion options. Some of these options—such as requiring all your users to change their passwords—severely affect your users and staff. Things will go more smoothly if you have a written plan. Although you may not create a perfect plan the first time, having one helps keep you calm and provides some structure when things go wrong.

      After your system is secure again, you should assess your security needs and strategies. Could the break-in have been prevented? How bad were the consequences? Should you revise your security policy or devote more staff time to security? Post-intrusion may be a good time to approach management with previously rejected security proposals.

      Security Tools

      Programmers have developed automated security tools (ASTs) to assess your system security. ASTs are sharp on both sides—if you don't use them to find insecurities, crackers may.

      Many crackers work from checklists of known bugs, methodically trying each in turn until they find a way in or give up and move on to an easier target. ASTs automate this boring job and generate summary reports. If you close those holes, a checklist cracker may move on to less secure hosts, preferably ones you don't administer.

      There are two problems with ASTs. First, you may gain a false sense of security when they cheerfully report "all's well." ASTs only report known insecurities, and new ones are discovered constantly. A second, related problem, is that if crackers break in to your system they may alter your AST to always report good news.

      Despite these problems, you should run ASTs. They are good tools if you understand their limitations, and especially if you can install them on and run them from read-only media. You can also use tools like Tripwire to verify the integrity of your ASTs.


      COPS (Computer Oracle and Password System) was written by Dan Farmer of Sun Microsystems. COPS has been ported to many different versions of UNIX. Most of it is written in Bourne shell scripts and perl, so it's easy to understand and to modify if it doesn't do exactly what you want. COPS performs comprehensive checks for user- and system-level insecurities, checks whether you've patched programs with known insecurities, and includes an expert system that tries to determine whether your computer can be cracked. If you don't run any other AST, you should run COPS.

      TAMU Tiger

      Texas A&M University (TAMU) developed a suite of tiger team programs to look for system insecurities in response to serious and persistent break-ins. A tiger team is a group of security experts hired to break in to your system and tell you how they did it. TAMU didn't have the staff resources for tiger teams, so they automated the process—if a host passed the TAMU tiger gauntlet, it was relatively immune to cracking.

      In contrast to COPS, which makes many checks of user accounts, Tiger assumes that the cracker already has access to a legitimate account on your computer and looks for ways in which she can get superuser access. Tiger checks cron entries, mail aliases, NFS exports, inetd entries, and PATH variables. It also checks .rhosts and .netrc files, file and directory permissions, and files that shouldn't be there.

      Tiger also computes message digests for important system files, and reports unpatched programs for which vendors have provided fixes. Tiger includes file signature databases for several standard UNIX distributions, which you can use rather than developing your own. You can ftp TAMUtiger from the host net.tamu.edu in the directory pub/security/TAMU. The TAMU tiger tar archive is named tiger-2.2.3.tar.gz (the extension ".gz" means the tar archive is compressed with the gzip program, available from ftp.uu.net and other ftp sites). The signature files are in the subdirectory tiger-sigs.


      SATAN (Security Analysis Tool for Auditing Networks) was promised for release by Dan Farmer, author of COPS, and Wietse Venema, author of tcpd, for the first half of 1994. According to the prerelease notes, SATAN will probe a host or set of hosts over a network, looking for information and potential insecurities in network services. It will either report the data or use an expert system to investigate further, based on the insecurities and information already discovered. SATAN will be a useful tool for both crackers and system administrators. Watch for an announcement in the USENET newsgroup comp.security.announce.

      Firewalls and Bastion Hosts

      Just as your car's firewall is designed to protect you from engine fires, a network firewall protects an internal, hidden network from the rest of the Internet. Firewalls are popular with sites that need heightened security, but are unpopular with users.

      The basic idea of a firewall is to establish a single, heavily guarded point of entry to your local area network (LAN). The system administrator maintains a high level of security on the firewall (or bastion host), which may also be surrounded by filtering routers that automatically limit access to the firewall.

      Firewalls (and the interior LANs they protect) can be made very secure, but they limit access to Internet services. In many firewall implementations, users who want access to the Internet must first log in to the firewall host.

      If you plan to implement a firewall you should subscribe to the Firewalls mailing list to get a feel for the design issues (see the section "Finding More Information" later in this chapter). The TIS firewalls software and other information is available from ftp.tis.com. Firewall tutorials, theoretical papers, and information about commercial firewall vendors is available on ftp.greatcircle.com. You should also read the Cheswick and Bellovin guide mentioned in the section "Finding More Information" in this chapter.


      The problem of maintaining security on hundreds of workstations installed in insecure, public sites led the Massachusetts Institute of Technology's (MIT's) Project Athena programmers to develop Kerberos.

      Kerberos solves some (but not all) of the problems inherent in physically insecure networks and computers. Kerberos network servers verify both their own identity and that of their clients without sending unencrypted passwords over the LAN where they may be snooped, and can provide privacy via data encryption. Persons using Kerberos services can be fairly sure that they're talking to the real service, and Kerberos services can be equally sure that when Joe asks the mail server for his electronic mail, it's really Joe. Kerberos is free, and source code is available from the host athena-dist.mit.edu. The USENET newsgroup comp.protocols.kerberos is devoted to discussion of the Kerberos system.

      A disadvantage of Kerberos is that each network client and server program must be Kerberized, that is, modified to call the Kerberos subroutines. Kerberized versions of standard applications such as telnet are supplied with Kerberos, and if you have source code for your applications you can add calls to the Kerberos subroutines yourself. However, many third-party software vendors provide neither source code nor Kerberized versions of their software.

      Kerberos has additional problems. Many Internet servers don't use it, and it does you no good to install a Kerberized telnet client if your users connect to remote hosts that run unKerberized telnet servers. Kerberos doesn't work with dumb (ASCII) terminals or most X-terminals, and on multiuser computers is only as strong as the superuser account because the superuser can find the secret keys. Kerberos also requires an otherwise-unused, secure host to maintain its database of principals and their secret keys.

      Despite its limitations, Kerberos is useful in certain environments. For more information, ftp to the host rtfm.mit.edu and download the Kerberos FAQ (Frequently Asked Questions) document.

      Hardware Solutions

      Dial-back modems, encrypting EtherNet hubs, and filtering routers all help solve some of your security problems.

      Dial-Back Modems

      A dial-back modem stores a list of valid login names and phone numbers. You dial the modem, go through an authentication procedure, and hang up. The modem consults its list of phone numbers and users, and calls you back. A cracker who discovers your modem through random dialing can't connect to your computer unless he's calling from one of the listed numbers.

      TIP: Dial-back modems can be tricked by clever crackers who use special equipment to generate the proper tones to trick your modem into thinking the calling modem has hung up when it hasn't. If your dial-back modem then looks up the "secure" number of the good guy's phone and calls back on the same line, the bad guy's modem picks up the call and gets in anyway. The best defense against this attack is to use one line for incoming connection requests and a second line for the dial-back. Some telcos even provide a one-way line for its call-back, so it can't be tricked by the method described above.

      Dial-back modems work well for organizations with relatively immobile users. They are also useful if you offer modem-based Internet access to users via the SLIP or PPP protocols. However, they don't work well for peripatetic users who need remote access to your system—S/Key is a better solution in that case.

      Encrypting EtherNet Hubs

      Encrypting hubs used with 10 BASE-T EtherNet can prevent snooping attacks. 10 BASE-T installations use a star topology, in which each station is on its own wire, connected to a central packet-routing hub. The EtherNet protocol requires that a packet destined for a certain host be sent to all hosts on the EtherNet, which is why packets can be snooped. An encrypting hub scrambles the contents of the packet for all the stations except the one for which the packet is intended, making snooping a waste of time.

      TIP: Some encrypting hubs also keep track of the EtherNet MAC addresses of the hosts on each wire, and can shut down a wire if a foreign host is introduced. This may help if a cracker unhooks one of your hosts and attaches his PC to your network, but it's not foolproof—most EtherNet cards allow you to set the MAC address in software, and a sophisticated cracker would set his to match the computer he's impersonating. However, some hubs can shut down a wire if the EtherNet heartbeat is interrupted, even momentarily. These hubs prevent the latter attack.

      Filtering Routers

      Filtering routers are often used in firewalls, placed between the Internet and the bastion host, or on both sides of the bastion host. They can be configured to discard packets based on the type of service requested, such as mail or ftp, or to discard some or all packets from specified hosts or networks. Routers are more difficult to break in to than are UNIX hosts because routers are single-purpose computers. Because they stop dangerous network connections before your bastion host ever sees them, the cracker's job is harder.

      Finding More Information

      The problem with printed security guides is that they're soon out of date. Vendors release new versions of UNIX with new bugs, and crackers continually look for new ways to break in. If you rely on old information, you'll soon fall behind. The following list gives some good sources of up-to-date information and the "nuts and bolts" guides that give detailed procedures for implementing security.

      USENET News

      If your site receives USENET news, you at least should read these: comp.security.announce, comp.security.unix, and comp.security.misc.

      comp.security.announce postings warn you of newly discovered security problems. CERT/CC advisories are posted there. comp.security.unix is for general discussion of UNIX security. comp.security.misc is for general discussions of computer security. You may also want to read comp.risks for discussions of the risks of computers, and comp.admin.policy for system administration policy discussions.


      The Computer Emergency Response Team Coordination Center (CERT/CC) was formed by the Defense Advanced Research Projects Agency (DARPA) and is run by Carnegie-Mellon University (CMU). (Alphabet soup, anyone?) CERT/CC acts as a coordination center for computer security information and incidents. When a security problem is found, CERT/CC works with UNIX vendors to correct the problem, and then issues an advisory through electronic mail and comp.security.announce, describing the problem, its impact, and how to correct it. CERT/CC advisories do not include specific how-to details of security problems, but they are specific about the fixes.


      The Forum of Incident Response and Security Teams (FIRST) is a cooperative group of government and private organizations in North America and Europe. By sharing information among FIRST members, they hope to prevent or at least respond quickly to intrusions. CERT/CC is one FIRST member, and its advisories are usually circulated for comment among FIRST members before they are released to the general public. For current information about FIRST, ftp to csrc.ncsl.nist.gov and look in the directory pub/first/gen-info. This host also has a large archive of security information.

      Vendor Contacts

      Some vendors have become more responsive to security concerns over the years. Some have mailing lists for notifying their customers of new bugs and patches. Contact your vendor's salesperson to see what security information your vendor provides.

      Mailing Lists

      Special-interest groups maintain mailing lists to discuss specific security topics. One of the most useful is the Firewalls list, which is targeted at discussion of firewall implementations, but often contains good advice on other aspects of security. To join firewalls, send mail to majordomo@greatcircle.com and include the words subscribe firewalls-digest in the body of the message.

      You can subscribe to the TAMU Tiger mailing list by sending mail to majordomo@net.tamu.edu and including the words subscribe tiger in the body of the message.

      The bugtraq mailing list is a currently popular "full-disclosure" list. The signal-to-noise ratio is fairly low, but depending on your paranoia level, you may want to subscribe to it. Subscribe by sending a letter to bugtraq-request@fc.net, with a single line in the body of the message that says: subscribe bugtraq yourlogin@your.host.domain.

      Periodically, someone dissatisfied with CERT/CC's vague advisories starts a security mailing list for public disclosure of security problems, including enough detail to exploit the problem. Some lists try to screen new members so only the "good guys" will get the hot tips, but some believe that the crackers already know the bugs, and the best defense for system administrators is full disclosure as soon as possible. This approach puts a burden on system administrators who don't have source code and must rely on their vendors to fix security bugs. You may want to monitor these lists so you'll be aware of new insecurities, even if you must rely on your vendor to fix them. Most of these lists are announced in comp.security.unix.

      Conferences and Networking

      Security conferences give you the opportunity to find out what other sites are doing to improve their security, to learn of new security software, and to see what theoretical work is being done. You can also meet other system administrators and share information with them. Systems administrators may tell you things in person that they wouldn't publish in the security newsgroups or mailing lists. Advance warning via a phone call from a friend at another site can give you the jump on the latest security problem. Most conferences are announced in the USENET newsgroups previously mentioned.

      Online Information and Program Source Archives

      Much security information resides on the Internet, accessible via ftp or one of the newer information protocols such as gopher or the World-Wide-Web. Many of these sources have been mentioned previously in this chapter. Good places to start are the archives on ftp.cert.org, csrc.ncsl.nist.gov, and ftp.cs.purdue.edu. Look for security software at the sites mentioned previously, or use an archie server such as archie.ans.net to find them. Mailing lists and USENET newsgroups frequently mention specific source or information archives. New security software is often posted to the USENET newsgroup comp.sources.unix.

      FTP and Other Information Archives

      A lot of security information is available on the net at ftp.cert.org, csrc.ncsl.nist.gov, and others. Recently the COAST (Computer Operations, Audit, and Security Tools) project of the Purdue University Computer Sciences department has set up an FTP archive that contains a large collection of security information and tools. You can access this archive via the ftp command by connecting to the host coast.cs.purdue.edu. Gopher and WWW (World-Wide-Web) access is planned soon.

      Other guides

      The following guides give the detailed procedures you need in order to avoid common mistakes. The first two are basic UNIX security texts that anyone concerned with security should read. The third guide covers basic system administration in detail, and includes a good section on security.

      Firewalls and Internet Security: Repelling and Wily Hacker, William R. Cheswick and Steven M. Bellovin, Addison-Wesley, 1994.
      Practical UNIX Security, Simson Garfinkel and Eugene Spafford, O'Reilly & Associates, 1991, Sebastopal, CA, ISBN 0-937175-72-2.
      UNIX System Security: A Guide for Users and System Administrators, David Curry, Addison-Wesley, 1992, ISBN 0-201-56327-4.
      UNIX System Administration Handguide, Evi Nemeth, Garth Snyder, and Scott Seebass, Prentice Hall, 1989, ISBN 0-13-933441-6.

      Where to Go from Here?

      Computer security is a full-time job for many people. As a system administrator you must decide how secure your system should be, what measures you should take to prevent, detect, and recover from intrusions, and then convince yourself (or your manager) to devote the necessary resources to the job. This chapter gives you a broad outline of security concerns, but doesn't tell you all you need to know. Running a secure system means evaluating your security needs, researching software and hardware security systems, and staying abreast of a rapidly changing field by taking advantage of all the resources available.

      Previous Page Main Page Next Page