Red Hat Knowledgebase

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.

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 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/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 client system from the 10.0.1.0/24 network, such as 10.0.1.2, tries to access the Telnet service, it receives a message stating the following message:

In addition, their login attempts are logged in /var/log/secure as follows:

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

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 order of operations followed by xinetd when a client requests a connection:

1. The xinetd daemon accesses the TCP wrappers hosts access rules through a libwrap.a library call. If a deny rule matches the client host, the connection is dropped. If an allow rule matches the client host, the connection is passed on 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 host the connection is dropped. Otherwise, xinetd starts an instance of the requested service and passes control of the connection to it.

Important: Care should be taken when using TCP wrappers access controls in conjunction with xinetd access controls. Misconfiguration can cause undesired effects.