Tài liệu IP Behavior pptx

4 - 1
1
IP Behavior – SANS
©2001
IP Behavior
Security Essentials
The SANS Institute
In this module, IP Behavior, we are going to take a look at how to analyze TCP/IP information and
how one would actually go about pulling it off the wire and looking for patterns. The key point when
it comes to security is, “Knowledge is power and ignorance is deadly.” Not understanding what is
occurring on your network can be very dangerous from a security standpoint because if you do not
understand what is occurring, then how can you determine whether it is good or bad? The answer is
that you cannot. Therefore, being able to understand and interpret data on your network will enable
you to determine what action you need to take to possibly protect against any malicious behavior.
4 - 2
2
IP Behavior – SANS
©2001
Objectives
• What is a sniffer?
• Introduction to TCPdump and TCPdump output
•TCP concepts
•Fragmentation
• Stimulus and normal response
In order to analyze and interpret TCP/IP traffic you need a way to be able to pull the traffic off of the
network. In order to do this we need to use a sniffer. There are a variety of sniffers available but
most of this chapter will concentrate on TCPdump and how to analyze TCPdump output. We will
then cover TCP concepts that are the foundation of how TCP communicates. We will look at
fragmentation in IP datagrams to see what is happening at the datagram level. Finally, we will
examine stimulus and response. How does a host respond to certain traffic under varying
circumstances? This will assist you in understanding what normal responses look like.

4 - 3
3
IP Behavior – SANS
©2001
Hub
Blah, blah, blah
Blah, blah, blah
Blah, blah, blah
Blah, blah, blah
Broadcast Ethernet
Broadcast Ethernet
Switch
Blah, blah, blah
Blah, blah, blah
Switched Ethernet
Switched Ethernet
What is a Sniffer?
• Sniffers gather all information transmitted across a line
– For broadcast media (ethernet), allows an attacker to gather
passwords, etc.
– For ethernet, all data is broadcast on the LAN segment
• Switched ethernet limits data to a specific source and destination
port on a switch
Sniffers are among the most common of hacker tools. They gather traffic off of the network, which
an attacker can read in real time, or squirrel away in a file, but not only can they be used by attackers
but they can also be used by the good guys to analyze network traffic and to figure out what is
occurring on the network.
When an ethernet interface is gathering all traffic, it is said to be in “promiscuous mode” and a
sniffer is basically a device or piece of hardware that listens on the cable and records all traffic as it
passes the network. In order to be able to sniff the traffic you have to be able to see it and this

depends on the type of device you are using to connect your systems together.
Traditional ethernet, usually implemented in a hub, is a broadcast medium, which broadcasts all data
to all systems connected to the LAN segment. Therefore, traditional ethernet is inherently sniffable.
Switched ethernet does not broadcast all information to all links of the LAN segment. Instead, the
switch is more intelligent than the hub, and by looking at the destination MAC address, will only
send the data to the required port on the switch. Switched ethernet is only sniffable in limited ways.
4 - 4
4
IP Behavior – SANS
©2001
Examples of Sniffers
• There are countless examples of sniffers out there
– es - freeware (ships with SunOS, Solaris RootKits)
– Linsniff - freeware (ships with Linux Rootkits)
– Websniff - freeware
– TCPdump - freeware
– snoop - distributed with Solaris
– Network Associates - commercial
– Shomiti Surveyor - commercial
– Ethereal - freeware
– Windump - freeware
– Snort - freeware
– Sniffit - freeware
– Dsniff - a free suite of tools built around a sniffer
There are lots of sniffers our there… some much more useful than others.
Depending on your needs, your interest, and your budget, there should be a sniffer out there that does
what you want. In this module we are going to concentrate and look at TCPdump which runs
primarily on Unix systems but also has a port to Windows, called windump.
4 - 5
5

