Red Hat Linux 9 Professional Secrets [Electronic resources] نسخه متنی

TCP/IP Services and Client/Server Architecture

By design, a typical Internet service is implemented in two parts—a server that provides information and one or more clients that request information. Such client/server architecture has been gaining popularity as an approach for implementing distributed information systems. The client/server architecture typically consists of a collection of computers connected by a communication network. The functions of the information system are performed by processes (computer programs) that run on these computers and communicate through the network.

In recent years, the client/server architecture has become commonplace as the mechanism that brings the centralized corporate databases to desktop PCs on a network. In a client/server environment, one or more servers manage the centralized database and clients gain access to the data through the server.

Like a database server, an Internet service such as FTP or the Web also provides a service using the client/server model. A user who wants to access information uses a client (for example, a Web browser) to connect to a server and download information (for example, Web pages from a Web server). In this case, the Web server acts as a database manager—the data are the HTML files (Web pages).

Understanding TCP/IP and Sockets

Client/server applications such as Web servers and browsers use TCP/IP to communicate. These Internet applications perform TCP/IP communications using the Berkeley Sockets interface (so named because the socket interface was introduced in Berkeley UNIX around 1982). The sockets interface consists of a library of routines that an application developer can use to create applications that can communicate with other applications on the Internet. There is even a Windows Sockets API (application programming interface—a fancy name for a library of programming functions that can be called by C programs) modeled after the Berkeley Sockets interface. The Winsock interface, as it’s known, provides a standard API that Windows programmers can use to write network applications.

Even if you do not write network applications using sockets, you have to use many network applications. Knowledge of sockets can help you understand how network-based applications work, which, in turn, helps you find and correct any problems with these applications.

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

Performing Client/Server Communications with TCP/IP

Client/server applications use the following basic steps to exchange data in a TCP/IP network:

1. 
   

   Create a socket. If the socket already exists, you can skip this step.



2. 
   

   Bind an IP address and port to the socket.



3. 
   

   Listen for connections if the application is a server using a stream socket.



4. 
   

   Establish connection if the application is a client using a stream socket.



5. 
   

   Exchange data.



6. 
   

   Close the socket when done.

Connectionless sockets (that implement data transfer using UDP) do not require Steps 3 and 4.

Regardless of whether it’s a server or a client, each application first creates a socket. Then it associates (binds) the socket with the local computer’s IP address and a port number. The IP address identifies the machine (where the application is running), and the port number identifies the application using the socket.

Servers typically listen to a well-known port number so that clients can connect to that port to access the server. For a client application, the process of binding a socket to the IP address and port is the same as that for a server, but the client can use zero as the port number—the sockets library automatically uses an unused port number for the client.

For a connection-oriented stream socket, the communicating client and server applications have to establish a connection. The exact steps for establishing a connection depend on whether the application is a server or a client.

In the client/server model, the server has to be up and running before the client can run. After creating a socket and binding the socket to a port, the server application sets up a queue of connections, which determines how many clients can connect to the server. Typically, a server listens to anywhere from one to five connections. However, the size of the listen queue is one of the parameters you can adjust (especially for a Web server) to ensure that the server responds to as many clients as possible.

After setting up the listen queue, the server waits for a connection from a client.

Establishing the connection from the client side is somewhat simpler. After creating a socket and binding the socket to a network address, the client establishes connection with the server. To make the connection, the client needs to know the network name or IP address of the server, as well as the port on which the server accepts connections. As the next section shows, all Internet services have well-known standard port numbers.

After a client establishes connection to a server using a connection-oriented stream socket, the client and server can exchange data by calling appropriate sockets API functions. Like a conversation between two persons, the server and client alternately send and receive data—the meaning of the data depends on the message protocol the server and clients use. Usually, a server is designed for a specific task; inherent in that design is a message protocol that the server and clients use to exchange necessary data. For example, the Web server and the Web browser (client) communicate using HTTP.

Exploring Internet Services and Port Numbers

The TCP/IP protocol suite has become the lingua franca of the Internet because many standard services are available on all systems that support TCP/IP. These services make the Internet tick by enabling the transfer of mail, news, and Web pages. These services go by well-known names such as the following:

• 
  

  DHCP (Dynamic Host Configuration Protocol) is for dynamically configuring TCP/IP network parameters on a computer. DHCP is primarily used to assign dynamic IP addresses and other networking information such as name server, default gateway, domain names that are needed to configure TCP/IP networks. The DHCP server listens on port 67.



• 
  

  FTP (File Transfer Protocol) enables the transfer of files between computers on the Internet. FTP uses two ports—data is transferred on port 20, while control information is exchanged on port 21.



• 
  

  HTTP (HyperText Transfer Protocol) is a recent protocol for sending HTML documents from one system to another. HTTP is the underlying protocol of the Web. By default, the Web server and client communicate on port 80.



• 
  

  SMTP (Simple Mail Transfer Protocol) is for exchanging email messages between systems. SMTP uses port 25 for information exchange.



• 
  

  NNTP (Network News Transfer Protocol) is for distribution of news articles in a store-and-forward fashion across the Internet. NNTP uses port 119.



