Honeypot for Infrastructure as a Service Security

Abstract

To provide a method, a storage medium, and a computing system for collecting data about an attack pattern against an Infrastructure-as-a-Service (IaaS) instance by using a honey pot to lure an attacker.SOLUTION: In a computing system, a honeypot server receives a request from an attacker for an Infrastructure-as-a-Service (IaaS) instance, generates a response to the request, communicates this response to the attacker upon request, and records data about the attacker and data about one or more interactions by the attacker with the honeypot server.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority under 35 U.S.C. §119(e) to U.S. Application No. 62 / 895,847, filed September 4, 2019, and entitled "HONEYPOTS FOR INFRASTRUCTURE-AS-A-SERVICE SECURITY," and U.S. Application No. 17 / 009,634, filed September 1, 2020, and entitled "HONEYPOTS FOR INFRASTRUCTURE-AS-A-SERVICE SECURITY," the entire contents of which are incorporated herein by reference for all purposes.

[0002] Technical Field The present disclosure relates to computer security, and more particularly to techniques for using honeypots to lure attackers to collect data about attack patterns against Infrastructure-as-a-Service (IaaS) instances, which can then be analyzed and used to prevent such attacks. [Background technology]

[0003] background With the rapid growth and adoption of cloud-based services (e.g., Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS)), an increasing number of organizations (e.g., companies, enterprises, government agencies, and educational institutions) are subscribing to cloud services offered by cloud service providers to perform critical business operations. As these cloud offerings proliferate, cloud service providers face increasing security threats from attacks by malicious users against the infrastructure that provides the cloud services. Cloud service subscribers (e.g., organizations) are also adversely affected by these attacks. The ability to identify and prevent such attacks is in the best interests of both subscribers and cloud service providers.

[0004] However, with cloud products, it's often unclear how attacks occur and / or how to prevent them. The reason for this is that cloud security is relatively new - a new type of security as opposed to traditional network and / or device-level security. Existing cloud security solutions are very low-level and reactive in nature - they wait until an attack has occurred before they can respond.

[0005] Early cloud attacks targeted instances that provided SaaS and PaaS services, but recently, as more computing networks, storage networks, and virtual networks are abstracted into the cloud and exposed through various IaaS instances, attacks against IaaS instances have increased. For example, with the popularity of cryptocurrencies such as Bitcoin, computing resources are increasingly being used to mine cryptocurrencies (e.g., Bitcoin mining), which requires large amounts of computing, storage, and network resources. IaaS instances are increasingly being attacked to "steal" grid, memory, and network resources. Compared to SaaS and PaaS attacks, IaaS attacks are still less understood. Summary of the Invention [Means for solving the problem]

[0006] overview The present disclosure relates to computer security, and more particularly to techniques for utilizing honeypots to lure attackers and collect data about attack patterns against Infrastructure-as-a-Service (IaaS) instances. The collected data can then be analyzed and used to prevent such attacks. Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media that store programs, code, or instructions executable by one or more processors, and the like.

[0007] Certain embodiments provide techniques for luring an attacker into establishing a session with a honeypot server. The honeypot server receives a request from the attacker for an Infrastructure-as-a-Service (IaaS) instance. The honeypot server generates a response to the request and causes the response to be communicated to the attacker upon request. The honeypot server also records data regarding the attacker and one or more interactions by the attacker with the honeypot server. In some embodiments, a network (also referred to as a honeynet) of honeypot servers may be provided.

[0008] As part of processing the request received from the attacker, the honeypot server determines an action corresponding to the request. This action may be, for example, an action to request instantiation of an IaaS instance. The honeypot server then instantiates the requested IaaS instance using at least one of computing resources, storage resources, or network resources. The honeypot server then returns a response to the attacker indicating that the IaaS instance was successfully instantiated.

[0009] In certain cases, a request received from an attacker may request an action to be performed using a pre-instantiated IaaS instance, and the honeypot server may generate a response to the request by applying the action to the pre-instantiated IaaS instance.

[0010] In certain embodiments, the honeypot server may determine that the request requests that an action be performed to instantiate an IaaS instance. The honeypot server may then generate a response to the request indicating that the requested IaaS instance was successfully instantiated without actually instantiating the IaaS instance. In some cases, a request from an attacker may request that an action be performed using an IaaS instance. The honeypot server may be configured to generate an appropriate response for the requested action without actually performing the action and without the IaaS instance being instantiated. In such a scenario, the honeypot server may use rule information to generate an appropriate response. For example, the rule information may include information identifying multiple actions and, for each action, at least one response corresponding to the action. The honeypot server may then use the rule information to find an appropriate response for the action requested by the attacker. In one embodiment, the honeypot server searches the rule information to find a corresponding response. The honeypot server may find an entry from the rule information whose action matches the action requested by the attacker, and may use the entry to determine a response to send to the attacker to make the attacker believe that the requested action was successfully performed.

[0011] Attackers can be lured to a honeypot server using a variety of techniques. For example, a set of one or more credentials can be deliberately made visible on one or more ports that attackers commonly search to conduct attacks, such as SSH (shell) port 22 or FTP (file transfer protocol) port 21. The credentials can include username and password pairs, certificates, keys, identifiers (e.g., tenant identifiers), etc.

[0012] There are different types of attackers. For example, an attacker can be an automated bot. In some cases, an attacker can be a user directing an attack using an application such as a browser, a GUI-based application, etc.

[0013] The above features and embodiments, as well as other features and embodiments, will become more apparent with reference to the following specification, claims, and accompanying drawings. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 2 illustrates an implementation of a honeynet with honeypots, according to certain embodiments. [Figure 2] FIG. 2 illustrates another implementation of a honeynet with honeypots, in accordance with certain embodiments. [Figure 3] 1 is a simplified block diagram of a distributed environment incorporating a honeynet comprising one or more honeypots, according to certain embodiments. [Figure 4] 2 is a simplified block diagram of a honeypot server according to certain embodiments; [Figure 5] 2 is a simplified block diagram of a honeypot server according to certain embodiments; [Figure 6] 2 is a simplified block diagram of a honeypot server according to certain embodiments; [Figure 7] FIG. 2 is a flow diagram of an example honeypot implementation, according to certain embodiments. [Figure 8] FIG. 1 is a simplified block diagram illustrating a pattern for implementing a cloud infrastructure as a service system, according to certain embodiments. [Figure 9] FIG. 1 is a simplified block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 10] FIG. 2 is a simplified block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to certain embodiments. [Figure 11] FIG. 2 is a simplified block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to certain embodiments. [Figure 12] FIG. 1 is a simplified block diagram illustrating an example of a computer system in accordance with certain embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. However, it will be apparent that various embodiments can be practiced without these specific details. The drawings and description are not limiting. As used herein, the word "exemplary" means "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0016] As more business operations are abstracted into the cloud, a given organization is simultaneously Your internal threat intelligence feeds should give you a good understanding of how your cloud environment can be attacked if you do nothing.

[0017] The present disclosure relates to computer security, and more particularly to techniques for using honeypots to lure attackers to collect data about attack patterns against Infrastructure-as-a-Service (IaaS) instances, which can then be used to prevent such attacks.

[0018] In certain embodiments, one or more honeypot servers (honeypots) are deployed, where each honeypot server (honeypot) is an endpoint node purposely deployed by an attacker to perform highly malicious activities, such as fake banking applications, applications related to critical infrastructure (e.g., payment processing, oil rig temperatures), etc. Such honeypots are used to collect data about the attacker.

[0019] In certain embodiments, honeypots may be deployed to trick malicious users (also referred to herein as attackers) into thinking they have compromised a real instance, such as a real Infrastructure-as-a-Service (IaaS) instance. In reality, the attacker is operating on isolated dummy or virtualized resources provided by the honeypot server, without actually affecting the protected resources. A honeynet, or a network of such honeypots, may be deployed to emulate an IaaS service or service offering offered by a cloud service provider. For example, a honeynet (or multiple honeynets) may be provided to emulate the Oracle Cloud Infrastructure (OCI) IaaS service offered by Oracle Corporation®. As another example, a set of servers may be set up as a honeynet with a regulated set of computing resources for mining Bitcoin.

[0020] A honeypot server may be set up using protocols such as SSH (Secure Shell) or FTP (File Transfer Protocol). The honeypot may be set up with some credentials (e.g., username / password pairs, keys, etc.) that an attacker can access and log in to. By gaining access to a real IaaS instance, the attacker thinks he has "hit the jackpot."

[0021] When an attacker interacts with the dummy IaaS instance, the honeynet infrastructure is configured to provide the attacker with appropriate responses to fool the attacker into believing that they are interacting with a real IaaS instance rather than a dummy instance. In certain embodiments, a fictitious attacker may be used to set up a canned / prefabricated sequence of interactions.

[0022] Attacker interactions with honeypots (and honeynets) are recorded or logged. The recorded attacker data may include attacker actions (e.g., threat actor user behavior patterns, other attributes unique to the user), unique attributes about the attacker, such as connection attributes and device-level attributes of the specific attacker (e.g., connection information, IP addresses of devices utilized by the attacker to originate attack calls and requests, ASN (Autonomous System Number) traceroute information, domain names, etc.), and other data related to the attack. The recorded data may include: , which may include data about the attacker's sequence of actions, the objects the attacker accessed, the API calls made by the attacker (e.g., REST API calls made by the attacker), and so on.

[0023] The logged data can then be analyzed to identify information and analytics about attack patterns. For example, the logged data may be used to answer questions such as how the attacker orchestrated the attack, what the attacker was attacking, what the purpose or intent behind the attack was, and how frequent the attacks were.

[0024] Honeynets, as described herein, provide an additional,necessary protection mechanism for cloud security when threat vectors are,often not binary vectors, but rather consist of several,sequences of actions or unique attributes.,When incorporated into a data lake and its extraction, loading, and,transformation mechanisms, unsupervised machine learning techniques,can be utilized to identify new zero-day threats (e.g.,,threats never seen before).

[0025] The data captured or recorded by a honeynet can then be used to uniquely identify specific attackers and classes of attackers and to find patterns in attacks. Data collected using a honeynet is important for understanding attack mechanisms and for preventing ongoing attacks, including zero-day vulnerabilities that an organization may not be aware of. Honeynet services can be offered as a security service so that when a specific IP address is identified as malicious, it is flagged and appropriate action can be taken.

[0026] The data recorded or logged by the honeynet can be sent to an analytics platform for analysis. For example, the recorded data can be sent to an AI (artificial intelligence)-based ML (machine learning) platform to build one or more models to identify such attacks. The data ingested by the honeynet system provides useful and relevant training data that can be used to further improve the machine learning techniques used to identify security threats. The data logged by the honeynet can be used to build new and improved security models.

[0027] Data recorded by a honeynet about one or more attackers may be used for various purposes. In certain embodiments, data collected by one or more honeynets may be forwarded from these honeynets to a centralized log server. The log server may then forward or provide access to the collected data for analysis. For example, the collected data may be forwarded for analysis and utilized by a threat intelligence tool configured to identify attackers and similar threats. For example, the threat intelligence tool may use the collected IP network information and its association with threat actors to identify similar attacks. The collected data (e.g., key pair values, event information, object information, etc.) may be fed into a machine learning pipeline to learn information about the characteristics of threat attacks. This data may be used to understand the sequence of events for current users, and whether these users pose a threat may be derived from their cloud activity profiles.

[0028] In certain embodiments, the machine learning pipeline used to analyze data recorded by one or more honeynets may be implemented using a distributed streaming platform, such as an Apache Kafka-based pipeline. Events and audit logs collected by the honeynets are provided to the Kafka-based pipeline. Kafka The pipeline stores the data in a data lake, which may then be subjected to clustering algorithms, such as K-means or K-means++ algorithms, to identify threat profiles and threats.

[0029] Proactive action can then be initiated against identified threats. In some cases, it may be possible to identify such threats and take preventative action even before malicious acts are performed. For example, an alert may be generated if information contained in a user's activity profile matches information or a profile generated based on data collected by the honeynet about an attacker. In some other cases, threats may be identified and preventative action taken in a rapid timeframe so that an attacker has less time to perform malicious acts. For example, a threat may be identified as soon as one or two actions matching an attack profile are identified.

[0030] In certain embodiments, the security functionality provided by a honeynet may itself be offered as a cloud service that may be configured to identify access to resources for subscribing tenants, flag inappropriate access, and take appropriate remedial action (e.g., if a particular IP address is identified as a bad address, it may be flagged and appropriate action taken).

[0031] A honeynet, or network of honeypots, is used in this way to capture and collect data about attackers, to put yourself in their shoes and understand how and where such attacks originate and are carried out, the resources being attacked, the patterns of behavior during such unauthorized access, affiliation, and motives, and to obtain contextual information about the attackers (e.g., where they come from, what type of operating system they use, what time they attack, and other attributes related to the attack). Honeynets can be used to find out more data about such attacks without endangering actual, useful resources. A cloud service provider may have one or more honeynets, each consisting of one or more honeypots, set up in one or more of the provider's data centers. Honeynets enable proactive identification of new types of threats, allowing cloud security software and personnel to stay one step ahead of attackers by obtaining more desirable data in an autonomous manner.

[0032] Illustrative Embodiment #1 The following describes an example workflow according to a specific embodiment. The workflow described below includes multiple steps. These steps and their order are not limiting.

[0033] Step 1: Make your honeynet accessible to attackers (e.g., dark web users) The first step involves setting up a honeynet that is attractive to attackers. In particular embodiments, a series of servers may be set up to intercept requests from the attacker over protocols such as HTTP or FTP. Credentials may conveniently be stored in a CSV or database file in a directory structure for the attacker to find. Once the attacker finds dummy credentials for an instance of a service (e.g., an IaaS instance), they may use the dummy credentials to access the service instance and attempt to use resources available through the service instance.

[0034] For example, as shown in Figures 1 and 2, an attacker can listen on a decoy node via FTP listening mode on port 22 or port 21 (used for secure login, FTP, port forwarding, etc.). Credentials can be set to a common naming convention (i.e., root / password). An attacker will look through historical directory listings and find a .csv / .db file prefixed with the text (superuser). Dark web users will find randomly generated credentials placed at the top of this file that specify the superuser. The credentials can be in the form of superuser name / password. These credentials are intended to give the attacker access to dummy IaaS instances provided by the IaaS honeynet set up to "take the attack."

[0035] Various techniques may be used by a honeynet to identify attackers. Generally, a normal user would not seek out decoy nodes on the Internet. For example, if a decoy node were running on port 22 for SSH, the average user (e.g., a legitimate client or tenant of a cloud service provider) would not seek out the decoy node and therefore would not scan the decoy node for credentials. The decoy node itself may be used as a mechanism for distributing dummy credentials. Attackers are attracted to the dummy credentials and can access and use these credentials to perform malicious acts. The attacker is led to believe that credentials have been inadvertently left on the decoy node, which is open on a port.