IP Behavior – SANS
©2001
TCPdump
TCPdump is a program that will dump traffic on a network. It is available
from or from www.tcpdump.org. You will also need to
download the libpcap packet capture library. TCPdump has also been
ported to Windows as windump. Windump and winpcap can be
downloaded from />.
In section 1, we will explore TCPdump.
4 - 6
6
IP Behavior – SANS
©2001
0101001110 111010010011000 00100011011
Network
packets
TCPdump running on a host “sniffing”
network packets
TCPdump output
TCPdump
07:00:48.036746 ping.net > myhost.com: icmp: echo request (DF)
07:00:48.036776 myhost.com > ping.net: icmp: echo reply (DF)
07:02:12.622460 log.net.3155 > syslog.com.514: udp 101
07:03:01.132414 send.net.32938 > mail.com.25: S 248631:248631(0) win
8760
On the slide “TCPdump”, we mean that TCPdump is a program that will read traffic off of the network. By
default, it will collect and print, in a standard format, all the traffic passing on the network. There are
command line options for TCPdump that will alter the default behavior. We can specify that we want to collect
only certain types of packets, print the records of these packets in verbose mode (-v), print the packets in
hexadecimal (-x), or actually write the records to a file as “raw packets”(-w) instead of printing them as

standard output.
TCPdump filters can be used to specify records to be collected. Rather than gather all traffic passing on the
network on which the host resides, TCPdump can be instructed to record packets with a specific trait.
Examples of filters would be to record only TCP packets, or record packets to a given port, say telnet, port 23,
for instance. You can limit the purview of what is collected to a specific IP or host. Combinations of traits
can be used to get more restrictive in what is collected. Just about any field in an IP datagram, including the
actual data payload, can be used to select the records that are collected.
On this slide, we see a host running TCPdump and gathering records from the network interface. We see the
records that TCPdump has collected at the bottom of the slide. TCPdump has a default standard output based
on the protocol (tcp, udp, icmp) of the record that is displayed. While each of the various protocols has a
similar format to the other, they are also distinct in what is displayed.
4 - 7
7
IP Behavior – SANS
©2001
timestamp source.port dest.port : udp bytes
timestamp: hour:minutes:seconds.fractions of seconds
source.port: source IP/hostname.source port
dest.port: destination IP/host.destination port
udp: may or may not expressly label the udp protocol
bytes: number of bytes of udp data (payload)
09:39:19.470000 nmap.edu.728 > dns.net.111: udp 56
Sample TCPdump UDP Output
If we examine a line of TCPdump UDP output on the slide “Sample TCPdump UDP output”, we first see a
timestamp or the record of the time when the TCPdump host read the packet. The timestamp is in the
format of hour, colon, minutes, colon, seconds, period, followed by fractions of a second. As you can see,
TCPdump allows for 6 fractional digits or millionths of a second. The record we see with the value 470000
has a precision of hundredths of a second. This is a limitation of the Linux operating system on which this
TCPdump record was collected, but this was corrected in a later RedHat release.
Next, we see the source information for the TCPdump record. This includes the source host name, nmap.edu,

or IP number depending upon whether the IP can be resolved. If you do not want names resolved, TCPdump
can be run with the -n parameter. At the end of the source host name, we see a period and the source port, in
this case 728. Immediately following the greater than sign, you see the destination host or IP address,
“dns.net”, followed by a period, followed by the destination port, in this case port 111 or what is more
commonly known as the portmapper or sunrpc port. In this record, you see the word “udp” to help identify
this protocol. Not all UDP records will be labeled expressly “udp”. DNS, or port 53, is a notable exception.
The final field is the number of bytes found of the UDP data. Recall that UDP data is wrapped in a UDP
header first and encapsulated in an IP header before it is sent out on the network.
4 - 8
8
IP Behavior – SANS
©2001
Sample TCPdump TCP Output
timestamp source.port dest.port flags beginning: ending bytes options
seq # seq #
09:32:43.910000 nmap.edu.1173 > dns.net.21: S 62697789:62697789(0) win 512
flags: tcp flags ( P
SH, RST, SYN, FIN)
beginning seq #: for the initial connection, this is the initial sequence number (ISN)
from the source IP
ending seq #: this is the beginning sequence number + data bytes
bytes: data bytes (payload) in the tcp packet
options: options that the source host advertises to the destination host
The TCPdump TCP record is identical to the UDP record as far as timestamp, source, and destination host and
port. What distinguishes the TCP format from the others are the TCP flags, sequence numbers,
acknowledgements, acknowledgement numbers, and TCP options.
In this record, we see the flag of SYN or S set following the destination port of 21 which, by the way, is the
port for ftp. The SYN flag indicates a request to begin a TCP session. Other possible flag values are P for
PUSH that sends data, R for RESET that aborts a connection, and F for FIN, which terminates a connection
more gracefully. While not an actual flag bit like the others, if you see a period in the flag field, it simply

