Access Control Using xinetd

The benefits offered by TCP wrappers are enhanced when the libwrap.a library is used in conjunction with xinetd, a super-daemon that provides additional access, logging, binding, redirection, and resource utilization control. Red Hat Linux configures a variety of popular network services to be used with xinetd, including FTP, IMAP, POP, and Telnet. When any of these services are accessed via their port numbers in /etc/services, the xinetd daemon handles the request. Before bringing up the requested network service, xinetd ensures that the client host information meets the access control rules, that the number of instances of this service is under a particular threshold, and that any other rules specified for that service or all xinetd services are followed. Once the target service is brought up for the connecting client, xinetd goes back to sleep, waiting for additional requests for the services it manages.

xinetd Configuration Files

The xinetd service is controlled by the /etc/xinetd.conf file, as well as the various service-specific files in the /etc/xinetd.d/ directory.

/etc/xinetd.conf

The xinetd.conf file is the parent of all xinetd-controlled service configuration files, as the service-specific files are also parsed every time xinetd starts. By default, xinetd.conf contains some basic configuration settings that apply to every service. Following is an example of a typical xinetd.conf:

Defaults {                instances                   = 60                log_type                    = SYSLOG authpriv                log_on_success              = HOST PID                log_on_failure              = HOST                cps                         = 25 30 } includedir /etc/xinetd.d

These lines control various aspects of xinetd:

• instances — Sets the maximum number of requests a particular service can handle at once.

• log_type — Tells xinetd to use the authpriv log, specified in /etc/syslog.conf and set to /var/log/secure by default, rather than use another specific file. Using FILE /var/log/xinetdlog here instead would move xinetd logging to a separate /var/log/xinetdlog file.

• log_on_success — Lets xinetd know what to log if the connection is successful. By default, the remote host’s IP address and the process ID of server processing the request are recorded.

• log_on_failure — Tells xinetd what to log if the connection fails or is not allowed.

• cps — Tells xinetd to allow no more than 25 connections per second to a given service. If this limit is reached, the service is retired for 30 seconds.

  Note

  Both the log_on_success and log_on_failure settings in /etc/xinetd.conf are often modified by each service, meaning that successful and failed connections will usually log more information than is indicated in /etc/xinetd.conf.

Various logging options are available in /etc/xinetd.conf and the service-specific xinetd configuration files:

• ATTEMPT — Logs the fact that a failed attempt was made. (log_on_failure)

• DURATION — Logs the length of time the service is used by a remote system. (log_on_success)

• EXIT — Logs the exit status or termination signal of the service. (log_on_success)

• HOST — Logs the remote host’s IP address. (log_on_failure and log_on_success)

• PID — Logs the process ID of the server receiving the request. (log_on_success)

• RECORD — Records information about the remote system in case the service cannot be started. Only particular services, such as login and finger, may use this option. (log_on_failure)

• USERID — Logs the remote user using the method defined in RFC 1413 for all multi-threaded stream services. (log_on_failure and log_on_success)

Other options for /etc/xinetd.conf are available, such as per_source, which limits the maximum number of connections from a particular IP address to a specific service. See the xinetd man page for more information.

Files in the /etc/xinetd.d/ Directory

The files in the /etc/xinetd.d/ directory are read every time xinetd starts, because of the includedir /etc/xinetd.d/ statement at the bottom of /etc/xinetd.conf. These files, with names such as finger, ipop3, and rlogin, correlate to the services controlled by xinetd. The files in /etc/xinetd.d/ use the same conventions as /etc/xinetd.conf. The primary reason they are stored in separate configuration files is to make it easier to add and remove a service from xinetd without affecting other services. To get an idea of how these files are structured, consider the wu-ftp file:

service ftp {             socket_type                 = stream             wait                        = no             user                        = root             server                      = /usr/sbin/in.ftpd             server_args                 = -l –a             log_on_success             += DURATION USERID             log_on_failure             += USERID             nice                        = 10             disable                     = yes }

The first line defines the service’s name. The lines within the braces contain settings that define how this service is supposed to be started and used. The wu-ftp file states that the FTP service uses a stream socket type (rather than dgram), the binary executable file to use, the arguments to pass to the binary, the information to log in addition to the /etc/xinetd.conf settings, the priority with which to run the service, and more.

The use of xinetd with a service also can serve as a basic level of protection from a Denial of Service (DoS) attack. The max_load option takes a floating-point value to set a CPU usage threshold when no more connections for a particular service will be accepted, preventing certain services from overwhelming the system. The cps option accepts an integer value to set a rate limit on the number of connections available per second. Configuring this value to something low, such as 3, will help prevent attackers from being able to flood your system with too many simultaneous requests for a particular service.

