Trends of Background Radiation in the Internet for TCP

Author: Brook Novak, University of Waikato, 2008

Thanks to my supervisor Matthew Luckie for helping with this project.

The HTML contents below is a directy copy and past from a LaTeX to HTML converter and contains many artifacts – missing references. Sorry for the inconvenience. Download full version: PDF

The Internet experiences large volumes of unproductive, useless traffic every day. A large majority of such traffic has been known to have malicious intent[22] or is a by-product of malicious attacks such as backscatter from a DoS attack[21]. This paper analyses four years of unsolicited TCP SYNs arriving at a /16 allocation. The focus is to find out how this unsolicited traffic has changed over time. Explanations are inferred from the trends and patterns that have emerged. It is found that only 13 ports are responsible for 59% of inbound unsolicited TCP SYN traffic. All these ports are either well-known vulnerable ports commonly attacked by many worms, or ports used purely by worms for uses such as backdoors. Over the period from December 2003 through to March 2008, unsolicited TCP connection requests have declined in both relative and absolute measurements. This decline is largely attributed to the decline of unsolicited activity on two ports; 135 (Microsoft Windows Endpoint Mapper Service) and 445 (Common Internet File System) which share related vulnerabilities.

Introduction

Internet traffic today is not all legitimate; excessive volumes of inbound traffic arriving are unsolicited [44,24,13]. This type of unproductive, useless traffic is termed as the Internet’s background radiation[23]. Generally such traffic is unwanted, especially traffic with malicious intent. Unfortunately ISP customers must pay for this unwanted traffic and their bandwidths are quenched by the presence of background radiation. This paper quantifies Internet’s background radiation over time, focusing on inbound TCP SYNs. A range of trends, patterns and events are illustrated by diagrams graphing traffic, looking at how the magnitudes and relative significance of the traffic changes over time. The investigations analyzes a range of different destination ports for which the most unsolicited activity resided. The Internet’s legitimate inbound TCP SYN traffic is presented to compare and relate the findings of unsolicited activity.The traces used for the analysis came from a single traffic monitor at the University of Waikato. This monitor captures all inbound and outbound traffic on a used /16 IPv4 allocation. We do not claim the results as being representative of other sites; previous work[4] has shown telescope placements to have measurement biases.

The changes of background radiation in the Internet has exposed many peculiar events for many ports over the last four years. The amount of unsolicited activity has declined over these years. It is found that most of the activity is present on ports 135 (Windows EPmap Service) and 445 (Windows CIFS), and decays exponentially over time. All of the ports analysed in this study have connections to one or more worms; which in many cases provide candidate explanations for the various increases and declines of activity seen on these ports.

Background work

A study in 2004 by Paxson et al. passively and actively measured the Internet’s background radiation[23]. They analyzed approximately two weeks of traces captured collectively at different times from three network telescopes. The first trace captured was on March 11th 2004, and the last on May the 5th. Large volumes of background radiation was observed, most of which was TCP. Because they had the ability to respond to suspicious TCP SYNs they were able to precisely classify traffic in terms of specific worms and viruses. This paper offers a different perspective to their work; the traces are collected from a single allocated and used address block. Network telescopes are commonly used for not only studying malicious traffic[16] but also by global scanning worm detectors[26]. Network telescopes provide a rich view of the Internet’s background radiation, however they are becoming more biased for analyzing malicious activity. Many worms and viruses have been known to avoid telescopes[26,44,25], especially nematodes[1]. Reasons to why worms and viruses are beginning to avoid telescopes could be to propagate faster through the Internet, or to silently spread undetected by global scanning worm detectors. Conversely network telescopes could be targeted by worms in an attempt to mislead that they cause a lot more damage than they actually do. We avoid this bias by considering traffic arriving at a used network. Paxson et al. passive measurements are expanded from their two week snapshot to a period of four years; looking specifically at TCP SYNs. The ports selected for analyzes include all the TCP ports that they investigated in their active measurements; bringing contexts to their findings. Trends are inferred for the range of activities they discovered per port; some of which are inferred to be new activities that have occurred after their work.

Methodology of Measurement

The Data

Figure 1: The amount of unique incoming TCP requests per day

Table 1: A summary of the traces analysed

Trace Name	Start Date (UTC)	End Date (UTC)	Duration
Waikato I	Dec 6 11:00:01 2003	Aug 17 22:02:39 2005	620 days
Waikato II	Nov 28 15:09:05 2005	Sep 25 14:54:57 2006	301 days
Waikato III A	Sep 25 16:48:32 2006	Sep 25 16:49:53 2006	81 seconds
Waikato III B	Sep 25 16:50:30 2006	Oct 2 11:37:24 2006	7 days
Waikato III C	Oct 2 11:47:44 2006	Feb 9 3:24:51 2007	129 days
Waikato III D	Feb 12 10:36:30 2007	Mar 8 13:00:00 2007	24 days
Waikato IV	Mar 28 16:53:13 2007	May 23 21:35:38 2007	56 days
Waikato V	Jun 5 17:37:21 2007	Sep 12 12:55:43 2007	99 days
Waikato VI	Oct 31 16:06:26 2007	Mar 14 03:00:01 2008	135 days
Total:			1,372 days

Traces used for this study was taken from a used /16 allocation staring from the 6th of December 2003, ending on the 14th of March 2008. For each of the traces, the data is split into day-long chunks for each day so the traces can be stored on hard-disk and analysed by day. Some days are split into multiple chunks due to key changes (which occur every Sunday), or monitor failures. The traces are generally continuous with respect to time. Table 1 summarises the traces[41].