means that none of the PUSH, RESET, SYN, or FIN flags are set. In a way, this is an informative placeholder.
Next is the beginning sequence number. One of the mechanisms that TCP uses to guarantee reliable packet
delivery is keeping track of the data it has received. This is partially done by using sequence numbers. In this
case, since this is an initial connection, it is known as the Initial Sequence Number or ISN. The ending
sequence number is the sum of the initial sequence number plus the number of TCP data bytes sent in this TCP
segment. A SYN connection sends no data bytes, as represented by the zero in parentheses. Data should not
be sent until the client and server actually establish the connection.
Finally, there is a TCP options field. In this record, we see nmap.edu advertising a window size of 512 bytes.
It is informing dns.net that it has an incoming buffer size of 512 bytes. If dns.net is a larger faster host, it will
have to slow itself and pace the data sent so it doesn’t overwhelm the buffer size of nmap.edu.
4 - 9
9
IP Behavior – SANS
©2001
Absolute and Relative Sequence
client.com.38060 > telnet.com.telnet: S 3774957990:3774957990(0) win
8760 <mss 1460> (DF)
telnet.com.telnet > client.com.38060: S 2009600000:2009600000(0) ack
3774957991 win 1024 <mss 1460>
client.com.38060 > telnet.com.telnet: .ack 1 win 8760 (DF)
client.com.38060 > telnet.com.telnet: P 1:28(27) ack 1 win 8760 (DF)
On the next slide, we show a handy feature of TCPdump. Notice the top line, we have the number
3774957990 in bold. That is an absolute sequence number. The absolute sequence number keeps
track of how much data has been sent by a connection. However, these numbers get pretty ugly. So
TCPdump can provide the information as relative sequence numbers as well. On the third line of
your slide, after the ack, you see a 1 in bold. That means one byte has been transferred. When we
look more closely at tcp, we will see our friends absolute and relative sequence again.
4 - 10
10
IP Behavior – SANS

©2001
Sample TCPdump ICMP Output
icmp format 1
timestamp source dest icmp: icmp message
14:59:30.220000 ping.net > hosta.mysite.com: icmp: echo request
14:59:38.140000 hosta.mysite.com > ping.net: icmp: echo reply
icmp format 2
timestamp router source icmp: dest
icmp message
02:09:47.600000 foreign.router > tryinghost.com: icmp: host desired.com
unreachable
In the slide “Sample TCPdump ICMP Output,” we see ICMP output generated by TCPdump. ICMP is the
protocol used for error control and message handling. There are many different types of ICMP records that
have different messages. We display two of the basic formats on this slide.
The first two ICMP records have a similar format. In the first ICMP record, we have a timestamp followed by
a source host – ping.net in the first record. Following the greater than sign, we see the destination host – in
this record hosta.mysite.com. Remember, ICMP doesn’t use ports to communicate like TCP and UDP do.
The ICMP message type follows the destination host. In the first record we see an ICMP echo request which is
generated by a commonly used program known as ping.
The second record is a response from the ping from hosta.mysite.com to ping.net. This is known as an ICMP
echo reply.
The third record shows a slightly different format. Often times a router will be involved when some kind of
error is detected. In this record, foreign.router delivers a message to tryinghost.com that host desired.com is
not reachable. This implies that tryinghost.com first attempted to send some kind of traffic to desired.com and
foreign.router intervened to inform tryinghost.com when it discovered a problem.
4 - 11
11
IP Behavior – SANS
©2001
TCPdump Output in Hex

