SEINA: A Stealthy and Effective Internal Attack in Hadoop Systems

Transcription

1 SEINA: A Sealhy and Effecive Inernal Aack in Hadoop Sysems Jiayin Wang, Teng Wang, Zhengyu Yang, Ying ao, Ningfang i, and Bo Sheng Deparmen of Compuer Science, Universiy of assachuses Boson, 1 orrissey Boulevard, Boson, A 2125 Deparmen of Elecrical and Compuer Engineering, Norheasern Universiy, 36 Huningon Ave., Boson, A 2115 Absrac Big daa processing frameworks such as Hadoop [1] have been widely adoped in he pas few years. However, he securiy issues in such large scale sysems have no been well sudied ye. While mos of he prior work is focused on he daa privacy and proecion, his paper invesigaes a poenial aack from a compromised inernal node agains he overall sysem performance. We explore he vulnerabiliies of he exising Hadoop sysem, and develop an effecive aack launched from he compromised node ha can significanly degrade he daa processing performance of he cluser wihou being deeced and blacklised for job execuion. In addiion, we presen a miigaion scheme ha proecs a Hadoop sysem from such aack. We conduc experimens on real sysems, and he resuls show ha his aack grealy slows down he job execuions in he naive Hadoop sysem even wih some basic defense mechanisms. Our miigaion scheme, while causing a minor overhead in normal circumsances, can keep he whole cluser running efficienly under his aack from he compromised inernal node. I. INTRODUCTION Wih he rise of cloud compuing and big daa analyics, more and more users are using big daa processing frameworks o analyze various ypes of daa. Users eiher own or ren a large-scale compuing cluser o deploy a framework such as Hadoop [1], [2] and Spark [3], [4], and process hese large volumes of daa. Some companies also offer he daa processing service, such as AWS [5]. Since big daa analyics provides criical informaion o a wide se of applicaions, he securiy of he processing plaform becomes a serious concern. While mos of he prior work considers he daa securiy and privacy, his paper considers a novel aack ha aims o degrade he processing performance of he enire cluser. The problem is moived by wo facs. Firs, when using a large scale cluser wih ens or hundreds of machines, users may no be able o harden and proec each node perfecly. Securiy breach and node comprise are possible in pracice. Second, once a node is compromised, he daa loss is no he only damage. Job execuion ime is also crucial o such a cluser, especially when i is processing a large bach of jobs. In his paper, we develop a sealhy and effecive aack SEINA, ha once launched can significanly prolong he job execuion ime. The main idea is o manipulae he ask execuion on he compromised node by pausing i and resuming i when needed. This aack is sealhy as i does no falsify any informaion or violae he daa processing proocol. We also consider ha he cluser may have deployed some defense mechanisms. Our aack will follow he securiy policy wihou riggering any alarm. On he oher hand, his aack is very effecive because i is designed based on he undersanding of he daa processing framework. Our main inuiion is o explore he vulnerabiliy of he curren speculaion scheme which sars a redundan ask when he original ask execuion becomes slow. In his paper, we use Hadoop as he arge plaform, bu he aack can be applied o any oher frameworks wih buil-in speculaion scheme. Our aack manipulaes he execuion imeline of he asks assigned o he compromised node so ha he whole cluser has o wai a long ime for he finish of hose asks. Wih a careful managemen, his aack can yield an exremely long delay which is much more serious han jus no paricipaing he compuaion. In addiion, we presen a miigaion scheme ha helps proec he exising Hadoop sysem agains his new aack. Wih a small overhead in regular circumsances, he miigaion scheme can grealy improve he performance under aack. We have implemened he aack and miigaion schemes in Hadoop YARN plaform, and conduced exensive experimens in real sysem environmens. The resuls show ha his new aack is devasaing in he naive Hadoop sysem, and our miigaion scheme is an effecive defense agains i. The res of his paper is organized as follows: Secion II reviews he relaed work and Secion III inroduces he background of Hadoop sysem and formulaes our problem. The design of he new aack SEINA is presened in Secion IV, and we discuss he miigaion scheme in Secion V. Finally, we presen he evaluaion resuls in Secion VI and conclude in Secion VII. II. RELATED WORK As one of he mos popular open-source implemenaions of apreduce [2], Hadoop [1] is wildly being adoped in Big Daa processing. However, many comprehensive sudies [6] [8] also indicaed ha challenges and issues of securiy in cloud compuing sill remain in Hadoop, including he impacs of muli-enancy, elasiciy and hird pary conrol, upon he securiy requiremens. To solve hese securiy relaed issues, a buil-in secure mode module [9] is proposed in he naive Hadoop YARN [1], which consiss of hree mechanisms: auhenicaion (i.e., by using Kerberos or Delegaion Tokens beween core Hadoop services and cliens), service level auhorizaion (i.e., cliens permissions o access given Hadoop services) and daa con-

