Research Article Strengthening MT6D Defenses …downloads.hindawi.com/journals/jece/2016/5212314.pdfResearch Article Strengthening MT6D Defenses with LXC-Based Honeypot Capabilities

Research ArticleStrengthening MT6D Defenses with LXC-BasedHoneypot Capabilities

Dileep Basam J Scot Ransbottom Randy Marchany and Joseph G Tront

Bradley Department of Electrical and Computer Engineering Virginia Tech Blacksburg VA 24061 USA

Correspondence should be addressed to Dileep Basam dileepbavtedu

Received 5 November 2015 Revised 8 February 2016 Accepted 6 March 2016

Academic Editor Elias P Duarte

Copyright copy 2016 Dileep Basam et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Moving Target IPv6 Defense (MT6D) imparts radio-frequency hopping behavior to IPv6 networks by having participating nodesperiodically hop onto new addresses while giving up old addresses Our previous research efforts implemented a solution to identifyand acquire these old addresses that are being discarded by MT6D hosts on a local network besides being able to monitor andvisualize the incoming traffic on these addresses This was essentially equivalent to forming a darknet out of the discarded MT6Daddresses but the solution presented in the previous research effort did not include database integration for it to scale and beextendedThis paper presents a solution with a new architecture that not only extends the previous solution in terms of automationand database integration but also demonstrates the ability to deploy a honeypot on a virtual LXC (Linux Container) on-demandbased on any interesting traffic pattern observed on a discarded address The proposed architecture also allows an MT6D hostto query the solution database for network activity on its relinquished addresses as a JavaScript Object Notation (JSON) objectThis allows an MT6D host to identify suspicious activity on its discarded addresses and strengthen the MT6D scheme parametersaccordingly We have built a proof-of-concept for the proposed solution and analyzed the solutionrsquos feasibility and scalability

1 Introduction

Nodes participating in MT6D periodically relinquish IPaddresses and hop on to new addressesThis address-hoppingtrait of MT6D improves the security and privacy of IPv6networks however there is no feedback mechanism in thecurrent implementation that is a node engaged in a MT6Dconversation has no means of realizing if there is an attackeruncovering its MT6D addresses and trailing the MT6D nodealong its address hops

(i) Challenge In this work we propose a mechanism touse relinquished MT6D addresses in order to discover anyanomalies and gather intelligence on attacker methods Wealso build a proof-of-concept solution to impart darknet andhoneypot capabilities to MT6D scheme

(ii) Proposal Our approach to solve this problem is to designa solution that identifies and acquires the addresses dis-carded by theMT6D hosts and enumerating incoming trafficon these relinquished addresses in addition to providing

the ability to deploy a virtual container-based honeypotconfigured with a specific discarded address upon detectinga suspicious traffic pattern Our previous effort [1] includedbuilding a Central Node (CN) that passively listens to locallink traffic in promiscuous mode identifying and acquiringdiscarded addresses by MT6D nodes and performing trafficenumeration on these addresses The CN uses typical IPv6neighbor discovery protocol (NDP) messages like NeighborSolicit (NS) and Multicast Listener Discovery (MLD) mes-sages to reconstructwho is relinquishingwhich addresses andwhen to acquire them

The solutionrsquos ability to deploy a honeypot tied to adiscarded MT6D address of interest can potentially takeup the conversation forward with the attacker to gatherintelligence on attacker methods besides collecting attacktraffic samples for further analysisThe solution also allows anMT6D node to query the database for incoming traffic on itsdiscarded addresses thus giving theMT6Dnode the ability toanalyze the activity to identify malicious traffic or an attackerpersistently trailing on its discarded addresses to change

Hindawi Publishing CorporationJournal of Electrical and Computer EngineeringVolume 2016 Article ID 5212314 13 pageshttpdxdoiorg10115520165212314

2 Journal of Electrical and Computer Engineering

the scheme parameters for example move to a strongersecret-key or a faster hopping interval to evade the attacker

(iii) Threat Model and Assumptions We assume a threatmodel involving an attacker with infinite resources (com-pute cycles and time) with an ability to brute-force thescheme parameters for example the secret key involvedin address computation (hashing scheme) to discover theMT6D addresses But the attacker validating these uncoveredMT6D addresses will generate some traffic leaving a trail ofhisher activity on these discarded MT6D addresses

(iv) Goals In this paper we seek to impart honeypot capa-bilities to Moving Target IPv6 Defense (MT6D) in order toprovide a feedback mechanism for evaluating the strengthsof MT6D scheme by analyzing the activity on discardedMT6D addresses Among the goals of this effort the firstgoal is to implement the database integration into CN alongwith developing a way to build web server to offer real-time visualization of the local MT6D addresses that arebeing relinquished and incoming traffic on these discardedaddresses Our next goal is to implement a capability ofdeploying honeypot service on a virtual container on-demand bound to a discardedMT6D address of interest withminimal interruption observable to an attacker Lastly wewant to analyze the feasibility and scalability of the proposedsolution by analyzing the CPU and memory overhead trendswhile scaling to multiple honeypot containers

The paper is organized as follows First we providebackground on Moving Target IPv6 Defense (MT6D) LinuxContainer (LXC) Honeypots Dionaea and various compo-nents used in building the solution in Section 2 Related workon virtual honeypot based solutions and adaptivedynamichoneypot architectures is discussed in Section 3 Section 4explains our idea and high level approach Section 5 describesthe solution testbed and implementation details In Section 6we present our results visualizations and our observationsSections 7 and 8 present future work and conclusion

2 Background

In this section we present background starting with IPv6followed by Moving Target IPv6 Defense (MT6D) DionaeaLXC and other components used in building the solution

21 IPv6 On September 24 2015 the American Registryfor Internet Numbers (ARIN) announced that it allocatedthe final IPv4 address blocks in its free pool and the IPv4address space is completely exhausted The IPv6 protocol bydesign overcomes the address exhaustion limitation with itsaddress length of 128 bits This new address size allows for2128 possible addresses approximately 792 times 1028 addressesfor every possible IPv4 address

22 Moving Target IPv6 Defense (MT6D) The MT6D[2 3] involves nodes that change network addresses whilemaintaining active sessions Leveraging the large addressspace in IPv6 the MT6D protocol changes IP addresses for