• The TCPdump command comes with a command line
option -x that will display the records in hexadecimal
• Hexadecimal output is more difficult to read and
decrypt, however it will show you the entire IP
datagram, even fields that TCPdump doesn’t display
in its standard output
• The “entire” packet is shown only if you’ve told
TCPdump to dump the entire packet via the -s
(snaplen) calling parameter
.
This slide reiterates what we discussed earlier. TCPdump output can be displayed in hexadecimal.
As you become more advanced in analyzing records, you'll want to be able to look for the protocol and the
only sure way to do that is in the hexadecimal information. We'll go over that, but don't worry if you don't
understand it all. Over time, the cumulative discussions of binary and hexadecimal arithmetic will begin to
look familiar and almost friendly.
This is done using the –x command line option of TCPdump. Hexadecimal output is indeed more difficult to
read or decipher. But if the snaplen, the -s parameter, is as large or larger than the datagram, the -x parameter
will show the entire datagram, something that the standard TCPdump output doesn’t do.
This can be used as a tool to investigate a particular field or value. Additionally, it can be used to uncover any
kind of anomalies in the datagram such as length values that may not be accurate. Fields in a datagram can be
“crafted” by a program instead of using normal system calls to create a number of very interesting, illegal
datagrams. TCPdump hexadecimal output gives us all the data to look for signs of this kind of tampering.
4 - 12
12
IP Behavior – SANS
©2001
04:19:31.800000 1.2.3.4 > 192.168.5.5: icmp:
echo reply (DF)
4500 0028 b5cb 4000 fe01 b229 0102 0304
IP Header

c0a8 0505 0000 bc9c bf3c 51ff 0018 f81b
000d d5f0 000d 63e8 0000 0000 0000
Sample Hexadecimal Output
ICMP message
We see the output of a datagram displayed in hexadecimal. The record is first displayed as you would see it in
normal TCPdump output.
In this slide, we are looking at the bowels of an ICMP echo reply packet. Each character in the hex output
represents 4 bits, two consecutive 4 bit values with no intervening spaces represent a byte. The IP header in
this datagram has 20 bytes. The IP header is displayed between the first and second arrows.
This is followed by an ICMP message that is found between the second and third arrows.
What do these hex values represent? Well, you’ll have to get a standard layout of what an IP header looks like
and similarly, you’ll need to acquire a layout of an ICMP message format. One of the best sources for this and
understanding TCP/IP in general, is TCP/IP Illustrated, Volume 1
by Richard Stevens.
4 - 13
13
IP Behavior – SANS
©2001
Finding the Protocol in the IP Header
45 0000 28b5 cb 40 00 fe 01 b2 29 01 02 03 04
16 17 18 19
0123456789101112131415
c0 a8 05 05
IP protocol field
icmp = 01
tcp = 06
udp = 17 = 11 hexadecimal
16
1
x

1
+ 16
0
x
1
= 17
BYTE
We get a feel for how this works by turning to the slide “Finding the protocol in the IP header.”
Here we have displayed the IP header. One of the hardest things to master when you first begin to
look at TCPdump output is exactly what protocol is being displayed. We saw where ICMP is pretty
obvious about announcing itself in the output somewhere. We saw where TCP is a little bit more
subtle with flags, sequence numbers, and acknowledgement numbers. Finally, UDP may or may not
announce its presence.
How can you determine the protocol of a record when it is not obvious to you looking at the standard
TCPdump output? First, you have to have that record stored in a TCPdump raw packet file. This
means that you have gathered TCPdump output and written it to a file using the TCPdump –w option
rather than display it. If you read the file in which the record is stored and display it in hexadecimal,
you should be able to determine the protocol.
To do this we need to know a couple of pieces of information. First, the IP protocol field is 9 bytes
into the IP header. Counting begins with 0 so if we look at the slide, the byte that has the gray
background represents the IP protocol. The current value that we see is 01 or the value for icmp.
Other values that you may see are 06 which is tcp, and 17 which is udp. Seventeen is the decimal
value of the number, but the IP header is in hexadecimal. Seventeen in decimal is 11 in
hexadecimal. If you remember the hexadecimal numbering system the least significant 1 (the
rightmost character) is equal to base 16 to the zero power. Anything to the 0 power is 1 so the
rightmost character is 1 times 1. The most significant character or leftmost character is also 1, which
represents base 16 to the first power, or 16. 16 times 1 is 16. So, 16 + 1 is seventeen decimal.
4 - 14
14
IP Behavior – SANS

