Running the xinetd Superserver

The client/server model requires that the server be up and running before a client makes a request for service. A simplistic idea would be to run all the servers and have them listen to their respective ports all the time. However, this idea is not practical because each server process would use up system resources in the form of memory and processor time. Besides, you don't really need all the services up and ready at all times. A smart solution to this problem is to run a single server, xinetd, which listens to all the ports and then starts the appropriate server when a client request comes in.

insider The xinetd server is a replacement for an older server named inetd but with improved insight access control and logging. The name xinetd stands for extended inetd. You can learn more about xinetd by visiting

Learning How xinetd Works

The xinetd server is designed to monitor the ports for the services it is configured to start. When a client requests connection to one of the monitored ports, xinetd starts the corresponding server. The client then directly communicates with that server while xinetd goes on to listening to the ports again. For example, when a client tries to connect to the Telnet port, xinetd starts the Telnet server and lets it communicate directly with the client (and the Telnet server exits when the client disconnects). xinetd also logs the connection requests in a log file based on settings in its configuration file.


The xinetd server is known as the Internet superserver because it starts various servers on demand. Typically, a Linux system starts xinetd when the system boots. The xinetd server reads a configuration file named /etc/xinetd.conf at startup. This file tells xinetd which ports to listen to and what server to start for each port. The file can contain instructions that include other configuration files. In Fedora Linux, the

/etc/xinetd.conf file looks like the following:

# Simple configuration file for xinetd

# Some defaults, and include /etc/xinetd.d/