communicating hosts in synchronization This achieves aneffect similar to frequency hopping in radio networks for anattacker passively listening to the conversation of two MT6Dhosts will see multiple hosts communicating with each otherrather than a pair of hosts MT6D achieves synchronizationbetween the involved nodes by having both ends of acommunication pair compute both their own IP addressand their remote-peerrsquos IP address during the particulartime window ldquo119905rdquo The scheme involves computation of theinterface-identifier part of the address that is IID1015840 extractedfrom first 64 bits from a hash digest (119867) of concatenatedstring made of a symmetric Secret-Key (SK) initial IID andcurrent time window ldquo119905rdquo

IID1015840 = 119867 [IID initial SK 119905]0rarr63 (1)

MT6D mechanism offers privacy and anonymity byhiding the original network layer addresses of involvedIPv6 nodes with dynamically generated addresses besidesprotecting against intrusion-based network attacks MT6Dprotects against address tracking and traffic correlation thushelping hosts keep their network identities private whileconducting sensitive communications

23 Dionaea and DionaeaFR Dionaea is a low-interactionhoneypot offering IPv6 support with an ability to capturemalware in addition to logging suspicious traffic Dionaeaoffers flexibility to configure services and interfaces to listenon Dionaea uses Sqlite as the backend database allowingcustom queries to be made to extract interesting informationfrom logs stored in the database [4]

DionaeaFR is an open-source library that offers front-end visualization of Dionaearsquos logs that are stored in theSqlite database DionaeaFRrsquos web server is implementedin Python and Django framework This front-end consoleallows retrieving statistics of traffic hitting the honeypot inaddition to offering a way to download attack traffic samplesfor example malware [5]

24 LXC LXC is a light-weight virtualization technologythat relies on isolated user spaces to create virtual containersthat share same kernel LXC uses Linux kernel featureslike namespaces Chroots CGroups and so forth to isolatethe container processes LXC differs from the concept ofstandard virtual machines (VM) by sharing the same kerneland underlying hardware which obviates the need for ahypervisor [6]

25 Other Components Used in Building the Solution

251 Scapy Pcapy Impacket Pyroute2 andWireshark Scapyis a Pythonmodule for packet crafting andmanipulation toolfor computer networks [7] Pcapy and Impacket are pythonlibraries for capturing and decoding raw network trafficPyroute2 is a network configuration library for binding IPaddresses to a Linux host Wireshark is a popular packetcapture and analysis tool [8]

Journal of Electrical and Computer Engineering 3

252 MongoDB and PyMongo MongoDB is a NoSQL data-base that stores each record in the database as a JSON objectand PyMongo is a Python library that acts as an applicationprogramming interface (API) to interact with MongoDBfrom Python code

253 D3js D3js is a JavaScript library that leveragesHTMLSVG and CSS to produce complex visualizations on a webbrowser [9]

254 Dstat Dstat is a free tool that combines vmstat iostatnetstat and ifstat to view system resources in real-time Thetool is used in thiswork to collect real-timeCPU (usrsys) andfree-memory (RAM) statistics during the experiments [10]

3 Related Work

A honeypot is a security resource that delivers insightsby getting probed attacked or compromised by maliciousentities [11] and subsequently reports the characteristics ofthe attack Honeypots are classified as either low or highinteraction based on their designed level of interaction withthe potential attacker Low-interaction honeypots as theirname suggests are often limited by the degree of interactionExamples of low interaction honeypots include Honeyd andDionaea On the other hand high-interaction honeypotssupport complex behavior by emulating a real operatingsystem with a full suite of applications High-interactionhoneypots carry more risk by allowing full compromise bythe attacker Honeypots have no legitimate production use forincoming traffic so in theory any traffic hitting a honeypotcan be deemed suspicious and warrant inspection

On the other hand a Honeynet is a basic network ofcommonly used operating systems in their default config-urations As a Honeynet does not broadcast its identity allincoming traffic is deemed illegitimate and further investi-gated Kuwatly et alrsquos work [12] discusses a dynamic honeypotsolution built from the fingerprinting tool (p0f) andNmap todynamically configure and leverage Honeyd-based emulatedvirtual hosts and a physical high-interaction honeypot clusterto capture and analyze attacker traffic Hecker et alrsquos paper[13] proposes a solution that uses nmap for fingerprintingthe local network (topology hosts ports etc) and Honeyd-configuration manager for dynamically building honeypots

Kishimoto et alrsquos work [14] on dynamic honeypot com-missioning involves detection of incoming address scanstargeting an unallocated IP address Research work done by[14] on commissioning honeypots based on incoming addressscans shows that disabling Duplicate Address Detection(DAD) makes the address acquisition faster During theprework tests we analyzed the relevant network capturesand found that we can significantly reduce the delay furtherby enabling a node to proactively claim ownership of theacquired address without waiting for NS messages fromrouterMore details are presented in Section 4 Hieb andGra-ham [15] employ dynamic honeypots and monitoring net-work activity of deployed honeypots to set up anomaly-basedintrusion detection for the network Brzeczkorsquos work [16]

on Turnkey Honeynet framework involved automatic com-missioning of Honeypots (Dionaea Kippo and Glastopf)depending on the composition of live attack traffic

Memari et al [17] built a virtual Honeynet and com-pared LXC virtualization with other virtualization methodsincluding VMware VirtualBox and KVM and concludedthat the LXC approach provides better performance Workby Sokol and Pisarcik [18] on Distributed Virtual Honeynetsframework talks about a master control center and a networkof high-interaction virtual Honeynets based on OpenVZ andLXC virtualization

Previous research work in this area involved creatingDarknets Network Telescopes and Honeynets with noadvertised services and listen for illegitimate traffic Thereare no current implementations adapting such a scheme tomoving target defense schemes like MT6D Also unlike astatic darknet that passively listens on unallocated addressspace our solution is dynamic as it learns IP-address andMACaddress associations from live network traffic to activelyacquire the addresses being purged in order to gatherintelligence on attacker methods Work presented in thispaper extends the related work discussed above in termsof a full IPv6 implementation framework of on-demandhoneypot commissioning using Linux containers (LXC) inaddition to proposing a method to leverage such a solutionto fortify MT6D defenses This solution presents a simplifiedvisualization of attacker traffic by ignoring the MT6D nodesthat do not have interesting incoming traffic to enable anuncluttered view of the suspicious traffic This work alsopresents a memory and CPU overhead analyses of the pro-posed solutionwhile scaling tomultiple honeypot containers

4 Idea and Approach

