48.5. TCP Wrappers and xinetd

Controlling access to network services is one of the most important security tasks facing a server administrator. Red Hat Enterprise Linux provides several tools for this purpose. For example, an iptables-based firewall filters out unwelcome network packets within the kernel's network stack. For network services that utilize it, TCP Wrappers add an additional layer of protection by defining which hosts are or are not allowed to connect to "wrapped" network services. One such wrapped network service is the xinetd super server. This service is called a super server because it controls connections to a subset of network services and further refines access control.
Figure 48.9, “Access Control to Network Services” is a basic illustration of how these tools work together to protect network services.
Access Control to Network Services

Figure 48.9. Access Control to Network Services

This chapter focuses on the role of TCP Wrappers and xinetd in controlling access to network services and reviews how these tools can be used to enhance both logging and utilization management. Refer to Section 48.9, “IPTables” for information about using firewalls with iptables.

48.5.1. TCP Wrappers

The TCP Wrappers package (tcp_wrappers) is installed by default and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP-wrapped service is one that has been compiled against the libwrap.a library.
When a connection attempt is made to a TCP-wrapped service, the service first references the host's access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages.
If a client is allowed to connect, TCP Wrappers release control of the connection to the requested service and take no further part in the communication between the client and the server.
In addition to access control and logging, TCP Wrappers can execute commands to interact with the client before denying or releasing control of the connection to the requested network service.
Because TCP Wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Red Hat Enterprise Linux are linked to the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.

Note

To determine if a network service binary is linked to libwrap.a, type the following command as the root user: 
ldd <binary-name> | grep libwrap
Replace <binary-name> with the name of the network service binary.
If the command returns straight to the prompt with no output, then the network service is not linked to libwrap.a.
The following example indicates that /usr/sbin/sshd is linked to libwrap.a: 
~]# ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00655000)
~]#

48.5.1.1. Advantages of TCP Wrappers

TCP Wrappers provide the following advantages over other network service control techniques:
  • Transparency to both the client and the wrapped network service — Both the connecting client and the wrapped network service are unaware that TCP Wrappers are in use. Legitimate users are logged and connected to the requested service while connections from banned clients fail.
  • Centralized management of multiple protocols — TCP Wrappers operate separately from the network services they protect, allowing many server applications to share a common set of access control configuration files, making for simpler management.

48.5.2. TCP Wrappers Configuration Files

To determine if a client is allowed to connect to a service, TCP Wrappers reference the following two files, which are commonly referred to as hosts access files:
  • /etc/hosts.allow
  • /etc/hosts.deny
When a TCP-wrapped service receives a client request, it performs the following steps:
  1. It references /etc/hosts.allow. — The TCP-wrapped service sequentially parses the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule, it allows the connection. If not, it moves on to the next step.
  2. It references /etc/hosts.deny. — The TCP-wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule, it denies the connection. If not, it grants access to the service.
The following are important points to consider when using TCP Wrappers to protect network services:
  • Because access rules in hosts.allow are applied first, they take precedence over rules specified in hosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying access to that same service in hosts.deny is ignored.
  • The rules in each file are read from the top down and the first matching rule for a given service is the only one applied. The order of the rules is extremely important.
  • If no rules for the service are found in either file, or if neither file exists, access to the service is granted.
  • TCP-wrapped services do not cache the rules from the hosts access files, so any changes to hosts.allow or hosts.deny take effect immediately, without restarting network services.

Warning

If the last line of a hosts access file is not a newline character (created by pressing the Enter key), the last rule in the file fails and an error is logged to either /var/log/messages or /var/log/secure. This is also the case for a rule that spans multiple lines without using the backslash character. The following example illustrates the relevant portion of a log message for a rule failure due to either of these circumstances: 
warning: /etc/hosts.allow, line 20: missing newline or line too long

48.5.2.1. Formatting Access Rules

