لطفا منتظر باشید ...
Shutting Down
Unnecessary Servers
Server programs, by design, provide access to
a computer. Thus, every server that runs on a computer increases the risk that
an unwanted individual will gain access to the computer. The interloper might
gain access through a bug in the server, a misconfiguration of the server, or a
compromised password. Whatever the exact details, one effective means of
reducing this risk is to shut down unnecessary servers. The first step to doing
this is locating unnecessary servers. Once located, you must decide to shut the
server down. Shutting down a server is normally a simple task, but some methods
are more effective than others.
Locating Unnecessary Servers
The task of locating unnecessary servers can
be broken down into two subtasks: Identifying servers that are running on your
system and determining which of these servers is unnecessary to normal system
operation. There are several ways to go about both of these tasks, and you may
want to do so in multiple ways to improve your chances of success.
Locating Servers
Unfortunately, there is no centralized
registry of running servers on a Linux system. If there were, locating servers
would be a relatively straightforward process. Instead, you must piece together
information from several different sources. It may be possible to overlook a
server by one method, so it's best if you use several to locate your servers.
Using Package Management Systems
One tool that's useful in locating servers is
your distribution's package management system. If you use the Red Hat Package
Manager (RPM) or Debian packages exclusively, your database should contain a
listing of every package that's installed on a computer. You can use this
database to browse the installed packages, reading package descriptions to help
you determine whether a package contains a server, and if so, whether you need
it or not. Tools that are particularly helpful for this task are GUI package
management systems, such as Red Hat's GNOME RPM, SuSE's YaST, and the Storm
Package Manager (part of the Storm distribution, but also useable with Debian).
These tools allow you to browse the installed packages in a window, as in the
GNOME RPM window shown in
can click a package and choose an option to read a description of the package. Some
package managers categorize their packages so that you can more easily locate
them, but these categories aren't as strictly defined as they might be, so you
may need to look in all the categories to locate all your servers. This
approach also will not find servers that you installed from tarballs or from
source code. Finally, you can't tell whether a server is actually running with this approach. A server that's installed
but not running poses much less risk than one that's actually running. (The
main risk is that some future configuration change might accidentally start the
server running, thus increasing your risk.)
Figure 22.1. GUI package
management tools let you look for installed servers.
Examining Server Startup Files
Another way to look for servers is to examine
the common server startup files: Super server
configurations Check your /etc/inetd.conf and /etc/xinetd.conf files, and files within the /etc/xinetd.d directory. These
contain references to all the servers that are started through the super
server. When using inetd , server lines that begin with pound signs ( # ) are inactive.
With xinetd , entries that include a disable = yes line are
inactive. SysV startup scripts You can check your SysV startup script locations (usually /etc/rc.d/rc?.d or /etc/rc?.d , where ? is the runlevel number) for servers started through SysV scripts. You
can learn a lot from the presence of these files and their filenames. Note that
some of these scripts start programs that are not servers, so you shouldn't
automatically disable anything you don't recognize. Local startup scripts Many distributions use scripts called rc.local , boot.local , or
something else to run local programsthose that
are installed in a way unique to a specific computer, rather than in a standard
way for the distribution in question. You'll have to check these scripts line-by-line
to determine what, if any, servers they start.
Starting Servers, describes each of these server startup methods in more detail,
including information such as the naming conventions for SysV startup scripts. You
may also want to employ a tool such as ntsysv or tksysv to help
interpret SysV startup scripts (and, on some distributions and with some tools,
super server configurations). For a more console-based approach, typing chkconfig --list displays the status of SysV and possibly xinetd startup
scripts on some distributions (notably Caldera, Mandrake, Red Hat, and
TurboLinux).Examining server startup methods can help you
determine what servers are running, but it may not paint a complete picture of
what servers are installed. For that, you'll
need to use a package management system or examine every executable on your
computer (a tedious proposition at best). As noted earlier, a package that's
installed but not running poses much less of a risk than does one that's
installed and running.
Examining Running Processes
Another tool that can be helpful in locating
servers is ps . This command returns information on running processes. You can
provide dozens of different options to modify the program's operation, but
typing ps ax is a good starting point if you want to locate servers. The output
is likely to be quite extensive, so you may want to redirect it to a file or
pipe it through more or less so you can examine the whole of the output. If you're searching for
a specific server, you can pipe the result through grep , as in ps ax | grep sendmail to locate information on any sendmail processes that
are running. However you use it, ps provides information on both server and
nonserver processes. Here's an edited example of its output: $ ps ax PID TTY STAT TIME COMMAND 1 ? S 0:15 init [3] 502 ? S 0:05 named -u bind 520 ? S 0:01 cupsd 535 ? SW 0:00 [nfsd] 1741 pts/4 S 0:00 /bin/bash 4168 ? S 0:00 httpd
Actual ps
outputs are likely to contain dozens of lines, even on a lightly loaded system.
This example has trimmed all but a few entries for demonstration purposes. The
first entry, with a process ID (PID) of 1, is always init . This process sits at the root of the
process tree; all others derive from it, directly or indirectly. Processes
whose names (in the COMMAND
column) are in brackets, such as [nfsd] ,
are kernel processes. You might recognize nfsd
as the name of the NFS daemona kernel-based server. Other servers in this
example are named , cupsd , and httpd , all of which are user-space servers. Two clues help
identify these as servers. First, their names all end in d , for daemon.
Second, they aren't tied to specific ttys (the TTY
column contains a question mark). Many nonserver processes, such as /bin/bash in this example, are tied to
specific ttys. Neither of these details indicates with certainty that a process
is a server, but they're useful clues.Once you've spotted potential servers with ps , you may want to try locating
documentation for the processes in question. Type man name , where name
is the name of the process; and try locating the binary file with the name of
the process, and track down its package and documentation (for instance, rpm -qf /path/to/name to locate the
package associated with name
on an RPM-based system, or dpkg -S
/path/to/name to
do the same thing on Debian).Keep in mind when using ps
that it won't locate servers that aren't running at the moment you check for
them. In particular, if a server is started through a super server, you won't
find it by examining a process list unless somebody is using the server at the
moment you try this test. This procedure also won't locate a server that's
crashed or has been temporarily taken down for maintenance.
Using
netstat
One problem with the ps
approach is that it's not always obvious which processes are involved in
network operations, much less which are servers. One tool that you can use to
help fine-tune this identification is netstat .This program reports information on network connections,
including which ports are in use. Like ps ,
netstat takes a large number of
options that modify its behavior. To help locate servers, netstat -lp is a good starting point.
This locates ports that are being listened to ( -l ),
and causes netstat to print ( -p ) the name of the server that's doing
the listening. The output also includes the port to which the server is
listening, and additional information. As with ps ,
you'll probably want to redirect the output to a file or pipe it through less or more .Although netstat
can be a useful tool, it's got its limits. It displays the ports that are being
listened to, but the program list won't be completely accurate for servers
started through a super server; netstat
will report the super server name rather than the name of the program that
ultimately fields the request.
Using
External Scanners
One of the most powerful tools for locating servers is an
external scanner program, such as Nessus (target="_blank">http://www.nessus.org ),
SAINT (http://www.wwdsi.com/saint/ ), or Nmap (
These programs run on a computer other than the one you want to check, and scan
the target system for running servers. Depending on the exact goals of the
scanner developers, it may report additional information, such as the OS in use
on the target or whether a server has any known vulnerabilities. A basic scan
can often be performed very simply by typing the tool's name followed by the
target system's hostname, as in nmapgingko.threeroomco.com .
The result should be a list of open ports and associated server types.WARNING
align=left border=0> Port scanners are frequently used by crackers to help them
locate vulnerable systems. Using the same tools yourself can be helpful in
that you'll spot the sorts of vulnerabilities a miscreant might locate.
Sadly, using these tools can also cast suspicion upon you, especially if the
use of the tool is unauthorized. Before you obtain and use a port scanner, clear
its use with your superiors. If you don't, you could find yourself in
troubleperhaps even enough to lose your job!
An external scan can be particularly helpful if you suspect a
server may have already been compromised. A competent cracker can replace tools
like ps and netstat so that any additional servers
won't appear to be running. An external scan might
discover these servers.NOTE
align=left border=0> The media generally use the term hacker
to refer to computer criminals. Individuals who enjoy programming or working
with computers in perfectly legal and honorable ways, however, have long used
this term to refer to their own activities. Indeed, many of the people who
wrote Linux consider themselves to be hackers in this positive sense. For this
reason, I use the term cracker to refer to
computer criminals and miscreants.
The drawback to an external scan is that it may not spot
servers if they're not accessible to the system doing the scanning. For
instance, if a computer has two network interfaces, scanning one interface
might turn up no servers running, when many servers are running on the other
interface. Likewise, firewall tools can block access to servers based on IP
addresses, so even if a computer has just one network interface, an external
scanner might not detect a server if a firewall blocks the scanning system.
Determining
When a Server Is Unnecessary
Once you've developed a list of servers, you must decide which
ones are necessary. Unfortunately, this task isn't always easy. Unless you're
intimately familiar with the operation of a Linux system, you may not
understand the function of a server, and so may believe it's unnecessary, when
in fact it plays some important role. The preceding chapters of this book can
help you determine whether many specific servers are necessary on your system.
You can also consult the server's documentation, such as its man pages, or
perform a Web search to locate more information.If you're still not sure if a server is
strictly necessary, you can try shutting it down and see what happens. If the
computer continues to operate normally in all respects, you can be sure that
the server wasn't doing anything necessary; however, most servers do provide some sort of noticeable function. It's
possible that the server you shut down does something necessary, but that is
not immediately obvious. For instance, you can run a font server (described in
Providing Consistent Fonts with Font Servers) even on a computer that doesn't
run X. The computer itself will continue to function if you shut down the font
server, but other systems will soon begin to malfunction.You should also be very cautious about
shutting down processes related to logins. Although remote login servers, as
described in
necessary, disabling local logins can cause serious problems that would require
an emergency boot floppy to correct. You should be cautious about removing
login processes started from SysV startup scripts or other system startup
scripts.One fortunate fact is that no process started
from a super server is vital for local operation. If you don't recognize a
super server entry, you can remove it and the local computer will continue to
function. As just noted, of course, other
systems might be adversely affected, but you can remove all the super server
entries and that computer will still boot and be usable from the console.
Methods of Shutting Down Servers
You can shut down servers in several different
ways. As a general rule, there are two main approaches: You can reverse whatever process is used to
start the server. For instance, you can comment out an entry in /etc/inetd.conf or rename a SysV startup script.
files aren't installed at all, it can't be run.The first method is usually the safest one to
try if you're not absolutely certain you don't need the server, because it's
the easiest to reverse. If you disable a server and then find that you do need it, you can quickly restore its startup
configuration.TIP
align=left border=0> When disabling a server, try doing so in a
way that doesn't delete any configuration information. For instance, comment
out an entry in /etc/inetd.conf rather than delete it, or rename a SysV startup script rather
than delete it. This allows for easy reversal of your changes should the need
arise.
Once you're convinced that the server program
is completely unnecessary, removing it from the computer makes sense. Eliminating
the server ensures that it won't be started accidentally in the future, and
saves disk space. If you think you might want the server in the future, you
might want to leave it installed; or you could remove it and back up its
configuration files, if you've modified them, so that you can restore your
configuration should you decide to re-install the server.