The central idea of this research effort is to devise a mecha-nism to gather intelligence on attacker methods by watchingfor suspicious traffic on relinquished MT6D addresses inaddition to be able to deploy a honeypot on a specific dis-carded address upon identifying a suspicious traffic pattern

To implement such a scheme as shown in Figure 1 wehave aMT6D-host that periodically hops onto new addresseswhile relinquishing old addresses A CN passively listens tothe network traffic in promiscuous mode to parse the NSandMLDmessages fromMT6D hosts to populate a databasecollection of who is relinquishing what address identifyingthe right time-instant to acquire these discarded addressesand subsequently binding these addresses to its local networkinterface After the CN binds these discarded addresses to itsnetwork interface it analyzes the incoming traffic on thesediscarded addresses andmay place a request to the honeypot-host for a honeypot container to be deployed on a specificIPv6 address The challenge is to migrate the IP addressfrom the CN to virtual LXC container on the honeypot-host(honeypot container) with minimal interruption observableto an external attacker who is sending the traffic to thediscarded address The steps involved in this process areunbinding a specific IP address on the CN binding thisaddress on honeypot container and finally invoking and


binding Dionaea and DionaeaFR services to this IP addresson the honeypot container

We propose an efficient and quick approach for hon-eypot deployment by maintaining hot spares of honeypotcontainers To facilitate the hot spares approach we packagedan LXC container with all prerequisites such as DionaeaDionaeaFR and supporting python libraries to act as a hon-eypot LXC-template The honeypot-commissioning-moduleon honeypot-host clones a fixed number of containers fromthe honeypot LXC-template in advance and maintains alist of available containers By keeping honeypot containerswaiting in a queue deploying a honeypot configured witha target IPv6 address requires that the only configurationneeded on the container-side is binding the IP address tothe network interface of an available container and startingDionaea honeypot andDionaeaFR (management web server)services This minimal configuration requirement ensuresminimal delay in bringing up honeypot service bound to thedesired IPv6 address

In order tominimize the interruptionwindow observableby an attacker during the migration of IP address from CN tohoneypot container we followed the approach of holding theaddress for a fixed-period after receiving the message that ahoneypot is being deployed from the honeypot-host For asmoother IP transition from CN to the honeypot containerbased on our initial tests we implemented the heuristic of CNholding the address for one second This address-holding-period compensates for the time it takes the IP address to bebound on containerrsquos network interface and to start Dionaeaand DionaeaFR services on the honeypot container

We went with the approach of using the honeypot-hostinstead of running a honeypot service on the CN itselffor two reasons First running honeypot on the CN maynot be a secure approach as the CN not only maintains adatabase of the discarded addresses but also actively collectsthe addresses that are currently active on MT6D hosts fromthe parsing of NS and MLD messages Secondly a designincluding a dedicated honeypot host with its own databaseallows flexibility for such a honeypot-host running virtualmachines with vulnerable-services to sit in a segregated zonelike a DMZ in the future while its partner CN can still be onthe local-network with MT6D nodes

Even though we used a low-interaction honeypot Dion-aea for experiments by the virtue of using LXC containers inour solution the solution allows high-interaction honeypotdeployment on the container So we are not limited toemulated services or virtual hosts in future experiments

5 Testbed and Implementation

The test setup as shown in Figure 1 involves three Linux desk-tops running the Ubuntu 1204 operating system connectedto a layer-2 switch with an uplink to the university networkrouter Virginia Tech has fully operational production IPv6networkTheMT6Dhost periodically acquires new addresseswhile relinquishing old addresses The CN identifies andacquires the discarded addresses on the local network and isalso responsible for performing traffic enumeration analysis

Virginia tech IPv6 production network

MT6D host Central Node (CN) Honeypot-host

Figure 1 Block diagram of test setup

and visualization Third Linux machine is the honeypot-hostsystem that is installed with LXC software to support on-demand creation of containers to act as individual honeypotsTo set context for the memory and CPU overhead analysesin Section 6 the honeypot-host system is a Dell OptiplexDesktop running 64-bit 1204 Ubuntu operating systeminstalled with Intel Core-2 6700 266GHz CPU 4GB RAMand 80GB of secondary memory

Figure 2 depicts the architecture of our solution Thesolution consists of CN block integrated with the database(MongoDB) and web server (Nodejs) modules for inter-module communication and real-time visualizations Thehoneypot-host block is implemented with on-demand hon-eypot deployment capability integrated with its dedicated(MongoDB) database

The implementation involves building honeypot-hostblock and implementing database integration for CN andhoneypot-host modules The CN includes traffic-parsingaddress-acquisition enumeration analysis and visualizationmodules The CN uses Pcapy and Impacket libraries in itstraffic-parsing module to listen to neighbor discovery (NSand MLD messages) conversations of all MT6D nodes onlocal link to learn the addresses that are being relinquished bythe MT6D nodes and stores these associations in a databaseIt employs the Pyroute library in address-acquisition moduleto acquire and bind these learned addresses to local hostand Scapy to send out a forced NA claiming ownership ofthe bound address as an unicast to the local-router TheCNrsquos traffic-enumeration module uses the same Pcapy andImpacket libraries to parse the incoming traffic on theseacquired addresses and does traffic enumeration (Source IPaddress Destination Port and Packet Count) storing thisdata in the form of a native python dictionaryThese python-dictionaries holding enumerated traffic data get converted toJSON objects for facilitating the visualizations A nodejs webserver has been built on the CN to offer visualizations basedon real-time traffic (MT6D addresses that are being spawnedand incoming traffic on acquired addresses) The visualizeddata offers two viewsMT6D view and attacker view (Figures


NSMLDmessages

MT6D hosts

Traffic parser

Addressacquisition logic

Trafficenumeration and

analysis

MT6D andattacker trafficvisualizations

Nodejs

Central Node (CN)

DB

DB

Honeypot commissioning moduleHoneypot

deployment andstatistics console

LXC container 1 LXC container 2

DionaeaFRDionaeaFRDionaeaFR

LXC container n

Honeypot system

Figure 2 Solution architecture

4 7 and 8) allowing an administrator to see whether anattacker is able to trail the MT6D node along the spawnedaddresses

