Controlling Network Access with xinetd

xinetd is the alternative to inetd used on some Linux systems—Red Hat Linux, for example. xinetd is configured in the /etc/xinetd.conf file. Chapter 3 describes the basic syntax and structure of the xinetd.conf file. As explained there, Red Hat creates individual xinetd configuration files for each service in the /etc/xinetd.d directory. These individual files are included by reference into the xinetd.conf file. Listing 12.2 shows a sample file from the xinetd.d directory.

Listing 12.2: An xinetd Configuration File

# default: off

# description: The IMAP service allows remote users to access their

# mail using an IMAP client such as Mutt, Pine, fetchmail,

# or Netscape Communicator.

service imap {

socket_type = stream wait = no user = root server = /usr/sbin/imapd log_on_success += DURATION USERID

log_on_failure += USERID

disable = no

The service, socket_type, wait, user, and server values all parallel values found in the inetd.conf file, except that the path provided for the server parameter does not invoke the tcpd wrapper program. The wrapper is not used because xinetd provides capabilities similar to those of wrapper on its own.

xinetd provides its own logging and its own access controls. Despite the fact that xinetd does not invoke tcpd, it does consult the /etc/hosts.allow and /etc/hosts.deny files in addition to the access controls defined in the xinetd.conf file. This means that hosts.allow and hosts.deny files created for other programs, such as portmapper, can provide security guidance to xinetd.

The log_on_success and log_on_failure lines in Listing 12.2 add the user ID of the remote user to the standard log entry when a successful connection is made or a connection attempt fails. The log_on_success line also logs the length of time that the server handling this connection ran. (DURATION applies only to log_on_success.) The += syntax means that the values defined for log_on_success and log_on_failure are added to the other values already being logged. In addition to logging the duration of the connection and the user ID of the remote user, log_on_success and log_on_failure allow you to log the following:

HOST The address of the remote host. Like USERID, this value can be used for both success and failure.

PID The process ID of the server started to handle the connection. PID applies only to log_on_success.

EXIT Logs the exit status of the server when the connection terminates. EXIT applies only to log_on_success.

ATTEMPT Logs unsuccessful connection attempts. ATTEMPT applies only to log_on_ failure.

RECORD Logs the connection information received from the remote server. This parameter applies only to log_on_failure.

The disable = no line in Listing 12.2 means that this service is enabled. To prevent this service from running, set disable to yes. As described earlier, Red Hat allows you to set the disable parameter from the chkconfig command line.

In addition to controlling whether or not a service is available, xinetd provides finer access controls. xinetd provides three different attributes for access control. It can be configured to accept connections from certain hosts, paralleling the host.allow file; to reject connections from certain hosts, paralleling the host.deny file; and to accept connections only at certain times of the day. These attributes are described as follows:

only_from This attribute identifies the hosts that are allowed to connect to the service. Hosts can be defined using

♦ a numeric address. For example, defines a specific host, and defines all hosts with an address that begins with 129.6. The address matches all addresses.

♦ an address scope. For example, 172.16.12.(3,6,8,23} defines four different hosts:,,, and

♦ a network name. The network name must be defined in the /etc/networks file.

♦ a canonical hostname. The IP address provided by the remote system must reverse-map to this hostname.

♦ a domain name. The hostname returned by the reverse lookup must be in the specified domain. For example, the value requires a host in the domain. Note that when a domain name is used, it starts with a dot.

♦ an IP address with an associated address mask. For example, would match every address from to

no_access This attribute defines the hosts that are denied access to the service. Hosts are defined using exactly the same methods as those described previously for the only_from attribute.

access_times This attribute defines the time of day a service is available, in the form hour\min-hour:min. A 24-hour clock is used. Hours are 0 to 23, and minutes are 0 to 59.

If neither only_from nor no_access is specified, access is granted to everyone. If both are specified, the most exact match applies—for example:

no_access =

The only_from command in this example permits every system on network to have access to the service. The no_access command takes away that access for one system. It doesn't matter whether the no_access attribute comes before or after the only_from attribute. It always works the same way because the more exact match takes precedence.

Listing 12.3 shows the /etc/xinetd.d/imap entry from our sample Red Hat system with some access controls added.

Listing 12.3: xinetd.conf Access Controls

# default: off

# description: The IMAP service allows remote users to access their

service {

mail using an IMAP client such as Mutt, Pine, fetchmail, or Netscape Communicator.

imap socket_type wait user server log_on_success log_on_failure disable only_from no_access server

= /usr/sbin/imapd += DURATION USERID += USERID = no

= = = /usr/sbin/in.rlogind

In Listing 12.3, the only_from attribute blocks access from every system except those on network At the same time, it permits access from every system on network, which is the local network for this sample system. In Listing 12.3, that is not exactly what we want. There is one system,, which is not trusted to have login access. The no_access attribute denies access to anyone on the system

tcpd wrapper can only protect services started by inetd or services, such as portmapper, which read the hosts.allow and hosts.deny file on their own. xinetd can secure only the services it starts. Other services, such as dhcpd, are started at boot time. To control access to services that are started by boot scripts and that don't read the tcpd configuration file, use the Linux IP firewall.

Was this article helpful?

0 0

Post a comment