©2001
TCPdump Review
• TCPdump “sniffs” packets off the network
• It dumps the packets in a standard output format
depending on protocol
• UDP packets may or may not have “udp” in the
output
• TCP packets are distinguishable because of flags
• ICMP packets will have the ICMP message description
• TCPdump can display records in hexadecimal format
Slide “TCPdump review” wraps up what we have learned in section 1 about TCPdump. TCPdump
can sniff packets off of the network. It dumps the packets in a standard output format depending on
the protocol – tcp, udp, or icmp. As you saw, UDP datagrams may be labeled as UDP – although
this is not always guaranteed. TCP segments are distinguishable because of flags, and other fields
such as the sequence and acknowledgement numbers, to name a few. ICMP messages will have the
ICMP message description contained in them.
4 - 15
15
IP Behavior – SANS
©2001
TCP Concepts
TCP is a connection-oriented reliable protocol.
In section 2, we will examine some TCP concepts. Remember TCP is a connection-oriented reliable
protocol.
4 - 16
16
IP Behavior – SANS
©2001
Establishing a TCP Connection
TCP requires a three-way handshake between the client and server before a

connection can be established and data transferred
Client Server
Send SYN
Receive
SYN/ACK
Send ACK
Receive SYN
Send
SYN/ACK
Receive ACK
Connection Established
SYN
SYN + ACK
ACK
Turning to the slide “Establishing a TCP connection, you will see that establishing a TCP connection is
almost ceremonial in nature involving what is commonly known as the three-way handshake. This is required
before any data can be passed between the two hosts. What is depicted is the client or source host initiating a
connection to the server or destination host. Because this is tcp, a port or service must be identified to which
to connect. Examples of destination ports might be 23 or telnet, 25 or sendmail, or port 80 also known as http
or the web server port. Ports are simply another way of establishing discrete connections so that each computer
can keep track of what connections they have to whom.
For the TCP three-way handshake, first the client sends a SYN to signal a request for a TCP connection to the
server. Second, if the server is up, offers the desired service, and can accept the incoming connection, it sends
something back. It will send a connection request of its own to the client and acknowledges the clients initial
connection request with an ack [short for acknowledgement bit], all in a single packet. At this point the
second step of the TCP three-way handshake is completed.
Finally, if the client receives the SYN and ACK and still wants to continue the connection, it sends a final lone
ACK to the server. Once the server receives the ACK, the connection has been established. Data can now be
exchanged between the two. Once the connection is established, you will often see the ACK bit set, as much as
possible, ACKS are "piggy-backed" onto packets with data to minimize traffic as opposed to sending a packet

with just an ACK. The acks serve to confirm to the client and server that the connection is still being used by
both.
4 - 17
17
IP Behavior – SANS
©2001
TCPdump Output of TCP Connection
Establishment
07:09:43.368615 download.net 39904 > ftp.com.21: S
733381829:733381829(0) win 8760 <mss 1460> (DF)
07:09:43.370302 ftp.com.21 > download.net.39904: S
1192930639:1192930639(0) ack 733381830 win 1024 <mss
1460> (DF)
07:09:43.370355 download.net.39904 > ftp.com.21: . ack 1 win
8760 (DF)
Client ACK
Server SYN/ACK
Client SYN
The TCPdump output on the slide “TCPdump output of TCP connection establishment”
shows the connection establishment. There are three TCP segments shown. A TCP segment
contains the information sent by TCP to IP. In the first segment, you see the client, download.net
attempt a connection to the ftp server, port 21, of ftp.com. You see the SYN flag set followed by the
Initial Sequence Number, 733381829, and the same ending sequence number, zero bytes in the
parentheses. Following that you see the TCP options - in this case a window size of 8760 and a
maximum segment size (mss) that it advertised to the server. The window size of 8760 says that the
client has an 8,760 byte buffer for incoming data to this connection. The maximum segment size
informs the destination host that the physical network on which this download.net resides should not
receive more than 1460 bytes at a time. So, in this case even though the client, download.com is
capable of accepting 8,760 bytes of data, the physical medium on which it resides, most likely
Ethernet, cannot accept more than 1460 bytes for a TCP segment size.

