Access Control Using xinetd Red Hat Linux 7.2: The Official Red Hat Linux Reference Guide Prev Chapter 9. TCP Wrappers and xinetd Next Access Control Using xinetd The benefits offered by TCP wrappers are only multiplied 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 by the correct user, xinetd ensures that the client host information meets the access control rules, the number of instances of this service is under a particular threshold, and 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 xinet 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: defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
}
includedir /etc/xinetd.d These lines control various aspects of how xinetd does its job: 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. The log_on_success and log_on_failure settings in /etc/xinetd.conf are often added to by each of the different services, meaning that successful and failed connections by each service will usually log more than what is indicated here. Various logging options are available for use 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. Files in the /etc/xinetd.d Directory The various 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, relate to the various services controlled by xinetd. The files in /etc/xinetd.d use the same conventions and options as what is seen in /etc/xinetd.conf. The primary reason they are in separate configuration files, one for each service, is to make it easier to add and remove services from the domain of xinetd without affecting its 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 that is being configured. Then, the lines within the brackets contain a variety of different settings that define how this service is supposed to be started and used. The wu-ftp file states that the FTP service uses a streaming 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 particular 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 (hosts.allow and 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 the services it controls. Note Unlike TCP wrapper host access control files, any changes to xinetd configuration files require a restart of the xinetd service, as well as a restart of any service affected by the change, 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 you 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 boo host, 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 booxinetd[16252]: EXIT: telnet status=0 pid=16256 Binding and Port Redirection The service configuration files for xinetd also support binding the service to a particular IP address and redirecting incoming requests for that service to another IP address, hostname, or port. Binding, controlled with the bind option in the service configuration files, specifically links the service to a particular IP address in use with the system, only allowing requests that use that IP address to access the service. This is particularly useful for systems with multiple network adapters and using multiple IP addresses, such as machines being used as firewalls, with one network adapter facing the Internet and the other connected to an internal network. Attackers attempting to connect for a specific service, such as Telnet or FTP, via the Internet connection may be blocked from connecting to the service while internal users may connect to the service via the NIC connected to the internal network. The redirect option, which accepts an IP address or hostname followed by a port number, tells the service to redirect any requests for this service to the specified location. 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 multihomed 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 FTP service: 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
bind = 123.123.123.123
redirect = 10.0.1.13 21
} The bind and redirect options in this file will ensure that the FTP 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 FTP 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 while 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. Prev Home Next Host-Based Access Control Lists Up Additional Resources
