|
Ch 13 -- Security Technologies
UNIX Unleashed, Internet Edition
- 13 -
Security Technologies
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:
- Security policies
- Physical security measures
- Access control and user authentication
- Network security
- Invasion detection
- Disaster recovery
- Firewalls and hardware devices
- Automated security tools
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.
Security Policies
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.
Security Policy Considerations
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.
Goals of a Security Policy
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:
- Availability. The system and at least the most important information it holds
must be available for use when the users need them.
- Utility. The system and the information it holds is intended to serve a purpose.
They must not only be available, but be available in such a way that that purpose
is met.
- Integrity. The system and the information it holds must remain intact and accessible.
- Authenticity. There must be a way for the system to ensure that potential users
are allowed access to various resources. Similarly, users should be able to verify
that they are connected to the right system.
- Confidentiality. Some information may be deemed private or semi-private; security
mechanisms must allow such designations and control access to that information appropriately.
- Possession. The owners of the system must be able to control its use and daily
operations. Because UNIX is a multi-user operating system, if the administrator loses
control of the system to a cracker, all users are affected.
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.
Physical Security
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?
- Enter your facility
- Read manuals, logon instructions, configuration notes, or system dumps
- Copy or take away tapes, PCMCIA cards, removable disks, or diskettes
- Connect their own laptop to a network backbone
- Sit down at a workstation
- Approach the system console
- Read or take away printer output
- See or modify your telephone panels
- Tap into network transmissions over copper, fiber, infrared, or cellular media
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.
Physical Access to People
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.
Thwarting Dumpster-Diving Attacks
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.
Thwarting Network- and Phone-Based Attacks
If your computer system is attached to a network, it is both a more attractive
target and easier to crack. Physical access to the computer is no longer necessary,
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.
People Issues
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.
User Authentication
Authentication is a fancy name for identifying yourself as a valid user
of a computer system, and it's your first defense against a break-in. Until recently,
UNIX user authentication meant typing a valid login name and password. This is known
as reusable password authentication, meaning that you enter the same password
each time you log in. Reusable password authentication is too weak for some systems
and will eventually be replaced by one-time password systems in which you enter a
different password each login.
Reusable passwords are strong enough for some sites as long as users choose good
passwords. Unfortunately, many don't. Research has shown that as many as 30% 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.
Picking Good Passwords
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.
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% 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.
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 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.
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 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.
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). 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
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.
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.
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. 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.
.rhosts and the Superuser Account
The superuser account (root) gets special treatment. Even if a host appears
in /etc/hosts.equiv, root at that host is not considered equivalent
unless the file /.rhosts also exists and contains a line for that site's
root account. While this may be convenient for software distribution using
rdist, consider carefully the security implications before you create a
/.rhosts; passwordless software distribution is also convenient for crackers.
For instance, if a cracker gains superuser access on ws1.corp.com, he can
install a special version of the login program on that host, use rdist
to send it to the other nine, and break into those, too. It may be better to forgo
/.rhosts files and do your software distribution the hard way with ftp.
.netrc Authentication
The .rhosts and /etc/hosts.equiv files only work with the so-called
r-commands (rsh, rlogin, rdist, rcp). The telnet
and ftp will still ask for a login name and password. However, you can use
the .netrc file to automate ftp access. The .netrc should
reside in your home directory on the host from which you run ftp. It contains
a list of host names, login names, and passwords, all unencrypted. Because it holds
clear text passwords, the .netrc file must be readable only by its owner.
Because the password is unencrypted, a .netrc is a worse security risk than
a .rhosts. It is useful for anonymous ftp access, though. For instance,
if you often log in to the host ftp.cert.org to look at the CERT/CC advisories,
you could create a .netrc containing the following lines:
machine ftp.cert.org
login anonymous
password yourlogin@yourhost.domain
This is safe 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.
File System Security
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.
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.
- 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
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.
sendmail
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.
Network File System (NFS)
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.
Network Information System (NIS)
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.
finger
You should run fingerd as an unprivileged user--the login nobody
is a good choice.
Trivial File Transfer Protocol (TFTP)
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.
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 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.
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. 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.
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. 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.
Automated 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.
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
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 and Courtney
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.
SPI-NET
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
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.
Online Sources for Automated Security Tools
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.
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.
Firewall technology is changing rapidly and many commercial products are now available.
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
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 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.
Summary
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.
| 
