Tài liệu Step by Step Analysis pptx

• IP filter looks for IP datagrams with more fragments flag set and zero fragment offset • So we see only first fragment • Need to verify if this is normal or malicious These records app

Step by Step Analysis

All material Copyright  Novak, 2000, 2001 All rights reserved

2

Step by Step Analysis

• Introduction to tcpdump

• Writing tcpdump Filters

• Examination of Datagram Fields

• Beginning Analysis

• Real World Examples

• Step by Step Analysis

This page intentionally left blank

3

Objectives

• Allow you to participate in the analysis process

• tcpdump event of interest will be displayed

• We’ll walk through the analysis process complete with missteps to see how it is actually done

In this section, we’ll examine the practical day-to-day aspects of analyzing traffic

• IP filter looks for IP datagrams with more

fragments flag set and zero fragment offset

• So we see only first fragment

• Need to verify if this is normal or malicious

These records appeared on the hourly wrap-up because ip.filter examines the IP header for any datagram that has the more fragments flag set and a zero fragment offset This will display only the first fragment The reason that this was done was to alert you of the fragmentation, yet not

overwhelm you with all the records

As mentioned before, fragmentation can be a normal by-product of a datagram travelling from a larger to a smaller network We’ve also seen where fragmentation can be used for malicious purposes such as denial of service We need to examine this fragmentation to see if it appears to be normal - no overlaps or gaps in fragments and a complete fragment train

6

Dump Fragmented Records

• We attempt to see the other fragments using the

following command:

tcpdump –r tcpdumpfile ‘host 1.2.3.4 and port 2444’

In an effort to dump the records associated with this fragmentation, we examine the hour in question with a filter of the host IP and the destination port number We use the port number to isolate the traffic we saw in case there are more connections to other ports that we don’t care to see

8

Re-examination

• tcpdump output on the previous slide appears to

indicate only first fragment was sent

• Is this some kind of malicious attack or denial of

service that sends only an initial fragment?

• Examine filter used to select records, we used

‘host 1.2.3.4 and port 2444’

• Remember subsequent fragments don’t carry

UDP header with port number

Because we only see the first fragment of the fragment train, the initial guess is that this may be some kind of malicious fragment attack perhaps a denial of service We should see all fragments in the fragment train, not just the first

However, if we re-examine the filter we used, we qualified the traffic by port number The port number is located in the UDP header Recall from the discussion on fragmentation that only the first fragment in the fragment train inherits the protocol header, or UDP in this case All subsequent fragments only carry the remaining UDP data Therefore, when we search by port number, only the first fragment appears

9

Another Attempt

• We make another attempt to dump the

fragmented records, but we search by IP number

only

tcpdump –r tcpdumpfile ‘host 1.2.3.4’

Attempting to dump the traffic again, we filter by source IP only The source IP is located in the IP header and will be found in all the fragments

Look at the second set of fragments with fragment ID 28843 The first fragment is 1480 bytes and the offset is byte 0 The second fragment starts at byte 1480 and has a length of 1480; this is normal Finally, the third fragment begins at the expected offset of 2960 for a length of 898 bytes.

11

Assessment

• If you examine the fragmentation, the fragments

and offsets appear to be normal

• This is a false positive

• When examining fragmented packets, use a filter

that looks at the IP address and perhaps protocol

type

• Using a filter that involves the protocol header

may yield incomplete or misleading results

So, the assessment of this traffic is that it is a false positive; the fragmentation does not appear to be corrupted in any way The lesson to be learned from this is when you are dealing with

fragmentation, make sure that you filter for fields found in the IP header only If you try to examine protocol fields, in this case, the UDP port number, you will receive incomplete data and you may come to false conclusions

12

Event of Interest 2

• The following records were dumped when 1.2.3.4

appeared in the Shadow’s scan output

• An unsolicited SYN/ACK can trigger a RESET by

the receiving host

• Possible way to scan for live hosts?

A good initial guess is that this is some kind of scan originating from hostile host 1.2.3.4 An unsolicited SYN/ACK combination to a destination host regardless of whether the scanned port is active or not may elicit a RESET This would be a method of finding live hosts in the network and possibly eluding any filtering router that has an access control statement which requires inbound traffic to be established inside the network In other words, only inbound traffic with the ACK flag set will be allowed in

• Is it possible someone is spoofing our 192.168

IP’s and sending them to port 113 of 1.2.3.4?

• Host 1.2.3.4 responds with a SYN/ACK directed

back to actual 192.168 network

