Inetd

Last updated

inetd (internet service daemon) is a super-server daemon on many Unix systems that provides Internet services. For each configured service, it listens for requests from connecting clients. Requests are served by spawning a process which runs the appropriate executable, but simple services such as echo are served by inetd itself. External executables, which are run on request, can be single- or multi-threaded. First appearing in 4.3BSD, [1] it is generally located at /usr/sbin/inetd. inetd is based on the (service) activator pattern [2]

Contents

Function

Often called a super-server, inetd listens on designated ports used by Internet services such as FTP, POP3, and telnet. When a TCP packet or UDP packet arrives with a particular destination port number, inetd launches the appropriate server program to handle the connection. For services that are not expected to run with high loads, this method uses memory more efficiently, since the specific servers run only when needed. Furthermore, in inetd's "nowait" mode of service management, no network code is required in the service-specific programs, as inetd hooks the network stream directly to stdin and stdout of the spawned process. For protocols that have frequent traffic, such as HTTP and POP3, either inetd's "wait" mode of operation, or a dedicated server that intercepts the traffic directly may be preferable.

Setup


The list of services that will be serviced is given in a configuration file, usually /etc/inetd.conf. A GUI for managing the configuration file is an optional accessory. The daemon may need a signal in order to re-read its configuration. For an example, telnet can be configured as follows (line taken from a machine running AIX version 5.1):

telnet  stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a

The first word, telnet, is the official name of the service. It is resolved using the system database to map port numbers and protocols to service names. In this case, /etc/services should contain:

telnet          23/tcp

The second and third words describe the type of socket and underlying protocol respectively. The /etc/protocols database is consulted.

The fourth word is the wait/nowait switch. A single-threaded server expects inetd to wait until it finishes reading all the data. Otherwise inetd lets the server run and spawns new, concurrent processes for new requests.

The fifth word is the user name, from the /etc/passwd database, that the service program should run as.

Finally, the path and the arguments of an external program are given. As usual, the first argument is the program name. In the example, inetd is told to launch the program /usr/sbin/telnetd with the command line arguments telnetd -a. inetd automatically hooks the socket to stdin, stdout, and stderr of the server program.

Generally TCP sockets are handled by spawning a separate server to handle each connection concurrently. UDP sockets are generally handled by a single server instance that handles all packets on that port.

Some simple services, such as echo, are handled directly by inetd, without spawning an external server.

Creating an inetd service

This is a simple inetd service, written in C. It expects a command line argument containing a filename for a log file, and then it logs all strings sent through the socket to the log file. Note that this is a very insecure example program.

#include<stdio.h>#include<stdlib.h>intmain(intargc,char**argv){constchar*fn=argv[1];FILE*fp=fopen(fn,"a+");if(fp==NULL)exit(EXIT_FAILURE);charstr[4096];/* inetd passes its information to us in stdin. */while(fgets(str,sizeofstr,stdin)){fputs(str,fp);fflush(fp);}fclose(fp);return0;}

The example uses stdio functions and it responds to network traffic coming in on stdin. In this case, we want all messages logged to a single file, so we only want one instance of the service running to service all requests. This means UDP is the correct protocol to use. First, an unused port number must be selected. In this sample, 9999 will be used. The /etc/services entry will look like this:

errorLogger 9999/udp

And the entry in /etc/inetd.conf will look like this:

errorLogger dgram udp wait root /usr/local/bin/errlogd errlogd /tmp/logfile.txt

This tells inetd to run the /usr/local/bin/errlogd program, with the commandline: errlogd /tmp/logfile.txt (refer to the inetd.conf man page for information on the other arguments). The first argument contains the filename to be used for the log file: /tmp/logfile.txt. inetd will run the service when needed, and attach port 9999 to the input and output streams, and all strings sent to that port will be logged to the file. By specifying wait, it tells inetd to only use one instance of the server to handle all requests.

Note: the functionality of the above example is usually implemented by using syslog and a process like syslogd. syslogd would normally be started in parallel with inetd, not as an inetd service.

inetd replacements

In recent years, because of the security limitations in the original design of inetd, it has been replaced by xinetd, rlinetd, ucspi-tcp, and others in many systems. Distributions of Linux especially have many options and Mac OS X (beginning with Mac OS X v10.2) uses xinetd. As of version Mac OS X v10.4, Apple has merged the functionality of inetd into launchd.

The services provided by inetd can be omitted entirely. This is becoming more common where machines are dedicated to a single function. For example, an HTTP server could be configured to just run httpd and have no other ports open. A dedicated firewall could have no services started.

systemd supports inetd services, and expands socket activation beyond IP messaging (AF INET+6) to include AF UNIX, AF NETLINK and more. [3] [4]

Security

While the inetd concept as a service dispatcher is not inherently insecure, the long list of services that inetd traditionally provided gave computer security experts pause. The possibility of a service having an exploitable flaw, or the service just being abused, had to be considered. Unnecessary services being disabled and "off by default" became the mantra. It is not uncommon to find an /etc/inetd.conf with almost all the services commented out in a modern Unix distribution.

See also

Related Research Articles

