About inetd and xinetd

Dialog unix: Using Internet "Super Waiter", inetd and xinetd January 06, 2010 16:00 Source: Chinaunix Document Channel Author: send_linux Edit: Zhou Rongmao Level: Intermediate

Martin Streicher, software developer, Pixel, Byte, and Comma

January 07, 2010 inetd is often called "super Waiter". XINETD is a variant of inetd that uses the same, but XINETD is more secure and can restrict access when the system is overloaded. Learn how inetd and xinetd work and how to configure it to add New daemons.

In theory, UNIX® is the kernel, or low-level software, that controls access to computer resources such as file systems, memory, and processors. However, in more popular terms, UNIX refers to a complete set of software running on the operating system. In fact, "It is a UNIX machine" is the basic function of the system: UNIX machines typically provide a shell interface, parallel access, powerful security, and a wide range of networking services.

Common abbreviations DNS: domain Name System FTP: file Transfer Protocol HTTP : Hypertext Transfer Protocol IMAP: Internet Information Access Protocol POPs: Post Office Protocol SMTP: Simple Mail Transfer Protocol TCP: Transmission Control Protocol UDP: User Datagram Protocol

In fact, the reason that UNIX (kernel, etc.) is chosen is usually its networking application. FTP, POP, SMTP, and HTTP were originally implemented on UNIX and were used on UNIX. UNIX systems also implement functions by running services (often called daemons), including synchronizing with the central Clock (Network Time Protocol), exchanging news (Network News Transfer Protocol), resolving host names to IP addresses (DNS), and so on. A common part of the service can be found in/etc/services on most UNIX machines. This file is similar to Listing 1.
Listing 1 Common entries in the/etc/services (UNIX Network Services directory)

FTP 21/tcp FSP 21/udp fspd ssh 22/tcp ssh 22/udp telnet 23/tcp SMTP 25/tcp Mail

Each entry in/etc/services lists the name of the service, the port number used by the service and the Protocol (TCP or UDP), the alias for the service (possibly not, and possibly multiple aliases). Each system daemon checks the/etc/services to find the ports and protocols to use when it provides services.

For example, the daemon that handles inbound e-mail looks for "SMTP" (service name) or "Mail" (one of the aliases) and listens for incoming TCP connections on port 25. Similarly, the Telnet daemon searches for "ssh" in the file and listens for incoming TCP connections on port 22.

Ports and FSP According to the international Internet Address Allocation Committee (Internet assigned Numbers authority,iana), ports 22 and 25 are specification ports for Secure Shell (SSH) and SMTP respectively. System administrators can change these modest settings to other ports in each daemon's configuration file, which helps reduce the risk of attack. After all, if you can't find a service, you can't attack it. The File Service protocol (FSP) is an asynchronous file transfer protocol. Because it does not require a persistent connection, it supports parallel transmissions. However, FSP is rarely available on modern systems.

Simply put, TCP establishes a persistent connection between the two machines. In addition, TCP connections are reliable, meaning that two machines collaborate with each other to ensure data transmission. Conversely, UDP is unreliable, which means that the data may not reach its destination. The sender machine transmits the data and then it doesn't matter. You can think of a port number as a unique address. It sends traffic to a specific destination on a remote machine. If the machine's hostname is equivalent to a city block, the port number is equivalent to the street address.

If a machine is a central server for your company, or if you use only one server, the system may run 5, 10, or more daemons. For example, a small company's server may run multiple services that are responsible for synchronizing with the world clock, providing WEB pages, transmitting e-mail, supporting remote shell access, printing pages, transferring files, connecting to databases, monitoring system stability, providing domain names, and sharing files through NFS. This configuration is not uncommon, mainly because the daemon is not expensive. Daemons are usually designed to hibernate while Idle, waiting for a request. When a service request appears, the daemon wakes up, responds and processes the request, and then continues hibernation.

However, a large number of dormant processes can still affect system performance. Therefore, if a service is expected to be frequently requested, such as a stable Web access request, it is necessary to have a long-running daemon. Otherwise, it is a good idea to reconfigure the daemon to perform as needed.

However, how the system provides ready-to-use services and starts when needed. The solution is to use the proxy service, which forecasts the various requests that arrive and initiates the appropriate service based on the needs of subsequent processing. On UNIX and linux® systems, this proxy is called inetd.

Given a list of services, INETD monitors the requests for ports and protocols for these services. When an activity occurs, INETD maps inbound requests to standard input (stdin), standard output (stdout), and standard errors (stderr) and initiates the appropriate daemon. The service processes the data and terminates. Inetd keeps resource consumption to a minimum and makes the daemon easier to write. Figure 1 shows the difference between a system running multiple daemons but not running inetd and a system running inetd as an agent.
Figure 1. A system running multiple daemons, one running inetd, one not running inetd

