Linux Patch Management: Keeping Linux Systems Up To Date

Linux typically supports network communication between clients and servers. For example, you can use Telnet to connect to a remote system. The Telnet client on your computer makes a connection with a Telnet server daemon on the remote system. This section assumes that you've installed the default RHEL krb5-workstation RPM package, which includes a more secure version of Telnet.

While the focus in this section is on the Kerberos-secured Telnet, other xinetd packages of note include rsync, which is popular for backups; cvs, popular for software development version control; and gssftp, which is a Kerberos-secured FTP service. As no xinetd service is explicitly cited in the RHCE Exam Prep guide, I keep the coverage of xinetd services to a minimum.

More Network Services

Both Red Hat exams require that you configure a Linux workstation as a client on a network. However, the secure shell is not included in the current version of the RHCT portion of the Exam Prep guide. And client configuration with a DHCP server was covered in Chapter 7. So this chapter focuses on the needs of RHCE candidates.

The Red Hat Exam Prep guide suggests that you can expect to configure SSH services during the exam. It also suggests that you need to know how to configure host- and user-based security for each service. While much of that is discussed in Chapter 15, some security configuration options are available for SSH.

While neither DHCP servers nor xinetd services are listed in the Red Hat Exam Prep guide, they are listed in the RH300 course outline, the prep course for the RHCE. And remember that changes can be made to the Red Hat Exam Prep guide at any time.

As of this writing, Red Hat has just added the Network Time Protocol (NTP) to the list of services required for the RHCE. As with other network services, per the RHCE section of the Red Hat Exam Prep guide, RHCEs must be able to do the following:

• Install the packages needed to provide the service.

• Configure SELinux to support the service.

• Configure the service to start when the system is booted.

• Configure the service for basic operation.

• Configure host-based and user-based security for the service.

It also suggests that you need to know how to "diagnose and correct problems with (these) network services" as well as SELinux-related network issues during the Troubleshooting and System Maintenance portion of this exam. As of this writing, the only available SELinux option related to NTP and DHCP is to disable protection for this service. Some additional protections may be available for individual xinetd services such as rsync and cvs; however, as of this writing, no individual xinetd service is listed in either the Red Hat Exam Prep guide or curriculum for RH133 and RH300.

To establish the connection on a TCP/IP network, a client application needs the IP address of the server and the port number associated with the server daemon. All common TCP/IP applications have a standard port number; some examples are shown in Table 13-1.

If you don't specify the port number, TCP/IP assumes that you're using the default port for the specified service. Clients can't connect unless the corresponding server is running on the remote system. If you are managing a server, you may have a number of server daemons to start when Linux is booted.

The xinetd (which stands for the Extended Internet Services Daemon) service can start a number of these server daemons simultaneously. The xinetd service listens for connection requests for all of the active servers with scripts in the /etc/xinetd.d directory. There's a generic configuration file for xinetd services, /etc/xinetd.conf. The scripts in the /etc/xinetd.d directory function as service-specific configuration files.

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.

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?