Enable the Extended Internet Daemon (xinetd)

• In this objective, you will learn how to enable the Extended Internet Daemon (xinetd) by reviewing the following:

What xinetd Is

Attach:netsrv13.png

A traditional server daemon launches and listens on a port for a request. When the request comes in it immediately handles the request. The downside of having multiple, infrequently used server daemons running all of the time is that they are consuming system resources such as memory while not doing any work.

A super server like xinetd listens on multiple ports and when a request comes in on a port, the super server launches the daemon responsible for that port to handle the request. When the session is closed, the super server shuts down the daemon. This allows for more efficient use of system resources such as memory for infrequently used services. The downside is that it can take slightly longer for the requested service to respond to requests.

What xinetd Is

• Services can run in one of two ways:

• xinetd accepts the connection requests, starts the required service, and passes the request to the newly started server process.
• Starting services through xinetd saves resources.
• Starting services through xinetd creates a delay while waiting for the required service.

Services can run either standalone, meaning they listen on a port themselves, or via the “super daemon” xinetd. In this case, the super daemon acts as a mediator of connection requests for a series of services. It accepts the connection requests, starts the required service, and passes the request to the newly started server process. If the connection between the client and the server is terminated, the server process started by xinetd is removed from memory.

Starting services through xinetd has both advantages and disadvantages. The most significant advantage is saving resources (especially memory), since a server process is started only when it is needed. A disadvantage, however, is that a delay occurs while the required service is loaded, started, and connected.

As a rule, you want to use xinetd only for services that are occasionally (not permanently) needed on the server. Some of the services run traditionally by xinetd include FTP and TFTP.

NOTE: For detailed information about xinetd, enter man 8 xinetd.

Configure xinetd with YaST

• To configure xinetd with YaST, do one of the following:

• Enable the xinetd daemon by selecting Enable

Attach:netsrv14.png

Enable the xinetd super daemon by selecting Enable. This activates the Currently Available Services list. You can Add, Edit, or Delete services in the list.

Add: Create a new xinetd configuration for a service from scratch.

Edit: Edit an existing xinetd configuration for a service. The service itself might have another configuration of its own, such as /etc/vsftpd.conf for vsftpd, that may need to be edited outside of YaST with an editor.

Delete: Remove a xinetd configuration of a service and turn it off.

Notice that some services are off (---), while others are not installed (NI).

To turn on a service, select the service and then select Toggle Status (On or Off). If a service is not installed, it will be installed. The word “On” appears in the Status column. An “X” appears in the Changed (Ch) column to indicate that the service has been edited and will be changed in the system configuration.

You can change the status of all installed services to On or Off by selecting Status for All Services > Activate All Services or Status for All Services > Deactivate All Services.

When you are done configuring the services, save the configuration setting and start the xinetd daemon by selecting Finish.

Configure xinetd

• /etc/xinetd.conf file
• Files in the /etc/xinetd.d/ directory

The /etc/xinetd.conf File

• Syntax:

    defaults
    {
        key operator parameter parameter. . .
    }

• Keys include log_type, only_from, instances, ...
• Operators include =, =, +=
• Parameters include file names, IP addresses, ...

In SUSE Linux Enterprise Server 12, the /etc/xinetd.conf file contains only general options, no service configurations.

Most attributes (keys) support only the operator =, but you can include additional values to some attributes by entering += or remove them by entering -=.

• The defaults entry in the configuration file is optional and allows you to set defaults such as the following:

Attach:netsrv15.png

The log_type and instances configuration will be overwritten if something else has been defined in the individual service entries. For all other attributes, the default configuration is combined with the values set in the services.

The log_type statement can define whether (as in the example) the output is forwarded to the syslog daemon or written directly to a log file (such as log_type = FILE /var/log/xinetd.log).

The keys log_on_success and log_on_failure configure what should be recorded in the log file, depending on whether the connection to a network service succeeds or fails.

The key instances can be used to limit the maximum possible number of daemons for each service, which protects the machine from either intentional or accidental overload due to too many simultaneous connections (denial-of-service attempts).

