vulnerable hosts, which makes the malware highly virulent in nature. Fast scanning network worms are a particularly dangerous sub-class of such software.
1
A Countermeasure Mechanism for Fast Scanning Malware Muhammad Aminu Ahmad* , Steve Woodhead* and Diane Gan∗∗ *Department of Engineering Science Department of Computing and Information System ** University of Greenwich, UK Email:{m.ahmad, s.r.woodhead, d.gan}@gre.ac.uk
Abstract—This paper presents a cross-layer countermeasure mechanism to detect and contain self-propagating malware. The mechanism uses a detection technique at the network layer and a data-link containment solution to block traffic from an infected host. The concept has been demonstrated using a software prototype. An empirical analysis of network worm propagation has been conducted to test the capabilities of the developed mechanism. The results show that the developed mechanism is effective in containing self-propagating malware with almost no false positives. Keywords: Network worm, worm detection, malware, cyber defence
I. I NTRODUCTION Self-propagating malware, termed a worm, is a malicious software program that propagates across a network by infecting hosts and in some cases launching malicious activities. The infection is achieved by exploiting vulnerabilities in host network services that have not been patched or unacknowledged at the point of an outbreak [1]. A scanning network worm propagates by probing pseudo-random addresses looking for vulnerable hosts, which makes the malware highly virulent in nature. Fast scanning network worms are a particularly dangerous sub-class of such software. Common countermeasures to malware are signature-based anti-virus software, network intrusion detection systems and host intrusion detection systems, which along with network firewalls, counter the effects of a large proportion of contemporary malware. However, the ability of such systems to counter the effects of fast scanning network worms is limited because their high propagation and infection rates pose a significant security threat, with consequent damage to networks and the Internet. This paper presents an improved mechanism, which we have termed NEDAC, for the detection and containment of fast scanning network worms (abbreviated as fast scanning worms hereafter). NEDAC uses detection and containment techniques at the network level and data link level respectively. The detection part of the mechanism uses a behavioural signature to detect the presence of fast scanning worms, while the containment part of the mechanism blocks outgoing traffic from a host that has been identified as infected using datalink access control. This is an improved mechanism over the technique reported by Ahmad and Woodhead [1].
The rest of the paper is organised as follows. Section 2 summarises related work on worm detection and containment systems. Section 3 presents a description of the NEDAC mechanism. Section 4 presents the evaluation method used to test the NEDAC mechanism. Section 5 presents the experiments conducted and Section 6 presents a discussion of the experimental results obtained. Section 7 concludes this paper and points out possible future work. II. R ELATED W ORK Significant research efforts have been devoted to the development of anomaly based network intrusion detection systems, which have led to the existence of numerous approaches [2]. These approaches identify the presence of worms using datagram header information, payload information or the combination of both [3]. Among the approaches that use datagramheader information are the techniques reported by Mahoney and Chan [4], Williamson [5], Gu et al. [6], Xinzhou et al. [7], Jung et al. [8], Weaver et al. [9], Whyte et. al [10] and Shahzad and Woodhead [11]. Mahoney and Chan [4] developed a technique that uses probability to rate anomalies in detection mode based on the rate of anomalies observed during the training phase; the rarer the detected anomalies during the training phase, the more likely they are to be hostile when identified in detection mode. Williamson [5] used source and destination IP addresses of datagrams to limit the rate at which malware can try to connect to new IP addresses. Whenever a host makes a request, the request is added to a delay queue if it is new, otherwise it will be processed as normal. Gu et al. [6] developed an algorithm that correlates incoming and outgoing traffic, i.e., if a host received a datagram on port i, and then starts sending datagrams destined for port i, it becomes a suspect. Xinzhou et al. [7] improved the technique developed by Gu et al. [6] using a combination of HoneyStat and a modified version of the algorithm. Furthermore, Jung et al. [8] proposed an algorithm, termed TRW, which identifies a remote host attempt to establish a new TCP connection to a local destination as normal if there is a corresponding TCP reply. On the other hand, failure to establish a successful TCP connection is considered suspicious. The algorithm then detects worm scanning based on the count of a host’s successful and failed TCP connection
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK attempts. Weaver et al. [9] simplified the TRW scheme by considering all new connections to be a failure until a response is received. The algorithm drops a datagram if it does not match an existing and successfully-established connection after a predefined threshold count. Another detection approach for scanning worms utilises the DNS activities of hosts to detect worm propagation. Whyte et al. [10] used DNS-based rate limiting to suppress scanning worms in an enterprise network by identifying the absence of DNS resolution before a new connection as anomalous. Shahzad and Woodhead [11] proposed a scheme that uses the absence of DNS lookup action prior to an outgoing TCP SYN or UDP datagram to a new destination IP address to detect worm propagation, and a protocol termed Friends to spread reports of an identified worm event to potentially vulnerable and uninfected peer networks within the scheme. Additionally, security researchers have proposed payload based detection techniques such as the work of Wang and Stolfo [12] and Kim et al. [13]. Wang and Stolfo [12] proposed a detection scheme known as PAYL to detect and generate signatures for zero-day worms. PAYL uses a training phase to create a profile during normal operation, and produces a byte frequency distribution as a model for normal payloads. Based on this information, a centroid model is created and then during the detection phase, the Mahalanobis distance of each datagram payload from the centroid model is calculated. A datagram is considered to be anomalous based on its distance from the normal behaviour. Kim et al. [13] proposed a detection scheme using a standalone device. The scheme employed the detection method reported by Kim et al. in [14]. During the training phase, the mean and standard deviation scores for all datagrams are computed. In the detection phase, a score is computed by counting the number of datagram bytes that fall outside the range defined for each byte. The mechanisms that use statistical analysis or payload information (e.g. Wang and Solfo [12] and Kim et al. [13]) to identify worm datagrams have limitations such as computational complexity [2], management overhead [15], high rates of false positives [16] and incur significant delays in deployment and detection [13]. Rate limiting techniques (e.g. Williamson [5], Whyte et al. [10] and Shahzad and Woodhead [11]) can only slow worm infections. Techniques that use the rate of successful or failed connections (e.g. [6], Jung et al. [8] and Weaver et al. [9]), and other datagram-header based anomaly detection systems (e.g Gu et al. [6] and Xinzhou et al. [7]) consume resources in order to keep track of distinct connection and host information, especially in large networks [16]. Thus, it is desirable to have a fast and accurate countermeasure solution that is capable of detecting and containing the infection of fast scanning worms, because the speed at which the malware propagates is very high for the existing techniques to act effectively. III. T HE NEDAC M ECHANISM The NEDAC mechanism consists of two main sub-systems that work together to provide a countermeasure solution. The first sub-system is the network layer detection system and the
second sub-system at the data-link layer containment system, with a connection maintained between the two systems to enable continuous data transmission. The detection system uses two different techniques to detect anomalies from client hosts and server hosts in a network. Client hosts are defined as network hosts which typically consume Internet services (e.g. workstations, laptops, tablets, smartphones, etc) while server hosts are network hosts used to serve client requests (e.g. web servers and email servers). The detection system keeps track of inbound and outbound TCP SYN and UDP datagrams for a window of time with value T to determine anomalies that exceed a threshold. The threshold is a maximum allowable count of anomalous datagrams a host can send beforeT has elapsed. The containment system receives the MAC address of an identified infected host from the detection system and then blocks all traffic originating from the host using MAC address access control. Figure 1 shows the flow diagram of the NEDAC detection system comprising the CHAD and SHAD algorithms. The flow diagram of the containment system used by NEDAC is presented in Figure 2. The detection system of NEDAC uses two techniques namely client host anomaly detection (CHAD) and server host anomaly detection (SHAD) for client and server hosts respectively. CHAD uses an algorithm that monitors TCP SYN and UDP datagrams from client hosts in a network traffic flow. The CHAD algorithm observes DNS resolution datagrams and records the IP address of the host that made the resolution and the resolved address in the resolution cache. For other inbound datagrams, the destination port is recorded in an inbound cache. Outgoing datagram header information (source IP addresses and ports) is associated to entries in an exempt table. The exempt table comprises a list of IP addresses and ports that are exempt from the algorithm. If the header information results in a miss, the algorithm determines whether there is a recent DNS query for the IP address prior to sending the datagram by checking the resolution cache. If there is a miss, the algorithm records the destination port in the noresolution cache, increments its counter and then determines whether the entry exceeds a threshold with value V . Upon a host exceeding the set threshold, the algorithm invokes the containment system and then checks the presence of the suspect port in the inbound cache. If there is a hit, an additional countermeasure is applied at network layer using access control list (ACL) to block all inbound datagrams destined to the suspect port in the network segment. A timeto-live (TTL) is provided for entries in all the caches. The default TTL value for DNS (86400 seconds) is applied to the resolution cache and 60 seconds is applied to the no-resolution and inbound caches. Furthermore, the algorithm decrements the counters in no-resolution and inbound caches by half after the expiration of a timing window of T , and then checks all caches to determine and remove entries with expired TTL values. The SHAD algorithm monitors TCP SYN and UDP datagrams from server hosts. The algorithm records the destination port and IP address of an inbound datagram in the inbound cache. To detect anomalies, the algorithm checks the presence of the destination port of outbound TCP SYN 2
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK
Start No
While true Yes Initialise T
Get IP traffic No While T > 0
Yes
Is IP traffic to/from server host?
No
Yes Halve thresholds
Yes getNextDatagram()
getNextDatagram() Add IP addresses to resolution cache Client Host Detection Algorithm
No Is packet DNS reply? No Add destination port to inbound cache Yes
Yes
No
No
Add destination IP address and port to inbound cache
Yes
Is datagram outbound? Yes
Is datagram outbound?
Is source host in exempt table?
Yes
Yes Is source host in exempt table? No Are IP addresses in resolution cache? No Update counter in noresolution cache
No
While there are more entries in the caches
Is destination port in inbound cache? Yes Update host counter in inbound cache
No
No
Yes No
Is TTL exceeded?
Yes Delete entry End
Is counter > threshold Yes
Is counter > threshold
Invoke containment system
Yes Invoke containment system
Server Host Detection Algorithm
Figure 1: The NEDAC detection system Start
Incoming requests No While true Yes Get data (MAC)
Validate MAC address Block host with the specified MAC address Send the host name and blocking time to output file
CSV output file
End
Figure 2: The NEDAC containment system
3
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK and UDP datagrams. Worm propagation is determined if the destination port of the outbound datagram is found in the inbound cache, and therefore a counter is incremented. For outbound UDP datagrams, an additional verification of the destination IP address is made to determine a reply datagram, i.e., if the destination IP address does not match the IP address recorded in the inbound table, the behaviour is marked as suspicious. The algorithm then identifies values above the set threshold, invokes containment system and clears caches as with the CHAD algorithm. This mechanism has additional features such as (1) separate detection techniques for client and server hosts to improve effectiveness of the system (2) an additional countermeasure mechanism for inbound worm traffic to block remote to local worm infection and (3) timeto-live for records maintained in caches to reduce excessive resource consumption. IV. E VALUATION This section presents an evaluation procedure designed to test NEDAC along with the previously reported DNS-based worm detection techniques. A. Testing Environment The environment used for the evaluation process is a virtualised testbed described by Ahmad and Woodhead[1]. The testbed contains four virtualised enterprise networks comprising a number of virtual network cells. The virtual network cells contain LANs with a DHCP server for IP address management, a DNS server for name resolution, an NTP server to provide a time synchronization service for the virtual hosts, a logging server to keep a record of worm infection activities and routers for internal routing services. The virtual enterprise networks are connected together using a border router to enable data communication and routing services across the internetwork. Figure 3 depicts the design of a virtual enterprise network in the testbed. The testbed also supports the use of worm daemons and other network utilities to facilitate worm attack events and the replaying network traces as background traffic. It has a scale of 1200 virtual machines. B. Background Traffic A set of legitimate traffic traces are required for the evaluation. A publicly available dataset that closely matched the evaluation requirements is the DARPA 1999 evaluation dataset [17]. Although the DARPA 1999 dataset is 16 years old at the time of this writing, the “inside” traces of weeks 1 and 3 of the dataset are attack free traces that contain payload information for the variety of protocols needed for the evaluation, with statistics as presented in Table I. Table I: DARPA Trace Statistics Datagrams Trace
TCP
UDP
Total
Week 1
6,399,752 (82%)
1,404,824 (18%)
7,804,576
Active Hosts 31
Week 3
8118074 (91%)
802866 (9%)
8,920,960
31
To prepare the traces for a replay session, the traces were merged and then divided into datagrams originating from a
NETWORK CELL A
NETWORK CELL B
10.0.0.0/8
11.0.0.0/8
12.0.0.0/8
13.0.0.0/8
NETWORK CELL D
NETWORK CELL C Virtual Switch
Gateway
Local servers
Virtual host
Figure 3: Virtual enterprise network design
client host and those originating from a server host using a tcpreplay pre-processor, tcpprep [18]. The function of tcpprep is to split traffic in a .pcap file into two streams (traffic originating from client and server). The details of the two streams are then recorded in a .cache file. The resulting .cache file can then be used by tcpreplay to replay the traffic traces as client datagrams or server datagrams. The resulting client and server traffic was then replayed as clientserver communication using tcpreplay between endpoints on IPv4 class A size networks. C. Worm Daemon The evaluation process used the characteristics of the Slammer worm and a contemporary pseudo-worm that was developed based on the Microsoft RDP (CVE-2012-0002) vulnerability [19] of 2012. The Slammer worm was chosen because it is among the fastest worm outbreaks experienced on the Internet that caused financial losses and disruption of services. The developed contemporary pseudo-worm was used to further evaluate NEDAC using new potential fast scanning worm. To develop and use the pseudo-worms in experiments, some important metrics are required such as the susceptible populations for the vulnerability, worm datagram size and the likely scan rate. Moore et al. [20]reported that the Slammer worm had a susceptible population of atleast 75,000 hosts. They also noted that Slammer exhibited an average scan rate of 4000 datagrams per infected host per second and had a datagram size of 404 bytes. Ahmad and Woodhead [1] reported the likely susceptible population and potential datagram size of the Microsoft RDP vulnerability as having values of circa 16.5M and 3800 bytes respectively.Furthermore, the bandwidth available for an infected host and the worm datagram size determine how fast a worm can send datagrams. The average Internet connection speed was estimated to be within the range 10 Mbps to 1000 Mbps [21]. Although it is impossible for a host to achieve the maximum speed of a 4
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK network card, the vast majority of Internet connected hosts are capable of transmitting data at 60 Mbps to 120 Mbps [22]. Thus based on the assumption that the Internet connected hosts exhibit an average data transmission rate of 90 Mbps, the scan rate S, required for a single worm instance to transmit a datagram of size M (in bytes), over a C megabits Internet connection per second can be determined using S = (MC∗8) . Therefore, the likely scan rate for the RDP pseudo-worm is 90,000,000 = 2960 datagrams per second. 3800∗8 The scan rates of the pseudo-worms were scaled down by a factor of 32 and 24 for the Slammer and RDP pseudoworms respectively to avoid overloading server resources. The resulting scan rates employed in the experiments are 125 “infectious” datagrams per second for Slammer and RDP. Furthermore, the results of the experiments were scaled up by a factor of 32 and 24 for the Slammer and RDP pseudoworms respectively.
ENTERPRISE NETWORK A
ENTERPRISE NETWORK B
10.0.0.0/8
D
Border Router
RIP
D
12.0.0.0/8
ENTERPRISE NETWORK C
E. Procedure The evaluation was conducted using software prototypes of NEDAC and DNS-based detection schemes reported by Whyte et al. [10] and Shahzad and Woodhead [11]. A detection algorithm, termed DNS-RL, was developed based on the descriptions provided by the authors of the DNS-based schemes. During the evaluation, a prototype of a detection scheme was positioned on the gateways of each network (layer 3), and for NEDAC, the containment system was positioned on the switches (layer 2) as depicted in Figure 4. The sets of experiments conducted for each detection scheme comprise a test for Slammer and RDP pseudo-worms using random and then hit-list scanning behaviours. The random scanning technique probes IPv4 addresses within the routable address space. The hit-list scanning technique infects a list of precompiled vulnerable hosts and then each infected host uses random scanning. Random scanning was chosen because it is the commonly used propagation method for most of the notable worm outbreaks experienced on the Internet such as the
D RIP
RIP
D. Parameters Having determined the susceptible population values of the candidate worms along with the size of routable IPv4 address space (3, 673, 309, 759 [23]), the number of susceptible hosts per million Interneth hostsfor each pseudo-worm was determi Sp ∗ 1, 000, 000 , where, Pm denotes ined using Pm = Rip the value of susceptible hosts per million Internet hosts, Sp denotes the absolute number of susceptible hosts and Rip denotes the number of routable IPv4 addresses. The results were 21 and 4454 susceptible hosts per million Internet hosts for the Slammer and RDP pseudo-worms respectively. For experimentation in the prepared testbed, the values were scaled down depending on the number of required hosts. Three class A size networks were used for Slammer and four class B size networks for RDP. The sizes of IPv4 class A and class B networks are 224 and 216 respectively. Thus, 24 21 = 1057 and the resulting values were 2 ∗ 3 ∗ 1000000 16 4454 2 ∗ 4 ∗ 1000000 = 1168 susceptible hosts respectively, within the relevant network address space.
11.0.0.0/8
D
Router equipped with detection system
RIP
D 13.0.0.0/8
ENTERPRISE NETWORK D Switch equipped with NEDAC containment system
Figure 4: Prototype evaluation set up
Code Red [24], Slammer [20], Witty [25] and Conficker [26]. Additionally, hit-list scanning was also experienced during the Witty worm outbreak. Shannon and David [25] noted that the Witty worm used a hit-list size of 110 to 160 hosts within the first 30 seconds of the worm outbreak. This hit-list size was within the range of 1% to 2% of Witty susceptible hosts. Therefore, the evaluation used 1% and 2% of the susceptible population values of 1057 and 1168 for Slammer and RDP and pseudo-worms. The average hit-list sizes were 10 and 20 hosts. For each pseudo-worm experiment, a number of hosts (1057 for Slammer and 1168 for RDP) were configured with the correct daemon for worm attack datagrams while other hosts were configured to replay the DARPA traces as background traffic between endpoints across the network as depicted in Figure 5. The worm attack and traffic replay events were executed concurrently in each experiment. The experiments were conducted without any countermeasures in place, then repeated with the countermeasures and the DARPA dataset as background traffic using threshold values of 100 through 400 anomalous datagrams sent by a host in a timing window of 10 seconds.
V. E XPERIMENTATION For each worm propagation experiment, the virtual machines configured were powered to automatically synchronize their time with the NTP server, and then wait for inbound datagrams. The worm infection event was initiated by sending a UDP datagram to one of the vulnerable virtual machines. The virtual machines used Damn Small Linux [27] as the operating system. 5
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK
ENTERPRISE NETWORK A
ENTERPRISE NETWORK B
10.0.0.0/8
11.0.0.0/8
D
D RIP
RIP
Border Router
RIP
RIP
D
D
12.0.0.0/8
13.0.0.0/8
ENTERPRISE NETWORK D
ENTERPRISE NETWORK C
D
Router equipped with detection system
Switch equipped with NEDAC containment system
Worm traffic
Background traffic
Figure 5: Pseudo-worm attack and background traffic generation events
A. Slammer Pseudo-worm The Slammer pseudo-worm experiment was conducted using 1057 susceptible hosts across three class A size networks. The pseudo-worm daemon was configured to listen on UDP port 1434 and then transmit UDP datagrams to port 1434 at a scan rate of 125 “infectious” datagrams per second, once “infected”. Five Slammer pseudo-worm propagation experiments were conducted using one initially infected host. Figure 6 shows the average result of the five experiments. The Slammer pseudo-worm experiment was repeated with an initial hit-list [28] of 10 and 20 hosts. Figures 7 and 8 show the results of the Slammer pseudo-worm propagation using hit-lists of 10 and 20 hosts. B. RDP Pseudo-worm The RDP pseudo-worm experiment was conducted using 1168 susceptible hosts across four class B size networks. The pseudo-worm daemon was configured to listen on UDP port 3389 and then transmit UDP datagrams to port 3389 at a scan rate of 125 “infectious” datagrams per second, once “infected”. Five RDP pseudo-worm experiments were conducted using one initially infected host. Figure 9 shows the average result of the five experiments. As with Slammer, the RDP-based worm experiment was repeated with a hit-list [28] of 10 and 20 hosts. Figures 10 and 11 show the results of RDP pseudoworm propagation using hit-lists of 10 and 20 hosts. VI. R ESULTS The section initially discusses the infection behaviours of the candidate pseudo-worms using random and hit-list scanning. Then results of the false positives observed during the experiments are discussed.
A. Random Scanning Infection The results of random infection behaviours for the Slammer and RDP pseudo-worms using a threshold value of 100 are presented in Figures 6 and 9. When no countermeasure solution was in place, the Slammer pseudo-worm infected 95% (1004) of the hosts in 90 seconds as shown in Figure 6. Additionally, the RDP pseudo-worm infected 95% (1110) of its susceptible hosts in eight seconds as shown in Figures 9. Comparatively, the RDP vulnerability had a significantly higher susceptible population than Slammer and therefore the pseudo-worm infected the population in a relatively short time. When the detection schemes were applied, the infections were delayed and suppressed by DNS-RL and blocked completely by NEDAC. With DNS-RL, the Slammer pseudo-worm infection was delayed by 90 seconds and suppressed to 31% (330) of the susceptible hosts. For the RDP pseudo-worm, the infection was delayed by 12 seconds and suppressed to 50% (580) with DNS-RL. However, with NEDAC, the initially infected host, for each pseudo-worm experiment, was detected and then blocked from sending out datagrams at the data-link layer, which stopped the infection completely for each of the two worm outbreak scenarios.
B. Hit-list Scanning Infection Figures 7 and 10 show the results of the worm experiments conducted with a hit-list of 10 hosts. When no countermeasure was in place, the Slammer pseudo-worm infected 95% (1004) of the hosts in 55 seconds as shown in Figure 7. The RDP pseudo-worm attained 95% (1110) infection in 5 seconds as shown in Figure 10. With the DNS-RL scheme, the Slammer pseudo-worm infection attained 95% in 100 seconds. The RDP pseudo-worm attained 95% infection in 15 seconds with DNS-RL. For NEDAC, nine further infections were observed during the RDP pseudo-worm propagation and no further infections were observed during the propagation of the Slammer pseudo-worm. Figures 8 and 11 show the results of the worm experiments conducted with a hit-list of 20 hosts. When no countermeasure was in place, the Slammer pseudoworm infected 95% (1004) of the hosts in 45 seconds as shown in Figure 8. The RDP pseudo-worm attained 95% infection in 5 seconds as shown in Figure 11. Furthermore, with the DNSRL scheme, the Slammer pseudo-worm infection attained 95% in 65 seconds. The RDP pseudo-worm attained 95% infection in 9 seconds with DNS-RL. For NEDAC, 56 further infections were observed during the RDP pseudo-worm propagation and three further infections during the propagation of Slammer. C. Detection Performance All real pseudo-worm datagrams were detected by the schemes in all the experiments conducted and therefore the true positive (TP) and false negative (FN) rates are 100% and 0% respectively. However, the DNS-RL scheme incurred higher rates of false positives (FP) than NEDAC. NEDAC has very low FP rates using 100 and 200 as thresholds and zero FP rates using 300 and 400 as thresholds. The false positive 6
1100
1100
1000
1000
900
900
800
800 Number of infected hosts
Number of infected hosts
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK
700 600
Infection Infection + DNS-RL Infection + NEDAC
500 400
700 600
400
300
300
200
200
100
100
0 0
20
40
60
80
100 120 Time (second)
140
160
180
Infection Infection + DNS-RL Infection + NEDAC
500
0 0
200
20
40
60 Time (second)
80
100
120
Figure 7: Slammer with a hit-list of 10 hosts
Figure 6: Slammer randon scanning 1100
1200
1000 1000
900
Number of infected hosts
Number of infected hosts
800 700 600
Infection Infection + DNS-RL Infection + NEDAC
500 400
Infection Infection + DNS-RL Infection + NEDAC
800
600
400
300 200
200
100 0 0
10
20
30
40 Time (second)
50
60
70
0 0
80
15
20
25
Figure 9: RDP randon scanning
1200
1200
1100
1100
1000
1000
900
900
800 700 Infection Infection + DNS-RL Infection + NEDAC
600 500 400
Number of infected hosts
Number of infected hosts
10 Time (second)
Figure 8: Slammer with a hit-list of 20 hosts
800 700 Infection Infection + DNS-RL Infection + NEDAC
600 500 400
300
300
200
200 100
100 0
5
2
4
6
8 10 Time (second)
12
14
16
18
Figure 10: RDP with a hit-list of 10 hosts
0
2
6 Time (second)
8
10
12
Figure 11: RDP with a hit-list of 20 hosts 15
16 DNS-RL NEDAC
DNS-RL NEDAC False positive rate (%)
14 False positive rate (%)
4
12 10 8 6 4
10
5
2 0
0 100
200 300 Threshold
400
Figure 12: False positive rate for Slammer experiment
100
200 300 Threshold
400
Figure 13: False positive rate for RDP experiment
7
International Conference On Cyber Security And Protection Of Digital Services (Cyber Security 2016), 2016, London, UK rate generally diminishes with rising threshold values. NEDAC raised one false positive with threshold values of 100 and 200, which was caused by a multicast UDP datagram sent by a host to port 520. The datagram was a RIP advertisement because the packet sniffer used to collect the traces was positioned between the gateway of the “inside” network and an external router. Additionally, the rate at which RIP sends updates to neighbouring routers is not similar to fast scanning worm behaviour, although the RIP port can be added into the exempt list in NEDAC to avoid false positives. Across the whole experimental data set, NEDAC has a better performance in terms of false positives compared to the DNS-RL scheme. VII. C ONCLUSION AND F UTURE W ORK This paper has presented a cross-layer mechanism for the detection and containment of fast scanning worms, which we have termed NEDAC. NEDAC uses behavioural techniques at the network layer to detect the presence of worms. Upon identification of an infected host, the network layer detection invokes a data-link layer containment system to completely isolate the host. A software prototype of the NEDAC mechanism was used to conduct a set of experiments for evaluation. The results of the evaluation showed the sensitivity of NEDAC in detecting and containing an identified worm infection at an early stage with almost no false positives. The results of a comparative analysis showed that NEDAC has a better performance compared to the previously reported DNS-based detection schemes. As for future work, it is desirable to further evaluate the mechanism using contemporary malware attacks and a range of different background traffic. The aim of improving the accuracy of the detection system and speed of containment further will also be investigated. Furthermore, the effect of timing window size will be examined and an improved method of applying threshold values for hosts in a network will be investigated. R EFERENCES [1] Muhammad Aminu Ahmad and Steve Woodhead. Containment of fast scanning computer network worms. In Internet and Distributed Computing Systems, volume 9258 of Lecture Notes in Computer Science, pages 235–247. Springer International Publishing, 2015. [2] V Jyothsna, VV Rama Prasad, and K Munivara Prasad. A review of anomaly based intrusion detection systems. International Journal of Computer Applications, 28(7):26–35, 2011. [3] Faisal M Cheema, Adeel Akram, and Zeshan Iqbal. Comparative evaluation of header vs. payload based network anomaly detectors. In Proceedings of the World congress on Engineering, volume 1, pages 1–5, 2009. [4] Matthew V Mahoney and Philip K Chan. Phad: Packet header anomaly detection for identifying hostile network traffic. 2001. [5] Matthew M Williamson. Throttling viruses: Restricting propagation to defeat malicious mobile code. In Computer Security Applications Conference, 2002. Proceedings. 18th Annual, pages 61–68. IEEE, 2002. [6] Guofei Gu, Monirul Sharif, Xinzhou Qin, David Dagon, Wenke Lee, and George Riley. Worm detection, early warning and response based on local victim information. In Computer Security Applications Conference, 2004. 20th Annual, pages 136–145. IEEE, 2004. [7] Xinzhou Qin, David Dagon, Guofei Gu, and Wenke Lee. Worm detection using local networks. 2004. [8] Jaeyeon Jung, Vern Paxson, Arthur W Berger, and Hari Balakrishnan. Fast portscan detection using sequential hypothesis testing. In Security and Privacy, 2004. Proceedings. 2004 IEEE Symposium on, pages 211– 225. IEEE, 2004.
[9] Nicholas Weaver, Stuart Staniford, and Vern Paxson. Very fast containment of scanning worms. In USENIX Security Symposium, volume 2, pages 16–85, 2004. [10] David Whyte, Evangelos Kranakis, and Paul C van Oorschot. Dns-based detection of scanning worms in an enterprise network. In NDSS, 2005. [11] Khurram Shahzad and Steve Woodhead. Towards automated distributed containment of zero-day network worms. In Computing, Communication and Networking Technologies (ICCCNT), 2014 International Conference on, pages 1–7. IEEE, 2014. [12] Ke Wang and Salvatore J Stolfo. Anomalous payload-based network intrusion detection. In Recent Advances in Intrusion Detection, pages 203–222. Springer, 2004. [13] Sun-il Kim, Nnamdi Nwanze, William Edmonds, Blake Johnson, and Paloma Field. On network intrusion detection for deployment in the wild. In Network Operations and Management Symposium (NOMS), 2012 IEEE, pages 253–260. IEEE, 2012. [14] Sun-il Kim and Nnamdi Nwanze. Noise-resistant payload anomaly detection for network intrusion detection systems. In Performance, Computing and Communications Conference, 2008. IPCCC 2008. IEEE International, pages 517–523. IEEE, 2008. [15] Pedro Garcia-Teodoro, J Diaz-Verdejo, Gabriel Maciá-Fernández, and Enrique Vázquez. Anomaly-based network intrusion detection: Techniques, systems and challenges. computers & security, 28(1):18–28, 2009. [16] Pele Li, Mehdi Salour, and Xiao Su. A survey of internet worm detection and containment. Communications Surveys & Tutorials, IEEE, 10(1):20– 35, 2008. [17] Richard Lippmann, Joshua W Haines, David J Fried, Jonathan Korba, and Kumar Das. The 1999 darpa off-line intrusion detection evaluation. Computer networks, 34(4):579–595, 2000. [18] Aaron Turner and M Bing. Tcpreplay: Pcap editing and replay tools for* nix. online], http://tcpreplay. sourceforge. net, 2005. [19] CVE. Common Vulnerabilities and Exposures. [Online]. Accessed on 19th October 2014. https://cve.mitre.org/cgibin/cvename.cgi?name=CVE-2012-0002. [20] David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, and Nicholas Weaver. Inside the slammer worm. IEEE Security & Privacy, (4):33–39, 2003. [21] Net Index. [Online]. Accessed 16 November 2014. Available: http://www.netindex.com/. [22] Marshini Chetty, David Haslem, Andrew Baird, Ugochi Ofoha, Bethany Sumner, and Rebecca Grinter. Why is my internet slow?: making network speeds visible. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 1889–1898. ACM, 2011. [23] M Cotton and L Vegoda. Special use ipv4 addresses. Technical report, BCP 153, RFC 5735, January, 2010. [24] Cliff Changchun Zou, Weibo Gong, and Don Towsley. Code red worm propagation modeling and analysis. In Proceedings of the 9th ACM conference on Computer and communications security, pages 138–147. ACM, 2002. [25] Colleen Shannon and David Moore. The spread of the witty worm. Security & Privacy, IEEE, 2(4):46–50, 2004. [26] SANS. The Conficker Worm, November 2008. Available: http://www.sans.org/security-resources/malwarefaq/conficker-worm.php. [27] Damn Small Linux. [Online]. Accessed 19th October 2014. Available: http://www.damnsmalllinux.org/. [28] Stuart Staniford, Vern Paxson, Nicholas Weaver, et al. How to own the internet in your spare time. In USENIX Security Symposium, pages 149–167, 2002.
8