Thehoneypot-host block includes the honeypot-commis-sioning module the LXC and a databaseThe honeypot-hostdatabase hosts two collections hpot requested collectionand hpot deployed collections for exchanging informationon addresses on which the honeypot is being requested ordeployed Figure 3 depicts the flow-diagram that explainsthe sequence of messages exchanged between the blocks andactions performed during the operation Step 1 involves theCN listening to and parsing local link NSMLD messagesto keep a list of MT6D addresses being relinquished onthe local network In Step 2 upon seeing an MT6D noderelinquish an address the CN assigns the address to itselfto facilitate traffic enumeration on this address In Step3 we have interesting incoming traffic hitting a discardedMT6D address (IPv6-address-of-interest) that is currentlybound to the CN Step 4 involves the CN requesting that ahoneypot be deployed on a specific IPv6 address by writingthe IPv6-address-of-interest to hpot requested collection onhoneypot-hostrsquos database In Step 5 the honeypot-host peri-odically checks hpot requested collection retrieves the IPv6-address-of-interest and acknowledges the CN by writingthe IP address to hpot deployed collection in honeypot-hostdatabase

In Steps 6 and 7 the CN continually checks for recordsin hpot deployed collection and upon finding a record theCN waits for a fixed time (the address-holding-period)and unbinds the address retrieved from hpot deployedcollectionrsquos record In the mean-time as shown in Step 8 thehoneypot-host checks for an available spare LXC containerin the queue and invokes a shell-script to run lxc-attachcommands to bind the IP-address on which honeypot isrequested to the containerrsquos network interface start the Dion-aea service to bind the honeypot service to the newly assignedIPv6 address and run the python web-server for launchingthe DionaeaFR front-end console To speed up the addressbinding process as specified in previous research effort [1]we disable Duplicate-Address-Detection (DAD) and use theconcept of a forced Neighbor Advertisement (NA) thus

advertising the new IPv6 address with the containerrsquos mac-address to the local router for quick address-acquisitionThiscompletes the deployment of a honeypot tied to a desiredIPv6 address and all future attacker traffic hits the honeypotcontainer

The MT6D view visualizations (Figures 4 and 7) showeach MT6D host represented by its mac address and all theaddresses relinquished by each MT6D host and incomingtraffic on each of these spawned addresses by source IPaddress and Protocol To simplify visualization of incomingtraffic without getting cluttered by new addresses that arebeing discarded by MT6D nodes and to observe the incom-ing traffic from the attacker perspective the attacker viewvisualization (as shown in Figure 8) view would show SourceIP (potential attacker) of incoming traffic at its root and thevisualization would then branch from each of these source-IPs of incoming traffic to a MT6D mac address and thenbranching to MT6D IPv6 addresses and incoming trafficcomposition in terms of protocol and port numbers andcorresponding packet-counts

In this chapter we have discussed how we implementedvarious components of the proposed solution and explainedhow information flows between different modules The nextsection presents evaluation of the solution in terms of ourobservations and results

6 Results

Our solution at its heart involves efficiently spinning up con-tainers on the honeypot-host and migrating the IP addressesfrom the CN to honeypot containers To characterize such asolution we will evaluate it in terms of interruption windowobservable by an attacker as well as CPU and memory over-headsThe interruption window observable to an attacker is acritical factor for judging the feasibility of the solution sincethe duration of interruption window may offer a cue to theattacker about migration of hisher traffic from one machine(the victim) to another (the honeypot) CPU and memoryoverhead analyses offer valuable insights into scalability ofthe solution that is the number of honeypot containers thatcan be accommodated for a specific honeypot-host system


MT6D host Central Node (CN) Honeypot host

Internet

(1) NSMLD messages

(2) Identify andacquire discardedMT6D address

(3) Interesting traffic from attacker on internetto a specific discarded MT6D address

(4) Request honeypoton this discardedMT6D address

(5) Honeypot-being-deployedmessage with address info

(6) Addressholdingperiod

(7) Unbindthe address onwhich honeypotis being deployed

(8) Locate a spare LXC container from queueBind the address to container network interfaceStart Dionaea service and DionaeaFR web server

(9) All future attacker traffic to the discardedaddress now hits the honeypot (Dionaea)running inside LXC container on honeypot-host

Figure 3 Flow diagram sequence of messages exchanged between various components

(CPU and memory) configuration We will also discuss amechanism for MT6D nodes to leverage our solution In thissection we will explain the methodology of the testing andpresent our results

61 Experiments and Results

611 Test Scenario We first present a particular instanceof potential attack-traffic hitting a discarded MT6D addressand launch a honeypot-service bound to the specific addresson an LXC container and supporting traffic visualizationsWe then present results detailing the address-migrationwindow times in terms of hold-packet-count and lost-packet-count for a ten-honeypot container deployment trial Wealso present our observations from CPU and memory over-head analyses for single five and ten-honeypot containerdeployment trials Hold-packet-count refers to the number ofpackets still hitting the CN since the trigger that deploys thehoneypot that is the first ICMP probe hitting the CN Lost-Packet-Count refers to the number of packets lost as seenby the attacker during the migration of an IP address to thehoneypot container from the CN

The experiment starts with an MT6D host with macaddress 0024e842c47a spinning off new addresses whiledropping its old addressesTheCN listens toMT6D hostrsquos NSand MLD messages and parses them to identify and acquirethe addresses that are being discarded by theMT6D host andvisualizes the incoming traffic on these discarded addressesFigure 4 shows the first level of a MT6D view visualiza-tion with the MT6D host represented by its mac address0024e842c47a at the center with each newly generatedMT6D address (eg 2001468c80c1118c239665ae9ac757)represented by the last 64 bytes (eg 8c239665ae9ac757)The 64 subnet prefix remains the same that is 20014680c80c111 for all the MT6D address children nodes

The next step involves sending ICMP echo probes(simulated attack traffic) every 50ms from the machine(at 26015c0c000773e15658df214082077) on a remoteInternet connection to a particular discardedMT6D address2001468c80c1118c239665ae9ac757 that is now assignedto the CN The first ICMP echo request packet serves asa trigger (as per configuration in the traffic enumerationand analysis module) for the CN to flag this activity andrequest a honeypot be deployed on this specific address


8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2

Figure 4 MT6D view depicting addresses spawned by a MT6D host

