Tài liệu Traffic Analysis Techniques 1 pdf

Trang 1

Traffic Analysis Techniques 1

Traffic Analysis is a set of techniques for

arranging and visualizing data so that

patterns and relations can be identified,

tagged or tracked This course serves as a

primer for taking logfiles of virtually any

format, organizing the data and performing

the analysis.

This section of the course will concentrate on externals, the fields in the packet header more than the content The purpose of this section is to teach the analysis of packets based on their behavior and the fields I hope that you find the material in this section to be something that you can use as you analyze network traffic

Trang 2

Common External Dimensions

to analyze traffic However, there are times when a crafted unique value in an inherently

uninteresting field may provide some kind of signature For instance, sequence numbers when normally generated are not of much interest to us as analysts However, if we spy a static sequence number or even a repeated acknowledgement number from what appears to be a reply from a static sequence number, we may begin to see a pattern of some sort which will ultimately assist in the analysis

The more clues that you can find in the data, the more help you have in possibly explaining why you are seeing what you are seeing

Trang 3

In Geometry, height, length, and width are the three primary dimensions.

In traffic analysis, the primary dimensions are To, From, and Service These functional dimensions are part of the Traffic Analysis discipline There are a large number of IP specific dimensions as well that are important to analysis of IP traffic These include:

From, To, Service Are Primary

Events of Interest

• Where do our “hits” come from?

• Who/What are they targeting?

• Can we find evidence of crafted

packets?

When we work without content we

focus on “externals” “ From ” turns out

to be quite challenging and interesting.

Trang 4

We don’t know anything about

port 17434, but what do we notice

about this pattern?

Primary focus – destination port

Secondary focus – source port, time

Many times the analyst has fragmentary data I checked my entire databank and these ports did not show up There are programmable Trojans, but the prober appears to be looking for a service Are these spoofed IP addresses? Really, we can’t say with fidelity because this firewall sensor does not record TCP flags What we do see is the 4 attempt pattern, with repeated source ports; this is typical

of a retry This is NOT likely a denial of service; these source addresses do want to connect to a service

Here’s a simple example of traffic analysis User report is shown below:

Twice last week and again this week my network has been getting hit with some kind of what looks like a distributed attack The number of hits is limited (100-200), but has always employed what appears to be a number of spoofed IPs, and usually aimed at a high numbered port, only one port to

an attack, one attack a day So far they've been after ports 23702, 17434, and today 20931.

I'm enclosing a portion of my firewall logs Can you advise what I'm seeing? I don't believe I've

Trang 5

Note IRC in the hostname While 6666 is not the most

common IRC port (6667 is), it is a fairly common IRC port.

We see the packets coming from ircsrv They think they

are under attack from us, but aren’t.

Primary focus – source host and port

Secondary focus – acknowledgement #, TCP flags

an acknowledgement number of 674711610 We don’t have the timestamps to analyze how closely the third record is timewise to the first two records But, it appears that ircsrv can no longer reply or

is not listening on port 6666 and responds with a reset It is possible that someone is engaged in a SYN flood of ircsrv using ourhost as one among many decoy source IP numbers

Trang 6

ns2> 172.20.137.48: icmp: ns2 udp port 51 unreachable [tos 0xc0]

We see a response; where did the stimulus originate from?

We will probably never know We do know a name server

probably isn’t UDP flooding us on purpose!

Primary focus – source host, dest hosts

Secondary focus – port unreachables

How can you know if the traffic you see is truly a hostile source host or just indirect collateral damage? First and foremost, you must have an audit trail of all activity into and out of your network from all possible ingress and egress points If you are certain that you have this completely covered, you can pretty much rest assured (assuming your audit trail tool isn’t dropping packets and is not experiencing any other malfunctions) that if you see no outbound traffic that elicited these responses, your source IP numbers have been spoofed Also, another indication is that if you see replies to hosts that are not active in your network, then the IP’s had to have been spoofed and it is collateral damage

Trang 7

History: RingZero was identified as a trojan that used ports 80, 8080 and 3128 to report IP

addresses and proxy ports to a central server (www.rusftpsearch.net) This particular trace highlights what is possibly a mutation of this trojan Note the IP ID field is not consistent with the normal behavior, incrementation

In the next slide we gain further information about this pattern

Trang 8

Can we find evidence of crafted packets?