The format for both /etc/hosts.allow and /etc/hosts.deny is identical. Each rule must be on its own line. Blank lines or lines that start with a hash (#) are ignored.
Each rule uses the following basic format to control access to network services: 
<daemon list>: <client list> [: <option>: <option>: ...]
  • <daemon list> — A comma-separated list of process names (not service names) or the ALL wildcard. The daemon list also accepts operators (refer to Section 48.5.2.1.4, “Operators”) to allow greater flexibility.
  • <client list> — A comma-separated list of hostnames, host IP addresses, special patterns, or wildcards which identify the hosts affected by the rule. The client list also accepts operators listed in Section 48.5.2.1.4, “Operators” to allow greater flexibility.
  • <option> — An optional action or colon-separated list of actions performed when the rule is triggered. Option fields support expansions, launch shell commands, allow or deny access, and alter logging behavior.

Note

More information on the specialist terms above can be found elsewhere in this Guide:
The following is a basic sample hosts access rule: 
vsftpd : .example.com
This rule instructs TCP Wrappers to watch for connections to the FTP daemon (vsftpd) from any host in the example.com domain. If this rule appears in hosts.allow, the connection is accepted. If this rule appears in hosts.deny, the connection is rejected.
The next sample hosts access rule is more complex and uses two option fields: 
sshd : .example.com  \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Note that each option field is preceded by the backslash (\). Use of the backslash prevents failure of the rule due to length.
This sample rule states that if a connection to the SSH daemon (sshd) is attempted from a host in the example.com domain, execute the echo command to append the attempt to a special log file, and deny the connection. Because the optional deny directive is used, this line denies access even if it appears in the hosts.allow file. Refer to Section 48.5.2.2, “Option Fields” for a more detailed look at available options.
48.5.2.1.1. Wildcards
Wildcards allow TCP Wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.
The following wildcards are available:
  • ALL — Matches everything. It can be used for both the daemon list and the client list.
  • LOCAL — Matches any host that does not contain a period (.), such as localhost.
  • KNOWN — Matches any host where the hostname and host address are known or where the user is known.
  • UNKNOWN — Matches any host where the hostname or host address are unknown or where the user is unknown.
  • PARANOID — Matches any host where the hostname does not match the host address.

Warning

The KNOWN, UNKNOWN, and PARANOID wildcards should be used with care, because they rely on functioning DNS server for correct operation. Any disruption to name resolution may prevent legitimate users from gaining access to a service.
48.5.2.1.2. Patterns
Patterns can be used in the client field of access rules to more precisely specify groups of client hosts.
The following is a list of common patterns for entries in the client field:
  • Hostname beginning with a period (.) — Placing a period at the beginning of a hostname matches all hosts sharing the listed components of the name. The following example applies to any host within the example.com domain: 
    ALL : .example.com
  • IP address ending with a period (.) — Placing a period at the end of an IP address matches all hosts sharing the initial numeric groups of an IP address. The following example applies to any host within the 192.168.x.x network: 
    ALL : 192.168.
  • IP address/netmask pair — Netmask expressions can also be used as a pattern to control access to a particular group of IP addresses. The following example applies to any host with an address range of 192.168.0.0 through 192.168.1.255: 
    ALL : 192.168.0.0/255.255.254.0

    Important

    When working in the IPv4 address space, the address/prefix length (prefixlen) pair declarations (CIDR notation) are not supported. Only IPv6 rules can use this format.
  • [IPv6 address]/prefixlen pair — [net]/prefixlen pairs can also be used as a pattern to control access to a particular group of IPv6 addresses. The following example would apply to any host with an address range of 3ffe:505:2:1:: through 3ffe:505:2:1:ffff:ffff:ffff:ffff: 
    ALL : [3ffe:505:2:1::]/64
  • The asterisk (*) — Asterisks can be used to match entire groups of hostnames or IP addresses, as long as they are not mixed in a client list containing other types of patterns. The following example would apply to any host within the example.com domain: 
    ALL : *.example.com
  • The slash (/) — If a client list begins with a slash, it is treated as a file name. This is useful if rules specifying large numbers of hosts are necessary. The following example refers TCP Wrappers to the /etc/telnet.hosts file for all Telnet connections: 
    in.telnetd : /etc/telnet.hosts
Other, lesser used, patterns are also accepted by TCP Wrappers. Refer to the hosts_access man 5 page for more information.

Warning

Be very careful when using hostnames and domain names. Attackers can use a variety of tricks to circumvent accurate name resolution. In addition, disruption to DNS service prevents even authorized users from using network services. It is, therefore, best to use IP addresses whenever possible.
48.5.2.1.3. Portmap and TCP Wrappers
Portmap's implementation of TCP Wrappers does not support host look-ups, which means portmap can not use hostnames to identify hosts. Consequently, access control rules for portmap in hosts.allow or hosts.deny must use IP addresses, or the keyword ALL, for specifying hosts.
Changes to portmap access control rules may not take effect immediately. You may need to restart the portmap service.
Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations.
48.5.2.1.4. Operators
At present, access control rules accept one operator, EXCEPT. It can be used in both the daemon list and the client list of a rule.
The EXCEPT operator allows specific exceptions to broader matches within the same rule.
In the following example from a hosts.allow file, all example.com hosts are allowed to connect to all services except cracker.example.com: 
ALL: .example.com EXCEPT cracker.example.com
In another example from a hosts.allow file, clients from the 192.168.0.x network can use all services except for FTP: 
ALL EXCEPT vsftpd: 192.168.0.

Note

Organizationally, it is often easier to avoid using EXCEPT operators. This allows other administrators to quickly scan the appropriate files to see what hosts are allowed or denied access to services, without having to sort through EXCEPT operators.

48.5.2.2. Option Fields

In addition to basic rules that allow and deny access, the Red Hat Enterprise Linux implementation of TCP Wrappers supports extensions to the access control language through option fields. By using option fields in hosts access rules, administrators can accomplish a variety of tasks such as altering log behavior, consolidating access control, and launching shell commands.
48.5.2.2.1. Logging
Option fields let administrators easily change the log facility and priority level for a rule by using the severity directive.
In the following example, connections to the SSH daemon from any host in the example.com domain are logged to the default authpriv syslog facility (because no facility value is specified) with a priority of emerg: 
sshd : .example.com : severity emerg
It is also possible to specify a facility using the severity option. The following example logs any SSH connection attempts by hosts from the example.com domain to the local0 facility with a priority of alert: 
sshd : .example.com : severity local0.alert

Note

In practice, this example does not work until the syslog daemon (syslogd) is configured to log to the local0 facility. Refer to the syslog.conf man page for information about configuring custom log facilities.
48.5.2.2.2. Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.
For example, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com: 
sshd : client-1.example.com : allow
sshd : client-2.example.com : deny
By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some administrators consider this an easier way of organizing access rules.
48.5.2.2.3. Shell Commands
Option fields allow access rules to launch shell commands through the following two directives:
  • spawn — Launches a shell command as a child process. This directive can perform tasks like using /usr/sbin/safe_finger to get more information about the requesting client or create special log files using the echo command.
    In the following example, clients attempting to access Telnet services from the example.com domain are quietly logged to a special file: 
    in.telnetd : .example.com \
	: spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
	: allow
  • twist — Replaces the requested service with the specified command. This directive is often used to set up traps for intruders (also called "honey pots"). It can also be used to send messages to connecting clients. The twist directive must occur at the end of the rule line.
    In the following example, clients attempting to access FTP services from the example.com domain are sent a message using the echo command: 
    vsftpd : .example.com \
	: twist /bin/echo "421 This domain has been black-listed. Access denied!"
For more information about shell command options, refer to the hosts_options man page.
48.5.2.2.4. Expansions
Expansions, when used in conjunction with the spawn and twist directives, provide information about the client, server, and processes involved.
The following is a list of supported expansions:
  • %a — Returns the client's IP address.
  • %A — Returns the server's IP address.
  • %c — Returns a variety of client information, such as the username and hostname, or the username and IP address.
  • %d — Returns the daemon process name.
  • %h — Returns the client's hostname (or IP address, if the hostname is unavailable).
  • %H — Returns the server's hostname (or IP address, if the hostname is unavailable).
  • %n — Returns the client's hostname. If unavailable, unknown is printed. If the client's hostname and host address do not match, paranoid is printed.
  • %N — Returns the server's hostname. If unavailable, unknown is printed. If the server's hostname and host address do not match, paranoid is printed.
  • %p — Returns the daemon's process ID.
  • %s —Returns various types of server information, such as the daemon process and the host or IP address of the server.
  • %u — Returns the client's username. If unavailable, unknown is printed.
The following sample rule uses an expansion in conjunction with the spawn command to identify the client host in a customized log file.
When connections to the SSH daemon (sshd) are attempted from a host in the example.com domain, execute the echo command to log the attempt, including the client hostname (by using the %h expansion), to a special file: 
sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
	: deny
Similarly, expansions can be used to personalize messages back to the client. In the following example, clients attempting to access FTP services from the example.com domain are informed that they have been banned from the server: 
vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"
For a full explanation of available expansions, as well as additional access control options, refer to section 5 of the man pages for hosts_access (man 5 hosts_access) and the man page for hosts_options.
Refer to Section 48.5.5, “Additional Resources” for more information about TCP Wrappers.

48.5.3. xinetd

The xinetd daemon is a TCP-wrapped super service which controls access to a subset of popular network services, including FTP, IMAP, and Telnet. It also provides service-specific configuration options for access control, enhanced logging, binding, redirection, and resource utilization control.
When a client attempts to connect to a network service controlled by xinetd, the super service receives the request and checks for any TCP Wrappers access control rules.
If access is allowed, xinetd verifies that the connection is allowed under its own access rules for that service. It also checks that the service can have more resources allotted to it and that it is not in breach of any defined rules.
If all these conditions are met (that is, access is allowed to the service; the service has not reached its resource limit; and the service is not in breach of any defined rule), xinetd then starts an instance of the requested service and passes control of the connection to it. After the connection has been established, xinetd takes no further part in the communication between the client and the server.

48.5.4. xinetd Configuration Files

The configuration files for xinetd are as follows:
  • /etc/xinetd.conf — The global xinetd configuration file.
  • /etc/xinetd.d/ — The directory containing all service-specific files.

48.5.4.1. The /etc/xinetd.conf File

The /etc/xinetd.conf file contains general configuration settings which affect every service under xinetd's control. It is read when the xinetd service is first started, so for configuration changes to take effect, you need to restart the xinetd service. The following is a sample /etc/xinetd.conf file: 
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 the following aspects of xinetd:
  • instances — Specifies the maximum number of simultaneous requests that xinetd can process.
  • log_type — Configures xinetd to use the authpriv log facility, which writes log entries to the /var/log/secure file. Adding a directive such as FILE /var/log/xinetdlog would create a custom log file called xinetdlog in the /var/log/ directory.
  • log_on_success — Configures xinetd to log successful connection attempts. By default, the remote host's IP address and the process ID of the server processing the request are recorded.
  • log_on_failure — Configures xinetd to log failed connection attempts or if the connection was denied.
  • cps — Configures xinetd to allow no more than 25 connections per second to any given service. If this limit is exceeded, the service is retired for 30 seconds.
  • includedir /etc/xinetd.d/ — Includes options declared in the service-specific configuration files located in the /etc/xinetd.d/ directory. Refer to Section 48.5.4.2, “The /etc/xinetd.d/ Directory” for more information.

Note

Often, both the log_on_success and log_on_failure settings in /etc/xinetd.conf are further modified in the service-specific configuration files. More information may therefore appear in a given service's log file than the /etc/xinetd.conf file may indicate. Refer to Section 48.5.4.3.1, “Logging Options” for further information.

48.5.4.2. The /etc/xinetd.d/ Directory

The /etc/xinetd.d/ directory contains the configuration files for each service managed by xinetd and the names of the files correlate to the service. As with xinetd.conf, this directory is read only when the xinetd service is started. For any changes to take effect, the administrator must restart the xinetd service.
The format of files in the /etc/xinetd.d/ directory use the same conventions as /etc/xinetd.conf. The primary reason the configuration for each service is stored in a separate file is to make customization easier and less likely to affect other services.
To gain an understanding of how these files are structured, consider the /etc/xinetd.d/krb5-telnet file: 
service telnet
{
         flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 disable         = yes
}
These lines control various aspects of the telnet service:
  • service — Specifies the service name, usually one of those listed in the /etc/services file.
  • flags — Sets any of a number of attributes for the connection. REUSE instructs xinetd to reuse the socket for a Telnet connection.

    Note

    The REUSE flag is deprecated. All services now implicitly use the REUSE flag.
  • socket_type — Sets the network socket type to stream.
  • wait — Specifies whether the service is single-threaded (yes) or multi-threaded (no).
  • user — Specifies which user ID the process runs under.
  • server — Specifies which binary executable to launch.
  • log_on_failure — Specifies logging parameters for log_on_failure in addition to those already defined in xinetd.conf.
  • disable — Specifies whether the service is disabled (yes) or enabled (no).
Refer to the xinetd.conf man page for more information about these options and their usage.

48.5.4.3. Altering xinetd Configuration Files

A range of directives is available for services protected by xinetd. This section highlights some of the more commonly used options.
48.5.4.3.1. Logging Options
The following logging options are available for both /etc/xinetd.conf and the service-specific configuration files within the /etc/xinetd.d/ directory.
The following is a list of some of the more commonly used logging options:
  • 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).
  • USERID — Logs the remote user using the method defined in RFC 1413 for all multi-threaded stream services (log_on_failure andlog_on_success).