• 
  

  Telnet enables a user on one system to log in to another system on the Internet (the user must provide a valid user ID and password to log in to the remote system). Telnet uses port 23 by default. However, the Telnet client can connect to any specified port.



• 
  

  SNMP (Simple Network Management Protocol) is for managing all types of network devices on the Internet. Like FTP, SNMP uses two ports: 161 and 162.



• 
  

  TFTP (Trivial File Transfer Protocol) is for transferring files from one system to another (typically used by X terminals and diskless workstations to download boot files from another host on the network). TFTP data transfer takes place on port 69.



• 
  

  NFS (Network File System) is for sharing files among computers. NFS uses Sun’s Remote Procedure Call (RPC) facility, which exchanges information through port 111.
  

A well-known port is associated with each of these services. The TCP protocol uses this port to locate a service on any system. (A server process—a computer program running on a system—implements each service.)

Note that many applications use specific port ranges that are outside the typical list of well-known ports.

As with the

/etc/hosts file, which stores the association between host names and IP addresses, the association between a service name and a port number (as well as a protocol) is stored in another text file, named

/etc/services . Following is a small subset of lines from the

/etc/services file in a Red Hat Linux system:

# /etc/services:
# $Id: services,v 1.32 2003/01/09 17:56:30 dwalsh Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single 
# well-known port number for both TCP and UDP; hence, most 
# entries here have two entries even if the protocol doesn't 
# support UDP operations.
# Updated from RFC 1700, ``Assigned Numbers'' (October 1994).  
# Not all ports are included, only the more common ones.
#
# The latest IANA port assignments can be gotten from
#       http://www.iana.org/assignments/port-numbers
# The Well Known Ports are those from 0 through 1023.
# The Registered Ports are those from 1024 through 49151
# The Dynamic and/or Private Ports are those from 49152 
# through 65535.
#
# Each line describes one service, and is of the form:
#
# service-name  port/protocol  [aliases ...]   [# comment]
tcpmux          1/tcp    # TCP port service multiplexer
tcpmux          1/udp    # TCP port service multiplexer
ftp-data        20/tcp
ftp-data        20/udp
# 21 is registered to ftp, but also used by fsp
ftp             21/tcp
ftp             21/udp          fsp fspd
ssh             22/tcp               # SSH Remote Login Protocol
ssh             22/udp               # SSH Remote Login Protocol
telnet          23/tcp
telnet          23/udp
# 24 - private mail system
smtp            25/tcp          mail
smtp            25/udp          mail
... many lines deleted ...

You’ll find browsing through the entries in the

/etc/services file to be instructive because they show the breadth of networking services available under TCP/IP.

Running the xinetd Superserver

The client/server model requires that the server be up and running before a client makes a request for service. A simplistic idea would be to run all the servers and have them listen to their respective ports all the time. However, this idea is not practical because each server process would use up system resources in the form of memory and processor time. Besides, you don’t really need all the services up and ready at all times. A smart solution to this problem is to run a single server, xinetd, which listens to all the ports, then starts the appropriate server when a client request comes in.

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.

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.

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

  
  

Starting Standalone Servers

Although starting servers through xinetd is a smart approach, xinetd is not efficient if a service has to be started very often. The Web server typically has to be started often because every time a user clicks on a link on a Web page, a request arrives at the Web server. For such high-demand services, it’s best to start the server in a standalone manner. Such standalone servers are designed to run as daemons—processes that run continuously. That means the server listens on the assigned port; whenever a request arrives, the server handles it by making a copy of itself. In this way, the server keeps running forever. A more efficient strategy, used for Web servers, is to run multiple copies of the server and let each copy handle some of the incoming requests.

To help you manage standalone servers, Red Hat Linux includes scripts (called initscripts) in the

/etc/init.d directory as well as symbolic links to enable execution of these scripts at various run levels (run levels are discussed in Chapter 20). You can log in as

root and manage the standalone servers through the initscripts in the following ways:

• 
  

  Use the

  service command to start, stop, or restart a server. The service command has the following syntax:

  service <servicename> <action>

  
  

  Here, <

  servicename > is the name of the service such as

  httpd for the Web server,

  sendmail for the mail server, and so on. The last field, <

  action >, must be one of

  start ,

  stop , or

  restart with the obvious meaning—

  start runs the server,

  stop terminates it, and

  restart stops the server first and then runs it again. Typically, you must restart a server after you have made changes to the server’s configuration file.



• 
  

  Use the

  chkconfig command to set up a service to start automatically when the system boots into a run level. For example, to set up

  httpd to run in run levels 3 and 5, you would type:

  chkconfig --level 35 httpd on
  

  
  

  If a service is already set to start automatically at boot time, you can disable it with the following

  chkconfig command:

  chkconfig --level 35 <servicename> off

  
  

  where <

  servicename > is the name of the service that you want to turn off.

Note that services can typically be configured to run under xinetd or on a standalone basis. For example, prior to version 9, Red Hat Linux used to start the FTP service under control of xinetd. Starting with version 9, however, the Very Secure FTP server (

vsftpd ) is set up as a standalone server. Nowadays, if you need to start the FTP service, type service vsftpd start. To start the FTP service automatically at boot time, type chkconfig vsftpd on.