Tài liệu Traffic Analysis Techniques 2 doc

Trang 1

Traffic Analysis Techniques 2

Basic traffic characteristics:

– To, From, Date, Time – Service, Type, or Class – Sequence numbers, Sets, Patterns – Weight or Severity

– Size

Welcome to the second half of our study of the fundamentals of traffic analysis In the first part of this topic, we discussed some of the basic characteristics that we pay particular attention to when performing traffic analysis: To, From, Date, Time, Service, Type, Class, Sequence Numbers, Sets and Patterns Now let’s build on that foundation by adding weight, severity and size to our list of analysis dimensions

Trang 2

Penetration technique by splitting the header into two parts.

Detect and analysis by Brian Betterton, GCIA:

“History: None previously observed.

Techniques: This was a host port scan using tiny fragments.

Targeting: Absolutely! This source has targeted my firewall specifically, null scanning using tiny

fragmented packets They are attempting to go unnoticed

Analysis: The intruder is probably using nmap, running a null scan, such as in Detect 3 The

difference here is they are also using tiny fragmented packets to try to elude notice It worked in this case, as my firewall did not log these

Severity Level: (Critical + Lethal) – (System Countermeasures + Net Countermeasures) = Severity

Level

This is a firewall (5), but the attack is unlikely to succeed (1) The firewall did not log these

fragments, so I’ll use an average value for network countermeasures

(5 + 1) – (5 + 3) = < 0”

When looking at fragmented traffic, some questions you should ask yourself are:

•Are the fragments too small?

•Do the fragments have the right offsets? Do the fragments overlap each other, or are there gaps between the fragments?

•What is the purpose of the fragmentation?

Trang 3

20:10:49 172.16.82.11.6221 > hosta.1: S

20:10:49 172.16.82.11.6220 > 255.255.255.255.1: S 20:10:52 172.16.82.11.6222 > hostb.1: S

20:10:53 172.16.82.11.6289 > hostc.1: S

20:10:53 172.16.82.11.7300 > hostd.1: S

Trace with complete header shown on notes pages

Key to understanding:

We tend to focus on destination ports, but here we see

that source ports also have a story to tell.

Scan for TCPMUX

Indicator of a burst on system

Here is another scan; all attempts are made to destination port 1, TCPMUX What makes this scan interesting is the source ports Look at the first three lines on the slide According to the timestamps, they occur during a three-second period The source port numbers are 6220, 6221 and 6222 This implies that no other connections were being initiated by the source system during that time

Now look at the fourth line It was logged only a second after the third line, yet the source port has increased from 6222 to 6289 When we look at the fifth line, which was logged during the same second as the fourth line, we see that the source port has really jumped – from 6289 to 7300 This is evidence of a large burst of network activity on the source system – over 1000 ports issued during a second

20:10:49 172.16.82.11.6221 > hosta.1: S 3072319638:3072319638(0) win 51220:10:49 172.16.82.11.6220 > 255.255.255.255.1: S 2109566624:2109566624(0)win 512

20:10:52 172.16.82.11.6222 > hostb.1: S 1729073814:1729073814(0) win 3212020:10:53 172.16.82.11.6289 > hostc.1: S 957786113:957786113(0) win 3212020:10:53 172.16.82.11.7300 > hostd.1: S 4288288149:4288288149(0) win 32120

Trang 4

NOTE: Slow arrival and two address families; this scan is

probably interleaved across multiple addresses.

Original IMAP (TCP 143) Script

This example shows a classic IMAP scan What dimensions are shown here? Remember, the basic traffic external dimensions are:

• To, From, Date, Time

• Service, Type, or Class

• Sequence numbers, Sets, Patterns

• Weight or Severity

• Size

The static source port of 10143 introduces the notion of a signature attack This is the source port that was used on the original IMAP exploit reported to Bugtraq This makes it really easy to detect when this exploit script is used, which is becoming rare