Figure 1 plots the amount of unique five-tuples which had at least one incoming TCP connection request for each day over the last four years. The dates are in UTC. Over time one might expect the number of unique incoming TCP connection requests to increase over time due to the Internet’s increase in popularity. However as discussed in section 4 the fairly constant activity is due unsolicited traffic having declined whilst legitimate (responded) traffic has inclined. Two outliers were removed from figure 1 where both of the days each saw over 14 million unique incoming TCP connection requests. The largest of the outliers was targeted at destination port 1434 (Microsoft SQL Server) which is discussed in section 4.1.4. The other outlier was targeted at destination port 445 (Common Internet File System over TCP) as discussed in section 4.1.3.

The gaps in the traces where the monitor did not capture traffic for longer than 24 hours are indicated on figure 1. The largest gap resides between the end of the Waikato I and the start of the Waikato II traces. All of the traces are continuous except for the Waikato III trace; where there are four small gaps, as outlined in table 1. All graphs presented in this paper contain these gaps and uses the same time zone as figure 1.

Table 2: A summary of all TCP packets encountered over all traces

Direction	Amount of Packets
Outbound	66,708,693,354 (49.27%)
Inbound	68,487,552,964 (50.59%)
Unknown	181,186,630 (0.001338%)
Invalid TCP Header	6,514,705 (0.00004812%)
Total	135,383,947,653

The direction of the packets are determined by the source addresses. Table 2 gives an overview of the directions for all the TCP packets seen across all traces. For some of the TCP packets found in the traces the directions of the packets were unable to be identified. These packets are traffic flowing directly between the two links that the Network Monitor is connected to. Such traffic might have been reliable transport for routing protocols between the two links. This relatively small amount of traffic is of no interest in this study, the TCP SYN packets with an unknown direction have been excluded from further analysis. There also were TCP packets which the TCP header was unable to be decoded, possibly due to the packet being malformed. Clearly no conclusions could be made from the malformed packets in terms of whether or not they were incoming unsolicited TCP SYNs. The effect of these inconclusive packets could either render the results as underestimates or overestimates of what actually occurred over the last four years. The packets for which the TCP header was unable to be decoded accounted for only 0.000048% of all TCP packets seen. This portion is small such that the results would not be skewed by these uncertaincies.

Counting TCP Connection Requests

The traces were analysed to quantify the amount of unique five-tuple that had an incoming TCP connection request with or without a response for each day. More precisely; for every incoming TCP SYN packet that was observed, it would be considered as being replied to if and only if an outgoing TCP SYN-ACK was seen that belonged to the same TCP flow (five-tuple with TCP as the protocol), was within five seconds and had a sequence number equal to one more than the sequence number of the incoming TCP SYN packet. Otherwise it would be considered as being unsolicited (denoted as a hit).If a five tuple had a hit on a specific day, the hit would be discounted if that same five tuple had a reply to on that same day. This logic aids in reducing false positives; by avoiding mistaking legitimate connection failures between two machines as hits (although the chance of the TCP SYN ACKs failing to reach the monitor is very unlikely).

If an incoming TCP SYN was classified as unsolicited but the packet was seen within a small window at the end of a chunk, then the TCP SYN is not considered as unsolicited but rather responded. This is necessary because there is no guarantee that there would or would not be a reply for these incoming TCP SYNs. This is a limitation; it would be best to not consider TCP SYNs in this window.

The benefit of limiting counts to one per five-tuple is to avoid skewing the results; since specific hosts may experience abnormally large incoming flux of TCP SYNs with the same five tuple (for example, a miss-configured external host constantly attempting and failing to connect to a specific machine, or a DoS attack using the same source address). DoS attacks targeted at a specific machine / port would still show in the results, since it is common for the source addresses to be spoofed at random [9]. In such cases one would expect to see outliers in the results which can be investigated further to verify whether or not that outlier was a DoS attack. Therefore although this method of counting is still subject to DoS attacks the results still would not be skewed. The results quantify the amounts of Internet addresses which experience TCP SYN background radiation, not the total magnitude of all TCP SYN background radiation.

Limitations

The traces do not provide a complete, continuous capture of traffic for the time-frame under observation for this study. Potentially crucial events may have been missed. However it is only of concern for major gaps (see figure 1 for major gaps) as there is no way to fill-in these voids. Three small gaps exist in the Waikato III trace (see Table 1). These small gaps would not change the major trends spanned over the four year period every if they contained anomalies.Section 3.2 describes how incoming TCP SYNs that are seen near the end of a trace chunk are always regarded as responded. Consequently the findings reflect an underestimation of how much TCP background radiation there has been in the Internet. The underestimations are magnified where there are days that have multiple chunks as they miss on n seconds where n is the number of chunks that represent the day. However there are only 202 days which consist of multiple chunks, where most of these are split into two chunks (due to the routine key change).

The traces contained only the IP and TCP headers; for which were anonymised per file using cryptopan[29]. The payload was not captured due to privacy concerns as the network monitor observed Internet activity for users who were unaware that their traffic was being recorded. TCP connection requests that were responded to were inferred as being legitimate, as there were no means to further inspect the TCP connection states. However, a malicious TCP connection requests can only be identified as malicious after connection establishment by inspecting the proceeding payloads. Consequently, by being restricted to only inspecting headers, such malicious traffic was inferred to be legitimate traffic where they should be classified as being part of the Internet’s background radiation. Thus the results yet again underestimate the magnitude of background radiation experienced at the monitored site. This would be bias if the unsolicited traffic was directed only at specific machines which listened on specific ports.

The ports which were selected for this study were known to be the target of many different types of worms over the last four years. Because the measurements are only passive, there is no means to classify that types of unsolicited packets per port. The explanations effectively are limited by the information about the unsolicited TCP SYNs.

This study surveys background radiation in the Internet across a selection of destination ports. This only one side of the story; there could also be compelling trends according to source ports of unsolicited TCP SYNs. The Witty Worm is an example of an Internet-Scale event where the large volumes of traffic can only be observed by looking at source port 4000 since the destination ports were selected at random [28].

Results

Figure 2: The total amount of hits that were responded per day