In the upper part, each service runs as a separate, long-term process (that is, the daemon). Each daemon listens for inbound requests on specific ports and processes them. In the lower part, inetd listens on many ports and starts the service when a request is received. The service processes the request and exits. There are some service exceptions. For example, an SMTP server that transmits e-mail messages usually runs independently.

According to its role, inetd is often called "super Waiter". In recent years, inetd has been replaced by its variant xinetd. The use of the two software is the same, but the latter is more secure and provides many features that can restrict access when the system is overloaded. The configuration of inetd and xinetd is similar, but not exactly the same. The system can run inetd or xinetd, but it cannot run both. Because the latter is more secure, it is preferred, so use it later in this article.

Install XINETD on the system

Like many of the other software discussed in this column, xinetd is open source and easily built on variants such as UNIX and OpenBSD and Linux. By the end of October 2009, the latest version of XINETD is 2.3.14, which can be obtained from the XINETD homepage (see Resources). After downloading the xinetd source code, unzip the compressed file, run the configuration script (see Listing 2), and build the software. Be sure to back up the inetd configuration (if any) before installing XINETD, and then disable and/or delete inetd. The steps to disable inetd depend on the UNIX variant used; see the system's inetd man page. This modification is likely to require superuser access.
Listing 2. Installing XINETD

$ wget http://www.xinetd.org/xinetd-2.3.14.tar.gz $ tar xgz xinetd-2.3.14.tar.gz $ cd xinetd-2.3.14 $./ Configure checking build system type ... i686-pc-linux-gnu checking host system type ... I686-pc-linux-gnu Checking target system type ... i686-pc-linux-gnu ... $ make CD libs/src/portable, make cc= ' gcc ' cflags= '-g-o2- I.. /.. /include ' Install make[1]: Entering directory '/home/strike/tmp/xinetd-2.3.14/libs/src/portable ' gcc-g- O2- I.. /.. /include -c-o difftime.o difftime.c ... $ # Disable and/or remove inetd $ sudo make install

Similarly, the steps that enable xinetd to start each time the system reboots vary by system.

If your UNIX version has a package manager, you can also install xinetd directly from a pre-built binary package. For example, on Ubuntu Linux, you can disable inetd with one command and install and enable XINETD:

$ sudo apt-get install xinetd

In any case, if you have previously run inetd, you must convert the inetd profile inetd.conf to a xinetd-compatible file if you are installing and enabling xinetd. You can perform the conversion manually, or you can modify the file using the transformation script provided by xinetd:

$ xconv.pl </etc/inetd.conf >/etc/xinetd.conf $ mv/etc/inetd.conf/etc/inetd.conf.sav

xconv.pl is a Perl script provided by XINETD. The latter step (moving the inetd configuration file outside of the standard location) is only a precautionary measure.

XINETD can be configured entirely in/etc/xinetd.conf. However, it is customary to provide default settings in this file and to include multiple profiles in the special directory/ETC/XINETD.D-one file per service. For example, the following is the XINETD configuration file installed on Ubuntu:

Defaults { Log_type = SYSLOG daemon Info } includedir/etc/xinetd.d

Defaults provides values for all services controlled by XINETD. Services can override these global defaults. Here, the default value of Log_type specifies where each daemon should send log entries (if logging is enabled). The syslog option sends the output to the syslog (central system log). Info requires only informational messages to be logged. Other values include Emerg, alert, crit, err, warning, notice, and Debug. The first value Emerg produces the least output from the xinetd, and the last value, debug, provides the most verbose output. If you are having problems starting a service from XINETD, you can enable more detailed logging options to help you determine the cause of the problem.

The files in/etc/xinetd.d are in the same format as xinetd.conf. There is an operation that contains 0, one, or more operands, and a set of variables and values placed in braces ({}). For example, listing 3 is/etc/xinetd.d/imap, which is an entry for an IMAP service. (IMAP is the mailbox protocol used to read and manage e-mail messages.) It has an important advantage over POPs: IMAP mailboxes can remain synchronized across any number of systems. ）
Listing 3./etc/xinetd.d/imap

Service IMAP { Socket_type = Stream Protocol = tcp Wait = no user = root Only_from = 198.72.5.0 localhost banner =/usr/local/etc/deny_banner Server =/usr/local/ SBIN/IMAPD }

