Generic xinetd Configuration

The generic configuration for xinetd services is stored in the /etc/xinetd.conf file. As RHCE candidates need to configure services only for "basic operation," this chapter analyzes only the active directives in this file. First, a number of default settings are enabled with the following command:

defaults

This allows services such as rsync to retain their default TCP/IP ports (873) within the xinetd service.

This is followed by

log_type SYSLOG daemon info

which specifies logging through the syslog daemon as described in Chapter 7, as configured in /etc/syslog.conf.

This is followed by

log_on_failure HOST

which specifies the logging information when a login through an xinetd-controlled service fails. Naturally, this specifies the host name (or IP address) of the client host. It might help to add USERID to the list, which lists the UID number associated with the failed login. This can help you identify compromised accounts.

This line,

log_on_success PID HOST DURATION EXIT

specifies the logging information associated with a successful connection. For example, once I logged off a Telnet connection from a remote system, and this led to the following entry in /var/log/messages:

Jul 25 17:54:31 Enterprise5vm xinetd[4618]: EXIT: telnet status=1
pid=4667 duration=472(sec)

The effect from /etc/xinetd.conf is straightforward. The next active line is

cps = 50 10

The cps command prevents attempts to "flood" any xinetd service; this line limits connections to 50 per second. If this limit is exceeded, xinetd waits 10 seconds before allowing a remote user to try again.

The next line,

instances = 50

limits the number of active services for a particular service; in this case, no more than 50 users can be logged into your Kerberos Telnet server simultaneously (less if other xinetd services are running).

This is followed by a related directive:

per_source = 10

This limits the number of connections from each IP address.

The next active directive is almost self-explanatory:

v6only = no

If you changed this to yes, access would be limited to systems with IPv6 addresses.

A couple of environment directives

groups = yes
umask = 002

allow execution with the xinetd group, or one defined with the group directive (singular).

Finally, the last line supports the use of the other configuration files specified in the /etc/xinetd.d directory:

includedir /etc/xinetd.d

Sample xinetd Configuration

Each file in the /etc/xinetd.d directory specifies a particular service you want to allow xinetd to manage. By default, scripts in this directory are disabled. The following code shows a sample of the /etc/xinetd.d/krb5-telnet configuration file, with this service disabled:

# 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
}

This is a typical /etc/xinetd.d configuration file. The variables (and a few additional variables that you can use) are described in Table 13-2. This is a versatile configuration file; other fields are described in the man pages for xinetd.conf. Read this man page; the only_from and no_access directives may be of particular interest -as per the Exam Prep guide, they can help you "configure host-based and user-based security for the service."

You can enable any xinetd service by changing disable = yes to disable = no.

You can activate a service in two ways. You can edit the configuration file directly by changing the disable field from no to yes. Then make the xinetd daemon reread the configuration files with the service xinetd reload command.

Alternatively, you can use the chkconfig servicename on command, which automatically makes this change and makes xinetd reread the configuration file.

Exam Watch

Always remember to make sure that a service will be active after a reboot. The chkconfig servicename on command is one way to do this for xinetd services. Otherwise, anything you configure may not work after your computer is rebooted-and you may not get credit for how you configured that service on your exam.

Exercise 13-1: Configuring xinetd

In this exercise, you will enable the Telnet service using xinetd. Attempt to establish a Telnet session using the command telnet localhost. If you're successful, Telnet is already enabled; disable it first with the chkconfig krb5-telnet off command.

1. Edit /etc/xinetd.d/krb5-telnet and change the value of disable from yes to no.

2. Tell xinetd to reread its configuration file using this command:

   # service xinetd reload
   

3. Try the telnet localhost command again. It should work.

4. Try to log in with a bad username or password.

5. Log into another terminal. What do you see when you run utmpdump/var/log/wtmp?

6. Now log in with a good username and password.

7. What do you see in /var/log/messages?

8. Log out of the Telnet session. What do you see now in /var/log/messages?

9. Use the chkconfig command to disable Telnet. (Remember that the name of the service is krb5-telnet.) Try connecting to the Telnet server again. Do you have to restart or reload xinetd?

10. What happens when you use chkconfig to disable Telnet? Does it change the /etc/xinted.d/krb5-telnet configuration file?