Figure 2 presents the amount of unique five-tuples for which an incoming TCP connection request was responded to per day. It is a subset of figure 1 since figure1 is the set of all incoming TCP connection requests; including both requests that were or were not responded to. The incline in incoming TCP connection requests is as expected due to the Internets growth in popularity. The activity appears to follow a rough pattern of peaks and troughs, most likely reflecting the Universities semesters and holidays; where peaks appear to be during semesters and troughs during semester breaks.

Figure 3: Percentages of incoming TCP connection requests that were unsolicited per day

Figure 4: Percentages of incoming TCP connection requests that were unsolicited per day excluding analysed ports

The percentages of incoming TCP connection requests that are unsolicited has declined over the last four years, as illustrated by figure 3.

There were many ports where a lot of unsolicited activity was observed. The TCP ports selected for further analysis are from Paxson et al. study; 80, 135, 1025, 139, 445, 6129, 3127, 2745, 4751, 1981, 4444, 9996, 5000 and 1433[23], including additional ports which showed a relatively large amount of unsolicited activity; 1023, 5554 and 9898. Figure 4 shows the remaining unsolicited TCP SYNs that are not analyzed further in this study. By comparing figures 3 and 4, the selection of ports account for an overall of 59.64% of the incoming unsolicited TCP SYNs, 79.55% of these SYN packets are accounted for from the beginning of the traces to the 3rd of Febuary 2006 (the half-way mark in traces). These figures remain the same (at two decimal places) when excluding ports 1981, 4444, 4751 and 9996 from the selection, since these ports had experienced relatively insignificant amounts of incoming unsolicited TCP SYNs.

A jump from 10% to 20% of unexplained unsolicited activity is seen from early December to early January 2005 shown in figure 4. This may suggest a rise of port scanning accross the 16-bit port space (for example the use of the Nmap tool[10]), or possibly an increase of TCP SYN floods that do not target specific ports.

Trends of Background Radiation per Port

Port 80

Figure 5: Hits over time for port 80

Figure 5 indicates an event that occurred between 12th of February and the 31st of May in 2004. The lifetime of the event is clear and the unsolicited packets follows a tight trend over time. The maximum hits experienced during this event occurred on the 5th of April, with 425,221 hits. This maximum however appears as an outlier and effectively is not regarded as the peak of the event. The peak of the event occurred on the 26th of April with 336,416 hits, 10.22% of the background radiation seen for that day. Paxson et al. data set for this port was gathered on the 29th of March[23], 34 days into this event. From their active measurements they found an average of 97.55% of the activity they saw on port 80 was attributed to attacks on Web applications; where the dominant activity was a WebDAV buffer-overrun exploit[23]. Their findings offer a likely explanation for the unsolicited activity seen in this event.

A short but intense event occurred on the 15th of July in 2005, lasting for three days. Day one reached 1,096,100 hits, day two 2,538,516 hits and day three 1,380,120 hits. There are many candidate explanations for this event; the address allocation might have been heavily scanned for Web Servers or possibly experienced worm traffic. If the latter, then the situation would have become quarantined very quickly, possibly because of its obvious presence and high consumption of network resources. The only virus discovered on this date was a new variation of the Beagle worm (also known as Bagle[40]) that used port 80 as a backdoor[32]. Another possibility to the sharp three day spike may be due to a targeted attack. However the incoming unsolicited TCP SYNs for day two of this event were reasonably evenly spread over 31,036 distinct IP addresses (47.36% of the /16 allocation), with a median of 67 hits per desintation IP and a standard deviation of 51.49. The source IP’s were also looked at for any other possible leads. The source IP that was responsible for the most incoming unsolicited SYN acks accounted for 15,114 hits, an outlier in the data set (where the next largest IP transmitted 4,926 connection requests).

On the 19th of December a relatively large rise in unsolicited connection requests occurred, peaking on the 23rd of December 2005 with 222,900 hits, accounting for 15.62% of incoming unsolicated TCP SYN traffic that day. This activity does not reveal a clear event, it is difficult to depict any type of trend. One explanation for this activity might be due to an outbreak of new variations of the Beagle worm. These variations were discovered daily, starting from December the 15th through to the 25th; using port 80 as a backdoor. Symantec released a report for these variations which assessed them as having spread quickly[34].

Apart from the three events, this port has experienced a relatively low and steady amount of background radiation over the last four years. Paxson et al. observed malicious activity across the HTTP proxy ports 81/1080/3128/8000/8080/8888 for all there monitored networks[23]. These ports had experienced a lot less background radiation as shown in figure 5; the amount of hits fluctuated a lot over time and did not suggest any compelling events. Although the proxy ports did indicate an increase of hits during the same time-frame of the first event discussed in this section.

Ports 135 and 1025

Figure 6: Hits over time for port 135

Figure 7: Hits over time for port 1025

Port 135 is the port used for Microsoft Windows Endpoint Mapper Service. This port had a lot of unsolicited activity at the beginning of the traces (see figure 6), so it is not known when this activity first started. The peak is inferred to be on the 12th of January 2004 with 1,021,016 hits, as indicated on figure 6. The unsolicited activity gradually declines over time with having one half-life of 198 days from the peak date. This port is home to many malicious worms as it is one of the ports used by Microsoft Windows DCOM Remote Procedure Call(RPC) service. This service has a buffer overrun vulnerability on every unpatched Windows XP/2000 machine [20]. Paxson et al. found that the predominant activity on this port was by the Blaster and Welchia worms[23].

An outlier was removed from figure 6 having 2,564,375 hits which occurred on Sunday the 11th of October 2004. There where no specific destination IP addresses that were heavily targeted; the maximum amount of unique hits a single destination IP address encountered was 337 and the median was 160 across a total of 16,040 unique destination IPs that were hit (24.48% of the /16 allocation). The hits were distibuted relativly evenly over the destination IPs, with a standard deviation of 15.56.

