Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Solaris Inetd Services

Lecture Notes

• Introduction
• Starting and stopping services
• Internet Service Daemon (inetd)
• Services Network Ports: Well known and Ephemeral Ports
• Starting Services for Well-known Ports
  • Starting Well-Known Port Services Startup Scripts
  • Starting Well-Known Port Services on Demand using Inetd
• Inetd Enhancements and Replacements

Introduction

Originally, BSD Unix set a different server program running for every network service. As the number of services grew in the mid 1980s, Unix systems started having more and more server programs sleeping in the background, waiting for network connections. Although the servers were sleeping, they nevertheless consumed valuable system resources such as process table entries and swap space. Perhaps more importantly, configuring these servers was somewhat difficult, as each server was started up in a different way and had a different syntax for defining which port they should bind to and which UID they should use when running.

Today's Unix systems use the Internet daemon, inetd (or xinetd), to centralize the handling of lightweight Internet services. The inetd daemon listens and accepts connections on many network ports at the same time. When a connection is received, inetd starts up the appropriate TCP-based or UDP-based server running under the appropriate UID. The Internet daemon also simplifies the writing of application-specific daemons themselves, as each daemon can be written so that it reads from the network on standard input and writes back to the network on standard output—no special calls from the Berkeley socket library are required.

Note: Linux use an alternative Internet daemon called xinetd. Instead of locating all of its configuration in a single inetd.conf file, xinetd typically requires a separate configuration file for each service in the directory /etc/xinetd.d.

inetd uses the bind( ) call to attach itself to many network ports and then uses the select( ) call to determine which of these ports is the one that has received a connection.

The inetd daemon is run at boot time as part of the startup procedure. When inetd starts executing, it examines the contents of the /etc/inetd.conf file to determine which network services it is supposed to manage. The program will reread its configuration file if it is sent a HUP signal

A sample inetd.conf file

# Internet server configuration database
#
ftp       stream tcp nowait root    /usr/sbin/ftpd ftpd
#telnet   stream tcp nowait root    /usr/sbin/telnetd telnetd
#shell    stream tcp nowait root    /usr/sbin/rshd rshd
#login    stream tcp nowait root    /usr/sbin/rlogind rlogind
#exec     stream tcp nowait root    /usr/sbin/rexecd rexecd
#uucp     stream tcp nowait uucp    /usr/sbin/uucpd uucpd
#finger   stream tcp nowait nobody  /usr/sbin/fingerd fingerd
#tftp     dgram  udp wait   nobody  /usr/sbin/tftpd tftpd
#comsat   dgram  udp wait   root    /usr/sbin/comsat comsat
talk      dgram  udp wait   root    /usr/sbin/talkd talkd
ntalk     dgram  udp wait   root    /usr/sbin/ntalkd ntalkd
#echo     stream tcp nowait root    internal
#discard  stream tcp nowait root    internal
#chargen  stream tcp nowait root    internal
#daytime  stream tcp nowait root    internal
#time     stream tcp nowait root    internal
#echo     dgram  udp wait   root    internal
#discard  dgram  udp wait   root    internal
#chargen  dgram  udp wait   root    internal
#daytime  dgram  udp wait   root    internal
#time     dgram  udp wait   root    internal

Each line of the inetd.conf file contains at least six fields, separated by spaces or tabs:

Service name

Specifies the service name that appears in the /etc/services file. inetd uses this name to determine which port number it should listen to. If you are testing a new service or developing your own daemon, you may wish to put that daemon on a nonstandard port. Unfortunately, inetd requires that the service name be a symbolic value such as smtp, rather than a numeric value such as 25.

Socket type

Indicates whether the service expects to communicate via a stream or on a datagram basis.

Protocol type

Indicates whether the service expects to use TCP- or UDP-based communications. TCP is used with stream sockets, while UDP is used with dgram, or datagrams.

Wait/nowait

If the entry is "wait," the server is expected to process all subsequent connections received on the socket. If "nowait" is specified, inetd will fork( ) and exec( ) a new server process for each additional datagram or connection request received. Most UDP services are "wait," while most TCP services are "nowait," although this is not a firm rule. Although some manpages indicate that this field is used only with datagram sockets, the field is actually interpreted for all services.

User

Specifies the UID that the server process will be run as. This can be root (UID 0), daemon (UID 1), nobody (often UID -2 or 65534), or any other user of your system. This field allows server processes to be run with fewer permissions than root to minimize the damage that could be done if a security hole is discovered in a server program.

Command name and arguments

The remaining arguments specify the command name to execute and the arguments passed to the command, starting with argv[0].

Some services, like echo, time, and discard, are listed as "internal." These services are so trivial that they are handled internally by inetd rather than requiring a special program to be run. Although these services are useful for testing, they can also be used for denial of service attacks. You should therefore disable them.

