Extended Internet Services Daemon (xinetd)
|
| < Day Day Up > |
|
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 } | Attribute | Description |
|---|---|
| id | Identifies a service. By default, the service ID is the same as the service name. |
| type | Type of service: RPC, INTERNAL (provided by xinetd), or UNLISTED (not listed in a standard system file). |
| flags | Possible flags include REUSE, INTERCEPT, NORETRY, IDONLY, NAMEINARGS (allows use of tcpd), NODELAY, and DISABLE (disable the service). See the xinetd.conf man page for more details. |
| disable | Specify yes to disable the service. |
| socket_type | Specify stream for a stream-based service, dgram for a datagram-based service, raw for a service that requires direct access to IP, and seqpacket for reliable sequential datagram transmission. |
| protocol | Specifies a protocol for the service. The protocol must exist in /etc/protocols. If this attribute is not defined, the default protocol employed by the service will be used. |
| wait | Specifies whether the service is single-threaded or multithreaded (yes or no). If yes, the service is single-threaded, which means that xinetd will start the server and then stop handling requests for the service until the server stops. If no, the service is multithreaded and xinetd will continue to handle new requests for it. |
| user | Specifies the user ID (UID) for the server process. The user name must exist in /etc/passwd. |
| group | Specifies the GID for the server process. The group name must exist in /etc/group. |
| instances | Specifies the number of server processes that can be simultaneously active for a service. |
| nice | Specifies the server priority. |
| server | Specifies the program to execute for this service. |
| server_args | Lists the arguments passed to the server. This does not include the server name. |
| only_from | Controls the remote hosts to which the particular service is available. Its value is a list of IP addresses. With no value, service is denied to all remote hosts. |
| no_access | Controls the remote hosts to which the particular service is unavailable. |
| access_times | Specifies the time intervals when the service is available. An interval has the form hour:min-hour:min. |
| log_type | Specifies where the output of the service log is sent, either syslog facility (SYSLOG) or a file (FILE). |
| log_on_success | Specifies the information that is logged when a server starts and stops. Information you can specify includes PID (server process ID), HOST (the remote host address), USERID (the remote user), EXIT (exit status and termination signal), and DURATION (duration of a service session). |
| log_on_failure | Specifies the information that is logged when a server cannot be started. Information you can specify includes HOST (the remote host address), USERID (user ID of the remote user), ATTEMPT (logs a failed attempt), RECORD (records information from the remote host to allow monitoring of attempts to access the server). |
| rpc_version | Specifies the RPC version for a RPC service. |
| rpc_number | Specifies the number for an UNLISTED RPC service. |
| env | Defines environment variables for a service. |
| passenv | The list of environment variables from xinetd's environment that will be passed to the server. |
| port | Specifies the service port. |
| redirect | Allows a TCP service to be redirected to another host. |
| bind | Allows a service to be bound to a specific interface on the machine. |
| interface | Synonym for bind. |
| banner | The name of a file to be displayed for a remote host when a connection to that service is established. |
| banner_success | The name of a file to be displayed at the remote host when a connection to that service is granted. |
| banner_fail | The name of a file to be displayed at the remote host when a connection to that service is denied. |
| groups | Allows access to groups the service has access to (yes or no). |
| enabled | Specifies the list of service names to enable. |
| include | Inserts the contents of a specified file as part of the configuration file. |
| includedir | Takes a directory name in the form of includedir /etc/xinetd.d. Every file inside that directory will be read sequentially as an xinetd configuration file, combining to form the xinetd configuration. |
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
| Tip | Red Hat currently disables all the services it initially set up when it installs xinetd. To enable a particular service, you will have to set its disable attribute to no. |
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
| Wildcard | Description |
|---|---|
| ALL | Matches all hosts or services. |
| LOCAL | Matches any host specified with just a hostname without a domain name. Used to match on hosts in the local domain. |
| UNKNOWN | Matches any user or host whose name or address is unknown. |
| KNOWN | Matches any user or host whose name or address is known. |
| PARANOID | Matches any host whose hostname does not match its IP address. |
| EXCEPT | An operator that lets you provide exceptions to matches. It takes the form of list1 EXCEPT list2 where those hosts matched in list1 that are also matched in list2 are excluded. |
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
| Tip | Originally, TCP wrappers were managed by the tcpd daemon. However, xinetd has since integrated support for TCP wrappers into its own program. You can explicitly invoke the tcpd daemon to handle services if you wish. The tcpd man pages (man tcpd) provide more detailed information about tcpd. |
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 328