Flogger: A File-centric Logger for Monitoring File Access and Transfers within Cloud Computing Environments

Transcription

1 11 Inernaional Join Conference of IEEE TrusCom-11/IEEE ICESS-11/FCST-11 Flogger: A File-cenric Logger for Monioring File Access and Transfers wihin Cloud Compuing Environmens Ryan K L Ko, Peer Jagadpramana, Bu Sung Lee Cloud and Securiy Lab HP Laboraories Singapore {ryan.ko peer.jagadpramana francis.lee}@hp.com Absrac Trus is one of he main obsacles o widespread Cloud adopion. In order o increase rus in Cloud compuing, we need o increase ransparency and accounabiliy of daa in he Cloud for boh enerprises and end-users. However, curren sysem ools are unable o log file accesses and ransfers effecively wihin a Cloud environmen. In his paper, we presen Flogger, a novel file-cenric logger suiable for boh privae and public Cloud environmens. Flogger records filecenric access and ransfer informaion from wihin he kernel spaces of boh virual machines (VMs) and physical machines (PMs) in he Cloud, hus giving full ransparency of he enire daa landscape in he Cloud. Wih Flogger, services can be buil above i o provide Cloud providers, end-users and regulaors wih he relevan provenance, e.g. a ool for an enduser o rack wheher his/ her file was ouched by an unauhorized user. We presen he iniial developmens of Flogger, and ineresing resuls from our experimens. We also presen compelling fuure work ha will shape he beginnings of a new logging paradigm: disribued VM/ PM file-cenric logging. Keywords- Cloud compuing; logging; audiabiliy; accounabiliy; rus in Cloud compuing; rused Cloud; Cloud compuing securiy; file-cenric logs; file-cenric logging mechanisms; deecive mechanisms. I. INTRODUCTION Trus is one of he main obsacles o widespread Cloud Compuing adopion. In order o increase rus in Cloud Compuing, here are boh prevenive and deecive measures [1]. While many Cloud Compuing service providers are focusing on prevenive measures (e.g. beer firewalls, sronger encrypion, ec), few are focusing on increasing he accounabiliy and ransparency of heir Clouds via deecive mechanisms (e.g. logging, repors for end-user self forensics) []. Wih Cloud compuing removing he need for end-users o own sysems, we also experience a change in mindse, from a focus on sysems securiy o a focus on daa securiy and proecion. There is a need o know he who, wha, where, when, how and why of daa movemens in he Cloud. This is made even more urgen wih he impending daa explosion [3], and he dawn of he so-called fourh paradigm [3, 4] described by he lae Microsof researcher Jim Gray. Wih he need for deecive measures and he change in focus o daa securiy and proecion, comes a demand for a robus securiy ools which will enable end-users, Cloud compuing service providers, adminisraors of Cloud services, and even regulaors o inspec, monior and analyze he rends of daa accesses and movemens wihin he largescale Cloud compuing environmen from a single poin of view. However, are curren deecive mechanisms ready for his change in paradigm? We begin by analyzing he curren sae of he ar: II. RELATED WORK A. User Space Cenralized File Sysem Call Monior In radiional one-sysem or local area nework (LAN) environmens, i is common o find user-space file monioring ools or exensions of file sysems (e.g. inoify [], swach [6], file aleraion moniors (FAM) [7]) o be widely used for monioring he single- or muliple-file aciviies wihin a single machine. Tools are also available for monioring packes in neworks (e.g. snor []). Wih large scales and heavy usage of virualizaion echnologies in Cloud compuing, such ools are insufficien o provide an over-arching view for monioring files across boh virual machines (VMs) and physical machines (PMs). Moreover, hese applicaions are usually housed wihin he user space, leaving hem vulnerable o user space aacks. B. File Inegriy Checkers as Inrusion Deecion File inegriy checkers such as TripWire inspec for changes o he files in he sysems by checking agains a baseline hash-key daabase which is regularly updaed wih he laes hash keys of he files wihin a sysem. Such an implemenaion is no scalable for he Cloud as here is a high volume of access, i.e. he need o regularly updae he key daabase is no feasible. Furhermore, hese ools do no provide a hisory of he file changes. Hence, while hey are able o idenify which files have changed, hey are unable o explain he hisory of wha acually happened o he files. Such limiaion is no desirable for forensics in he conex of he Cloud. C. Virual Environmen Moniors Wih he rise in adopion of virualizaion echnologies especially in privae Clouds, sofware such as he HyTrus Appliance [9] are saring o become more prominen. These ools enable adminisraors o regulae he access righs and o have an overview of he aciviies and consolidaion of common sysem logs for all virual machines. However, his visibiliy of he virual layer is sill no he full ransparency requesed by end-users [1] surveyed by he Fujisu Research Insiue, which saes ha % of hese users wan /11 $6. 11 IEEE DOI 1.119/TrusCom