2 2 fidenialiy (i.e., daa encrypion on Hadoop services/cliens RPC and cross-daa-node block daa ransferring). However, Hadoop is no ready for secure hybrid-cloud compuing in large scale sysems [11], [12], since i is originally designed o work on a single cloud and no aware of he presence of he daa wih differen securiy levels. To overcome his challenge, a secure daa-inensive compuing sysem called Sedic [13] is proposed, which schedules individual map asks over a carefully planned daa placemen, in a way ha he asks wihin he privae cloud only work on sensiive daa and hose on he public cloud only processes public daa. [14] furher proposed a novel DDoS deecion mehod based on Hadoop ha implemens a HTTP GET flooding deecion algorihm in Hadoop on he disribued compuing plaform. Laer, a securiy soluion SAPSC [15] is proposed based on he HDFS layer, wih maser/slave archiecure under he environmen of a Privae Sorage Cloud exended wih a Parner/Public Cloud. eanwhile, a fullscale, daa-cenric, repuaion-based rus managemen sysem for Hadoop clouds called Haman [16] is developed o leverage he clouds disribued compuing power o srenghen is securiy, which is achieved by formulaing boh consisency-checking and rus managemen as secure cloud compuaions. III. BACKGROUND AND SYSTE ODELS In his secion, we ake Hadoop as an insance o inroduce he background of big daa processing frameworks and he vulnerabiliies o poenial aacks from a compromised node. A he end, we formulae he problem by presening he sysem model, securiy model, and adversaries objecive. A. Archiecure of big daa processing frameworks Big daa processing frameworks, such as Hadoop, are usually deployed in a large scale cluser consising of a maser node and many slave nodes. Users submi heir jobs o he maser node, and each job is composed of many asks which can be execued in parallel in he cluser. Cenralized conrolling modules are deployed a he maser node in charge of monioring slave nodes saus and dispaching asks o slave nodes for execuion. Paricularly in Hadoop YARN, Resourceanager in he maser node manages he slave nodes and he resource allocaion. And Nodeanager is deployed on each slave node. Each job firs launches a special ask, Applicaionaser, on a slave node. Applicaionaser splis he job o muliple asks, generaes resource requess ha are sen o Resourceanager, and negoiaes resources wih he scheduler in Resourceanager. In urn, Resourceanager responds o a specific resource reques by graning a resource conainer which is an allocaion of a specific amoun of resources (CPU, memory ec.) on a specific Nodeanager. Then Applicaionaser works wih Nodeanagers o execue asks in he conainers. One ask can execue in one conainer and he conainer will erminae once he ask is finished. In addiion, every Nodeanager needs o repor he available resources of is slave node periodically o Resourceanager. B. How he cluser handle slow execuions In his paper, our design of he aack arges on he vulnerabiliy of speculaion scheme which is a common soluion for handling slow ask execuion in big daa processing plaforms. In his subsecion, we briefly inroduce how he speculaion works in Hadoop which helps undersand he aacking echnique presened in he nex secion. In he Hadoop sysem, if a ask is deeced as running slowly, a redundan ask (speculaive ask) will be creaed in he sysem as an alernaive. Hadoop runs a background speculaor service ha mainains a saisics able o record he average execuion ime of a ask for each job. The daa in his able is updaed upon he compleion of each ask. The speculaor service will periodically check his able and he running asks o find he candidae asks for speculaive execuion. Specifically, i enumeraes all he running asks and esimae he finish ime of each ask i based on he elapsed ime and he curren progress as shown in Eq(1), where T now is he curren imesamp, T sar (i) is he saring ime of ask i, T mean is average execuion ime wih he ask ype of i and P G(i) indicaes i s curren progress. In addiion, he speculaor service esimaes he finish ime of he alernaive speculaive execuion in Eq(2). The execuion ime of he speculaive ask is esimaed as he mean value of he hisoric execuion imes of he same ype of asks mainained in he saisic able. EsEnd = T now T sar (i) + T sar (i) (1) P G(i) EsRepEnd = T mean + T now (2) The speculaor service will creae a new ask aemp of he seleced running ask if EsEnd > EsRepEnd. In addiion, Applicaionaser configures a hreshold ha every ask canno execue longer han (T erm ). Above all, a redundan ask will be creaed for a running ask when: T now > min( P G(i) 1 P G(i) T mean, T erm ) + T sar (i). C. Problem Formulaion In our problem seing, we consider ha a se of jobs are submied o a Hadoop cluser consiss of one maser node and m slave nodes. We consider a homogeneous cluser and assume ha for he same ype of asks in he same job, he execuion ime of each ask is he same, generally denoed as. Thus, we assume ha he aacker is aware of he execuion ime of each ask she or he plans o aack. In pracice, his execuion ime daa can be lean from hisoric execuion of he same ype of asks because each node including he compromised node before deeced will be assigned wih muliple asks from he same ype of processing. In addiion, we assume ha he Hadoop sysem can apply a basic defense scheme ha deecs abnormal ask execuions and records he number of heir occurrences on each node. Once he abnormal evens happened on a node exceed a hreshold τ, he node is considered suspicious and blacklised. In pracice, here are various ways o define an abnormal ask