For a complete list of logging options, refer to the xinetd.conf man page.
48.5.4.3.2. Access Control Options
Users of xinetd services can choose to use the TCP Wrappers hosts access rules, provide access control via the xinetd configuration files, or a mixture of both. Refer to Section 48.5.2, “TCP Wrappers Configuration Files” for more information about TCP Wrappers hosts access control files.
This section discusses using xinetd to control access to services.

Note

Unlike TCP Wrappers, changes to access control only take effect if the xinetd administrator restarts the xinetd service.
Also, unlike TCP Wrappers, access control through xinetd only affects services controlled by xinetd.
The xinetd hosts access control differs 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, xinetd's access control is found in each service's configuration file in the /etc/xinetd.d/ directory.
The following hosts access options are supported by xinetd:
  • only_from — Allows only the specified hosts to use the service.
  • no_access — Blocks listed hosts from using the service.
  • access_times — Specifies the time range when a particular service may be used. The time range must be stated in 24-hour format notation, HH:MM-HH:MM.
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 enhanced logging configuration can increase security by blocking requests from banned hosts while verbosely recording each connection attempt.
For example, the following /etc/xinetd.d/telnet file can be used to block Telnet access from a particular network group and restrict the overall time range that even allowed users can log in: 
service telnet
{
         disable         = no
	 flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 no_access       = 172.16.45.0/24
	 log_on_success  += PID HOST EXIT
	 access_times    = 09:45-16:15
}
In this example, when a client system from the 10.0.1.0/24 network, such as 10.0.1.2, tries to access the Telnet service, it receives the following message: 
Connection closed by foreign host.
In addition, their login attempts are logged in /var/log/messages as follows: 
Sep  7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
When using TCP Wrappers in conjunction with xinetd access controls, it is important to understand the relationship between the two access control mechanisms.
The following is the sequence of events followed by xinetd when a client requests a connection:
  1. The xinetd daemon accesses the TCP Wrappers hosts access rules using a libwrap.a library call. If a deny rule matches the client, the connection is dropped. If an allow rule matches the client, the connection is passed to xinetd.
  2. The xinetd daemon checks its own access control rules both for the xinetd service and the requested service. If a deny rule matches the client, the connection is dropped. Otherwise, xinetd starts an instance of the requested service and passes control of the connection to that service.

