Locating Unnecessary Servers

Before you can remove servers you're not using, you must locate them. You can go about this task in several ways, each of which has its specific advantages and disadvantages. Broadly speaking, three methods are checking for installed or running software, monitoring the local computer's network activity, and scanning one system from another.

Checking Installed or Running Software

Several Linux tools, which are described more fully in other chapters, can help you track down software that's installed or running. At a crude level, the Is command or a GUI file browser enables you to see what files exist in common program directories, such as /bin, /sbin, /usr/bin, /usr/sbin, /usr/X11R6/bin, /usr/local/bin, and /usr/local/sbin. (Many distributions also store program files in subdirectories of/opt.) Unfortunately, many of the files you'll find in these directories have cryptic names, so figuring out what these programs do can be time-consuming. As the /usr/local directory tree holds files you've installed without the benefit of your distribution's package management system, you may want to take the time to study its contents periodically to be sure there's nothing you've forgotten or that's suspicious in this directory tree.

Tip If you don't recognize a program name, type man progname, whereprogname is the program name. Many programs come with man pages describing their operation, so chances are good you'll find information on what the program does.

Most software on most Linux systems is installed with the help of package management systems, as described in Chapter 11, "Managing Packages." This fact provides a means to study the software installed on your system. GUI package management tools, such as GNOME RPM, MandrakeUpdate, Red Hat's Package Management, SuSE's YaST2, or the Storm Package Manager for Debian, can be very useful because they enable you to quickly browse the installed packages, reading descriptions of what each package does. For instance, Figure 18.2 shows the Storm Package Manager in operation, including a description of an FTP server installed on the system. Using a package manager, you can uninstall any packages that aren't necessary.

Figure 18.2: GUI package management tools enable you to determine what's installed on your system and remove unnecessary packages.

Another approach to assessing the risk from installed programs is to examine the Linux process table using ps, as described in Chapter 14, "Programs and Processes." For instance, you might type ps ax | less to peruse the processes that are running on your system. Chances are many of these processes will be unfamiliar to you because their names are cryptic and they're programs that normally run in the background and don't require attention. When examining processes, pay particular attention to those whose names end in d. Servers' names often, but not always, end in that letter, which stands for daemon—a word derived from the Greek for "helper." Daemons run in the background and perform useful tasks. Most servers run as daemons, but not all daemons are servers.

One limitation of checking running processes is that this approach doesn't reveal servers that are launched by super servers (inetd orxinetd) unless somebody happens to be accessing the server in question at the time you use ps. Fortunately, you can assess the servers that are handled by the super server fairly easily—check the /etc/inetd.conf file for inetd or the /etc/xinetd.conf file and files in /etc/xinetd.d for xinetd. Chapter 22, "Running Servers," provides more information on the formats used by these configuration files.

Using Local Network Activity Tools

Unfortunately, checking installed and running local programs can be tedious, and it's easy to overlook a server, particularly if its name doesn't make it obvious that it's a server. One tool that can be helpful in spotting stray servers is netstat. This program is the Swiss Army knife of network status tools; it provides many different options and output formats to deliver information on routing tables, interface statistics, and so on. For purposes of spotting unnecessary servers, you can use netstat with its -a and -p options, as shown here:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State

A690/inetd tcp 0 0 teela.rodsbooks.conrssh nessus.rodsbooks.:39361 ESTABLISHED A787/sshd

I've trimmed most of the entries from this output to make it manageable as an example. The Local Address and Foreign Address columns specify the local and remote addresses, including both the hostname or IP address and the port number or associated name from /etc/services. The first of the two entries shown here isn't actively connected, so the local address and the foreign address and port number are all listed as asterisks (*). This entry does specify the local port, though—ftp. This line indicates that a server is running on the ftp port (TCP port 21). The State column specifies that the server is listening for a connection. The final column in this output, under the PID/Program name heading, indicates that the process with a process ID (PID) of 690 is using this port. In this case, it's inetd.

The second output line indicates that a connection has been established between teela.rodsbooks.com and nessus.rodsbooks.com (the second hostname is truncated). The local system (teela) is using the ssh port (TCP port 22), and the client (nessus) is using port 39361 on the client system. The process that's handling this connection on the local system is sshd, running as PID 787.

It may take some time to peruse the output of netstat, but doing so will leave you with a much improved understanding of your system's network connections. If you spot servers listening for connections that you didn't realize were active, you should investigate the matter further. Some servers may be innocent or even necessary. Others may be pointless security risks.

Tip When you use the -p option to obtain the name and PID of the process using a port, the netstat output is wider than 80 columns. You may want to open an extra-wide xterm window to handle this output, or redirect it to a file that you can study in a text editor capable of displaying more than 80 columns. To quickly spot servers listening for connections, pipe the output through a grep LISTEN command to filter on the listening state. The result will show all servers that are listening for connections, omitting client connections and specific server instances that are already connected to clients.

Using Remote Network Scanners

A final method of spotting unnecessary servers is to use a network scanner, such as Nmap (http://www.insecure.org/nmap/) or Nessus (http://www.nessus.org). These tools will scan another computer to locate open ports. More sophisticated tools, including Nessus, will check for known vulnerabilities, so they can tell you if a server might be compromised should you decide to leave it running.

Warning Network scanners are used by crackers for locating likely target systems, as well as by network administrators for legitimate purposes. Many organizations have policies forbidding the use of network scanners except under specific conditions. Therefore, you should check these policies and obtain explicit permission, signed and in writing, to perform a network scan, just as you should obtain permission before performing password cracking. Failure to do so could cost you your job or even result in criminal charges, even if your intentions are honorable.

Nmap is capable of performing a basic check for open ports. Pass the -sT parameter and the name of the target system to it, as shown here:

$ nmap -sT teela.rodsbooks.com

Starting nmap V. 3.00 (www.insecure.org/nmap/)

Interesting ports on teela.rodsbooks.com (

(The 1581 ports scanned but not shown below are in state: closed)

Port State Service

21/tcp open ftp

22/tcp open ssh

Note As with the output of netstat shown in "Using Local Network Activity Tools," this output has been trimmed for brevity's sake.

This output shows two open ports—21 and 22, used by ftp and ssh, respectively. If you weren't aware that these ports were active, you should log onto the scanned system and investigate further, using netstat or ps to locate the programs using these ports and, if desired, shut them down. The -sT option specifies a scan of TCP ports. A few servers, though, run on UDP ports, so you need to scan them by typing nmap -sU hostname. (This usage requires root privileges, unlike scanning TCP ports.)

Nmap is capable of more sophisticated scans, including "stealth" scans that aren't likely to be noticed by most types of firewalls, ping scans to detect which hosts are active, and more. The Nmap man page provides details. Nessus, which is built atop Nmap, provides a GUI and a means of performing automated and still more sophisticated tests. Nessus comes as separate client and server components; the client enables you to control the server, which does the actual work.

When you use a network scanner, you should consider the fact that the ports you see from your test system may not be the same as those that might be visible to an attacker. This issue is particularly important if you're testing a system that resides behind a firewall from another system that's behind the same firewall. Your test system is likely to reveal accessible ports that would not be accessible from the outside world. On the other hand, a cracker on your local network would most likely have access similar to your own, so you shouldn't be complacent because you use a firewall. Nonetheless, firewalls can be important tools for hiding servers without shutting them down.

0 0

Post a comment