cps stands for connections per second. The first value (50) is the maximum number of connections per second that can be handled. The second value (10) is the wait period before accepting new connections after the maximum has been exceeded (helpful in preventing Denial of Service attacks).

The directive includedir /etc/xinetd.d prompts xinetd to search all files in the /etc/xinetd.d/ directory for the configuration of services. The syntax is the same as that used in /etc/xinetd.conf.

The /etc/xinetd.d/ Directory

• The /etc/xinetd.d/ directory contains separate configuration files for every service.
• Syntax is the same as used in /etc/xinetd.conf

    service service_name
    {
        key operator parameter parameter. . .
        key operator parameter parameter. . .
    }

The main advantage of splitting the configuration in several files is ease of administration and that individual software packages can add their own xinetd configuration to the directory.

Configuration File Example

• The following is an example of the configuration of vsftpd:

Attach:netsrv16.png

Configuration File Keywords

Attach:netsrv17.png

NOTE: For a description of all possible parameters, in a terminal window enter man xinetd.conf.

Internal Services

• Certain services are provided by xinetd itself without calling another program.
• Internal services are labeled in the configuration as follows:

• With services such as echo, you must:

Certain services (such as echo, time, daytime, chargen, and discard) are provided by xinetd itself without calling another program. These are called internal services and are labeled in the configuration as type = INTERNAL

Without this line, xinetd assumes that external services are involved. With services such as echo, which are both TCP- and UDP-based services, you not only specify the respective socket_type, but you also need to identify the service in the id field in such a way that it is properly distinguished from other services.

• Example: Echo over TCP:

Attach:netsrv18.png

Attach:netsrv19.png

chkconfig

• Use the chkconfig program to list services covered by xinetd as shown in the following:

http://shristov.eu/pmwiki/uploads/CertificationMaterials/netsrv20png Attach:netsrv20.png

• chkconfig can also be used to turn xinetd services on and off:

    da10:~ # chkconfig daytime
    daytime off
    da10:~ # chkconfig daytime on
    da10:~ # chkconfig daytime
    daytime xinetd
    da10:~ #

Configure Access Control

• The daemon xinetd recognizes four parameters used to control access monitoring:

Access Control Example

• The following is an example for the Telnet service:

Attach:netsrv21.png

These settings result in the following:

    192.168.0.3
    192.168.0.7
    192.168.0.10
    192.168.0.12
    192.168.1.0-255

Configure Log Files

• To protect your server, you need log files that the system administrator can use to detect unauthorized attempts to log in.
• To maintain optimal system security, you need to record failed and unauthorized connection attempts.
• To shut off a service but still retain its logging functions, configure only_from without using any additional parameters as in the following:

Almost every hacker has to make several attempts and needs some time before achieving success. To protect your server, you not only need hacker-resistant software, but you also need log files that the system administrator can use to detect unauthorized attempts to log in.

Because of this, it does not make sense to only deter unauthorized access attempts. To maintain optimal system security, you also need to record failed and unauthorized connection attempts.

To shut off a service but still retain its logging functions, configure only_from without using any additional parameters.

log_type

• Logging through xinetd is controlled by the log_type key along with the log_on_success and log_on_failure keys.
• You can also log the circumstances of how and why the network service was used.

Logging through xinetd is controlled by the log_type statement (SYSLOG or FILE) along with the log_on_success and log_on_failure attributes.

These let you record from which host and for how long an access attempt was made, and which user was using the service (if the remote host supports this feature).

In addition, you can also log the circumstances of how and why the network service was used. However, even the best log does not mean much if you do not check it on a regular basis for failed connection attempts.

Manage xinetd

• To have the daemon automatically activated at boot, enter:

• To start the daemon, use one of the following commands:

• To stop the daemon, use one of the following commands:

• /usr/sbin/rcxinetd is a link to /sbin/service
• To find out if the daemon is currently running, use one of the following commands:

• To have xinetd reload its configuration:

• xinetd can be influenced by signals sent with kill or killall

Attach:netsrv22.png