Paxson et al. found similar characteristics of background radiation with the ports 1025 and 135; where they both experienced a similar set of exploits (since port 1025 is used by Microsoft’s DNS Server which uses the RPC service). Figure 7 however does not suggest a strong relationship between the two ports over the last four years. An event occurred for port 1025 starting on the 7th of March 2004, and eventually ending around the 1st of January 2005. It peaked on the 19th of March, reaching 161,624 hits (as indicated on graph). Paxson et al. data set for this port was gathered when the port experienced a high amount of activity; providing possible explanations for this background radiation. Another explanation might be due to the release of a mass mailing worm named Keco, discovered on the 8th of March 2004[37]. Keco was regarded as having a high spread rate according to Symantec[37]. This worm sequentially opens TCP ports, starting with port 1025. A possible explanation might be that some of the unsolicited activity seen here was connection attempts or scans on the starting port of Keco’s backdoors.

A short event with a significant magnitude of activity occurred on the 8th of December 2005 for port 1025. From glancing at figure 7 it appears as though the peak is a single point, however there are two points; the largest (the actual peak) on the 9th of December with 1,529,678 hits, closely followed by 1,529,436 hits for the day after. The destination IP addresses of the unsolicited packets were evenly spread amongst 15,592 addresses (23.79% of the /16 allocation) having a standard deviation of just 11.89. The even spread discounts any type of targeted attacks, appearing to indicate some sort of scanning behaviour.

There appears to be an event with a relatively low magnitude of unsolicited activity, beginning on the 7th August 2006, ending on about the 2nd of May 2007. This area of interest is magnified on figure 7. It peaks with 48,875 hits on the 22nd of August 2007. The event sustains its activity for about seven to eight months. Because of its long period it is hard to find a strong explanation for the activity; there probably would have been many causes occurring at different times. For example, Rinbot variant BC was first discovered on the 16th of April 2007[14] which scanned port 1025 to exploit the Windows DNS Server buffer overflow vulnerability[7].

Ports 445 and 139

Figure 8: Hits over time for port 445

Figure 9: Hits over time for port 139

Port 445 is usually used by Windows for CIFS(Common Internet File System) over TCP using the SMB (Server Message Block) protocol. Similarly, port 139 was used by various Windows operating systems for CIFS over NetBIOS/TCP.

Figure 8 reveals that a lot of background radiation has occurred over the last four years. An outlier was removed from this graph on the 18th of April 2004 with over 10 million hits. By observing the apparent trend, the beginning of the event looks as if it started within several days just before the trace (the 7th of December 2003). The peak of the event is hard to judge. There appears to be another (relatively) short event starting from 20th of August 2004, ending on the 30th of November 2004, containing a higher level of unsolicited activity than the longer events. Therefore the days during shorter event are not candidate peaks for the longer event. The peak for the longer event was taken as shown in figure 8, experiencing 1,285,517 hits. The chosen peak is relatively a lot larger than the trend (experiencing more than double the hits), however it was discounted as an outlier since there were a cluster of days just below this point, and also because it occurred close peak of the general trend. From its peak the trend has an exponential decay over time, having one half-life of 93 days. With a closer view of the graph the activity is still ever so slightly declining when the trace finishes as shown in the magnified portion of figure 8; hence the end of this event not yet known.

The shorter event for port 445 does not appear to have any sort of trend. It peaks on the 23rd of November 2004, with 2,139,376 hits, accounting for 58% of the unique incoming unsolicitated TCP SYN traffic that day. After the shorter event for port 445, Starting from the 10th of January 2005, several extremities sporadically occur.

Paxson et al. found that the majority of the background activity they saw on port 445 tried to exploit the Windows Locater Service buffer overflow vulnerability; which might explain some of the initial activity seen in figure 8. Leading up to the peak of the large event there is a small cluster of days which break away from the trend. This might be due to the release of the first Sasser worm which was discovered on the 1st of May 2004[3]. The Sasser spreads on port 445 by exploiting a vulnerability in the Local Security Authority Subsystem Service (LSASS) used by Windows operating systems[38]. This same vulnerability was exploited by a new worm family denoted Korgo, which was first discovered on the 22nd of May 2004[39]. These two worm families had many variants which all target port 445. It might have been that the fluctuations of unsolicited activity shown in figure 8 were caused by specific variations of either of these major worm families.

The major outlier for port 445 that occurred on the 18th of April 2004 experienced 10,439,313 hits, accounting for %73.93 of the hits that day. 24.87% of the monitored /16 allocation experianced at least one hit that day. For this day, the maximum amount of hits that a single destination IP address experianced was 1,277 hits and median being 644. Clearly there were no targeted attacks responsible of this outlier.

Figure 9 presents the hits for port 139, an outlier was removed with over one million hits. A lot of sporadic activity occurs beginning on the 22nd of May 2004, with varying extremities each having over 200,000 hits. The gaps in the data makes it difficult to classify any trends or events for port 139. Unfortunately it appears as though the unsolicited activity was beginning to rise just before the large gap in the data (from the 17th of August 2005 to the 28th of November 2005). It would be unreasonable to quantify metrics for an event where the point of interest may lie within the gap (starting from about mid April through to near the end of the trace). It is conceivable that the peak of the event occurred within the gap, as the incline leading into the gap is steep.

The outlier removed from figure 9 occurred on 20th of April 2006, with 1,367,108 hits. The maximum amount of hits that a single destination IP address experienced was only 303, then median being 87 and with a tight standard deviation of 12.22. There were 15,856 destination IP addresses (24.19% of the /16 allocation) which had at least one hit. This discounts any type of targeted attacks for being the cause of this outlier.

Port 1433

Figure 10: Hits over time for port 1433