Access Control within xinetd

Users of xinetd services can choose to use the TCP wrappers host access control files (/etc/hosts.allow and /etc/hosts.deny), provide access control via the xinetd configuration files, or a mixture of both. Information concerning the use of TCP wrappers host access control files can be found in the “What Is TCP Wrappers?” section earlier in this chapter. This section of the chapter will discuss using xinetd to control access to services.

Note

Unlike TCP wrappers host access control files, any changes to xinetd configuration files require a restart of the xinetd service to take effect.

The xinetd host access control available through its various configuration files is different from the method used by TCP wrappers. While TCP wrappers places all of the access configuration within two files, /etc/hosts.allow and /etc/hosts.deny, each service’s file in /etc/xinetd.d can contain access control rules based on the hosts that will be allowed to use that service. The following options are supported in the xinetd files to control host access:

• only_from — Allows the hosts specified to use the service.

• no_access — Blocks these hosts from using this service.

• access_times — Specifies the time range when a particular service may be used. The time range must be stated in a HH:MM-HH:MM format using 24-hour notation.

The only_from and no_access options can use a list of IP addresses or hostnames or can specify an entire network. As with TCP wrappers, combining xinetd access control with the proper logging configuration for that service allows you not only to block the request but also to record every attempt to access it. For example, the following /etc/xinetd.d/telnet file can be used to block Telnet access to a system by a particular network group and restrict the overall time range within which even legitimate users can log in:

service telnet {               disable            = no               flags              = REUSE               socket_type        = stream               wait               = no               user               = root               server             = /usr/sbin/in.telnetd               log_on_failure     += USERID               no_access          = 10.0.1.0/24               log_on_success     += PID HOST EXIT               access_times       = 09:45-16:15 }

In this example, any system from the 10.0.1.0/24 subnet, such as 10.0.1.2, that tries to telnet into the server will receive a message stating Connection closed by foreign host. In addition, the login attempt is logged in /var/log/secure:

May 15 17:35:47 boo xinetd[16188]: START: telnet pid=16191 from=10.0.1.2 May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2 May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2 May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

Binding and Port Redirection

The service configuration files for xinetd also support binding the service to an IP address and redirecting incoming requests for that service to another IP address, hostname, or port. Binding is controlled with the bind option in the service configuration files and links the service to one IP address on the system. When used, the bind option allows only requests for the proper IP address to access the service. Each service can be bound to different network interfaces based on your needs. This is particularly useful for systems with multiple network adapters or using multiple IP addresses. For instance, you can configure Telnet to listen only on the interface connected to a private network and not to the interface connected with the Internet.

The redirect option accepts an IP address or hostname followed by a port number. It tells the service to redirect any requests for this service to the specified host and port number. This feature can be used to point to another port number on the same system, redirect the request to different IP address on the same machine, shift the request to a totally different system and port number, or any combination of these options. In this way, a user connecting to certain service on a system may be rerouted to another system with no disruption. The xinetd daemon is able to accomplish this redirection by spawning a process that stays alive for the duration of the connection between the requesting client machine and the host actually providing the service, transferring data between the two systems.

The real strength of the bind and redirect options can be seen when they are used together. By binding a service to a particular IP address on a system and then redirecting requests for this service to a second machine that only the first machine can see, you can use an internal system to provide services for a totally different network. Alternatively, these options can be used to limit the exposure of a particular service on a multi-homed machine to a known IP address, as well as redirect any requests for that service to another machine specially configured for that purpose. For example, consider a system that is used as a firewall with this setting for its telnet service:

service telnet {            socket_type            = stream            wait                   = no            server                 = /usr/sbin/in.telnetd            log_on_success        += DURATION USERID            log_on_failure        += USERID            bind                   = 123.123.123.123            redirect               = 10.0.1.13 21 23 }

The bind and redirect options in this file will ensure that the telnet service on the machine is bound to the external IP address (123.123.123.123), the one facing the Internet. In addition, any requests for telnet service sent to 123.123.123.123 will be redirected via a second network adapter to an internal IP address (10.0.1.13) that only the firewall and internal systems can access. The firewall will then send the communication between the two systems, and the connecting system will think it is connected to 123.123.123.123 when it is actually connected to a different machine.

This feature is particularly useful for users with broadband connections and only one fixed IP address. When one is using Network Address Translation (NAT), the systems behind the gateway machine, which are using internal-only IP addresses, are not available from outside the gateway system. However, when certain services controlled by xinetd are configured with the bind and redirect options, the gateway machine can act as a type of proxy between outside systems and a particular internal machine configured to provide the service. In addition, the various xinetd access control and logging options are also available for additional protection, such as limiting the number of simultaneous connections for the redirected service.