You should routinely check the entries in the /etc/inetd.conf file and verify that you understand why each of the services in the file is being offered to the Internet. Sometimes, when attackers break into systems, they create new services to make future break-ins easier. If you cannot explain why a service is being offered at your site, you may wish to disable it until you know what purpose it serves. In many circumstances, it is better to disable a service that you are not sure about than it is to leave it enabled in an effort to find out who is using it at a later point in time: if somebody is using the service, they are sure to let you know! One easy way to list all of the services that are enabled is:

% grep -v "^#" /etc/inetd.conf
talk    dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.ntalkd
pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd popper -c -C -p 2
auth    stream  tcp     nowait  nobody  /usr/sbin/tcpd identd -o -E -i

Because of the importance of the /etc/inetd.conf file, you may wish to track changes to this file using a source code control system such as RCS or CVS. You may also wish to use a consistency-checking tool such as Tripwire or detached PGP signatures to verify that all changes to the file are authorized and properly recorded.

The client-server model describes network services and the client programs of those services. One example of the client-server relationship is the name server and resolver model of the DNS. Another example of the client and server relationship is the NFS.

• The client is a host or a process that uses services from another program, known as a server. You can apply the client-server relationship to computer programs within a single computer or use the relationship across a network to make one application server a host to one or more application clients. Examples of clients in the Solaris 9 OE are:

  • For name services, a client is a host system that uses either the NIS+, NIS, DNS, or LDAP name service lookup provided by the name service server.
  • In file systems, the client is a system that remotely accesses the resources of a storage server, such as a server with large disk and network capacity.
  • For applications, such as sendmail or calendar manager, the client accesses services from a server process.
     
• The server is a host or a process that provides services to another program(client). Client-server computing is a key factor in supporting network computing. The client-server model on the network can be multilayered.  The storage clients rely on the storage server to access their data. Conversely, one of the storage clients, such as a printer host, can be configured to act as the interface for network printers. To perform print operations from the storage host, the storage host must assume a print client role when communicating with the print server role of the printer host.

  Examples of servers in the Solaris 9 OE are:

  • A host system providing name services to a network in NIS+, NIS, DNS, and LDAP.
  • A host system providing disk space to the network, such as a server with large disk and network capacity.
  • A host system providing windowing services to applications. The client and the server can run on the same system or on separate systems.
  • A host system providing web services to client systems.

Starting and stopping services

To start services for server processes, you must know which files to use for automatic service configuration. You must also know how to manually start the services.

There are two ways of starting services: via inetd and via RC files

 Internet Service Daemon (inetd)

The inetd daemon is a special network process that runs on each system and starts server processes that do not automatically start at boot time. The inetd daemon is the server process for both the standard Internet services and Sun Remote Procedure Call (Sun RPC) services. The inetd daemon starts at boot time using the /etc/rc2.d/S72inetsvc script. A configuration file lists the services that the inetd daemon will listen for and start in response to network requests. If you do not specify a configuration file, the inetd daemon uses the default /etc/inet/inetd.conf file.

1. To get the list of services that the inetd daemon listens for,  perform the command:

   # cat /etc/inet/inetd.conf
   .
   .(output truncated)
   .
   # TELNETD - telnet server daemon
   telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
   # smserverd to support removable media devices
   100155/1 tli rpc/ticotsord wait root
   /usr/lib/smedia/rpc.smserverd rpc.smserverd
   # REXD - rexd server provides only minimal authentication
   #rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd rpc.rexd
   # FTPD - FTP server daemon
   ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -a
   .
   .(output truncated)
   .

2. When the inetd daemon receives a network request, it runs the associated command in the inetd.conf file.
    
3. Structure of inetd.conf file Each entry is a single line in the following form:

   service-name endpoint-type protocol wait-status uid server-program \ server-arguments

   • service-name The name of a valid service listed in the /etc/services file.
   • endpoint-type The value can be one of the following:
     • stream for a stream socket
     • dgram for a datagram socket
     • raw for a raw socket
     • seqpacket for a sequenced packet socket
     • tli for all TLI endpoints protocol
   • A recognized protocol listed in the /etc/inet/protocols file. For servers that support the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) over the Internet Protocol Version 6  (IPv6) address, the tcp6 and udp6 protocol types are also recognized but are not listed in the /etc/inet/protocols file.
   • wait-status This field has values wait or nowait. The wait keyword is usually associated with UDP servers and informs the inetd daemon that it should not listen for additional incoming requests for this service until the current server exits. The nowait keyword is usually associated with TCP servers and indicates that the inetd daemon continues to listen for incoming requests even while the current server is running.
   • uid The user ID under which the server should run. server-program The path name of a server program that the inetd daemon invokes to provide a requested service, or the value internal if the inetd daemon itself provides the service.
   • server-To invoke a server with command-line arguments, the entire arguments command line (including the command itself) must appear in this field (which consists of all remaining words in the entry).

