Red Hat [Electronic resources] : The Complete Reference Enterprise Linux Fedora Edition؛ The Complete Reference نسخه متنی

Extended Internet Services Daemon (xinetd)

If your system averages only a few requests for a specific service, you don't need the server for that service running all the time. You need it only when a remote user is accessing its service. The Extended Internet Services Daemon (

xinetd ) manages Internet servers, invoking them only when your system receives a request for their services.

xinetd checks continuously for any requests by remote users for a particular Internet service; when it receives a request, it then starts the appropriate server daemon.

The

xinetd program is designed to be a replacement for

inetd , providing security enhancements, logging support, and even user notifications. For example, with

xinetd you can send banner notices to users when they are not able to access a service, telling them why.

xinetd security capabilities can be used to prevent denial-of-service attacks, limiting remote hosts' simultaneous connections or restricting the rate of incoming connections.

xinetd also incorporates TCP, providing TCP security without the need to invoke the

tcpd daemon. Furthermore, you do not have to have a service listed in the

/etc/services file.

xinetd can be set up to start any kind of special-purpose server. The Red Hat Linux versions 7.0 and up use

xinetd .

Starting and Stopping xinetd Services

You can start, stop, and restart

xinetd using its startup script in the

/etc/rc.d/init.d directory, as shown here:

# service xinetd stop
# service xinetd start
# service xinetd restart

On Red Hat, you can also turn on and off particular

xinetd services with

chkconfig , as described earlier. Use the

on and

off options to enable or disable a service.

chkconfig will edit the disable option for the service, changing its value to "yes" for off and "no" for on. For example, to enable the swat server, you could enter:

chkconfig swat on

xinetd Configuration: xinetd.conf

The

xinetd.conf file is the configuration file for

xinetd . Entries in it define different servers to be activated when requested along with any options and security precautions. An entry consists of a block of attributes defined for different features, such as the name of the server program, the protocol used, and security restrictions. Each block for an Internet service such as a server is preceded by the keyword

service and the name by which you want to identify the service. A pair of braces encloses the block of attributes. Each attribute entry begins with the attribute name, followed by an assignment operator, such as

= , and then the value or values assigned. A special block specified by the keyword

default contains default attributes for services. The syntax is shown here:

service <service_name>
{
<attribute> <assign_op> <value> <value> ...
...
}

xinetd Attributes

Most attributes take a single value for which you use the standard assignment operator,

= . Some attributes can take a list of values. You can assign values with the

= operator, but you can also add or remove items from these lists with the

=+ and

=- operators. Use

=+ to add values and

=- to remove values. You often use the

=+ and

=- operators to add values to attributes that may have an initial value assigned in the default block.

Attributes are listed in Table 20-6. Certain attributes are required for a service. These include

socket_type and

wait . For a standard Internet service, you also need to provide the

user (user ID for the service), the

server (name of the server program), and the

protocol (protocol used by the server). With

server_args , you can also list any arguments you want passed to the server program (this does not include the server name as with

tcpd ). If protocol is not defined, the default protocol for the service is used.

service tftp   
{
socket_type = stream
wait = no
user = root
protocol = ftp
server = /usr/sbin/in.tftpd
server_args = -l -a
disable = yes
}

Disabling and Enabling xinetd Services

Services can be turned on and off with the

disable attribute. To enable a service, you set the disable attribute to

no , as shown here:

disable = no

You then have to restart

xinetd to start the service.

# /etc/rc.d/init.d/xinetd restart

To enable management by

chkconfig , a commented default and description entry needs to be placed before each service segment. Where separate files are used, the entry is placed at the head of each file. Red Hat already provides these for the services it installs with its distribution, such as POP3 and SWAT. A default entry can be either on or off. For example, the

chkconfig default and description entries for the FTP service are shown here:

# default: off
# description: The POP3 service allows users#     to access 
their mail using a POP3 client #    such as Netscape Communicator, or fetchmail.

Red Hat indicates whether a service is set on or off by default. If you want to turn on a service that is off by default, you have to set its

disable attribute to

no and restart

xinetd . The Red Hat entry for the POP3 mail server,

ipop3d , is shown here. An initial comment tells you that it is off by default, but then the

disable attribute turns it on:

# default: off
# description: The POP3 service allows users#     to access
 their mail using a POP3 client #    such as Netscape Communicator, or fetchmail.

service pop3
{
socket_type     = stream
wait            = no
user            = root
server          = /usr/sbin/ipop3d
log_on_success += HOST_DURATION
log_on_failure += HOST
disable         = no
}

Logging xinetd Services

You can further add a variety of other attributes such as logging information about connections and server priority (

nice ). In the following example, the

