Each time a machine requests services from another, it specifies a particular destination and transport method. The destination is expressed as the Internet (IP) address of the target machine, and the transport method is the transport protocol (that is, TCP or UDP). Further, the requesting machine specifies the application it is trying to reach at the destination by using a system of ports.

Just as machines on the Internet have unique IP addresses, each application (FTP or Telnet, for example) is assigned a unique address called a port. The port defines the type of service that is being requested or provided. The application in question is bound to that particular port, and, when any connection request is made to that port, the corresponding server application responds.

There are thousands of ports on the average Internet server, although often, most will not be active. For purposes of convenience and efficiency, a standard framework has been developed for port assignments. (In other words, although a system administrator can assign services to the ports of his choice, services are generally assigned to recognized ports commonly referred to as well-known ports.) The table below shows some commonly recognized ports and the applications typically bound to them.

Each of the ports described above are assigned to application-level protocols or services—that is, they are visible to the user, and the user can interact with them. We will examine each of these applications in the following sections.

Hypertext Transfer Protocol (HTTP)

Hypertext Transfer Protocol (HTTP) is perhaps the most renowned protocol of all because it enables users to surf the World Wide Web. Stated briefly in RFC 1945, HTTP is

…an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, enabling systems to be built independently of the data being transferred.

HTTP has forever changed the nature of the Internet, primarily by bringing the Internet to the masses. Using a common browser such as Netscape Navigator or Microsoft Internet Explorer, you can monitor the process of HTTP as it occurs. Depending upon the version of HTTP the server supports, your browser will contact the server for each data element (text, graphic, sound) on a WWW page. Thus, it will first grab text, then a graphic, then a sound file, and so on. In the lower-left corner of your browser's screen is a status bar. Watch it for a few moments while it is loading a page. You will see this request/response activity occur, often at a very high speed.

HTTP typically runs on port 80 using TCP. HTTP does little to protect the confidentiality of data because documents are transmitted without encryption. Some security can be added by using HTTPS, which is HTTP transmitted over Secure Sockets Layer (SSL). HTTPS typically runs on port 443 using TCP.

Domain Name System (DNS)

The Domain Name System (DNS) provides services that translate host names to IP addresses and back again. Much as Address Resolution Protocol provides a mechanism for translating addresses between the data-link and network layers (hardware address to IP address), DNS translates addresses between the network layer and the application layer (IP address to hostnames). Because IP addresses aren't exactly human friendly, the Domain Name System was developed to allow people to use human-friendly naming for systems. For example, when you enter http://www.fbi.gov into your Web browser, the name needs to be translated from that friendly format into an IP address that can be used by the network layer.

DNS has two modes of operation. The first mode is primarily for communications to clients that need names resolved to addresses. Because this is a small, easy task, transport for this mode is provided by UDP. DNS servers also must transfer large blocks of DNS records so that the workload and administration involved with resolving names to and from IP addresses can be distributed. These larger transfers (called DNS zone transfers) occur via TCP.

DNS is a very active area of discussion, and numerous Internet drafts and RFCs have been created to add functionality and security to DNS.

All modern operating systems that run TCP/IP come with a DNS client (called a resolver) as part of the OS. A client program that enables a user to query DNS directly is often included. On UNIX and Microsoft Windows NT or 2000, the program nslookup is provided. This DNS client lets you interactively connect to a DNS server and perform various queries of the DNS data.

The most widely used DNS server is the Berkeley Internet Name Domain (BIND) DNS server. Developed and supported by the Internet Software Consortium, BIND is available for most UNIX systems as well as for Microsoft Windows NT. DNS typically runs on port 53 using UDP and TCP.

Telnet

Telnet is best described in RFC 854, the Telnet protocol specification:

The purpose of the Telnet protocol is to provide a fairly general, bi-directional, eight-bit byte-oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other.

Telnet not only enables the user to log in to a remote host, it also lets that user execute commands on the host. Thus, an individual in Los Angeles can telnet to a machine in New York and begin running programs on the New York machine just as though she were in New York.

For those of you who are unfamiliar with Telnet, it operates much like the interface of a bulletin board system (BBS). Telnet is an excellent application for providing a terminal-based front-end to databases. For example, many university library catalogs can be accessed via Telnet or tn3270 (a variation that emulates an IBM 3270 terminal).

Even though GUI applications have taken the world by storm, Telnet—which is essentially a text-based application—is still incredibly popular. Telnet enables you to perform a variety of functions (retrieving mail, for example) at a minimal cost in network resources.

