5.4. The inetdxinetd Daemon | Hacker Linux Uncovered

5.4. The inetd/xinetd Daemon

To process requests from clients , the server has to be permanently loaded into the memory and connected to a certain port. There is nothing difficult about this, but keeping the program loaded in the memory all the time is not efficient use of the memory resources, especially if the program is large and its services are seldom required. In such a case, it is better to have one service monitoring ports and launching the necessary service when it detects access to a certain port. Linux implements this capability in the older inetd and the newer xinetd daemons.

How do these daemons decide which service to start? They employ the /etc/services file for this. The file contains a list of services and the associated ports in the following format:

 name port/protocol  alias

Name The name of the service to run.
Port The port number to monitor.
Protocol The inetd service can work with TCP and UDP, whose ports do not intersect (and are totally different); thus, the protocol to work with has to be specified explicitly.
Alias A name that can be given to the service.

For example, there are following lines in the /etc/services file:

 tcpmux       1/tcp         # TCP port service multiplexer tcpmux       1/udp         # TCP port service multiplexer rje          5/tcp         # Remote Job Entry rje          5/udp         # Remote Job Entry echo         7/tcp ... ... ftp             21/tcp ftp             21/udp            fsp fspd ... ...

I selected these entries on purpose to show your how various services are described.

If you have an old Linux distribution, it most likely still uses inetd . As was already mentioned, this old version is a potential security problem. You should update to xinetd , which is becoming, if it has not already become, the standard.

I recommend switching to xinetd because it contains many additional features that make administration more convenient and the service more secure. For example, it has functions built in to check all successful and unsuccessful connections, to control access, and to only allow access at strictly defined times.

5.4.1. Configuring xinetd

The /etc/xinetd.conf file is the main configuration file for the xinetd daemon. The file contains default configuration settings for the services to be launched and the directory, in which the configuration files for specific services are to be stored. The contents of the file are shown in Listing 5.3.

Listing 5.3: The /etc/xinetd.conf configuration file

 # # 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

The defaults keyword is followed by the default settings for all services. Any of these values can be changed for each individual service.

The last entry specifies the /etc/xinet.d directory:

 includedir /etc/xinetd.d

This catalog contains configuration files for each service. The files are named after the corresponding services; their contents are similar to the contents of the /etc.xinetd.conf file. Listing 5.4 shows the contents of the /etc/xinet.d/telnet configuration file for the Telnet service.

Listing 5.4: The Telnet service configuration file

 # default: on # description: The telnet server services telnet sessions; # it uses unencrypted username/password # pairs for authentication. service telnet {        disable            = no        flags              = REUSE        socket_type        = stream        wait               = no        user               = root        server             = /usr/sbin/in.telnetd        log_on_failure    += USERID }

The following are the main parameters that can be edited:

disable If set to true , this disables the service.
flags Attributes for the service's execution.
socket_type The type of the socket used. Should be stream for TCP, and dgram for UDP.
protocol The protocol used to transfer data (TCP or UDP).
server The full path to the daemon's executable program.
user Access rights. In most cases, the value of this parameter will be root . This is a normal situation, because the root rights are required for working with ports below 1024. Currently, most services lower their rights according to the settings.
instances The maximum number of program instances that can run simultaneously .
log_type Events to be logged in the specified file or system log.
log_on_success and log_on_failure Information to be logged upon a successful or an unsuccessful system login, respectively. The following three values can be used: PID, HOST , or USER .
per_source The maximum number of connections per user. A single user can create several connections, because users like to squeeze everything they can out of the channel by creating several connections working in parallel.
server_args The arguments, with which the server is to be launched.

In connection with the user parameter, I stated that the root rights are necessary to be able to work with ports below 1024. What is the reason for this restriction? Unless a user has the root rights, he or she will not be able to launch a service that works with a port in the 1 to 1024 port number range. This protection is necessary because ports in this range are used by important services that regular users are not allowed to run.

Just imagine that hackers who only manage to obtain user rights are able to run the FTP server. This will allow them to upload to and download from the server any files that they desire , which will not make you happy.

5.4.2. Security

You already know that the rights and time to access services using the xinetd program can be restricted. This can be done using the no_access, only_from , and access_time commands in the configuration file.

The no_access command prohibits access from the specified computers. For example, the following entry in the configuration file prohibits access from the 192.168.1.1 address:

 no_access 192.168.1.1

To prohibit access from an entire network, only its address has to be specified. For example, to prohibit access to all computers in the 192.168.1. x network, the following entry is added:

 no_access 192.168.1

Note that in this case the IP address consists not of four octets, as usual, but only of three.

To prohibit access completely, the following line has to be added to the configuration file:

 no_access 0.0.0.0

Now consider how access can be allowed using the only_from command. This command is handy because it can be used to prohibit access from any address and then allow it only from a specified address. Access from any address is prohibited by issuing the command without an argument, as follows :

 only_from =

I recommend including this line in the main configuration file /etc/xinetd.conf and then specifying permitted addresses for each service in its configuration file. For example, to allow access from the addresses 192.168.1.2 and 192.168.1.19, the following entry is added to the configuration file:

 only_from  =  192.168.1.2 192.168.1.19

A network is allowed access by the following entry:

 only_from  =  192.168.1.

To allow access to all of the network but not to one computer in it, the following two entries can be used:

 no_access  =  192.168.1.1 only_from  =  192.168.1.

The priority of the prohibition command is higher than that of the permission command, so even though the entire network is allowed access, the 192.168.1.1 computer from this network will not be able to connect.

Next, consider how the access time can be specified. It is logical to allow access to a server working in a company office only during work hours. For example, the following entry allows access only from 8:00 to 18:00:

 access_time = 8:00 -18:00

I, however, would recommend increasing the second value to 19:00, because employees often stay after work and I personally do not like to be pestered about the access rights every day.

The xinetd built-in security functions are quite convenient and powerful, even though they double the access rights that can be configured in the /etc/hosts.allow and /etc/ hosts .deny files. I prefer configuring security settings using the xinetd configuration files because the access parameters here are stored in the files of those services that they affect.

5.4.3. Shortcomings of xinetd

Any technology has its shortcoming, and inetd/xinetd is not an exception. When a user connects to one of the ports of your server, the xinetd program parses the port table to locate the service that has to be launched. The process of the looking up the service and its launching may take a little while. But this is not the worst thing. A user can wait a few seconds, but it's a different story with hackers. They can direct a large number of requests to connect to the server, and the xinetd program will consume all of the resources searching for and launching the requested services. In this way, a successful DoS attack can be carried out.