3 3 execuion. In his paper, we consider he following represenaive definiions referring o differen defense schemes: Defense I: A ask execuion is considered abnormal if he original ask is no successfully finished, i.e., he Hadoop sysem has o sar a speculaive ask and i is finished before he original ask. Defense II: A ask execuion is considered abnormal if he ask is finished, bu he execuion ime is abnormally long regardless if he original ask is finished or no. In he design of SEINA, our objecive is o develop an aacking sraegy ha maximizes he execuion ime of he jobs under he basic defense schemes. Here is a reference able of he noaions ha will be used in our analysis. Their deailed definiions will be inroduced in he nex secion. m i / τ D(θ, ) D( i ) number of nodes in he cluser a paricular ask / execuion ime of a ask abnormaliy hreshold he Hadoop sysem ses delay of a ask(execuion ime ) if i s paused a progress θ delay of job execuion when ask i is aacked TABLE I: Noaions IV. DESIGN OF SEINA In his secion, we presen he deails of he aack ha sealhily and effecively prolongs he execuion ime of a bach of jobs in a processing cluser. Once a node is compromised, he adversary gains he full conrol, and can launch a wide se of aacks. For example, he compromised node can refuse o execue he assigned asks, repor more resource availabiliies o arac more asks, and delee or revel he hosed daa. However, hese kinds of aacks can be easily deeced and he Hadoop sysem will exclude i from he cluser by lising i in a blacklis. Then he wors damage is he loss of one compuing node, and he daa hosed here. In his paper, we aim o develop a beer aacking sraegy ha could cause much more serious performance degradaion han jus losing a node. Our main idea is o le he aacker inendedly delay he execuion of vicim asks assigned o he compromised node which will evenually rigger speculaive asks o be launched on oher nodes. In he res of his secion, we firs presen how o delay a ask s execuion, and analyze he addiional overhead caused by he aack. Then we furher analyze how a delayed ask affecs he execuion ime of a job and he makespan of muliple jobs. Finally, we presen complee aacking algorihms ha arge on he hree basic defenses menioned in he previous secion. A. Delayed execuion of a single ask In a Hadoop sysem, each ask is execued in a resource conainer which refers o an individual process on he hosing node. Once a node is compromised, he aacker is able o view all he running processes, pause and resume heir execuions via exernal process managemen commands. Therefore, he aacker can pause he execuion in any resource conainer, and resume i laer if needed. Specifically, if he aacker plans o delay he execuion of a paricular ask (given he ask ID), she or he can check he Hadoop log messages and find he ID of he process (PID in Linux) ha is execuing he ask. Then he aacker can execue he exernal commands o pause he specific process. In he res of his subsecion, we analyze he impac of he delayed execuion, i.e., if he sysem has o wai and sar a speculaive ask o finish he ask, how much more ime i has o spend comparing o a regular execuion. Assume ha a ask s regular execuion ime is. The aacker sars o execue he ask a ime, and pauses he execuion when he progress becomes θ. We use D(, θ) o indicae he delay caused by his seing. Afer he execuion is paused, a a given ime poin T θ, he expeced finish ime of he ask is T θ, and he finish ime of a speculaive ask is T +. The cluser will decide o launch a speculaive ask when T θ > T + T > 1 θ 1 Therefore, he longes delay we can achieve given and θ is D(θ, ) = 1 θ 1 (3) The following Fig. 1 illusraes an example of delayed execuion. Pause execuion ( θ = 2/3) T = 2 Speculaive execuion Fig. 1: Inuiions of he aack: In his example, he aacker pauses he execuion of a ask when i reaches he progress of 2 3. The Hadoop sysem wais unil ime T = 2 o realize ha i worhwhile o sar a speculaive ask. A ime T, he original ask is expeced o be finished a T θ = 3 2 T = 3, which is he same as saring a speculaive ask (T + = 3 ). Apparenly, D(θ, ) is an increasing funcion on θ. To cause he mos serious damage, he aacker should pause he ask execuion when he progress is very close o 1. However, in pracice, he progress repor funcion in Hadoop is no finegrained, and here are also some aomic processes ha canno be divided. Therefore, he repored progress value is discree and bounded when inclining close o 1. We define α (, 1) as he larges progress an unfinished ask can reach before he finish. Then he mos delay he aacker can cause for a single ask is D(α, ) = 1 α 1. For example, when α = 9%, he delay is D(α, ) = 9 which is quie significan.