2 o know exacly wha goes on in he physical servers hosing he gues machines. D. Cloud Sysems Healh and Performance Monioring When here is menion of monioring, here is a curren emphasis of monioring he server performance in Clouds. Such a focus on sysem monioring is no oally aligned o he acual needs of users. Despie having color schemes, visualizaions and aracive dashboards, ools such as VMWare vfabric Hyperic [11] and CloudKick [1] are sill unable o offer he crucial need of monioring daa movemens and ransfers in he Cloud. III. NEW BREED OF LOGGERS REQUIRED I is now eviden from observing he limiaions of he sae-of-he-ar ha we need he following necessary requiremens for effecive monioring of daa in he Cloud: Transcend VM/ PM - I mus be in kernel space, and mus be able o ranscend boh virual and physical spaces in he Cloud, providing full ransparency of all operaions in he Cloud. Provenance - I mus provide a full or a summarized/ concise provenance of daa life cycles and ransfers in he Cloud. This is also in andem wih he increase in he emphasis of daa governance [13] and accounabiliy [1]. Single Audiable View - I mus be able o provide a single consolidaed repor for inspecion. Efficien sorage - I mus be efficien in boh shor erm sorage and long erm archival. Analyics I mus provide audiing feaures o enable srong analyics and quick observaions of fooprins of file aciviies and ransfers. Wih he above lis in mind, we propose Flogger (shor for File-Cenric Logger), a novel file-cenric logger ha can be implemened in boh VM and PM kernels in a noninvasive manner wihin nodes in he Cloud. IV. FLOGGER - ARCHITECTURE AND DESIGN A. Flogger Addresses he Sysem Layer of he TrusCloud Framework Flogger addresses he needs of sysem layer wihin he TrusCloud Framework [1]. TrusCloud is a layered framework describing he differen layers of granulariy for Cloud accounabiliy. The Sysem Layer in he framework highlighed he imporance of monioring and audiing conainers of daa (e.g. files) wihin and ou of he Cloud. Wih he foundaional Sysem Layer, we can hen sudy movemen and changes of daa wihin and across files (Daa Layer), and also workflows and daa flows (Workflow Layer) hus giving full provenance of daa in he Cloud and in compliance o he Law/ Regulaion Layer and he Policies Layer. Furher descripions of issues relaed o hese layers of accounabiliy are described in [1]. B. Flogger Componens and Archiecure Figure 1 shows Floggers and heir accompanying componens, and demonsraes he underlying mechanisms capuring file acions and movemens from he underlying kernel space (depiced by he numeric sequence in Figure 1). A simple example of he resuling file-cenric log (in shor, flog ) capured by boh a VM and is hos PM is shown in Figure. 1) Componens The ypical implemenaion consiss of he following componens (See Figure 1): Flogger (Linux) A Linux Loadable Kernel Module (LKM) running on VM which inerceps file and nework operaions and wries he evens as VM flogs. Flogger (Windows) A Windows Device Driver running on PM which inerceps file operaions and wries he evens as PM flogs. Componens accompanying Flogger - File Sender Clien program running on VM which ransfers he VM log files from VM o PM via a direc communicaion channel. - File Sender daemon running on VM which regularly execues he File Sender Clien program. - File Sender Server program running on hos PMs which receives he VM log files sen by he File Sender Clien program. - Two Daabase Loader daemons running on PM. The firs one regularly loads he VM log files ino a remoe daabase server. The second one regularly loads he PM log files ino he same remoe daabase server. Wih hese componens, we can hen view and analyze he consolidaed VM and PM flogs using any daabase fronend ools or in spreadshee ools reading comma-separaed value (CSV)/ ab-separaed value (TSV) files. ) How Flogger Works Flogger capures file-cenric logs (a.k.a. flogs) via he following seps (wih reference o he labels in Figure 1): Sep 1: Linux Flogger/ Windows Flogger inercep every file access in he VMs. The Floggers capure he following informaion (Flog Subse A) (non-exhausive lis): VM Accessed file name and full pah e.g. /home/users/john/docs/sensiive. VM File access dae/ime VM IP address VM MAC address Machine ype i.e. VM or PM UID of file owner of he accessed file GID of file owner of he accessed file UID of process owner who accessed he file GID of process owner who accessed he file Acion done o accessed file e.g. Creae, Read, Wrie, Socke (Send Message), Socke (Receive Message), Delee I is imporan o noe ha he lis in Flog Subse A is no exhausive and more aribues are added o make he sysem more robus, e.g. more imesamps. 766