defaults {

instances log_type log_on_success log_on_failure cps

includedir /etc/xinetd.d

Comment lines begin with the pound sign (#). The defaults block, enclosed in curly braces ({...}), specifies default values for some attributes. These default values apply to all other services that xinetd is set up to start. The instances attribute is set to 60, which means there can be, at most, 60 servers simultaneously active for any service. The other attributes have the following meanings:

• The log_type attribute specifies how xinetd should log error or status information. In this case the log_type is SYSLOG authpriv, which means that xinetd will use the SYSLOG facility's authpriv log. The / etc/syslog.conf file defines the authpriv log as the file /var/log/secure. This means that the /var/log/secure file contains the logs for services started by xinetd.

• The log_on_success attribute tells xinetd what information to log when a server is started and when the server exits. In this case, the attribute is set to HOST and PID. The result is that if the startup of a service such as Telnet is successful, then xinetd logs the name of the remote host that has requested the service and the process ID of the Telnet server (that it starts). This setting for the log_on_success attribute results in entries in the /var/log/secure file of the following form:

Apr 3 16:44:23 localhost xinetd[2483]: START: telnet pid=3466 from=

• The log_on_failure attribute tells xinetd what information to log when it cannot start a server. In this case, the attribute is set to HOST, which means that if xinetd cannot start a service such as Telnet, it logs the name of the remote host that requested the service.


• The cps = 25 30 line tells xinetd to allow no more than 25 connections per second to a given service. If this limit is reached, the service is turned off for 30 seconds. Placing a limit such as this protects your system against denial of service attacks that attempts to overwhelm the system by requesting too many connections.

The last line in the /etc/xinetd.conf file uses the includedir directive to include all files inside the /etc/xinetd.d directory, excluding files whose names begin with a period (.). The idea is that the /etc/xinetd.d directory would contain all service configuration files —one file for each type of service the xinetd server is expected to manage. You should study the files in /etc/xinetd.d directory to see what services xinetd can start and how each service is configured. You can enable or disable a service by editing that service's configuration file in /etc/xinetd.d (you can also perform this task through the chkconfig command, as described in Chapter 22).

Here is the listing of files in the /etc/xinetd.d directory on a typical Fedora Linux system: ls /etc/xinetd.d chargen daytime echo-udp klogin ktalk time-udp chargen-udp daytime-udp eklogin krb5-telnet rsync cvs echo gssftp kshell time

Each file specifies the attributes for one service. As this listing shows, there are more than two dozen services that xinetd can start. Whether all the services are enabled or not, depends on the settings in each configuration file.

Understanding the xinetd Configuration Files

For example, the following listing shows the contents of the /etc/xinetd.d/krb5-tel-net file, which specifies the xinetd configuration for the telnet service (this version of Telnet uses Kerberos to authenticate users):

# default: off

# description: The kerberized telnet server accepts normal telnet

# sessions, but can also use Kerberos 5

# authentication. service telnet

flags = REUSE

socket_type = stream wait = no user = root server = /usr/kerberos/sbin/telnetd log_on_failure += USERID

disable = yes

The filename (in this case, krb5-telnet) can be anything; what matters is the service name that appears next to the service keyword in the file. In this case, the line service telnet tells xinetd the name of the service. xinetd uses this name to look up the port number from the /etc/services file. If you use the grep command to look for telnet in the /etc/services file, here's what you'll find:

grep telnet /etc/services telnet 23/tcp telnet 23/udp rtelnet 107/tcp # Remote Telnet rtelnet 107/udp telnets 992/tcp telnets 992/udp

As the first two lines that begin with telnet show, the port number of the Telnet service is 23. This tells xinetd to listen to port 23 for Telnet service requests.

The attributes in the /etc/xinetd.d/krb5-telnet file, enclosed in curly braces, have the following meanings:

♦ The flags attribute provides specific instructions about how to run the servers that xinetd starts. The REUSE flag means that the service is left running even if xinetd is restarted. Note that the REUSE flag is now implicitly assumed to be set for all services.

♦ The socket_type attribute is set to stream, which tells xinetd that the Telnet service uses a connection-oriented TCP socket to communicate with the client. For services that use the connectionless UDP sockets, this attribute would be set to dgram.

♦ The wait attribute is set to no, which tells xinetd to start a new server for each request. If this attribute is set to yes, xinetd waits until the server exits before starting the server again.

♦ The user attribute provides the user ID that xinetd uses to run the server. In this case, the server runs the Telnet server as root.

♦ The server attribute specifies the program to run for this service. In this case, xinetd runs the / usr/kerberos/sbin/telnetd program to respond to requests for Telnet service.

♦ The log_on_failure attribute tells xinetd what information to log when it cannot start a server. In this case, the attribute appends the USERID flag to the default setting of HOST (set through the defaults block in the /etc/xinetd.conf file). The result is that if the Telnet service fails, xinetd logs the name of the remote host that requested the service as well as the user ID of the remote user.

♦ The disable attribute turns off the service if it's set to yes. By default the disable attribute is set to yes and Telnet is turned off.

The xinetd server uses the facilities of the libwrap library (called the TCP wrapper), which provides an access-control facility for Internet services. The TCP wrapper can start other services such as FTP and Telnet, but before starting the service, the wrapper consults the /etc/hosts.allow file to see if the host requesting service is allowed that service. If there is nothing in /etc/hosts.allow about that host, the TCP wrapper checks the /etc/hosts.deny file to see if the service should be denied. If both files are empty, the TCP wrapper allows the host access to the requested service. You can place the line ALL:ALL in the /etc/hosts.deny file to deny all hosts access to any Internet services, and then enable specfic hosts to access the services by listing them in the /etc/hosts.allow file (see the "/etc/hosts.allow" and "/etc/hosts.deny" sections to learn more about these access control files).


In addition to the access control provided by the TCP wrapper files— /etc/hosts .allow and /etc/hosts.deny—you can also control access to each service by using the following attributes in xinetd configuration files:

• The only_from attribute specifies a list of IP addresses that are the only ones allowed to connect to the server. To deny all connections, use the following line:

only_from =

On the other hand, to allow access to all hosts in the class C network, add the following line:

• The no_access attribute specifies the IP addresses of remote hosts that are not allowed to connect to xinetd services. For example, to deny access to the host with IP address, write:

no_access =

Browse through the files in the /etc/xinetd.d directory on your Fedora Linux system to find out the kinds of services that xinetd is set up to start. By default nearly all of these services are turned off by setting the disable attribute to yes. You should leave them disabled, unless you need a service such as Telnet for your internal network.

If you need to connect to your Fedora Linux system by using telnet and you get an error message, check the appropriate Telnet file in the /etc/xinetd.d directory and make sure the disable attribute it set to no or the disable line is commented out by placing a # at the beginning of the line. You can also turn the service on or off by using the chkconfig command. For example, to turn Telnet service on, type:

chkconfig krb5-telnet on

After you make any change to the xinetd configuration files or turn a service on or off, you must restart the xinetd server by typing the following command:

service xinetd restart

Note that for a Telnet server that uses Kerberos 5 to authenticate users, you also must set up Kerberos properly. Kerberos is configured through the options stored in the /etc/krb5.conf file. To learn more about Kerberos configuration, type man krb5.conf and read the Kerberos Infrastructure HOWTO located at HOWTO/Kerberos-Infrastructure-HOWTO/.

Was this article helpful?

0 0
Make Money Writing

Make Money Writing

This Report Will Show You How To Make Money By Providing Writing Services To Other Internet Marketers. Learn how to make money by writing the right way. Grab your copy of this report now and learn. Why writing is a great way to earn money. How to compete with cheap writers, even if you charge a lot more money.

Get My Free Ebook

Post a comment