Port 1433 is the default port used by Microsoft’s SQL Server. Figure 10 presents the hits for port 1433 over time. Five outliers were removed from this graph in order to see the event more clearly, these outliers are summarized in table 3. The outliers did not appear to have any pattern (in terms of time or magnitude), occurring randomly throughout 2004 and 2005 with varying amounts of hits. On the 24th of January 2005 there were over 18 million hits, the largest amount that was ever seen (for a specific port / day) over all of the traces. The hits for this extreme was generally well spread over 15,848 destination IP addresses (24.18% of the /16 allocation), the median hit count for a destination IP was 1169 hits, the maximum was only 1244 closely followed by 1242 as the next largest hit count. The distibution of hits over IP addresses is spread enough to infer that this outlier was not due to targeted attacks.

Table 3: Outliers removed from figure 10

Date	Amount	% of hits
18/4/2004	1,251,605	8.86
28/4/2004	2,060,382	38.58
22/7/2004	1,314,921	33.62
9/1/2005	1,608,381	34.27
24/1/2005	18,289,578	82.08

There appears to be an event that occurred over most of the four years. The trend of the event is not very strong as the activity is well spread. The start of the event could be before the beginning of the trace, but with a closer look, the start is defined as being around mid June 2004, right before it ramps up. The peak of the event was on 31st of October 2004 with 297,869 hits, as shown on figure 10. The proceeding days with larger hits were not considered to be peaks as they are anomalies (with respect to the trend). The trend of the event has an exponential decay (form the peak), with a single half-life of 262.67 days. There is no clear end of this event. A short event occurs from on the 2nd to the 12th of August 2007, peaking on day two with 434,170 hits. It appears as a sharp spike.

Paxson et al. found many cases where login attempts using blank passwords were made after connection establishment[23]. Many spikes in activity on port 1433 occurred in the past (around 2002 to 2003) which were attributed to SQLSnake[18] exploiting the blank password login vulnerability[11]. The activity seen on this port could be due to specific Agobot (also known as Gaobot[12]) variations; which amongst other activities attempts to exploit the Microsoft SQL Server authentication vulnerability[2].

Port 6129

Figure 11: Hits over time for port 6129

Port 6129 is used by the Dameware’s Mini Remote Control Server, an administration tool for Windows. Figure 11 shows the hits for port 6129 revealing an event that decays at a relatively fast rate over time. Four outliers were removed from the graph in order to have a clearer view of the four years of activity. The event begins on the 20th of December 2003, after two weeks of having seen no incoming unsolicited TCP SYNS from the beginning of the trace. It peaks just five days after with 668,684 hits. The trend is clear, having an exponential decay over time with one half-life of 42.39 days. Interestingly, the event eventually splits into two bands just after July 2004; the lower band gradually declining from about 100 hits per day down to zero, and the upper band averaging about 15,000. The end of the event stops once the upper band finishes, which is on 20th of December 2006. There appears to be no time pattern with the days of the upper band; its random nature provides no leads to why this band exists.The outliers that were removed form the graph in figure 11, along with the points indicated on figure 11 (labeled as “Second event” ) occurred within a period of 60 days. There were only nine days that made up this set and were spread without any sort of pattern. Therefore it is unclear to whether these days are related, hence is not really an event. The largest of these days was on the 27th of January 2005 with 2,329,540 hits, 57.18% of the unsolicited acitvity that day. For this day, the hits were generally evenly spread over 15,848 destination IP addresses (24.18% of the /16 allocation), having a max of 170 hits and median of 149 hits for a single desintation IP.

Older versions of Dameware (2003) had a buffer-overrun vulnerability, which was discovered in December 2003[6]. A family of worms named Agobot are associated with this port; as Paxson et al. found[23]. Their findings offer likely explanations for the presence of the first event classified in this section.

Ports 3127, 2745 and 4751

Figure 12: Hits over time for port 3127

Figure 13: Hits over time for port 2745

Figure 14: Hits over time for port 4751

Ports 3127, 2745 and 4751 are used as backdoors by several viruses. These backdoors have been known to be scanned and exploited by many other worms / viruses, not just the viruses that originally opened these ports.

The background radiation on port 3127 (figure 12) appears to unveil an event. Initially the trace starts with zero to minor unsolicited activity on this port; then on the 9th of February, 298,559 hits occur. It quickly peaks two days later with 919,579 hits. The drop-off from the peak exponentially decays over time never really settling back near to zero, fluctuating from several to about a thousand hits near the end of the trace. From the peak it takes 21 days for one half-life to elapse.

Port 3127 was used as a backdoor for the Mydoom virus and its variants. The Mydoom virus was first discovered on the 26th of January 2004 [27]. It spread via email and attempted to spread through a peer to peer file sharing application called KaZaA[19]. It was not until the 9th of February, a new variant named DoomJuice was released; exploiting the backdoor left behind on port 3127 [36,43]. These series of events provide likely explanations to the activity seen in figure 12.

There appears to be an event for port 2745 (figure 13), less intense compared to port 3127 (and all others mentioned thus far). The event starts on the 3rd of March 2004, eventually ending at about the 29th October 2006. The peak is on the 5th of April 2004 with 309,789 hits. The trend appears to be generally declining exponentially from the peak, it takes 69.76 days to reach its half-life.

Port 2745 is used as a backdoor by many of the Beagle worm variants. The first Beagle variant that used this port as a backdoor was Beagle.C, first discovered on the 28th of February 2004[33]. If this was the cause of the activity, reasons to why unsolicited activity is not seen until four days later might be that the new variant may have been slow to propagate through the Internet; its predecessor released in the same month did not propagate rapidly and stopped propagation nearing the end of the month[42].

There appears to be an event on port 4751 shown by figure 14; however the event is much smaller compared to the events outlined on the other backdoor ports. The event begins on the 28th of March 2004 and ends on the 6th June 2004. On the 30th of March 2004 it reaches its peak at only 978 hits. The unsolicited activity exponentially declines form its peak over time. It takes only 69 hours to reach one half-life.