Notes

• By specifying a protocol value of tcp6 or udp6 for a service, the inetd daemon passes the given daemon an AF_INET6 socket.
• The following daemons have been modified to accept AF_INET6 sockets and service connection requests coming from either IPv4 or IPv6-based transports: ftp, telnet, shell, login, exec, tftp, finger, and printer.
• Modified services do not usually require separate configuration lines for tcp or udp.

The inetd daemon starts a server process when it receives an appropriate service request. The in.ftpd server process can be invoked by the inetd daemon each time a connection to the File Transfer Protocol (FTP) service is requested as shown in the following example:

# grep ftp /etc/inet/inetd.conf
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -a

When changing the /etc/inet/inetd.conf file, send a hang-up (HUP) signal to the inetd process to force it to reread the configuration file:

# pkill -HUP inetd

Note – To turn off a service, add a # symbol to the beginning of the line corresponding to that service in the /etc/inetd.conf file, and send a HUP request.

Services Network Ports: Well known and Ephemeral Ports

Network ports help transport protocols distinguish between multiple service requests arriving at a given host computer. The TCP and UDP transport protocols identify ports using a positive integer between 1 and 65535, which is called a port number.

Network ports can be divided into two categories:

• well-known ports. Well-known ports are stored in the /etc/inet/services file. To view the well-known port that the telnet service uses, perform the command:

  # grep telnet /etc/inet/services
  telnet 23/tcp

  This example shows that the telnet service uses well-known port 23 and uses the TCP protocol.

• ephemeral (short-lived) ports.

Port Numbers There are two fundamental approaches to port assignments:

• . Central authority:
  • All users must agree to allow the central authority to assign all port numbers.
  •  The central authority is responsible for publishing the list of port number assignments, called well-known port assignments.
  •  Well-known port assignments dictate software requirements on a system.
•  Dynamic binding:
  •  The ports are unknown to the client in advance. The system software dynamically assigns ports to the programs that require them.
  •  To obtain the current port assignments on any computer, the software generates a request to the target machine for the port number information. The target machine then responds with the port number.
  •  These port number assignments are considered ephemeral since assignments are short lived, only lasting until the system is rebooted.

Starting Services for Well-known Ports

Each network service uses a port that represents an address space reserved for that service. If a port number is not pre-assigned, the operating system allows an application to choose an unused port number. A client often communicates with a server through a well-known port.  The list of services that use a well-known port includes:

• Services that start using start-up scripts (R-scripts) at system boot time
• Services that do not start automatically at boot, and must start on demand

Starting Well-Known Port Services Startup Scripts

One of the well-known port services that starts at boot time is the sendmail process. The sendmail process uses well-known port 25 to perform network services for email using the Simple Mail Transport Protocol (SMTP). You can confirm that the name has been translated to the port number by searching for the mail entry in the /etc/inet/services file. To confirm the translation, perform the command: 

# grep mail /etc/inet/services
smtp 25/tcp mail

The sendmail process is initialized by the startup script /etc/rc2.d/S88sendmail when you boot the Solaris 9 OE. Because the sendmail process uses port 25, the sendmail process starts listening at  port 25 for incoming mail activity soon after start up. There is no need for the inetd daemon to listen at port 25 for incoming sendmail requests or to start sendmail, because the sendmail process is already running.

Starting Well-Known Port Services on Demand using Inetd

The telnet service is a well-known port service that does not automatically start at boot time. For example the telnet service uses port 23. At the same time this services is used only episodically and it makes sense to run it only when there is a request to save memory. The inetd daemon can listen for telnet requests, so that the telnet service does not have to continually run on the system. When the inetd daemon  receives a network request at a port, it uses the information listed in the /etc/inet/service file to determine which service to start and if this is a telnet connection starts telnet daemon.

Here is a typical scenario that involves two system alisa and bill with alisa trying to connect to bill using telnet service:

1. The initiating host alisa executes telnet bill command.
2. The telnet service is a well-known service. The port for this service is port 23.
3. The telnet packet requesting a connection goes to port 23 on the host bill.
4. Initially, the inetd daemon listens at port 23 for the telnet service. The telnet bill command on alisa  generates a request to port 23 that inetd recognizes as a telnet request because of the configuration entry in the /etc/inet/services file (it associates ports and services for inetd).
5. The telnet service does not continuously run on a system waiting for a connection. The inetd daemon must start the telnet service dynamically on demand.
6. The inetd daemon consults the /etc/inetd.conf file to find a matching entry for the requested service. The inetd daemon  identifies the telnet service line.
7. The inetd daemon executes the in.telnetd process from the /etc/inetd.conf file. The in.telnetd daemon takes control of the current telnet session’s communication.
8. The in.telnetd daemon receives this session’s traffic and runs on port 23 until this telnet session ends.