The CN sends a ldquohoneypot-requestedrdquo message with theaddress information to the honeypot-host databaseThe hon-eypot-commissioning-module retrieves the ldquohoneypot-re-questedrdquo message acknowledges the CN with a ldquohoneypot-deployedrdquo message picks the IP address and looks up thecontainer-queue for an available honeypot container Thehoneypot-commissioning-module identifies an availablecontainer (in this case ldquohpot-container 1rdquo) and assigns theIPv6 address under attack 2001468c80c1118c239665ae9ac757 to the local network interface of the honeypot containerand starts the Dionaea service and DionaeaFR python webserver on the container

Figure 5 shows an ICMP ping (sending ICMP echorequest probe every 50ms) results as seen by the attackerFigure 6 shows the Wireshark capture running on the CN toidentify the point when CN stops responding to the ICMPecho request packets incoming on the IPv6-address-of-interest indicating the unbinding Figure 7 presents a second-level MT6D view visualization of incoming attack traffic

showing an MT6D host with MAC address 0024e842c47areceiving ICMP traffic of type 0x80 and a count of 24 ona specific discarded address 8c239665ae9ac757 from anattacker at address 26015c0c000773e15658df214082077Figure 8 presents attacker-view visualization depicting anattacker at address 26015c0c000773e15658df214082077sending traffic to MT6D host with MAC address 0024e842c47a on a particular spawned MT6D address that is8c239665ae9ac757 and the traffic composition is ICMPType 0x80 and Code 0x00 (ICMP echo request) with acount of 24 MT6D view and attacker view present the visu-alization of the same traffic from two perspectives the formershows theMT6D host at the center whereas the attacker viewputs the attacker-address at the center of the visualizationand plots MT6D hosts that are getting hit from that specificattacker-address

612 Observations on Interruption Window From Figures5 6 7 and 8 we can infer that the first 24 ICMP echo


Figure 5 ICMP pingflood traffic from simulated attacker on a remote Internet connection at 50ms interval

Figure 6 Wireshark capture showing packets hitting CN before the IP address migration

request (ICMP type = 0x80 and code = 0) packets withsequence IDs till ldquo24rdquo hit the CN and one ICMP echo requestpacket with sequence ID ldquo25rdquo was lost while packets (withsequence IDs from ldquo26rdquo ldquo27rdquo ) were routed to honeypotcontainer resulting in subsequent ICMP echo replies inFigure 5 indicating successful IP address transition from CNto honeypot container

To verify the address-transition and Dionaea servicebinding we used an nmap NSE auth-spoof (generally usedfor testing authentication servers for malware infection)script as shown in Figure 9 to generate test-traffic on variousports targeting address of interest that is 2001468c80c1118c239665ae9ac757 Figure 10 shows the DionaeaFR consoledisplaying incoming connections for the address 2001468c80c1118c239665ae9ac757 on ports HTTPD SMB SIP andso forth

Figure 11 shows the hold-packet-counts and lost-packet-counts for the 10-honeypot deployment trial We can alsoobserve the IP address migration from the CN to the honey-pot container on honeypot-host involves loss of one packet ornone from the perspective of an attacker probing a discardedMT6D address with an ICMP echo request packet every50ms From the Wireshark packet captures we attribute thispacket-loss that is unresponsive ICMP echo requests to therouter on Virginia Tech production network either routingthe packet to the CN even after the IP address is migrated tothe honeypot container or the router forwarding the packet tohoneypot container while the container is still in the processof binding the address to its network interface In either caseeven though the packet makes it to CN or the honeypotcontainer depending on routing-table entry neither of themcan respondwith ICMP echo reply as the address is not activeon their respective network interfaces

613 Observations on CPU and Memory Overheads Figures12 13 and 14 show CPU and memory (RAM) loading

characteristics for three independent trials of single hon-eypot container five-honeypot container and ten-honeypotcontainer deployment CPU time comprises Usr-CPU andSys-CPU Usr-CPU is CPU time spent in user-mode outsidekernel code and Sys-CPU is the CPU time spent in thekernel within the process handling system calls and otherkernel-space events We observed that the trend of mem-ory consumption with honeypot-service being deployed oneach container is proportionally linear (sim125MB for eachhoneypot container launch) while CPU consumption peakstemporarily and then remains constant The baseline free-memory consumption for the honeypot-host after a cleanreboot was observed to be around 3025 MegaBytes Thebaseline CPU consumption was observed to be nominalFrom the observed memory and CPU consumption trendwe substantiate the virtue of using the hot-spare LXC con-tainers approach as the containers waiting as spares placenominal load on system resources and only request resourcesMemory and CPU on-demand when we invoke Dionaea andDionaeaFR management-server services on the container

Figure 12 shows memory and CPU consumption fora single honeypot container experiment From the originuntil the point ldquoArdquo on the free-memory curve represents thememory consumption on machine serving as baseline Atepoch timesim1443048570 the LXC container ldquohpot-container1rdquo is cloned from honeypot-LXC-template and the ldquohpot-container 1rdquo is started and lies waiting as hot spare in thequeue We can observe a drop in free-memory at point ldquoArdquoAt epoch time sim1443048801 the honeypot-commissioning-module runs a script to bind the requested IPv6 addressstart the Dionaea service and start the DionaeaFR pythonweb server on container ldquohpot-container 1rdquo This step bringsup Dionaea service bound to desired IP address on ldquohpot-container 1rdquo We can observe a significant drop (sim125MB) infree-memory at point ldquoBrdquo on the curve in response toDionaeaand DionaeaFR service invocation We can also observe


8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2

ICMP_Type_Code8000-gt24

ICMP_Type_Code8000-gt

35

Figure 7 MT6D view of incoming traffic hitting the CN visualized

the CPU (Usr and Sys CPU) consumption spike to a peakvalue at the time instant corresponding to point ldquoBrdquo that isat the launch of honeypot services on the virtual containerand subsequently remain constant

Figure 13 depicts the CPU and memory consumptiontrend for a five honeypot container trial Fromorigin until thepoint ldquoArdquo on the free-memory curve represents the baselinememory consumption

At epoch time sim1443023165 five containers (ldquohpot-container 1rdquo ldquohpot-container 2rdquo ldquohpotcontainer 5rdquo) arecloned from honeypot-LXC-template These cloned contain-ers are started and made to wait as hot-spares in queueAt epoch times corresponding to points ldquoBrdquo ldquoCrdquo ldquoDrdquo ldquoErdquoand ldquoFrdquo on the free-memory curve one can observe dropsin available-memory corresponding to instants of binding