Port 4751 is another port used as a backdoor by some of the worms in the Beagle family. The first variant to open this backdoor was Beagle.U, discovered on the 26th of March 2004[30], which may offer an explanation to the activity seen on this port. As with port 2745, the reason to why unsolicited activity on this port did not appear until two days after the discovery date might have been because of the worm taking its time to propagate through the Internet.

Port 5000

Figure 15: Hits over time for port 5000

Port 5000 is used by Windows for its Universal plug and play service (UPNP). Figure 15 shows both the hits over time for this port. There appears to be two separate, possibly related events. The first event begins on the 12th of March 2004 and peaks on the 17th of May 2004 with 480,783 hits. This event ends on the 6th of January 2004, the day before the next event. The second event (zoomed area on figure 15) peaks on the 12th of January 2004, with 27,006 hits and ends sharply on the 3rd of February 2005. Neither of these events really have a trend or pattern.

On the 17th of May 2004, a new worm called Bobax was discovered. This worm scans port 5000, and if responded it will try to exploit the Windows LSASS buffer overrun vulnerability in order to propagate itself[31]. The unleash of the Bobax worm might be an explanation for why the peak of the first event occurred on the 17th of May.

Ports 1023, 5554 and 9898

Figure 16: Hits over time for port 1023

Figure 17: Hits over time for port 5554

Figure 18: Hits over time for port 9898

Figures 16, 17 and 18 show the hits for ports 1023, 5554 and 9898 respectively. An outlier was removed from fig 17 with 567,139 hits on the 18th of October 2004, for which the hits were well spread over 16,040 destination IP addresses (24.48% of the /16 allocation). The three figures look remarkably similar; where the unsolicited activity all starts near the beginning of May 2004. The peaks were 141,125 on the 11th of Semptember 2004 for port 1023, 170,956 on the 5th of August 2004 for port 5554, and 174,289 on the 13th August 2004 for port 9898. All three ports show an exponential decay from their peaks, with similar half-life’s of about 90 days (see section 4.2 for exact half-life’s). Also, they each experience a temporary drop-off near the end of November 2004. For each of the three ports, 139 of the 1,377 days of traces captured were found to have exactly the same number of hits for those days; the maximum amount of hits of those 139 days had 4,606 hits. With a tolerance of 100 hits, 341 days were the same, the maximum amount of hits for these days was 9437 hits.

The day for which all of the three ports experienced the same and largest amount of hits (4,606 hits) was on the 17th of June 2007. These unsolicited TCP SYNs came from the same three IP source addresses for all ports and were responsible for the exact same amount of hits (2304, 2048 and 254). A day where each port experienced 2,189 hits was randomly selected, revealing that the same source IP address was emitting all of these packets to each of the three ports evenly over the destination IPs (every destination IP on this day experiencing exactly one hit). On a day where the three ports experienced between 9,374 and 9,437 hits, the top seven source IPs that were emitting the most unsolicited TCP SYNs were the same, as shown in table 4. Another day was randomly selected near the time in which the unsolicited activity was high (30th of September 2004); seeing a maximum of 106,138 hits (of the three ports). It was found that the top four source IP’s were the same for each of the three ports, the proceeding source IP’s were very similar, only slightly out of order. From these observations; there appears to be a relationship with the source IP’s holds throughout the traces.

Port 5554 is used by the Sasser worm as a backdoor port; this worm was first discovered on the 1st of May 2004[3,38]. On the 5th of August 2004, a new Sasser variant called Sasser.E was discovered[17]. Instead of using port 5554 as the backdoor, Sasser.E used port 1023 as an alternative. On the 14th of May 2004 a new worm called Dabber was discovered[35]. The Dabber worm not only used port 9898 as a backdoor port; but also exploited both of Sasser’s backdoor ports 1023 and 5554[15,8]. Their appears to be a connection with the start dates of these three worms and the sudden increases of unsolicited activity shown in figures 16, 17 and 18. It is likely that the Dabber worm is the culprit behind the similarities of these three ports.

Table 4: Top seven source IPs with the most hits for ports 1023, 5554 and 9898 on the 30th November 2005

IP Rank	1023 Hits	5554 Hits	9898 Hits
1	3318	3322	3311
2	1650	1646	1647
3	1529	1535	1535
4	1022	1024	1024
5	1022	1024	1024
6	643	427	570
7	253	254	254

Ports 1981, 4444 and 9996

The ports 1981, 4444 and 9996 are used by Agobot, Sasser and Blaster respectively[23]. Each of these worms sends a malicious packet containing a payload that exploits a specific buffer overrun; the payload contains executable code that binds a command shell to these ports. The attacker assumes that these ports are successfully bound and issues commands to the comprised hosts (on the bound ports); the Blaster worm for example issues commands to the compromised hosts to download a copy of the worm’s full executable code via TFTP[5].There were no compelling events found on these ports; the amount of hits seen on these ports were relatively low. The amount of hits seen was low because the most likely causes for seeing any activity on these ports must first successfully complete the first phase (the transfer of the buffer overrun packets) before attempts are made to connect to these ports. Port 1981 saw its largest amount of hits with 380 hits, which was an outlier. The largest number of hits seen on port 4444 was 2,300, which again was an outlier; the next largest hit only having 956 hits. Port 9996 saw the least activity, seeing a maximum of 19 hits in one day.

Summary

Table 5: Classifications of all events on each port

Port	Start Date	Peak Date	Peak	Peak	1 half-life	End
	(UTC)	(UTC)	Count	%	(Days)	(Days)
