لطفا منتظر باشید ...
Using xinetd
Traditionally, inetd has been the super
server used on Linux systems. Since 2000, however, a shift has begun toward the
use of an alternative, xinetd (pronounced "zi-net-dee"). As a first approximation, you
can think of xinetd as being a combination of inetd and TCP Wrappers. This
is only a rough analogy, though; there are things that xinetd can do
that inetd with TCP Wrappers can't do, and things that inetd with TCP
Wrappers can do that xinetd alone can't do. In the end, though, xinetd is more flexible
because it can be combined with TCP Wrappers, if required, to extend its
flexibility. In early 2002, Red Hat and Mandrake are the two major
distributions that use xinetd by default, but you can add xinetd to other
distributions if you like.
The /etc/xinetd.conf File Format
As a new super server with expanded
capabilities, xinetd requires a new file format. The /etc/xinetd.conf file
controls xinetd , but both Red Hat and Mandrake provide only a minimal xinetd.conf file. This file includes default settings for all servers and a line that
causes xinetd to read all the files in /etc/xinetd.d and treat
them as supplementary configuration files. Thus, xinetd configuration is
something like SysV configuration, in that each server has its own control file
named after the server, such as /etc/xinetd.d/telnet to control the Telnet
server. You can configure xinetd using just its main xinetd.conf file if you prefer, but server
packages for Red Hat and Mandrake often drop their startup files in /etc/xinetd.d .Whether it's located in /etc/xinetd.conf or a file in /etc/xinetd.d , a xinetd server definition spans several lines; however, a basic definition
includes the same information as an inetd.conf entry. For
instance, the following xinetd definition is mostly equivalent to the inetd.conf entry
presented earlier for a Telnet server: service telnet { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/in.telnetd }
This entry provides the same information as an inetd.conf entry. The xinetd configuration file format, however,
explicitly labels each entry and splits them across multiple lines. Although
this example presents data in the same order as does the inetd configuration, this order isn't
required. Also, the xinetd
definition doesn't call TCP Wrappers, although it could (you'd list /usr/sbin/tcpd on the server line, then add a server_args line that would list /usr/sbin/in.telnetd to pass the name of
the Telnet server to TCP Wrappers).In addition to the standard inetd
features, xinetd provides many
configuration options to expand its capabilities. Most of these are items that
appear on their own lines between the curly braces in the service definition.
The most important of these options include the following: Security features As noted
earlier, xinetd provides
numerous security options, many of which are roughly equivalent to those
provided by TCP Wrappers. These are discussed in greater depth in the upcoming
section "
disable an inetd server by
commenting out its configuration line. You can accomplish the same goal by
adding the disable = yes line to
a xinetd server definition. The
same effect can be achieved in the main /etc/xinetd.conf
file by using the disabled = server_list option in the defaults section, where server_list is a space-delimited list
of server names. Various configuration tools use one of these methods to
disable servers, and in fact a disable = no
line may be present for servers that are active. Redirection If you want to
pass a request to another computer, you can use the redirect = target
option, where target is
the hostname or IP address of the computer that should receive the request. For
instance, if you include the redirect =
192.168.3.78 line in the /etc/xinetd.d/telnet
file of dummy.threeroomco.com ,
attempts to access the Telnet server on dummy.threeroomco.com will be redirected to the
internal computer on 192.168.3.78. You might want to use this feature on a NAT
router (see Chapter 25 ) to allow an internal computer to
function as a server for the outside world. The iptables utility can accomplish the same goal at a somewhat
lower level, but doing it in xinetd
allows you to apply xinetd 's
access control features. Logging You can fine-tune xinetd 's logging of access attempts using
the log_on_success and log_on_failure options, which determine
what information xinetd logs on
successful and unsuccessful attempts to access a server. These options take
values such as PID (the server's
process ID, or PID), HOST (the
client's address), USERID (the
user ID on the client system associated with the access attempt), EXIT (the time and exit status of the
access termination), and DURATION
(how long the session lasted). When setting these values, you can use a += or -=
symbol, rather than = , to add or
subtract the features you want to log from the default. Connection load limits You can
limit the number of connections that xinetd
will handle in several ways. One is the per_source
option, which specifies how many connections xinetd
will accept from any given source at any one time. ( UNLIMITED sets xinetd
to accept an unlimited number of connections.) The instances option specifies the maximum number of processes xinetd will spawn (this value may be
larger than the per_source
value). The cps option takes two
space- separated values: the number of connections xinetd accepts per second and the number of seconds to
pause after this limit is reached before enabling access again. You can adjust
the scheduling priority of the servers that xinetd
runs using the nice option,
which sets a value in much the same way as the nice
program. Finally, max_load takes
a floating-point value that represents the system load average above which xinetd refuses further connections. Taken
together, these options can reduce the chance that your system will experience
difficulties because of certain types of denial of service (DoS) attacks or
because of a spike in the popularity of your servers.You can use most of these options directly in the server
definition or in the defaults section in the main /etc/xinetd.conf file. If placed in the latter location,
the feature applies to all servers handled through xinetd , unless overridden by a competing option in the
server definition area.If you make changes to the /etc/xinetd.conf file or its included files in /etc/xinetd.d , you must
restart the xinetd server program. Because xinetd itself is usually
started through a SysV startup script, you can do this by typing a command such
as /etc/rc.d/init.d/xinetd
restart , although the startup script may be
located somewhere else on some distributions. Alter natively, you can pass xinetd the SIGUSR1 or SIGUSR2 signals via kill . The former tells xinetd to reload its configuration file
and begin responding as indicated in the new file. The latter does the same,
but also terminates any servers that have been inactivated by changes to the
configuration file.
Setting Access Control Features
Part of the appeal of xinetd is that
it combines access control features that closely resemble those of TCP Wrappers
in the super server itself. This can simplify configuration. The TCP Wrappers
and xinetd access control features aren't exactly identical, though, so there
are situations in which one tool or the other is superior. Like other xinetd configuration options, you can set access control features either globally or
for specific servers. Major access control options include the
following: Host-based
restrictions The only_from and no_access options are conceptually very similar to the contents of the /etc/hosts.allow and /etc/hosts.deny files for TCP Wrappers, but xinetd sets these
features in its main configuration file or server-specific configuration file. Specifically,
only_from sets a list of computers that are explicitly allowed access (with
all others denied access), whereas no_access specifies
computers that are to be blacklisted. If both are set for an address, the one
with a more specific rule takes precedence. For both options, addresses may be
specified by IP address (for instance, 172.23.45.67 ), by network
address using a trailing .0 (for instance, 172.23.0.0 for 172.23.0.0/16) or with an explicit netmask (as in 127.23.0.0/16 ),
a network name listed in /etc/networks , or a hostname (such as badguy.threeroomco.com ). If a hostname is used, xinetd does a single
lookup on that hostname at the time the server starts, so if the hostname-to-IP
address mapping changes, a hostname may not be very effective. Temporal restrictions You can specify a range of times during which the server is available
by using the access_times option. This option requires an access time specified as hour :minute-hour:minute , such as 08:00-18:00 , which restricts access to the server to the hours of 8:00 AM to
6:00 PM. Times are specified in a 24-hour format. Note that this restricts only
the initial access to the server. For instance, if the Telnet server is
restricted to 8:00 AM to 6:00 PM, somebody could log in at 5:58 PM and stay on
indefinitely. Interface
restrictions You can bind a server to just one
network interface using the bind or interface options (they're synonyms), which take the IP address associated
with an interface. For instance, if eth1 is linked to
172.19.28.37, bind =
172.19.28.37 links a server only to eth1 . Any attempt to access the server from
eth0 is met with silence, as if the server weren't running at all. This
feature is most useful on routers and other computers linked to more than one
network, but it's also of interest to those with small internal networks and
dial-up links. For instance, you can bind servers like Telnet or FTP to your
local Ethernet interface, and they won't be available to the Internet at large
via your PPP connection.Although this and the preceding section
outline the most useful xinetd options, there are some less often used options that aren't
described here. You should consult the xinetd man page for
further information on additional options.
