Access Control Using xinetd

/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. Below 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 using 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 the 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 man page for xinetd for more information.

Files in the /etc/xinetd.d/ Directory

The files in the /etc/xinetd.d/ directory are read every time xinetd starts, due to 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 brackets 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 wrapper 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 wrapper host access control files can be found in the Section called Host-Based Access Control Lists. This section will discuss using xinetd to control access to services.

	Note
	Unlike TCP wrapper host access control files, any changes to xinetd configuration files require a restart of the xinetd service to go into affect.

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 host names, or can specify an entire network. Like TCP wrappers, combining xinetd access control with the proper logging configuration for that service, you can not only block the request but also 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 that 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, when any system from the 10.0.1.0/24 subnet, such as 10.0.1.2, tries to telnet into the server, they will receive a message stating Connection closed by foreign host. In addition, their 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 only allows 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 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.