80	12/2/2004	26/4/2004	336,416	10.22	NA	109
80	15/7/2005	16/7/2005	2,538,516	63.54	NA	3
80	19/12/2005	23/12/2005	222,900	15.62	187.39	101
135	Unknown	12/1/2004	1,021,016	44.45	198.36	1,121
1025	7/3/2004	29/4/2004	161,624	4.22	24.68	300
1025	8/12/2005	9/12/2005	1,529,678	47.70	NA	19
1025	7/9/2006	22/9/2006	48,875	2.90	NA	237
445	7/12/2003	4/5/2004	1,285,517	34.25	93.88	1559
445	20/9/2004	23/11/2004	2,139,376	58.42	NA	71
1433	15/6/2004	31/10/2004	297,869	17.64	262.67	1230
1433	2/8/2007	3/8/2007	434,170	16.93	NA	10
6129	20/12/2003	25/1/2004	668,684	30.40	42.39	1096
3127	9/2/2004	11/2/2004	919,579	33.14	21.02	1495
2745	3/3/2004	5/4/2004	309, 789	8.01	69.76	970
4751	28/3/2004	30/3/2004	978	0.04	2.89	70
5000	12/3/2004	17/5/2004	480,783	17.79	NA	300
5000	7/1/2005	12/1/2005	27,006	1.58	NA	27
1023	10/5/2004	11/9/2004	141,125	7.32	96.63	1404
5554	3/5/2004	5/8/2004	170,956	8.10	91.78	1411
9898	12/5/2004	13/8/2004	174,289	6.64	97.76	1402

Table 5 summarizes all events outlined in section 4.1. Note that only events that exponentially decayed can have a half-life (since half-life’s only apply to exponentially decayed trends). The end dates for events which exponentially decayed are roughly estimated, since by definition and exponentially decay never actually reaches zero. Therefore the durations of these events (column “End” in table 5) are not a reasonable metric for comparing to other events with.

A peculiar pattern occurred for all except one of the outliers for the selected port for this study; all except for one had the hits distributed over a quarter of the monitored /16 allocation. The exception was an outlier on port 80; where almost half of the /16 allocation experienced at least one hit for that day. No reasons were found for this pattern and is left open for future work.

Conclusion

While the amount of legitimate incoming TCP connection requests are on the rise, the amount of illegitimate incoming TCP connection requests has declined over the last four years. Typically, once an incline of illegitimate activity reaches its peak; it was found that either the activity was a burst and ceased to exist, or exponentially decayed over time. Ports 135 and 445 are prime examples of ports that had experienced large volumes of illegitimate TCP connection requests, and are exponentially decaying over time. Most of the ports which collectively experienced the majority of unsolicited activity over the last four years are linked to worms which exploit vulnerabilities in various services that run on Microsoft Windows Operating Systems. Reasons to why we are still seeing suspicious activity years after patches were released to fix vulnerabilities might be due to remnants old worms still propagating the Internet. Or it might be due to contemporary worms that attempts to exploit multiple vulnerabilities, including old vulnerabilities for which unpatched machines are forever subject to.

Bibliography

1

Dave Aitel.
Nematodes – benificial worms.
Technical report, Immunity, Inc, 2005.

2

Paul Barford and Vinod Yegneswaran.
An inside look at botnets.
pages 171-191, 2007.

3

BBC.
Sasser net worm affects millions.
BBC Online News Article, 2004.
Retreived from http://news.bbc.co.uk/1/hi/technology/3682537.stm, on 3rd of June 2008.

4

Evan Cooke, Michael Bailey, Z. Morley Mao, David Watson, Farnam Jahanian, and Danny McPherson.
Toward understanding distributed blackhole placement.
In WORM ’04: Proceedings of the 2004 ACM workshop on Rapid malcode, pages 54-64, New York, NY, USA, 2004. ACM.

5

eEye Digital Security.
Analysis: Blaster worm.
Online Published Advisory, 2003.
Retreived from http://research.eeye.com/html/advisories/published/AL20030811.html, on 4th of June 2008.

6

Security Focus.
Dameware mini remote control server pre-authentication buffer overflow vulnerability.
Security Focus Online BugTraq Service, 2003.
Retreived from http://www.securityfocus.com/bid/9213, on 4th of June 2008.

7

Security Focus.
Microsoft windows dns server escaped zone name parameter buffer overflow vulnerability.
Security Focus Online BugTraq Service, 2007.
Retreived from http://www.securityfocus.com/bid/23470/info, on 3rd of June 2008.

8

Deborah Hale.
Samba – buffer overrun, hp remote command execution, top 15 worms, hosts file, sasser/dabber activity.
SANS Internet Storm Center Website, 2004.
Retreived from https://isc.incidents.org/diary.html?date=2004-07-22, on 4th of June 2008.

9

Alefiya Hussain, John Heidemann, and Christos Papadopoulos.
A framework for classifying denial of service attacks.
In SIGCOMM ’03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pages 99-110, New York, NY, USA, 2003. ACM.

10

Insecure.Com.
Nmap.
Nmap Official Website, 2008.
Retreived from http://nmap.org/, on 4th of June 2008.

11

Computer Associates International.
Microsoft sql server desktop engine blank ‘sa’ password vulnerability.
CA Threat Assessment Report, 2002.
Retreived from http://www.ca.com/us/securityadvisor/vulninfo/vuln.aspx?id=5705, on 4th of June 2008.

12

Computer Associates International.
Win32/agobot family.
CA Threat Assessment Report, 2004.
Retreived from http://www.ca.com/us/securityadvisor/virusinfo/virus.aspx?id=37776, on 4th of June 2008.

13

J. Jung, V. Paxson, A. Berger, and H. Balakrishnan.
Fast portscan detection using sequential hypothesis testing, 2004.

14

Gregg Keizer.
Soaring port 1025 scans could foreshadow windows dns server bug exploit.
Computer World Online Articles, 2007.
Retreived from http://www.symantec.com/business/news/article.jsp?aid=IN_041707_New_Port_Scans, on 3rd of June 2008.

15

Will Knight.
‘dabber’ worm targets computers through sasser.
NewScientistTech Online Report, 2004.
Retreived from http://technology.newscientist.com/channel/tech/electronic-threats/dn4997-dabber-worm-targets-computers-through-sasser.html?feedId=electronic-threats_rss20, on 4th of June 2008.