Please note the TTLs on this slide; they are descending This is not normal, obviously Why would someone send that many packets with descending TTLs (to port 80, in this case)?

The MOST important thing to keep in mind is that without being able to see the TTL and IP ID, this would just look like a noisy scan to port 80 In fact, the analyst might decide it is a SYN flood And

in fact, that is one possibility to explain this traffic – just a bandwidth, CPU wasting attack

However, since we are working on traffic analysis, let’s dig a bit deeper

Now, please notice the IP ID; it is not changing Clearly something is wrong; what could it be? One possibility is that someone is crafting packets and this is being used as a type of traceroute

However, if that is true, they are not doing it in a clever manner If you were going to do a

traceroute, it would be much more logical to have the TTLs count up, 1, 2, 3 instead of down, 255,

254, 253 If you count up then the other site does not see every packet If you count down, the other site has a big signature since so many packets get to them Scan detect code will probably notice what the attacker is doing, even if you don’t have a signature for that particular port

Trang 9

Notice we are seeing the packets coming to port 8080, also a part of the RingZero pattern Please note that the IP ID is lower here than in the previous slide The fact that they are hitting proxy ports and that the IP ID is not acting normally makes this suspicious

Since IP IDs are issued sequentially, the non-packet craft explanation is that the source machine is actually sending packets that fast How fast? Now we need to look at the time fields If we look at the difference between the TTL 18 packet and the TTL 17 packet in the previous slide, this slide and the next slide, we see the time between packets is somewhere in the range of 000151 What good is that information? It means that the source machine is capable of cycling through ALL of its IP IDs

in just under 10 seconds Since the delay time is much higher than that between port numbers, about

a minute, the IP ID might well not be crafted, but simply the result of turnover

Obviously, you don’t want to calculate speed from only three data points, so as a sanity check, you can compare the delta between the first two packets and the TTL 1 packet You see that all the packets kept streaming at about the same speed; this is also true on the next slide On this slide there was some huge delay (compared to the speed we are able to achieve) Either the sending system got busy or the Internet got congested At the end of the exercise though, you know that the source host

is able to send packets at a high rate of speed

Trang 10

RingZero? 3

