The Individual Protocols
Data is transmitted via TCP/IP using the protocol stack.
In each layer of the TCP/IP stack, individual protocols provide certain
network services. These protocols can be categorized as network-level or
application-level, with many individual protocols existing in each level.
Network-Level Protocols
Network-level protocols facilitate the data transport process transparently. They are
invisible to the end user unless that user employs utilities to monitor
system processes.
Tip
Sniffers are devices that can monitor network
processes. A sniffer is a device—either hardware or software—that can read
every packet sent across a network. Sniffers are commonly used to isolate
network problems that, although invisible to the end user, are degrading
net work performance. As such, sniffers can read all activity occurring
between network-level protocols. Moreover, sniffers can pose a tremendous
security threat. You will examine sniffers in Chapter 15, "Sniffers."
Important TCP/IP network-level protocols include
the following:
·
Address Resolution Protocol (ARP)
·
Internet Control Message Protocol (ICMP)
·
Internet Protocol (IP)
·
Transmission Control Protocol (TCP)
·
User Datagram Protocol (UDP)
We will briefly examine each, ascending up the stack from
the data-link layer to the transport layer.
 For more comprehensive information about
protocols (or the stack in general), see TCP/IP
Illustrated, Volume 1 by W. Richard Stevens (Addison Wesley, ISBN #
0-201-63346-9).
The Address Resolution Protocol (ARP)
The Address Resolution Protocol (ARP) serves
the critical purpose of mapping Internet addresses into hardware addresses
and translating the network layer address (or IP address) to the data-link
address. This is vital in routing information between hosts on a local
network, and out onto the Internet. Before a message (or other data) is
sent, it is packaged into IP packets, or blocks of information suitably
formatted for Internet transport. These contain the numeric, network IP
address of both the originating and destination machines. What remains is
to determine the hardware, or the data-link address of the destination
machine. This is where ARP makes its
entrance.
An ARP request message is broadcast on a local network. If
the destination IP address is active on the local network, the destination
host will reply with its own hardware address. The originating machine
receives this reply, and the transfer process can
begin.
For those readers seeking in-depth
information on ARP, see RFC 826 at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc826.txt.
The Internet Control Message Protocol (ICMP)
The Internet Control Message Protocol provides
error and control messages that are passed between two (or more) computers
or hosts. It enables those hosts to share the information. In this respect,
ICMP is critical for diagnosis of network problems. ICMP provides helpful
messages, such as the following:
·
Echo and reply messages to test for network availability
·
Redirect messages to enable more efficient routing
·
Time-exceeded messages to inform sources that a packet has
exceeded its allocated time within the network
An ICMP packet can be of several types. The two most common are the ICMP_ECHO_REQUEST
and ICMP_ECHO_REPLY. These
packets are used to test network connectivity to make sure a host or
network component is active and reachable.
Tip
Perhaps the most widely known ICMP implementation involves
a network utility called ping. Ping
is often used to determine whether a remote machine is alive. Ping's method
of operation is simple: When the user pings a remote machine, a series of ICMP_ECHO_REQUEST packets are forwarded
from the user's machine to the remote host. The remote host replies with ICMP_ ECHO_REPLY packets. If no reply
packets are received at the user's end, the ping program usually generates
an error message, indicating that the remote host is down or unreachable.
In-depth information about ICMP can be
found in RFC 792 at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc792.txt.
The Internet Protocol (IP)
The Internet Protocol provides packet
delivery for all protocols within the TCP/IP suite. Thus, IP is the heart
of the process by which data traverses the Internet. The IP datagram, or packet, is the
vehicle for transmission of data on TCP/IP networks. The structure of an IP
datagram is shown in Figure 4.3.
Figure
4.3. The IP datagram.
An IP datagram is composed
of several parts. The first part, the header, is composed of important network
information, including source and destination IP addresses. Together, these
elements form a complete header. The remaining portion of a datagram
contains whatever data is then being sent.
One of the important aspects of IP networking is that it
can be used to transmit data using a number of protocols (that is, TCP,
UDP, and so on). Each protocol serves a particular function; we'll be
looking at some important ones soon. In addition, IP enables the
fragmentation and reassembly of data. At the data-link layer, networks can
only transmit data in discrete chunks up to a specific size, called the
Maximum Transmission Unit (MTU). If the data you want
to transmit is larger than the MTU that a network can
transmit, the data must be broken into pieces smaller than the MTU,
transmitted, and then put back together at the other end. IP provides a
mechanism for fragmenting the data, tracking it, and reassembling it.
Fragmentation is also important from a security perspective. In some cases,
it can be manipulated to work around security measures if security isn't
implemented carefully.
An IP datagram also contains a
time-to-live (TTL) field. A numeric value, the TTL is decremented as the IP
datagram traverses the network. When that value finally reaches zero, the
datagram is discarded. This ensures that the network doesn't become clogged
with datagrams that can't find their destination in a timely fashion. Many
other types of packets have
time-to-live limitations, and some network utilities (such as Traceroute)
use the time-to-live field as a marker in diagnostic routines.
IP Network Addressing
The IP address is a unique identifier
for a system on the network. It is 32 bits long and is usually represented
as 4 numbers, each a byte, separated by decimal points, for example, 32.96.111.130. Each byte, or octet, in
an IP address can range from 0 to 255. This representation of an IP address
is called dotted-decimal notation and is
the most common humanly readable format for working with IP addresses.
A contiguous range of IP addresses defines an IP network. This range of IP addresses is denoted by
the combination of an IP address and network mask (or netmask). A netmask is a 32-bit value like an IP
address, which, when combined with the IP address, defines address
boundaries of the IP network. This requires conversion of the IP address
and netmask to binary format and their combination using binary arithmetic.
Note that the first address in a contiguous range of IP addresses indicates
the network address. The last address in the contiguous range denotes the
network broadcast address.
The network layer in TCP/IP is usually considered to be
unicast. This is in contrast to the data-link layer, where ARP operates in
a broadcast mode. Unicast indicates that IP
communications occur between two
endpoints in a point-to-point fashion. However, an IP datagram can be
addressed to the network broadcast address. This causes the IP datagram to
be received and responded to by all nodes on the IP network. Several
network based denial of service attacks take advantage of this broadcast capability in IP.
In-depth information on the Internet
Protocol can be found in RFC 760 at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc760.txt.
The Transmission Control Protocol (TCP)
The Transmission Control Protocol (TCP) is one of the main protocols employed on the Internet.
Working at the transport level in the stack, it facilitates such
mission-critical tasks as file transfers and remote sessions. TCP
accomplishes these tasks through a method called reliable communication. In this respect, TCP is
more reliable than other protocols within the suite because it includes
mechanisms for sequencing and acknowledgment of data transmission.
As with IP, TCP has its own packet structure (see Figure 4.4), composed of source port and destination
port numbers that identify services.
In addition, important parts of a TCP packet are the sequence number,
flags, and checksum. The sequence number
tracks a TCP connection and the
order in which data is sent. The flags
control the connection state, whether it is being
established, in use, or being closed. There are six flags that can be used
in combination to describe the state of a TCP connection. The most
important for this analysis are SYN, ACK, and FIN. The checksum in the TCP packet ensures that the data
has not been corrupted during transmission.
Figure
4.4. TCP packet structure.
The TCP system relies on a virtual circuit between the
requesting machine (client) and its target (server). This circuit is opened
via a three-part process, often referred to as the three-way handshake.
The process typically follows the pattern illustrated in Figure 4.5.
Figure
4.5. Establishment of TCP connection.
To establish a TCP connection, the three-way handshake
must be completed as follows:
1. The
client sends a TCP SYN packet to the server that it
wants to establish a connection with. This is a TCP packet with only the
SYN flag active. The packet also contains an initial sequence number (ISN)
that will be used to track the connection.
2. The
server responds with a TCP SYN packet with its own ISN. The server also
acknowledges the client's TCP SYN by setting the ACK flag on this packet
and using the client's ISN plus 1 as the acknowledgement number.
3. The
client acknowledges the server's TCP SYN with a TCP ACK using the server's
ISN plus 1.
No data is exchanged during this process, but, when it is
completed, a connection is available for data transfer between the client
and server. This connection provides a full-duplex transmission path. Full-duplex
transmission enables data to travel to both machines at the same time. In
this way, while a file transfer (or other remote session) is underway, any
errors that arise can be forwarded to the requesting machine.
TCP also provides extensive error-checking capabilities. For each block of data
sent, a checksum is calculated, and the sequence number is incremented. The
two machines identify each transferred block using the sequence number. For
each block successfully transferred, the receiving host sends an ACK
message to the sender that the transfer was clean. Conversely, if the
transfer is unsuccessful, one of two things might occur:
·
The requesting machine receives error information.
·
The requesting machine receives nothing.
When an error is received, the data is retransmitted
unless the error is fatal, in which case, the transmission is usually
halted. A typical example of a fatal error would be if the connection was
dropped.
Similarly, if no confirmation is received within a
specified time period, the information is also retransmitted. This process
is repeated as many times as necessary to complete the
transfer or remote session.
TCP Connection Termination
As you might expect, because TCP provides a
protocol for establishing a connection, it also provides a protocol for
terminating a connection. Establishing a TCP connection takes three steps,
whereas terminating one takes four steps. Because a TCP connection is bi-directional or full-duplex,
transmission in both directions of the connection must be shut down
separately. This is done by using the TCP FIN packet, much as the TCP SYN
packet is used to create a connection. When a client is finished using a
connection, it will issue a TCP FIN packet to the server. The server
responds with a TCP ACK to acknowledge that the connection is closing.
Because the connection is bi-directional, the server will also issue a TCP
FIN to the client. The client will then acknowledge the server's TCP FIN,
thus completing the TCP connection termination
process.
In-depth information about TCP can be
found in RFC 793 at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc793.txt.
User Datagram Protocol (UDP)
The User Datagram Protocol (UDP) is a simple, connectionless transport layer
protocol. In fact, it is so simple that the RFC that defines it is only
three pages long. Unlike TCP, UDP provides no reliability, and, because it
is connectionless, it doesn't have any mechanism for connection
establishment or termination. It does provide data integrity checks via a
checksum. Although it might seem that
UDP is inferior to TCP, it is, in fact, much better for certain
applications because it has very low overhead.
In-depth information about UDP can be
found in RFC 768 at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc768.txt.
Application Level Protocols—The Ports
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.) Table 4.1 shows some commonly recognized ports
and the applications typically
bound to them.
Table
4.1. Common Ports and Their Corresponding Services or Applications
|
|
Service
or Application
|
Port
|
|
Hypertext
Transfer Protocol (HTTP)
|
TCP port 80
|
|
Domain Name
System (DNS)
|
UDP and TCP
port 53
|
|
Telnet
|
TCP port 23
|
|
File
Transfer Protocol (FTP)
|
TCP port 20
and 21
|
|
Simple Mail
Transfer Protocol (SMTP)
|
TCP port 25
|
|
Secure
Shell (SSH)
|
TCP port 22
|
Each of the ports described in Table 4.1 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.
For a comprehensive list of all port
assignments, visit ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
This document is extremely informative and exhaustive in its treatment of commonly assigned port
numbers.
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.
RFC 1945 has been superseded by RFC
2068, which is available at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2068.txt.
RFC 2068 is a more recent specification of HTTP.
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.
The core RFCs for DNS are 1034 and
1035. You can find them at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1034.txt
and http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1035.txt.
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). Figure 4.6 shows an example of a Telnet library catalog
screen.
Figure
4.6. A sample Telnet session.
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 (examined later in this chapter) 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.
RFC 114 contains the first definition
of FTP, but a more practical document might be RFC 959, found at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc959.txt.
Mechanical Operation of FTP
File transfers using FTP can be accomplished using any
suitable FTP client. Table 4.2 defines some common FTP clients,
by operating
system.
Table
4.2. FTP Clients for Various Operating Systems
|
|
Operating
System
|
Clients
|
|
UNIX
|
Native,
LLNLXDIR2.0, FTPtool, NCFTP
|
|
Microsoft
Windows 95/98
|
Native,
WS_FTP, Netload, Cute-FTP, Leap FTP, SDFTP, FTP Explorer
|
|
Microsoft
Windows NT/2000
|
See
listings for Windows 95/98
|
|
Microsoft
Windows 3.x
|
Win_FTP,
WS_FTP, CU-FTP, WSArchie
|
|
Macintosh
|
Anarchie,
Fetch, Freetp
|
|
OS/2
|
Gibbon FTP,
FTP-IT, Lynn's Workplace FTP
|
FTP file transfers occur in a client/server environment.
The requesting machine starts one of the clients named in Table 4.2. 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 (for other
operating systems, see Table 4.3).
Table
4.3. FTP Servers for Various Operating Systems
|
|
Operating
System
|
Servers
|
|
UNIX
|
Native
(FTPD), WUFTD
|
|
Microsoft
Windows 95/98
|
WFTPD,
Microsoft FrontPage, WAR FTP Daemon, Vermilion
|
|
Microsoft
Windows NT/2000
|
Serv-U,
OmniFSPD, Microsoft Internet Information Server
|
|
Microsoft
Windows 3.x
|
WinQVT,
Serv-U, Beames & Whitside BW Connect, WFTPD FTP Server, WinHTTPD
|
|
Macintosh
|
Netpresenz,
FTPd
|
|
OS/2
|
Penguin
|
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. These security issues
are covered in detail later in this book.
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.
Further information on SMTP is
available in RFC 821 http://info.internet.isi.edu:80/in-notes/rfc/files/rfc821.txt.
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.
Information on the IETF SSH working
group, along with the latest Internet drafts, can be found at http://www.ietf.org/html.charters/secsh-charter.html.
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 in Table 4.4.
Table
4.4. SSH Clients for Various Operating Systems
|
|
Operating
System
|
Clients
|
|
UNIX
|
SSH
Communications, F-Secure, OpenSSH, Lsh, MindTerm
|
|
Microsoft
Windows 95/98
|
SSH
Communications, F-Secure, PuTTY, TeraTerm, FiSSH, SecureCRT, Cygwin32,
MindTerm
|
|
Microsoft
Windows NT/2000
|
Same as 95/98
|
|
Macintosh
|
F-Secure,
NiftyTelnet 1.1 SSH, MindTerm
|
|
OS/2
|
MindTerm
|
Secure Shell server implementations are also available, although not on as many platforms as for clients (see Table 4.5).
Table
4.5. SSH Servers for Various Operating Systems
|
|
Operating System
|
Servers
|
|
UNIX
|
SSH
Communications, F-Secure, OpenSSH, Lsh
|
|
Microsoft
Windows 95/98
|
SSH
Communications, F-Secure, Cygwin32
|
|
Microsoft
Windows NT/2000
|
Same as
95/98
|
|