16

Abhishek Kumar, Vern Paxson, and Nicholas Weaver.
Exploiting underlying structure for detailed reconstruction of an internet-scale event.
In IMC ’05: Proceedings of the 5th ACM SIGCOMM conference on Internet measurement, pages 1-14, New York, NY, USA, 2005. ACM.

17

McAfee.
W32/sasser.worm.e.
McAfee Online Threat Assessment Summary, 2004.
Retreived from http://vil.nai.com/vil/content/v_125091.htm, on 4th of June 2008.

18

Brian McWilliams.
‘sqlsnake’ worm blamed for spike in port 1433 scans.
Online News Article, 2002.
Retreived from http://www.securityfocus.com/news/429, on 4th of June 2008.

19

Cade Metz.
Mydoom virus, kazaa and the dangers of peer-to-peer.
PCMag.com Online News Report, 2004.
Retreived from http://www.pcmag.com/article2/0,4149,1472818,00.asp, on 4th of June 2008.

20

Microsoft.
Microsoft security bulletin ms03-026.
Microsoft’s Online Security Bulletins, 2003.
Retreived from http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx, on 3rd of June 2008.

21

David Moore, Colleen Shannon, Douglas J. Brown, Geoffrey M. Voelker, and Stefan Savage.
Inferring internet denial-of-service activity.
ACM Trans. Comput. Syst., 24(2):115-139, 2006.

22

David Moore, Colleen Shannon, Geoffrey M. Voelker, and Stefan Savage.
Network telescopes.
Technical report, CAIDA, 2003.

23

Ruoming Pang, Vinod Yegneswaran, Paul Barford, Vern Paxson, and Larry Peterson.
Characteristics of internet background radiation.
In IMC ’04: Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, pages 27-40, New York, NY, USA, 2004. ACM.

24

Susmit Panjwani, Stephanie Tan, and Keith M. Jarrin.
An experimental evaluation to determine if port scans are precursors to an attack.
In DSN ’05: Proceedings of the 2005 International Conference on Dependable Systems and Networks, pages 602-611, Washington, DC, USA, 2005. IEEE Computer Society.

25

Moheeb Abu Rajab, Fabian Monrose, and Andreas Terzis.
Fast and Evasive Attacks: Highlighting the Challenges Ahead, volume 4219/2006 of Lecture Notes in Computer Science, pages 206-225.
Springer Berlin / Heidelberg, 2006.

26

David W. Richardson, Steven D. Gribble, and Edward D. Lazowska.
The limits of global scanning worm detectors in the presence of background noise.
In WORM ’05: Proceedings of the 2005 ACM workshop on Rapid malcode, pages 60-70, New York, NY, USA, 2005. ACM.

27

Alex Salkever.
Mydoom’s most damning dynamic.
Business Week Online News Report, 2004.
Retreived from http://www.businessweek.com/technology/content/jan2004/tc20040128_7597_tc047.htm, on 4th of June 2008.

28

Colleen Shannon and David Moore.
The spread of the witty worm.
IEEE Security and Privacy, 2(4):46-50, 2004.

29

Adam Slagell, Jun Wang, and William Yurcik.
Network log anonymization: Application of crypto-pan to cisco netflows.
In Proceedings of the Workshop on Secure Knowledge Management 2004, 2004.

30

Symantec.
W32.beagle.u@mm.
Symantec Security Response Online Report, 2004.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-032609-0734-99, on 4th of June 2008.

31

Symantec.
W32.bobax.a.
Symantec Security Response Online Report, 2004.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-051912-4449-99&tabid=2, on 4th of June 2008.

32

Symantec.
W32.beagle.bw@mm summary.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2005-071623-4305-99&tabid=1, on 26th of May 2008.

33

Symantec.
W32.beagle.c@mm.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-022715-1724-99&tabid=1, on 4th of June 2008.

34

Symantec.
W32.beagle.cx@mm summary.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2005-121511-1751-99&tabid=1, on 26th of May 2008.

35

Symantec.
W32.dabber.a.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-051414-5013-99&tabid=2, on 4th of June 2008.

36

Symantec.
W32.hllw.doomjuice.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-020909-2916-99, on 4th of June 2008.

37

Symantec.
W32.keco@mm summary.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-030816-4517-99&tabid=1, on 3rd of June 2008.

38

Symantec.
W32.sasser.worm.
Symantec Security Response Online Report, 2007.
Retreived from http://www.symantec.com/security_response/writeup.jsp?docid=2004-050116-1831-99&tabid=1, on 3rd of June 2008.

39

Malaysian Computer Emercency Responce Team.
W32.korgo worm.
Malaysian Computer Emercency Responce Team Advisory Report, 2004.
Retreived from http://www.mycert.org.my/advisory/MA-075.062004.html, on 3rd of June 2008.

40

Viruslist.com.
Email-worm.win32.bagle.a.
Viruslist Website, 2004.
Retreived from http://www.viruslist.com/en/viruses/encyclopedia?virusid=21928, on 3rd of June 2008.

41

WAND.
Wits: Waikato internet traffic storage.
Data retrieved from http://wand.cs.waikato.ac.nz/wits/.

42

Wikipedia.
Bagle (computer worm).
Wikipedia, 2008.
Retreived from http://en.wikipedia.org/wiki/Bagle_(computer_worm), on 4th of June 2008.

43

Wikipedia.
Mydoom (computer worm).
Wikipedia, 2008.
Retreived from http://en.wikipedia.org/wiki/Mydoom, on 4th of June 2008.

44

Vinod Yegneswaran, Paul Barford, and Johannes Ullrich.
Internet intrusions: global characteristics and prevalence.
In SIGMETRICS ’03: Proceedings of the 2003 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, pages 138-147, New York, NY, USA, 2003. ACM.