00:52:24.638450 212.209.62.2.1248 > 142.62.0.108.3128: S 174756:174756(0) win 8192 <mss 1460> (DF) (ttl 18, id

Key to Understanding: What would most analysts see?

A BIG RingZero scan (TTLs are counting down) and

would report it as such.

There is one other possibility to consider, that there is a routing problem and the packets are ping ponging back and forth Obviously, if we could examine the link layer and see the MAC addresses,

we could answer this in short order We think this is NOT correct, however If it was a routing problem resulting in ping ponging, the packets would begin to saturate the link of the screwed uprouter After all, the problem should not only happen with one address So, if each group of packets was slower than the first, a routing problem should be considered

So what do we know? This certainly appears to be proxy scanning The IP IDs can be explained as

a natural result of the system’s potential speed The TTLs cannot be explained naturally unless you decide this is a misconfigured router 18 packets/minute is not enough to be an effective Denial of Service

The bottom line: who can say! But this was a great opportunity to apply analysis to the packet fields

Trang 11

Slow Scan Multi-site Probe

(Source port analysis shows these are 2 processes)

20 thousand range src port numbers are sendmail

Note low and slow approach

Date Time Source Host Source Port Dest Host Dest Port

Primary focus – source host/port, dest host ports

Secondary focus – time

The main thing to note in this detect is the interesting interleaving of the source port numbers Low source ports are used for the port 111 scans, while high source ports are associated with the port 25 scans Also, this is an example of a crude low and slow scan, where they send only so many attempts per hour to avoid detection This will foil many commercial intrusion detection systems

Trang 12

146.9.31.161.20 > 172.20.2.32.19000: S 1:1(0) win 16383 (DF) ( ipid 20831)

146.9.31.161.20 > 172.20.2.33.19000: S 1:1(0) win 16383 (DF) ( ipid 20831)

146.9.31.161.20 > 172.20.2.34.19000: S 1:1(0) win 16383 (DF) ( ipid 20831)

146.9.31.161.20 > 172.20.2.40.19000: S 1:1(0) win 16383 (DF) ( ipid 20841)

Key to Understanding:

Obvious packet craft with sequence number and IP ID 19000

is a default listener port for Trend Micro’s VirusWall This has been correlated for October 2000 as mail relay scan.

Primary focus – dest port, source port

Secondary focus – seq #’s, IP ID #’s

This is a detect and analysis from October 2000 GIAC by George Bakos Port 19000 is the default listener for one of the sendmail daemons of Trend Micro's VirusWall "sandwich" configuration The sequence & IP ID numbers make it obvious these packets are crafted

rbernadino@bta.pt posted a similar trace to firewalls@lists.gnac.net one hour after this one was logged If you are using VirusWall, consider using ports other than the default, as well as enabling anti-relaying and firewalling to allow traffic only from the VirusWall host to the internal mail daemon, bastion-host style Otherwise, an attacker might be able to use the default facility to send Unsolicited Commercial Mail (Spam is a trademark of Hormel foods) The point for us as analysts,

of course, is that we see the static IP ID and an almost impossible static sequence number, so we know to examine this traffic closely

Something else of note is the source port, TCP 20 – often used for FTP data and perhaps

indiscriminately left open on some sites that may not be properly secured.

Trang 13

111 Signature – IMAP

00:25:09.57 prober.2666 > relay.143: S 111:111(0) win 000:25:09.59 prober.2666 > relay.143: S 111:111(0) win 000:42:50.79 prober.2666 > web.143: S 111:111(0) win 0

00:43:24.05 prober.2666 > relay.143: S 111:111(0) win 000:43:24.07 prober.2666 > relay.143: S 111:111(0) win 000:44:20.42 prober.2666 > relay2.143: S 111:111(0) win 000:44:42.62 prober.2666 > ns2.143: S 111:111(0) win 0

00:44:42.64 prober.2666 > ns2.143: S 111:111(0) win 0

00:44:42.67 prober.2666 > ns1.143: S 111:111(0) win 0

This tool crafts packets with a SEQ number of 111.

Note the window size of zero and fixed source port.

Secondary focus – seq #’s, window size

The signature here is the 111:111 seq/ack numbers This is not as widespread as some exploits, but there were over twenty cases collected in the wild that we know of, (and we receive only a fraction

of what is available) Firewalls often disrupt the TCP three-way handshake since their purpose is to block packets, except those destined for particular ports, or those from or to particular addresses Therefore, it is a rare opportunity to be able to fingerprint a particular exploit as early as a SYN packet

Two other distinct signatures of this traffic are the static source port of 2666 and a window size of 0 Initial TCP window sizes for normal traffic are non-zero values

Trang 14

Secondary focus – seq #’s, protocol

At the top of the slide we see the sequence number 111 again The initial TCP scans are for a different purpose altogether – perhaps zone xfers; it’s hard to say without more info What we do know is that the DNS server responds and the attacker terminates the conversation The final 4 lines are version of BIND activity, done using UDP

Detect by Marc E Labram, GCIA

Trang 15

23:33:00.906644 scanr.53 > mailer.111: S 100:100(0) win 512

23:43:18.340156 scanr.53 > mailer2.111: S 100:100(0) win 51223:43:18.340156 scanr.53 > mailer2.111: S 100:100(0) win 512

Key to understanding:

This pattern has a strong resemblance to the previous

portmap scan: same fixed source port and an artificially low

Initial Sequence Number Source port may be to penetrate dumb packet filters February 1998 Correlation in notes.

Secondary focus – seq #’s

YA Signature – PORTMAP

This fundamental pattern, source port 53 to destination port 111, was still going strong in May 2000 Unfortunately the sequence number data was not available

Detect below by Laurie Zirkle:

“According to arachNIDS, ‘Attacker is making a connection using the source port 53 (dns) to a privileged port This should not occur naturally - and is meant to fool old or misconfigured packet filters into allowing the connection, since they sometimes allow all dns traffic.’ This is all I get from snort, no packet dump and nothing in the alert file.”

May 17 12:03:17 dns1 snort[51901]: IDS007 - MISC-Source Port

Traffic 53 TCP: 194.219.84.38:53 -> z.y.w.34:111

May 17 12:03:17 dns3 snort[3439]: IDS007 - MISC-Source Port Traffic

53 TCP: 194.219.84.38:53 -> z.y.w.98:111

Tiêu đề	Traffic Analysis Techniques 1
Thể loại	Course notes
Năm xuất bản	2000-2001

Định dạng
Số trang	27
Dung lượng	636,26 KB