In the second segment, you see ftp.com send a SYN and an ACK to download.com informing it
that it is available and a willing participant in this connection and to establish one of its own as well.
ftp.com informs download.net of its initial sequence number, 1192930639. This is also the ending
sequence number because no data is sent. This is normal for the SYN/ACK packets. The number
following the ACK is the acknowledgement number, in this case 733381830. Note that this value is
the initial sequence number advertised by download.com in the first record 733381829
incremented by a count of one because the segment with the initial SYN consumed one sequence
number. ftp.com has just acknowledged that it received the segment with the SYN flag set from
download.com. ftp.com advertises its options - a window size of 1024 and a maximum segment size
of 1460.
In the final line, download.net sends the final lone ACK to ftp.com and acknowledges receiving
the one byte containing the SYN/ACK flags from ftp.com. Right after the destination part, following
the colon, you’ll see a period. Remember this was the placeholder value when none of the PUSH,
RESET, SYN, or FIN bits is set.
4 - 18
18
IP Behavior – SANS
©2001
Server and Client Ports
• Server or well-known ports historically are ports
numbered 1-1023; these do not change on the
server
• Client ports, also known as ephemeral ports,
historically are numbered greater than 1023; these
ports generally change per TCP connection
• Before the client initiates a connection request to the
well-known server port (sends a SYN), it selects an
unused ephemeral port on which to communicate
• For most TCP protocols, the client and server
communicate the entire session using the client’s

ephemeral port and the server’s well-known port
Moving ahead to the slide “Server and client ports” we introduce server and client ports. In the past, more
so than today, well-known server ports generally fell in the range of 1-1023. Historically, under Unix only,
processes running with root privilege could open a port below 1024. These ports should remain constant on
the host on which they are offered. In other words, if you find telnet at port 23 on a particular host one day,
you should find it there the next day. You will find many of the older well-established services in this range of
1-1023 such as telnet, or sendmail port 25. Today, some of the newer services such as Lotus Notes, TCP
port 1352, don’t tend to conform to this original convention. This is partially because there are more services
than numbers in this range today.
Client ports, often known as ephemeral ports, are selected only for that particular connection and are reused
after the connection is freed. These are generally numbered greater than 1023. When a client initiates a
connection to a server, an unused ephemeral port is selected. For most services, the client and server continue
to exchange data on these two ports for the entirety of the session. This connection is known as a socket pair
and it will be unique. That is, there will be only one connection on the Internet that has this combination of
source IP and source port connected to this destination IP and destination port.
There may be another user connection from another source IP to this same destination IP and destination port,
but that user will have a different source IP and most likely different source port. There may even be someone
from the same source IP connected to the same destination IP and port. But, this user will be given a different
ephemeral port thus distinguishing it from the other connection to the same server and destination port. For
instance, two users on the same host may be connecting to the same web server. While this is the same source
IP, the same destination IP and port (80), the web server will be able to maintain who gets what by the
ephemeral source ports involved.
4 - 19
19
IP Behavior – SANS
©2001
TCPdump Output of Client/Server
Port Communication
07:11:01.209928 sendit.net.39905 > mailserver.com.25: S
743211991:743211991(0) win 8760 <mss 1460> (DF)

07:11:01.211211 mailserver.com.25 > sendit.net.39905: S
1202779586:1202779586(0) ack 743211992 win 8760 <mss
1460> (DF)
07:11:01.211254 sendit.net.39905 > mailserver.com.25: . ack 1 win
8760 (DF)
= ephemeral port 39905
= server port 25
On the slide “TCPdump Output of Client/Server Port Communication” you’ll see TCPdump
output of the three-way handshake again. This time, the emphasis is on the port selection and not so
much the TCP flag settings. The client sendit.net has selected ephemeral port 39905 on which to
communicate with mailserver.com on its well-known sendmail port 25.
When mailserver.com responds to the SYN request, it communicates on port 25 to the sendit.net port
39905. Lastly, when the final ACK is sent, the ephemeral port 39905 and port 25 remain the same.
If data is exchanged, it will be done on these two ports. Not until after the connection is closed and
some time has passed, will client port 39905 be freed up for use by another TCP client on sendit.net.
Port 25 of mailserver.com will remain bound to the sendmail service.
4 - 20
20
IP Behavior – SANS
©2001
Connection Termination
• Connection termination can be done “gracefully”
when the client or server initiates a normal session
close
– This is done by having either the client or server send a FIN
to the other. The FIN signals the desire to terminate the
connection; the other side must close its connection too by
sending a FIN.
• Connection termination can be done more abruptly
when the client or server aborts the session