requested IP address and invocation of the Dionaea serviceandDionaeaFRweb-server on each LXC honeypot containerWe can also observe the CPU consumption spike to peakvalue at the time instants corresponding to points ldquoBrdquo ldquoCrdquoldquoDrdquo ldquoErdquo and ldquoFrdquo that is at the launch of honeypot serviceson the virtual-containers and subsequently lie constant

Figure 14 shows similar memory consumption behaviorfor a ten-honeypot-deployment trial at epoch time corre-sponding to point ldquoArdquo that is sim1443029196 ten containers(ldquohpot-container 1rdquo ldquohpot-container 2rdquo ldquohpot-container10rdquo) are cloned started and lie waiting in hot spares queueEpoch times corresponding to points ldquoBrdquo ldquoCrdquo ldquoDrdquo ldquoErdquoldquoFrdquo ldquoGrdquo ldquoHrdquo ldquoIrdquo ldquoJrdquo and ldquoKrdquo on the free-memory curvecorrespond to IP address binding and invocation of Dionaeaservices We can also observe the CPU consumption spike to



8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077root ICMP_Type_Code8000-gt35

f8a1cc15e13c7d9d

Figure 8 Attacker view of incoming traffic hitting the CN visualized

Figure 9 Nmap script to send test traffic on various services to a deployed honeypot

Figure 10 DionaeaFR console showing deployed honeypot connection statistics

peak value at the time instants corresponding to points ldquoBrdquoldquoCrdquo ldquoDrdquo ldquoErdquo ldquoFrdquo ldquoGrdquo ldquoHrdquo ldquoIrdquo ldquoJrdquo and ldquoKrdquo that is at thelaunch of honeypot services on the virtual-containers andsubsequently remain constant

62 How Can a MT6D Node Leverage Our Solution TheMT6D nodes can consume the CNrsquos intelligence on attacker-activity using the solutionrsquos Mongo database API The JSONobject responsible for Figure 8 the attacker-view visual-ization can be queried from the CNrsquos database by anyMT6D host to detect a trailing attacker by identifyingall the attacker-address nodes that have the MT6D hostrsquosMAC address as child node In this case the MT6D hostwith the MAC address 0024e842c47a can analyze theJSON object responsible for Figure 8 to understand itsMAC address is a child node for the attacker address26015c0c000773e15658df214082077 and among its relin-quished addresses particularly MT6D addresses ending with

8c239665ae9ac757 and f8a1cc15e13c7d9d were hit withICMP echo request traffic Based on the attack traffic com-position the MT6D host can communicate with its MT6Dpartner and change its scheme parameters (eg strongersecret-key and faster hopping-interval) to evade any trailingattackers

With this solution in place nodes participating in MT6Dcan uncover any suspicious activity on their relinquishedaddresses and be able to use it in fine-tuning the schemeparameters The solutionrsquos traffic enumeration and honeypotdeployment capabilities offer insights into attacker methodsIn this chapter we evaluated our solution in terms of inter-ruption window observable to an attacker CPU andmemoryoverhead analyses in addition to discussing a mechanismto offer gathered intelligence on relinquished addresses toMT6D nodes through an JSON API In the next section wewill conclude our findings and provide directions for futurework


Pack

et co

unt

Packet-loss observed from attackerHold-packets

50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0

Figure 11 Chart giving out Hold-packet counts and packet-loss observed by an attacker during one of the 10-honeypot deployment trialsinvolving sending an ICMP echo request every 50ms that is rate of 20 packetssecond

Free

-mem

ory

(RA

M) (

MB)

Epoch timeFree-memoryUsr CPU ()Sys CPU ()

100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)

Figure 12 Memory and CPU loading characteristics for the scenario of 1-honeypot container hot spare and subsequent deployment

7 Future Work

Future work should include CPU and memory overheadanalyses of the solution under complex attack scenariosand evaluation of the solutionrsquos performance (IP-address

migration times and packet-loss observable to attacker) withthe honeypot-host sitting in a segregated environment likea DMZ It is also important to perform overhead analy-sis on network devices as such a solution grabbing dis-carded addresses on a complex MT6D network would place


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Free-memoryUsr CPU ()Sys CPU ()

100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)

Figure 13 Memory and CPU loading characteristics for the scenario of 5-honeypot container hot spares and subsequent deployment

Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549


overhead on the router in terms of persistent routing tableentries Future work can also include enhancing the solutionwith a new feature that would reclaim active honeypotcontainers based on no or low-priority incoming attackertraffic hitting a deployed honeypot container

8 Conclusion

In this work we proposed a solution to dynamically deploya LXC container-based honeypot upon detecting suspiciousactivity on discarded MT6D addresses We also evaluated

the built solution in terms of interruption observable to anexternal attacker CPU and memory overhead analyses todemonstrate the feasibility and scalablility of such a solutionFrom our tests we observed that the interruption observableto an attacker is one packet or none during the migrationof the IPv6 address from the CN to the honeypot containerWe also observed that the trend of the memory consumptionwith number of honeypot containers being deployed to beproportionally linear while CPU consumption peaks to avalue and stays constant during the launch of the honeypot-service on each container This supports the argument that


the presented solution in this effort is scalable provided thatthe memory and compute resources can be catered by theunderlying honeypot-host hardware

The implemented solution offers two visualization viewsMT6D view and attacker-view MT6D view displays nodesrepresenting discarded addresses from all MT6D hosts ina local network and their corresponding incoming trafficAttacker view displays nodes corresponding to attackersaddresses sending traffic and those specific MT6D hosts anddiscarded addresses that are receiving attack traffic As wecan observe from Figures 7 and 8 attacker view simplifiesthe visualization over MT6D view by the virtue of ignoringMT6Dnodeswith no interesting trafficMT6Dnodeswith noincoming traffic no longer appear on the visualization thusresulting in less-cluttered visualization of interesting activityThis paves way for visualizing suspicious activity on largeMT6D networks without getting burdened by the periodicaddress-hopping activity

The solution with database-integration also allows anyMT6D node to query for traffic activity on its discardedMT6D addresses as a JSON object This can be integrated asa feedback mechanism into work that our fellow researchersMorrell et al are doing in the area of MT6D Client-Serverstack in terms of an MT6D Server looking up suspiciousactivity on discarded addresses and communicating newMT6D scheme parameters such as longer secret-key or fasteraddress-hopping interval to its MT6D client [19]

