IP Behavior - Part 1

Trang 1

Welcome back to the SANS GIAC LevelTwo TCP/IP course In this section, we introduce some more detail to topics discussed in the previous section, as well as introduce some new concepts all together

Trang 2

Trang 3

• You will also need to download libpcap.tar.Z

windumpis the Windows counterpart:

• Available at http://netgroup-serv.polito.it/windump

• libpcap available at http://netgroup-serv.polito.it/winpcap

In section 1, we will explore tcpdump

Trang 4

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 slide “tcpdump”, we see that tcpdump is a program that will read traffic on 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, either by collecting specified records, printing in a more verbose mode (-v), printing in hexadecimal (-x) or writing records as “raw packets” to a file (-w) instead of printing 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 collect records with a specific trait Examples of filters would be to collect only TCP records, or collect records 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

We see on this slide, a host running tcpdump and gathering records from the network interface We see the records that tcpdump has collected below 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

Trang 5

Sample tcpdump UDP output

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

If we examine a line of tcpdump UDP output on slide “Sample tcpdump UDP output”, we first see

a timestamp This is when the tcpdump host read the record 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 Redhat 5.2 operating system

on which this tcpdump record was collected, but this is corrected in more current Redhat releases

Next, we see before the greater than sign, 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 Next, the trace is followed by a period and the source port, in this case 728 Immediately following the greater than sign, you see the destination host or IP, 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 It is analyzed at the application layer so that is why you don’t see the word “UDP” Other protocols such as Simple Network Management Protocol (SNMP) and Network Time Protocol (ntp) are also analyzed at the application level tcpdump will analyze or decode traffic at the highest layer that it is familiar with

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

Trang 6

Sample tcpdump TCP output

timestamp source.port dest.port flags beginning: ending bytes window

seq # seq # 09:32:43.910000 nmap.edu.1173 > dns.net.21: S 62697789:62697789(0) win 512

flags: TCP flags ( PSH, RST, SYN, FIN)

beginning seq #: for the initial connection, this is the initial sequence number (ISN)

from the source IPending seq #: this is the beginning sequence number + data bytes

bytes: data bytes (payload) in the TCP packet

window size: nmap.edu receive window (TCP buffer)

Our next slide is titled “Sample tcpdump TCP output”, 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 is 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

Trang 7

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 titled “Absolute and relative sequence”, we show a handy feature of tcpdump Notice the top line, we have the number 3774957990 in bold That is an absolute sequence number

If we were to convert the field from hex stored in the actual record to decimal this is what we would come up with

Sequence numbers help us track 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 sequence

number has been consumed in the the TCP process for this connection When we look more closely

at TCP, we will see our friends absolute and relative sequence again

Trang 8

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

Trang 9

tcpdump output in hex

• Command line option -x displays records in

hexadecimal

• Hex more difficult to read and decrypt

• Shows entire IP datagram, even fields that tcpdump

doesn’t display in standard output

• “Entire” packet is shown using -s (snaplen)

Displaying output in hexadecimal 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

Trang 10

Sample hexadecimal output

ICMP message

Turning to slide “Sample hexadecimal output”, 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 value 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

Trang 11

Finding the protocol in the IP header

161x 1 + 160x 1 = 17

We get a feel for how this works by turning to 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 and 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

Trang 12

tcpdump review

• “Sniffs” packets off network

• Dumps packets in standard output format depending

on protocol

• UDP packets may or may not have “udp” in output

• TCP packets are distinguishable because of flags

• ICMP packets will have ICMP message description

• 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 as the sequence and acknowledgement numbers, to name a few ICMP messages will have the ICMP message description contained in them

Trang 13

TCP Concepts

Section 2

TCP is a connection-oriented reliable protocol

In section 2 we will examine some TCP concepts Remember TCP is a connection-oriented reliable protocol

Trang 14

Establishing a TCP connection

TCP requires a three-way handshake between the client and server before

a connection can be established and data transferred

Turning to 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

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 and offers the desired service, and can accept the incoming connection, it sends a connection request of its own to the client and acknowledges the client connection request with an ACK, 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 and accepts 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

Trang 15

tcpdump output of TCP connection

The tcpdump output on slide “tcpdump output of tcp connection establishment” shows the

connection establishment In the first record, 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 a window size of 8760 and a TCP option - maximum segment size (mss) that it advertises to the server The window size of 8760 says that the client has an 8,760 byte TCP 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 of TCP data at a time So, in this case even though the client, download.com is capable of accepting 8,760 bytes of data in its buffer, the physical medium on which it resides, most likely Ethernet, cannot accept more than 1460 bytes for

a TCP segment size

In the second record, 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 records 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 plus 1 ftp.com has just acknowledged that one sequence number was consumed from the download.com SYN ftp.com advertises its 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 sequence number consumed in the exchange of 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

Trang 16

Server and client ports

• Server or well-known ports historically ports numbered 1-1023

– These do not change on server

• Client ports, also known as ephemeral ports, historically

numbered greater than 1023

– These ports generally change per TCP connection

• Before client initiates a connection request to well-known server

port (sends a SYN), it selects an unused ephemeral port

• Most TCP protocols, client and server communicate entire

session using client’s ephemeral port and server’s well-known

port

Moving ahead to 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 on port 25 Today, some of thenewer 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

Tiêu đề	IP Behavior - Part 1
Tác giả	William Ralph Stephen Northcutt, Alan Paller, Judy Novak
Trường học	Unknown University
Chuyên ngành	Computer Security / Networking
Thể loại	lecture notes
Năm xuất bản	2001
Thành phố	Unknown City

Định dạng
Số trang	32
Dung lượng	542,84 KB