[0036] There are several ways that attacks can occur, but the following two are the most common: (1) Use automated bots: Bots can be configured to learn as many credentials as possible and then use scripts to exploit those credentials to do bad things. (2) The attacker is interested in interacting with the service themselves, for example, using a browser or other GUI application. An attacker may interact with a cloud service (e.g., Oracle's OCI service) using a GUI. This may be done through CLI (command line interface) (e.g., REST API-based requests) requests directed to an API endpoint that has the ability to perform actions according to the attacker's requests. The GUI is essentially a wrapper around the CLI requests. CLI requests may be generated using a command line mode or using a GUI interface.

[0037] In certain embodiments, the honeynets described herein are capable of resisting both bot-based and GUI-based attacks.

[0038] Step 2A: The attacker is an automated bot (CLI mode) For the purposes of step 2A, it is assumed that the attack is carried out using an automated bot in CLI (Command Line Interface) mode. Figure 1 illustrates a honeynet system 100 for handling requests received from automated bots, according to a particular embodiment. The honeynet 100 may be composed of one or more honeypots. In Figure 1, an IaaS instance 102 provided by the honeynet is shown within a dotted line.

[0039] As shown in Figure 1, a decoy node 104 allows an attacker to access a REST API node 106. The REST API node 106 may be a gateway to an instance 102 of an IaaS service. In Figure 1 (and Figure 2), the IaaS instance 102 (instance 202 in Figure 2) is shown with a dotted line and is a These include network resources, storage resources, and network resources. A decoy node 104 may provide an attacker with access to credentials to access a honeynet consisting of one or more honeypots, which in turn provide one or more "dummy" IaaS instances 102. The provided credentials allow the attacker to connect to one of the dummy IaaS instances provided by the IaaS honeynet.

[0040] The REST API (Command and Control) node 106 (206 in FIG. 2) acts as an intermediary between the attacker and the resources or objects on which the attacker wishes to perform nefarious acts. For example, the REST API endpoint 106 (206 in FIG. 2) acts as an intermediary for all resources / actions created from CLI GET requests being generated by a bot / attacker. In certain embodiments, the REST API node 106 receives the CLI requests from the attacker, parses the CLI requests to understand the action the attacker requested, and provides the attacker with the output or response the attacker expected for the request.

[0041] The REST API node 106 also has the ability to trick an attacker into believing that it has accessed a resource or performed some action that is not a real dummy. This is done by providing correct dummy responses to requests (e.g., GET requests, POST requests) received from the attacker, fooling the attacker into believing that the attack was actually successful (i.e., the action the attacker requested to be performed was successfully performed). For example, the responses could trick the attacker into believing that it was able to set up an IaaS instance and perform various operations using that instance. The REST API node 106 provides false or dummy information to the attacker to fool them into believing that the malicious activity was successful; that is, it fools the attacker into believing that what the attacker is requesting is actually occurring. This node is used as a tool to perpetuate the deception.

[0042] REST API node 106 has the functionality to process requests received from an attacker and provide the attacker with information the attacker expects to receive, thereby tricking the attacker into continuing the attack. In a particular embodiment, REST API node 106 is configured as follows:

[0043] (1) Receive and interpret requests from an attacker, and perform or pretend to perform the requested actions. These actions may include setting up the correct resources (e.g., spinning up databases, computers, containers, etc.) as requested by the attacker.

[0044] (2) Providing a response to the attacker, including performing error handling, to trick the attacker into believing that they have accessed a real, non-dummy instance.

[0045] With regard to interpreting the request and creating resources, the instance may be created using techniques for provisioning resources in response to subscription requests. In certain embodiments, the REST API node 106 determines which resources the attacker is requesting based on the provisioning techniques used by the service provider. In some other embodiments, techniques such as RegEx (regular expression) scripts and / or NLP (natural language processing) cached dictionaries (e.g., using appropriate webhooks) may be used to respond to CLI GET requests from an attacker.

[0046] Various techniques may be used by the honeynet to provide appropriate responses that will lead the attacker to believe that they have accessed a genuine IaaS instance. In some cases, an appropriate response to the request may be generated by the honeynet and provided to the attacker without actually performing the requested action(s). In some embodiments, the honeynet may be pre-loaded with POST requests that the attacker will communicate from a CLI tool of their choice. One way to do this is to use NLP (Natural Language Processing) technology, such as by establishing and utilizing an NLP dictionary that has requests and responses that are automatically sent back to the attacker when the appropriate conditions are met. There are various ways this can be handled, such as using string analysis to understand what request is being made and then determining the appropriate response from the dictionary.

[0047] In certain embodiments, as shown in FIGS. 1 and 2, a reverse proxy 112 (FIG. 1) (212 in FIG. 2) may be optionally provided as part of a process that can obtain additional information from the client to provide confidentiality and anonymity to servers located in a dummy VPC (Virtual Private Cloud). The reverse proxy 112 may be configured to record attributes of the attacker or the client device used by the attacker. The reverse proxy 112 also acts as a privacy and confidentiality barrier for resources that the attacker is spinning up. For example, an attacker may spin up databases or computer or network resources, and the reverse proxy 112 may be used to anonymize the identities of these resources. The reverse proxy node 112 maintains the anonymity of the instances 102, ensuring that the attacker never learns the true identities of these instances.

[0048] The resources of the IaaS instance 102 that the attacker interacts with may be limited to compute, storage, and memory resources, and may provide a small number of basic functions. The IaaS services / objects accessed by the attacker provide the correct responses necessary to maintain the "integrity" of the IaaS instance.

[0049] Step 2B: The attacker is a "real" user (GUI mode) In some cases, the attacker may be a genuine user directing the attack through an application running on the attacker's client system, for example, using a browser in another GUI application to initiate access to the IaaS instance. A system 200 for addressing requests and responses related to GUI-mode attacks is shown in FIG.

[0050] The process for GUI mode is very similar to the process for CLI mode. In GUI mode, an attacker may launch an attack using a fake browser GUI 204 to send requests. The attacker's interactions with the console (e.g., client device) and GUI application can be logged by the log node 210 of FIG. 2 (node ​​108 of FIG. 1). For example, data can be logged about the user / attacker's login, the attacker's interactions with the browser (e.g., which links the attacker clicked, the sequence of clicks, etc.). In certain embodiments, an asynchronous ON event listener 210 can be utilized to collect data about how the attacker is interacting with the GUI console. This collected data can be used to better understand not only the critical actions the attacker is taking on the backend, but also what actions are occurring on the console itself.

[0051] Step 2C: Error Handling In certain embodiments, the IaaS Honeynet API Control & Command Server provides a Status: 200 response to the attacker unless the API GET request is incorrectly formatted and / or the output type is incorrect. In the case of incorrect formatting and / or incorrect data type, the REST API node The code 206 sends the attacker the appropriate error handling code.

[0052] Step 3: Logging in Verbose Mode As shown in Figures 1 and 2, in certain embodiments, a separate log node (108 in Figure 1 and 208 in Figure 2) may be installed to record all events / resources / objects accessed in the honeynet's IaaS instances provided by the honeynet, as well as all events / resources / objects accessed by attackers. Logging may be performed in chronological order.

[0053] Step 4: ETL / machine learning pipelines, native threat intelligence feeds, etc. In certain embodiments, the log node 1108, 208 or server stores all attacker interactions. Data may be stored in various formats, such as RAW or .csv. Logged data may be periodically exported to an analytics platform for analysis. For example, a daily cron job may be used to upload logged data to an ETL (Extract, Transform, Load) / Machine Learning pipeline for future training. The log server also provides unique core attributes for attackers for native threat intelligence feeds that feed directly into internal blacklists used by security monitoring, detection, and prevention programs to protect against future threats surrounding actors who have previously attacked IaaS honeynets.

[0054] The amount of resources made available to the dummy IaaS instances set up by the honeynet may be determined based on the acceptable cost of luring an attacker and obtaining information about the attacker's activities. In some embodiments, a limited amount of computing, storage, and network resources may be allocated. For example, a specific number of pre-fabricated images, each with a fixed, limited amount of computing, storage, and network resources, may be provided, and these pre-fabricated images may be used to set up the IaaS instances requested by the attacker and perform the actions requested by the attacker. These pre-fabricated virtualized or containerized images may be hard-coded to not expand beyond the preset constraints.

[0055] The honeynet entices the attacker to connect and establish a session with the honeynet, leading the attacker to believe that he is attacking real / legitimate resources and performing the desired malicious activity, further enticing him to perform even more malicious activities. At some point, the honeynet may decide to stop the attacker's activities and shut down the attacker's session with the honeynet. In some cases, this point may be reached, for example, when the honeynet determines that sufficient data has been recorded about the attacker and his interactions with the honeynet and the dummy instance. In some other cases, this point may be time-based. For example, the honeynet may determine that this point has been reached when the duration of the attacker's session with the dummy instance and the honeynet meets or exceeds a preset time threshold. Various other factors may also be used to determine when to "shut down" the attacker. In other embodiments, a combination of the aforementioned and other factors may also be used.

[0056] Illustrative Embodiment #2 An IaaS instance includes a configuration of processing resources (e.g., cores, processors), storage resources (e.g., memory resources), and network resources bundled together to provide computing, storage, and network services. At the lowest level (memory, compute, IaaS clouds provide cloud virtualization (at the networking and resource layers). IaaS clouds provide service offerings for computing and storage functions coupled with network functions. Attacks on SaaS / PaaS instances are very different from attacks on SaaS or PaaS instances because attacks on IaaS instances target the data used by SaaS / PaaS applications rather than the computing, memory, or network resources. In the case of IaaS, several resources may be involved, and the configuration of these resources is difficult to understand, leading to a lack of existing solutions for preventing IaaS attacks. Monitoring IaaS resources and identifying attacks against them is extremely difficult because there are so many moving parts, each with its own unique configuration, and it's very easy to miss something. As a result, some IaaS attacks proceed completely unnoticed.

[0057] FIG. 3 is a simplified block diagram of a distributed environment 300 incorporating a honeynet with one or more honeypots, according to certain embodiments. As shown in FIG. 3, the distributed environment 300 includes a cloud service provider's data center 302. Here, the cloud service provider may offer one or more of IaaS, PaaS, SaaS, and other cloud services. These services may be provided using one or more real service instances 304. The term "real" is used here to distinguish these instances from "dummy" instances provided by the honeynet. The real service instances may include one or more real IaaS instances (e.g., R-IaaS#1) that provide one or more IaaS services, one or more real PaaS instances (e.g., R-PaaS#1) that provide one or more PaaS services, and one or more real SaaS instances (e.g., R-SaaS#1) that provide one or more SaaS services. The infrastructure for providing these real cloud services is provided by the cloud service provider. For example, the infrastructure may be provided by the data center 302. A customer or tenant may subscribe to one or more cloud services offered by a cloud service provider that utilizes data center 302 .

[0058] The distributed environment 300 depicted in FIG. 3 is illustrative only and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize that numerous variations, alternatives, and modifications are possible. For example, in other embodiments, the distributed environment 300 may have more or fewer systems or components than those depicted in FIG. 3, may combine two or more systems, or may have a different configuration or arrangement of systems. The configuration of the data center 302 depicted in FIG. 3 is illustrative only and not limiting. For simplicity, while only one data center 302 is depicted in FIG. 3, a typical distributed environment may include multiple data centers, possibly in different geographic locations. The multiple data centers may be communicatively coupled to each other via one or more communication networks. The communication network may be various types of communication networks, such as the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet network, a public or private network, a wired network, a wireless network, or the like, and / or combinations thereof. Communications may be facilitated using different communication protocols, including both wired and wireless protocols, such as the IEEE 802.XX suite of protocols, TCP / IP, IPX, SAN, AppleTalk®, Bluetooth®, and other protocols.

[0059] Attacks are carried out on resources provided by the data center 302 and maliciously exploit them. Each attacker has different characteristics. An entity that attempts to connect to the data center 302 or use resources provided by the data center 302 without proper authorization is considered an attacker. For example, an entity that uses dummy credentials to access and use resources provided by the data center 302 is considered an attacker.

[0060] Attackers come in many forms, including automated bot attackers and human user attackers. In the example shown in FIG. 3, automated bot 308 running on client device 310 may attempt to attack and exploit resources provided by data center 302. Automated bot 308 may be configured to listen in on endpoint nodes within data center 302 to find a way to connect and then use that connection to exploit resources provided by data center 302. Attacks may also originate from human users 312 using applications or software (e.g., GUI browser 314) running on client device 316 to attack and exploit resources provided by data center 302. The attacks themselves may be performed using different mechanisms, such as a command line interface (CLI) mechanism or a GUI-based mechanism.

[0061] The resources that an attacker (e.g., a bot or a human user) hacks or maliciously exploits may include one or more of the genuine instances 304 provided by the data center 302. For example, an attacker may connect to a genuine IaaS instance provided by the data center 302 and attempt to exploit the computing, storage, and / or network resources or services provided by the genuine IaaS instance. For example, an attacker may connect to a genuine IaaS instance and use the genuine IaaS instance to “steal” computing, memory, and network resources to perform cryptocurrency mining operations (e.g., Bitcoin mining), which require large amounts of computing, storage, and network resources.

[0062] As shown in FIG. 3, data center 302 provides honeynet 306. Honeynet 306 is configured to lure such attackers and collect data about them without compromising the data center's 302's genuine resources (e.g., genuine instances). Honeynet 306 comprises various components, including a network of honeypot servers (or honeypots). Each honeypot may represent a particular IaaS service instance that provides access to a particular set of IaaS resources. Each honeypot is configured to trick attackers into believing that they have successfully gained access to a genuine IaaS instance. Different honeypots 318, 320, 322, etc. may be provided for different types of IaaS services. While only one honeynet is shown in the embodiment shown in FIG. 3, this is not a limitation. A data center may provide one or more honeynets.

[0063] In the embodiment shown in Figure 3, honeynet 306 also includes a log server 330. Log server 330 is configured to receive and collect data about attacks logged by honeypots, and the collected data is stored in non-volatile memory for subsequent analysis. In some embodiments, such as the embodiment shown in Figure 3, honeynet 306 itself includes an analytics platform or server 332. Analytics platform or server 332 is configured to analyze the data collected by honeypots and the data logged by log server 330. In some other embodiments, analytics platform 332 is located at the data center 302 level. 32 may be provided. Such an analytics platform may be used to receive and analyze data collected by one or more honeynets hosted by data center 302. In some cases, the analytics platform may be located at a location remote from data center 302. In such cases, log server 330 may be configured to communicate data collected by honeynets 306 of data center 302 to the remote analytics platform using communication interface 344 of data center 302.

[0064] In particular embodiments, a particular set of available resources 324 may be set aside for use by honeypots in honeynet 306. Available resources 324 may include computing resources (e.g., cores, processors), storage resources (e.g., memory), network resources, database resources, containers, etc. The honeypot may use resources included in available resources 324 to spin up dummy IaaS instances that trick attackers into believing they are connecting to and using real IaaS instances. In some embodiments, resources included in available resources 324 may be pre-packaged into bundles of resources (called "pods"), each consisting of a particular set of computing, memory, and network resources in a pre-configured configuration. The honeypot may then spin up dummy IaaS instances using one or more of these pre-packaged bundles or pods.

[0065] Data center 302 may provide one or more host machines (e.g., computer systems) that provide the infrastructure for providing the various services and components of data center 302 shown in Figure 3. The host machines may be used to provide real instance 304, one or more honeynets 306 and their components, as well as various other servers and components of data center 302 shown in Figure 3. For example, honeypots included in honeynet 306 may be deployed across one or more host machines in data center 302.

[0066] In particular embodiments, honeynets are isolated and separated from real instances for security reasons. Thus, the infrastructure of data center 302 used to host honeynets is separate from the infrastructure used to support real instances 304. For example, the host machines used to run and support honeynet 306 may be isolated from other host machines in data center 302.

[0067] A variety of different techniques are used to lure attackers into honeynet 306. Attackers, including automated bots and human attackers, typically seek out SSH port 22 and FTP port 21 to exploit vulnerabilities on these ports. In the embodiment shown in FIG. 3, a decoy server or decoy node 336 is used to lure attackers. Decoy server 336 is configured to openly broadcast information on one or more ports in data center 302, such as SSH port 22 and FTP port 21, to draw the attacker's attention to these ports. When an attacker connects to one of these ports, dummy or fake credentials 338 are conveniently placed for the attacker to access. In some embodiments, decoy server 336 may broadcast information about dummy credentials 338, making it appear as if the credentials were broadcast in error. The dummy credentials 338 may include dummy restricted information, such as dummy username / password information, API keys, MAC addresses, certificates, tenant identifiers, passwords, etc. The purpose is to trick an attacker into believing that they have obtained real credentials that can be used to attack resources provided by the data center 302. In this form, some default credentials may be placed as dummy credentials. In some cases, an attacker sends an API call (e.g., GET cred) to access the dummy credentials 338, and then the dummy credentials are sent as a response to the API call. The API call may be handled by the API gateway server 340.

[0068] For example, in a typical scenario, an entity (tenant) that uses data center 302 to legitimately subscribe to a service offered by a cloud service provider is provided, at the time of subscription (or thereafter), with one or more credentials customized for that tenant. These credentials enable the tenant to log in to data center 302 and establish a session with the authentic instance offering the service to which it subscribes (e.g., an authentic IaaS instance offering a particular type of IaaS service). During session establishment, the tenant is prompted for credentials. The credentials are then used to authenticate the tenant. Upon successful authentication with the authentic instance offering the service to which the tenant subscribes, a session is established for the tenant.

[0069] The dummy credentials also allow the attacker to establish a session, but unlike a session with a legitimate tenant, the dummy credentials are used to establish a session with the honeynet 306 for the attacker. The session may be established with a honeypot included in the honeynet, or with a dummy IaaS instance spun up by the honeypot.

[0070] Once access to the dummy is gained, the attacker can send requests to data center 302 to establish a session for the instance and subsequent requests to perform one or more actions during the session. These requests may be in the form of API calls made by the attacker. In the embodiment shown in Figure 3, these API requests are received and processed by API gateway server 340. API gateway server 340 may be configured to read the requests, possibly authenticate the requests, and then forward the requests to back-end components of data center 302 for processing.

[0071] 3, an automated bot may be lured to a specific port on data center 302 and used to access dummy credentials 338. The automated bot 308 then sends a request to data center 302 using the obtained dummy credentials, requesting that a session be established on behalf of the attacker. The request is received and processed by API gateway server 340, and if it is determined to be from the attacker rather than a legitimate tenant of data center 302, it is forwarded to honeynet 306 for action. In particular embodiments, the request may be forwarded to a specific honeypot in honeynet 306 configured to provide the specific type of IaaS service requested in the API call of the attacker's request.

[0072] The API calls made by the legitimate tenants are the same as the API calls made by the attackers. Based on the API calls and the information received from the API calls, the API gateway server 340 must determine whether the request is from a legitimate tenant or an attacker so that it can forward the request to the appropriate backend component for processing. The API gateway server 340 may make this determination using different methods, such as:

[0073] (1) For API calls that request a session to be established, the API call: Typically, it also contains credentials (e.g., username / password) used to authenticate the requestor before establishing a session. If it determines that these credentials are dummy credentials, API gateway server 340 knows the request is from an attacker or malicious actor. API gateway server 340 then forwards the request to a component of honeynet 306 for further action.

[0074] (2) After the attacker is able to log in and establish a session with the dummy IaaS instance, data about the attacker and the attacker's actions during the session is collected and logged. This logged data may include, for example, device-level information about the device used by the attacker to submit the attack request. In certain cases, this device-level information can be determined from the API call itself. Thus, for an API call received by API gateway server 340, after API gateway server 340 determines that the device-level information about the API call matches stored device-level information about the attacker's device (which may have been previously recorded while the attacker was interacting with data center 302), API gateway server 340 determines that the API call is from an attacker and forwards the API call to a component of honeynet 306 for action.

[0075] (3) API gateway server 340 may also use information about the port number on which the request was received to determine whether the request is from an attacker. For example, as described above, ports such as SSH port 22 and FTP port 21 are commonly used to direct attacks. Therefore, requests and API calls received via these ports may be tagged as requests from an attacker. For example, in certain embodiments, based on the port of the connection and based on the dummy credentials, API gateway server 340 may determine that the request is not a legitimate request but rather a request from a malicious actor or attacker.

[0076] (4) A combination of the various pieces of information described above may be used to identify requests from an attacker.

[0077] Upon identifying the request as originating from an attacker, API gateway server 340 forwards the request to a component of honeynet 306 for further action. In particular embodiments, upon identifying the attacker, API gateway server 340 connects the attacker to and opens a session with a particular honeypot server from honeynet 306. For example, API gateway server 340 may establish a session for the attacker with a particular honeypot configured to provide the IaaS service requested in the request, and then forward the request to the honeypot for further action.

[0078] After a session is established between the attacker and a particular honeypot, the attacker can send further requests to spin up IaaS instances and to use resources provided by the IaaS instances. In particular embodiments, the honeypot may spin up a dummy IaaS instance, such as the dummy IaaS instance D-IaaS#1 spun up by HP1318 in FIG. 3. The honeypot may then return a response to the attacker indicating that the requested IaaS instance is installed and ready for the attacker to use, which may lead the attacker to believe that a legitimate (non-dummy) IaaS instance has been spun up.

[0079] After the dummy IaaS instance is spun up, during the session, the attacker can perform various actions using the resources associated with the spun-up IaaS instance. An attacker may send one or more requests to perform an action, such as a Bitcoin mining operation, using the compute, storage, and network resources provided by the dummy IaaS instance. For example, an attacker may utilize the compute, storage, and network resources provided by the dummy IaaS instance to perform an action, such as a Bitcoin mining operation. The honeypot with which the attacker establishes a session is configured to receive these requests, interpret each request to determine one or more actions or operations requested by the request, perform these actions using the spun-up dummy IaaS instance, and generate and send to the attacker responses corresponding to the actions and requests. The generated responses are valid responses from the real IaaS instance, leading the attacker to believe that they have access to the services and resources provided by the spun-up IaaS instance.

[0080] In certain embodiments, a honeypot can generate and send to an attacker appropriate responses corresponding to requested actions and API calls received from the attacker without actually configuring or spinning up a dummy IaaS instance. For example, the honeypot may use a set of rules to generate responses. The set of rules may include a mapping that identifies a set of possible actions that the attacker can request and one or more appropriate responses for each action. Upon receiving a request from the attacker, the honeypot may translate the request into one or more actions and then use the mapping to determine one or more responses for the one or more actions. The one or more responses may then be returned to the attacker in response to the received request. The honeypot generates a response that would lead the attacker to believe that it was able to spin up an IaaS instance and utilize the services and resources provided by the spun-up IaaS instance, even though the dummy IaaS instance has not even been spun up. The rule information (e.g., mapping information) may be stored in non-volatile memory accessible to the honeypot, such as in a database.

[0081] In certain embodiments, a combination of a dummy IaaS instance and a set of rules may be used by a honeypot to generate responses to requests received from an attacker. In one such embodiment, the honeypot can learn new rules, such as new action-response mappings, based on the spun-up dummy IaaS instance. For example, the honeypot may add new action-response mappings to its rule information after learning responses to a particular requested action received from an attacker using the dummy IaaS instance. When the same action is subsequently requested, the honeypot uses the rule information, rather than the IaaS instance, to generate the appropriate response for that action. One or more machine learning techniques may be used to learn, build, and augment the rule information mappings.

[0082] In addition to processing requests, the honeypot is configured to collect and record data about the attacker and its actions and interactions with the honeypot. The recorded attacker data may include the attacker's actions (e.g., the threat actor's user behavior patterns, other attributes unique to the user), unique attributes about the attacker, such as connection attributes and device-level attributes of the specific attacker (e.g., connection information, IP addresses of devices utilized by the attacker, Autonomous System Number (ASN) traceroute information, domain names, etc.), and other data related to the attack. The recorded data may include data about the attacker's sequence of actions, objects accessed by the attacker during the attacker's session with the honeypot, API calls made by the attacker (e.g., REST API calls made by the attacker), etc. The logged data may include information about API requests received from the attacker, responses generated and sent by the honeypot in response to the API requests, the IP address from which the request originated, the port number used by the attacker to connect to the data center, JavaScript on events (GUI This may include information about the client-based interactions (e.g., browser-based events on the client device may be monitored), device-level information, the interval between requests, etc.

[0083] In certain embodiments, a honeynet, such as honeynet 306, may include a log server 330. Log server 330 is configured to collect and / or receive data collected by honeypots included in honeynet 306. In such embodiments, data collected by individual honeypots may be forwarded to log server 330. Log server 330 is configured to store the data in the correct format. This data may be stored in non-volatile memory accessible to log server 330. Log server 330 may also function as a controller for accessing the collected data.

[0084] In particular embodiments, honeynet 306 may include an analytics subsystem 332. Analytics subsystem 332 is configured to analyze data collected by honeypots included in honeynet 306. The collected data may be analyzed to gain insights into attacker motivations (e.g., attack goals and intent), attack patterns, attack mechanisms, attack launch points (in terms of connectivity (e.g., IP addresses, domains, etc.) and geographical points), different types of attacks, resources and objects accessed by attackers during attacks, what attackers are attacking, which resources are utilized, how the resources are utilized, operations performed during attacks, attack frequency profiles, etc. Based on the analysis, in particular embodiments, profiles are generated to identify attackers and attacks. These profiles may then be used to prevent attacks before they occur.

[0085] In certain embodiments, instead of or in addition to having an analytics platform at the honeynet level, an analytics platform may be provided by data center 302. In such embodiments, data collected by one or more honeynets at data center 302 may be forwarded to this analytics platform for analysis. In certain embodiments, the analytics platform may be provided by a computing platform remote from data center 302. Such a remote analytics platform may be configured to collect and / or receive data collected by multiple honeynets dispersed across one or more data centers, aggregate the data, and then analyze the aggregated data.

[0086] A variety of different techniques may be used to analyze the data collected by the honeynet. In particular embodiments, ML (machine learning) techniques may be used. The data collected by the honeynet may serve as training data and be used to build and train models for identifying attackers and attacks based on various criteria contained in the collected data. Such models can then be used to proactively identify attackers and attacks, and preferably stop such attacks before they occur.

[0087] In certain embodiments, a big data pipeline may be provided to process the collected data, for example, a Hadoop or data lake platform may be provided to receive and process the data collected by the honeynet.

[0088] In the embodiment shown in Figure 3, a reverse proxy server 342 is provided to provide confidentiality and anonymity for servers and other components of data center 302 that reside behind the proxy server. The reverse proxy resides between clients (e.g., clients 310 and 316) and provides anonymity for servers behind the proxy. The client does not know which server it is connecting to. A reverse proxy server provides several benefits, including load balancing, caching, internal traffic isolation, and logging. The reverse proxy server 342 may also be configured to record attributes about the attacker or the client device used by the attacker. The reverse proxy server 342 acts as a privacy and confidentiality barrier for the resources that the attacker is spinning up. For example, an attacker may spin up databases or computer or network resources, and a reverse proxy may be used to anonymize the identities of these resources. The reverse proxy preserves the anonymity of the instances, ensuring that the attacker never learns the true identities of these instances.

[0089] As described above, a honeypot is configured to respond to requests received from an attacker while collecting data about the attacker and the attacker's actions. At some point, the honeypot may decide to stop the attacker's actions and block the attacker's session. The honeypot may make this decision using a variety of different factors and combinations of these factors. Some of the factors include:

[0090] (1) Time Threshold—If the duration of an attacker's session meets or exceeds a pre-set time threshold, the honeypot may decide to terminate the user's session.

[0091] (2) Interval - If an attacker stops interacting with a honeypot, they can wait a certain period of time, for example, allowing session activity to continue while the attacker is interested. In general, the more data collected by a honeypot, the more data is available for downstream analysis.

[0092] (3) Data Criteria - In some cases, the honeypot may decide to close the attacker's session once it determines that sufficient data has been recorded about the attacker and their interactions with the honeypot.

[0093] (4) A variety of other factors may also be used to determine when to "shut down" an attacker, and in other embodiments, a combination of these and other factors may be used.

[0094] In certain embodiments, an attacker may be allowed only one session with the honeypot. In such embodiments, any subsequent attempts by the attacker to open a second session are prohibited. In some other embodiments, multiple sessions may be allowed, either in parallel or sequentially. In such embodiments, information about the attacker may persist between sessions.

[0095] In certain embodiments, the functionality provided by one or more honeynets may be offered as a cloud service to subscribing customers. By subscribing to such a service, customers may be able to proactively identify attacks against their resources.

[0096] Figure 4 is a simplified block diagram of a honeypot server 400, according to a particular embodiment. Honeypot server 400 (also referred to as honeypot 400) may include multiple subsystems communicatively coupled to one another. In the embodiment shown in Figure 4, the subsystems of honeypot 400 include request interpretation subsystem 406, response generation subsystem 408, communication interface subsystem 412, and recording subsystem 414. These subsystems may be implemented solely in software (e.g., programs, code, or instructions executable by one or more processors), in hardware, or a combination thereof. The honeypot 400 shown in FIG. 4 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize that numerous variations, alternatives, and modifications are possible. For example, in some implementations, honeypot 400 may have more or fewer subsystems or components than those shown in FIG. 4, may combine two or more systems, or may have different configurations or arrangements of systems.

[0097] The request interpretation subsystem 406 is configured to receive and interpret requests from an attacker. For example, in particular embodiments, upon determining that a request or API call is from an attacker, the API gateway server 340 selects a particular honeypot from the honeynet 306 (e.g., as shown in FIG. 3 ) and forwards the request to the selected honeypot. At the honeypot, the request is received by the request interpretation subsystem 406. Upon receiving the request, the request interpretation subsystem 406 is configured to interpret the request and determine a set of one or more actions to perform in response to the request. The one or more actions may include, for example, an action to install or spin up an IaaS instance, an action to utilize one or more resources provided by the IaaS instance, etc.

[0098] If the action includes spinning up an IaaS instance, the request interpretation subsystem 406 may use one or more resources from the available resources 404 to set up a dummy IaaS instance 416. The dummy IaaS instance 416 may provide services that enable utilization of one or more computing resources (e.g., processing resources such as processors, cores, etc.), one or more storage resources (e.g., providing memory resources), one or more network resources, and other resources provided by the dummy IaaS instance 416. For example, if the action performed corresponds to utilization of resources provided by the dummy IaaS instance 416, the request interpretation subsystem 406 may allow the attacker to use the resources to fulfill the attacker's request. In certain cases, the request interpretation subsystem 406 may apply the action requested by the attacker to the dummy IaaS instance 416. The honeypot 400 may be configured to spin up and utilize one or more dummy IaaS instances.

[0099] The response generation subsystem 408 is configured to generate dummy responses to requests received from an attacker such that the response generated by the response generation subsystem 408 leads the attacker to believe that the response is valid and generated by a valid IaaS instance, thereby encouraging the attacker to continue their activities without fear of being detected as a malicious actor or user.

[0100] There may be a one-to-one, one-to-many, or many-to-one relationship between actions and responses. In a one-to-one relationship, each action may have its own response. In a one-to-many relationship, an action may have multiple associated responses. In a many-to-one relationship, one response may be generated and sent for multiple actions. The response generation subsystem 408 is responsible for generating appropriate responses to received attacker requests.

[0101] The response generation subsystem 408 may use various techniques to generate a response. According to one technique, the request interpretation subsystem 406 may apply the action to be performed to the dummy IaaS instance 416. The dummy IaaS instance 416 may then send a corresponding response to the response generation subsystem 408. Subsystem 408 may forward the response received from dummy IaaS instance 416 as a response to the request. In some cases, response generation subsystem 408 may format or modify the response received from dummy IaaS instance 416 to generate a response that is communicated to the attacker.

[0102] According to a second technique, the response generation subsystem 408 may generate responses to attacker requests without using a dummy IaaS instance 416, using a set of rules 418. In such an embodiment, the dummy IaaS instance may not even be instantiated by the honeypot 400. The rule information 418 may be stored in non-volatile memory 402, such as a database, accessible to the honeypot 400. The set of rules 418 may include mapping information that specifies a mapping between actions that an attacker can request and their corresponding responses. A one-to-one, one-to-many, or many-to-one relationship between actions and responses may be reflected in the mapping information.

[0103] Upon receiving a request from an attacker, the request interpretation subsystem 406 interprets the request and identifies one or more actions to be performed in response to the request. The response generation subsystem 408 may then search the rules 418 to identify an appropriate response for the requested action. The identified response based on the rules 418 may then be returned to the attacker as a response to the attacker's request. The honeypot generates a response that leads the attacker to believe that it was able to spin up an IaaS instance and utilize the services and resources provided by the spun-up IaaS instance, even though a dummy IaaS instance may not have been spun up. For example, the honeypot 400 may receive a request from the attacker in which the requested action is to instantiate (spin up / install) an IaaS instance. The response generation subsystem 408 may then search the rule information (e.g., mapping information) to find an appropriate response to this request without actually installing the IaaS instance, but the response indicates that the requested IaaS instance has been installed, thereby tricking the attacker into believing that they have installed a valid IaaS instance.

[0104] Upon receiving a request from an attacker, the request interpretation subsystem 406 may translate the request into a specific action to be performed. The response generation subsystem 408 may then search the mapping information 418 to find an entry in the mapping information that matches the specific action to be performed. The response generation subsystem 408 uses the matching entry to identify a response corresponding to the matching entry, i.e., a response to the action. The identified response is then used to send a response to the attacker in response to the received request.

[0105] In particular embodiments, the response generation subsystem 408 may generate a response to a request received from an attacker using a combination of a first technique (i.e., using a dummy IaaS instance) and a second technique (i.e., using rule information 418). Upon receiving a requested action from the attacker, the response generation subsystem 408 may determine whether to use the first response generation technique or the second response generation technique and generate a response to return to the attacker using the determined technique.

[0106] In some embodiments, the response generation subsystem 408 may use machine learning rules to learn new mappings between actions and responses and use this learned information to add the mappings to the rules 418. These learned mappings may then be used to generate responses to subsequent requests received from the attacker.

[0107] The recording subsystem 414 is configured to record data regarding the attacker and their interactions with the honeypot 400. The recording subsystem 414 may also track and store information regarding requests and corresponding responses generated by the response generation subsystem 408 in response to the requests and returned to the attacker. The recording subsystem 414 may be configured to store the recorded data as recorded data 420 in the non-volatile memory 402. In some embodiments, the recorded data may also be communicated from the honeypot 400 to external components such as other honeypots, the log server 330, or a location remote from the data center 302 (e.g., a remote analytics platform). Data collected by the honeypot server 400 may also be sent to a centralized collection server (e.g., a honeynet log server), which may then send the data to other analytics subsystems. Analytics may reside on-premise or elsewhere. The Honeynet log server may determine which data to send to Analytics or may provide an interface for Analytics to pull data from the Honeynet log server. In certain embodiments, the communication interface 412 may facilitate communication of data to and from the honeypot 400.

[0108] Non-volatile memory 402 may also store other information 422 that honeypot 400 uses to perform its operations. For example, other information 422 may include configuration information, such as information about pre-created instances (customized "pod" combinations of IaaS resources) that honeypot 400 can use to set up dummy IaaS instances.

[0109] 5 is a simplified block diagram of a honeynet 500 connected to a cloud service provider infrastructure 502, according to certain embodiments. The honeynet 500 may be a virtual computing instance and / or a cluster of one or more virtual machines. The honeynet 500 may be accessible to one or more attackers 501 and / or the cloud service provider 502 via a public network 504. The cloud service provider 502 may also be in communication with a threat analysis system 506. The threat analysis system 506 may be configured to analyze collected data about attackers and make recommendations, alerts, and / or decisions to prevent threats based on the collected data.

[0110] In some examples, a set of honeypot endpoints (honeypot servers (or just honeypots) S1-S3) can be installed in honeynet 500. In honeynet 500, each honeypot is an endpoint node purposely installed for attackers to perform highly malicious acts. Honeynet 500 can be deployed on one or more host machines. For security reasons, these host machines can be isolated from the rest of cloud service provider 502 (e.g., as shown in FIG. 5) or the host machines can be isolated within cloud service provider 502 (e.g., as shown in FIG. 3 where HP1-HP3 are implemented within data center 302). A honeynet management system 508 can be provided for deploying and configuring honeypots S1-S3 and for performing local processing. Although three different honeypots S1-S3 are shown in FIG. 5, any number of honeypots can be implemented in honeynet 500. As will be described in further detail below, honeypots S1-S3 can be implemented in various forms (e.g., types).

[0111] Different types of honeypots may be deployed in honeynet 500 to emulate different kinds of services. For example, SSH and / or Telnet honeypots for emulating SSH / Telnet services, SMTP (e.g., Examples of honeypots include SMTP-based honeypots to emulate HTTP (e.g., a mail server), SSL, and TLS; HTTP honeypots to emulate HTTP (e.g., a web server); other honeypots to emulate services such as ftp, rdp, http, and https, e.g., to collect credentials; or a Web Logic honeypot to emulate an Oracle WebLogic server environment. Thus, different honeypots may emulate different types of servers and may have different shapes. For example, the shape of a server may dictate the APIs used to access the server, file structure, and so on. Customers 507 (e.g., of cloud service provider 502) can request honeypots be deployed based on the shapes / types of honeypots they are interested in, and then decide and select the specific honeypots they want to use. This selection may be based on the type of service the customer runs (e.g., to collect attacker data about that type of service).

[0112] Implementing these various types of honeypots allows for the collection of different network-based indicators of compromise (IOCs). When an attacker request comes into honeynet 500, the request can be matched to the appropriate honeypot based on the activity requested by the attacker, the port on which the request was received, or other criteria. Multiple attackers may simultaneously interact with the same honeypot, with each honeypot configured to provide the appropriate response to the attacker to trick the attacker into believing that they are in a real environment and interacting with a real IaaS instance rather than a dummy instance. This may be done through emulation. In certain embodiments, the honeypots may comprise actual servers (e.g., WebLogic servers) to enhance the realism of the interaction. Through this interaction, a honeynet platform 509 implemented within the cloud service provider's 502 environment is able to collect network-based IOCs, including samples of specific malware associated with specific attack types. A honeynet platform 509 may be provided for configuring and deploying honeynet 500 and the various honeypots S1-S3. In particular embodiments, a Docker infrastructure is used to deploy and manage honeypots, with each honeypot implemented as a Docker container (e.g., an isolated, virtualized bundle of software).

[0113] As described above, customer 507 can choose different types of honeypots to deploy based on their interests. Because there are multiple different attack types that attack different targets, customer 507 can select the specific honeypots they want from the Docker-configured containers. For example, there may be a Point of Sale (POS) system that provides access to payment information, a healthcare system that provides access to health records and other personally identifiable information (PII), etc. Therefore, customer 507 may want to collect different types of data by exposing different types of honeypots on a public network (e.g., the Internet). Each honeypot can log data about attacker actions / interactions to a local persistent store. Honeypots may log raw (RAW) data, which can then be processed locally to generate processed honeypot data. This processing may include log rotation (e.g., rotating data every 5 minutes or other interval), log validation (e.g., determining that data of interest has been collected and is in the correct format), PII scrubbing to anonymize the data, and data formatting (e.g., putting the data in the correct format (e.g., JSON) for transfer to a central system). The processed data may then be sent to a honeynet platform 509, which may then forward this data to a threat intelligence analysis system 506 (e.g., an external service) or an internal version of a threat analysis module 510. In some examples, one of the threat intelligence analysis systems 506, 510 can identify IP addresses of known attackers (e.g., detected from log data collected and stored from honeypots located around the world). These IP addresses can then be used by various security products to potentially require step-up (e.g., multi-factor) authentication for privileged access requests from these IP addresses.

[0114] One major concern with implementing a honeypot is whether an attacker will gain kernel-level access from the honeypot and then gain access to the main network (e.g., by using a malicious binary). This could lead to irreparable damage to the cloud service provider 502. Therefore, isolating the honeypot is very important. In some examples, this isolation can be achieved by implementing the honeynet 500 using a third-party service provider (e.g., external to the cloud service provider 502 implementing the honeynet platform 509). In this way, even if an attacker is able to penetrate beyond the honeypot into the underlying systems, they still cannot access the cloud service provider 502. However, another way to isolate the honeynet 500 is to implement it in a Docker container and / or on the user's bare metal (e.g., an isolated, single-tenant physical machine not shared by other services).

[0115] Honeynet 500 may be configured using a variety of different types of honeypots. Honeynets 512 and 514 may be configured the same as honeynet 500 or differently, as desired. For example, honeynet 500 may be implemented in any configuration by honeynets 512 and / or 514. However, honeynet 512 may be implemented within cloud service provider 502, while honeynet 514 is merely another honeynet implemented by cloud service provider 502 (e.g., honeynet 500 implemented on a third-party host). Any number of additional honeynets similar to honeynets 500 and 514 may be implemented, for example, in various locations around the world.

[0116] As noted above, honeynet 500 may include multiple honeypots. As an example, honeynet 500 includes a first honeypot S1 accessible via port P1, a second honeypot S2 accessible via port P2, and a honeypot S3 accessible via port P3. Each of ports P1, P2, and P3 may be accessible on public network 504. Thus, these ports become visible as attacker 501 scans the Internet looking for open ports. This is intentional, allowing attacker 501 to be lured to the honeypot. Honeynet 500 may be deployed on a single host device (e.g., internal or external to cloud service provider 502). This single host may be containerized such that there are various containers, each containing a honeypot. Other configurations (e.g., multiple hosts for honeynet 500 and / or multiple honeypots in a single container) may be implemented if desired. When a request comes from an entity (e.g., an attacker), the type of request and / or the port associated with the request may be used to determine which honeypot to connect the entity to. For example, if the request is to access port P1, the honeynet management system 508 may determine, based on the request on port P1, to connect the entity to the S1 honeypot corresponding to port 22.

[0117] You may know that different types of services use specific ports. For example, the SSH service generally uses port 22, the SMTP service generally uses port 30, and so on. For example, a typical honeypot service typically uses port 25, while an FTP service typically uses port 21. Once honeypot services are deployed within honeynet 500, they are reachable via the IP addresses assigned to the hosts. These services essentially function the same as any other server. An attacker 501 can scan the Internet for IP addresses and discover which ports are open on each IP address. IP addresses with open ports are attractive targets for attackers. Therefore, a honeypot can be constructed using these specific ports available on the Internet. Of course, these ports typically require passwords, even in the real world (e.g., ports other than honeypot ports). In some cases, the password / username combinations may be publicly known. However, in other instances, honeypots may be configured using various known username / password combinations (e.g., username: admin, password: password is a common standard / default password). Although not shown here, each honeypot port (e.g., P1-P3) may have a corresponding internal port number that is not known to the outside world. For example, port 22 may be a privileged port that is exposed externally (e.g., requires a login), but the actual port that communicates with the honeypot may be some other port number. In this case, the honeynet management service 508 may maintain a mapping between each external / privileged port and its corresponding internal (e.g., non-privileged) port number.

[0118] In some examples, the honeynet management system 508 may be accessible through other / unknown ports. The ports for the honeynet management system 508 may be selected from a list of randomly / rarely used ports that an attacker would not be interested in checking. Additionally, the honeynet management service 508 may allow a service (e.g., a customer) to manage and / or control how containers are installed, how the environment is set up, and how the honeypots operate. In some cases, the configuration settings used by the honeynet management system 508 to manage and / or control the honeypots may be controlled by the cloud service provider 502 (e.g., more directly by the honeypot platform 509 of the cloud service provider 502). In some cases, the controller of the honeypot platform 509 operates in both the control plane (e.g., to control the honeynet 500) and the data plane (e.g., to fetch data associated with the honeynet 500). The honeypot platform 509 may also include a synchronizer configured to synchronize logging of data about interactions received from the honeypots. The honeypot platform 509 may also include a statistics collector, which may be configured to aggregate collected data (e.g., system logs, etc.).

[0119] As mentioned above, honeynet 500 can alternatively be implemented within cloud service provider 502, which controls honeynet 500 (e.g., honeynet 512). This is obviously more dangerous from a security perspective, since if attacker 501 were to escape the container in which the honeypot is hosted, they could potentially gain access to other private / secure information and / or resources of cloud service provider 502. Having honeynet 500 hosted by a third-party provider would mitigate that risk. However, there are several benefits and advantages to hosting honeynet 510 within cloud service provider 502. For example, threat analysis system 510 can gather attacker data specific to those attackers who wish to attempt to exploit that particular service provider. One example is Oracle's WebLogic server. Attackers looking to hack into Oracle's cloud infrastructure services may want to Attackers will look for WebLogic servers on port 80 or port 443. By having emulated WebLogic servers as honeypots to lure attackers, Oracle will be able to gather useful data about attackers who are intentionally targeting known Oracle vulnerabilities.

[0120] Using a similar example, Oracle might choose to build a honeynet such as honeynet 512 that resides within its OCI (Oracle Cloud Infrastructure) service. To make the honeypot appear more authentic, honeypot platform 509 could configure honeynet 512 to look like real Oracle servers, rather than just emulating the servers in the containers. This should work, since an attacker attempting to hack into Oracle would be able to see the WebLogic servers as evidence that they have penetrated OCI. Thus, making the honeypot specific to the resident service provider can help catch sophisticated attackers targeting specific OCI applications (e.g., because the attacker is aware of specific vulnerabilities within).

[0121] Another example of configuring a honeypot to appear more authentic (e.g., in the Oracle example, making it appear to be Oracle even though it is hosted by Oracle) is to design the honeypot to look like a Fusion Applications front end (or other application development suite). When an attacker initiates a session with the honeypot, the attacker may be presented with or be able to access simulated Fusion data. Additionally, the honeypot can be configured to be hosted using an Oracle IP address. The honeypot platform 509 can then track and log the attacker's interactions with the machine, potentially allowing the attacker to steal "tagged" data. This data can then be identified when / if found; i.e., the simulated data can be tagged in this way and given access to the attacker. If the attacker attempts to use that data outside of the honeypot, the attempt can be discovered, and the attacker can be detected and potentially identified.

[0122] Another option would be to set up a pseudo control plane API that looks like the service provider's control plane API (e.g., OCI in this example). It would look like a traditional API used by the service provider, but would be configured with weak credentials that would allow an attacker access. Again, the service provider would track what the attacker is doing while on the network. In some cases, bare metal hardware may be used to prevent attackers from compromising customers who are supposedly sharing a hypervisor. Each session would be tagged, and all network traffic in the tenancy would be monitored. In this way, the honeypot platform 509 could track advanced attack patterns and learn what techniques attackers are using to move between machines.

[0123] As will be described in more detail below, an IaaS provider may be configured with a service tenancy, a data plane, a control plane, specific subnets, IP addresses, gateways, etc. Given the patterns (e.g., architectures) shown in Figures 9-11, it would be advantageous to emulate these patterns as closely as possible when configuring honeypots. This is true whether the honeynet is running locally (e.g., honeynet 512) or externally implemented (e.g., honeynet 500). Thus, honeypot platform 509 can be configured to run the honeypots externally, such as on a third-party service provider's machine. Even if it works, you will likely want to configure your honeypot instances to look like the infrastructure of the honeypot platform 509 hosting service provider.

[0124] Additionally, the honeypot platform 509 may be configured to offer a tool called honeypot-as-a-service that can be used by others (e.g., by subscribing customers 507). In this example, a customer wants to run a honeypot for its own data collection and protection from attackers, without providing any computing functionality itself. Thus, the honeypot platform 509 can offer others the ability to host any type of honeynet as a service. In one example, this service can be provided via one or more APIs and / or through a subscription service.

[0125] In some examples, a honeynet service may provide one honeynet accessible to multiple different customers. However, in other examples, individual honeynets (e.g., one honeynet per customer) may be implemented. Such a service may be hosted by a service provider (e.g., cloud service provider 502 using honeynet 512) on behalf of customer 507, or may be hosted within the customer's 507 environment. In addition, each customer 507 can customize what kind of honeynet they want to build, including which honeypot instances they want to run. They may want to distribute honeypots across different honeynets, across different ranges, across specific geographic regions, etc. For example, customer 507 may want to implement a specific honeypot (e.g., WordPress servers) in a specific region (e.g., India). In this example, honeynet platform 508 then builds a honeynet in India (potentially with only that one honeypot) to track attackers targeting WordPress servers in that country. In another example, various honeynets are constructed using multiple different honeypots already in multiple containers, and upon request, the honeypot platform 508 automatically deploys honeypot containers of the requested type into the appropriate honeynet.

[0126] In this manner, honeypot platform 508 can be configured to receive requests for honeynets or honeypots from customers. The requests can include configuration information. The configuration information specifies the number of honeynets, the location where the honeynet(s) will be deployed, the type and / or number of honeypots to be deployed within the honeynet(s), and the type of data to be logged. In response to the request, honeypot platform 508 builds one or more honeynets and / or one or more honeypots based on the configuration information. Data can be collected, logged, processed, and / or analyzed before being transmitted to a threat analysis system (e.g., threat analysis system 506 and / or threat analysis system 512) and / or the customer itself. Honeypot platform 508 continues to implement these honeynets and / or honeypots as a service on behalf of the customer until a certain amount of time has elapsed or the customer requests termination of the service.

[0127] 6 is a simplified block diagram of a computing system that can host a honeynet 600 on behalf of a honeypot platform system 602 and / or that can host a honeynet 600 controlled by a honeypot platform system 602. In some embodiments, the computing system hosting the honeynet 600 may be a third-party service provider (e.g., different from the computer hosting the honeypot platform system 602). However, in other examples, the same computing system may host the honeynet 600. It may also be a network system.

[0128] In some examples, a computing system hosting honeynet 600 can have a base operating system and can implement a container 604 that can emulate one or more honeypots (e.g., honeypots S1, S2, S3, ..., SN; collectively, honeypots S1-N). Honeypots S1-SN can be any type of honeypot (as described above), can be containerized (e.g., implemented in container 604), and can write data to disk (e.g., by logging the data to RAW HP Data 606 in persistent store 608). If an attacker gains access to one of honeypots S1-SN, they can log their activity by writing to a file in RAW HP Data 606. This data can be written in a JSON format, for example. In some cases, each HP S1-SN may send out different types of data based on the type of server it is emulating. For example, each type of server may consume and / or process different types of data. As an example of this, SSH data is significantly different from mail server data (e.g., SMTP).

[0129] In some examples, this data can be sent to a log rotator 610 in a data processing system 612. The data processing system 612 is part of a honeypot management system 614 configured to manage honeypots S1-SN along with a visualization system 616. The log rotator 610 can rotate the log data at regular intervals (e.g., every five minutes or as needed). In some cases, the computing system 600 may not be able to control how the honeypot logs data (e.g., whether to log to one file daily or to different files). Therefore, the log rotator 610 is typically configured to rotate logs at specific time periods desired by the data processing system 612 or the host system 600. The log data may be subdivided by time period for synchronization with an HP data synchronizer 618. However, before sending the data to the HP data synchronizer 618, the data processing system 612 may first validate the data (e.g., using a log validator 620), scrub the data (e.g., using a PII scrubber 622), and format the data (e.g., using a data formatter 624). The data validator 620 may verify the type of data ingested and ensure that it is the correct type for the field of interest to downstream consumers 626 (e.g., customers) (e.g., if the data is an IP address, is it actually a 32-bit address?). The PII scrubber 622 may be configured to scrub the data for personally identifiable information to obfuscate identities that might otherwise be discovered. The data formatter 624 may be configured to format the data into a JSON format (e.g.,) so that it can be shared (e.g., later in the pipeline) with a platform (e.g., the HP data synchronizer 618) that understands that format. After processing, the data may be stored in processed HP data 628 in the persistent store 608.

[0130] In some cases, persistent store 608 is configured as block storage (e.g., for economy). Honeypots S1-SN are running (e.g., they may be running in parallel) and constantly logging data to block storage, first to raw HP data 606 and then, once processed, to processed HP data 628. In some instances, multiple attackers may connect to a single honeypot. This is possible because each honeypot is an emulated server. Thus, the same honeypot instance (e.g., by type) can communicate with multiple attackers simultaneously, but the single honeypot appears to each attacker as a separate instance. However, the emulated honeypot instance may only be able to access the data for a given session with each attacker. It is stateful only for the instance, so if an attacker logs out, a new login can emulate a new instance of the same, but all attackers' logs on the same instance can be written in parallel.

[0131] As mentioned above, it is advantageous to make the emulated server appear authentic to an attacker. This allows the attacker to remain logged in for a longer period of time, thereby gathering more data. This also allows the attacker to attempt more advanced techniques, which can be logged and analyzed to learn from the attacker. Techniques for making the emulated environment appear authentic include providing a user interface (UI), creating fake accounts that the attacker can access, and / or running instances and / or sessions on bare-metal machines. As mentioned above, honeypots S1 through S1N are implemented in Docker containers (or other types of containers). Such containers are virtual environments that emulate each type of server or service being requested. Each honeypot S1 through S1N is a virtual container emulating an environment. When a hacker requests a filesystem listing, it is advantageous to reply with an appropriate response that makes the emulated environment appear authentic. For example, in the case of a web server, the response may indicate to the attacker that the server is running Apache on port 80. The honeypot can also create a list of files that appear to be standard files stored on systems that were actually running Apache.

[0132] As briefly mentioned above, an attacker's session may be stateful while the attacker is logged into the honeypot. In some instances, the session may be refreshed at a specific interval (e.g., five minutes). Most attacks are automated and last only a few seconds, so five minutes is a sufficient amount of time for a session. However, in some instances, the session may be active while the attacker is logged in and interacting with the honeypot (e.g., making requests).

[0133] Once the data is logged and processed, it can be returned directly to the honeypot platform system 602, e.g., the HP data synchronizer 618. The synchronizer 618 can be configured to fetch data from the processed HP data 628 at regular intervals (e.g., five minutes). The synchronizer helps synchronize the data feeds at regular intervals so that no data is lost. The synchronizer 618 can then send the data to downstream consumers 626 and / or threat analysis systems. In some examples, the controller 630 of the honeypot platform system 602 can be configured to add, split, restructure, improve, or control any of the honeypots S1-SN. The controller 630 may communicate with the honeypot management system 614 via an SSH-type connection and / or a secure shell application. Additionally, the system statistics collector 632 is configured to collect information about system logs or other log information. The system statistics collector 632 may be implemented as part of the control plane of the honeypot platform system 602 and may also communicate with the visualization system 616 of the honeypot management system 614 via SSH. In some examples, the monitoring and alerting system 634 can be configured to check files and file systems that it is designated to monitor. The monitoring and alerting system 634 can run checksums on the data to see if there is any mismatch and, in some cases, restore the file. This is advantageous if an attacker actually breaks into the honeypot platform system 602 (e.g., if the computing system hosting the honeynet 600 is the same computer hosting the honeypot platform system 602) and makes any changes. The monitoring and alerting system 634 can then notify downstream customers, third-party services (e.g., the honeynet The logger 632 may be configured to present the logged data to a UI or other application that prepares the data for visualization.

[0134] FIG. 7 is a flow diagram illustrating an example method 700 for performing the techniques described herein. Some or all of method 700 (or other processes described herein, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions, or may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) collectively operating on one or more processors by software, hardware, or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium is a non-transitory storage medium. Method 700 may be performed by one or more, or a combination of, computing systems hosting data center 302 of FIG. 3, honeypot server 400 of FIG. 4, honeynet 500 and / or honeypot platform 509 of FIG. 5, or honeynet 600 and / or honeypot platform system 602 of FIG. 6.

[0135] Method 700 may begin at block 702. In block 702, a computing instance of an IaaS service may provide (e.g., implement / run) multiple honeypot servers. Each honeypot server may be implemented in a container or may emulate a physical server. Additionally, each honeypot server may be identified by a honeypot type. For example, honeypot types may include SMTP honeypot, WebLogic honeypot, HTTP honeypot, FTP honeypot, SSH honeypot, etc. Based on the type, each honeypot may interact with users differently, process different data, etc. Additionally, the multiple honeypots may be considered as a honeynet. This honeynet may be implemented by a computing instance running locally within the IaaS service or externally (e.g., by a third-party service provider).

[0136] At block 704, method 700 may include the computing instance luring an attacker into establishing a session with at least one of the honeypot servers. The luring step may be based on one or more ports associated with an IP assigned to the honeypot that are exposed on a public network (e.g., the Internet). The luring step may also include exposing the honeypot's login credentials, although in most cases exposing the port will be sufficient to lure an attacker because of the wide variety of username / password combinations that are commonly known to attackers and the general public.

[0137] At block 706, method 700 may include the computing instance receiving a first request from an attacker. In some cases, the first request may be a request related to the instance and / or may include request characteristics. The first request is typically a request to log in to a service that resides across a port of interest to the attacker. The first request characteristics may identify the port to which the request was sent, the type of service being requested, the type of action being requested, etc.

[0138] At block 708, method 700 includes selecting a particular one of the plurality of honeypot servers based at least in part on the request characteristics and the honeypot type by the computing instance. For example, if an attacker is requesting access to port 25, and port 25 corresponds to an SMTP server, the computing instance may identify a honeypot that is emulating an SMTP server for the attacker. In this example, the request characteristics are information that identifies either port 25 or the request to log into an SMTP (mail) server. Using this information, the computing instance can identify an SMTP honeypot for this potential connection (e.g., based on a mapping of characteristics to types). The specific honeypot identified in this example is an SMTP honeypot.

[0139] At block 710, method 700 may cause the computing instance to establish a session with the attacker to connect to a particular honeypot. In this manner, a short-lived (e.g., 5 minutes) session may be established. During the session, the attacker has privileged access to the identified particular honeypot server. When the attacker logs off, a new session must be established with the same honeypot server or a different type of honeypot server.

[0140] At block 712, method 700 may cause a particular honeypot server connected to the attacker to generate a response to a second request from the attacker. The second request may occur after a session is established and thus would be received from a logged-in attacker. The second request may be a request to spin up a virtual computing instance, a request to access a secured resource, or the like. Essentially, the second request may be any type of request that an attacker may choose to make to a logged-in honeypot server. The response generated must be an appropriate response to the request. For example, if the request was to access data, the response must provide the data or a dummy of the data. If the request was to spin up a virtual computing instance, the response must be a response that the instantiation has been confirmed.

[0141] At block 714, method 700 may cause the particular honeypot server to communicate a response to the second request to the attacker. As discussed above, the response must be an appropriate response to the given request in order to continue to convince the attacker that they are connecting to a genuine server.

[0142] At block 716, method 700 may end. At block 716, the computing instance may record data about the attacker or about one or more interactions by the attacker with a particular honeypot. This data may be processed and / or analyzed to help prevent future attacks.

[0143] Exemplary Implementations As mentioned above, Infrastructure As A Service (IaaS) is a special type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider may also provide a variety of services (e.g., billing, monitoring, logging, security, load balancing, and clustering) that accompany these infrastructure components. Accordingly, these services can be policy-based, allowing IaaS users to enforce policies that drive load balancing and application availability. This will allow for maintaining availability and performance.

[0144] In some cases, IaaS customers may access resources and services over a wide area network (WAN) such as the Internet and can use the cloud provider's services to install the remaining elements of their application stack. For example, a user can log in to an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer can then use the provider's services to perform a variety of functions, including load balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0145] In most cases, the cloud computing model requires the participation of a cloud provider, which may be, but need not be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS, or an entity may choose to deploy a private cloud and become its own provider of infrastructure services.

[0146] In some examples, IaaS deployment is the process of putting a new application or a new version of an application onto a provisioned application server. It can also include the process of provisioning the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider below the hypervisor layer (e.g., server, storage, network hardware, and virtualization). Thus, the customer will be responsible for handling the deployment of the operating system, middleware, and / or application (e.g., on top of self-service virtual machines (which can be spun up on demand)).

[0147] In some examples, IaaS provisioning may refer to obtaining a computer or virtual host for use and also installing the necessary libraries or services on it. In most cases, deployment does not include provisioning, which may need to be done first.

[0148] In some cases, IaaS provisioning presents two distinct challenges. First, there's the upfront challenge of provisioning the initial set of infrastructure before anything can run. Second, there's the challenge of evolving the existing infrastructure once everything is provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges may be addressed by allowing the configuration of the infrastructure to be defined declaratively: one or more configuration files can define the infrastructure (e.g., which components are needed and how they interact). The entire topology of the infrastructure can then be declaratively defined (e.g., which resources depend on which resources and how those resources work together). In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0149] In some instances, the infrastructure may have many elements connected to each other. For example, there may be one or more VPCs (Virtual Private Clouds) (e.g., possibly on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, one or more security group rules that define how to secure the network and one or more virtual machines (VMs) may also be provisioned. Other infrastructure elements, such as load balancers, databases, etc., may also be provisioned. The infrastructure will evolve over time as more infrastructure elements are required and / or added.

[0150] In some cases, intermittent deployment techniques may be employed to enable infrastructure code deployment across various virtual computing environments. In addition, the described techniques enable management of the infrastructure within these environments. In some examples, a service team may write code that requires deployment to one or more, often many, different production environments (e.g., across various different geographic locations, sometimes spanning the entire world). However, in some examples, the infrastructure onto which the code will be deployed must first be in place. In some cases, provisioning may be done manually, and once the infrastructure is provisioned, provisioning tools may be utilized to provision resources and / or development tools may be utilized to deploy the code.

[0151] FIG. 8 is a block diagram 800 illustrating an example IaaS architecture pattern according to at least one embodiment. A service operator 802 is communicatively coupled to a secured host tenancy 804. The secured host tenancy 804 may comprise a virtual cloud network (VCN) 806 and a secured host subnet 808. In some examples, the service operator 802 may employ one or more client computing devices. The client computing devices may be palm-sized portable devices (e.g., iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass head-mounted displays) that run software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 10, PalmOS, and that support internet, email, SMS (Short Message Service), Blackberry, or other communication protocols. Alternatively, the client computing devices may be general-purpose personal computers, including personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be, for example, but not limited to, workstation computers running various commercially available UNIX or UNIX-like operating systems, including various GNU / Linux operating systems such as Google Chrome OS.Alternatively or additionally, the client computing device may be a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device, or other electronic device capable of communicating over a network and / or the Internet that has access to the VCN 806.

[0152] The VCN 806 may include a Local Peering Gateway (LPG) 810. The LPG 810 may communicate with Secure Sockets Layer (SSH) via an LPG 810 included in an SSH VCN 812. SSH VCN 812 may include an SSH subnet 814, and SSH VCN 812 may be communicatively coupled to a control plane VCN 816 via an LPG 810 included in the control plane VCN 816. SSH VCN 812 may also be communicatively coupled to a data plane VCN 818 via an LPG 810. The control plane VCN 816 and the data plane VCN 818 may be included in a service tenancy 819. The service tenancy 819 may be owned and / or operated by the IaaS provider.

[0153] The control plane VCN 816 may include a control plane DMZ (Demilitarized Zone) tier 820 that functions as a perimeter network (e.g., a portion of the enterprise network between the enterprise intranet and external networks). DMZ-based server operations may be limited, which may help limit security breaches. Additionally, the DMZ tier 820 may include one or more LB (Load Balancer) subnet(s) 822, the control plane App Tier 824 may include App subnet(s) 826, and the control plane Data Tier 828 may include DB (Database) subnet(s) 830 (e.g., front-end DB subnet(s) and / or back-end DB subnet(s)). The LB subnet(s) 822 included in the control plane DMZ tier 820 can be communicatively coupled to the app subnet(s) 826 included in the control plane app tier 824 and to an internet gateway 834 that may be included in the control plane VCN 816, and the app subnet(s) 826 can be communicatively coupled to the DB subnet(s) 830 included in the control plane data tier 828 and to a service gateway 836 and a NAT (network address translation) gateway 838. The control plane VCN 816 can include the service gateway 836 and the NAT gateway 838.

[0154] The control plane VCN 816 may include a data plane mirror Aplitier 840. The data plane mirror Aplitier 840 may include app subnet(s) 826. The app subnet(s) 826 included in the data plane mirror Aplitier 840 may include a VNIC (Virtual Network Interface Controller) 842. The VNIC 842 may run a compute instance 844. The compute instance 844 may communicatively couple the app subnet(s) 826 of the data plane mirror Aplitier 840 to the app subnet(s) 826. The app subnet(s) 826 may be included in the data plane Aplitier 846.

[0155] Data plane VCN 818 may include a data plane Aplicity tier 846, a data plane DMZ tier 848, and a data plane data tier 850. Data plane DMZ tier 848 may include LB subnet(s) 822. LB subnet(s) 822 may be communicatively coupled to app subnet(s) 826 of data plane Aplicity tier 846 and to an internet gateway 834 of data plane VCN 818. App subnet(s) 826 may be communicatively coupled to a service gateway 836 of data plane VCN 818 and a NAT gateway 838 of data plane VCN 818. Data plane data tier 850 also includes DB subnet(s) 830. DB subnet(s) 830 may be communicatively coupled to app subnet(s) 826 of data plane Aplicity tier 846.

[0156] The Internet gateway 834 of the control plane VCN 816 and the Internet gateway 834 of the data plane VCN 818 can be communicatively coupled to a metadata management service 852. The metadata management service 852 provides a public interface The public internet 854 can be communicatively coupled to a NAT gateway 838 of the control plane VCN 816 and a NAT gateway 838 of the data plane VCN 818. The service gateway 836 of the control plane VCN 816 and the service gateway 836 of the data plane VCN 818 can be communicatively coupled to cloud services 856.

[0157] In some examples, the service gateway 836 of the control plane VCN 816 or the service gateway 836 of the data plan VCN 818 can make API (application programming interface) calls to the cloud service 856 without traversing the public internet 854. The API calls from the service gateway 836 to the cloud service 856 can be one-way. That is, the service gateway 836 can make an API call to the cloud service 856, and the cloud service 856 can send the requested data to the service gateway 836. However, the cloud service 856 would not initiate the API call to the service gateway 836.

[0158] In some examples, secured host subnet 804 can be directly connected to a service tenancy 819 that would otherwise be isolated. Secure host subnet 808 can communicate with SSH subnet 814 through LPG 810. LPG 810 may enable bidirectional communication through otherwise isolated systems. By connecting secured host subnet 808 to SSH subnet 814, secured host subnet 808 may be given access to other entities within service tenancy 819.

[0159] The control plane VCN 816 may enable users of the service tenancy 819 to install or provision desired resources. The desired resources provisioned in the control plane VCN 816 may be deployed or used in the data plane VCN 818. In some examples, the control plane VCN 816 may be isolated from the data plane VCN 818, and the data plane mirror Aplita 840 of the control plane VCN 816 may communicate with the data plane Aplita 846 of the data plane VCN 818 via a VNIC 842 that may be included in the data plane mirror Aplita 840 and a VNIC 842 that may be included in the data plane Aplita 846.

[0160] In some examples, a user, or customer, of the system can make a request, for example, a CRUD (Create, Read, Update, and Delete) operation, through the public internet 854. The public internet 854 can communicate the request to the metadata management service 852. The metadata management service 852 can communicate the request to the control plane VCN 816 through an internet gateway 834. The request can be received by LB subnet(s) 822 included in the control plane DMZ tier 820. The LB subnet(s) 822 can determine that the request is valid, and in response to this determination, the LB subnet(s) 822 can send the request to app subnet(s) 826 included in the control plane app tier 824. If the request is validated and requires a call to the public internet 854, the call to the public internet 854 can be sent to the NAT gateway 838, which can make the call to the public internet 854. The memory desired to be stored by the request can be stored in the DB subnet(s) 830.

[0161] In some instances, the data plane mirror ApliTia 840 may The VNIC 842 can facilitate direct communication between the control plane VCN 816 and the data plane VCN 818. For example, it may be desirable to apply configuration changes, updates, or other suitable modifications to resources included in the data plane VCN 818. Via VNIC 842, the control plane VCN 816 can make these changes, updates, or other suitable modifications to the configuration for the resources included in the data plane VCN 818 by communicating directly with those resources.

[0162] In some embodiments, the control plane VCN 816 and the data plane VCN 818 can be included in the service tenancy 819. In this case, a user or customer of the system need not own or operate either the control plane VCN 816 or the data plane VCN 818. Instead, an IaaS provider may own or operate both the control plane VCN 816 and the data plane VCN 818, which can be included in the service tenancy 819. This embodiment enables network isolation, preventing users or customers from interacting with the resources of other users or other customers. This embodiment also allows users or customers of the system to store databases privately without having to rely on the public internet 854, which may not provide the desired level of storage security.

[0163] In other embodiments, the LB subnet(s) 822 included in the control plane VCN 816 can be configured to receive signals from the service gateway 836. In this embodiment, the control plane VCN 816 and the data plane VCN 818 can be configured by the IaaS provider's customers to be called without calling the public internet 854. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and stored in the service tenancy 819, isolated from the public internet 854.

[0164] FIG. 9 is a block diagram 900 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., service operator 802 of FIG. 8 ) can be communicatively coupled to a secured host tenancy 904 (e.g., secured host tenancy 804 of FIG. 8 ). Secured host tenancy 904 can comprise a VCN (Virtual Cloud Network) 906 (e.g., VCN 806 of FIG. 8 ) and a secured host subnet 908 (e.g., secured host subnet 808 of FIG. 8 ). VCN 906 can comprise an LPG (Local Peering Gateway) 910 (e.g., LPG 810 of FIG. 8 ). LPG 910 can be communicatively coupled to an SSH (Secure Shell) VCN 912 (e.g., SSH VCN 812 of FIG. 8 ) via LPG 810 included in SSH VCN 912. SSH VCN 912 can include an SSH subnet 914 (e.g., SSH subnet 814 in FIG. 8 ), which can be communicatively coupled to a control plane VCN 916 (e.g., control plane VCN 816 in FIG. 8 ) via an LPG 910 included in the control plane VCN 916. The control plane VCN 916 can be included in a service tenancy 919 (e.g., service tenancy 819 in FIG. 8 ), and the data plane VCN 918 (e.g., data plane VCN 818 in FIG. 8 ) can be included in a customer tenancy 921, which can be owned or operated by a user or customer of the system.

[0165] The control plane VCN 916 may include a control plane DMZ tier 920 (e.g., control plane DMZ tier 820 in FIG. 8 ), which may include LB subnet(s) 922 (e.g., LB subnet(s) 822 in FIG. 8 ), and app subnet(s) 926 (e.g., app subnet(s) 826 in FIG. 8 ). The control plane DMZ tier 920 may comprise a control plane Aplicity tier 924 (e.g., control plane Aplicity tier 824 in FIG. 8 ) that includes a DB (database) subnet(s) 930 (e.g., similar to DB subnet(s) 830 in FIG. 8 ), and a control plane data tier 928 (e.g., control plane data tier 828 in FIG. 8 ). The LB subnet(s) 922 included in the control plane Aplicity tier 924 may be communicatively coupled to app subnet(s) 926 included in the control plane Aplicity tier 924 and to an internet gateway 934 (e.g., internet gateway 834 in FIG. 8 ) that may be included in the control plane VCN 916, and the app subnet(s) 926 may be communicatively coupled to DB subnet(s) 930 included in the control plane data tier 928, to a service gateway 936 (e.g., service gateway in FIG. 8 ), and to a NAT (network address translation) gateway 938 (e.g., NAT gateway 838 in FIG. 8 ). The control plane VCN 916 may include a service gateway 936 and a NAT gateway 938 .

[0166] The control plane VCN 916 may include a data plane mirror Apri tier 940 (e.g., data plane mirror Apri tier 840 of FIG. 8 ). The data plane mirror Apri tier 940 may include app subnet(s) 926. The app subnet(s) 926 included in the data plane mirror Apri tier 940 may include VNICs (Virtual Network Interface Controllers) 942 (e.g., VNICs of 842) on which compute instances 944 can run (e.g., similar to compute instances 844 of FIG. 8 ). The compute instances 944 can facilitate communication between the app subnet(s) 926 of the data plane mirror Apri tier 940 and the app subnet(s) 926 that may be included in the data plane Apri tier 946 (e.g., data plane Apri tier 846 of FIG. 8 ) via the VNICs 942 included in the data plane mirror Apri tier 940 and the VNICs 942 included in the data plane Apri tier 946.

[0167] An internet gateway 934 included in the control plane VCN 916 can be communicatively coupled to a metadata management service 952 (e.g., metadata management service 852 in FIG. 8 ). The metadata management service 952 can be communicatively coupled to the public internet 954 (e.g., public internet 854 in FIG. 8 ). The public internet 954 can be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916. A service gateway 936 included in the control plane VCN 916 can be communicatively coupled to cloud services 956 (e.g., cloud services 856 in FIG. 8 ).

[0168] In some examples, the data plane VCN 918 can be included in the customer tenancy 921. In this case, the IaaS provider may provide a control plane VCN 916 for each customer, and the IaaS provider may install a unique compute instance 944 for each customer, which is included in the service tenancy 919. Each compute instance 944 may enable communication between the control plane VCN 916 included in the service tenancy 919 and the data plane VCN 918 included in the customer tenancy 921. The compute instance 944 enables resources provisioned in the control plane VCN 916 included in the service tenancy 919 to be deployed or used in the data plane VCN 918 included in the customer tenancy 921.

[0169] In another example, the IaaS provider's customers are housed in customer tenancy 921. In this example, the control plane VCN 916 can include a data plane mirror Apulitia 940, which can include app subnet(s) 926. The data plane mirror Apulitia 940 can reside in the data plane VCN 918, but the data plane mirror Apulitia 940 need not be housed in the data plane VCN 918. That is, the data plane mirror Apulitia 940 may have access to the customer tenancy 921, but the data plane mirror Apulitia 940 may not reside in the data plane VCN 918 or be owned or operated by the IaaS provider's customer. The data plane mirror Apulitia 940 need only be configured to call the data plane VCN 918, but not to call entities contained in the control plane VCN 916. A customer may wish to deploy or use resources in the data plane VCN 918 that are provisioned in the control plane VCN 916, and the data plane mirror Apulitia 940 can facilitate the customer's desired deployment or use of the resources.

[0170] In some embodiments, an IaaS provider's customers can apply filters to data plane VCNs 918. In this embodiment, the customer can determine which data plane VCNs 918 are accessible, and the customer may restrict access from the data plane VCNs 918 to the public internet 954. The IaaS provider may not be able to apply filters or control the data plane VCNs 918's access to any external networks or databases. Customer filtering and control of the data plane VCNs 918 included in the customer tenancy 921 can help isolate the data plane VCNs 918 from other customers and the public internet 954.

[0171] In some embodiments, cloud services 956 can be invoked through service gateway 936 to access services that may not reside on the public internet 954, control plane VCN 916, or data plane VCN 918. The connection between cloud services 956 and control plane VCN 916 or data plane VCN 918 may be disjoint or continuous. Cloud services 956 may reside on different networks owned or operated by the IaaS provider. Cloud services 956 may be configured to receive calls from service gateway 936 and may not be configured to receive calls from the public internet 954. Cloud services 956 may be isolated from other cloud services 956, and control plane VCN 916 may be isolated from cloud services 956 that are not in the same region as control plane VCN 916. For example, control plane VCN 916 may be located in "Region 1," and cloud service "Deployment 8" may be located in Region 1 and Region 2. If a call to deployment 8 is made by service gateway 936 included in control plane VCN 916 located in region 1, the call may be sent to deployment 8 in region 1. In this example, control plane VCN 916, or deployment 8 in region 1, may not be communicatively coupled to or in communication with deployment 8 in region 2.

[0172] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1002 (e.g., service operator 802 of FIG. 8) can be communicatively coupled to a secured host tenancy 1004 (e.g., secured host tenancy 804 of FIG. 8). Secured host tenancy 1004 can be connected to a virtual cloud network (VCN). 8 ) and a secure host subnet 1008 (e.g., secure host subnet 808 in FIG. 8 ). VCN 1006 can include an LPG 1010 (e.g., LPG 810 in FIG. 8 ) that can be communicatively coupled to an SSH VCN 1012 (e.g., SSH VCN 812 in FIG. 8 ) via an LPG 1010 included in SSH VCN 1012. SSH VCN 1012 can include an SSH subnet 1014 (e.g., SSH subnet 814 in FIG. 8 ), which can be communicatively coupled to a control plane VCN 1016 (e.g., control plane VCN 816 in FIG. 8 ) via an LPG 1010 included in control plane VCN 1016, and to a data plane VCN 1018 (e.g., data plane 818 in FIG. 8 ) via an LPG 1010 included in data plane VCN 1018. The control plane VCN 1016 and the data plane VCN 1018 can be included in a service tenancy 1019 (e.g., service tenancy 819 in FIG. 8).

[0173] The control plane VCN 1016 may include a control plane DMZ tier 1020 (e.g., control plane DMZ tier 820 in FIG. 8 ) that may include LB (load balancer) subnet(s) 1022 (e.g., LB subnet(s) 822 in FIG. 8 ), a control plane Aplicity tier 1024 (e.g., control plane Aplicity tier 824 in FIG. 8 ) that may include app subnet(s) 1026 (e.g., similar to app subnet(s) 826 in FIG. 8 ), and a control plane data tier 1028 (e.g., control plane data tier 828 in FIG. 8 ) that may include DB subnet(s) 1030. The LB subnet(s) 1022 included in the control plane DMZ tier 1020 can be communicatively coupled with app subnet(s) 1026 included in the control plane app tier 1024 and can be communicatively coupled with an Internet gateway 1034 (e.g., Internet gateway 834 in FIG. 8 ) that can be included in the control plane VCN 1016, and the app subnet(s) 1026 can be communicatively coupled with DB subnet(s) 1030 included in the control plane data tier 1028 and can be communicatively coupled with a service gateway 1036 (e.g., service gateway in FIG. 8 ) and a NAT (Network Address Translation) gateway 1038 (e.g., NAT gateway 838 in FIG. 8 ). The control plane VCN 1016 can include the service gateway 1036 and the NAT gateway 1038.