Previous work done by Morrell et al [20] showed that aserver can successfully bind up to 60000 randomly generatedaddresses with each bound address communicating withan individual client Based on these observations the CNshould be able to bind and listen on a large number ofdiscarded MT6D addresses We would also like to point outthe solutionrsquos honeypot-deployment ability is unaffected bythe number of MT6D nodes on network as the incomingtraffic enumeration and analysis are delegated to the CNand the honeypot-host resources are engaged only when theCN matches incoming traffic with a configured attack-trafficsignature

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

Theauthors would like to thankChrisMorrellMike Cantrelland Dr David Raymond Virginia Tech for their manyhelpful suggestions and comments during the course ofresearch

References

[1] D Basam R Marchany and J G Tront ldquoAttention movingtarget defense networks how well are youmovingrdquo in Proceed-ings of the 12th ACM International Conference on ComputingFrontiers (CF rsquo15) article 54 ACM 2015

[2] M Dunlop S Groat W Urbanski R Marchany and J TrontldquoMT6D a moving target IPv6 defenserdquo in Proceedings of

the IEEE Military Communications Conference (MILCOM rsquo11)pp 1321ndash1326 IEEE Baltimore Md USA November 2011

[3] M Dunlop S Groat W Urbanski R Marchany and J TrontldquoThe blind manrsquos bluff approach to security using IPv6rdquo IEEESecurity amp Privacy vol 10 no 4 pp 35ndash43 2012

[4] Google ldquoDionaea the honeynetprojectrsquos 2009rdquo 2009 httpdi-onaeacarnivoreit

[5] R Espadas Dionaeafr 2014 httpsgithubcomrubenespadasDionaeaFR

[6] Canonical ldquoLxcrdquo 2015 httpslinuxcontainersorglxc[7] P Biondi ldquoScapyrdquo 2011 httpwwwsecdevorgprojectsscapy[8] G CombsWireshark 2007 httpwwwwiresharkorg[9] M Bostock ldquoD3jsrdquo Data Driven Documents 2012[10] D Wieers ldquoDstatrdquo 2013 httpdagwieershome-madedstat[11] L Spitzner ldquoHoneypots catching the insider threatrdquo in Pro-

ceedings of the 19th Annual Computer Security ApplicationsConference pp 170ndash179 IEEE December 2003

[12] I Kuwatly M Sraj Z Al Masri and H Artail ldquoA dynamichoneypot design for intrusion detectionrdquo in Proceedings of theIEEEACS International Conference on Pervasive Services (ICPSrsquo04) pp 95ndash104 IEEE Beirut Lebanon July 2004

[13] C Hecker K L Nance and B Hay ldquoDynamic honeypot con-structionrdquo in Proceedings of the 10th Colloquium for InformationSystems Security Education University of Maryland AdelphiMd USA June 2006

[14] K Kishimoto K Ohira Y Yamaguchi H Yamaki and HTakakura ldquoAn adaptive honeypot system to capture IPv6address scansrdquo in Proceedings of the IEEE International Con-ference on Cyber Security (CyberSecurity rsquo12) pp 165ndash172Washington DC USA December 2012

[15] J Hieb and J H Graham ldquoAnomaly-based intrusion detectionfor network monitoring using a dynamic honey potrdquo TechRep TR-ISRL-04-03 Intelligent Systems Research LaboratoryUniversity of Louisville Louisville KY USA 2004

[16] A W Brzeczko Scalable framework for turn-key honeynetdeployment [PhD dissertation] Georgia Institute of Technol-ogy Atlanta Ga USA 2014

[17] N Memari S J Hashim and K Samsudin ldquoDesign of a virtualhybrid honeynet based on lxc virtualisation for enhancednetwork securityrdquo Defence SampT Technical Bulletin vol 7 no 2p 120 2014

[18] P Sokol and P Pisarcik ldquoDigital evidence in virtual honeynetsbased on operating system level virtualizationrdquo in Proceedingsof the Security and Protection of Information pp 22ndash24 BrnoCzech Republic May 2013

[19] CMorrell R Moore R Marchany and J G Tront ldquoDHT blindrendezvous for session establishment in network layer movingtarget defensesrdquo in Proceedings of the 2nd ACM Workshop onMoving Target Defense (MTD rsquo15) pp 77ndash84 ACM DenverColo USA October 2015

[20] C Morrell J S Ransbottom R Marchany and J G TrontldquoScaling IPv6 address bindings in support of a moving targetdefenserdquo in Proceedings of the 9th International Conference forInternet Technology and Secured Transactions (ICITST rsquo14) pp440ndash445 London UK December 2014

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics


Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks



the scheme parameters for example move to a strongersecret-key or a faster hopping interval to evade the attacker

(iii) Threat Model and Assumptions We assume a threatmodel involving an attacker with infinite resources (com-pute cycles and time) with an ability to brute-force thescheme parameters for example the secret key involvedin address computation (hashing scheme) to discover theMT6D addresses But the attacker validating these uncoveredMT6D addresses will generate some traffic leaving a trail ofhisher activity on these discarded MT6D addresses

(iv) Goals In this paper we seek to impart honeypot capa-bilities to Moving Target IPv6 Defense (MT6D) in order toprovide a feedback mechanism for evaluating the strengthsof MT6D scheme by analyzing the activity on discardedMT6D addresses Among the goals of this effort the firstgoal is to implement the database integration into CN alongwith developing a way to build web server to offer real-time visualization of the local MT6D addresses that arebeing relinquished and incoming traffic on these discardedaddresses Our next goal is to implement a capability ofdeploying honeypot service on a virtual container on-demand bound to a discardedMT6D address of interest withminimal interruption observable to an attacker Lastly wewant to analyze the feasibility and scalability of the proposedsolution by analyzing the CPU and memory overhead trendswhile scaling to multiple honeypot containers

The paper is organized as follows First we providebackground on Moving Target IPv6 Defense (MT6D) LinuxContainer (LXC) Honeypots Dionaea and various compo-nents used in building the solution in Section 2 Related workon virtual honeypot based solutions and adaptivedynamichoneypot architectures is discussed in Section 3 Section 4explains our idea and high level approach Section 5 describesthe solution testbed and implementation details In Section 6we present our results visualizations and our observationsSections 7 and 8 present future work and conclusion

2 Background

In this section we present background starting with IPv6followed by Moving Target IPv6 Defense (MT6D) DionaeaLXC and other components used in building the solution