To use Telnet, the user issues whatever command necessary to start his Telnet client, followed by the name (or numeric IP address) of the target host. In UNIX, this is done as follows:

% telnet http://www.fbi.gov

This command launches a Telnet session, contacts http://www.fbi.gov, and requests a TCP connection on port 23. That connection request will either be honored or denied, depending on the configuration at the target host. In UNIX, the telnet command has long been a native one. In addition, Telnet has been included with Microsoft Windows distributions for more than a decade.

Telnet is a simple protocol, and offers very little in the way of security. All data transmitted during a Telnet session, including the login ID and password, are sent unencrypted. Anyone with access to a sniffer and the network between the client and server could capture critical data including your password.

Secure Shell provides services similar to Telnet, but adds security by encrypting the data between client and server.

Telnet typically runs on port 23 via TCP.

File Transfer Protocol (FTP)

File Transfer Protocol (FTP) is a standard method of transferring files from one system to another. Its purpose is set forth in RFC 0765 as follows:

The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among Hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.

For more than two decades, researchers have investigated a wide variety of file-transfer methods. The development of FTP has undergone many changes in that time. Its first definition occurred in April 1971, and the full specification can be read in RFC 114.

Mechanical Operation of FTP

File transfers using FTP can be accomplished using any suitable FTP client. The table below defines some common FTP clients, by operating system.

FTP file transfers occur in a client/server environment. The requesting machine starts one of the clients named in the table above. This generates a request that is forwarded to the targeted FTP server (usually a host on another network). Typically, the request is sent by the client to port 21. For a connection to be established, the targeted file server must be running an FTP server.

FTPD: An FTP Server Daemon

FTPD is the standard FTP server daemon for UNIX. Its function is simple: to reply to connect requests received and to satisfy those requests for file transfers. An FTP daemon comes standard on most distributions of UNIX..

FTPD waits for a connection request. When such a request is received, FTPD requests the user login. The user must either provide her valid user login and password or log in anonymously (if the server allows anonymous sessions).

When logged in, the user can download files. In certain instances and if security on the server allows, the user can also upload files.

As with Telnet, FTP is an insecure protocol. It does nothing to encrypt the user ID, password, or any of the files being transferred. Secure Shell provides a more secure method of file transfer via either Secure Copy (SCP) or Secure FTP (SFTP).

FTP uses ports 20 and 21 via TCP.

Simple Mail Transfer Protocol (SMTP)

SMTP is the protocol responsible for email transmission between servers, and the sending of email from clients to servers. Its purpose is stated concisely in RFC 821:

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.

SMTP is an extremely lightweight protocol. Running any SMTP-compliant client, the user sends a request to an SMTP server. The client forwards a series of instructions, indicating that it wants to send mail to a recipient somewhere on the Internet. If the SMTP allows this operation, an affirmative acknowledgment is sent back to the client machine. At that point, the session begins. The client might then forward the recipient's identity, his IP address, and the message (in text) to be sent.

Despite the simple character of SMTP, mail service has been the source of countless security holes. The configuration of an SMTP server can be complex, depending upon the options an administrator needs to support. A combination of SMTP server application bugs, and difficulty in configuration have led to numerous security holes.

Most networked operating systems have SMTP servers available for use. STMP server support is included as sendmail for most UNIX distributions, or part of Internet Information Services for Microsoft Windows.

SMTP typically runs on port 25 via TCP.

Secure Shell Protocol (SSH)

SSH is relatively new to the TCP/IP suite of protocols. Unlike the application protocols we've examined already, SSH has been widely implemented without completing the RFC process. This is largely because of the vast demand for a more secure method of providing services similar to Telnet and FTP.

There are two versions of the SSH protocol, and a number of implementations. The first widely used version of the protocol was SSH1, which was defined in an Internet draft (a pre-RFC document) in 1995. As of this writing, there is an Internet Engineering Task Force working group developing the second generation of SSH. Based upon that group's Internet drafts, a number of SSH2 implementations have been completed.

SSH allows you to log in to another computer over a network, to execute commands in a remote machine (like Telnet), and to move files from one machine to another (like FTP). It provides for strong authentication and secure, encrypted communications over otherwise insecure networks. It is intended as a replacement for Telnet and other remote access protocols like rlogin, rsh, and rcp. In SSH2, there is a replacement for FTP as well, called sftp.

Secure Shell client implementations exist for a variety of platforms, as shown below:

Secure Shell server implementations are also available, although not on as many platforms as for clients (see the table below).