1 IDIC – SANS GIAC LevelTwo ©2000, 2001 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. 2 IDIC - SANS GIAC LevelTwo ©2000, 2001 2 Common External Dimensions •Date, time •To, From • Service, Service port numbers • Sequence numbers Four W’s : Who, What, Where, When Extra credit: Why When we talk about columns and typing, we are approaching the subject of highly dimensional data. Consider the date field a dimension, time another and so forth. By highly dimensional we mean “lots of columns”. Just about any field in the headers can be used to create another dimension. Most of the time, many fields will contain normal non-descript values and will not add anything to our focus if we are trying 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. 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: ACK #’s SEQ #’s IP identification #’s Arriving TTL values Time Flags IDIC - SANS GIAC LevelTwo ©2000, 2001 3 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. 4 IDIC - SANS GIAC LevelTwo ©2000, 2001 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 been compromised yet, but this type of attack is highly unusual, and now coming almost every day. Sorry to bother you, but if you could help I'd sure appreciate it. Thanks in advance. 5 IDIC - SANS GIAC LevelTwo ©2000, 2001 5 ircsrv.6666 > ourhost.1630: S 1234316212:1234316212(0) ack 674711610 win 4096 (DF) ircsrv.6666 > ourhost.1630: S 1306722499:1306722499(0) ack 674711610 win 4096 (DF) ircsrv.6666 > ourhost.1630: R 1:1(0) ack 1 win 4096 (DF) Key to understanding: 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 Collateral Damage (1) This slide illustrates an important point; one of the important rules is where is the traffic coming from! Odds are this is collateral effects of a denial of service attack on the IRC server. This appears as if someone has earlier spoofed the source IP of ourhost with an initial sequence number of 674711609 and sent the traffic to ircsrv destination port 6666. In the first two records, you see that ircsrv was listening and able to respond and replied with the SYN and ACK flags set and 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. 6 IDIC - SANS GIAC LevelTwo ©2000, 2001 6 ns2> 172.20.137.48: icmp: ns2 udp port 51 unreachable [tos 0xc0] ns2> 172.20.114.23: icmp: ns2 udp port 5006 unreachable [tos 0xc0] ns2> 172.20.211.116: icmp: ns2 udp port 5592 unreachable [tos 0xc0] ns2> 172.20.249.110: icmp: ns2 udp port 2605 unreachable [tos 0xc0] ns2> 172.20.110.43: icmp: ns2 udp port 1362 unreachable [tos 0xc0] ns2> 172.20.180.85: icmp: ns2 udp port 2686 unreachable [tos 0xc0] ns2> 172.20.176.18: icmp: ns2 udp port 1608 unreachable [tos 0xc0] ns2> 172.20.3.124: icmp: ns2 udp port 8358 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 Collateral Damage (2) This second example of collateral damage shows a pattern that could be attributed to the Trinoo. Again, the source addresses are faked and we see the result of the attack. What is happening here is that a host at the attacked site, ns2, is responding back, trying to be helpful, and telling us that the UDP port that we tried to reach is not in service. Note how many UDP ports we supposedly tried. 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. 7 IDIC - SANS GIAC LevelTwo ©2000, 2001 7 RingZero Pattern 07:58:32.586953 lan213.huntingdon.edu.3304 > 192.168.58.240.80: S 105977495:105977495(0) win 8192 (DF) (ttl 19, id 37127) 07:59:17.552178 lan213.huntingdon.edu.3352 > 192.168.58.240.8080: S 106022445:106022445(0) win 8192 (DF) (ttl 19, id 8201) 08:00:02.603811 lan213.huntingdon.edu.3393 > 192.168.58.240.3128: S 106067447:106067447(0) win 8192 (DF) (ttl 19, id 50956) OK, we need to be candid with you about something. This next pattern is a bit challenging, and the team spent a lot of time deciding whether to include it and how to explain it. However, we think you will enjoy this, but we want to warn you upfront that this is an unsolved pattern. That happens sometimes. So please relax and let’s take it by the numbers. 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. 8 IDIC - SANS GIAC LevelTwo ©2000, 2001 8 RingZero? 1 00:50:49.091588 212.209.62.2.1040 > 142.62.0.108.80: S 79134:79134(0) win 8192 <mss 1460> (DF) (ttl 18, id 16384) 00:50:49.091774 212.209.62.2.1040 > 142.62.0.108.80: S 79134:79134(0) win 8192 <mss 1460> (DF) (ttl 17, id 16384) . 00:50:49.093137 212.209.62.2.1040 > 142.62.0.108.80: S 79134:79134(0) win 8192 <mss 1460> (DF) (ttl 1, id 16384) 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. 9 IDIC - SANS GIAC LevelTwo ©2000, 2001 9 RingZero? 2 00:51:36.515153 212.209.62.2.1170 > 142.62.0.108.8080: S 126571:126571(0) win 8192 <mss 1460> (DF) (ttl 18, id 9986) 00:51:36.515310 212.209.62.2.1170 > 142.62.0.108.8080: S 126571:126571(0) win 8192 <mss 1460> (DF) (ttl 17, id 9986) . 00:51:36.521579 212.209.62.2.1170 > 142.62.0.108.8080: S 126571:126571(0) win 8192 <mss 1460> (DF) (ttl 1, id 9986) Can we find evidence of crafted packets? 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. 10 IDIC - SANS GIAC LevelTwo ©2000, 2001 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 14851) 00:52:24.638597 212.209.62.2.1248 > 142.62.0.108.3128: S 174756:174756(0) win 8192 <mss 1460> (DF) (ttl 17,id 14851) . 00:52:24.640191 212.209.62.2.1248 > 142.62.0.108.3128: S 174756:174756(0) win 8192 <mss 1460> (DF) (ttl 1, id 14851) Can we find evidence of crafted packets? 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 up router. 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. [...]... win 0 web .14 3: S 11 1 :11 1(0) win 0 relay .14 3: S 11 1 :11 1(0) win 0 relay .14 3: S 11 1 :11 1(0) win 0 relay2 .14 3: S 11 1 :11 1(0) win 0 ns2 .14 3: S 11 1 :11 1(0) win 0 ns2 .14 3: S 11 1 :11 1(0) win 0 ns1 .14 3: S 11 1 :11 1(0) win 0 This tool crafts packets with a SEQ number of 11 1 Note the window size of zero and fixed source port IDIC - SANS GIAC LevelTwo ©2000, 20 01 13 The signature here is the 11 1 :11 1 seq/ack numbers... 19 2 .16 8 .1. 109:8080 20 0 -> 10 9 SF POP II Original Pattern May 21 11: 14:29 210 .16 4. 212 .7:0 May 21 11: 36 :10 210 .16 4. 212 .7:0 May 21 11: 57:50 210 .16 4. 212 .7:0 May 21 12: 41: 11 210 .16 4. 212 .7:0 May 21 13:02:52 210 .16 4. 212 .7:0 : SYN FIN Scan: -> 19 2 .16 8 .1. 98 :10 9 : SYN FIN Scan: -> 19 2 .16 8 .1. 99 :10 9 : SYN FIN Scan: -> 19 2 .16 8 .1. 100 :10 9 : SYN FIN Scan: -> 19 2 .16 8 .1. 102 :10 9 : SYN FIN Scan: -> 19 2 .16 8 .1. 103 :10 9 May 21, 2000; this... 32768 (DF) 10 .10 .1. 4.53 > badguy.com.2666: S 320076960:320076960(0) ack 11 2 win 32768 (DF) badguy.com.2666 > 10 .10 .1. 1.53: R 11 2 :11 2(0) win 0 badguy.com.2666 > 10 .10 .1. 4.53: R 11 2 :11 2(0) win 0 badguy.com .11 01 > 10 .10 .1. 1.53: (30) 10 .10 .1. 1.53 > badguy.com .11 01: badguy.com .11 01 > 10 .10 .1. 4.53: (30) 10 .10 .1. 4.53 > badguy.com .11 01: 16 549+ TXT CHAOS)? VERSION.BIND 16 549* 1/ 0/0 CHAOS)... systems 11 Primary focus – dest port, source port Secondary focus – seq #’s, IP ID #’s Impossible Sequence Numbers 14 6.9. 31. 1 61. 20 ipid 208 31) 14 6.9. 31. 1 61. 20 ipid 208 31) 14 6.9. 31. 1 61. 20 ipid 208 31) 14 6.9. 31. 1 61. 20 ipid 208 41) > 17 2.20.2.32 .19 000: S 1: 1(0) win 16 383 (DF) ( > 17 2.20.2.33 .19 000: S 1: 1(0) win 16 383 (DF) ( > 17 2.20.2.34 .19 000: S 1: 1(0) win 16 383 (DF) ( > 17 2.20.2.40 .19 000: S 1: 1(0) win 16 383... May 1 08:32:03 212 .10 9.2 .13 6: 21 -> z.y.w.34: 21 SYNFIN **SF**** May 1 08:32:22 212 .10 9.2 .13 6:53 -> z.y.w.34:53 SYNFIN **SF**** May 1 08:32:38 212 .10 9.2 .13 6 :10 9 -> z.y.w.34 :10 9 SYNFIN **SF**** May 1 08:32:57 212 .10 9.2 .13 6 :11 0 -> z.y.w.34 :11 0 SYNFIN **SF**** May 1 08:33:09 212 .10 9.2 .13 6 :11 1 -> z.y.w.34 :11 1 SYNFIN **SF**** May 1 08:33:28 212 .10 9.2 .13 6 :14 3 -> z.y.w.34 :14 3 SYNFIN **SF**** May 1 08:33:47 212 .10 9.2 .13 6 :10 80... 256 .10 8.206.96 212 42 256 .10 8.206.96 617 256 .10 8.206.96 2295 256 .10 8.206.96 10 17 256 .10 8.206.96 2333 256 .10 8.206.96 729 256 .10 8.206.96 20553 256 .10 8.206.96 10 23 256 .10 8.206.96 29276 256 .10 8.206.96 803 256 .10 8.206.96 29 419 256 .10 8.206.96 900 Dest Host 256.38 .1. 41 256.38 .1. 1 256.38 .1. 1 256.38 .10 .11 4 256.38 .10 .11 4 256.34.229 .18 256.34.229 .18 256.38 .1. 41 256.38 .1. 41 256.38.48 .15 7 256.38.48 .15 7 256.38 .1. 1... 256.38 .1. 1 256.38 .1. 1 256.38 .10 .11 4 256.38 .10 .11 4 Dest Port 11 1 t 25 t 11 1 t 25 t 11 1 t 25 t 11 1 t 25 t 11 1 t 25 t 11 1 t 25 t 11 1 t 25 t 11 1 t 20 thousand range src port numbers are sendmail Note low and slow approach IDIC - SANS GIAC LevelTwo ©2000, 20 01 11 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 11 1 scans, while... Snort:” 05/ 21- 11: 14:29 .14 8908 210 .16 4. 212 .7:0 -> 19 2 .16 8 .1. 98 :10 9 TCP TTL:2 21 TOS:0x0 ID:55044 SF**** Seq: 0x2B150000 Ack: 0x0 Win: 0x200 00 00 00 00 00 00 21 Reflexive 10 9 -> 10 9 SF POP II March 2000 [**] IDS198/SYN FIN Scan [**] 02 /16 -05:43:22.4 914 86 216 .25.99.40 :10 9 -> 17 2 .16 .1. 11: 109 TCP TTL: 31 TOS:0x0 ID:39426 SF**** Seq: 0x734EB1D6 Ack: 0xDF0CDA6 Win: 0x404 [**] IDS198/SYN FIN Scan [**] 02 /16 -05:43:22. 511 3 81. .. 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 13 Primary focus – dest port, source port Secondary focus – seq #’s, protocol 11 1 Signature – DNS badguy.com.2666 > 10 .10 .0 .1. 53: S 11 1 :11 1(0) win 0 badguy.com.2666 > 10 .10 .0.4.53: S 11 1 :11 1(0) win 0 10 .10 .1. 1.53 > badguy.com.2666: S 7007990 81: 7007990 81( 0) ack 11 2 win... using UDP Detect by Marc E Labram, GCIA 14 Primary focus – dest port, source port Secondary focus – seq #’s YA Signature – PORTMAP 23:33:00.906644 23:33:00.906644 23:43 :18 .34 015 6 23:43 :18 .34 015 6 scanr.53 scanr.53 scanr.53 scanr.53 > > > > mailer .11 1: S 10 0 :10 0(0) win 512 mailer .11 1: S 10 0 :10 0(0) win 512 mailer2 .11 1: S 10 0 :10 0(0) win 512 mailer2 .11 1: S 10 0 :10 0(0) win 512 Key to understanding: This pattern . ©2000, 20 01 14 11 1 Signature – DNS badguy.com.2666 > 10 .10 .0 .1. 53: S 11 1 :11 1(0) win 0 badguy.com.2666 > 10 .10 .0.4.53: S 11 1 :11 1(0) win 0 10 .10 .1. 1.53. badguy.com.2666 > 10 .10 .1. 1.53: R 11 2 :11 2(0) win 0 badguy.com.2666 > 10 .10 .1. 4.53: R 11 2 :11 2(0) win 0 badguy.com .11 01 > 10 .10 .1. 1.53: 16 549+ TXT CHAOS)?