21 IPv6 On September 24 2015 the American Registryfor Internet Numbers (ARIN) announced that it allocatedthe final IPv4 address blocks in its free pool and the IPv4address space is completely exhausted The IPv6 protocol bydesign overcomes the address exhaustion limitation with itsaddress length of 128 bits This new address size allows for2128 possible addresses approximately 792 times 1028 addressesfor every possible IPv4 address

22 Moving Target IPv6 Defense (MT6D) The MT6D[2 3] involves nodes that change network addresses whilemaintaining active sessions Leveraging the large addressspace in IPv6 the MT6D protocol changes IP addresses for

communicating hosts in synchronization This achieves aneffect similar to frequency hopping in radio networks for anattacker passively listening to the conversation of two MT6Dhosts will see multiple hosts communicating with each otherrather than a pair of hosts MT6D achieves synchronizationbetween the involved nodes by having both ends of acommunication pair compute both their own IP addressand their remote-peerrsquos IP address during the particulartime window ldquo119905rdquo The scheme involves computation of theinterface-identifier part of the address that is IID1015840 extractedfrom first 64 bits from a hash digest (119867) of concatenatedstring made of a symmetric Secret-Key (SK) initial IID andcurrent time window ldquo119905rdquo

IID1015840 = 119867 [IID initial SK 119905]0rarr63 (1)

MT6D mechanism offers privacy and anonymity byhiding the original network layer addresses of involvedIPv6 nodes with dynamically generated addresses besidesprotecting against intrusion-based network attacks MT6Dprotects against address tracking and traffic correlation thushelping hosts keep their network identities private whileconducting sensitive communications

23 Dionaea and DionaeaFR Dionaea is a low-interactionhoneypot offering IPv6 support with an ability to capturemalware in addition to logging suspicious traffic Dionaeaoffers flexibility to configure services and interfaces to listenon Dionaea uses Sqlite as the backend database allowingcustom queries to be made to extract interesting informationfrom logs stored in the database [4]

DionaeaFR is an open-source library that offers front-end visualization of Dionaearsquos logs that are stored in theSqlite database DionaeaFRrsquos web server is implementedin Python and Django framework This front-end consoleallows retrieving statistics of traffic hitting the honeypot inaddition to offering a way to download attack traffic samplesfor example malware [5]

24 LXC LXC is a light-weight virtualization technologythat relies on isolated user spaces to create virtual containersthat share same kernel LXC uses Linux kernel featureslike namespaces Chroots CGroups and so forth to isolatethe container processes LXC differs from the concept ofstandard virtual machines (VM) by sharing the same kerneland underlying hardware which obviates the need for ahypervisor [6]

25 Other Components Used in Building the Solution

251 Scapy Pcapy Impacket Pyroute2 andWireshark Scapyis a Pythonmodule for packet crafting andmanipulation toolfor computer networks [7] Pcapy and Impacket are pythonlibraries for capturing and decoding raw network trafficPyroute2 is a network configuration library for binding IPaddresses to a Linux host Wireshark is a popular packetcapture and analysis tool [8]





3 Related Work







4 Idea and Approach


















NSMLDmessages

MT6D hosts

Traffic parser



analysis


Nodejs

Central Node (CN)

DB

DB





LXC container n

Honeypot system








6 Results




Internet

(1) NSMLD messages
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation













3 Related Work







4 Idea and Approach


















NSMLDmessages

MT6D hosts

Traffic parser



analysis


Nodejs

Central Node (CN)

DB

DB





LXC container n

Honeypot system








6 Results




Internet

(1) NSMLD messages
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation
























NSMLDmessages

MT6D hosts

Traffic parser



analysis


Nodejs

Central Node (CN)

DB

DB





LXC container n

Honeypot system








6 Results




Internet

(1) NSMLD messages
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










NSMLDmessages

MT6D hosts

Traffic parser



analysis


Nodejs

Central Node (CN)

DB

DB





LXC container n

Honeypot system








6 Results




Internet

(1) NSMLD messages
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











Internet

(1) NSMLD messages
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077

root

f8a1cc

15e13c7d

9d

0c4956d72977871c

a57b

1f16

0446

b6a2
















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation



















8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










8c239665ae9ac7

57

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408

2077ro

ot

f8a1cc

15e13c7d

9d

0c4956d72977871ca5

7b1f

1604

46b6

a2



35









8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











8c239665ae9ac757

00

24

e842

c47

a2601

05

c0c0

00

773

e1565

8df2

1408


f8a1cc15e13c7d9d









Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










Pack

et co

unt


50

45

40

35

30

25

20

15

10

5

0

hpot

-con

tain

er 1

hpot

-con

tain

er 2

hpot

-con

tain

er 3

hpot

-con

tain

er 4

hpot

-con

tain

er 5

hpot

-con

tain

er 6

hpot

-con

tain

er 7

hpot

-con

tain

er 8

hpot

-con

tain

er 9

hpot

-con

tain

er 1

0


Free

-mem

ory

(RA

M) (

MB)


100

90

80

70

60

50

40

30

20

10

0

A

B

1443048456

1443048481

1443048506

1443048531

1443048556

1443048581

1443048606

1443048631

1443048656

1443048681

1443048706

1443048731

1443048756

1443048781

1443048806

1443048831

1443048856

3050

3000

2950

2900

2850

2800

2750

Usr

Sys

CPU

usa

ge (

)


7 Future Work




Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










Free

-mem

ory

(RA

M) (

MB)

Epoch time


100

120

80

60

40

20

0

3500

3000

2500

2000

1500

1000

500

0

A B C D E F

1443022625

1443022725

1443022825

1443022925

1443023025

1443023125

1443023225

1443023325

1443023425

1443023525

1443023625

1443023725

1443023825

1443023925

1443024025

1443024125

Usr

Sys

CPU

usa

ge (

)


Free

-mem

ory

(RA

M) (

MB)

Epoch time

Usr

Sys

CPU

usa

ge (

)


AB C

D E F G HI J

K

100

90

80

70

60

50

40

30

20

10

0

3500

3000

2500

2000

1500

1000

500

0

1443028849

1443028949

1443029049

1443029149

1443029249

1443029349

1443029449

1443029549

1443029649

1443029749

1443029849

1443029949

1443030049

1443030149

1443030249

1443030349

1443030449

1443030549



8 Conclusion








Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation














Competing Interests


Acknowledgments


References




















RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation







