WIXLIB

TABLE I.S URVEY OF ACCEPTABLE U SE P OLICIESProhibited activityillegal activities (generically)sending unsolicited mass e-maildistributing malware of any kinddistributing harmful contentdistributing virusesunauthorised access to other systemsfake mail headersintentional interference with a systemactivities harmful to the CSP’s operationsfake IP addresses in network headersscanning for vulnerabilities of a systemIRC servers, anonymisation, streaming, download and P2P services, linking to thesecontent that compromises national securityreceive unsolicited XXXXXimpliedXXXXXXXXXXXXXXXimpliedXXXXXXXXA. PortscanningE. Forged HeadersIn a portscan, messages are sent to ports on remote hoststo check whether they are open. While this is not an attackin itself, it is often a precursor to one as it can be used tocheck for vulnerable network services which can subsequentlybe attacked. An attacker may either scan many ports on aspecific remote host or a specific port on many remote hosts.Techniques for detecting inbound portscans on the networklevel exist (among others [22], [23]) and should be adaptablefor detection of outbound scans in a cloud environment.Incorrect sender information in the header of networkmessages (e. g. a wrong sender IP address in an IP packet oran incorrent sender address in an e-mail) may pose a problemfor the receiver and/or the ‘sender’ of the messages. On theone hand, fake information makes it harder for the victim ofan attack to identify the attacker and block the attack – if theattacker constantly changes the ‘sender’ information, it cannotbe used to formulate a rule for blocking attack traffic. Onthe other hand, forged sender information can be used foramplification attacks, in which the attacker sets the senderinformation to resemble those of the victim. The attackerthen sends requests to a server, which will send the responsemessages (which will typically be larger than the request)to the victim, who did not request them. DNS servers areparticularly popular as amplifiers, as small DNS requests maysometimes generate very large response messages, especiallyif DNSSEC is being used [26].B. Distribution of MalwareCloud resources can be used to distribute malware. Thismay take place in different forms, one of them being throughplacing it on websites hosted within a cloud. Malware couldalso be spread by sending it attached to e-mail messages,typically of the spam variety (see Sect. III-D) or by exploitingvulnerabilities on network hosts in order to directly install themalware on the victim machine (see Sect. III-F).F. Exploiting Security VulnerabilitiesC. (Distributed) Denial of ServiceA denial of service (DoS) attack has the goal of compromising the availability of a network service. This is typicallyachieved by overloading the victim machine by means ofsending a large number of requests. If multiple machines areinvolved in sending the requests, the attack is classified as adistributed denial of service (DDoS) attack. DoS attacks arevisible at the network level and could be detected by sensorsat the boundary of user VLANs (see Sect. IV). Numerousapproaches for detecting inbound DoS attacks exist already[24] and should be adaptable to outbound detection.D. Sending Unsolicited E-MailCloud infrastructures can easily be used to send a largenumber of unsolicited e-mail messages (i. e. spam). This mayor may not include forged sender information. Techniques fordetecting spam messages exist (e. g. [25]), but are typicallydeployed at the mail server used for either sending or receivingthe messages. For our scenario, these would have to be adaptedto either monitor messages at the network level or to monitorthe mail server software deployed by a customer from outsidethe VM.Cloud environments can also be used to exploit securityvulnerabilities on other network hosts. If the pattern of activityfor exploiting a vulnerability is known, it should not only bepossible to detect inbound, but also outbound attacks.G. BotnetsBotnets consist of a large number of compromised hostswhich can be commanded by the botnet ‘owner’ to launchattacks against other network hosts [27]. The compromisedhosts are referred to as ‘bots’ and are typically controlled bya command and control server, as described by Strayer et al.[27], although a peer-to-peer structure is also possible [28].Both bots as well as command and control servers could be runwithin cloud environments. A survey of some existing botnetdetection techniques has been composed by Feily et al. [29].While botnets are not specifically listed in the surveyedacceptable use policies, they are still something that providersshould aim to protect themselves against as they are typicallybeing used for conducting (in the case of bots) or supporting(in the case of command and control servers) other types ofabuse.

1) Command and Control Servers: Command and controlservers are used to control a botnet. They take commands fromthe botnet ‘owner’ and communicate these to the individualbots, which will then execute the commands. If any information is requested from the bots, it will be collected by thecommand and control server, where they can be collected bythe botnet ‘owner’. A command and control server of the Zeusbotnet has been found to be operating within Amazon’s EC2in 2009 [2].2) Bots: VM instances may also be used as bots. This mayeither be due to a benevolent customer’s VM getting infectedwith malware, but also due to a malevolent user deliberatelyinstalling the bot software.The bot software itself may be detectable by looking at theinner workings of the VM: it will be present in memory andon the virtual hard drive and may also be present in the OS’sprocess list (although many bots try to disguise themselves bymanipulating the OS process information). A bot may also bedetected by detecting its symptoms: it will communicate witha command and control server and may be used to launchattacks (such as DoS or spamming as described above).IV.D ETECTING A BUSE IN AN I AA S E NVIRONMENTIn the previous section, we have shown which types ofactivity would be considered abuse in an IaaS environment.We will now review existing security techniques in order toevaluate the potential of their application for cloud computingabuse detection. The treatment will specifically highlight opportunities and limitations in order to identify gaps in research.Classical intrusion detection systems cannot be directlyemployed for the detection of abuse in cloud environments.On the one hand, these systems are typically geared towardsdetecting intrusions, i. e. attacks originating from outside themonitored network targeting machines within it. Furthermore,detection software running on the monitored host itself (i. e.within virtual machines) cannot be relied upon in this scenario,as users could easily tamper with or disable it due to havingfull control of the VM. Its behaviour will thus have to bemonitored from the outside.The possible placement of different IDS sensor types forabuse detection in an IaaS infrastructure with isolated virtualnetworks for each user is illustrated in Figure 2.One way this can be achieved is by monitoring networktraffic originating from VMs using a network-based IDS, suchas Snort [30]. Although these are mostly used to detect intrusions into a network or system, they can also be used to detectattacks launched from within the network, provided suitablesignatures (in case of signature-based systems) or training data(in case of anomaly-based systems) are available to the system.This is referred to as ‘outbound intrusion detection’ [31] or‘extrusion detection’ [25].If user networks are not isolated from each other, networkbased IDS would have to be placed either with each individualVM (1b) or at the border of the provider’s network to theInternet (1c). While the IDS would be simpler to deploy inthe latter case, it would be unable to detect attacks originatingfrom a VM within the cloud environment targeting anotherVM within it.Internet(1c)(1a)(1b)VMVMVM(user 1) (user 1) (user 2)(2)(3)VMIVMIVMIVMIVMIVMVM(user 1) (user 3)VMIVMIVirtual MachineMonitor (VMM)Virtual MachineMonitor (VMM)Virtual MachineMonitor (VMM)HardwareHardwareHardwarePhysical machine 1Fig. 2.VMVM(user 2) (user 3)Physical machine 2Physical machine 3Placement of sensorsIn an environment where each user has a virtual network(VLAN) to himself which is isolated from other customers’networks (as recommended by Hao et al. [32] and Chowdhuryet al. [33]), the IDS could instead be placed at the border ofeach individual user’s virtual network with the public part ofthe network (1a). While the placements described above (1b,1c) would also be possible, (1a) provides the best compromisebetween visibility of malicious traffic and ease of deployment.Compared with deploying an IDS with each individual VM,it would not be possible to detect attacks a customer’s VMlaunches on another VM on that customer’s virtual network,but responsibility for preventing this can easily be left to thecustomer as no third parties are affected by such attacks.While network-based IDS are relatively simple to deploy,they can only examine the network traffic – which might notalways be clearly classifiable as legitimate use or abuse, e. g.due to encryption. Host-based IDS on the other hand cannotbe deployed within a VM as a malicious user could easilydisable or modify these. The technique of ‘virtual machine introspection’ (VMI), as presented by Garfinkel and Rosenblum[34], allows to monitor the inside of a VM without a user beingable to interfere (2). A VMI-based IDS can directly inspect themachine state and could be used to detect malicious softwarerunning on the host. This could include malware used to hijacka VM as well as attack tools willingly executed by a malicioususer. It is important to note that no assumptions must be maderegarding the semantics or trustworthiness of the VM whenusing VMI on customer VMs [35]: Users will be in full controlof the virtual machine and can manipulate any of the softwarerunning within. This applies even to users using VM imagessupplied by the provider.As a consequence, VMI techniques are challenging to usein situations where the user is not cooperating with the operatorof the VMI system: They require knowledge about the memorystructures used by the operating system running within theVM. While there are relatively few Windows kernel versionsbeing used, there is a huge number of different Linux kernels

(which will potentially use different memory structures) dueto frequent updates and the possibility of users compilingcustom kernels. Existing VMI software, such as LibVMI [36],typically requires the Linux kernel’s System.map file, whichcontains the kernel symbol table and enables the VMI softwareto find system information in memory. However, a providercannot assume a malevolent user to provide the correct versionof this file. While there are memory analysis techniqueswhich enable memory analysis without prior knowledge of thelocation of data structures in memory, these are relatively slow[37] and would make real-time monitoring infeasible. The lackof satisfactory solutions means that this is a fruitful area offuture research.2) Filtering of Network Traffic: Another technical measureto prevent abuse would be a firewall. This could block networktransmissions according to its rule-set. Unlike an intrusionprevention system, it will not take into account any information provided by IDS sensors when deciding which networktransmissions are to be blocked. One example of malicioustraffic that could easily be filtered is traffic with fake headerinformation (see Sect. III-E). A cloud service provider caneasily prevent its customers from sending IP packets containingfake sender IP addresses by filtering network packages if theirsender address does not match the customer’s network, asdescribed in RFC 2827 [38]. Similar filtering could be set upfor other protocols.Another source of data, which could be used for intrusiondetection, is information available from the virtual machinemonitor (3). One example of data provided by the VMM is thecreation and destruction time of a VM, as used for intrusiondetection by Doelitzscher et al. [10].3) Logging: Alternative to an outright prevention of abuse,the system could also trigger an extensive logging procedure toallow later forensic investigations of the suspicious activities.While this would allow abuse to take place at first, it at leastmakes legal prosecution possible at a later stage. This couldalso help providers in case they were held legally responsiblefor abuse conducted by their customers.Some of the presented techniques may also be of use fordetecting abuse of machines in large networks of companiesor universities. Especially if the use of personal devices ispermitted, there will be a large heterogeneity of devices, withthe organisation having no control over both soft- and hardwareof these devices. This limits outbound intrusion detection toanalysing the network traffic. On devices actually controlled bythe organisation, traditional host-based sensors may be used ifthe user’s rights are sufficiently restricted to prevent tamperingwith the sensor.V.P REVENTION OF A BUSE IN AN I AA S E NVIRONMENTIn addition to the detection techniques as outlined in theprevious section, research should also encompass preventionof abuse. It is currently unclear how an abuse preventionsystem could be constructed and how effective it would be inpreventing abuse in cloud computing. Both technical as wellas non-technical measures may play a role in preventing abuse.A. Technical Measures1) Intrusion Prevention Systems (IPS): Intrusion prevention systems (IPS) exist as an extension of intrusion detectionsystems. Similar to IDS, existing implementations cannot bedirectly employed for preventing abuse in cloud computing.Thus, an ‘abuse prevention system’ is needed as a new classof prevention system. Similar to IPS, it would be desirable forthis system to automatically take corrective action on detectionof abusive activity by the abuse detection system. Possiblereactions might be to shut down the system or restrict itsnetwork connection.False positive reports by the abuse detection system relatingto perfectly legitimate events are a challenge for automaticprevention. If a VM is shut down or taken off the networkfollowing a false positive, customers would very likely bedissatisfied and might decide to move their business to acompetitor. Additionally, the provider might be in breach of aservice level agreement and incur financial penalties. Allowingan abuse prevention system to take automatic action is thusfeasible only if an IDS report can almost certainly be attributedto abuse.Compared to constant comprehensive logging of all activity within the cloud, this approach would reduce storagerequirements considerably. Also, user privacy (cf. Sect. VII)is improved, as detailed activity logs will only be created forcustomers suspected of conducting abuse.B. Non-technical Measures1) Acceptable Use Policies: Acceptable use policies formpart of the contract between customer and provider and canhelp to deter abuse. Especially if certain behaviour is notillegal, but the provider still does not want it to be conductedwithin its environment, it is necessary to formalise this behaviour as disallowed. A policy cannot outright prevent anyabuse from happening, but it makes clear to users that a certaintype of use will not be tolerated and allows a provider to takenecessary steps for stopping such use, i. e. by terminating theuser’s services. An acceptable use policy can also make iteasier to implement technical prevention measures, as userswho subsequently complain about the blocked type of use notworking can be referred to the policy which they have acceptedas part of their contract. For a survey of the typical contentsof acceptable use policies see Sect. III.2) Account Verification: In the past, many – especiallysmaller – cloud service providers offered trial accounts anddid not require any verification apart from an e-mail address.As e-mail addresses are very easy to obtain, it was possibleto automatically create a large number of accounts with suchproviders. These accounts could then be used for maliciouspurposes. Such an attack was demonstrated by Salazar andRagan at the 2014 RSA Conference USA [39]. This type ofattack can easily be prevented by requiring a higher level ofauthentication for new accounts, e. g. by asking for a phonenumber and authenticating it by means of sending a textmessage containing a verification code. A study by Thomaset al. [40] has shown that phone verification significantlyincreases the price of an account on the black market, leadingto the conclusion that it is indeed harder to create suchaccounts.

