<BR></P>

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

<BR></P>

<PRE>lucre.corp.com mylogin</PRE>

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

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>While this is convenient, it carries a risk&#151;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.

<BR></NOTE>

<HR ALIGN=CENTER>

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

<BR></P>

<PRE>ws1.corp.com

ws2.corp.com

[_]

ws10.corp.com</PRE>

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

<BR></P>

<H4 ALIGN="CENTER">

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

<FONT SIZE=3><B><I>.rhosts</I></B><B> and the superuser account</B>

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

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

<BR></P>

<H4 ALIGN="CENTER">

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

<FONT SIZE=3><B><I>.netrc</I></B><B> authentication</B>

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

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

<BR></P>

<PRE>machine ftp.cert.org

login anonymous

password yourlogin@yourhost.domain</PRE>

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

<BR></P>

<P>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 &quot;Security Tools&quot; later 

in this chapter) check the security of your users' .rhosts and .netrc files.

<BR></P>

<H3 ALIGN="CENTER">

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

<FONT SIZE=4><B>File System Security</B>

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

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

<BR></P>

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

<BR></P>

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

<BR></P>

<H4 ALIGN="CENTER">

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

<FONT SIZE=3><B>Backup Policies</B>

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

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

<BR></P>

<P>You should answer the following questions about your backup strategy:

<BR></P>

<UL>

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

<BR>

<BR></LI>

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

<BR>

<BR></LI></UL>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="warning.gif" WIDTH = 37 HEIGHT = 35><B>WARNING: </B>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&#151;in fact, anything that moves the tape 
over the capstan.

<BR>

<BR>Further, tape formulations vary among manufacturers and even between production runs as vendors change their formulations. To make matters worse, buying &quot;data grade&quot; 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.

<BR>

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

<BR></NOTE>

<HR ALIGN=CENTER>

<UL>

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

<BR>

<BR></LI>

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

<BR>

<BR></LI>

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

<BR>

<BR></LI>

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

<BR>

<BR></LI></UL>

<H3 ALIGN="CENTER">

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

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

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

<P>Attaching your computer to a network presents a host of new security threats&#151;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.

<BR></P>

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

<BR></P>

<H4 ALIGN="CENTER">

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

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

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

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

<BR></P>

<P>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&#151;and especially if you allow anonymous logins&#151;crackers have a program to exploit that might give them superuser privileges.

<BR></P>

<P>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&#151;if you don't need the features, the BSD version may be better.

<BR></P>

<P>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 &quot;Program Wrappers&quot; later in this chapter) to run a short program that changes to a secure directory and runs chroot 

before invoking ftpd.

<BR></P>

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

<BR></P>

<HR ALIGN=CENTER>

<NOTE>