Throughout this book, we will mainly deal with installation and
configuration issues. Administration is, however, much more than
that—after setting up a service, you have to keep it running, too.
For most services, only a little attendance will be necessary, while some,
like mail and news, require that you perform routine tasks to keep your system
up to date. We will discuss these tasks in later chapters.
The absolute minimum in maintenance is to check system and per-application
log files regularly for error conditions and unusual events. Often, you
will want to do this by writing a couple of administrative shell scripts
and periodically running them from cron. The source
distributions of some major applications, like inn or
C News, contain such scripts. You only have to tailor them to suit your
needs and preferences.
The output from any of your cron jobs should be mailed to an
administrative account. By default, many applications will send error
reports, usage statistics, or log file summaries to the
root account. This makes sense only
if you log in as root frequently; a much
better idea is to forward root's mail to
your personal account by setting up a mail alias as described in
Chapter 19 or Chapter 18.
However carefully you have configured your site, Murphy's law guarantees
that some problem will surface eventually. Therefore,
maintaining a system also means being available for complaints. Usually,
people expect that the system administrator can at least be reached via email
as root, but there are also other
addresses that are commonly used to reach the person responsible for a
specific aspect of maintenence. For instance, complaints about a
malfunctioning mail configuration will usually be addressed to
postmaster, and problems with the
news system may be reported to
newsmaster or
usenet. Mail to
hostmaster should be redirected to
the person in charge of the host's basic network services, and the DNS name
service if you run a name server.
Another very important aspect of system administration in a network
environment is protecting your system and users from intruders.
Carelessly managed systems offer malicious people many targets. Attacks
range from password guessing to Ethernet snooping, and the damage caused
may range from faked mail messages to data loss or violation of your
users' privacy. We will mention some particular problems when discussing
the context in which they may occur and some common defenses against them.
This section will discuss a few examples and basic techniques for
dealing with system security. Of course, the topics covered cannot
treat all security issues you may be faced with in detail; they merely
serve to illustrate the problems that may arise. Therefore, reading a
good book on security is an absolute must, especially in a networked
system.
System security starts with good system administration. This includes
checking the ownership and permissions of all vital files and
directories and monitoring use of privileged accounts. The COPS
program, for instance, will check your file system and common
configuration files for unusual permissions or other anomalies. It is
also wise to use a password suite that enforces certain rules on the
users' passwords that make them hard to guess. The shadow password
suite, for instance, requires a password to have at least five letters
and to contain both upper- and lowercase numbers, as well as
non-alphabetic characters.
When making a service
accessible to the network, make sure to give it “least
privilege”; don't permit it to do things that aren't required
for it to work as designed. For example, you should make programs
setuid to root or some other
privileged account only when necessary. Also, if you want to use a
service for only a very limited application, don't hesitate to
configure it as restrictively as your special application allows. For
instance, if you want to allow diskless hosts to boot from your
machine, you must provide Trivial File Transfer
Protocol (TFTP) so that they can download basic
configuration files from the /boot
directory. However, when used unrestrictively, TFTP allows users
anywhere in the world to download any world-readable file from your
system. If this is not what you want, restrict TFTP service to the
/boot directory.[1]
You might also want to restrict certain services to users from certain
hosts, say from your local network. In Chapter 12,
we introduce tcpd, which does this for a variety of
network applications. More sophisticated methods of restricting access
to particular hosts or services will be explored later in Chapter 9.
Another important point is to avoid “dangerous”
software. Of course, any software you use can be dangerous because
software may have bugs that clever people might exploit to gain access
to your system. Things like this happen, and there's no complete
protection against it. This problem affects free software and
commercial products alike.[2] However, programs that require special privilege are inherently
more dangerous than others, because any loophole can have drastic
consequences.[3]
If you install a setuid program for network purposes, be doubly
careful to check the documentation so that you don't create a security
breach by accident.
Another source of concern should be programs that enable login or
command execution with limited authentication. The
rlogin, rsh, and
rexec commands are all very useful, but offer very
limited authentication of the calling party. Authentication is based
on trust of the calling host name obtained from a name server (we'll
talk about these later), which can be faked. Today it should be
standard practice to disable the r commands
completely and replace them with the ssh suite of
tools. The ssh tools use a much more reliable
authentication method and provide other services, such as encryption
and compression, as well.
You can never rule out the possibility that your precautions might
fail, regardless of how careful you have been. You should therefore
make sure you detect intruders early. Checking the system log files is
a good starting point, but the intruder is probably clever enough to
anticipate this action and will delete any obvious traces he or she
left. However, there are tools like tripwire,
written by Gene Kim and Gene Spafford, that allow you to check vital
system files to see if their contents or permissions have been
changed. tripwire computes various strong
checksums over these files and stores them in a database. During
subsequent runs, the checksums are recomputed and compared to the
stored ones to detect any modifications.