log_on_success attribute logs the duration (

DURATION ) and the user ID (

USERID ) for connections to a service,

log_on_failure logs the users that failed to connect, and

nice sets the priority of the service to 10.

log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10

The default attributes defined in the defaults block often set global attributes such as default logging activity and security restrictions.

log_type specifies where logging information is to be sent, such as to a specific file (

FILE ) or to the system logger (

SYSLOG ).

log_on_success specifies information to be logged when connections are made, and

log_on_failure specifies information to be logged when they fail.

log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST RECORD

xinetd Network Security

For security restrictions, you can use

only_from to restrict access by certain remote hosts.

no_access denies access from the listed hosts, but no others. These controls take IP addresses as their values IP addresses. You can list individual IP addresses, a range of IP addresses, or a network, using the network address. The

instances attribute limits the number of server processes that can be active at once for a particular service. The following examples restrict access to a local network 192.168.1.0 and the localhost, deny access from 192.168.1.15, and use the

instances attribute to limit the number of server processes at one time to 60.

only_from = 192.168.1.0
only_from = localhost
no_access = 192.168.1.15
instances = 60

xinetd Defaults and Internal Services

A sample default block is shown here:

defaults
{
instances = 60
log_type = FILE /var/log/servicelog
log_on_success = HOST PID
log_on_failure = HOST RECORD
only_from = 192.168.1.0
only_from = localhost
no_access = 192.168.1.15
}

The

xinetd program also provides several internal services, including

time ,

services , servers, and

xadmin .

services provides a list of currently active services, and

servers provides information about servers.

xadmin provides

xinetd administrative support.

Service Files in xinetd.d Directory

Instead of having one large

xinetd.conf file, you can split it into several configuration files, one for each service. You do this by creating an

xinetd.conf file with an

includedir attribute that specifies a directory to hold the different service configuration files. In the following example, the

xinetd.d directory holds

xinetd configuration files for services like swat. Red Hat uses just such an implementation. This approach has the advantage of letting you add services by just creating a new configuration file for them. Modifying a service involves editing only its configuration file, not an entire

xinetd.conf file.

includedir /etc/xinetd.d

The following example shows the

xinetd.conf file used for Red Hat Linux:

#
# Simple configuration file for xinetd
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances           = 60
log_type            = SYSLOG authpriv
log_on_success      = HOST PID
log_on_failure      = HOST
cps                         =  25 30
}
includedir /etc/xinetd.d

As an example, the

swat file in the

xinetd.d directory is shown here. Notice that it is disabled by default:

# default: off
# description: SWAT is the Samba Web Admin Tool.# Use swat
 to configure your Samba server. # To use SWAT, connect to port 901
 with your # favorite web browser.
service swat
{
port               = 901
socket_type        = stream
wait               = no
only_from          = localhost
user               = root
server             = /usr/sbin/swat
log_on_failure    += USERID
disable            = yes
}

TCP Wrappers

TCP wrappers add another level of security to

xinetd -managed servers. In effect, the server is wrapped with an intervening level of security, monitoring connections and controlling access. A server connection made through

xinetd is monitored, verifying remote user identities and checking to make sure they are making valid requests. Connections are logged with the

syslogd daemon (see Chapter 27) and may be found in

syslogd files such as

/var/log/secure . With TCP wrappers, you can also restrict access to your system by remote hosts. Lists of hosts are kept in the

hosts.allow and

hosts.deny files. Entries in these files have the format

service:hostname:domain . The domain is optional. For the service, you can specify a particular service, such as FTP, or you can enter

ALL for all services. For the hostname, you can specify a particular host or use a wildcard to match several hosts. For example,

ALL will match on all hosts. Table 20-7 lists the available wildcards. In the following example, the first entry allows access by all hosts to the Web service,

http . The second entry allows access to all services by the

pango1.train.com host. The third and fourth entries allow FTP access to

rabbit.trek.com and

sparrow.com :

http:ALL
ALL:pango1.train.com
ftp:rabbit.trek.com
ftp:sparrow.com

The

hosts.allow file holds hosts to which you allow access. If you want to allow access to all but a few specific hosts, you can specify

ALL for a service in the

hosts.allow file but list the ones you are denying access to in the

hosts.deny file. Using IP addresses instead of hostnames is more secure because hostnames can be compromised through the DNS records by spoofing attacks where an attacker pretends to be another host.

When

xinetd receives a request for an FTP service, a TCP wrapper monitors the connection and starts up the

in.ftpd server program. By default, all requests are allowed. To allow all requests specifically for the FTP service, you would enter the following in your

/etc/hosts.allow file. The entry

ALL:ALL opens your system to all hosts for all services:

ftp:ALL