Note – The inetd daemon continues to listen for new service requests.

Inetd Enhancements and Replacements

One typical enhancement of indet that provides better security is TCP Wrappers. the idea of TCP Warappers is realy simple: to screen the connection based on the rules contained in certain files (hosts.allow, host.deny) and based onthis screening to grant of deny request.  If the request is allowed, then the the corresponding server process (e.g ftp) can be started. This mechanism is also referred to as tcp_wrapper. Solaris 9 can be installed with TCP wrappers in the default installation. And TCP Wrappers are standard in Solaris 10.

There is also a  replacement for inetd, called xinetd that includes built-in TCP wrapper functionality. Like combination of  inetd+tcpd, it enables the configuration of the access rights for a given machine, but it can do more:

• access control based on time segments
• full logging both for connection success or failure
• some level of containment against Denial of Services (DoS) attacks (attacks which attempt to freeze a machine by saturating its resources) :
  • limitation on the number of servers of the same type to run at a time
  • limitation on the total number of servers
  • limitation on the size of the log files.
• binding of a service to a specific interface: this allows you, for instance, to make services available to your private network but not to the outside world.
• can be used as a proxy to other systems.

 It is often used in Linux distributions, but not in Solaris.

• Frederic Raynal has written an excellent article on xinetd.
• Curator has written a tutorial on the use of xinetd here.
• xinetd has a mailing list. More information on xinetd mailing lists can be found here.

Old News ;-)

A Simple Socket Server Using 'inetd'

Perl code for simple server and client.

24.9. When to use or not to use inetd

The decision to add or move a service into or out of inetd(8) is usually based on server load. As an example, on most systems the telnet daemon does not require as many new connections as say a mail server. Most of the time the administrator has to feel out if a service should be moved.

A good example I have seen is mail services such as smtp and pop. I had setup a mail server in which pop3 was in inetd(8) and exim was running in standalone, I mistakenly assumed it would run fine since there was a low amount of users, namely myself and a diagnostic account. The server was also setup to act as a backup MX and relay in case another heavily used one went down. When I ran some tests I discovered a huge time lag for pop connections remotely. This was because of my steady fetching of mail and the diagnostic user constantly mailing diagnostics back and forth. In the end I had to move the pop3 service out of inetd(8).

The reason for moving the service is actually quite interesting. When a particular service becomes heavily used, of course, it causes a load on the system. In the case of a service that runs within the inetd(8) meta daemon the effects of a heavily loaded service can also harm other services that use inetd(8). If the multiplexor is getting too many requests for one particular service, it will begin to affect the performance of other services that use inetd(8). The fix, in a situation like that, is to make the offending service run outside of inetd(8) so the response time of both the service and inetd(8) will increase.

Chapter 24. The Internet Super Server inetd

Another reason to use inetd is that you can use TCP-wrappers with it.  Mail daemons are usually complied with TCP-wrappers library support but this is not true for other daemons.

24.9. When to use or not to use inetd

The decision to add or move a service into or out of inetd(8) is usually based on server load. As an example, on most systems the telnet daemon does not require as many new connections as say a mail server. Most of the time the administrator has to feel out if a service should be moved.

A good example I have seen is mail services such as smtp and pop. I had setup a mail server in which pop3 was in inetd(8) and exim was running in standalone, I mistakenly assumed it would run fine since there was a low amount of users, namely myself and a diagnostic account. The server was also setup to act as a backup MX and relay in case another heavily used one went down. When I ran some tests I discovered a huge time lag for pop connections remotely. This was because of my steady fetching of mail and the diagnostic user constantly mailing diagnostics back and forth. In the end I had to move the pop3 service out of inetd(8).

The reason for moving the service is actually quite interesting. When a particular service becomes heavily used, of course, it causes a load on the system. In the case of a service that runs within the inetd(8) meta daemon the effects of a heavily loaded service can also harm other services that use inetd(8). If the multiplexor is getting too many requests for one particular service, it will begin to affect the performance of other services that use inetd(8). The fix, in a situation like that, is to make the offending service run outside of inetd(8) so the response time of both the service and inetd(8) will increase.

The inetd - -etc-inetd.conf file from Securing and Optimizing Linux  by Gerhard Mourani

Old Red Hat inetd configuration is like Solaris.

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

inetd - Wikipedia, the free encyclopedia

The inetd Super-Server FreeBSD page where the idea originated. BTW daytime, time, echo, discard, chargen, and auth are all internally provided services of inetd.

inetd Daemon

• inetd.conf File Format for TCP/IP

inetd Daemon