4 4 B. Impac of he delayed asks on job execuions In his subsecion, we furher analyze he impac of he aack on he execuion of a job or muliple jobs. Specifically, we need o answer he following wo quesions: (1) when he adversary aacks a ask causing D(α, ) delay, wha is he impac on he execuion ime of he job he vicim ask belongs o? and (2) if muliple jobs are running, wha is he impac on he makespan performance. In a Hadoop apreduce job, here are wo kinds of asks, i.e., map asks and reduce asks. We assume ha he aacker will mainly focus on he map asks, because here are much fewer reduce asks and hus he compromised node may no ge he chance o hos hem. Based on his assumpion, we furher presen he analysis of he overhead of a single job caused by a delayed map ask. Assume ha a single job consiss of map asks running in a cluser wih m nodes. Each node can hos r conainers o run he map asks and each map ask s execuion ime is. The map phase of he job will be finished in he ime of m r. In paricular, he ask execuions roughly follow waves. There are m r waves for every node, and anoher final wave for a subse of nodes. Node 1 Node 2 Node 3 Delayed execuion Fig. 2: An example of delay execuion aack: he delayed ask is he las finished map ask in his case. Assume he aacker delays he execuion of a ask in i- h wave, hen in he following ime period of D(α, ), he compromised node can offer r 1 conainers o execue he map asks. Thus, he finish ime of he map phase under aack is { T < D(α, ) m r 1 T = T + D(α,) (m r 1) oherwise m r (4) where T = i + D(α, ) and = i m r. Referring o Fig. 2, when he aack sars, here are asks lef o be assigned. Depending on he value of i and D(α, ), here are wo cases in he analysis. Firs, he delayed ask is he las o finish in he map phase, which indicaes he map phase will ake T = T o finish. The condiion for his case is ha he delay D(α, ) is long han he execuion ime of he remaining asks wih m r 1 conainers, i.e., m r 1. In he second case, he aacked ask is no he las one in he map phase. Afer i resumes o he normal sae, he cluser will coninue o execue oher pending asks ( D(α,) (m r 1)) wih m r conainers. For muliple job execuions, he impac on he overall makespan canno be expressed in a closed form. However, we can apply he similar analysis o esimae he delay. Due o he page limi, we omi he deails in his paper. Overall, for a paricular ask i, we can derive he delay of he job execuion caused by aacking i, denoed as D( i ). C. ain algorihm Finally, we presen he complee aacking algorihms based he analysis of delayed execuion aack. We develop differen sraegies agains each of he wo defenses we menioned. Agains Defense I: The firs defense only couns unfinished asks and is no effecive agains an inelligen aack. Wih our delayed execuion echnique, he adversary can easily bypass abnormaliy deecion and he hreshold checking of τ, and aack every ask assigned o he compromised node. Specifically, he aacker can firs normal execue he ask unil he progress reaches α, hen pauses he execuion. The Hadoop sysem will evenually sar a speculaive ask afer D(α, ) delay. Wih he knowledge of he ask execuion ime and speculaion policy, he aacker can esimae he ime when he speculaive ask will be launched and finished. Then, he aacker can resume is own ask s execuion before he speculaive ask s progress reaches α, i.e., ensure ha is ask is finished before he speculaive ask. In his case, he aacker s behavior is no considered abnormal. Pause execuion Speculaive ask Resume execuion Fig. 3: Illusraion of he aack agains Defense I Therefore, he bes sraegy agains Defense I is o aack every ask assigned o he compromised node by pausing each ask a progress α, waiing for T A, and hen resuming he execuion. The waiing T A can be calculaed as T A = D(α, ) + α. In pracice, he aacker can make a more conservaive esimaion o make sure is ask will finish before he speculaive ask by seing T A = β (D(α, ) + α ), β (, 1) In our evaluaion, we se β =.8. Agains Defense II: The second defense is more effecive as i couns he slow execuion of asks. Once he aacker launches he delayed execuion process, i will be deeced regardless if he ask is finished or no. In his case, he aacker has o consider he abnormaliy hreshold τ, and canno delay every ask assigned o i. The bes sraegy for he adversary is o selec a se of vicim asks o aack wihou violaing he abnormaliy policy. For example, if he sysem hreshold τ is 5%, hen he adversary can delay a mos 5 asks ou of 1 asks assigned o he compromised node. Therefore, he problem of developing he bes aacking sraegy becomes how o selec k vicim asks o aack in order o maximize he job execuion ime. The consrain parameer k is derived from he abnormaliy hreshold τ. We find ha he special case of his problem is similar o he radiional job scheduling problem, and can be reducible o he bin-packing problem which is NP-hard. The proof is omied due o he page limi. In his paper, we presen a greedy algorihm o solve he problem. The idea is o ieraively selec he ask

5 5 ha can cause he longes delay. The deailed algorihm is shown in Algorihm 1. Algorihm 1 Aacker s Algorihm agains Defense II 1: Iniialize he resul se of seleced asks RET = {} 2: For each job s map ask, calculae D(α, ) 3: while RET < k do 4: for each job j s map ask do 5: d j1 = D( i ), i is in he las wave 6: d j2 = D( i ), i is in he second las wave 7: = j %(m r) ( 8: p j = 1 (m 1) r ) ( / m r 9: end for 1: Sor all d j1 p j and d j2 (oally 2 j values) in he descending order 11: Add he firs ask in he lis o he reurn se RET 12: Rearrange he ask execuions considering he asks in RET being delayed 13: end while In his algorihm, we use RET o represen he seleced asks for he aack, iniializing i as empy (line 1). Then we consider each job s map asks as he candidaes, and calculae he delayed of each ask if i is under aack (line 2). Then we use a while loop o selec k asks as he arges (lines 3 13). In each round, we enumerae all he jobs and calculae wo delays for each job s map asks. d j1 is he delay caused by aacking he ask in he las wave while d j2 is he delay when we aack a ask in he second las wave. Based on he analysis in he previous subsecion and Eq. 4, we find ha under he same circumsance, i is more effecive o delay he asks in he ailing waves han he asks in he earlier waves. Thus he asks in he las wave are he bes candidae for he aack. However, no every node would be able o serve in he las wave. So we consider wo candidaes for each job, he ask in he second las wave which for sure will be assigned o he compromised node, and he ask in he las wave which causes he mos damage, bu may no be assigned o he compromised node. In our algorihm, we use p j o represen he probabiliy ha he compromised node can execue a ask in he las wave. In line 7, j is he oal number of map ask in job j, and is he remainder of divided by m r which is he number of map asks in he las wave. The Hadoop resource manager will randomly pick conainers across he cluser o serve hese asks. The equaion in line 8 calculaes he probabiliy p j. Evenually, he algorihm considers all he candidaes, wo values from each job. For he delay caused by he ask in he las wave, we use he expeced value of p j d j1 for comparison. The bes choice for he aack is he ask wih he longes delay (lines 1 11). Once a candidae is seleced for he aack, we will consider he new arrangemen of he ask execuions assuming ha asks in RET will be delayed by D(α, ). Then he algorihm repeas he process and selecs he nex candidae. I erminaes when here are k seleced asks in he resul se RET. ) V. ITIGATION SCHEE In his secion, we briefly discuss some miigaion schemes ha can proec a Hadoop sysem from he delayed execuion aack. Firs, as we have discussed, Defense II is a beer sraegy han Defense I. The Hadoop sysem needs o monior he execuion ime of every ask on each node. A abnormally slow ask is a suspicious sign of aacks. However, in pracice, i is difficul o se an appropriae value for he hreshold τ because a benign node may occasionally yield a slow execuion. On he oher hand, he aack may behave normally in he earlier waves, and hen aack he las wave or second las wave o significanly prolong he job execuion. In his paper, we presen wo echniques ha can help reduce he negaive impac when he sysem is under aack. Our main inuiion is o proec he execuion of he las wave which is he major arge and he mos imporan wave for he job execuion. Firs, he Hadoop sysem should selec he mos reliable or fases nodes o execue he asks in he las wave. Various merics can be used here o sor all he nodes, such as he average ask execuion ime and he op/boom ask execuion ime. This is a sronger proecion han he abnormaliy hreshold checking. If he compromised node has launched delay execuion in he earlier waves, bu sill wihin he hreshold τ, i sill has he equal probabiliy o hos he asks in he las wave. In our miigaion scheme, however, if he sysem can find sufficien more reliable nodes (e.g., wih no slow execuion a all), he compromised node will be excluded from execuing he las wave. Second, we propose o change he policy for launching a speculaive ask in he las wave. In order o defend he sysem, we need a more aggressive policy. We may sar a speculaive ask even if he esimaed finish ime of a speculaive ask is laer han he original ask. In our miigaion scheme, when he original ask becomes slow, we use a parameer γ (, 1) o adjus he comparison. Le T o and T s be he esimaed execuion ime of he original ask and a speculaive ask. In sead of comparing T o and T s, our scheme checks wheher T s is shor han γ T o. If i is rue, a speculaive ask will be launched. In our evaluaion, we se γ =.75. In fac, boh echniques cause addiional overhead in regular circumsances wih no aacks. Bu hey do save a lo of execuion ime when he sysem is under aack. In Secion VI, we presen evaluaion resuls ha show he effeciveness of our miigaion scheme. VI. IPLEENTATION AND EVALUATION In his secion, we will firs inroduce he sysem implemenaion and presen he performance evaluaion resuls of boh SEINA and our miigaion scheme. A. Sysem Implemenaion Firs, o achieve he aacking of SEINA, we creae a se of new modules in he node manager: he Conainer onior (C), he Conainer Conroller (CC), and he Conainer Operaor (CO). C is responsible for monioring he execuion of each conainer including he saus of each conainer, he

6 6 execuion ime of each compleed conainer, he progress of each running conainer, and so on. CC is in charge o conrol a conainer o be paused or resumed according o he algorihms in SEINA and he saisics of C. While receiving he commands from CC, CO riggers he process commands in Linux o pause or resume a conainer. Second, we implemen our miigaion scheme on Hadoop YARN version We modified he RConainerAllocaor of Applicaionaser o assign ailing asks of every job o he appropriae node managers, and DefaulSpeculaor o change he policy for launching a speculaive ask in he las wave. B. Tesbed Seup and Workloads All experimens are conduced on NSF CloudLab plaform a he Universiy of Uah [17]. Each server has 8 ARv8 cores a 2.4GHz, 64 GB memory and 12 GB sorage. We launched a Hadoop YARN cluser wih 1 maser node and 8 slave nodes. In each slave node, we configured 16 vcores and 64 GB memory. Our workloads for evaluaion consider general Hadoop benchmarks wih large daases as he inpu. In paricular, we use wo daases in our experimens including 2 GB wiki caegory links daa and 2 GB synheic daa. The wiki daa includes wiki page caegories informaion, and he synheic daa is generaed by he ool TeraGen in Hadoop. We choose he following hree Hadoop benchmarks from Hadoop examples library o evaluae he performance: (1) Terasor: Sor (key,value) uples on he key wih he synheic daa as inpu. (2) Word Coun: Coun he occurrences of each word wih a lis of Wikipedia documens as inpu. (3) Wordmean: Coun he average lengh of he words wih a lis of Wikipedia documens as inpu. C. Performance Evaluaion Our performance meric is he makespan of a bach of jobs. In he cluser, we assume only one node manager is aacked and ohers can work normally. We mainly compare he changing of he makespan in various siuaions. Two caegories of ess are conduced wih differen workloads: simple workloads consis of he same ype of jobs and mixed workloads represen a se of hybrid jobs. We generae 6 jobs of he same benchmarks in each es of simple workloads. And for esing mixed workloads, we mix all hree benchmarks above and generae 2 jobs for each benchmark. For each job of boh simple and mixed workloads, he inpu daa is 2 GB. There are 8 map asks and 1 reduce asks creaed by each job. Each map ask requires 1vcore + 2GB memory and each reduce ask requires 1vcore + 3GB memory. In he res of his subsecion, we separaely presen he evaluaion resuls of boh he aacks and he miigaion scheme. 1) Performance Impac by he Aack: For our firs experimen, we conduc he es resuls of he makespan impac by various kinds of aack: he horough aack, he aack agains Defense I, and he aack agains Defense II. Thorough aack. Firs, we run he es wih he horough aack. In oher words, all he ask conainers in he aacked node manager can be paused during he execuion according o he algorihm in IV. To show he performance impac of he horough aack, besides he makespan wihou any aack, we also es he resuls wih one node manager blocked in he cluser. As illusraed in Fig. 4, Hadoop:Non-aack indicaes he makespans of boh simple and mixed workloads wihou any aack. Node Blocked shows he makespans wih one node manager blocked, i.e., here are only 7 slave nodes working in he cluser. Compared o Hadoop:Non-aack, he average makespan wih one slave node blocked only increases 14.3%. Thorough Aack presens a much beer impac on reducing he performance of he makespan which is averagely 76.4% larger han Hadoop:Non-aack. akespan (Sec) Hadoop:Non-aack Node Blocked Thorough Aack Terasor WordCoun Wordean ix Fig. 4: akespan wihou any aack: (1) Hadoop:Non-aack (Naive Hadoop) (2) Node Blocked (Naive Hadoop wih one nodeanager blocked), and (3) wih horough aack. Aack agains Defense I. Second, we consider a policy in he Resourceanager o block he suspicious Nodeanagers wih several killed asks. In Hadoop, a ask may be killed because of wo reasons: 1) is execuion ime is oo long and beyond a hreshold (6 seconds by defaul) in Applicaionaser; 2) i runs oo slow and is speculaive ask has finished earlier. If he Resourceanager deecs any job wih n percen of asks killed in a Nodeanager, such Nodeanager will be blocked as an aacker. In his case, SEINA needs o conrol he pause ime of every aacked conainer and guaranee each ask can be finished before is speculaive ask and won execue longer han he hreshold configured in Applicaionaser. Fig. 5 shows he es resuls of boh simple and mixed workloads. During he experimens, we se a severe value of n =.15%. For he job wih 8 map ask and 1 reduce asks, only 1 killed ask per job can be generaed by SEINA. SEINA:Time-conrol indicaes he aacking resuls of SEINA under Defense I. On average, he makespan under SEINA:Time-conrol prolongs 46.7% compared o he one wihou any aack. And he makespan under SEINA:Timeconrol is only 16% less han Thorough Aack. Aack agains Defense II. Furhermore, we consider anoher sric policy in he Resourceanager which moniors he execuion ime of every ask on each Nodeanager and block he one wih several slow conainers. Specifically, for each job, if here are k asks on a Nodeanager running slower han he average ask execuion ime, such Nodeanager will be considered as an aacker and ge blocked. In his case, insead of he horough aack, he aacker needs o conrol he number of aacked ask conainers wihin he number of k per each job. Fig. 6 illusraes he es resuls wih k = 3. During he