Other dimensions in the example include: time, to, from, service, and patterns Note both the destination network IDs and that only SYN packets were used

Trang 5

No attack here Window sizes can be negotiated during

the TCP conversation; this was just one of the nicest

examples of this I have ever seen.

Negotiating Window Sizes

Not every trace that we look at is an attack or a probe The example in this slide shows two hosts negotiating the TCP window size The window size is used to restrict the flow of packets by limiting the number of packets that have been sent but not yet acknowledged This is perfectly normal behavior; however, if you are not familiar with window sizes, this may look suspicious to you

Trang 6

Sequential, Temporal, Service Dimensions

• Sequence numbers as patterns

• Sequence numbers as signatures

• Time data for ordering

• Time data for correlation

• Service or application

So far, we have studied traffic analysis through its external dimensions, such as To, From, and Service Although dissecting the traffic using the external dimensions is certainly the heart of traffic analysis, there are other dimensions that can be used as well

First, there are sequential dimensions – thinking of sequence numbers as patterns or as signatures We have already discussed this to some extent, but we will expand on this concept in the coming slides

Another way of analyzing data is by studying its temporal dimensions – using time data for ordering or for correlating events

A final way of examining the traffic is by using the service dimensions – focusing on a particular service or application

Trang 7

10:16:58.602949 scanr.1869 > 172.20.211.0.137: udp 5010:16:58.603041 scanr.1869 > 172.20.211.0.137: udp 5010:17:00.763690 scanr.1869 > 172.20.211.0.137: udp 50

10:17:02.175284 scanr.1750 > 172.20.211.0.echo: udp 81

10:51:57.583558 scanr.1869 > 172.20.211.0.137: udp 5010:51:58.624647 scanr.1869 > 172.20.211.0.137: udp 5010:52:00.175124 scanr.1869 > 172.20.211.0.137: udp 50

10:52:01.942465 scanr.1382 > 172.20.211.0.echo: udp 81

… Only echoes shown from here on in

10:55:22.696118 scanr.1385 > 172.20.211.0.echo: udp 8110:59:12.389749 scanr.1104 > 172.20.211.0.echo: udp 8111:04:12.879154 scanr.1041 > 172.20.211.0.echo: udp 81

11:10:39.223615 scanr.1539 > 172.20.211.0.echo: udp 81

NetBIOS and Echo

This scan is a mixture of NetBIOS and UDP echo service connection attempts The biggest anomaly here is that the scan is sent to the legacy broadcast address,

172.20.211.0 Windows systems will not answer these broadcasts, so it is not clear what the attacker’s intent is Perhaps he or she is confused, looking for a router, or possibly looking for a SAMBA system Since the source port for the NetBIOS

attempts is not 137, this indicates that something other than NBTSTAT is being used

by the scanning computer to generate this traffic

The pattern is stable across many packets – three NetBIOS-NS scans and then an echo The source port on the NetBIOS attempts is always constant, while the source port on the echo attempts changes each time So it appears that two separate

processes are running Note that the echo source port is descending until the final example, when it gets out of sequence This might be the clue that allows an analyst

to tie this pattern to some other piece of information, but it would be a long shot

Trang 8

Web (TCP 80) Example

15:05:15 surfer.1497 > server.http: S 28396544:28396544(0) win 8192 (DF)

15:05:16 server.http > surfer.1497: S 115698281:115698281(0) ack 28396545 win 8760 (DF)

15:05:46 server.1123 > surfer.1533: P 739781:741229(1448) ack 1823985720

win 8116 (DF)

15:06:09 surfer.http > server.1424: R 2572545643:2572545643(0) win 0

15:06:09 server.1348 > surfer.7777: SFR 3105729:3107161(1432) ack

688054539 win 8320 (DF)

15:06:29 surfer.1497 > webserver.http: F 340:340(0) ack 10221 win 8760

(DF )

More of the transaction is shown in the notes

Your turn: what is wrong with this picture?

