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

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

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.

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:

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:

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

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.

---

sendmail

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.

finger

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

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

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.

Kerberos

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.

CERT/CC

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.

FIRST

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.