Important

Care should be taken when using TCP Wrappers access controls in conjunction with xinetd access controls. Misconfiguration can cause undesirable effects.
48.5.4.3.3. Binding and Redirection Options
The service configuration files for xinetd 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-specific configuration files and links the service to one IP address on the system. When this is configured, the bind option only allows requests to the correct IP address to access the service. You can use this method to bind different services to different network interfaces based on requirements.
This is particularly useful for systems with multiple network adapters or with multiple IP addresses. On such a system, insecure services (for example, Telnet), can be configured to listen only on the interface connected to a private network and not to the interface connected to the Internet.
The redirect option accepts an IP address or hostname followed by a port number. It configures 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 a different IP address on the same machine, shift the request to a totally different system and port number, or any combination of these options. A user connecting to a certain service on a system may therefore be rerouted to another system without 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 advantages of the bind and redirect options are most clearly evident 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, an internal system can be used 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 especially 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/kerberos/sbin/telnetd
	 log_on_success		+= DURATION USERID
	 log_on_failure		+= USERID
	 bind                    = 123.123.123.123
	 redirect                = 10.0.1.13 23
}
The bind and redirect options in this file 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 are 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 then sends the communication between the two systems, and the connecting system thinks 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 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.
48.5.4.3.4. Resource Management Options
The xinetd daemon can add a basic level of protection from Denial of Service (DoS) attacks. The following is a list of directives which can aid in limiting the effectiveness of such attacks:
  • per_source — Defines the maximum number of instances for a service per source IP address. It accepts only integers as an argument and can be used in both xinetd.conf and in the service-specific configuration files in the xinetd.d/ directory.
  • cps — Defines the maximum number of connections per second. This directive takes two integer arguments separated by white space. The first argument is the maximum number of connections allowed to the service per second. The second argument is the number of seconds that xinetd must wait before re-enabling the service. It accepts only integers as arguments and can be used in either the xinetd.conf file or the service-specific configuration files in the xinetd.d/ directory.
  • max_load — Defines the CPU usage or load average threshold for a service. It accepts a floating point number argument.
    The load average is a rough measure of how many processes are active at a given time. See the uptime, who, and procinfo commands for more information about load average.
There are more resource management options available for xinetd. Refer to the xinetd.conf man page for more information.

48.5.5. Additional Resources

More information about TCP Wrappers and xinetd is available from system documentation and on the Internet.

48.5.5.1. Installed Documentation

The documentation on your system is a good place to start looking for additional configuration options for TCP Wrappers, xinetd, and access control.
  • /usr/share/doc/tcp_wrappers-<version>/ — This directory contains a README file that discusses how TCP Wrappers work and the various hostname and host address spoofing risks that exist.
  • /usr/share/doc/xinetd-<version>/ — This directory contains a README file that discusses aspects of access control and a sample.conf file with various ideas for modifying service-specific configuration files in the /etc/xinetd.d/ directory.
  • TCP Wrappers and xinetd-related man pages — A number of man pages exist for the various applications and configuration files involved with TCP Wrappers and xinetd. The following are some of the more important man pages:
    Server Applications
    • man xinetd — The man page for xinetd.
    Configuration Files
    • man 5 hosts_access — The man page for the TCP Wrappers hosts access control files.
    • man hosts_options — The man page for the TCP Wrappers options fields.
    • man xinetd.conf — The man page listing xinetd configuration options.

48.5.5.2. Useful Websites