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 Figure 22.1. You 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 programs ”those 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.

Chapter 4, 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 daemon ”a 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 (http://www.nessus.org), SAINT (http://www.wwdsi.com/ saint /), or Nmap (http://www. insecure .org/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

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 trouble ”perhaps 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

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 Chapter 15, 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 Chapters 13 and 14, may not be 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. Chapter 4 discusses these methods.

• You can uninstall the server. If the server's 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

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.