TCP/IP Services and Client/Server Architecture

Socket Definition

Network applications use sockets to communicate over a TCP/IP network. A socket is an abstraction that represents an endpoint of a connection. Because a socket is bidirectional, data can be sent as well as received through it. A socket has three attributes:

• The network address (the IP address) of the system

• The port number identifying the process (a process is a computer program running on a computer) that exchanges data through the socket

• The type of socket (such as stream or datagram) identifying the protocol for data exchange

Essentially, the IP address identifies a network node, the port number identifies a process on the node, and the socket type determines the manner in which data is exchanged—through a connection-oriented or connectionless protocol.

Connection-Oriented Protocols

The socket type indicates the protocol being used to communicate through the socket. A connection-oriented protocol works like a normal phone conversation. When you want to talk to your friend, you have to dial your friend’s phone number and establish a connection before you can have a conversation. In the same way, connection-oriented data exchange requires both the sending and receiving processes to establish a connection before data exchange can begin.

As the name TCP/IP suggests (and as the “Network Protocols” section indicates), TCP relies on IP—Internet Protocol—for delivery of packets. IP does not guarantee delivery of packets, nor does it deliver packets in any particular sequence. IP does, however, efficiently deliver packets from one network to another. TCP is responsible for arranging the packets in the proper sequence, detecting whether or not errors have occurred, and requesting retransmission of packets in the case of an error.

TCP is useful for applications that plan to exchange large amounts of data at a time. In addition, applications that need reliable data exchange use TCP. For example, FTP uses TCP to transfer files.

In the sockets model, a socket that uses TCP is referred to as a stream socket because TCP provides an illusion of a continuous stream of data.

Connectionless Protocols

A connectionless data-exchange protocol does not require the sender and receiver to explicitly establish a connection. It’s like shouting to your friend in a crowded room—you can’t be sure if your friend hears you, and if you can’t tell whether or not he or she heard you, after a certain amount of time, you shout again to see if he or she hears you.

UDP is used by applications that exchange small amounts of data at a time or by applications that do not need the reliability and sequencing of data delivery. For example, SNMP (Simple Network Management Protocol) uses UDP to transfer data. UDP is generally used by applications where each message is largely self-contained so that even if some of the messages don’t get through, it’s not critical.

In the sockets model, a socket that uses UDP is referred to as a datagram socket.

Sockets and the Client/Server Model

It takes two sockets to complete a communication path. When two processes communicate, they use the client/server model to establish the connection. The server application listens on a specific port on the system—the server is completely identified by the IP address of the system where it runs and the port number where it listens for connections. The client initiates connection from any available port and tries to connect to the server (identified by the IP address and port number). Once the connection is established, the client and the server can exchange data according to their own protocol.

The sequence of events in sockets-based data exchanges depends on whether the transfer is connection oriented (TCP) or connectionless (UDP).

Learning How xinetd Works

The xinetd server is designed to monitor the ports for the services it is configured to start. When a client requests connection to one of the monitored ports, xinetd starts the corresponding server. The client then directly communicates with that server while xinetd goes on to listening to the ports again. For example, when a client tries to connect to the Telnet port, xinetd starts the Telnet server and lets it communicate directly with the client (and the Telnet server exits when the client disconnects). xinetd also logs the connection requests in a log file based on settings in its configuration file.

Secret

The xinetd server is known as the Internet superserver because it starts various servers on demand. Typically, a Red Hat Linux system starts xinetd when the system boots. The xinetd server reads a configuration file named /etc/xinetd.conf at startup. This file tells xinetd which ports to listen to and what server to start for each port. The file can contain instructions that include other configuration files. In Red Hat Linux, the /etc/xinetd.conf file looks like the following:

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