15:05:15.880000 surfer.1497 > webserver.http: S 28396544:28396544(0) win 8192(DF)

15:05:16.100000 webserver.http > surfer.1497: S 115698281:115698281(0) ack

28396545 win 8760 (DF)

15:05:16.13 surfer.1497 > webserver.http: P 1:340(339) ack 1 win 8760 (DF)15:05:18.93 surfer.1496 > webserver.http: P 380:743(363) ack 73 win 8688 (DF)15:05:19.27 surfer.1496 > webserver.http: F 743:743(0) ack 73 win 8688 (DF)15:05:19.71 surfer.1496 > webserver.http: R 28354188:28354188(0) win 0 (DF)15:05:22.65 surfer.1497 > webserver.http: P 1:340(339) ack 1 win 8760 (DF)15:05:46.92 webserver.1123 > surfer.1533: P 739781:741229(1448) ack 1823985720win 8116 (DF)

15:06:09.39 surfer.http > webserver.1424: R 2572545643:2572545643(0) win 015:06:09.55 webserver.1348 > surfer.7777: SFR 3105729:3107161(1432) ack

688054539 win 8320 (DF)

15:06:29.99 surfer.1497 > webserver.http: F 340:340(0) ack 10221 win 8760 (DF)15:06:58.36 surfer.1497 > webserver.http: R 28396885:28396885(0) win 0 (DF)15:07:45.93 surfer.1491 > webserver.http: R 27843570:27843570(0) win 0 (DF)15:08:02.13 webserver.http > surfer.1490: F 5681:5681(0) ack 589 win 8173 (DF)

So what is wrong with this picture? It starts out innocently enough, with a user and a web server We see several different ports in use on the client’s machine, but that is typical of HTTP traffic, where different elements on a web page may each require their own connection This trace gets weird in the middle, when webserver’s port 1123 sends a PUSH/ACK to the user’s port 1533, the user sends a RESET from their port

80 to webserver’s port 1424, and webserver’s port 1348 sends a SYN/FIN/RESET to the user’s port 7777 Although it’s hard to tell exactly what’s going on, it appears that the surfer may have come across a malicious web site The web site could be probing the user’s machine, by attempting to contact it on common ports (HTTP, in this case) and by sending packets with odd flag combinations, such as

Trang 9

Your turn: pattern continues on notes pages None

of the hosts exist What can we tell from this pattern?

The pattern continued for weeks at multiple sites

So what can we tell from this pattern? We can see that these are sets of 4 connection attempts Within each set, the source and destination ports are the same, and the sequence numbers are fixed However, among the various sets of attempts, all the source ports are different, and all the sequence numbers are different So the signature is sets of 4 attempts with SYN only set to destination port 139; also, the window size is always set to 8192

These are most likely appearing in sets of 4 because of retries Note that there is a clear pattern in the timestamps within each set of 4 – the gap between attempts is 3 seconds, then 6 seconds, then 12 seconds Normally, when retries occur, the source ports and sequence numbers remain the same, as they do here

Trang 10

TTL

• In the notes pages are the Time To Live fields from the traces in the previous

slide Notice how they cluster around

120 This is not expected behavior This

is also fixed in the nmap 2.08 release ,

which has a decoy function so that the

decoy TTLs are random.

Analysis credit to Army Research Lab

Destination IP Address: 172.20.224.77

Expected Traceroute hops: 10

Expected Traceroute hops: 12-13

Trang 11

Treating Port Numbers as

Sequence Numbers

• Can we get meaningful information

by treating port numbers as

sequence numbers?

Let’s explore whether we can get meaningful information by treating port numbers as sequence numbers If you think about it for a minute, there are similarities between port numbers and sequence numbers Normally, their values are incrementing over time Certain protocols, such as FTP and HTTP, tend to use a lot of port numbers during any given session In these cases, it may make sense to use all of the port numbers as

sequence numbers in order to better analyze the traffic

Trang 12

