Certification Objective 10.05: The Extended Internet Services Daemon (xinetd)

---

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 have the default RHEL 3 krb5-workstation RPM package, which includes a more secure version of Telnet.

On The Job 

If you're working with Red Hat Linux 9, you can also work with the telnet-server RPM. Some of the commands with this older Telnet server are different from what you see here.

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 10-6.

Table 10-6: Typical TCP/IP Port Numbers

Port Number	Service
>21	FTP
>23	Telnet
>25	SMTP (outgoing mail)
>80	HTTP
>443	HTTPS (secure HTTP)
>631	Internet Printing Protocol (CUPS configuration)

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 Extended Internet Services Daemon) program can start a number of these server daemons simultaneously. The xinetd program 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 also function as service specific configuration files.

Generic xinetd Configuration

The generic configuration for xinetd services is stored in the /etc/xinetd.conf file. It's short and fairly straightforward, so we can analyze it line by line. First, there are a number of default settings that are started with the following command:

defaults

This allows services such as POP3 to retain their default TCP/IP ports (110). This is followed by:

instances = 60

which limits the number of active services for a particular service; in this case, no more than 60 users can be logged into your Kerberos Telnet server simultaneously. The following line means that log messages are sent as specified in /etc/syslog.conf.

log_type = SYSLOG authpriv 

The following line means that for each successful logon to a xinetd service, the name (or IP address) of the remote computer and the process ID (PID) are sent to the appropriate log file.

log_on_success = HOST PID

The next line means that whenever there is a failed attempt to log on to an xinetd service, the name (or IP address) of the remote computer and reason is sent to the appropriate log file.

log_on_failure = HOST

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

cps = 25 30

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: on # description: The telnet server serves telnet sessions; it uses \ #       unencrypted username/password pairs for 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 10-7. 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 fields may be of particular interest.

Table 10-7: Standard Parameters for xinetd Configuration Files

Field	Description of Field Entry
flags	Supports different parameters for the service; REUSE is a default which supports continuous use of the service. Options include IPv6 to set this as a service for those types of networks.
socket_type	Specifies the communication stream.
wait	Set to yes for single-threaded applications, or no for multithreaded applications.
user	Account under which the server should run.
group	Group under which the server should run.
server	The server program.
only_from	Hostname or IP address allowed to use the server. CIDR notation (such as 192.168.0.0/24) is okay.
no_access	Hostname or IP address not allowed to use the server. CIDR notation is okay.
log_on_failure	If there's a failed login attempt, this specifies the information sent to a log file.
disable	Yes by default, which disables the service.

You have two ways to activate a service. 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 

CIDR notation is based upon Classless Inter-Domain Routing. Under CIDR, you do not need to specify the full IPv4 subnet address; 192.168.0.0/255.255.255.0 is the same as 192.168.0.0/24. As of this writing, the Red Hat exams do not require any detailed understanding of IPv6 addresses.

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 10-4: 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/telnet and change the value of disable from yes to no.

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

   # service xinetd reload

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

4. Use the chkconfig command to disable Telnet. Try connecting to the Telnet server again. Do you have to restart or reload xinetd?

5. What happens when you use chkconfig to enable Telnet? Does it change the /etc/xinted.d/telnet configuration file?

Security by User or Host

The best way to prevent a cracker from using a service is to remove it completely from your Linux system. However, you may want to keep a service loaded because you're planning to use it in the near future.

You can achieve some measure of security by disabling or removing unused services in the /etc/xinetd.d directory. But you need to take other measures to protect yourself against attacks through enabled services. With xinetd, you have two approaches. You can set up fields in individual /etc/xinetd.d configuration files to block computers by hostname or IP address. Alternatively, you can block access to specific users, computers, or even networks through the hosts.allow or hosts.deny files in the /etc directory. This system is known as tcp_wrappers, which is enabled by default.

When xinetd receives a network request for a service, it passes the request on to tcp_wrappers. This system logs the request and then checks its access rules. If there are no limits on the particular host or IP address, tcp_wrappers passes control back to xinetd to start the needed service.

The key files are hosts.allow and hosts.deny. The philosophy is fairly straightforward; clients listed in hosts.allow are allowed access; clients listed in hosts.deny are denied access. When xinetd receives a request, the tcp_wrappers system takes the following steps:

1. It searches /etc/hosts.allow. If tcp_wrappers finds a match, it grants access.

2. It searches /etc/hosts.deny. If tcp_wrappers finds a match, it denies access.

3. If the host isn't found in either file, access is automatically granted to the client.

You use the same access control language in both /etc/hosts.allow and /etc/hosts.deny to tell tcp_wrappers which clients to allow or deny. The basic format for commands in each file is as follows:

daemon_list : client_list

The simplest version of this format is:

ALL : ALL

This specifies all services managed by xinetd and makes the rule applicable to all hosts on all IP addresses. If you set this line in /etc/hosts.deny, all access is prohibited to all services. However, you can create finer filters. For example, the following line:

telnetd : 192.168.1.5

in /etc/hosts.allow allows the client with an IP address of 192.168.1.5 to connect to your system through Telnet. The same line in /etc/hosts.deny would prevent the computer with that IP address from using Telnet to connect to your system. You can specify clients a number of different ways, as shown in Table 10-8.

Table 10-8: Sample Commands in /etc/hosts.allow and /etc/hosts.deny

Client	Description
.example.com	Domain name. Since this domain name begins with a dot, it specifies all clients on the example.com domain.
172.16.	IP address. Since this address ends with a dot, it specifies all clients with an IP address of 172.16.x.y.
172.16.72.0/255.255.254.0	IP network address with subnet mask. CIDR notation not recognized.
ALL	Any client, any daemon.
[e-mail]	Applies to the specific user on the given computer.

As you can see in Table 10-8, there are two different types of wildcards. ALL can be used to represent any client or service. The dot (.) specifies all hosts with the specified domain name or IP network address.

You can set up multiple services and addresses with commas. Exceptions are easy to make with the EXCEPT operator. See the following excerpt from a /etc/hosts.allow file for an example:

#hosts.allow ALL :.example.com telnetd : 192.168.25.0/255.255.255.0 EXCEPT 192.168.25.73 in.pop3d, in.tftpd : 192.168.1.10

The first line in this file is simply a comment. The next line opens ALL xinetd services to all computers in the example.com domain. The following line opens the Telnet service to any computer on the 192.168.25.0 network, except the one with an IP address of 192.168.25.73. Then, the POP3 and TFTP services are opened to the computer with an IP address of 192.168.1.10.

The code that follows contains a hosts.deny file to see how lists can be built to control access.

#hosts.deny ALL EXCEPT in.tftpd : .xyz.com telnetd : ALL EXCEPT 192.168.1.10 ALL:ALL

The first line in the hosts.deny file is a comment. The second line denies all services except TFTP to computers in the .xyz.com domain. The third line states that the only computer that is allowed to access our Telnet server has an IP address of 192.168.1.10. Finally, the last line is a blanket denial; all other computers are denied access to all services controlled by tcp_wrappers.

You can also use the twist or spawn command in /etc/hosts.allow or /etc/hosts.deny to access shell commands; primarily they're intended to send messages, track access, and log problems. For example, take the following line in a /etc/hosts.deny file:

telnetd : .crack.org : twist /bin/echo Sorry %c, access denied

This sends a customized error message for Telnet users on the crack.org domain. Different operators such as %c are described in Table 10-9. Some of these operators may be able to help you track the intruder.

Table 10-9: tcp_wrappers Operators

Field	Description	Field	Description
%a	Client address	%h	Client hostname
%A	Host address	%H	Server hostname
%c	Client information	%p	Process ID
%d	Process name	%s	Server information

Exercise 10-5: Configuring tcp_wrappers

In this exercise, you will use tcp_wrappers to control access to network resources. Since tcp_wrappers is enabled by default, you shouldn't have to make any modifications to /etc/xinetd.conf.

1. Verify that you can telnet to the system using the address localhost.

2. Edit /etc/hosts.deny and add the following line (don't forget to write the file):

   ALL : ALL

3. What happens when you try to telnet to the address localhost?

4. Edit /etc/hosts.allow and add the following line:

   telnetd : 127.0.0.1

5. Now what happens when you try to telnet to the address localhost?

6. If you have other systems available to you, try restricting access to the Telnet service using some of the other tcp_wrappers rules.

7. Undo your changes when finished.

---