Now, if you take a slightly different approach to viewing this traffic, it may appear that 1.2.3.4 was simply an intermediate or victim host What may be happening is that some malicious party for whatever reason may be spoofing the internal 192.168 IP addresses and sending them to host 1.2.3.4 port 113 If port 113 is listening, it will reply with a SYN/ACK to the alleged source IP

Port 113 is known as auth or ident It is used to authenticate a user requesting a service For instance, when connections to some servers are made, for example sendmail, the server may try to connect to the client host on port 113 This is a rather primitive way of trying to authenticate the user Not all servers query for port 113 and not all clients will offer port 113

We see no RESETs from the 192.168 hosts because they are not live hosts

15

More Clues

• In order to get a SYN/ACK response back from

1.2.3.4 on port 113, port 113 must be active

16

Assessment

• This may be spoofing or network scanning

• Try to communicate with the contact of 1.2.3.4

We have not positively identified the nature of the scan You will find often times that there may be

no definitive answer This was an example to help you view what may appear to be an obvious scan from 1.2.3.4 in another way If you can identify the network contact for 1.2.3.4, you can try to see if they have been seeing traffic from the 192.168 network directed at them If they can confirm this, it means that someone is spoofing the internal IP’s It is also possible someone is spoofing 1.2.3.4 as a source IP so they may not even be able to confirm outbound traffic to the 192.168 network

• Dump the records for the foreign IP

tcpdump –r tcpdumpfile ‘host 1.2.3.4’

We see an initial SYN from a foreign host and would like to examine all the traffic from the unknown source host So, we dump the hourly records for the foreign IP 1.2.3.4

18

Partial Results

• Here is one TCP session extracted by looking at

the data exchanged between the hosts:

• Is it possible that the sensor is seeing only

inbound traffic and it takes a different route

outbound?

A first assessment might be that we are seeing crafted packets from hostile host 1.2.3.4 In other words, the hostile host is sending what appears to be a partial session to myhost.com If this were so, myhost.com should reply with some kind of RESET since it is not expecting this activity We do not see this so that rules out this guess

For this particular session, we are seeing only inbound traffic Is it possible that the sensor is capturing this traffic inbound and fails to capture outbound traffic because it may have a different egress point? This is a better possibility than the first

21

Another Assessment

• See evidence in previous slide that we are

capturing some traffic outbound from

myhost.com

• Appears we have some kind of intermittent

sensor capture

• Dropping packets on the sensor?

• Multiple ingress/egress points and we see only

traffic that passes by the sensor on a given

22

Event of Interest 4

• The following output appears in the hourly wrap-up:

05:52:23.040000 wiley.ns.demon.net.15770 >mydns.com.80: udp 4294967289

• What kind of mutant behavior is this record exhibiting?

• What tools/scripts can we use to discover what is

going on?

We examine a record that appears in the hourly wrap-up because of some filter that we have refined

to look at UDP traffic Look at the record closely and try to determine what the anomalous behavior may be that caused it to become an event of interest

Begin to think about what tools can be used to investigate this

23

Mutant Behavior

wiley.ns.demon.net.15770 >mydns.com.80: udp 4294967289

• UDP datagram length reported as 4294967289

• What is wrong with this length?

• Maximum length value for UDP is a 16 bit field

• 216 - 1 = 65,535

• How can a datagram of this alleged length be

sent without fragmentation?

• What can we do to investigate this?

We detect some output from Shadow that appears to be abnormal There is a value of 4294967289

in the UDP length field There are a couple of problems with this The first is that the UDP length field is a 16 bit value in the UDP header The maximum possible value for a length would be 65,535 How could tcpdump possibly report such a large value?

Also, how is it possible that fragmentation did not occur with a UDP datagram length so large?What tools have we covered in this course to help us assess what is happening?

24

Investigation

• First, check traffic from the hostile source IP for

the hour in question

• Could there be some kind of catalyst for receiving

this datagram?

tcpdump –r tcpdumpfile ‘host hostile IP ’

The first thing we do is examine the traffic for the hour in question This will just help us put the traffic in some kind of context It may not explain the mutant UDP datagram length, but we might

be able to see why this record appeared

Note that we search using the hostile IP number for wiley.ns.demon.net Searching by IP is more efficient and perhaps more accurate since additional resolution does not have to be done If resolution cannot be done for wiley.ns.demon.com, no records will appear even though there are records in the tcpdump files for the IP number associated with wiley.ns.demon.com

25

Results From tcpdump