3 Figure 1. Archiecure and flow of ineracions and informaion passing beween Flogger componens Figure. Sample consolidaed file-cenric log (flog) exraced from querying he log sorage 767

4 No. (Included for his paper) filename full_pah ~ c/ c/ c/ c/ c/ c/ c/ ~ c/ c/ c/ c/ c/ u i d g i d Table 1: Exraced columns from flogs of Scenario 1 file_ user nam e pid p_uid alice 4436 alice 3 alice 4436 alice 3 alice 44 alice 3 alice 44 alice 3 alice 44 alice 3 alice 44 alice alice 44 alice alice 44 alice 3 alice 44 alice 3 alice 49 alice 3 alice 49 alice 3 alice bob proce ss_us ernam e vm_ip4 vm_ip6 vm_mac fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 fe c9fffec bc44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 :c:9:c :bc:44 vm_ine rface eh eh eh eh eh eh eh eh eh eh eh eh dae_ime :: :: :6: :7: :7: :7: :7: :7: :7: :: :: ::34+ imeva l_sec imeval_u sec vm_ip 4_raw acion Creae Read Read Wrie Read Rename (Old File) Rename (New File) Rename (New File) Read Read Read Read Sep 1 : Jus like VMs, PMs also have Floggers which inercep he PMs file sysem calls and hen sores hem in he Daa Sore. Sep : Afer he file life-cycle relaed informaion are capured, hey are sen o he hos PM. The VM Flogger direcly sends he capured informaion (Flog Subse A) o PM Receiver Daemon via a Communicaion Channel beween VM and PM. The Communicaion Channel is special mechanism available on ypical hypervisors which enable a serial cable-like communicaion beween VMs and PMs. I does no involve neworking ransfers. Hence, no VM Flogger ransfer Flogs o PM File Sender Servers via nework ransfers. This increases he securiy of he ransfer of Flogs. Sep 3: VM File Sender Daemon regularly execues he File Sender Clien which reads he File Access Deails (Flog Subse A) and sends hem o he PM via he Communicaion Channel beween VM and PM. Sep 4: PM File Sender Server receives he File Access Deails (Flog Subse A) from VM File Sender Clien via he Communicaion Channel beween VM and PM. Sep : PM Flogger generaes oher PM informaion (Flog Subse B), for example (bu no limied o): PM IP address PM MAC address Sep 6: The PM Flogger sends Subse B o PM File Sender Server. Subses A & B will give users a consolidaed se of informaion (i.e. Flog) which can pinpoin he VMs and PMs involved in each file s life cycle o enable full accounabiliy of disribued VM and PM archiecures, e.g. Cloud compuing. Sep 7: Wihin he PM Subne, he PM Daabase loader daemons wrie he join/ consolidaed informaion (boh Subse A & Subse B) o a Daa Sore e.g. daabase for fuure daa mining and reporing. Noe ha all he consolidaion of he Flogs across PMs ino he Daa Sore ake place only in he PM Subne. Users in he VM Subne should have no 76