[0174] The data plane VCN 1018 may comprise a data plane Apli tier 1046 (e.g., data plane Apli tier 846 in FIG. 8 ), a data plane DMZ tier 1048 (e.g., data plane DMZ tier 848 in FIG. 8 ), and a data plane data tier 1050 (e.g., data plane data tier 850 in FIG. 8 ). The data plane DMZ tier 1048 may comprise LB subnet(s) 1022. The LB subnet(s) 1022 may be communicatively coupled to trusted app subnet(s) 1060 and untrusted app subnet(s) 1062 of the data plane Apli tier 1046, and may be communicatively coupled to an Internet gateway 1034 included in the data plane VCN 1018. The trusted app subnet(s) 1060 can be communicatively coupled to the service gateway 1036 included in the data plane VCN 1018, the NAT gateway 1038 included in the data plane VCN 1018, and the DB subnet(s) 1030 included in the data plane data tier 1050. The untrusted app subnet(s) 1062 can be communicatively coupled to the service gateway 1036 included in the data plane VCN 1018 and the DB subnet(s) 1030 included in the data plane data tier 1050. The data plane data tier 1050 may include the DB subnet(s) 1030. The DB subnet 1030 can be communicatively coupled to a service gateway 1036 included in the data plane VCN 1018.

[0175] The untrusted app subnet(s) 1062 can have one or more primary VNICs 1064(1)-(N). The VNICs 1064(1)-(N) can be communicatively coupled to tenant virtual machines (VMs) 1066(1)-(N). Each tenant VM 1066(1)-(N) can be communicatively coupled to a respective app subnet 1067(1)-(N). The app subnets 1067(1)-(N) can be included in respective container egress VCNs 1068(1)-(N). The container egress VCNs 1068(1)-(N) can be included in respective customer tenancies 1070(1)-(N). Each auxiliary VNIC 1072(1)-(N) can facilitate communication between the untrusted app subnet(s) 1062 included in the data plane VCN 1018 and the app subnet(s) included in the container egress VCN 1068(1)-(N). Each container egress VCN 1068(1)-(N) can include a NAT gateway 1038 that can be communicatively coupled to the public internet 1054 (e.g., public internet 854 in FIG. 8 ).

