Tracking Down Unnecessary Servers

To keep your system running securely and efficiently, you should periodically audit your system, looking for servers that need not be running. Here’s how to do it.
Linux is an extremely flexible operating system. You can run it on a server, on a workstation, or in various more specialized roles. This flexibility also means that you can’t be sure just what you’ll get when you install Linux — at least, not without substantial experience with a specific distribution. Perhaps the distribution you install runs certain server programs by default. And even if you know the default installed configuration, your system can change over time. For example, you might have tried out a server program, decided you didn’t want it, and then deleted it. Or perhaps just forgot about it.
For whatever reason, unnecessary servers often run on and on. Some can be a nuisance, consuming CPU time, memory, network bandwidth, and other resources that you’d rather devote to other tasks. Worse, unnecessary servers can be a security threat. A bug or misconfiguration in a server can leave your system vulnerable to attack. This threat is particularly great when you’re unaware that the server is running, because you’re unlikely to spend time upgrading such servers and tending to configurations.
For these reasons, you should periodically audit your system, looking for servers that need not be running. Once you’ve identified such servers, you should delete them or at least disable them.

Using netstat to Find Running Servers

Several tools exist to help locate servers. One of the most direct of these is netstat, which is something of a Swiss Army knife of network utilities. Depending on the options you give it, netstat can display information on your network interfaces, routing table, open sockets, and more.
To locate running servers, use netstat ‘s ability to display open sockets, including those that are listening for connections. To do so, pass it the –a and –p options, which you can combine together:
$ netstat –ap
The result is likely to be an overwhelmingly long list of ports and program names. The output is also likely to exceed 80 columns, so you may need to widen your xterm window or run netstat from a larger-than-normal text video mode, as described in the January 2005 “Guru Guidance” column (available online at http://www.linux-mag.com/2005-01/guru_01.html). The best approaches are to pipe the output through less and to use grep to search for particularly important keywords. Figure One shows the first few lines of output on one system, as piped through less.
Figure One: The netstat output can be quite long.

The netstat –ap output is arrayed in columns, and some of the most important columns are:
*Proto. The first column specifies the protocol — most commonly tcp or udp for TCP or UDP, respectively.
*Local address. This is the fourth column, and it specifies the IP address and port number used by the connection. (Whenever possible, netstat converts IP addresses to hostnames, and port numbers to their names based on entries in /etc/services.) An asterisk in the IP address area signifies a server listening on all available addresses.
*Foreign address. This is the fifth column, and it specifies the hostname or IP address, as well as the port name or number, of the remote system. Listening servers list both of these as asterisks (as in *:*).
*State. This is the sixth column, and it’s a code word that specifies the state of the connection. Most importantly, LISTEN denotes a server that’s listening for connections and ESTABLISHED denotes an established connection.
*PID/Program name. The seventh and final column lists the program process ID (PID) and program name, if available. If you run netstat as a non- root user, this information is unavailable for most sockets, so for full identification of processes, run netstat as root.
Following the TCP and UDP information, netstat displays information on Unix domain sockets. These are connections that are local to the Linux computer itself and that don’t use a network address (not even the loopback address). Thus, some of the information displayed is different from that just described. Servers listening on Unix domain sockets but not on TCP/IP ports don’t pose a security threat (at least, not to the extent of unwanted TCP/IP servers), so you can safely ignore these lines of the netstat output, at least for the purpose of finding unwanted network servers.
Because servers, by definition, are programs that listen for network connections, you can use grep to search for all your servers:
# netstat –ap | grep LISTEN
Even this result may be long enough you’ll want to pipe it through less. From this output, you should be able to easily extract the port numbers the servers are using and, if you ran netstat as root, the PID number and program name that’s listening to the ports.

Tracking Down the Server Programs

Unfortunately, using netstat isn’t the end of the process. Although netstat does give you a PID and program name, that information isn’t always accurate. Most notably, when you use a super server, such as inetd or xinetd, netstat reports the super server’s name rather than the target server’s name. So, if you run many programs from a super server, you’re likely to see many entries in the netstat output showing the super server and its PID number.
The port mapper, a tool used by the Network File System (NFS) and a few other servers to manage connections, is another special case, but it runs in addition to the target server that it manages. (The port mapper is often started as a requirement for starting a super server, because a super server can run some servers that rely on the port mapper.)
When tracking down servers run via a super server, you’ll need to consult the local address column (the fourth in the netstat output) and compare it to your super server configuration.
For instance, consider the following output fragment:
tcp 0 0 *:saned  *:* LISTEN 7648/xinetd
tcp 0 0 *:5900 *:* LISTEN 7648/xinetd
tcp 0 0 *:sunrpc *:* LISTEN 7282/portmap
tcp 0 0 *:nfs *:* LISTEN -
tcp 0 0 *:telnet *:* LISTEN 7648/xinetd
tcp 0 0 *:631 *:* LISTEN 6899/cupsd
This output indicates that three servers are being run via xinetd:
saned, telnet, and something using port 5900 (this is in fact a VNC
server session). A fourth server (cupsd) is running on its own accord
(using port 631). The port mapper is running on the sunrpc port, and although it’s not immediately obvious from this output, the nfs server
is being mediated by the port mapper. (Such servers frequently display a
dash in the PID/process name column, even when root runs netstat.)
For the servers that are being handled by the super servers, consult your
super server configuration — the /etc/inetd.conf file for inetd, or
the /etc/xinetd.conf file and files in /etc/xinetd.d for xinetd.
You should find references to each server’s port name or number (saned,
5900), and telnet in this example) in these files. grep is useful to search for these strings:
$ grep saned /etc/xinetd.d/*
The result should be a list of files in which the string appears, along with the lines in the files in which the string appears. If you choose to disable the server, you can use this information to do the job, as described shortly.
Some configurations use port numbers in the super server configuration, but netstat will return port names. If your search doesn’t turn up any hits, try looking up the port number in /etc/services. For instance, searching for the string saned in that file reveals that saned uses port 6566. You can then search your super server configuration for anything that uses port 6566.
Identifying portmapper-mediated servers can be done using the rpcinfo program. Pass it the –p parameter and the name of a system (such as localhost for the local computer) and it returns basic information on the servers it’s handling. The output typically includes several lines for each service, along with port numbers. The design of RPC servers is such that you’re likely to see both the target server (such as nfs) and support servers (such as nlockmgr or status). Details vary from one system to another, though.
Identifying standalone servers is relatively straightforward: the final column of the netstat output should identify them by PID and by process name. If necessary, you can double-check by searching for them using ps, as in ps ax|grep 6899 to locate the process with PID 6899.

Determining What a Server Does

In all of these cases, of course, knowing the server name, as revealed directly by netstat, by the rpcinfo program, or by the contents of your super server configuration, only takes you so far. You must know what the server does before you can decide what to do with it. This step is trivially easy if you’re a walking encyclopedia of Linux servers, but for everybody else, a bit of research is in order.
Start with the Linux man pages. Try using the server name, as in man cupsd. If this brings up an entry, it may tell you enough about the server to decide whether or not to keep it. The Linux info page system (info cupsd) can also be a useful resource.
Another trick is to locate the server program using your package manager and then look for documentation. For instance, in the previous example, the cupsd server has PID 6899, and typing ps ax|grep 6899 reveals that the full path to the server executable is /usr/sbin/cupsd. On an RPM-based system, typing rpm –qf /usr/sbin/cupsd then reveals that the package name is cups, and rpm –ql cups|grep doc reveals all of the files in that package that contain the string doc (hence, many documentation files) in their paths. If you find nothing in this way, try omitting the grep command to locate all the files that came with the package; perhaps one of them will provide a clue.
Web searches can also be quite useful. Try searching on the server name and “Linux.” This approach can be helpful both when you can’t find local documentation and when that documentation is difficult to comprehend. Some of the RPC services are particularly poorly documented in local documentation and so can benefit from investigation in this way.

Disabling Unwanted Servers

By this point, you should have completed an inventory of the servers that are running on your system and have a good idea of which ones you need and which ones you don’t need. (Note that even if the port mapper isn’t doing anything, some distributions require that it runs, at least when you use their conventional startup scripts. The idea is that you might decide to add a server that needs the port mapper, so it should be running at all times.)
Temporarily disabling individual servers that are running in a standalone manner is fairly easy — you can use kill or the package’s SysV startup script (passing it the stop parameter). This won’t do the job permanently, though; for that, you must disable whatever mechanism the server uses to start itself.
Most distributions provide utilities to help automate management of SysV startup scripts to permanently enable or disable servers. In Red Hat, Fedora, SuSE, and most other distributions, the chkconfig program is the most basic tool that does this job. Type chkconfig –d name to disable the name SysV script in the current runlevel.
In Gentoo Linux, rc-update does a similar job, but you specify a named runlevel, such as default for the default runlevel. For instance, rc-update del badserver default removes the badserver SysV startup script from the default runlevel. Once you make such a change, you should also manually shut down the server, typically by passing the stop argument to the SysV script, to ensure that it’s not running. Disabling it via the SysV startup scripts only disables it until the next reboot or until you change into the runlevel you’ve configured.
For super servers, you must reconfigure the super server. For inetd, you should delete or comment out the line in /etc/inetd.conf that refers to the server in question. Adding a hash mark (#) to the start of the line makes it a comment. For xinetd, locate the entry for the server, which spans multiple lines and looks something like this:
service telnet
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.telnetd
server_args = –h
disable = no
Locate the line that reads disable=no and change it to read disable=yes. If the line doesn’t exist, add it.
Whether you’re using inetd or xinetd, you must tell the super server to reload its configuration to enable the changes. The super server is usually started through its own SysV startup script. Look for it and pass it the reload option, as in /etc/init.d/xinetd reload. Sometimes this won’t work properly, but passing the restart option should do the trick. This has the disadvantage of occasionally disrupting existing connections, though.
Servers that use the port mapper are started using their own SysV startup scripts or super server configurations, and so can be disabled in the same way you’d disable other servers.

Deleting Unwanted Servers

Disabling unwanted servers is all well and good, but if you don’t need the server and you’re sure you’ll never need it, completely deleting it from the system is the safer alternative. This action ensures that you won’t accidentally start the server again in the future. You should begin by disabling the server, as just described. After you’ve done that, track down the server’s package using your package management system. You can then delete the package using that system.
Keep a caveat in mind, though: Sometimes a server is installed in a single package along with other programs that you do need. Thus, you should review the package’s description before you delete it.
You may also run into dependency problems. When a server package includes other programs you do need or when other packages depend on the server package, you may best be served by simply disabling the server. In the case of dependencies, investigate the packages in question, though; perhaps they require that the server actually be running. If this is the case, you’ll have to decide whether to leave the server running or to delete the program that relies on the server.

Roderick W. Smith is the author or co-author of over a dozen books, including Linux in a Windows World and The Definitive Guide to Samba 3. He can be reached at class="emailaddress">rodsmith@rodsbooks.com.

Comments are closed.