5 awareness of hese behind-he-scenes seps. I is also noeworhy o know ha we have no decided on he exac shor, medium and long erm sorage of flogs, as his require anoher se of I/O experimens agains benchmarks and scale. V. RESULTS AND EXAMPLE SCENARIOS This paper repors our iniial experimens focusing on deploying Floggers o capure flogs across VMs and PMs for a Cloud, and also o demonsrae ha we are able o join he informaion for VMs and heir underlying hos PMs. This gives a comprehensive overview of he file-cenric accesses and ransfers wihin a ypical Cloud. Many oher research opics and quesions were raised and hey will be covered in Secion VI. A. Environmens Experimens Conduced In In order o prove he concep of Flogger, we have developed and run he implemenaion of Flogger on he following operaing sysems: Flogger (Linux) in he Linux Family o CenOS.3 o Fedora 1 o Ubunu 11.4 Flogger (Windows) in he Windows Family o Windows XP Professional SP3 o Windows Server R Flogs generaed were also pushed ino daabases via he DB loaders. Experimens were conduced agains he prominen open-source row-based relaional daabase PosgreSQL 9. and in preparaion for daa analyical needs over flogs, we also experimened wih he column-sore MoneDB. B. Use Case Scenarios To illusrae he Flogger in acion, we will explain wo example scenarios. I is imporan o noe he number of scenarios is no exhausive, and hey serve o enhance he appreciaion of he usage and poenial of Flogger. 1) Example Scenario 1: Recording and Deecion of Unauhorized User Accessing a File In his scenario, a ficiious user Alice creaes a sensiive documen () and modified he documen. Some ime laer, anoher user Bob reads he sensiive documen wihou Alice s permission. Table 1 shows a subse of he columns and resuls of flogs from a VM as a resul of enacing his scenario. The log rows number 1 o 11, excluding 6 o, depic Alice creaing and modifying he sensiive documen. The log rows number 6 o (he Rename operaions) depic he ex edior doing some behind-he-scene housekeeping operaions during a save operaion. Ineresingly, he log row number 1 depics Bob reading he sensiive documen wihou Alice s permission. Noe ha Bob s username is displayed in row 1 insead of Alice s username. ) Example Scenario : Capuring of File Transfers Across VMs in he Cloud In he nex scenario, we show Flogger capuring file ransfers wihin he Cloud. The firs VM running CenOS.3 sends a file (escopy.) via he Linux program scp (Secure Copy) o he second VM running Ubunu In Figures 3(a) o 3(d), he sender VM log rows number and 7 depic he nework operaions (Socke (Send Message)) when he firs VM is sending he file. (We have spli up he able ino pars a o d due o space reasons). (a) (b) (c) (d) Figure 3. Exrac from Scenario Sender Logs (a) (b) (c) (d) Figure 4. Exrac from Scenario Receiver Logs In Figures 4(a) o 4(d), he receiver VM log row number 14 depics one of he nework operaions (Socke (Receive Message)) when he second VM is receiving he file. Noe: mos of he receiver log rows have been hidden due o space consrain. Noe ha a he same ime, corresponding physical machine logs are also generaed in heir underlying PMs during he scp ransfer. Boh ses of VM and PM logs can hen be joined for furher analysis and forensics. 769