[0176] The internet gateway 1034 included in the control plane VCN 1016 and the internet gateway 1034 included in the data plane VCN 1018 can be communicatively coupled to a metadata management service 1052 (e.g., metadata management system 852 of FIG. 8 ). The metadata management service 1052 can be communicatively coupled to the public internet 1054. The public internet 1054 can be communicatively coupled to a NAT gateway 1038 included in the control plane VCN 1016 and the NAT gateway 1038 included in the data plane VCN 1018. The service gateway 1036 included in the control plane VCN 1016 and the service gateway 1036 included in the data plane VCN 1018 can be communicatively coupled to cloud services 1056.

[0177] In some embodiments, the data plane VCN 1018 can be integrated with the customer tenancy 1070. This integration may be useful or desirable for an IaaS provider's customer in some cases, such as when they want support when running code. A customer may provide code for execution that may be destructive, communicate with other customer resources, or cause undesirable effects. Accordingly, the IaaS provider may determine whether to run code that the customer has provided to the IaaS provider.

[0178] In some examples, an IaaS provider's customer may request temporary network access from the IaaS provider for the ability to attach to a data plane tier app 1046. The code to perform this function may run in a VM 1066(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 1018. Each VM 1066(1)-(N) may be connected to one customer tenancy 1070. Each container 1071(1)-(N) contained in a VM 1066(1)-(N) may be configured to run this code. In this case, there may be two levels of isolation (e.g., containers 1071(1)-(N) may be running code contained in at least one VM 1066(1)-(N) contained in the untrusted app subnet(s) 1062). The two levels of isolation may help prevent erroneous or unwanted code from damaging the IaaS provider's network or from damaging a different customer's network. The containers 1071(1)-(N) may be communicatively coupled to the customer tenancy 1070 and may be configured to send or receive data from the customer tenancy 1070. Containers 1071(1)-(N) may not be configured to send or receive data from other entities in data plane VCN 1018. Once the code execution is complete, the IaaS provider may kill or discard containers 1071(1)-(N).

