User guide

Chapter 2. Securing Your Network
64
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.
2.3.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
{