Do you know what network services are enabled on your systems? Many administrators simply don't know. They've never bothered to question it—they never thought it was a problem. Hopefully by now you realize that not every program your system runs is necessarily healthy for it (or you) from a security point of view.

By turning off the services you don't need, you simply eliminate the risk inherent in running them.

Caution

Turning off the wrong network service might prevent users from doing work that they should legitimately be able to do. On a home system, that might cause you a minor inconvenience. On a production system, this can land you in hot water—and, in some cases, cost thousands of dollars. Learn before you burn! Follow sound change-management procedures to establish whether your user community requires a service. Overzealous hardening of systems can backfire in the long run, as managers will be hesitant to support your efforts. This is in nobody's interests.

Before turning off unused services, you need to audit what is enabled. Specifically, you need to figure out what services are currently active or will become active if requested by a client.

Network daemons are either standalone or started by a master (or super) daemon when the system enters multiuser mode. By examining each start-up script, you can identify each daemon that is started and the command-line options it is invoked with.

Possibly the most famous master daemon is inetd. Inetd reads a configuration file (often /etc/inetd.conf) to find out which services to listen for. Upon receiving a packet, inetd forks (creates a copy of itself) and executes (exec) the program specified in inetd.conf, handing over the new client connection in the process. Inetd continues listening in the background.

Make yourself familiar with the inetd configuration file. Use the man pages to learn about services you don't recognize.

The start-up (and shutdown) scripts are normally located in the /etc/rc* directories (rc means run command). Each rc directory represents a different system run-level. The start-up scripts are easy to identify—they start with a capital "S" (the shutdown scripts start with a "K" for "kill") and are executed in numerical order (for example, S01, S02, S03, and so on). In fact, they are executed in the order generated by the filename shell wildcard character (just like ls *). The convention to use two-digit numbers avoids S3 executing after S24, for example.

We're interested in run-level 3—multiuser mode.

Read the start-up scripts on your system and make a list of services that are started. If you're not sure which program name represents a network daemon and which doesn't, here are some things to check for.

Check the man pages. If you are looking for a program called "nuked" and typing man nuked doesn't get you anywhere, try searching the man pages using the man -k nuked command. Man pages that describe the program as serving network clients or listening for connections are clearly good indicators of a network server.

Run the ps command (ps aux or ps -ef). If the program is listed, run lsof -I and grep for the program name. If it appears, you can be sure it's a network daemon. The -I switch to lsof says, "list processes using a TCP/IP socket."

Check whether the name of the program (minus the d if there is one) is listed in /etc/services. grep is your friend here.

Last of all, if the program name ends in "d" (daemon)—it's probably a daemon. Okay, now we're starting to clutch at straws.

The man page for the program talks about RFC compliance. An RFC (Request for Comments) defines how a protocol works and what must be implemented for an implementor of the protocol to call a program RFC compliant. To gain a deep understanding of TCP/IP and application protocols (for example, FTP or HTTP), you'll find RFCs an invaluable source of information. You can find a hyperlinked archive of RFCs at http://www.landfield.com/rfcs/.