[0179] In some embodiments, trusted app subnet(s) 1060 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet(s) 1060 may be communicatively coupled to DB subnet(s) 1030 and may be configured to perform CRUD operations on DB subnet(s) 1030. Untrusted app subnet(s) 1062 may be communicatively coupled to DB subnet(s) 1030, although in this embodiment, the untrusted app subnet(s) may be configured to perform read operations on DB subnet(s) 1030. Containers 1071(1)-(N) that may be included in each customer's VMs 1066(1)-(N) and that may execute code from the customer may not be communicatively coupled to DB subnet(s) 1030.

[0180] In other embodiments, the control plane VCN 1016 and the data plane VCN 1018 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 1016 and the data plane VCN 1018. However, communication may occur indirectly through at least one method. The LPG 1010 may be established by an IaaS provider that can facilitate communication between the control plane VCN 1016 and the data plane VCN 1018. In another example, the control plane VCN 1016 or the data plane VCN 1018 can invoke a cloud service 1056 via the service gateway 1036. For example, a call from the control plane VCN 1016 to the cloud service 1056 can include a request for a service that can communicate with the data plane VCN 1018.

[0181] FIG. 11 is a block diagram 1100 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service operator 1102 (e.g., service operator 802 in FIG. 8 ) can be communicatively coupled to a secured host tenancy 1104 (e.g., secured host tenancy 804 in FIG. 8 ). Secured host tenancy 1104 can include a virtual cloud network (VCN) 1106 (e.g., VCN 806 in FIG. 8 ) and a secured host subnet 1108 (e.g., secured host subnet 808 in FIG. 8 ). VCN 1106 can include an LPG 1110 (e.g., LPG 810 in FIG. 8 ) that can be communicatively coupled to an SSH VCN 1112 (e.g., SSH VCN 812 in FIG. 8 ) via an LPG 1110 included in SSH VCN 1112. SSH VCN 1112 can include SSH subnet 1114 (e.g., SSH subnet 814 in FIG. 8 ), which can be communicatively coupled to control plane VCN 1116 (e.g., control plane VCN 816 in FIG. 8 ) via LPG 1110 included in control plane VCN 1116, and to data plane VCN 1118 (e.g., data plane 818 in FIG. 8 ) via LPG 1110 included in data plane VCN 1118. Control plane VCN 1116 and data plane VCN 1118 can be included in service tenancy 1119 (e.g., service tenancy 819 in FIG. 8 ).

