InformIT: Red Hat Linux 7 Unleashed

Network Daemons

A daemon is a program that waits for another program to ask it to do something. Network daemons in particular are similar to the jacks in an operator's switchboard. They create one or more sockets and listen to those sockets, waiting for another process to connect. In Linux, as with most variants of UNIX, network services can be provided in one of two ways: as standalone daemons where they handle each session themselves or incorporated into another configuration (such as inetd) that handles the connections and disconnections for it.

Standalone TCP/IP Daemons

Originally, all UNIX network servers were standalone daemons. When you wanted to start a server, you ran a program that created the socket and listened to it. Many UNIX server programs still run in this manner. Examples are Squid, the Web cache/proxy server; Samba, the SMB file/print server; Apache, the Web server, and many others (see Chapter 12, "Apache Server," and Chapter 17, "Samba").

Even though they have many functions, most network daemons usually share a few characteristics:

Their names end with a d (for daemon).
They respond to the HUP signal (HANG UP signal; read man 7 signal for more information) by rereading their configuration files. The HUP signal is sent by the kill -HUP command.
They are usually started at boot time by scripts in the /etc/init.d directory. These scripts minimally accept the start and stop parameters to start and end the daemons. Most of them accept the restart parameter to tell the daemon to reread its configuration files.
When they receive a request, they create another copy of themselves to service it. Thus, there may be several copies of each daemon running simultaneously at any given time.

Networking Service Control

In the standalone daemon model, each service you run on a server has a corresponding daemon. This poses several problems:

If you have many services on a server, you need to have many daemons running, even if they are idle. Although inactive daemons will probably be swapped out to disk, they still take up valuable resources, such as virtual memory and process table entries.
There is no centralized way of modifying the daemons to provide services such as encryption or access control. Each daemon program must be modified to provide these services.
If a daemon dies because of user or programmer error, the service will not be available until it is restarted. The restart procedure can be automated, but then the program that restarts the daemon can also die.
Programming a network daemon isn't easy, especially because most daemons must be multithreaded. Being multithreaded enables them to manage several requests at once.

Eventually someone came up with a solution. How about a single daemon that could be configured to listen to any number of sockets and transfer control to different programs when it was needed? This daemon would also take care of multithreading and of managing the sockets. Thus was born inetd, the original so-called "Internet super-server." This is the time we should mention a relatively new addition to Red Hat Linux: xinetd. This program is meant to be a secure replacement for inetd. Though not completely secure, it is much more secure than inetd.

Configuring xinetd

xinetd has built-in access control features for stopping connections from undesired clients or only allowing desired connections. It can limit the number of incoming connections, number of incoming connections from specific hosts, or total number of connections for a service. This feature is particularly useful for assistance in thwarting what is known as DdoS (Distributed Denial of Service) attacks. It can limit access to services based on access time of day. xinetd can have services bind to specific IPs. This lets you provide different services to internal clients than external clients. xinetd is installed at installation time with Red Hat Linux if you select the Everything option for your installation.

When xinetd is installed, a Perl script is supplied in the same directory as the xinetd binary that conveniently converts an inetd.conf into an xinetd.conf. It may be run when you are logged in as root by typing the string /usr/sbin/xconv.pl < /etc/inetd.conf > /tmp/xinetd.conf, where /usr/sbin is your path to the xinetd executable. The xinetd.conf looks much like a legacy inetd.conf file and may be edited much the same as well. As with most subjects with regard to Red Hat Linux, an entire chapter could be written on xinetd. You may read more in depth about xinetd at http://www.synack.org/xinetd/. Here are some of the keywords most commonly used when configuring this new "Super Server":

`wait`	This attribute determines if the service is single-threaded or multi-threaded. If its value is yes the service is single-threaded; this means that `xinetd` will start the server and then it will stop handling requests for the service until the server dies. If the attribute value is no, the service is multithreaded and `xinetd` will keep handling new service requests.
`user`	Determines the `uid` for the server process. The user name must exist in `/etc/passwd`. This attribute is ineffective if the effective user ID of `xinetd` is not superuser.
`group`	Determines the `gid` for the server process. The group name must exist in `/etc/group`. If a group is not specified, the group of `user` will be used (from `/etc/passwd)`. This attribute is ineffective if the effective user ID of `xinetd` is not superuser.
`EXIT`	Logs the fact that a server exited along with the exit status or the termination signal (the process id is also logged if the `PID` option is used).
`DURATION`	Logs the duration of a service session.

You can (as root) control what services are started or not run during bootup by using the ntsysv command. However, you should know that you'll shut off all networking services unless you run xinetd. A much better approach is to edit its configuaration files, found under the /etc directory, and the /etc/xinetd.d directory. For example, here is the default telnet control file under xinetd's /etc/xinetd.d directory:

# default: on
# description: The telnet server serves telnet sessions; it uses #       unencrypted username/password pairs for authentication.
service telnet
{
        disable = no
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
}

As you can see, the default state for telnet access is enabled with Red Hat Linux. Your job as a system administrator will be to decide what services to provide on your system.

TCP/IP Troubleshooting Tools | Next Section

Previous Section