This is a common service configuration file. Let's take a look at the line: The first line specifies that this is a service and takes a name for the service. Socket_type describes how connections work, often stream (for TCP connections) or Dgram (for UDP services). The wait control xinetd whether to process one connection at a time (wait=yes) or multiple connections (wait=no) at a time. user specifies which users the daemon should run as. This user is often the root user (Superuser), but some services are best or must be run as the creator of the service. ONLY_FROM specifies which systems can make requests for this service. Here, only the 198.72.5 subnet system and local host are allowed to use IMAP services. The rightmost 0 is the wildcard character, and any system that allows IP address prefixes to 198.72.5 is requested to service. You can specify the system by using a variety of representations; see the Xinetd.conf man page for details. (Enter Man 5 xinetd.conf.) If access is blocked, the contents of the/usr/local/etc/deny_banner file are sent to the client. Finally, the server specifies an executable program that runs when access is allowed.

The service configuration may be very rich. Services can be provided only at specific times of the day (the Access_times option), or only when the load of the machine is below the threshold, as per the average load. You can also forward incoming service requests to another server (redirect option).

XINETD also supports the chroot option. The chroot option changes the root directory of the process. After the new root directory is set by chroot, files outside the root directory and its subdirectories are equivalent to non-existent. In other words, if you use Chroot to change the root directory to/tmp/fake_root, then the process will not be able to access all of the file system resources outside of/tmp/fake_root. Chroot can separate the resources that the service can access from the rest of the system. For example, you can run the FTP service under chroot so that no one will be able to access files outside of the new root directory. (This is actually the best practice for FTP.) ）

Running the service under XINETD

To demonstrate how XINETD transforms an application into a daemon, we write a Ruby script that returns the index of the text file it can access. This script is shown in Listing 4.
Listing 4. Ruby script to generate a text file index

#! /usr/bin/env Ruby txtfiles = File.join ("/tmp/xinetd/", "* *", "*.txt") Dir.glob (txtfiles). Each do |filename|< C4/>puts "#{filename}" end

A new service must be enabled in accordance with the following rules: Select an unused port of more than 1024 for the service. (Port 1-1024 is reserved for super users.) To edit the service directory/etc/services as a superuser, add the name, port, and protocol of the service. For example, you can add the entry find 11000/tcp, which means that the Ruby script runs on port 11000 and uses the TCP protocol. Create an entry for the service in/ETC/XINETD.D. The entries for Ruby scripts can be as follows:

Service Find { Socket_type = Stream Protocol = tcp User = Martin Wait = No server =/tmp/xinetd/find.rb log_type = SYSLOG daemon Debug }

Although there are some minor differences, this fragment should look familiar. This script runs as a user, Martin, because it does not require special privileges. In general, you should provide as few privileges as possible-not just here, but in terms of granting access to any system resources. For TCP protocol services, you must set up Wait=no. The server points to a script or executable program to run, Log_type specifies a higher logging level, which helps resolve any problems in the service. Restart the xinetd, or send a reset signal to its process. To restart xinetd, you should look for a control script where/ETC/INIT.D or the system saves the startup script. Run the following command:

$ sudo/etc/init.d/xinetd Restart

Another way is to send a reset signal to the xinetd daemon. The signal Sighup lets xinetd re-read its configuration and may close the connection based on the new parameters. The commands used are:

$ sudo pkill-sighup xinetd

If the system has no pkill (it looks for process IDs based on the process name), then use PS aux | The grep xinetd looks for the process number and then uses the sudo kill-sighup pid, where the PID is the process ID.

To test the new service, create a directory named/TMP/XINETD, create a Ruby script and save it in/TMP/XINETD/FIND.RB. Use chmod +x/tmp/xinetd/find.rb to set this file to executable. Next, create some directories and text files:

$ mkdir a b C $ touch a/d.txt b/e.txt

You can now test the new service. When an inbound connection appears on port 11000, XINETD launches the Ruby script. Any script output sent to the standard output is sent to the standard output on the machine that makes the request. This script does not require input, but if necessary, the standard input on the requesting machine is passed to the script. Telnet provides an easy way to connect to any service:

$ telnet localhost 11000 trying 127.0.0.1 ... Connected to localhost. Escape character is ' ^] '. /tmp/xinetd/b/e.txt /tmp/xinetd/a/d.txt Connection closed by foreign host.

It worked. The port is open, the control is passed to the script, and the script generates the expected output.

More reasons to run xinetd

XINETD has many advantages. It can save resources by running the daemon only when it is needed. It provides an additional layer of security that allows the service to be isolated in a directory by "Modifying the root directory". Most importantly, it can actually convert any script or program into a service. But be aware that if your service is very popular, you should consider rewriting it in efficient languages such as C. The faster you process the request, the better the performance.