6 Figures and 6 below depic he Socke (Send Message) and Socke (Receive Message) respecively being capured in he Linux kernel message log. Figure. Scenario Sender Kernel Message Log File Figure 6. Scenario Receiver Kernel Message Log File C. Provenance from Logs From he wo scenarios, we can now visualize he daa provenance poenial informaion ha Floggers can provide for Cloud end-users, adminisraors and even regulaors. Virual machine file access and ransfers are logged wih heir corresponding file sysem calls in he physical hoss. Such correlaion gives a good ransparency of he locaion of files wihin a Cloud, and analyical ools can be buil over hese flogs o le people answer quesions such as Are my files really deleed in his Cloud? or Can I see who has accessed my sensiive file in his Cloud?. VI. CURRENT AND FUTURE WORK The developmen of Floggers and he successful consolidaion of simulaneously-generaed VM and PM filecenric logs addressed he need for higher Cloud accounabiliy and ransparency, bu also revealed limiaions and several compelling fuure research direcions: A. Inegriy and Securiy of he Logger and Logs A he momen, flogs are passed securely down he communicaion channels from he VMs o heir hos PMs. As such, here is no nework ransfer of flogs a he virual layer and he VM subne (see Figure 1). Flogs consolidaed a he PMs are sen o he daa sore wihin he PM subne. Securiy of he Floggers also depends on he inegriy of he machine kernels in he Cloud. However, he assumpion of he kernel inegriy is insufficien. Vulnerabiliies may exis when PMs are ransferring logs o he daabase sorage. Auhenicaion or simple clien puzzles-like proocols beween PMs and he sorage may be inroduced when flogs are ransferred. There is also a need for flogs o remain amper-proof and immuable. These requiremens are our curren op prioriies. B. Scale and Log Daa Size Explosion Compared o sysem-cenric logs (e.g. even logs, sysem logs, or user accoun aciviy logs), file-cenric logs (flogs) grow a a relaively higher rae. In one of our experimens, a file creaed in a word processing applicaion generaed up o approximaely 9, file aciviies wihin 3 minues even hough user-riggered aciviies (e.g. wrie) are kep o he minimum. I was laer revealed ha is auomaic backup feaures was enabled, causing i o be exremely chay. We are also aware ha he prospec of flogs ougrowing he size of he acual files o be racked is a realisic one. However, he concerns of he exponenial growh of logs may be miigaed by our curren aemps in exploring iered sorage and archival [1], de-duplicaion and summarizaion echniques. C. Rules for Applicaion Fooprins Capured in Flogs In our experimen, we also noe an ineresing observaion of recurring fooprins for differen ypes of sofware. This opens he possibiliy of creaing heurisics and rules for idenificaion of anomalies and aacks in he Cloud. D. Visualizaions Wih he large amoun of daa colleced, i is perhaps a good idea o formulae differen ypes of useful exploraory and presenaion visualizaions for he discovery and presenaion of noable rends and paerns in he flogs. Visualizaion needs for end-users, adminisraors and regulaors are differen. For example, Cloud service providers may only offer end-users knowledge abou he high-level geography wihou revealing specific daa ceners locaions. End-users can sill know if heir daa has violaed 77