05:52:21.560000 mydns.com.domain > wiley.ns.demon.net.domain: 25303 (38) (DF)

05:52:21.650000 wiley.ns.demon.net.domain > mydns.com.domain:

25303*-1/3/3 (176)

05:52:22.530000 mydns.com.domain > wiley.ns.demon.net.domain: 25329 (38) (DF)

05:52:22.630000 wiley.ns.demon.net.domain > mydns.com.domain:

25329*-1/3/3 (176)

05:52:22.940000 mydns.com.domain > wiley.ns.demon.net.domain: 25333 (34) (DF)

05:52:23.040000 wiley.ns.demon.net.15770 > mydns.com.80: udp 4294967289

What we see is that the mutant record appears amidst a stream of seemingly normal DNS traffic between mydns.com and wiley.ns.demon.net The pattern appears to be that mydns.com queries wiley.ns.demon.net for some kind of DNS resolution In the first two queries wiley.ns.demon.net responds appropriately to the queries

On the fifth line of the output, mydns.com queries again with DNS message number 25333 Soon thereafter, wiley.ns.demon.net responds with an inappropriate packet There is no response to query

25333, however there is an attempted probe of mydns.com on port 80 with a very large length

26

More Investigation

• The output from the looking at the hour’s data

didn’t explain the large UDP length

• How can we view the UDP datagram length?

So, we just saw the traffic that may have elicited this mutant datagram, but this still doesn’t explain why the length was so large To look at the datagram length in its native form, we must examine the datagram in hexadecimal

We examine the UDP datagram length by dumping the datagram in hexadecimal We also try to zero

in on the exact record using the port number in the mutant record This will prevent us from

dumping all the previous traffic between those two hosts Since we are not dealing with fragmented packets, we can look at the protocol header fields such as the port number and get accurate results

28

Hex Results

4500 00c8 58d2 0000 3411 f19c 9e98 0141 83da 1803 3d9a 0050 0001 a3c7 0904 18ba

5010 2238 27b5 0000 0469 6373 7705 6465 6d6f 6e02 636f

IP Header

UDP datagram length

Examining the hexadecimal, we see in the UDP header that the length is 1 byte long What is wrong with this value? Remember that the UDP header has fields such as the source and destination ports These ports, if you recall, have a range of values from 1 to 65,535 How many bytes are needed to represent the maximum value of 65,535? 216-1 represents two 8 bit fields or 2 bytes for each port Minimally, you can see we need at least 4 bytes in the UDP header to represent the port fields

29

Assessment

• Actual datagram has a UDP length of 1

• Minimum UDP length 8 - UDP header requires 8

bytes

• UDP length field has been crafted

• tcpdump does not have any error checking rules

when it attempts to compute decimal UDP length

• tcpdump algorithm used to compute UDP length

is inaccurate when the UDP length is less than 8

• May be some kind of reconnaissance or denial of

service on internal DNS server

What appears in the datagram is the actual length of the UDP datagram This has been crafted because a true minimum datagram length is 8 bytes The UDP datagram length includes the UDP header; there are always 8 bytes in the UDP header

The culprit in translation of the UDP datagram length appears to be tcpdump tcpdump must not do error checking before trying to compute the UDP length Somehow, the algorithm goes awry on computation and we end up with the wrong UDP length

What was the 1 byte UDP length all about anyway? And why did wiley.ns.demon.net send a UDP datagram on port 80? There are no confirmed answers Perhaps this is intended as some kind of denial of service - we just don’t know Again, whatever it is, chances are it is not for the good of mankind

30

Event of Interest 5

12:29:48.230000 4.3.2.1.1049 > 172.16.54.171 3128 : S 9779697:9779697(0) win 8192 <mss 1460> (DF)

12:29:58.070000 4.3.2.1.1049 > 172.16.54.171 3128 : S 9779697:9779697(0) win 8192 <mss 1460> (DF)

12:30:10.960000 4.3.2.1.1049 > 172.16.54.171 3128 : S 9779697:9779697(0) win 8192 <mss 1460> (DF)

12:46:16.080000 1.1.1.1.2262 > 172.16.99.110 3128 : S 20315949:20315949(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)

12:46:22.070000 1.1.1.1.2262 > 172.16.99.110 3128 : S 20315949:20315949(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)

The following output appeared in the hourly wrap-up We saw many more similar scans to port

3128 each hour This appears to be a scan of port 3128 of different inactive hosts It also appears that there are multiple retries to each host since they don’t appear to be responding