لطفا منتظر باشید ...
1.4. Maintaining Your System
Throughout this book, we will
mainly deal with installation and configuration issues.
Administration is, however, much more than thatafter setting
up a service, you have to keep it running, too. For most services,
only a little attendance will be necessary, while some, such as mail,
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
logfiles 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 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 logfile 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 Chapters
Chapter 11 and Chapter 12.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 nameserver.
1.4.1. System Security
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 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 filesystem
and common configuration files for unusual permissions or other
anomalies. Another tool, Bastille Linux, developed by Jay Beale and
found at http://www.bastille-linux.org, contains a
number of scripts and programs that can be used to lock down a Linux
system. 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, now a default, requires a password
to have at least five letters and to contain both upper- and
lowercase numbers, as well as nonalphabetic
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 (we'll come back to this in Chapter 10). You might also want to restrict certain
services to users from certain hosts, say from your local network. In
Chapter 10, 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 in Chapter 7.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.[5] However, programs that require
special privilege are inherently more dangerous than others because
any loophole can have drastic consequences.[6] 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.[5] There have been
commercial Unix systems (that you have to pay lots of money for) that
came with a setuid root shell script, which allowed users to gain
root privilege using a simple
standard trick.[6] In 1988,
the RTM worm brought much of the Internet to a grinding halt, partly
by exploiting a gaping hole in some programs, including the
sendmail program. This hole has long since been
fixed.
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 hostname
obtained from a nameserver (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 that you detect intruders early. Checking the system
logfiles 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.
Finally,
it's always important to be proactive about
security. Monitoring the mailing lists for updates and fixes to the
applications that you use is critical in keeping current with new
releases. Failing to update something such as Apache or OpenSSL can
lead directly to system compromise. One fairly recent example of this
was found with the Linux Slapper worm, which propagated using an
OpenSSL vulnerability. While keeping up to date can seem a daunting
and time-consuming effort, administrators who were quick to react and
upgrade their OpenSSL implementations ended up saving a great deal of
time because they did not have to restore compromised
systems!