– This is done by either the client or server sending a RST to
the other - signaling the desire to abort the connection
immediately.
On the slide “Connection Termination” we discuss closing a connection. There are two ways of terminating
a session, the graceful method or the abrupt method.
When the graceful method is conducted,
• One of the hosts, either the client or server, will signal with a FIN to the other that it wants to terminate the
session.
•The receiving host will signal back with an ACK or acknowledge the request. This only terminates half the
connection.
•Then, the other host will have to initiate a termination as well. It will send a FIN to the initial host.
•The receiving host will then need to acknowledge this and send an ACK back.
Both sides need to initiate a FIN and acknowledge the other’s FIN because TCP is full duplex; this means that
there are two connections established: One from the client to the server, and one back from the server to the
client. Both the client and server send data in an asynchronous manner so both sides of the connection have to
be individually terminated.
The second method of termination is an abrupt halting of the connection. This is done by one host sending the
other a RESET. This signals the desire to abruptly terminate the connection.
4 - 21
21
IP Behavior – SANS
©2001
TCPdump Output from Graceful
Connection Termination
Client initiates a close with a FIN, server does an ACK
07:15:54.796413 sendit.net
.39905 > mailserver.com.25: F 14:14(0) ack
186 win 8760 (DF)
07:15:54.797241 mailserver.com
.25 > sendit.net.39905: . ack 15 win

8760 (DF)
Server initiates close with a FIN, client does an ACK
07:15:54.798865 mailserver.com
.25 > sendit.net.39905: F 186:186(0)
ack 15 win 8760 (DF)
07:15:54.798896 sendit.net
.39905 > mailserver.com.25: . ack 187 win
8760 (DF)
Examining the slide “TCPdump Output from Graceful Connection Termination” we see the
two-way graceful termination. sendit.net signals the intent to terminate the connection with
mailserver.com by sending a FIN. mailserver.com acknowledges the termination and the session is
half-closed. The second half of the close must now be completed.
In the second record, the server mailserver.com signals the intention to close by sending a FIN to the
client sendit.net. sendit.net acknowledges receipt of the close and this connection is terminated.
After a time, the ephemeral port 39905 will be recycled for reuse.
4 - 22
22
IP Behavior – SANS
©2001
TCPdump Output from an Aborted
Connection
client.com.38060 > telnet.com.telnet: S 3774957990:3774957990(0) win
8760 <mss 1460> (DF)
telnet.com.telnet > client.com.38060: S 2009600000:2009600000(0) ack
3774957991 win 1024 <mss 1460>
client.com.38060 > telnet.com.telnet: .ack 1 win 8760 (DF)
client.com.38060 > telnet.com.telnet: P 1:28(27) ack 1 win 8760 (DF)
telnet.com.telnet > client.com.38060: P 1:14(13) ack 1 win 1024
telnet.com.telnet > client.com.38060: P 14:23(9) ack 28 win 1024
client.com.38060 > telnet.com.telnet: R 28:28(0) ack 1 win 8760 (DF)

The slide “TCPdump Output from an Aborted Connection” shows an aborted connection. This
depicts the beginning of a normal session where client.com connects to telnet.com on the telnet port.
Data is exchanged between the hosts. The line in bold shows client.com as it aborts the connection
to telnet.com. It sends a RESET to telnet.com to signal the intent to terminate immediately. There is
no further communication between the two hosts after the abort.
4 - 23
23
IP Behavior – SANS
©2001
Connection establishment ephemeral port
client.com.38060 > telnet.com.telnet: S 3774957990:3774957990(0) win 8760 <mss
1460> (DF)
telnet.com.telnet > client.com.38060: S 2009600000:2009600000(0) ack 3774957991
win 1024 <mss 1460>
client.com.38060 > telnet.com.telnet: .ack 1 win 8760 (DF)
Data Transfer
client.com.38060 > telnet.com.telnet: P 1:28(27) ack 1 win 8760 (DF)
telnet.com.telnet > client.com.38060: P 1:14(13) ack 1 win 1024
telnet.com.telnet > client.com.38060: P 14:23(9) ack 28 win 1024
Connection Termination
telnet.com.telnet > client.com.38060: F 4289:4289(0) ack 92 win 1024
client.com.38060 > telnet.com.telnet: .ack 4290 win 8760 (DF)
client.com.38060 > telnet.com.telnet: F 92:92(0) ack 4290 win 8760(DF)
telnet.com.telnet > client.com.38060: .ack 93 win 1024
TCPdump Output of an Entire TCP Session
Advancing to the slide “TCPdump Output of an Entire TCP Session” we show a full TCP session. The data
transfer portion shown has been abbreviated due to space limitations. First there’s the three-way handshake including
the ephemeral port selection of 38060 by client.com to the telnet port of server telnet.com. We see client.com
advertising the initial sequence number of 3774957990, a window size of 8760, and a maximum segment size of 1460.
The server responds with a sequence number of its own 2009600000, a window size of 1024, and a maximum segment