[0182] The control plane VCN 1116 includes a control plane DMZ tier 1120 (e.g., control plane DMZ tier 820 in FIG. 8) that can include LB subnet(s) 1122 (e.g., LB subnet(s) 822 in FIG. 8), and app subnet(s) 1126 (e.g., app subnet(s) 10). The LB subnet(s) 1122 included in the control plane DMZ tier 1120 can be communicatively coupled with the app subnet(s) 1126 included in the control plane app tier 1124 and can be communicatively coupled with an Internet gateway 1134 (e.g., Internet gateway 834 in FIG. 8 ) that can be included in the control plane VCN 1116, and the app subnet(s) 1126 can be communicatively coupled with the DB subnet(s) 1130 included in the control plane data tier 1128 and can be communicatively coupled with a service gateway 1136 (e.g., service gateway in FIG. 8 ) and a NAT (Network Address Translation) gateway 1138 (e.g., NAT gateway 838 in FIG. 8 ). The control plane VCN 1116 can include the service gateway 1136 and the NAT gateway 1138.

[0183] Data plane VCN 1118 may comprise a data plane Apli tier 1146 (e.g., data plane Apli tier 846 in FIG. 8 ), a data plane DMZ tier 1148 (e.g., data plane DMZ tier 848 in FIG. 8 ), and a data plane data tier 1150 (e.g., data plane data tier 850 in FIG. 8 ). Data plane DMZ tier 1148 may comprise LB subnet(s) 1122. LB subnet(s) 1122 may be communicatively coupled to trusted app subnet(s) 1160 (e.g., trusted app subnet(s) 1060 in FIG. 10 ) and untrusted app subnet(s) 1162 (e.g., untrusted app subnet(s) 1062 in FIG. 10 ) of data plane Apli tier 1146, and may be communicatively coupled to an Internet gateway 1134 included in data plane VCN 1118. Trusted app subnet(s) 1160 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118, a NAT gateway 1138 included in the data plane VCN 1118, and DB subnet(s) 1130 included in the data plane data tier 1150. Untrusted app subnet(s) 1162 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118 and DB subnet(s) 1130 included in the data plane data tier 1150. Data plane data tier 1150 may include DB subnet(s) 1130. DB subnet(s) 1130 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118.

[0184] The untrusted app subnet(s) 1162 may include primary VNICs 1164(1)-(N). The VNICs 1164(1)-(N) may be communicatively coupled to tenant VMs (virtual machines) 1166(1)-(N) present in the untrusted app subnet(s) 1162. Each tenant VM 1166(1)-(N) may execute code in a respective container 1167(1)-(N) and may be communicatively coupled to the app subnet 1126. The app subnet 1126 may be included in a data plane Apli tier 1146. The data plane Apli tier 1146 may be included in a container egress VCN 1168. Each auxiliary VNIC 1172(1)-(N) may facilitate communication between the untrusted app subnet(s) 1162 included in the data plane VCN 1118 and the app subnet included in the container egress VCN 1168. The container egress VCN 1168 may include a NAT gateway 1138 that may be communicatively coupled to the public internet 1154 (e.g., public internet 854 in FIG. 8).

[0185] The internet gateway 1134 included in the control plane VCN 1116 and the internet gateway 1134 included in the data plane VCN 1118 can be communicatively coupled to a metadata management service 1152 (e.g., metadata management system 852 of FIG. 8 ). The metadata management service 1152 can be communicatively coupled to the public internet 1154. The public internet 1154 can be communicatively coupled to a NAT gateway 1138 included in the control plane VCN 1116 and the NAT gateway 1138 included in the data plane VCN 1118. The service gateway 1136 included in the control plane VCN 1116 and the service gateway 1136 included in the data plane VCN 1118 can be communicatively coupled to cloud services 1156.

[0186] In some examples, the pattern illustrated by the architecture of block diagram 1100 in FIG. 11 may be considered an exception to the pattern illustrated by the architecture of block diagram 1000 in FIG. 10 , and the pattern illustrated by the architecture of block diagram 1100 may be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customers (e.g., because regions are isolated). Each container 1167(1)-(N) contained in a VM 1166(1)-(N) for each customer can be accessed by the customer in real time. The containers 1167(1)-(N) can be configured to call each auxiliary VNIC 1172(1)-(N) contained in app subnet(s) 1126 of the data plane app tier 1146, which can be included in a container egress VCN 1168. The auxiliary VNICs 1172(1)-(N) can send the call to a NAT gateway 1138. The NAT gateway 1138 can send the call to the public Internet 1154. In this example, containers 1167(1)-(N) that customers can access in real time can be isolated from the control plane VCN 1116 and can be isolated from other entities included in the data plane VCN 1118. Containers 1167(1)-(N) can also be isolated from other customer resources.