A Berkeley (BSD) socket is an application programming interface (API) for Internet domain sockets and Unix domain sockets, used for inter-process communication (IPC). It is commonly implemented as a library of linkable modules. It originated with the 4.2BSD Unix operating system, which was released in 1983.

In computing, the Windows Sockets API (WSA), later shortened to Winsock, is an application programming interface (API) that defines how Windows network application software should access network services, especially TCP/IP. It defines a standard interface between a Windows TCP/IP client application and the underlying TCP/IP protocol stack. The nomenclature is based on the Berkeley sockets API used in BSD for communications between programs.

DICT is a dictionary network protocol created by the DICT Development Group in 1997, described by RFC 2229. Its goal is to surpass the Webster protocol to allow clients to access a variety of dictionaries via a uniform interface.

Terminal Access Controller Access-Control System refers to a family of related protocols handling remote authentication and related services for network access control through a centralized server. The original TACACS protocol, which dates back to 1984, was used for communicating with an authentication server, common in older UNIX networks including but not limited to the ARPANET, MILNET and BBNNET. It spawned related protocols:

The Berkeley r-commands are a suite of computer programs designed to enable users of one Unix system to log in or issue commands to another Unix computer via TCP/IP computer network. The r-commands were developed in 1982 by the Computer Systems Research Group at the University of California, Berkeley, based on an early implementation of TCP/IP.

In computer networking, a network service is an application running at the network application layer and above, that provides data storage, manipulation, presentation, communication or other capability which is often implemented using a client–server or peer-to-peer architecture based on application layer network protocols.

TCP Wrappers is a host-based networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) operating systems such as Linux or BSD. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes.

netstat Command line network statistics tool

In computing, netstat is a command-line network utility that displays open network sockets, routing tables, and a number of network interface and network protocol statistics. It is available on Unix, Plan 9, Inferno, and Unix-like operating systems including macOS, Linux, Solaris and BSD. It is also available on IBM OS/2 and on Microsoft Windows NT-based operating systems including Windows XP, Windows Vista, Windows 7, Windows 8 and Windows 10.

netcat Computer networking utility

netcat is a computer networking utility for reading from and writing to network connections using TCP or UDP. The command is designed to be a dependable back-end that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and investigation tool, since it can produce almost any kind of connection its user could need and has a number of built-in capabilities.

<span class="mw-page-title-main">Terminal server</span> Device that interfaces serial hosts to a network

A terminal server connects devices with a serial port to a local area network (LAN). Products marketed as terminal servers can be very simple devices that do not offer any security functionality, such as data encryption and user authentication. The primary application scenario is to enable serial devices to access network server applications, or vice versa, where security of the data on the LAN is not generally an issue. There are also many terminal servers on the market that have highly advanced security functionality to ensure that only qualified personnel can access various servers and that any data that is transmitted across the LAN, or over the Internet, is encrypted. Usually, companies that need a terminal server with these advanced functions want to remotely control, monitor, diagnose and troubleshoot equipment over a telecommunications network.

The Discard Protocol is a service in the Internet Protocol Suite defined in 1983 in RFC 863 by Jon Postel. It was designed for testing, debugging, measurement, and host-management purposes.

The Echo Protocol is a service in the Internet Protocol Suite defined in 1983 in RFC 862 by Jon Postel. It was originally proposed as a way to test and measure an IP network.

The Daytime Protocol is a service in the Internet Protocol Suite, defined in 1983 in RFC 867 by Jon Postel. It is intended for testing and measurement purposes in computer networks.

The Time Protocol is a network protocol in the Internet Protocol Suite. Its purpose is to provide a site-independent, machine readable date and time.

The Character Generator Protocol (CHARGEN) is a service of the Internet Protocol Suite defined in RFC 864 in 1983 by Jon Postel. It is intended for testing, debugging, and measurement purposes. The protocol is rarely used, as its design flaws allow for ready misuse.

In computer networking, xinetd is an open-source super-server daemon which runs on many Unix-like systems, and manages Internet-based connectivity.

A network socket is a software structure within a network node of a computer network that serves as an endpoint for sending and receiving data across the network. The structure and properties of a socket are defined by an application programming interface (API) for the networking architecture. Sockets are created only during the lifetime of a process of an application running in the node.

In client-server computing, a Unix domain socket is a Berkeley socket that allows data to be exchanged between two processes executing on the same Unix or Unix-like host computer. This is similar to an Internet domain socket that allows data to be exchanged between two processes executing on different host computers.

In computer networking, a port or port number is a number assigned to uniquely identify a connection endpoint and to direct data to a specific service. At the software level, within an operating system, a port is a logical construct that identifies a specific process or a type of network service. A port at the software level is identified for each transport protocol and address combination by the port number assigned to it. The most common transport protocols that use port numbers are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP); those port numbers are 16-bit unsigned numbers.

References

  1. inetd(8)    FreeBSD System Manager's Manual
  2. Lecture 21: Android Services and Local IPC (part 17), 4 November 2013, retrieved 2023-10-23
  3. "Systemd for Developers I".
  4. "Rethinking PID 1".