7 7 akespan (Sec) Hadoop:Non-aack SEINA:Time-conrol Terasor WordCoun Wordean ix Fig. 5: akespan under SEINA: conrolling he pause ime of every aacked conainer es, SEINA only aacks 1 or 2 ask conainers for every job and sill significanly affecs he performance of he makespan of boh simple and mixed workloads. SEINA:1 / SEINA:2 indicae he es resuls by aacking one/wo ask per job. For a oal number of 8 asks for each job, SEINA increases meanly 36.2% and 61% of he makespan by aacking 1 and 2 asks per job. On average, he makespan of SEINA:2 is only 8.7% less han he one of Thorough Aack. Overall, SEINA indicaes boh efficien and effecive aacking resuls. akespan (Sec) Hadoop:Non-aack SEINA:1 SEINA:2 Terasor WordCoun Wordean ix Fig. 6: akespan under SEINA: (1) SEINA:1: aack one ask per job, and (2) SEINA:2: aack wo asks per job. 2) Performance of he iigaion Scheme: In he end, we run he experimens of our miigaion scheme. Fig. 7 illusraes he performance wih SEINA aacking agains Defense II, and he makespan of he miigaion scheme in a normal environmen wihou any aack. Ours:Aack indicaes he makespans wih he miigaion scheme under SEINA and he average makespan only increase 11.1% compared o he one wihou any aack. Ours:Non-aack shows he makespans wih he miigaion scheme wihou any aack. Wihou any aack, he mean makespan of Ours:Non-aack is jus 5.6% larger han he one of he naive Hadoop. From he es resuls, he miigaion scheme can effecively defense he aack of SEINA and causes a minor overhead in he environmen wihou any aack. akespan (Sec) Hadoop:Non-aack Ours:Non-aack Ours:Aack Terasor WordCoun Wordean ix Fig. 7: akespan under he miigaion scheme VII. CONCLUSION This paper sudies a securiy problem in big daa processing frameworks. Our goal is o degrade he overall sysem performance by launching aacks from a compromised inernal node. We ake Hadoop YARN as a represenaive plaform and develop a new aack scheme SEINA which can effecively prolong he makespan of he applicaions agains wo basic defense schemes. Furhermore, we creae a miigaion scheme o proec he Hadoop sysem from such aack. Our evaluaion is based on experimens wih various workloads and seings. The resuls show a significan performance reducion caused by SEINA on he naive Hadoop sysem, and an effecive proecion from our miigaion scheme agains SEINA. REFERENCES [1] Apache Hadoop. hp://hadoop.apache.org. [2] Jeffrey Dean and Sanjay Ghemawa. apreduce: simplified daa processing on large clusers. Communicaions of he AC, 51(1):17 113, 28. [3] Apache Spark. hp://spark.apache.org. [4] aei Zaharia, osharaf Chowdhury, Tahagaa Das, e al. Resilien disribued daases: A faul-oleran absracion for in-memory cluser compuing. In NSDI, 212. [5] Amazon AWS ER. hps://aws.amazon.com/emr/. [6] Lockneed. Awareness, rus and securiy o shape governmen cloud adopion. L Cyber Securiy Alliance and arke Connecion Whie Paper, 21. [7] Kevin Hamlen, ura Kanarcioglu, Laifur Khan, and Bhavani Thuraisingham. Securiy issues for cloud compuing. Opimizing Informaion Securiy and Advancing Privacy Assurance: New Technologies: New Technologies, 15, 212. [8] Jiaqi Zhao, Lizhe Wang, Jie Tao, Jinjun Chen, Weiye Sun, Rajiv Ranjan, Joanna Kołodziej, Achim Srei, and Dimirios Georgakopoulos. A securiy framework in g-hadoop for big daa compuing across disribued cloud daa cenres. Journal of Compuer and Sysem Sciences, 8(5):994 17, 214. [9] Hadoop in secure mode. hps://hadoop.apache.org/docs/r2.7.1/ hadoop-projec-dis/hadoop-common/secureode.hml. [1] Vinod Kumar Vavilapalli, Arun C urhy, Chris Douglas, Sharad Agarwal, ahadev Konar, Rober Evans, Thomas Graves, Jason Lowe, Hiesh Shah, Siddharh Seh, e al. Apache hadoop yarn: Ye anoher resource negoiaor. In Proceedings of he 4h annual Symposium on Cloud Compuing, page 5. AC, 213. [11] Borja Soomayor, Rubén S onero, Ignacio Llorene, and Ian Foser. Virual infrasrucure managemen in privae and hybrid clouds. IEEE Inerne compuing, 13(5):14 22, 29. [12] Jianzhe Tai, Deng Liu, Zhengyu Yang, Xiaoyun Zhu, Jack Lo, and Ningfang i. Improving flash resource uilizaion a minimal managemen cos in virualized flash-based sorage sysems. Cloud Compuing, IEEE Transacions on, PP:1 1, 215. [13] Kehuan Zhang, Xiaoyong Zhou, Yangyi Chen, XiaoFeng Wang, and Yaoping Ruan. Sedic: privacy-aware daa inensive compuing on hybrid clouds. In Proceedings of he 18h AC conference on Compuer and communicaions securiy, pages AC, 211. [14] Yeonhee Lee and Youngseok Lee. Deecing ddos aacks wih hadoop. In Proceedings of The AC CoNEXT Suden Workshop, page 7. AC, 211. [15] Qingni Shen, Yahui Yang, Zhonghai Wu, Xin Yang, Lizhe Zhang, Xi Yu, Zhenming Lao, Dandan Wang, and in Long. Sapsc: securiy archiecure of privae sorage cloud based on hdfs. In Advanced Informaion Neworking and Applicaions Workshops (WAINA), h Inernaional Conference on, pages IEEE, 212. [16] Safwan ahmud Khan and Kevin W Hamlen. Haman: Inra-cloud rus managemen for hadoop. In Cloud Compuing (CLOUD), 212 IEEE 5h Inernaional Conference on, pages IEEE, 212. [17] Rober Ricci, Eric Eide, and The CloudLab Team. Inroducing Cloud- Lab: Scienific infrasrucure for advancing cloud archiecures and applicaions. USENIX, 39(6), December 214.