We surveyed the same providers as in Section III andfound that for these large providers, verification measuresbeyond a simple e-mail confirmation are in place. Signing upfor an account with Amazon, Microsoft Azure, ProfitBricks,Rackspace and Softlayer requires providing a phone number,which can be used for phone verification. Amazon, Microsoftand Google additionally require new customers to provide theirbilling information even if they do not currently intend to useany billed services. HP occasionally asks users to send copiesof their utility bills as proof of address.3) Financial Incentivisation: Another measure to deterabuse would be to implement an incentive system. This couldbe implemented in form of a deposit made by a customerbefore starting to use the services. If users are subsequentlyfound to be abusing the services, the service is terminated andthe provider gets to keep the deposit. Szefer and Lee proposesuch a system using Bitcoin to make the deposit, which theycall ‘BitDeposit’ [41].VI.R EPORTINGAs not all abusive activity can be prevented by the techniques mentioned in Section V, reports by the abuse detectionsystem may have to be manually examined by a cloud serviceprovider’s staff. Manual examination of each individual eventwould be too costly, as there will potentially be a largenumber of events reported by the IDS – especially in largecloud environments. Security metrics will have to be devised,aggregating events to allow easier identification of malicioususers or abused VMs.A possible way of doing this would be to assign a reputation to each individual VM based on events reported bythe IDS. An event which can almost certainly be attributedto abuse should have a higher impact on the

possibilities of virtual machines in IaaS clouds are comparable with those of physical machines. Detecting and preventing abuse in IaaS is therefore considerably harder than in SaaS and PaaS environments. Abuse of services is not limited to cloud computing. It is also an issue for providers of dedicated root servers, a