If we compare SRC/DST pairs, the pattern is obvious

This slide shows a very vanilla FTP file transfer On the first line, C is establishing an FTP connection with goslo The source port called FTP-DATA (or TCP port 20, if you prefer) remains fixed during the file transfer, and the destination port for C is

incrementing by one

Note: FTP is rich in patterns caused by the large number of states in the protocol, as well as some curious implementations of it Grep “ftp|ftp-data” from a large volume of traffic and sit down with a cup of coffee for a half hour sometime

Trang 13

Comparison of Two FTPs

Bounce versus normal

SRC/DEST Port Pairs

0 2000

FTP Bounce pattern falls out fairly easily

Let’s look at two different FTP sessions, A and B The graph shows both sessions, with the packet number along the bottom and the port number along the side Both source and destination ports are included on the graph Here is the data that was used, showing the source and destination port pairs for the A and B sessions:

Trang 14

09/04/97 05:49:14 192.168.4.2 2051 -> smtp-ftp.swc.navy.mil 2109/04/97 05:49:17 192.168.4.2 2051 -> smtp-ftp.swc.navy.mil 2109/04/97 05:49:23 192.168.4.2 2051 -> smtp-ftp.swc.navy.mil 2109/04/97 05:49:35 192.168.4.2 2051 -> smtp-ftp.swc.navy.mil 2109/04/97 05:50:55 192.168.4.2 2055 -> smtp-ftp.swc.navy.mil 2109/04/97 05:50:58 192.168.4.2 2055 -> smtp-ftp.swc.navy.mil 2109/04/97 05:51:04 192.168.4.2 2055 -> smtp-ftp.swc.navy.mil 2109/04/97 05:51:16 192.168.4.2 2055 -> smtp-ftp.swc.navy.mil 21

TCP Port Sequence (FTP)

Failed connection

What we see above is probably a failure to make a connection The source host

(192.168.4.2) appears to be retrying four times As with our earlier example, the

timestamps are increasing by 3, 6 and 12 seconds in each set of 4 attempts Also, note the source port column values, 2051 and 2055 The source port is changing between each set of attempts, which means that this traffic is not being generated by a tool with a fixed source port

Trang 15

Failed - Successful Connection

Failed Versus Successful FTP

0 1000

Note the two patterns are fairly similar to one another

This graph shows sessions A and C, which we looked at on the last two slides A was a successful FTP attempt, while C was an unsuccessful FTP attempt that retried several times This is the data that was used for the graphs, with the numbers being source port / destination port pairs:

A: 20 1031 20 1032 20 1033 20 1034 20 1035

C: 2051 21 2051 21 2051 21 2051 21 2055 21

Notice how similar the two patterns are; both are alternating between values that do not appear to be changing (although the higher port numbers are actually changing very slightly)

Trang 16

All Three FTP Cases

Trang 17

This is the general pattern of a file transfer;

large http transfers are very similar.

Let’s expand our graph to include 3 more FTP sessions Sessions D and E are from successful FTPs, while session F is from a failed FTP Of the 6 sessions, the only one which is substantially different from the others is B, the FTP bounce attack Note that session F, where the file transfer failed, still doesn’t deviate from the expected pattern

Trang 18

B’s port scan is still obvious.

One of the problems that we face with intrusion detection is that there is a lack of good visualization support It bothers us too! We have found that using Perl to put commas

in the file allows us to suck the data we are evaluating into Excel so we can use its graphing functions Obviously, we only do this for cases where we don’t know what is going on Many times, the graphing will make the “oddball” pattern stand out In this case, by doing the cone graph in Excel, we can see that session B is clearly different from all the others

Tiêu đề	Traffic Analysis Techniques 2
Trường học	University of Technology Sydney
Chuyên ngành	Network Security
Thể loại	Giáo trình
Năm xuất bản	2000, 2001
Thành phố	Sydney

Định dạng
Số trang	36
Dung lượng	741,8 KB