size of 1460.
On the first record of the data transfer, we see the P for PUSH flag. It says to send data immediately instead of
waiting for more data to be sent and buffering it in a more efficient transfer size. In a service like telnet, expedient
response time is the priority rather than optimally-sized data transfers. In the 3 separate PUSH transfers, we see 27 TCP
data bytes transferred by the client to the server, then 13 from the server to the client, and finally 9 from the server to the
client again.
On the first PUSH, we see the relative beginning sequence number of 1 and an ending sequence number of 28.
Recall that the ending sequence number was the beginning sequence number plus the data bytes, in this case 27. If we
relate this back to the absolute sequence number, client.com selected an ISN of 3774957990. The current relative
sequence numbers of 1:27 represent 3774957990 plus 1 or 3774957991 as the absolute beginning sequence number and
the absolute ending sequence number would be 3774957991 plus 27 which is 3774958018.
In the second line of data transfer, you see the server, telnet.com, send 13 bytes of data to client.com. Again, this
is using relative sequence numbers. This time the absolute initial sequence number is 2009600000, since we’re talking
about the telnet.com server. We can then use that number to figure out the telnet.com server's current absolute sequence
number. The absolute beginning sequence number would be 2009600001 and the ending sequence number would be 13
bytes more than this, which is 2009600014.
In the third line of the data transfer, you see the server, telnet.com, send 9 bytes. So the running total of relative
sequence numbers continues. The previous ending byte was 14, so counting resumes there. The next range of bytes
sent is 14 through 23.
In the connection termination, we see a two-way close beginning with telnet.com and acknowledged by
client.com. Then client.com initiates the second part of the close by sending a FIN, which is acknowledged by
telnet.com.
4 - 24
24
IP Behavior – SANS
©2001
TCP Concepts Review
• TCP must first complete a three-way handshake
before a session can begin
• The session is conducted between the client’s

ephemeral port and the server’s well-known port
• There is a very distinct protocol to terminate a
connection, different for a graceful termination and
an aborted session
• A TCP session consists of three main parts - session
establishment, data transfer, and session termination
This concludes section 2 on TCP concepts. We review what we’ve learned on the slide “TCP
Concepts Review.” We’ve learned that the first part of a TCP connection involves the three-way
handshake. The connection is conducted between the two hosts using an ephemeral port for the
client and a well-known port for the server. There are distinct protocols to terminate a session – one
that is graceful, another that immediately aborts the connection. Finally, a TCP session consists of
three parts; session establishment, data transfer, and session termination.
By now you should be familiar with the "look and feel" of TCPdump traces and how TCP works. I
thank you for your attention, and if you are taking this course for credit, please prepare for the quiz.
4 - 25
25
IP Behavior – SANS
©2001
Course Revision History
v1.3 – 19 Nov 1999
v1.4 – edited by K. Rosenthal – 11 Feb 2000
v1.5 – edited by F. Kerby and J. Kolde – 17 Aug 2000
v1.6 – edited by J. Kolde, adjusted grayscale for b/w printing – 22 Nov 2000
v1.7 – edited by F. Kerby – 25 Nov 2000
v1.8 – edited by F. Kerby, minor changes – 15 Jan 2001
v1.9 – updates, additions and edit by E. Cole – 07 May 2001
v2.0 – edited/formatted by J. Kolde – 12 May 2001
v2.1 – edited and audio recorded by C. Wendt – 27 June 2001
v2.2 – updates E.Cole – 10 Aug 2001
v2.3 – updated E. Cole – 1 Nov 2001

v2.4 – edited and audio recorded by C. Wendt – 14 January 2002