<IMG SRC="warning.gif" WIDTH = 37 HEIGHT = 35><B>WARNING: </B>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.

<BR></NOTE>

<HR ALIGN=CENTER>

<H4 ALIGN="CENTER">

<CENTER><A ID="I26" NAME="I26">

<FONT SIZE=3><B>sendmail</B>

<BR></FONT></A></CENTER></H4>

<P>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 &quot;features.&quot;

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I27" NAME="I27">

<FONT SIZE=3><B>Network File System (NFS)</B>

<BR></FONT></A></CENTER></H4>

<P>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.

<BR></P>

<P>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 &quot;Finding 

More Information&quot; later in this chapter provide cookbook procedures for safely administering NFS.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I28" NAME="I28">

<FONT SIZE=3><B>Network Information System (NIS)</B>

<BR></FONT></A></CENTER></H4>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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 &quot;nuts and bolts&quot; books for detailed instructions on safe NIS administration.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I29" NAME="I29">

<FONT SIZE=3><B>finger</B>

<BR></FONT></A></CENTER></H4>

<P>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.

<BR></P>

<P>You should run fingerd as an unprivileged user&#151;the login nobody is a good choice.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I30" NAME="I30">

<FONT SIZE=3><B>The Trivial File Transfer Protocol (TFTP)</B>

<BR></FONT></A></CENTER></H4>

<P>TFTP is used by diskless workstations to load UNIX from a file server. It's called &quot;trivial&quot; because the normal security checks of FTP have been removed&#151;accounts and passwords are not required. Some versions of the TFTP server allow 
crackers to grab any file on the system&#151;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.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I31" NAME="I31">

<FONT SIZE=4><B>Intrusion Detection</B>

<BR></FONT></A></CENTER></H3>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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?

<BR></P>

<P>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.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I32" NAME="I32">

<FONT SIZE=3><B>Message Digests</B>

<BR></FONT></A></CENTER></H4>

<P>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&#151;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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>Files change all the time on UNIX systems, and if you don't configure it correctly Tripwire may become your UNIX equivalent of &quot;the boy who cried wolf.&quot; 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.

<BR></P>

<P>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.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I33" NAME="I33">

<FONT SIZE=3><B>C2 Auditing</B>

<BR></FONT></A></CENTER></H4>

<P>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, 1994, this information is 
recorded in an audit file.

<BR></P>

<P>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.

<BR></P>

<P>Note that there is a difference between offering &quot;C2 security features&quot; (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 &quot;C2 features&quot; aren't valuable, but you should know the difference.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I34" NAME="I34">

<FONT SIZE=3><B>Program Wrappers</B>

<BR></FONT></A></CENTER></H4>

<P>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.

<BR></P>

<P>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.

<BR></P>

<P>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.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I35" NAME="I35">

<FONT SIZE=4><B>Disaster Recovery</B>

<BR></FONT></A></CENTER></H3>

<P>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 &quot;Finding More Information&quot; 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.

<BR></P>

<P>This list is not exhaustive, but it shows a broad range of post-intrusion options. Some of these options&#151;such as requiring all your users to change their passwords&#151;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.

<BR></P>

<P>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.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I36" NAME="I36">

<FONT SIZE=4><B>Security Tools</B>

<BR></FONT></A></CENTER></H3>

<P>Programmers have developed automated security tools (ASTs) to assess your system security. ASTs are sharp on both sides&#151;if you don't use them to find insecurities, crackers may.

<BR></P>

<P>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.

<BR></P>

<P>There are two problems with ASTs. First, you may gain a false sense of security when they cheerfully report &quot;all's well.&quot; ASTs only report known insecurities, and new ones are discovered constantly. A second, related problem, is that if 
crackers break