UNIX Unleashed, Internet Edition
by Robin Burk
As we've seen in Chapter 12, UNIX systems face formidable security threats. Fortunately, there are a wide variety of things you can do as a UNIX system administrators to prevent, detect and respond to such threats.
In this chapter, we'll look at a number of technologies you can use to make your system more secure, deter hackers, and identify system intruders. Many of the tools and techniques available serve several of these functions at once. Others offer very targeted, if invaluable, help with a narrow function. Among the approaches we'll discuss are:
No one of these is likely to solve all your security needs. Good system security begins with planning and a well thought-out set of policies. To create good policies, however, you need to know what tools and procedures you can use to reduce your security risks.
The single most useful security technology is also the simplest. The right policies and procedures can significantly increase the security of even the most vanilla UNIX system.
Security begins with analysis. Before you can protect your system in a cost-effective way, you need to know what resources must be protected, their relative value to you and your organization, and the areas in which they are most at risk. You also need to evaluate what security protection is already in place.
For instance, if you administer a database server for a large corporation and it is only connected to a corporate WAN over leased lines, protecting the integrity of the data on the server will be a high priority. You will probably decide that the risk of intrusion from outsiders is less of a threat, because there are no easy public gateways into your network. However, there is a potential for inadvertent or malicious damage on the part of otherwise authorized users throughout the company.
On the other hand, if you administer an Internet server, you are vulnerable to network-oriented attacks from every cracker out there. Your own information and resources are at risk, and so are the e-mail, Web files, and other resources for each of your customers. Inadvertent damage will be easy to manage, because you are able to keep a tight rein on the activities of legitimate users.
Policies and procedures must be well thought out and must be easily enforceable if they are to improve your system's security. In most cases, you will need the active support of management in implementing security measures. Unfortunately, many managers don't have the hands-on experience to balance rigorous procedures against users' needs. Management will need your best professional advice to craft policies and procedures that are effective without being unreasonable, arbitrary, or awkward for users to work within. You will also need management's help in publicizing the policies, enforcing the procedures, and establishing an atmosphere of acceptance on the part of users.
If you gain the support of management and users for your policies, your life will be much easier and your system is far more likely to become and remain secure.
One way to gain support is to describe your approach in terms of cost versus benefit tradeoffs. For instance, your policy should begin by identifying the degree to which this system's resources and information are deemed critical to the company, difficult to replace, proprietary or otherwise in need of strong security measures. The more valuable the system, the more firm and comprehensive the security approach should be. Management will commit money and time to protect assets that are clearly valuable to the company and users will accept more stringent controls on such a system.
Security policies and procedures must also match the culture of your organization or user community. For instance, if your system serves a classified military site, a public agency, or the finance department of a buttoned-down corporation, you may choose an approach that leaves the user no choice as to how he will accomplish various computing tasks. On the other hand, if your system serves an academic or research community, your users will demand a fair degree of autonomy and flexibility in their use of the system. In this case, your security policy must ensure that an adequate degree of protection is in place, but without otherwise constraining how people use the system.
Your system exists to provide services and collect information on behalf of some set of authorized users. The purpose of your security policy is to protect those resources against deliberate or inadvertent misuse. There are at least six aspects of the system to consider:
Each security measure, and the overall security approach, should be evaluated against these criteria. Not every security measure will address all six objectives, but taken together, they must provide a comprehensive response to the security threat.
TIP: 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.
A second element of good system security is to control physical access to your system and any networks attached to it.
Begin by auditing your site. What prevents unauthorized users from doing any of the following?
Make sure your policy and procedures clearly address how these forms of system access will be prevented. Then ensure that the policies and procedures are actually enforced even when people are just stepping out to lunch or are busy on a critical project.
Prevent potential crackers from watching the screen as receptionists enter data, from gaining access to telephone lists and office layout diagrams, and from walking through work areas. It's just too easy and natural for users to respond to pleasant queries by showing an outsider how they log in, access information, or do their jobs.
Don't let your physical security measures stop when things go out the door. Make sure that such materials as memos listing modem numbers, valid account names, or passwords; diskettes and tapes; printouts; and manuals are disposed of in such a way as to prevent crackers from gaining useful information. This is easiest to accomplish if your policies address the disposal of all paper and other media. Set up procedures so that the occasional interesting or useful document is automatically destroyed along with the other, less interesting material.
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, because 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 any place in the world.
Physical network-based attacks occur with more frequency than you might imagine, even in these days of ubiquitous modems and dialup network services. However, most network-based attacks are executed from remote computers.
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."
TIP: You may also want to run public-domain replacements for some vendor software, for instance, the public-domain Version 8 sendmail program. 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.
Social engineering on the part of crackers is a subtle and difficult threat to address. As you may guess, the best defense against social engineering is user and staff education. Your users should know, for instance, that because 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 is to educate your users on such matters.
A second way to counter the social engineering threat is to limit system use on the part of temporary workers, employees of other companies, new hires, and others who have not yet been trained or whose commitment to maintaining system security is not obvious. This will require management guidance and support, but can be a surprisingly effective measure to take. Often new hires are not yet ready to make productive use of the system, for instance. If your company includes security and application training as part of the orientation process before system access is granted, such users are less likely to be vulnerable to the wiles of friendly crackers.
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.
TIP: 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.
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% to 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.
Good passwords are six to eight 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 books 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 because it isn't found in any dictionary, uses a fairly rich vocabulary (the digit "1" and capitalization), and it's easy to remember (but not to type).
NOTE: 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.
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% 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.
TIP: 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.
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.
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 by guessing it, watching you type it, or by cracking it offline on another computer. Changing passwords every one to six 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.
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 10 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.
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). As this alert suggests, there is a real threat that persistent passwords will be captured and used to hack your system.
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 because the password that logs you in on Tuesday is different from the one you used Monday.
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.
TIP: 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, because 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.
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. Because 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, because 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 10 workstations are mutually equivalent with respect to user authentication. After 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 nine are also compromised.
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.
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 because you're not divulging anything that isn't already public knowledge (that ftp.cert.org supports anonymous ftp).
TIP: 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.
Despite your best efforts to establish and implement 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 has 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.
TIP: You can use the COPS and TAMU Tiger programs to detect insecurities in newly installed systems. The Tripwire and TAMU tiger packages can both detect subsequent file system modifications.
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:
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.
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.
NOTE: 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 because 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 inspected for bugs regardless of whether they're running in a restricted environment.
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.
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.
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 books mentioned in the section "Finding More Information" later in this chapter provide cookbook procedures for safely administering NFS.
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" books for detailed instructions on safe NIS administration.
You should run fingerd as an unprivileged user--the login nobody is a good choice.
If you don't need TFTP service, disable it. 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.
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, 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.
The National Computer Security Center (NCSC) publishes the Trusted Computer Systems Evaluation Criteria (TCSEC, or Orange Book) 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, 1997, 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.
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. Because 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.
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. 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.
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.
TIP: 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 such as 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.
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 written by Dan Farmer, author of COPS, and Wietse Venema, author of tcpd. SATAN is a set of tools that 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 comes with extensive information regarding known vulnerabilities in a variety of operating systems and protocols, which makes it a valuable tool for administrators and crackers both.
For this reason, CIAC has developed Courtney to monitor potential SATAN probes. Courtney receives real-time tcpdump information and monitors the number and nature of processes to which given hosts attempt connection.
The Security Profile Inspector for Networks is an integrated network security package for UNIX systems developed by the Lawrence Livermore National Laboratory of the Department of Energy. SPI-NET is available for free to government agencies and companies performing work for the Departments of Energy and Defense. A commercial version is under development.
Merlin was developed by CIAC and integrates Tiger, Tripwire, COPS, SPI-NET, Crack, and other popular UNIX-based security tools. Merlin offers a single, easy-to-use interface and extends the tools' capabilities in a number of ways.
There are a number of excellent World Wide Web sites with links to security tools. SATAN, Courtney, and a wide variety of other security tools can be downloaded from the CIAC Web site at http://www.llnl.gov/ciac/securitytools.html. Merlin is available from CIAC at http://www.llnl.ciac/toolsUnixSysMon.htm. SPI-NET is available from the Computer Security Technology Center of Livermore Labs at http://www.llnl.gov/cstc/spi/spinet.html.
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.
Firewall technology is changing rapidly and many commercial products are now available.
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.
Dial-back modems, encrypting EtherNet hubs, and filtering routers all help solve some of your security problems.
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 call-back, so they can't be tricked by the method described here.
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 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 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.
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 gain the support and resources necessary to implement your plan.
Security technology is changing rapidly. The underlying issues and vulnerabilities of UNIX are understood and documented, however, so it is by no means a hopeless task to secure your UNIX system in appropriate and cost-effective ways. To do so will take both an initial effort and ongoing vigilance combined with a commitment to stay abreast of security developments.
©Copyright,
Macmillan Computer Publishing. All rights reserved.