Comment lines begin with the pound sign (#). The defaults block, enclosed in curly braces ({...}) specifies default values for some attributes. These default values apply to all other services that xinetd is set up to start. The instances attribute is set to 60, which means there can be, at most, 60 servers simultaneously active for any service. The other attributes have the following meanings:

• The log_type attribute specifies how xinetd should log error or status information. In this case the log_type is SYSLOG authpriv, which means that xinetd will use the SYSLOG facility’s authpriv log. The /etc/syslog.conf file defines the authpriv log as the file /var/log/secure. This means that the /var/log/secure file contains the logs for services started by xinetd.

• The log_on_success attribute tells xinetd what information to log when a server is started and when the server exits. In this case, the attribute is set to HOST and PID. The result is that if the startup of a service such as Telnet is successful, then xinetd logs the name of the remote host that has requested the service and the process ID of the Telnet server (that it starts). This setting for the log_on_success attribute results in entries in the /var/log/secure file of the following form:

      Feb  1 13:52:57 dhcppc7 xinetd[2241]: START: telnet pid=2627      from=192.168.0.4

• The log_on_failure attribute tells xinetd what information to log when it cannot start a server. In this case, the attribute is set to HOST, which means that if xinetd cannot start a service such as Telnet, it logs the name of the remote host that requested the service.

• The cps = 25 30 line tells xinetd to allow no more than 25 connections per second to a given service. If this limit is reached, the service is turned off for 30 seconds. Placing a limit such as this protects your system against denial of service attacks that attempts to overwhelm the system by requesting too many connections.

  The last line in the /etc/xinetd.conf file uses the includedir directive to include all files inside the /etc/xinetd.d directory, excluding files whose names begin with a period (.). The idea is that the /etc/xinetd.d directory would contain all service configuration files—one file for each type of service the xinetd server is expected to manage. You should study the files in /etc/xinetd.d directory to see what services xinetd can start and how each service is configured. You can enable or disable a service by editing that service’s configuration file in /etc/xinetd.d (you can also perform this task through the chkconfig command, as described in Chapter 22).

Here is the listing of files in the /etc/xinetd.d directory on a typical Red Hat Linux system:

ls /etc/xinetd.d
chargen      daytime-udp  imap   kotalk  rexec   servers   telnet
chargen-udp  echo         imaps  ktalk   rlogin  services  time
cups-lpd     echo-udp     ipop2  ntalk   rsh     sgi_fam   time-udp
daytime      finger       ipop3  pop3s   rsync   talk

Each file specifies the attributes for one service. As this listing shows, there are more than two dozen services that xinetd can start. Whether all the services are enabled or not, depends on the settings in each configuration file.

Understanding the xinetd Configuration Files

For example, the following listing shows the contents of the /etc/xinetd.d/telnet file, which specifies the xinetd configuration for the telnet service:

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

The filename (in this case, telnet) can be anything; what matters is the service name that appears next to the service keyword in the file. In this case, the line service telnet tells xinetd the name of the service. xinetd uses this name to look up the port number from the /etc/services file. If you use the grep command to look for telnet in the /etc/services file, here’s what you’ll find:

grep telnet /etc/services
telnet          23/tcp
telnet          23/udp
rtelnet         107/tcp                         # Remote Telnet
rtelnet         107/udp
telnets         992/tcp
telnets         992/udp

As the first two lines that begin with telnet show, the port number of the Telnet service is 23. This tells xinetd to listen to port 23 for Telnet service requests.

The attributes in the /etc/xinetd.d/telnet file, enclosed in curly braces, have the following meanings:

• The flags attribute provides specific instructions about how to run the servers that xinetd starts. The REUSE flag means that the service is left running even if xinetd is restarted. Note that the REUSE flag is now implicitly assumed to be set for all services.

• The socket_type attribute is set to stream, which tells xinetd that the Telnet service uses a connection-oriented TCP socket to communicate with the client.

• For services that use the connectionless UDP sockets, this attribute would be set to dgram.

• The wait attribute is set to no, which tells xinetd to start a new server for each request. If this attribute is set to yes, xinetd waits until the server exits before starting the server again.

• The user attribute provides the user ID that xinetd uses to run the server. In this case, the server runs the Telnet server as root.

• The server attribute specifies the program to run for this service. In this case, xinetd runs the /usr/sbin/in.telnetd program to respond to requests for Telnet service.

• The log_on_failure attribute tells xinetd what information to log when it cannot start a server. In this case, the attribute appends the USERID flag to the default setting of HOST (set through the defaults block in the /etc/xinetd. conf file). The result is that if the Telnet service fails, xinetd logs the name of the remote host that requested the service as well as the user ID of the remote user.

• The disable attribute turns off the service if it’s set to yes. By default the disable attribute is set to yes and Telnet is turned off.

Secret

The xinetd server uses the facilities of the libwrap library (called the TCP wrapper), which provides an access-control facility for Internet services. The TCP wrapper can start other services such as FTP and Telnet, but before starting the service, the wrapper consults the /etc/hosts.allow file to see if the host requesting service is allowed that service. If there is nothing in /etc/hosts.allow about that host, the TCP wrapper checks the /etc/hosts.deny file to see if the service should be denied. If both files are empty, the TCP wrapper allows the host access to the requested service. You can place the line ALL:ALL in the /etc/hosts.deny file to deny all hosts access to any Internet services, and then enable specfic hosts to access the services by listing them in the /etc/hosts.allow file (see the “/etc/hosts.allow” and “/etc/hosts.deny” sections to learn more about these access control files).

In addition to the access control provided by the TCP wrapper files—/etc/ hosts.allow and /etc/hosts.deny—you can also control access to each service by using the following attributes in xinetd configuration files:

• only_from attribute specifies a list of IP addresses that are the only ones allowed to connect to the server. To deny all connections, use the following line:

  only_from = 

• On the other hand, to allow access to all hosts in the 192.168.1.0 class C network, add the following line:

  only_from = 192.168.1.0/24

• no_access attribute specifies the IP addresses of remote hosts that are not allowed to connect to xinetd services. For example, to deny access to the host with IP address 192.168.1.64, write:

  no_access = 192.168.1.64
  

  Browse through the files in the /etc/xinetd.d directory on your Red Hat Linux system to find out the kinds of services that xinetd is set up to start. By default nearly all of these services are turned off by setting the disable attribute to yes. You should leave them disabled, unless you need a service such as Telnet for your internal network.

  If you need to connect to your Red Hat Linux system by using telnet and you get an error message, check the appropriate Telnet file in the /etc/xinetd.d directory and make sure the disable attribute it set to no or the disable line is commented out by placing a # at the beginning of the line. You can also turn the service on or off by using the chkconfig command. For example, to turn Telnet service on, type:

  chkconfig telnet on

  After you make any change to the xinetd configuration files or turn a service on or off, you must restart the xinetd server by typing the following command:

  service xinetd restart