126

Chapter 8. TCP Wrappers and

xinetd

8.3.1.4. 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.