7 cross-geography policies of daa ransfers. On he oher hand, regulaors may be graned special access accouns o visualize and audi he compliance of full daa flows wihin he Cloud. E. Linkage wih Governance, Regulaion and Compliance (GRC) needs Wih he daa accesses and ransfers logged by Flogger, auomaic audiing and high availabiliy of daa flow informaion are now realisic fuures in he Cloud. This is also inline wih he vision of he Workflow Layer in he TrusCloud framework[1]. VII. CONCLUDING REMARKS In his paper, we emphasized he imporance of a filecenric deecive measures for increasing rus in he Cloud. We also demonsraed he increase of ransparency and accounabiliy of he Cloud via he novel file-cenric logging mechanisms known as Floggers. Curren sysem logs only focuses on general sysem healh indicaors (e.g. upimes, processor usage, evens, ec). There is no focus on he life cycles of files sored in he file sysems across boh VM and PM. Our echnique has addressed he need for a file-cenric logging wihin neworks of PMs hosing muliple-folds of VMs. Moreover, curren sysem logs are sandalones kep wihin each VM or PM, and a bes, across muliple VMs or PMs, bu never consolidaed or managed across boh VM and PM simulaneously. There is a need for users o be aware of he exac VMs and he physical locaions of underlying PMs ha hey have sored daa in. Our echnique, Flogger, has addressed his by logging file life-cycle relaed evens on boh VMs and heir underlying hos PMs. Floggers can be applied ino boh privae and public Cloud compuing environmens. Because of he serviceoriened naure of Cloud services, Cloud users no longer need o own and mainain heir own PMs, bu raher, sore heir informaion in he Cloud, wihou he need o be concerned of he vendors server sysem healh indicaors. Our echnique will enable sysem adminisraors and endusers o audi file life cycles, access and ransfer hisories. File-cenric logs, or flogs, colleced by Floggers will also enable sysem adminisraors and end-users o idenify boh he virual and physical locaion of original and duplicae files o faciliae accounabiliy, IT forensics and racking of criminal aciviies wihin a Cloud provider s servers. The iniial experimens show a lo of promise. While here is much fuure work involved, we srongly feel ha his is he exciing beginning of he disribued VM/PM filecenric logging paradigm for Cloud compuing. Miranda Mowbray from he TrusCloud research projec [1] for heir valuable criique and feedback. REFERENCES [1] R.K.L. Ko, P. Jagadpramana, M. Mowbray, S. Pearson, M. Kirchberg, Q. Liang and B.S. Lee, TrusCloud - A Framework for Accounabiliy and Trus in Cloud Compuing, Proc. IEEE nd Cloud Forum for Praciioners (IEEE ICFP 11), IEEE Compuer Sociey, 11, pp. 1-. [] R.K.L. Ko, B.S. Lee and S. Pearson, Towards Achieving Accounabiliy, Audiabiliy and Trus in Cloud Compuing, Proc. Inernaional workshop on Cloud Compuing: Archiecure, Algorihms and Applicaions (CloudComp11), Springer, 11, pp. -1. [3] A.J.G. Hey, S. Tansley and K.M. Tolle, The fourh paradigm: daa-inensive scienific discovery, Microsof Research Redmond, WA, 9. [4] S. Sakr, A. Liu, D. Baisa and M. Alomari, A Survey of Large Scale Daa Managemen Approaches in Cloud Environmens, Communicaions Surveys & Tuorials, IEEE, no. 99, pp [] R. Love, Kernel Korner: Inro o inoify, Linux Journal, vol., no. 139,, pp.. [6] S.E. Hansen and E.T. Akins, Auomaed sysem monioring and noificaion wih swach, USENIX Associaion s Proceedings of he Sevenh Sysems Adminisraion (LISA VII) Conference, [7] Silicon Graphics Inernaional Corp, File Aleraion Monior (FAM) Overview, 9; hp://oss.sgi.com/projecs/fam/. [] M. Roesch, Snor-lighweigh inrusion deecion for neworks, Proc. 13h Large Insallaion Sysem Adminisraion Conference (LISA), 1999, pp [9] HyTrus, HyTrus Appliance, 1; hp:// [1] Fujisu Research Insiue, Personal daa in he cloud: A global survey of consumer aiudes, 1; hp:// [11] VMWare Hyperic, Performance Monioring for Cloud Services, 11; hp:// [1] CloudKick, CloudKick - Cloud Monioring and Managemen, 11; hps:// [13] Cloud Securiy Alliance, Securiy Guidance for Criical Areas of Focus in Cloud Compuing V.16, 9; hps://cloudsecuriyalliance.org/csaguide.pdf. ACKNOWLEDGMENTS We would like o hank our colleagues Markus Kirchberg, Teck Hooi Lim, Alan Tan, Chun Hui Suen, Ahmed Aneeh, Ahmed Rifau Rasheed, Siani Pearson, and 771