[0187] In another example, a customer can invoke cloud service 1156 using containers 1167(1)-(N). In this example, the customer can execute code in containers 1167(1)-(N) that requests a service from cloud service 1156. Containers 1167(1)-(N) can send the request to auxiliary VNICs 1172(1)-(N). Auxiliary VNICs 1172(1)-(N) can send the request to a NAT gateway. The NAT gateway can send the request to public Internet 1154. Public Internet 1154 can send the request to LB subnet(s) 1122 included in control plane VCN 1116 via Internet gateway 1134. In response to determining that the request is valid, the LB subnet(s) can send the request to app subnet(s) 1126. The app subnet(s) 1126 can send the request to cloud service 1156 via service gateway 1136.

[0188] It should be understood that the illustrated IaaS architectures 800, 900, 1000, 1100 may have components other than those shown. Additionally, the illustrated embodiments are only a few examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS system may have more components than those shown, fewer components than those shown, a combination of two or more components, or a different configuration or arrangement of components.

[0189] In certain embodiments, self-service, subscription-based elastically scheduled An IaaS system may include a suite of application, middleware, and database service offerings delivered to customers in a stable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the assignee of this application.

[0190] 12 illustrates an example computer system 1200 on which various embodiments of the present disclosure may be implemented. System 1200 may be used to implement any of the computer systems described above. As shown, computer system 1200 includes a processing unit 1204 that communicates with several peripheral subsystems via a bus subsystem 1202. These peripheral subsystems may include a processing acceleration unit 1206, an I / O subsystem 1208, a storage subsystem 1218, and a communication subsystem 1224. Storage subsystem 1218 includes a tangible computer-readable storage medium 1222 and a system memory 1210.

[0191] Bus subsystem 1202 provides a mechanism for allowing the various components and subsystems of computer system 1200 to communicate with each other as intended. While bus subsystem 1202 is illustrated as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1202 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using various bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a Mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0192] Processing unit 1204, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 1200. Processing unit 1204 may include one or more processors. These processors may include single-core or multi-core processors. In particular embodiments, processing unit 1204 may be implemented as one or more independent processing units 1232 and / or 1234, each including a single-core or multi-core processor. In other embodiments, processing unit 1204 may be implemented as a quad-core processing unit formed by incorporating two dual-core processors on a single chip.

[0193] In various embodiments, processing unit 1204 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any time, some or all of the program code being executed may reside in processor(s) 1204 and / or in storage subsystem 1218. With appropriate programming, processor(s) 1204 may provide the various functions described above. Computer system 1200 may further include a processing acceleration unit 1206. Processing acceleration unit 1206 may include a digital signal processor (DSP) and / or a special purpose processor, etc.

[0194] The I / O subsystem 1208 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or a display. The user interface input devices may include touchscreens, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. The user interface input devices may also include motion sensing and / or gesture recognition devices, such as a Microsoft Kinect® motion sensor, which allows a user to control and interact with input devices such as a Microsoft Xbox® 360 game controller through a natural user interface using gesture and voice commands. The user interface input devices may also include eye gesture recognition devices, such as a Google Glass® blink detector, which detects a user's eye behavior (e.g., "blinking" while taking a photo and / or making a menu selection) and translates the eye gestures into input for an input device (e.g., Google Glass®). Additionally, the user interface input devices may include voice recognition sensing devices, which allow a user to interact with a voice recognition system (e.g., Siri® Navigator) through voice commands.

[0195] User interface input devices also include, but are not limited to, 3D (three-dimensional) mice, joysticks or pointing sticks, game pads, and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices, such as computed tomography, magnetic resonance imaging, positron emission tomography, and ultrasound devices. User interface input devices may also include audio input devices, such as MIDI keyboards and digital musical instruments.

[0196] User interface output devices may include display subsystems, indicator lights, or non-visual display devices such as audio output devices. The display subsystem may be a flat-panel display such as one using a CRT (cathode ray tube), LCD (liquid crystal display), or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all manner of devices and mechanisms for outputting information from computer system 1200 to a user or to another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey textual, graphical, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, drawing devices, audio output devices, and modems.

[0197] Computer system 1200 may be configured with a storage subsystem 1218 that includes software elements that are illustrated as currently residing in system memory 1210. System memory 1210 may store program instructions that are loadable and executable on processing unit 1204, as well as data generated during the execution of these programs.

[0198] Depending on the configuration and type of computer system 1200, system memory 1210 may be volatile memory (such as RAM (random access memory)) and / or non-volatile memory (such as ROM (read only memory), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by the processing unit 1204. In some implementations, system memory 1210 may include multiple different types of memory, such as SRAM (static RAM) or DRAM (dynamic RAM). In some implementations, essential components within computer system 1200, such as during startup, may be accessed by the processing unit 1204. A Basic Input / Output System (BIOS), containing the basic routines that help transfer information between components, may typically be stored in ROM. Also, by way of example, system memory 1210 includes application programs 1212, which may include client applications, a web browser, mid-tier applications, a relational database management system (RDBMS), etc., program data 1214, and operating system 1216. By way of example, operating system 1216 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 12 OS, and Palm® OS operating systems.

[0199] Storage subsystem 1218 may also provide a tangible, computer-readable storage medium for storing basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above may be stored in storage subsystem 1218. These software modules or instructions may be executed by processing unit 1204. Storage subsystem 1218 may also provide a repository for storing data used in accordance with the present disclosure.

[0200] Storage subsystem 1200 may also include a computer-readable storage medium reader 1220 that may be further coupled to a computer-readable storage medium 1222. In conjunction with system memory 1210, and optionally in combination with system memory 1210, computer-readable storage medium 1222 may comprehensively represent remote, local, fixed, and / or removable storage devices, as well as storage media for containing, storing, transmitting, and retrieving computer-readable information on a temporary and / or more permanent basis.

[0201] The computer-readable storage medium 1222 containing the code or portions of code may include any suitable medium known or used in the art, including, but not limited to, storage and communication media, such as volatile and nonvolatile, removable and non-removable media, implemented in any method and technology for storing and / or transmitting information. This may include tangible computer-readable storage media, such as RAM, ROM, EEPROM (Electronically Erasable Programmable ROM), flash memory, or other memory technology, CD-ROM, DVD (Digital Versatile Disk), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage, or other tangible computer-readable media. This may also include intangible computer-readable media, such as data signals, data transmissions, or other media that can be used to transmit the desired information and that can be accessed by computing system 1200.

[0202] By way of example, computer-readable storage medium 1222 may include hard disk drives that read from or write to fixed, nonvolatile magnetic media, magnetic disk drives that read from or write to removable, nonvolatile magnetic disks, and optical disk drives that read from or write to removable, nonvolatile optical disks or other optical media, such as CD-ROMs, DVDs, and Blu-Ray® disks. The computer-readable storage medium 1222 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer-readable storage medium 1222 may also include solid-state drives (SSDs) based on non-volatile memory, such as flash memory-based solid-state drives (SSDs), enterprise flash drives, and solid-state ROM; volatile memory-based SSDs, such as solid-state RAM, dynamic RAM, static RAM, and DRAM-based SSDs; magnetoresistive RAM (MRAM) SSDs; and hybrid SSDs that use SSDs based on a combination of DRAM and flash memory. These disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1200.

[0203] The communications subsystem 1224 provides an interface to other computer systems and networks. The communications subsystem 1224 serves as an interface for receiving data from the computer system 1200 and transmitting data from the computer system 1200 to other systems. For example, the communications subsystem 1224 may enable the computer system 1200 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 1224 may include a Radio Frequency (RF) transceiver component, a Global Positioning System (GPS) receiver component, and / or other components for accessing a wireless voice or / and / or data network (e.g., using cellular technology, next-generation data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates For Global Evolution), WiFi (IEEE 802.28 family of standards), other mobile communications technologies, or any combination thereof). In some embodiments, the communications subsystem 1224 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0204] In some embodiments, the communications subsystem 1224 may receive incoming communications in the form of structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc., on behalf of one or more users who may utilize the computer system 1200.

[0205] As an example, the communications subsystem 1224 may be configured to receive data feeds 1226 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, RSS (Rich Site Summary) feeds, and / or real-time updates from one or more third-party information sources.

[0206] Additionally, the communications subsystem 1224 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1228 of real-time events and / or event updates 1230 that has essentially no apparent end, that is continuous or infinite. Applications that generate continuous data may include, for example, sensor data applications, tickers, network performance measurement tools (e.g., network monitoring and traffic monitoring applications), and the like. Examples of such applications include: traffic management applications, clickstream analysis tools, and automobile traffic monitoring.

[0207] Communications subsystem 1224 may also be configured to output structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc. to one or more databases that may be in communication with one or more streaming data source computers connected to computer system 1200.

[0208] The computer system 1200 may be one of a variety of types, including a palm-sized portable device (e.g., an iPhone® mobile phone, an IPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or other data processing system.

[0209] Due to the ever-changing nature of computers and networks, the illustrated description of computer system 1200 is illustrative only. Many other configurations are possible having more or fewer components than the illustrated system. For example, customized hardware may be used, and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Furthermore, connection to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods for implementing various embodiments.

[0210] While specific embodiments of the present disclosure have been described, various modifications, substitutions, alternative configurations, and equivalents are encompassed within the scope of the present disclosure. The embodiments of the present disclosure are not limited to operation in a particular data processing environment, but can freely operate in multiple data processing environments. Additionally, while the embodiments of the present disclosure have been described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described sequence of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0211] Furthermore, while embodiments of the present disclosure have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments of the present disclosure may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. Various processes described herein may be implemented on the same processor or on any combination of different processors. Thus, where a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform the operation, by programming a programmable electronic circuit (e.g., a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using various techniques, including, but not limited to, conventional techniques for inter-process communication; different paired processes may use different techniques, and the same pair of processes may use different techniques at different times.

[0212] The specification and drawings are to be regarded appropriately as illustrative rather than strict, but additions, subtractions, deletions and other modifications and alterations may be made thereto without departing from the broader spirit and scope of the appended claims. It will be apparent that various modifications and equivalents may be made to the disclosed embodiments. Accordingly, while specific embodiments of the disclosure have been described, they are not limiting. Various modifications and equivalents are intended to be encompassed within the scope of the appended claims.

[0213] In the context of describing the disclosed embodiments (particularly in the context of the appended claims), the use of the terms "a," "an," and "the," and terms of similar referents, should be construed to include both the singular and the plural, unless inconsistent. The terms "comprising," "having," "including," and "containing" should be construed as open-ended terms (i.e., meaning "including, but not limited to"), unless otherwise noted. The term "connected" should be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values ​​herein is merely a shorthand means of referring individually to each individual value within the range, unless otherwise indicated herein, and each individual value is included in the specification as if it were individually set forth. All methods described herein can be performed in any suitable order, unless inconsistent. Any examples or exemplary language (e.g., "such as") provided herein are merely intended to better shed light on embodiments of the present disclosure and do not limit the scope of the present disclosure unless specifically claimed. No language in the present specification should be construed as indicating any non-claimed element as essential to the practice of the present disclosure.

[0214] Disjunctive language, such as the phrase "at least one of X, Y, or Z," should be understood to be within the scope of common usage to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically indicated otherwise. Thus, such disjunctive language is generally not intended to imply that a particular embodiment requires, and does not require, at least one of X, at least one of Y, or at least one of Z.

[0215] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art will be able to employ such variations as appropriate, and the present disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Additionally, any combination of the above-described elements in any possible variations thereof is included in this disclosure, unless expressly indicated herein.

[0216] All references, including publications, patent applications, and patents, cited in this specification are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.

[0217] While aspects of the disclosure have been described in the foregoing specification with reference to specific embodiments thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Moreover, embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and accompanying drawings are therefore to be regarded as illustrative rather than limiting.

Claims

1. 1. A method comprising: The method includes a step of providing a plurality of honeypot servers, the computing system including an Infrastructure as a Service (IaaS) computing instance associated with an IaaS provider, each honeypot server included in the plurality of honeypot servers including a honeypot type, the method further comprising: receiving, by the computing system, a first request from an attacker, the first request being associated with a characteristic of a particular honeypot type; the computing system establishing a session with the attacker to connect to a particular honeypot server of the particular honeypot type; causing the particular honeypot server of the computing system to communicate a response to the first request to the attacker; the computing system recording at least one of data regarding the attacker and data regarding one or more interactions between the attacker and the particular honeypot server; generating a response to a second request from the attacker by the particular honeypot server of the computing system, wherein the IaaS computing instance is run by a third-party service provider outside of an IaaS service provider environment, and the response to the second request is configured to appear to be a response from the IaaS provider; the second request is for instantiation of the IaaS computing instance; wherein the response to the second request indicates that the IaaS computing instance was successfully instantiated.

2. The method of claim 1 , further comprising the step of: the computing system luring the attacker into establishing a session with at least one honeypot server of the plurality of honeypot servers.

3. 3. The method of claim 2, wherein the luring includes exposing one or more ports to a public network, the one or more ports including at least one of a Secure Shell (SSH) port 22, a File Transfer Protocol (FTP) port 21, or a Simple Mail Transfer Protocol (SMTP) port 25.

4. 3. The method of claim 1, further comprising: the computing system identifying the particular honeypot server from the plurality of honeypot servers based at least in part on characteristics of the first request and the honeypot type.

5. The method of any one of claims 1 to 4, wherein the attacker is a user using an application to generate at least one of the first request or the second request.

6. 1. A system comprising: one or more processors; and a non-transitory computer-readable memory containing instructions that, when executed by the one or more processors, cause the system to perform operations, including: a computing system providing a plurality of honeypot servers, the computing system including an Infrastructure as a Service (IaaS) computing instance associated with an IaaS provider, each honeypot server included in the plurality of honeypot servers including a honeypot type; and the operation further comprising: receiving, by the computing system, a first request from an attacker, the first request associated with a characteristic of a particular honeypot type; the computing system establishing a session with the attacker to connect to a particular honeypot server of the particular honeypot type; causing the particular honeypot server of the computing system to communicate a response to the first request to the attacker; the computing system recording at least one of data regarding the attacker and data regarding one or more interactions between the attacker and the particular honeypot server; generating a response to a second request from the attacker, the particular honeypot server of the computing system, wherein the IaaS computing instance is run by a third-party service provider outside of an IaaS service provider environment, and the response to the second request is configured to appear to be a response from the IaaS provider; the second request is for instantiation of the IaaS computing instance; The response to the second request indicates that the IaaS computing instance was successfully instantiated.

7. The system of claim 6 , further comprising the computing system luring the attacker into establishing a session with at least one honeypot server of the plurality of honeypot servers.

8. 8. The system of claim 7, wherein the luring includes exposing one or more ports to a public network, the one or more ports including at least one of a Secure Shell (SSH) port 22, a File Transfer Protocol (FTP) port 21, or a Simple Mail Transfer Protocol (SMTP) port 25.

9. The system of any one of claims 6 to 8, further comprising: the computing system identifying the particular honeypot server from the plurality of honeypot servers based at least in part on characteristics of the first request and the honeypot type.

10. The system of any one of claims 6 to 9, wherein the attacker is a user using an application to generate at least one of the first request or the second request.

11. A computer readable program for causing one or more processors to carry out the method of any one of claims 1 to 5.

Images