Softpanorama (slightly skeptical) Open Source Software Educational Society

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

Solaris Inetd Services

Lecture Notes

• 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

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.

Recommended Links

inetd Daemon

• inetd.conf File Format for TCP/IP

inetd Daemon

Chapter 11: inetd: the Internet super server

Configuring the Internet Daemon, inetd

xinetd

• 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.

Last modified: February 28, 2008