Honeypot for protecting the security of infrastructure as a service

Abstract

To provide a method for using a honeypot to lure attackers and collecting data about attack patterns against IaaS (Infrastructure-as-a-Service) instances.SOLUTION: When a honeypot server receives a request about an IaaS instance from an attacker, the honeypot server generates a response to the request, and communicates the response to the attacker in response to the request. In addition, the honeypot server records data regarding the attacker and data regarding one or more interactions by the attacker with the honeypot server.SELECTED DRAWING: Figure 4

Description

Technical Field

[0003] ,

[0001] Cross - Reference to Related Applications This application claims the benefit and priority of U.S. Application No. 62 / 895,847, filed on September 4, 2019, entitled "HONEYPOTS FOR INFRASTRUCTURE - AS - A - SERVICE SECURITY", and U.S. Application No. 17 / 009,634, filed on September 1, 2020, entitled "HONEYPOTS FOR INFRASTRUCTURE - AS - A - SERVICE SECURITY", under 35 U.S.C. § 119(e), and incorporates by reference all of their descriptions herein for all purposes.

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

Background Art

[0003] Background Cloud-based services (such as SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), and IaaS (Infrastructure-as-a-Service)) are rapidly increasing in popularity, and more organizations (such as companies, corporations, government agencies, and educational institutions) are subscribing to cloud services provided by cloud service providers to conduct critical business operations. As the number of products offered by these clouds increases, cloud service providers are facing increased security threats from malicious user attacks on the infrastructure that provides the cloud services. Cloud service subscribers (such as organizations) are also negatively affected by these attacks. Being able to identify and prevent such attacks will be of greatest benefit to both subscribers and cloud service providers.

[0004] However, with regard to cloud products, it is often unclear how attacks occur and / or how to prevent them. This is because cloud security is a relatively new type of security, in contrast to traditional network and / or device-level security. Existing cloud security solutions are very basic and inherently reactive; that is, they think about how to deal with an attack after it has occurred.

[0005] Early cloud attacks targeted instances providing SaaS and PaaS services, but more recently, as more computing networks, storage networks, and virtual networks are abstracted into the cloud and exposed through various IaaS instances, attacks on IaaS instances are increasing. For example, with the rise of cryptocurrencies like Bitcoin, computing attacks on IaaS instances have increased as more computing, storage, and network resources are required for cryptocurrency mining (e.g., Bitcoin mining). IaaS instances are increasingly being attacked to "steal" grid resources, memory resources, and network resources. Compared to SaaS and PaaS attacks, IaaS attacks are still not well understood. [Overview of the project] [Means for solving the problem]

[0006] overview This disclosure relates to computer security, and in particular to techniques for using honeypots to lure attackers and collect data on attack patterns against IaaS (Infrastructure-as-a-Service) instances. The collected data can then be analyzed and used to prevent such attacks. Various embodiments, including methods, systems, and non-temporary computer-readable storage media for storing programs, code, or instructions executable by one or more processors, are described herein.

[0007] In certain embodiments, a technique is provided to lure an attacker and establish a session with a honeypot server. The honeypot server receives requests from the attacker regarding IaaS instances (Infrastructure-as-a-Service instances). The honeypot server generates a response to the request and, as requested, communicates this response to the attacker. The honeypot server also records data about the attacker and data about one or more interactions the attacker has with the honeypot server. In some embodiments, a network consisting of honeypot servers (also referred to as a honeynet) may be provided.

[0008] As part of processing requests received from an attacker, the honeypot server determines the action to take in response to the request. This action could be, for example, a request to instantiate an IaaS instance. The honeypot server then instantiates the requested IaaS instance using at least one of the following resources: computing resources, storage resources, or network resources. The honeypot server then returns a response to the attacker indicating that the IaaS instance has been 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. The honeypot server can then generate a response to the request by applying the action to that pre-instantiated IaaS instance.

[0010] In certain embodiments, the honeypot server may determine that a request asks for the action of instantiating an IaaS instance. The honeypot server may then generate a response indicating that the requested IaaS instance has been successfully instantiated, without actually instantiating the IaaS instance. In some cases, a request from an attacker may ask for an action to be performed using the IaaS instance. The honeypot server is configured to generate an appropriate response to the requested action without actually performing the action and without instantiating the IaaS instance. In such scenarios, 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 that action. The honeypot server can then use this rule information to find an appropriate response to the action requested by the attacker. In one embodiment, the honeypot server searches the rule information to find the corresponding The honeypot server can find items in the rule information that match the action requested by the attacker. The honeypot server can then use these items to determine the response to send to the attacker, making the attacker believe that the requested action was successfully performed.

[0011] Various techniques can be used to lure attackers to a honeypot server. For example, a set of one or more credentials can be deliberately made visible on one or more ports that attackers commonly search to direct an attack, such as SSH (shell) port 22 or FTP (file transfer protocol) port 21. Credentials may include username and password pairs, certificates, keys, and identifiers (e.g., tenant identifiers).

[0012] Attackers come in various types. For example, an attacker could be an automated bot. In some cases, an attacker could be a user who directs the attack using applications such as browsers or GUI-based applications.

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

[0014] [Figure 1] This figure shows an embodiment of a honeynet equipped with a honeypot, according to a specific embodiment. [Figure 2] This figure shows another embodiment of a honeynet equipped with a honeypot, according to a specific embodiment. [Figure 3] This is a simplified block diagram of a distributed environment incorporating a honeynet comprising one or more honeypots, according to a specific embodiment. [Figure 4] This is a simplified block diagram of a honeypot server according to a specific embodiment. [Figure 5] This is a simplified block diagram of a honeypot server according to a specific embodiment. [Figure 6] It is a simplified block diagram of a honeypot server according to a specific embodiment. [Figure 7] It is a flowchart of an implementation example of a honeypot according to a specific embodiment. [Figure 8] It is a simplified block diagram showing a certain pattern for implementing a cloud infrastructure as a service system according to a specific embodiment. [Figure 9] It is a simplified block diagram showing another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 9] It is a simplified block diagram showing another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 10] It is a simplified block diagram showing another pattern for implementing a cloud infrastructure as a service system according to a specific embodiment. [Figure 11] It is a simplified block diagram showing another pattern for implementing a cloud infrastructure as a service system according to a specific embodiment. [Figure 12] It is a simplified block diagram showing an example of a computer system according to a specific embodiment.

Mode for Carrying Out the Invention

[0015] [[ID=2?]]Detailed Description In the following description, for the sake of convenience of explanation, specific details are described in order to enable a full understanding of specific embodiments. However, it will be clear that various embodiments can be implemented even without these specific details. The drawings and the description are not limiting. The word "exemplary" used in this specification means "serving as an example, a specific example, or an illustration". None of the embodiments or designs described as "exemplary" in this specification should necessarily be construed as more preferable or advantageous than other embodiments or designs.

[0016] As more business operations are abstracted and become cloud-based, in parallel, a given organization becomes overall It should be noted that in the original text, there is an unclear "[[ID=2?]]" which might be a typo. I have translated it as "[[ID=2?]]Detailed Description" as it is. If this is incorrect, please provide the correct information for a more accurate translation. The likelihood of becoming a target of threats increases further. It is necessary to well understand how the cloud environment will be attacked when nothing is done, based on the in-house threat intelligence feed.

[0017] This disclosure relates to computer security, and particularly to a technique for attracting attackers using honeypots and collecting data on attack patterns against IaaS (Infrastructure-as-a-Service) instances. And the collected data can be used to prevent such attacks.

[0018] In certain embodiments, one or more honeypot servers (honeypots) are installed. Here, each honeypot server (honeypot) is an endpoint node deliberately installed for an attacker to perform extremely malicious acts. For example, fake banking applications, applications related to important infrastructure (such as payment processing, temperature of oil rigs), etc. Such honeypots are used to collect data about attackers.

[0019] In certain embodiments, a honeypot may be deployed to deceive a malicious user (hereinafter also referred to as an attacker) into believing that a real instance, such as a genuine IaaS (Infrastructure-as-a-Service) instance, has been compromised. In reality, the attacker is operating on isolated dummy or virtualized resources provided by the honeypot server, and the protected resources are not actually affected. A honeynet, or a network consisting of such honeypots, may be deployed to emulate an IaaS service or service product provided by a cloud service provider. For example, a honeynet (or a set of honeynets) may be provided to emulate the OCI (Oracle Cloud Infrastructure) IaaS service provided 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 a protocol such as SSH (Secure Shell) or FTP (File Transfer Protocol). The honeypot may have several credentials (e.g., username and password pairs, keys, etc.) that an attacker can access and log into. By gaining access to a real IaaS instance, the attacker will think they have "hit the jackpot."

[0021] When an attacker interacts with a dummy IaaS instance, the honeynet infrastructure is configured to deceive the attacker into believing they are interacting with a real IaaS instance rather than a dummy instance by providing appropriate responses. In certain embodiments, a hypothetical attacker may be used to set up a pre-configured / pre-fabricated flow of interaction.

[0022] Interactions with an attacker's honeypot (and honeynet) are recorded or logged. Recorded attacker data may include the attacker's actions (e.g., the attacker's user behavior patterns, other user-specific attributes), unique attributes about the attacker such as connection and device-level attributes of a specific attacker (e.g., connection information, IP address of the device the attacker used to initiate the attack call and request, ASN (Autonomous System Number) traceroute information, domain name, etc.), and other data related to the attack. Recorded data This could include data about the attacker's actions, objects accessed by the attacker, and API calls made by the attacker (for example, REST API calls made by the attacker).

[0023] Furthermore, the data recorded in the logs can be analyzed to identify information and analytics about attack patterns. For example, the data recorded in the logs may be used to answer questions such as how the attacker orchestrated the attack, what the attacker was targeting, what the objectives and intentions behind the attack were, and how frequently the attack occurred.

[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 a set of actions or unique attributes. When integrated into a data lake and its extraction, loading, and transformation mechanisms, they enable the use of unsupervised machine learning techniques to identify novel zero-day threats (e.g., threats never seen before).

[0025] Furthermore, the data captured or recorded by the honeynet can be used to uniquely identify specific attackers and attacker categories, and to find patterns in their attacks. The data collected using a honeynet is crucial for understanding attack mechanisms and preventing ongoing attacks, including zero-day vulnerabilities that the attackers may not be aware of. Honeynet services can be offered as a security service so that appropriate action is taken when specific IP addresses are identified as malicious.

[0026] The data recorded or logged by the honeynet can be sent to an analytics platform for analysis. For example, recorded data can be sent to an AI-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. New and improved security models can be built using the data logged by the honeynet.

[0027] Data recorded by a honeynet about one or more attackers may be used for a variety of purposes. In certain embodiments, data collected by one or more honeynets may be transferred from these honeynets to a centralized log server, which may transfer the collected data for analysis or provide access to the collected data. For example, the collected data may be transferred for analysis and used by a threat intelligence tool configured to identify attackers and similar threats. For example, a threat intelligence tool may use the collected IP network information and the association between that IP network information and the threat actors to identify similar attacks. The collected data (e.g., key pair values, events, 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 a series of events about a current user, and whether these users are posing a threat may be derived from the user's cloud activity profile.

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

[0029] Then, preventative measures can be initiated against the identified threats. In some cases, it may be possible to identify such threats and take preventative measures even before malicious activity is carried out. 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 can be identified and preventative measures taken quickly to reduce the time an attacker has to carry out malicious activity. For example, a threat may be identified as soon as one or two actions that match an attack profile are identified.

[0030] In certain embodiments, the security features provided by HoneyNet can be offered as a cloud service. Such a cloud service can be configured to identify access to resources for subscribing tenants, flag inappropriate access, and take appropriate corrective action (for example, if a particular IP address is identified as malicious, it will be flagged and appropriate action will be taken).

[0031] A network consisting of honeynets or honeypots is used in this way to ingest and collect data about attackers, to understand from the attacker's perspective where and how such attacks originate and are executed, what resources are attacked, what are the behavioral patterns, sequence information, and motivations during such unauthorized access, and as a tool to obtain contextual information about attackers (e.g., where the attacker is coming from, what kind of operating system the attacker is using, when the attack occurs, and other attributes related to the attack). By using a honeynet, more data about such attacks can be uncovered without endangering actual useful resources. For cloud service providers, one or more honeynets, each consisting of one or more honeypots, may be deployed in one or more of the provider's data centers. Honeynets enable the proactive identification of new types of threats, allowing cloud security software / cloud security personnel to stay one step ahead of attackers by autonomously obtaining more desirable data in advance.

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

[0033] Step 1: Make the honeynet accessible to attackers (e.g., dark web users). The first step involves setting up a honeynet to attract attackers. In certain embodiments, a set of servers may be set up to intercept requests from attackers using protocols such as HTTP or FTP. Conveniently, credentials may be stored in CSV files or database files in a directory structure so that they can be found by the attackers. When an attacker finds dummy credentials for an instance of a service (e.g., an IaaS instance), they attempt to use those dummy credentials to access the service instance and use the resources available through that service instance.

[0034] For example, as shown in Figures 1 and 2, an attacker could intercept a decoy node via FTP listening mode on port 22 or port 21 (used for secure login, FTP, port forwarding, etc.). Credentials could be set to a common naming convention (i.e., root / password). An attacker would likely look through a list of historical directories and find a .csv / .db file prefixed with text (superuser). A dark web user would find randomly generated credentials placed at the top of this file specifying the superuser. These credentials could be in the form of superusername / password. These credentials are intended to give the attacker access to a dummy IaaS instance provided by an IaaS honeynet that has been set up to be "attacked".

[0035] Various techniques may be used by the honeynet to identify the attacker. Generally, ordinary users would not look for decoy nodes on the internet. For example, if a decoy node is running on port 22 for SSH, the average user (e.g., a legitimate client or tenant of a cloud service provider) would not try to find that decoy node, and therefore would not look at it to find credentials. The decoy node itself may be used as a mechanism to distribute dummy credentials. Attackers are attracted to the dummy credentials, access and use them to perform malicious acts. Attackers are led to believe that credentials are inadvertently left on a decoy node that is open on a port.

[0036] There are several ways in which an attack can occur, but the following two are the most common. (1) Use an automated bot. The bot may be configured to learn as many credentials as possible, and then use a script to use the learned 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. The attacker may interact with a cloud service (for example, Oracle's OCI service) using a GUI. This can be done by CLI (command line interface) requests (for example, REST API-based requests) directed to API endpoints that have the capability to perform actions in response to the attacker's requests. A GUI is essentially a wrapper around a CLI request. A CLI request can be generated using command line mode or using a GUI interface.

[0037] In certain embodiments, the honeynet described herein is capable of dealing with 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 shows a honeynet system 100 for dealing with requests received from the automated bot, according to a particular embodiment. The honeynet 100 may consist of one or more honeypots. In Figure 1, the IaaS instance 102 provided by the honeynet is shown within the dotted line.

[0039] As shown in Figure 1, the decoy node 104 allows the attacker to access the REST API node 106. The REST API node 106 may be a gateway to instance 102 of the IaaS service. In Figure 1 (and Figure 2), the IaaS instance 102 (instance 202 in Figure 2) is shown by a dotted line and is a compute node. This includes ing resources, storage resources, and network resources. The decoy node 104 may provide the attacker with access to credentials for accessing a honeynet consisting of one or more honeypots, where these honeypots 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 & Control) node 106 (206 in Figure 2) acts as an intermediary between the attacker and the resources or objects to which the attacker intends to perform highly malicious actions. For example, the REST API endpoint 106 (206 in Figure 2) functions to mediate all resources / actions created from CLI GET requests generated by the bot / attacker. In a particular embodiment, the REST API node 106 receives CLI requests from the attacker, parses the CLI requests to understand the action the attacker is requesting, and provides the attacker with the output or response the attacker expects for the request.

[0041] Furthermore, REST API node 106 has the functionality to deceive an attacker into believing that they have accessed or performed some action on a non-dummy resource. This is done by providing a correct dummy response to a request received from the attacker (e.g., a GET request, a POST request), deceiving the attacker into believing that the attack was successful (i.e., that the action the attacker requested to be performed was successfully executed). For example, the response might deceive the attacker into believing that they were able to set up an IaaS instance and perform various operations using that instance. REST API node 106 supplies the attacker with false or dummy information, making them believe that the malicious act was successfully performed. In other words, it deceives the attacker into believing that what the attacker is requesting is actually happening. This node is used as a tool to maintain the deception.

[0042] The REST API node 106 has the function of processing requests received from the attacker, deceiving the attacker by supplying them with information they expect, and allowing them to continue the attack. In a particular embodiment, the REST API node 106 is configured as follows:

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

[0044] (2) Provide the attacker with a response that includes error handling, making the attacker believe that they have accessed a real, non-dummy instance.

[0045] Regarding interpreting requests and setting up resources, instances may be set up 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, CLI GET requests from attackers may be handled using techniques such as RegEx (regular expression) scripts and / or cached dictionaries of NLP (natural language processing) (e.g., using appropriate webhooks).

[0046] Various techniques may be employed by the honeynet to provide a suitable response that leads the attacker to believe they have access to a genuine IaaS instance. In some cases, the honeynet may generate and provide an appropriate response to a request without actually executing the requested action(s). In some embodiments, the honeynet may preload POST requests that the attacker communicates from a CLI tool of their choice. One way to do this is to use NLP (Natural Language Processing) technology, such as by setting up and using an NLP dictionary that contains requests and responses that are automatically sent back to the attacker when certain conditions are met. There are various ways to address this, for example, by using string analysis to understand what kind of request is being made and then determining an appropriate response from the dictionary.

[0047] In certain embodiments, as shown in Figures 1 and 2, a reverse proxy 112 (212 in Figure 2) may be optionally provided as part of a flow that can obtain additional information from the client and 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, the attacker may spin up a database or a computer or network resource, and the reverse proxy 112 may be used to anonymize the identity information of these resources. The reverse proxy node 112 maintains the anonymity of the instances 102, ensuring that the attacker can never know the true identity information of these instances.

[0048] The resources of IaaS instance 102 that the attacker interacts with may be limited to compute resources, storage resources, and memory resources, and may provide a small number of basic functionalities. The IaaS services / objects that the attacker accesses will 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 legitimate user directing the attack through an application running on the attacker's client system, for example, by using a browser of another GUI application to initiate access to an IaaS instance. Figure 2 shows system 200 for handling requests and responses related to GUI-mode attacks.

[0050] Processing for GUI mode is very similar to processing for CLI mode. In GUI mode, an attacker may initiate an attack using a fake browser GUI 204 and send requests. The attacker's interactions with the console (e.g., client device) and the GUI application can be recorded by the log node 210 in Figure 2 (node ​​108 in Figure 1). For example, data on user / attacker logins and the attacker's interactions with the browser (e.g., which links the attacker clicked, a series of clicks, etc.) can be recorded. In certain embodiments, an asynchronous ON event listener 210 may be used to collect data on how the attacker is interacting with the GUI console. This collected data can be used to better understand not only the decisive actions the attacker is taking in 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 and command server will provide the attacker with a status of 200 in all cases, unless the API GET request is incorrectly formatted and / or the output type is incorrect. If the format is incorrect and / or the data type is incorrect, the REST API will not respond. Code 206 sends the attacker an appropriate error handling code.

[0052] Step 3: Logging in Verbose Mode As shown in Figures 1 and 2, in certain embodiments, separate log nodes (108 in Figure 1 and 208 in Figure 2) may be set up to record all events / resources / objects accessed in the Honeynet's IaaS instance provided by the Honeynet, as well as all events / resources / objects accessed by the attacker. Logging may be performed chronologically.

[0053] Step 4: ETL / Machine Learning Pipeline, Native Threat Intelligence Feed, etc. In certain embodiments, log nodes 1108, 208, or the server store all attacker interactions. The 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 provides attackers with unique core attributes for a native threat intelligence feed that is directly populated into an internal blacklist used by security monitoring, detection, and prevention programs, preparing for future threats around actors who have previously attacked the IaaS honeynet.

[0054] The amount of resources available to dummy IaaS instances deployed by the honeynet may be determined based on the acceptable cost of luring an attacker and obtaining information about their activity. In some embodiments, a limited amount of computing, storage, and network resources may be allocated. For example, a specific number of pre-fabricated images may be provided, each having a fixed, limited amount of computing, storage, and network resources, which can then be used to deploy IaaS instances requested by an attacker and perform actions requested by the attacker. These pre-fabricated virtualized or containerized images may be hardcoded to not expand beyond pre-configured constraints.

[0055] The honeynet entices an attacker to establish a connection and a session with it, making the attacker believe they are attacking real / legitimate resources and performing the desired malicious act, thereby further enticing them to perform more malicious acts. At some point, the honeynet may decide to stop the attacker's actions and cut off the attacker's session with the honeynet. In some cases, this point may be reached, for example, when the honeynet confirms that it has recorded sufficient data about the attacker and their interactions with the honeynet and dummy instances. 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 session between the attacker's dummy instances and the honeynet meets or exceeds a predetermined time threshold. Various other factors may also be used to determine when to "cut off" the attacker. In other embodiments, a combination of the aforementioned factors and other factors may be used.

[0056] Exemplary Embodiment #2 An IaaS instance includes a configuration that bundles processing resources (e.g., cores, processors), storage resources (e.g., memory resources), and network resources to provide computing, storage, and networking services. It provides cloud virtualization (at the infrastructure and resource layers). IaaS cloud provides service products related to computing and storage functions provided in conjunction with network functions. Attacks on IaaS instances are very different from attacks on SaaS or PaaS instances because attacks on SaaS / PaaS instances target the data used by SaaS / PaaS applications, rather than attacking computing / memory / network resources. In the case of IaaS, several resources may be involved, and the configuration of these resources is difficult to understand, resulting in a lack of existing solutions to prevent IaaS attacks. Monitoring IaaS resources and identifying attacks against them is very difficult because there are so many moving parts, each with its own configuration, and many things can be very easily overlooked. As a result, some IaaS attacks proceed without being detected at all.

[0057] Figure 3 is a simplified block diagram of a distributed environment 300 incorporating a honeynet comprising one or more honeypots, according to a particular embodiment. As shown in Figure 3, the distributed environment 300 comprises a data center 302 of a cloud service provider. 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. Here, the term "real" is used to distinguish these instances from "dummy" instances provided by the honeynet. A real service instance may include one or more real IaaS instances (e.g., R-IaaS#1) providing one or more IaaS services, one or more real PaaS instances (e.g., R-PaaS#1) providing one or more PaaS services, and one or more real SaaS instances (e.g., R-SaaS#1) providing 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. Customers or tenants can subscribe to one or more cloud services offered by cloud service providers utilizing data center 302.

[0058] The distributed environment 300 shown in Figure 3 is merely an example and does not unnecessarily limit the scope of the claimed embodiment. Those skilled in the art will see that numerous variations, alternative options, and modifications are possible. For example, in an alternative embodiment, the distributed environment 300 may have more or fewer systems or components than those shown in Figure 3, or it may be a combination of two or more systems, or the configuration or arrangement of the systems may differ. The configuration of the data center 302 shown in Figure 3 is merely an example and not limiting. For simplification, only one data center 302 is shown in Figure 3, but a typical distributed environment may, in some cases, have multiple data centers in different geographical locations. Multiple data centers may be connected to each other in a communicative manner via one or more communication networks. Communication networks can be of various types, including the Internet, WAN (Wide Area Network), LAN (Local Area Network), Ethernet® network, public or private network, wired network, wireless network, and / or a combination thereof. Communication will be facilitated using various 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] An attacker attacked and maliciously misused resources provided by Data Center 302. Attackers have different characteristics. Entities that attempt to connect to Data Center 302 or use resources provided by Data Center 302 without proper authorization are considered attackers. For example, an entity that accesses and uses resources provided by Data Center 302 using dummy credentials is considered an attacker.

[0060] Attackers can take various forms, including automated bots and human users. In the example shown in Figure 3, an automated bot 308 running on client device 310 may attempt to attack and misuse resources provided by data center 302. The automated bot 308 may be configured to intercept endpoint nodes within data center 302, find a way to connect, and then use that connection to utilize resources provided by data center 302. Attacks can also originate from a human user 312 using an application or software (e.g., a GUI browser 314) running on client device 316 to attack and misuse resources provided by data center 302. The attacks themselves can be carried out using different mechanisms, such as CLI (command-line interface) mechanisms and GUI-based mechanisms.

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

[0062] As shown in Figure 3, data center 302 provides a honeynet 306. The honeynet 306 is configured to lure such attackers and collect data about them without compromising the data center 302's real resources (e.g., real instances). The honeynet 306 comprises various components, including a network of honeypot servers (or honeypots). Each honeypot may represent a specific IaaS service instance that provides access to a particular set of IaaS resources. Each honeypot is configured to deceive an attacker into believing that they have successfully obtained access to a real IaaS instance. Different honeypots 318, 320, 322, etc., may be provided for different types of IaaS services, each with its own distinct honeypot. Although only one honeynet is illustrated in the embodiment shown in Figure 3, this is not limiting. A data center may provide one or more honeynets.

[0063] In the embodiment shown in Figure 3, the honeynet 306 also includes a log server 330. The log server 330 is configured to receive and collect data about attacks recorded by the honeypot. The collected data is then stored in non-volatile memory for subsequent analysis. In some embodiments, such as the embodiment shown in Figure 3, the honeynet 306 itself includes an analytics platform or server 332. The analytics platform or server 332 is configured to analyze the data collected by the honeypot and the data logged by the log server 330. In some other embodiments, the 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 provided by data center 302. In some cases, the analytics platform may be located remotely from data center 302. In such cases, log server 330 may be configured to communicate data collected by data center 302's honeynet 306 to the remote analytics platform using data center 302's communication interface 344.

[0064] In certain embodiments, a specific set of available resources 324 may be reserved for use by a honeypot in the honeynet 306. These available resources 324 may include computing resources (e.g., cores, processors), storage resources (e.g., memory), network resources, database resources, containers, and so on. The honeypot may use the resources included in the available resources 324 to spin up dummy IaaS instances that trick an attacker into believing they are connected to and using a real IaaS instance. In some embodiments, the resources included in the available resources 324 may be pre-packaged into bundles of resources (called "pods"), each of which consists of specific computing resources, memory resources, and network resources in a pre-configured configuration. The honeypot may then use one or more of these pre-packaged bundles or pods to spin up dummy IaaS instances.

[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. These host machines may provide real instances 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 contained within honeynet 306 may be deployed across one or more host machines of data center 302.

[0066] In certain embodiments, the honeynet is isolated and separated from the real instances for security reasons. Therefore, the infrastructure of data center 302 used to provide the honeynet is separate from the infrastructure used to support the 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] Various different techniques are used to lure attackers into the honeynet 306. Attackers, including automated bots and human attackers, typically look for SSH port 22 and FTP port 21 and exploit vulnerabilities in these ports to carry out attacks. In the embodiment shown in Figure 3, a decoy server or decoy node 336 is used to lure attackers. The decoy server 336 is configured to draw the attacker's attention to one or more ports of the data center 302, such as SSH port 22 and FTP port 21, by openly broadcasting information on these ports. When an attacker connects to one of these ports, a dummy or fake credential 338 is conveniently placed for the attacker to access. In some embodiments, the decoy server 336 may broadcast information about the dummy credential 338 while making it appear as if the credential was accidentally broadcast. Dummy credentials 338 may contain dummy restricted information such as dummy username / password information, API keys, MAC addresses, certificates, tenant identifiers, and passwords. The purpose is to make an attacker believe they have obtained genuine credentials that can be used to attack resources provided by data center 302. Specific implementation In this configuration, several default credentials may be placed as dummy credentials. In some cases, an attacker may send an API call (e.g., GET cred) to access dummy credentials 338, and then the dummy credentials are sent as a response to that API call. The API call may be handled by the API gateway server 340.

[0068] For example, in a typical scenario, an entity (tenant) legitimately subscribes to a service provided by a cloud service provider using data center 302. At the time of subscription (or thereafter), the tenant is provided with one or more customized credentials for that tenant. These credentials enable the tenant to log in to data center 302 and establish a session with the real instance providing the service being subscribed to (for example, a real IaaS instance providing a specific type of IaaS service). When establishing the session, the tenant is requested to provide credentials, which are then used to authenticate the tenant. Once the real instance providing the service the tenant subscribes to is successfully authenticated, a session is established for the tenant.

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

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

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

[0072] API calls made by a legitimate tenant are the same as API calls made by an attacker. Based on the API call and the information received through the API call, 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 handling. The API gateway server 340 may make this determination using different methods, such as the following:

[0073] (1) In the case of an API call that requests the establishment of a session, the API call is: Typically, this includes credentials (e.g., username / password) used to authenticate the requester before establishing a session. If the API gateway server 340 determines that these credentials are dummy credentials, it knows that the request is from an attacker or malicious actor. The API gateway server 340 then forwards the request to the components of the honeynet 306 for further action.

[0074] (2) After the attacker has logged in and established a session with the dummy IaaS instance, data about the attacker and their actions during the session is collected and logged. This logged data may include, for example, device-level information about the device the attacker used to initiate the attack request. In certain cases, this device-level information can be identified from the API call itself. Therefore, in the case of an API call received by the API gateway server 340, after the API gateway server 340 determines that the device-level information about the API call matches the device-level information about the attacker's device that is stored (this information may have been previously recorded while the attacker was interacting with the data center 302), the API gateway server 340 determines that it is an API call from the attacker and forwards the API call to the components of the honeynet 306 for handling.

[0075] (3) The 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 previously described, 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 on dummy credentials, the API gateway server 340 may determine that the request is not a legitimate request but a request from a malicious actor or attacker.

[0076] (4) Various combinations of the information described above may be used to identify the demands from the attacker.

[0077] If the API gateway server 340 identifies that a request originated from an attacker, it forwards the request to a component of the honeynet 306 for processing. In certain embodiments, once the attacker is identified, the API gateway server 340 opens a session connecting the attacker to a specific honeypot server from the honeynet 306. For example, the API gateway server 340 may set up a session for the attacker with a specific honeypot configured to provide the IaaS service requested in the request, and then forward the request to that honeypot for further processing.

[0078] After a session is established between the attacker and a particular honeypot, the attacker can send further requests to spin up an IaaS instance and further requests to use the resources provided by the IaaS instance. In certain embodiments, the honeypot may spin up a dummy IaaS instance. For example, HP1318 in Figure 3 is a dummy IaaS instance D-IaaS#1 that has been spun up. The honeypot may then return a response to the attacker indicating that the requested IaaS instance has been set up and is ready for the attacker to use. This response is designed to make the attacker believe that a legitimate (not dummy) IaaS instance has been spun up.

[0079] After the dummy IaaS instance is spun up, during the session, the attacker can use the resources associated with the spun-up IaaS instance to perform various actions. An attacker could potentially submit one or more requests to perform actions such as Bitcoin mining by utilizing the computing, storage, and network resources provided by a dummy IaaS instance. The honeypot where the attacker has established a session would receive these requests and, for each request, would be configured to interpret the request to identify one or more actions or operations requested by the request, perform these actions using the spun-up dummy IaaS instance, and generate and send a response corresponding to the actions and requests to the attacker. The generated response would be designed to lead the attacker to believe that it is a valid response from a real IaaS instance and that it was able to utilize the services and resources provided by the spun-up IaaS instance.

[0080] In certain embodiments, a honeypot can generate and send appropriate responses to an attacker for requested actions and API calls received from the attacker, without actually setting up or spinning up a dummy IaaS instance. For example, the honeypot may use a set of rules to generate responses. This set of rules may include a mapping that identifies a set of possible actions 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 this mapping to determine one or more responses for one or more actions. These one or more responses may then be returned to the attacker in accordance with the received request. The responses generated by the honeypot are such that they lead the attacker to believe that they were able to spin up an IaaS instance and that they were able to utilize the services and resources provided by the spun-up IaaS instance, even though not even a dummy IaaS instance had 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 honeypot may utilize a combination of a dummy IaaS instance and a set of rules to generate responses to requests received from an attacker. In one such embodiment, the honeypot can learn new rules, such as new mappings between actions and responses, based on the spun-up dummy IaaS instance. For example, after learning responses to a particular requested action received from an attacker using the dummy IaaS instance, the honeypot may add new action-response mapping items to the rule information. Subsequently, when the same action is requested, the rule information, rather than the IaaS instance, is used 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, their actions, and their interactions with the honeypot. Recorded attacker data may include the attacker's actions (e.g., the attacker's user behavior patterns, other user-specific attributes), unique attributes about the attacker such as connection and device-level attributes for a specific attacker (e.g., connection information, IP address of the device used by the attacker, ASN (Autonomous System Number) traceroute information, domain name, etc.), and other data related to the attack. Recorded data may include data about a series of actions by the attacker, objects accessed by the attacker during their session with the honeypot, and API calls made by the attacker (e.g., REST API calls made by the attacker). Logged data may include information about API requests received from the attacker, responses generated and sent by the honeypot in response to API requests, the IP address from which the request originated, the port number used by the attacker to connect to the data center, and JavaScript® on events (GUI). This concerns the underlying interactions, which may include device-level information, request intervals, etc. (for example, browser-based events on the client device may be monitored).

[0083] In certain embodiments, a honeynet, such as honeynet 306, may include a log server 330. The 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 transferred to the log server 330. The log server 330 is configured to store the data in the correct format. This data may be stored in non-volatile memory accessible to the log server 330. The log server 330 may also function as a controller for accessing the collected data.

[0084] In certain embodiments, the honeynet 306 may include an analytics subsystem 332. The analytics subsystem 332 is configured to analyze data collected by the honeypots included in the honeynet 306. By analyzing the collected data, insights can be gained about the attacker's motives (e.g., objectives and intentions of the attack), attack patterns, attack mechanisms, attack origins (in terms of connectivity (e.g., IP addresses, domains, etc.) and geographical perspectives), different types of attacks, resources and objects accessed by the attacker during the attack, what the attacker is attacking, which resources were used, how those resources were used, operations performed during the attack, and attack frequency profiles. In certain embodiments, based on the analysis, 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 having an analytics platform at the honeynet level, or in addition to an analytics platform at the honeynet level, the analytics platform may be provided by the data center 302. In such embodiments, data collected by one or more honeynets in the data center 302 may be transferred to this analytics platform for analysis. In certain embodiments, the analytics platform may be provided by a remote computing platform from the data center 302. Such a remote analytics platform may be configured to collect and / or receive data collected by multiple honeynets scattered across one or more data centers, aggregate the data, and then analyze the aggregated data.

[0086] Various different techniques may be used to analyze the data collected by the honeynet. In certain embodiments, machine learning (ML) techniques may be used. The data collected by the honeynet may be provided as training data and used to build and train models to identify attackers and attacks based on various criteria contained in the collected data. Such models can then be used to identify attackers and attacks in advance, and preferably to 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 the servers and other components of the data center 302 behind the proxy server. The reverse proxy exists between clients (such as clients 310 and 316) and anonymizes the servers behind the proxy. The client does not know which server it is connecting to. The reverse proxy server provides several benefits, including load balancing, caching, isolation of internal traffic, and logging. The reverse proxy server 342 may also be configured to log attributes about the attacker or attributes about the client device used by the attacker. The reverse proxy server 342 acts as a privacy and confidentiality barrier for resources that the attacker is spinning up. For example, an attacker may spin up a database or a computer or network resource, and the reverse proxy may be used to anonymize the identity of these resources. The reverse proxy maintains the anonymity of the instances, ensuring that the attacker can never know the true identity of these instances.

[0089] As described above, the honeypot is configured to respond to requests received from the attacker while collecting data about the attacker and their 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, or combinations thereof. Some of these factors include:

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

[0091] (2) Interval - If the attacker stops interacting with the honeypot, wait for a certain period of time. For example, session activity can be allowed to continue as long as the attacker is interested. Generally, the more data the honeypot collects, the more data becomes available for downstream analysis.

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

[0093] (4) Various other factors may be used to determine the timing of "blocking" the attacker. In another embodiment, a combination of the aforementioned factors and other factors may be used.

[0094] In certain embodiments, an attacker may only be allowed one session with the honeypot. In such embodiments, the attacker's attempt to open a second session is prohibited. In some other embodiments, multiple sessions may be allowed 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 to subscribing customers as a cloud service. By subscribing to such a service, customers can proactively identify attacks against their resources.

[0096] Figure 4 is a simplified block diagram of a honeypot server 400 according to a specific embodiment. The honeypot server 400 (also referred to as the honeypot 400) may comprise a plurality of subsystems that are interconnected and can communicate with one another. In the embodiment shown in Figure 4, the subsystems of the honeypot 400 include a request interpretation subsystem 406, a response generation subsystem 408, a communication interface subsystem 412, and a recording subsystem 414. These subsystems may be implemented solely in software (for example, as programs, code, or instructions executable by one or more processors), in hardware, or in combination thereof. The honeypot 400 shown in Figure 4 is merely an example and does not unnecessarily limit the scope of the claimed embodiments. Those skilled in the art will see that numerous variations, alternative choices, and modifications are possible. For example, in some embodiments, the honeypot 400 may have more or fewer subsystems or components than those shown in Figure 4, may be a combination of two or more systems, or may have different system configurations or arrangements.

[0097] The request interpretation subsystem 406 is configured to receive and interpret requests from an attacker. For example, in a particular embodiment, if the API gateway server 340 determines that a request or API call is from an attacker, it selects a specific honeypot from the honeynet 306 (for example, as shown in Figure 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. These one or more actions may include, for example, actions to set up or spin up an IaaS instance, and actions to utilize one or more resources provided by the IaaS instance.

[0098] If the action involves spinning up an IaaS instance, the request interpretation subsystem 406 may use one or more of the available resources 404 to set up a dummy IaaS instance 416. The dummy IaaS instance 416 may provide services that enable the use of one or more computing resources (e.g., processing resources such as processors or cores), 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 to be performed corresponds to the use of resources provided by the dummy IaaS instance 416, the request interpretation subsystem 406 may allow the attacker to use these resources to satisfy 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 a dummy response to a request received from the attacker. The dummy response generated by the response generation subsystem 408 is designed to lead the attacker to believe that the response is valid and was generated by a valid IaaS instance. This allows the attacker to continue their actions without fear of being detected as a malicious actor or malicious user.

[0100] A one-to-one, one-to-many, or many-to-one relationship can exist between an action and a response. In a one-to-one relationship, each action may have its own response. In a one-to-many relationship, an action may have multiple related responses. In a many-to-one relationship, a single response may be generated and sent for multiple actions. The response generation subsystem 408 is responsible for generating an appropriate response to the attacker's request that it receives.

[0101] The response generation subsystem 408 may use various techniques to generate the 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 the corresponding response to the response generation subsystem 408. Then, the response generation Subsystem 408 may forward the response received from dummy IaaS instance 416 as a response to the request. In some cases, the response generation subsystem 408 may format or modify the response received from dummy IaaS instance 416 to generate a response to be communicated to the attacker.

[0102] According to the second technique, the response generation subsystem 408 may generate a response to an attacker's request using a set of rules 418 without using a dummy IaaS instance 416. 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, that is accessible to the honeypot 400. The set of rules 418 may include mapping information that specifies the mapping between actions that an attacker can request and the corresponding responses. The mapping information may reflect a one-to-one relationship, a one-to-many relationship, or a many-to-one relationship between actions and responses.

[0103] Upon receiving a request from an attacker, the request interpretation subsystem 406 interprets the request to identify one or more actions to be performed in response to the request. The response generation subsystem 408 can then look up rule 418 to identify an appropriate response for the requested action. The response identified based on rule 418 can then be returned to the attacker as a response to the attacker's request. The response generated by the honeypot is one that leads the attacker to believe that they were able to spin up an IaaS instance and that they were able to utilize the services and resources provided by the dummy IaaS instance, even though the dummy IaaS instance may not have been spun up. For example, honeypot 400 might receive a request from an attacker where the requested action is to instantiate (spin up / set up) an IaaS instance. The response generation subsystem 408 can then search for rule information (e.g., mapping information) to find a suitable response to this request without actually deploying an IaaS instance. However, the response indicates that the requested IaaS instance has been deployed, thereby deceiving the attacker into believing that a valid IaaS instance has been deployed.

[0104] Upon receiving a request from an attacker, the request interpretation subsystem 406 can translate the request into a specific action to be performed. The response generation subsystem 408 then searches the mapping information 418 and can find an item in the mapping information that matches the specific action to be performed. The response generation subsystem 408 uses this matching item to identify the response corresponding to that item, that is, to identify the 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 certain 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 or second response generation technique and generate a response to return to the attacker using the decided technique.

[0106] In some embodiments, the response generation subsystem 408 may learn new mappings between actions and responses using machine learning rules and add these learned mappings to rule 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 relating to the attacker and their interactions with the honeypot 400. The recording subsystem 414 may also track and store information about requests and corresponding responses generated by the response generation subsystem 408 and returned to the attacker. The recording subsystem 414 may be configured to store the recorded data as recorded data 420 in 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 to a remote location (e.g., a remote analytics platform) from the data center 302. The data collected by the honeypot server 400 may also be sent to a central collection server (e.g., a honeynet log server), which may then send the data to other analytics subsystems. Analytics may reside on-premises or elsewhere. The honeynet log server can decide which data to send to analytics, or it may provide an interface for analytics to retrieve data from the honeynet log server. In certain embodiments, the communication interface 412 would facilitate data communication with the honeypot 400.

[0108] The non-volatile memory 402 may also store other information 422 that the honeypot 400 uses to perform its operations. For example, the other information 422 may include configuration information, such as information about pre-created instances (customized combinations of IaaS resource "pods") that the honeypot 400 can use to deploy dummy IaaS instances.

[0109] Figure 5 is a simplified block diagram of a honeynet 500 connected to a cloud service provider infrastructure 502 according to a particular embodiment. The honeynet 500 may be a virtual computing instance and / or a cluster consisting of one or more virtual machines. One or more attackers 501 and / or the cloud service provider 502 described above may be able to access the honeynet 500 via the public network 504. The cloud service provider 502 may also communicate with a threat analysis system 506. The threat analysis system 506 can be configured to analyze the 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 honeypots only) S1-S3) can be deployed in a honeynet 500. In the honeynet 500, each honeypot is an endpoint node deliberately set up for an attacker to perform extremely malicious actions. The honeynet 500 may be deployed on one or more host machines. For security reasons, these host machines can be isolated from the rest of the cloud service provider 502 (for example, as shown in Figure 5), or the host machines can be isolated within the cloud service provider 502 (for example, as shown in Figure 3, where HP1-HP3 are implemented within the data center 302). A honeynet management system 508 can be provided to deploy and configure honeypots S1-S3 and to perform local processing. Although three different honeypots S1-S3 are shown in Figure 5, any number of honeypots may be implemented within the honeynet 500. As will be discussed in more detail later, honeypots S1-S3 may be implemented in various forms (e.g., types).

[0111] You may deploy different types of honeypots on HoneyNet 500 to emulate different types of services. For example, an SSH and / or Telnet honeypot to emulate SSH / Telnet services, SMTP (for example, e-mail Examples include SMTP-based honeypots to emulate mail servers, SSL, and TLS; HTTP honeypots to emulate HTTP (e.g., web servers); other honeypots to emulate services such as ftp, rdp, http, and https, for example, to collect credentials; or a WebLogic honeypot to emulate an Oracle WebLogic server environment. Thus, each different honeypot may emulate a different type of server and may have a different shape. For example, the shape of the server may define the APIs, file structures, etc., used to access this server. A customer 507 (for example, of a cloud service provider 502) can decide and select a specific honeypot they want to use after requesting the deployment of honeypots based on the shape / type of honeypots they are interested in. This selection may also be based on the type of service the customer will perform (for example, to collect attacker data on that type of service).

[0112] By implementing these various types of honeypots, it becomes possible to collect different network-based IOCs (Indicators of Compromise). When an attacker request arrives at honeynet 500, the request can be mapped 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 interact with the same honeypot simultaneously, and each honeypot is configured to provide appropriate responses to the attacker in order to deceive them 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, to make the interaction more realistic, the honeypot may have a real server (e.g., a WebLogic server). Through this interaction, the honeynet platform 509 implemented within the environment of the cloud service provider 502 can collect network-based IOCs, including samples of specific malware related to a particular type of attack. A honeynet platform 509 can be provided for deployment, configuring honeynet 500 and various honeypots S1-S3. In certain embodiments, a Docker infrastructure is used to deploy and manage honeypots, with each honeypot being implemented as a Docker container (for example, a bundle of isolated, virtualized software).

[0113] As described above, customer 507 can select various types of honeypots to deploy based on their interests. Since there are multiple different attack types targeting different targets, customer 507 can select the specific honeypot they want from the Docker configuration containers. For example, this could include a Point of Sale (POS) system that provides access to payment information, or a healthcare system that provides access to health records and other PII (personally identifiable information). Therefore, customer 507 may want to collect different types of data by exposing different types of honeypots to a public network (e.g., the internet). Each honeypot can log data about the attacker's actions / interactions in a local persistent store. The honeypot may log raw, unprocessed data, and this data can then be processed locally to generate processed honeypot data. This processing includes log rotation (e.g., rotating data every 5 minutes or at other intervals), log validation (e.g., determining that the 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 can then be sent to the Honeynet Platform 509. The Honeynet Platform 509 then receives the data from the Threat Intelligence Analysis System 506 (e.g., an external service) or an internal version of the Threat Analysis Module 510. This data may be provided. In some cases, either the threat intelligence analysis system 506, 510 can identify the IP addresses of known attackers (for example, detected from log data collected and stored from honeypots scattered 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 could gain kernel-level access from the honeypot and then (for example, using malicious binaries) enter the main network. This could lead to irreparable damage to the cloud service provider 502. Therefore, isolating the honeypot is crucial. In some cases, this isolation can be achieved by implementing honeynet 500 using a third-party service provider (for example, outside the cloud service provider 502 implementing the honeynet platform 509). In this way, even if an attacker manages to penetrate the underlying system beyond the honeypot, they still cannot access cloud service provider 502. However, another way to isolate honeynet 500 is to implement the honeynet within a Docker container and / or on the user's bare metal (for example, an isolated, single-tenant physical machine not shared by other services).

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

[0116] As described above, honeynet 500 may have multiple honeypots. For example, honeynet 500 may have a first honeypot S1 accessible by port P1, a second honeypot S2 accessible by port P2, and a honeypot S3 accessible by port P3. Each of ports P1, P2, and P3 may be accessible on the public network 504. Thus, if an attacker 501 searches from one end of the internet to the other looking for open ports, these ports will be exposed. This is intentional and makes it possible to lure the attacker 501 into the honeypots. Honeynet 500 may be deployed on a single host device (for example, inside or outside the cloud service provider 502). This single host can be containerized so that there are various containers, each containing a honeypot. Other configurations may be implemented if necessary (for example, having multiple hosts for honeynet 500 and / or multiple honeypots in a single container). When a request comes from an entity (for example, an attacker), the type of request and / or the port associated with the request may be used to determine which honeypot to connect to the entity. For example, if the request is to access port P1, the honeynet management system 508 may decide to connect the entity to the S1 honeypot corresponding to port 22, based on the request on port P1.

[0117] It is known that various types of services use specific ports. For example, the SSH service generally uses port 22, and the SMTP service generally uses port 22. Using port 25, the FTP service typically uses port 21, for example. Once honeypot services are deployed within honeynet 500, these services become accessible via the IP addresses assigned to the hosts. These services then function essentially the same as other servers. An attacker 501 can search the internet from one end to the other for IP addresses and find out which ports on each IP address are open. IP addresses with open ports would be prime targets for an attacker. Thus, a honeypot can be built using these specific ports available on the internet. Of course, these ports generally require a password, even in the real world (e.g., ports that are not honeypot ports). In some cases, the password / username combination may be publicly available. However, in other examples, a honeypot may be configured using various known username / password combinations (e.g., username: admin, password: password is a common standard / default password). Although not illustrated here, each honeypot port (e.g., P1-P3) may have a corresponding internal port number that is not known externally. For example, port 22 might be a privileged port exposed to the outside (e.g., requesting login), but the actual port communicating with the honeypot might be a different port number. In this case, the honeynet management service 508 can maintain a mapping between each external / privileged port and its corresponding internal (e.g., unprivileged) port number.

[0118] In some examples, the honeynet management system 508 may be accessible through other ports / unknown ports. The port for the honeynet management system 508 may be selected from a list of randomly used / rarely used ports that an attacker would not likely try to access. In addition, the honeynet management service 508 allows a service (e.g., a customer) to manage and / or control how containers are deployed, how the environment is configured, and how the honeypots operate. In some cases, the configuration settings that the honeynet management system 508 uses to manage and / or control the honeypots can be controlled by the cloud service provider 502 (e.g., more directly by the cloud service provider 502's honeypot platform 509). In some cases, the controller of the honeypot platform 509 operates in both the control plane (e.g., for controlling the honeynet 500) and the data plane (e.g., for fetching data associated with the honeynet 500). The honeypot platform 509 may also include a synchronization unit configured to synchronize the logging of data about interactions received from the honeypots. The honeypot platform 509 may also include a statistics collection unit. The statistics collection unit can be configured to aggregate the collected data (e.g., system logs).

[0119] As mentioned above, instead, honeynet 500 could be implemented within a cloud service provider 502 that controls honeynet 500 (for example, honeynet 512). This is obviously more dangerous from a security standpoint. This is because if an attacker 501 manages to escape from the container hosting the honeypot, they could potentially gain access to other personal / secure information and / or resources of the cloud service provider 502. Hosting honeynet 500 by a third-party provider would mitigate this risk. However, there are some merits and advantages to hosting honeynet 510 within the cloud service provider 502. For example, a threat analysis system 510 could access attacker data specific to these attackers who want to try to exploit that particular service provider. One example is Oracle's WebLogic servers. Attacks that want to hack into Oracle's cloud infrastructure services... An attacker would likely look for a WebLogic server on port 80 or port 443. By having an emulated WebLogic server as a honeypot to lure attackers, Oracle would be able to collect useful data about attackers who are intentionally targeting known vulnerabilities in Oracle.

[0120] Using a similar example, Oracle might choose to build a honeynet like honeynet 512 residing within its OCI (Oracle Cloud Infrastructure) service. To make the honeypot appear more realistic, honeypot platform 509 could configure honeynet 512 to look like a real Oracle server, even though it's merely an emulation of a server in a container. This should work, as an attacker attempting to hack Oracle could see the WebLogic server as evidence of having penetrated OCI. Thus, making the honeypot a resident service provider-specific honeypot can help catch sophisticated attackers targeting specific OCI applications (for example, because the attacker is aware of specific internal vulnerabilities).

[0121] Another example of configuring a honeypot to look more authentic (for example, in the Oracle example, making it appear as if it is Oracle, even though it is hosted by Oracle) is to design the honeypot to look like a Fusion Applications frontend (or other application development suite). Once an attacker initiates a session with the honeypot, the attacker may be presented with simulated Fusion data, or may be able to access it. In addition, the honeypot can be configured to be hosted using Oracle's IP address. The honeypot platform 509 can then track and log the interactions the attacker has with the machine, and in some cases, allow the attacker to steal "marked" data. This data is then identifiable when it is found. That is, simulated data can be marked in this way and made accessible to an attacker. If the attacker attempts to use that data outside of the honeypot, the attempt will be discovered, the attacker will be detected, and in some cases, they may be identified.

[0122] Another option would be to set up a pseudo-control plane API that looks like the service provider's control plane API (for example, OCI in this example). It would be configured to look like the traditional API used by that service provider, but with weak credentials that would allow the 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 the attacker from compromising customers who are suspected of sharing a hypervisor. Each session would be tagged, and all network traffic in that tenancy would be monitored. In this way, the honeypot platform 509 would be able to track sophisticated attack patterns and learn what techniques the attacker is using to move between machines.

[0123] Further details will be discussed later, but an IaaS provider may be configured with service tenancy, data plane, control plane, specific subnets, IP addresses, gateways, etc. If the pattern is as shown in Figures 9-11 (e.g., architecture), it would be advantageous to emulate these patterns as closely as possible when configuring the honeypot. This is true whether the honeynet is running locally (e.g., honeynet 512) or externally implemented (e.g., honeynet 500). Therefore, the honeypot platform 509 is designed so that the honeypot itself is not running outside the service provider, such as on a third-party service provider's machine. Even if it's working, it will try to configure the honeypot instance to appear as if it's on the infrastructure of Honeypot Platform 509 hosting the service provider.

[0124] In addition, the honeypot platform 509 may be configured to provide a tool called honeypots as a service, which others (for example, a subscribed customer 507) can use. In this example, the customer wants to run a honeypot to collect their data and protect themselves from attackers without having the computing power itself do the work. Thus, the honeypot platform 509 can provide others with the ability to host any type of honeynet as a service. In one example, this service could be provided via one or more APIs and / or through a subscription service.

[0125] In some examples, a honeynet service may have a single 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., a cloud service provider 502 using honeynet 512) on behalf of customer 507, or it may be hosted within customer 507's 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, different ranges, or specific geographical areas. For example, customer 507 might want a specific honeypot (e.g., a WordPress server) implemented in a specific region (e.g., India). In this example, the honeynet platform 508 would build a honeynet in India (possibly with only that one honeypot) to track attackers targeting WordPress servers in that country. In another example, various honeynets are built using multiple different honeypots already residing in multiple containers, and when a request is made, the honeypot platform 508 automatically deploys the requested type of honeypot container to the appropriate honeynet.

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

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

[0128] In some examples, the computing system hosting the honeynet 600 may have a base operating system and may 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 the RAW HP data 606 in persistent store 608). If an attacker gains access to one of the honeypots S1~SN, their activity can be logged by writing to a file in the RAW HP data 606. This data can be written in JSON format, etc. In some cases, each HP S1~SN may send out different types of data based on the type of server that each HP S1~SN is emulating. For example, each type of server may utilize and / or process different types of data. As an example, SSH data is quite different from mail server data (for example, SMTP).

[0129] In some cases, this data can be sent to the log rotation unit 610 of the data processing system 612. The data processing system 612 is just part of a honeypot management system 614, which is configured to manage honeypots S1-SN together with the visualization system 616. The log rotation unit 610 can rotate the log data at regular intervals (for example, every 5 minutes, or as needed). In some cases, the computing system 600 may not need to be able to control how the honeypot logs the data (for example, whether it logs to one file each day or to different files). Therefore, the log rotation unit 610 is generally configured to rotate the log at specific intervals that are desirable for the data processing system 612 or the host system 600. The log data may be divided into smaller intervals so that it can be synchronized with the HP data synchronization unit 618. However, before sending data to the HP data synchronization unit 618, the data processing system 612 may first validate the data (for example, using the log verification unit 620), scrub the data (for example, using the PII scrub unit 622), and format the data (for example, using the data formatting unit 624). The data verification unit 620 may verify the type of data ingested and ensure that it is the correct type of field of interest to downstream consumers 626 (for example, customers) (for example, if the data is an IP address, whether it is actually a 32-bit address). The PII scrub unit 622 may be configured to scrub personally identifiable information to obfuscate identities that might otherwise be discovered. The data formatting unit 624 may be configured to format the data in JSON format (for example) so that it can be shared with a platform that understands that format (for example, the HP data synchronization unit 618) (for example, later in the pipeline). After processing, the data can be stored in the processed HP data 628 of the persistent store 608.

[0130] In some cases, persistent store 608 is configured as block storage (for example, to save space). Honeypots S1-SN are running (for example, they may be running in parallel) and constantly logging data to block storage, first recorded in raw HP data 606, and then, once processed, recorded in processed HP data 628. In some examples, multiple attackers may connect to a single honeypot. This is possible because each honeypot is an emulated server. Therefore, the same honeypot instance can communicate with multiple attackers simultaneously (for example, by type), but that single honeypot appears to each attacker as if it were an individual instance. However, the emulated honeypot instance has a given set with each attacker. The instance is stateful only within that instance. Therefore, when an attacker logs out, and a new login occurs, a new emulation of the same instance can be created. However, it is possible to write logs for all attackers on the same instance in parallel.

[0131] As mentioned above, it is advantageous to make the emulated server appear to the attacker as a real server. This allows the attacker to stay logged in for a longer period, enabling the collection of more data. It also tricks the attacker into attempting more advanced techniques, which can then be logged and analyzed for learning. Techniques to make the emulated environment appear real include providing a UI (user interface), creating fake accounts that the attacker can access, and / or running instances and / or sessions on a bare-metal machine. As described above, honeypots S1-SN are implemented in Docker containers (or other types of containers). Such containers are virtual environments that emulate each type of server or service requested. Each honeypot S1-SN is a virtual container emulating an environment. If a hacker requests a list of file systems, it is advantageous to respond with an appropriate response that makes the emulated environment appear real. For example, in the case of a web server, the response could indicate to the attacker that the server is running Apache on port 80. Furthermore, a honeypot can create a list of files that appear to be standard files stored on the system where Apache was actually running.

[0132] As briefly mentioned above, an attacker's session may be stateful while the attacker is logged into the honeypot. In some cases, the session may be refreshed after a certain period (e.g., 5 minutes). Since most attacks are automated and last only a few seconds, 5 minutes is sufficient time for a single session. However, in some cases, the session may remain active while the attacker is logged in and interacting with the honeypot (e.g., making requests).

[0133] Once data is logged and processed, it can be returned directly to the honeypot platform system 602, for example, the HP data synchronization unit 618. The synchronization unit 618 can be configured to fetch data from the processed HP data 628 at regular intervals (e.g., every 5 minutes). The synchronization unit helps to synchronize the data feeds at regular intervals, so no data is lost. The synchronization unit 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, rebuild, 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. In addition, the system statistics collection unit 632 is configured to collect information about system logs or other log information. The system statistics collection unit 632 may be implemented as part of the control plane of the honeypot platform system 602 and may also communicate with the visibility 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 perform checksums on the data to see if there is any mismatched data and, in some cases, recover files. This is advantageous if an attacker actually infiltrates the honeypot platform system 602 (for example, if the computing system hosting honeynet 600 is the same computer hosting honeypot platform system 602) and makes some changes. The monitoring and alerting system 634 can then detect downstream customers, third-party services (for example, honeynet Alerts can be sent to the computing system hosting the 600 and / or honeypot platform system 602. The logger 632 can be configured to present the logged data to a UI or to other applications to prepare the data for visualization.

[0134] Figure 7 is a flowchart illustrating an exemplary method 700 for performing the techniques described herein. All or part of Method 700 (or other processes or variations and / or combinations thereof described herein) may be performed under the control of one or more computer systems comprising executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that runs collectively on one or more processors by software, hardware, or a combination thereof. The code may be stored, for example, on a computer-readable storage medium in the form of a computer program containing multiple instructions executable by one or more processors. The computer-readable storage medium is a non-temporary storage medium. Method 700 may be performed by one or more of the following computing systems, or a combination thereof: the data center 302 in Figure 3, the honeypot server 400 in Figure 4, the honeynet 500 and / or honeypot platform 509 in Figure 5, or the honeynet 600 and / or honeypot platform system 602 in Figure 6.

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

[0136] In block 704, method 700 allows a computing instance to lure 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 IPs assigned to honeypots exposed on a public network (e.g., the internet). The luring step may also include exposing the login credentials of the honeypot, but in most cases, exposing ports will be sufficient to lure an attacker, because there are many username / password combinations that are widely known to attackers and the general public.

[0137] In block 706, method 700 allows a computing instance to receive a first request from an attacker. In some cases, the first request may be a request concerning the instance and / or may include request characteristics. The first request is typically a request to log in to a service located on the other side of a port of interest to the attacker. The first request characteristics may identify the port from which the request was sent, the type of service being requested, the type of action being requested, and so on.

[0138] In block 708, method 700 describes how a computing instance selects from among multiple honeypot servers based on at least some of the request characteristics and honeypot types. A specific honeypot server can be identified. For example, if an attacker requests access to port 25, and port 25 corresponds to an SMTP server, a computing instance can identify a honeypot emulating an SMTP server for that attacker. In this example, the request characteristic is information that identifies either port 25 or the request to log in to an SMTP (mail) server. Using this information, the computing instance can identify an SMTP honeypot for this possible connection (for example, based on a mapping of characteristics to types). The specific honeypot identified in this example is an SMTP honeypot.

[0139] In block 710, method 700 allows a compute instance to establish a session with an attacker to connect to a specific honeypot. Thus, a short-term (e.g., 5 minutes) state session may be established. During the session, the attacker has privileged access to the identified specific 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] In block 712, method 700 allows a specific honeypot server connected to an attacker to generate a response to a second request from the attacker. The second request may be made after the session has been established and will therefore be received from the logged-in attacker. The second request may be a request to spin up a virtual computing instance or a request to access a secure resource. Essentially, the second request can be any type of request that the attacker might choose to make to the logged-in honeypot server. The generated response must be an appropriate response to that request. For example, if the request was to access data, the response must provide that data or a dummy of that data. If the request was to spin up a virtual computing instance, the response must be a response confirming that the instantiation has been confirmed.

[0141] In block 714, method 700 allows a specific honeypot server to communicate a response to the attacker in response to a second request. As mentioned above, the response must be appropriate to the given request in order to keep the attacker believing that they are connected to a real server.

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

[0143] Exemplary Embodiments As mentioned above, IaaS (Infrastructure as a Service) is a specific 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, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer)). In some cases, the IaaS provider may also supply a wide variety of services associated with these infrastructure components (e.g., billing, monitoring, logging, security, load balancing, and clustering). Therefore, since these services can be policy-based, IaaS users can enforce policies that drive load balancing and application Availability and performance will be maintained.

[0144] In some cases, IaaS customers may access resources and services over a WAN (Wide Area Network), such as the internet, and install the remaining elements of their application stack using the cloud provider's services. For example, a user can log into an IaaS platform, create virtual machines (VMs), install operating systems (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on those VMs. The customer can then use the provider's services to perform various 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. This cloud provider may, but does not have to be, a third-party service specializing in providing IaaS (e.g., offering, renting, or selling). Alternatively, an entity may choose to deploy a private cloud, becoming the provider of its own infrastructure services.

[0146] In some cases, IaaS deployment refers to the process of putting a new application or a new version of an application onto a prepared application server. This may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider at a lower layer than the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may be responsible for dealing with the deployment of the (OS), middleware, and / or application (on top of self-service virtual machines, for example, which can be spun up on demand).

[0147] In some cases, IaaS provisioning can refer to acquiring computers or virtual hosts for use, and even installing the necessary libraries or services on them. In most cases, provisioning is not included in the deployment, and provisioning may need to be done first.

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

[0149] In some examples, infrastructure can consist of many interconnected elements. For instance, it could include one or more VPCs (Virtual Private Clouds), also known as core networks (e.g., a pool of configurable and / or shared computing resources, perhaps on-demand). In some examples, provisions may also be made for how to set up network security and for one or more security group rules that define one or more VMs (virtual machines). Other infrastructure elements, such as load balancers and databases, may also be provisioned. As more infrastructure elements are required and / or added, the infrastructure will evolve incrementally.

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

[0151] Figure 8 is a block diagram 800 showing an example of an IaaS architecture pattern according to at least one embodiment. A service operator 802 is communicably connected to a secure host tenancy 804. The secure host tenancy 804 may comprise a VCN (Virtual Cloud Network) 806 and a secure host subnet 808. In some examples, the service operator 802 may use one or more client computing devices. The client computing devices may be palm-sized portable devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, PDAs) or wearable devices (e.g., Google Glass® head-mounted displays) running software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 10, PalmOS, and supporting the Internet, email, SMS (Short Message Service), Blackberry®, or other communication protocols. Alternatively, a client computing device may be a general-purpose personal computer, including personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. A client computing device may also be, but is not limited to, a workstation computer running various commercially available UNIX® or UNIX-like operating systems, including various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition to the above, the client computing device may be a thin client computer, an internet-enabled gaming system (for example, a Microsoft Xbox gaming console with or without Kinect® gesture input), and / or a personal messaging device, or any other electronic device that can communicate over a network and / or the Internet that has access to the VCN806.

[0152] VCN806 may include LPG (Local Peering Gateway) 810. LPG810 is included in SSH VCN812 and connects via SSH (Secure SSH). SSH VCN812 can be communicatively connected to VCN812. SSH VCN812 may include SSH subnet 814, and SSH VCN812 can be communicatively connected to control plane VCN816 via LPG810, which is included in control plane VCN816. Furthermore, SSH VCN812 can be communicatively connected to data plane VCN818 via LPG810. Control plane VCN816 and data plane VCN818 may be included in service tenancy 819. Service tenancy 819 may be owned and / or operated by an IaaS provider.

[0153] Control Plane VCN816 may include Control Plane DMZ (Demilitarized Zone) Tier 820, which functions as a perimeter network (for example, part of the corporate network between a company's intranet and an external network). DMZ-based servers may have limitations on their operation and can help mitigate security breaches. In addition, DMZ Tier 820 may include one or more LB (Load Balancer) subnets 822, Control Plane App Tier 824 may include application subnets 826, and Control Plane Data Tier 828 may include database subnets 830 (for example, front-end DB subnets and / or back-end DB subnets). The LB subnet 822 included in the control plane DMZ tier 820 can communicate with the application subnet 826 included in the control plane application tier 824 and the internet gateway 834 which may be included in the control plane VCN 816. The application subnet 826 can communicate with the DB subnet 830 included in the control plane data tier 828, the service gateway 836 and the NAT (Network Address Translation) gateway 838. The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0154] The control plane VCN816 may include the data plane mirror application tier 840. The data plane mirror application tier 840 may include application subnet 826. Application subnet 826 included in the data plane mirror application tier 840 may include a VNIC (Virtual Network Interface Controller) 842. VNIC842 can run compute instance 844. Compute instance 844 can connect application subnet 826 of the data plane mirror application tier 840 to application subnet 826 in a communicative manner. Application subnet 826 may be included in the data plane application tier 846.

[0155] The data plane VCN818 may include the data plane application tier 846, the data plane DMZ tier 848, and the data plane data tier 850. The data plane DMZ tier 848 may include LB subnet 822. The LB subnet 822 can be communicatively connected to the application subnet 826 of the data plane application tier 846 and to the internet gateway 834 of the data plane VCN818. The application subnet 826 can be communicatively connected to the service gateway 836 and the NAT gateway 838 of the data plane VCN818. The data plane data tier 850 also includes DB subnet 830. The DB subnet 830 can be communicatively connected to the application subnet 826 of the data plane application tier 846.

[0156] The Internet gateway 834 of the control plane VCN816 and the Internet gateway 834 of the data plane VCN818 can be connected to the metadata management service 852 for communication. The metadata management service 852 is a public internet service. It can be connected to Net 854 for communication. The public internet 854 can be connected to the NAT gateway 838 of the control plane VCN816 and the NAT gateway 838 of the data plane VCN818. The service gateway 836 of the control plane VCN816 and the service gateway 836 of the data plane VCN818 can be connected to the cloud service 856 for communication.

[0157] In some examples, a service gateway 836 of the control plane VCN816 or a service gateway 836 of the data plan VCN818 can make API (Application Programming Interface) calls to a cloud service 856 without going through the public internet 854. API calls from service gateway 836 to cloud service 856 can be one-way; that is, service gateway 836 can make API calls to cloud service 856, and cloud service 856 can send the requested data to service gateway 836. However, cloud service 856 will not initiate API calls to service gateway 836.

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

[0159] The control plane VCN816 may allow users of service tenancy 819 to install or provision desired resources. Desired resources provisioned in the control plane VCN816 may be deployed or used in the data plane VCN818. In some examples, the control plane VCN816 can be isolated from the data plane VCN818, and the data plane mirror application tier 840 of the control plane VCN816 can communicate with the data plane application tier 846 of the data plane VCN818 via VNIC842 which may be included in the data plane mirror application tier 840 and VNIC842 which may be included in the data plane application tier 846.

[0160] In some cases, system users or customers can make requests through the public internet 854, for example, to perform CRUD (Create, Read, Update, and Delete) operations. The public internet 854 can communicate requests to the metadata management service 852. The metadata management service 852 can communicate requests to the control plane VCN 816 through the internet gateway 834. Requests may be received by LB subnets 822 included in the control plane DMZ tier 820. LB subnets 822 may determine that the request is valid, and in accordance with this determination, LB subnets 822 may send the request to application subnets 826 included in the control plane application tier 824. If the request is validated and requires a call to the public internet 854, the call to the public internet 854 may be sent to a NAT gateway 838 that can make calls to the public internet 854. Memory that is requested by the request to be stored can be stored in DB subnets 830.

[0161] In some cases, the data plane mirror app tier 840 is a control plane Direct communication between the control plane VCN816 and the data plane VCN818 can be facilitated. For example, it may be desirable to apply changes, updates, or other suitable modifications to the configuration of resources included in the data plane VCN818. Through VNIC842, the control plane VCN816 can communicate directly with the resources included in the data plane VCN818 and make these changes, updates, or other suitable modifications to the configuration of those resources.

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

[0163] In other embodiments, the LB subnet 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 to be invoked by the IaaS provider's customer without calling the public internet 854. Since the customer's database 1 can be controlled by the IaaS provider and stored in the service tenancy 819, isolated from the public internet 854, the IaaS provider's customer would likely prefer this embodiment.

[0164] Figure 9 is a block diagram 900 showing another exemplary pattern of an IaaS architecture relating to at least one embodiment. A service operator 902 (for example, service operator 802 in Figure 8) can be communicatively connected to a secure host tenancy 904 (for example, secure host tenancy 804 in Figure 8). The secure host tenancy 904 may comprise a virtual cloud network (VCN) 906 (for example, VCN806 in Figure 8) and a secure host subnet 908 (for example, secure host subnet 808 in Figure 8). The VCN906 may comprise a local peering gateway (LPG) 910 (for example, LPG810 in Figure 8). The LPG910 can be communicatively connected to an SSH (Secure Shell) VCN912 (for example, SSH VCN812 in Figure 8) via the LPG810 contained within the SSH VCN912. SSH VCN912 may include an SSH subnet 914 (for example, SSH subnet 814 in Figure 8), and SSH VCN912 may be communicably connected to control plane VCN916 (for example, control plane VCN816 in Figure 8) via an LPG 910 included in control plane VCN916. Control plane VCN916 may be included in service tenancy 919 (for example, service tenancy 819 in Figure 8), and data plane VCN918 (for example, data plane VCN818 in Figure 8) may be included in customer tenancy 921, which may be owned or operated by a user or customer of the system.

[0165] The control plane VCN916 may include a control plane DMZ tier 920 (for example, control plane DMZ tier 820 in Figure 8) which may include an LB subnet 922 (for example, an LB subnet 822 in Figure 8) and an application subnet 926 (for example, an application subnet 826 in Figure 8). The control plane may include an application tier 924 (for example, the application tier 824 in Figure 8) and a data tier 928 (for example, the data tier 828 in Figure 8) which may include a database subnet (for example, similar to the database subnet (for example, multiple) 830 in Figure 8). An LB subnet (for example, multiple) 922 included in the control plane DMZ tier 920 can be communicatively connected to an application subnet (for example, multiple) 926 included in the control plane application tier 924 and an internet gateway 934 (for example, the internet gateway 834 in Figure 8) which can be included in the control plane VCN 916. An application subnet (for example, multiple) 926 can be communicatively connected to a database subnet (for example, multiple) 930 included in the data tier 928, a service gateway 936 (for example, the service gateway in Figure 8), and a network address translation gateway 938 (for example, the NAT gateway 838 in Figure 8). The control plane VCN916 may include a service gateway 936 and a NAT gateway 938.

[0166] The control plane VCN916 may include a data plane mirror app tier 940 (for example, the data plane mirror app tier 840 in Figure 8). The data plane mirror app tier 940 may include an app subnet 926. The app subnet 926 included in the data plane mirror app tier 940 may include a VNIC (Virtual Network Interface Controller) 942 (for example, the VNIC of 842) capable of running a compute instance 944 (for example, similar to compute instance 844 in Figure 8). The compute instance 944 can easily communicate with the app subnet 926 of the data plane mirror app tier 940 and the app subnet 926 that can be included in the data plane app tier 946 (for example, the data plane app tier 846 in Figure 8) via the VNIC 942 included in the data plane mirror app tier 940 and the VNIC 942 included in the data plane app tier 946.

[0167] The Internet gateway 934 included in the control plane VCN916 can communicate with the metadata management service 952 (for example, the metadata management service 852 in Figure 8). The metadata management service 952 can communicate with the public internet 954 (for example, the public internet 854 in Figure 8). The public internet 954 can communicate with the NAT gateway 938 included in the control plane VCN916. The service gateway 936 included in the control plane VCN916 can communicate with the cloud service 956 (for example, the cloud service 856 in Figure 8).

[0168] In some examples, the data plane VCN918 can be included in the customer tenancy 921. In this case, the IaaS provider may provide a control plane VCN916 for each customer, and the IaaS provider may install a unique compute instance 944 included in the service tenancy 919 for each customer. Each compute instance 944 may enable communication between the control plane VCN916 included in the service tenancy 919 and the data plane VCN918 included in the customer tenancy 921. The compute instance 944 makes it possible to deploy or use resources provisioned in the control plane VCN916 included in the service tenancy 919 in the data plane VCN918 included in the customer tenancy 921.

[0169] In another example, an IaaS provider's customers are included in customer tenancy 921. It may have a database. In this example, the control plane VCN916 may have a data plane mirror app tier 940 which may have app subnets 926. The data plane mirror app tier 940 may reside in the data plane VCN918, but does not have to reside in the data plane VCN918. That is, the data plane mirror app tier 940 may have access to the customer tenancy 921, but does not have to reside in the data plane VCN918, or be owned or operated by the IaaS provider's customer. The data plane mirror app tier 940 may be configured to call the data plane VCN918, but does not have to be configured to call entities contained in the control plane VCN916. The customer may want to deploy or use resources in the data plane VCN918 provisioned in the control plane VCN916, and the data plane mirror app tier 940 can facilitate the customer deploying or using resources as desired.

[0170] In some embodiments, a customer of the IaaS provider can apply filters to the data plane VCN918. In these embodiments, the customer can determine which data plane VCN918 is accessible, and the customer may restrict access from the data plane VCN918 to the public internet 954. The IaaS provider may not be able to apply filters to or control access of the data plane VCN918 to any external network or database. By applying filters to and controlling the data plane VCN918 included in the customer tenancy 921, the customer can help isolate the data plane VCN918 from other customers and the public internet 954.

[0171] In some embodiments, a service gateway 936 can invoke a cloud service 956 to access a service that may not exist on the public internet 954, the control plane VCN916, or the data plane VCN918. The connection between the cloud service 956 and the control plane VCN916 or the data plane VCN918 may be disconnected or not continuous. The cloud service 956 may reside on a different network owned or operated by the IaaS provider. The cloud service 956 may be configured to receive calls from the service gateway 936 and not to receive calls from the public internet 954. The cloud service 956 may be isolated from other cloud services 956, and the control plane VCN916 may be isolated from cloud services 956 that are not in the same region as the control plane VCN916. For example, the control plane VCN916 may be located in "Region 1", and the cloud service "Deployment 8" may be located in Region 1 and "Region 2". If a call to deployment 8 is made by a service gateway 936 included in control plane VCN916 located in region 1, this call may be sent to deployment 8 in region 1. In this example, control plane VCN916, or deployment 8 in region 1, does not need to be communicatively connected to or communicating with deployment 8 in region 2.

[0172] Figure 10 is a block diagram 1000 showing another exemplary pattern of an IaaS architecture relating to at least one embodiment. A service operator 1002 (for example, service operator 802 in Figure 8) can be communicatively connected to a secure host tenancy 1004 (for example, secure host tenancy 804 in Figure 8). The secure host tenancy 1004 is a VCN (Virtual Cloud Network). The VCN can comprise a VCN 1006 (for example, VCN806 in Figure 8) and a secure host subnet 1008 (for example, secure host subnet 808 in Figure 8). VCN 1006 can comprise an LPG 1010 (for example, LPG810 in Figure 8) that can communicately connect to SSH VCN 1012 (for example, SSH VCN812 in Figure 8) via an LPG 1010 included in SSH VCN 1012. SSH VCN 1012 can comprise an SSH subnet 1014 (for example, SSH subnet 814 in Figure 8), which can communicately connect to control plane VCN 1016 (for example, control plane VCN816 in Figure 8) via an LPG 1010 included in control plane VCN 1016, and can communicately connect to data plane VCN 1018 (for example, data plane 818 in Figure 8) via an LPG 1010 included in data plane VCN 1018. The control plane VCN1016 and data plane VCN1018 can be included in service tenancy 1019 (for example, service tenancy 819 in Figure 8).

[0173] The control plane VCN1016 may include a control plane DMZ tier 1020 (for example, control plane DMZ tier 820 in Figure 8) which can include load balancer (LB) subnet(s) 1022 (for example, LB subnet(s) 822 in Figure 8), a control plane application tier 1024 (for example, control plane application tier 824 in Figure 8) which can include application subnet(s) 1026 (for example, similar to application subnet(s) 826 in Figure 8), and a control plane data tier 1028 (for example, control plane data tier 828 in Figure 8) which can include database subnet(s) 1030. The LB subnet(s) 1022 included in the control plane DMZ tier 1020 can communicate with the application subnet(s) 1026 included in the control plane application tier 1024, and can communicate with the internet gateway 1034 (for example, the internet gateway 834 in Figure 8), which can be included in the control plane VCN 1016. The application subnet(s) 1026 can communicate with the DB subnet(s) 1030 included in the control plane data tier 1028, and can communicate with the service gateway 1036 (for example, the service gateway in Figure 8) and the NAT (Network Address Translation) gateway 1038 (for example, the NAT gateway 838 in Figure 8). The control plane VCN 1016 may include the service gateway 1036 and the NAT gateway 1038.

[0174] The data plane VCN 1018 may comprise a data plane application tier 1046 (for example, data plane application tier 846 in Figure 8), a data plane DMZ tier 1048 (for example, data plane DMZ tier 848 in Figure 8), and a data plane data tier 1050 (for example, data plane data tier 850 in Figure 8). The data plane DMZ tier 1048 may comprise an LB subnet 1022. The LB subnet 1022 can be communicatively connected to trusted application subnets 1060 and untrusted application subnets 1062 of the data plane application tier 1046, and can be communicatively connected to an internet gateway 1034 included in the data plane VCN 1018. A trusted application subnet 1060 can communicate with service gateway 1036 included in data plane VCN 1018, NAT gateway 1038 also included in data plane VCN 1018, and DB subnet 1030 included in data plane data tier 1050. An untrusted application subnet 1062 can communicate with service gateway 1036 included in data plane VCN 1018 and DB subnet 1030 included in data plane data tier 1050. Data plane data tier 1050 may include DB subnet 1030. The DB subnet 1030 can be connected to the service gateway 1036 included in the data plane VCN 1018 in a communicative manner.

[0175] An untrusted application subnet 1062 may have one or more primary VNICs 1064(1) to (N). VNICs 1064(1) to (N) can be communicatively connected to tenant VMs (virtual machines) 1066(1) to (N). Each tenant VM 1066(1) to (N) can be communicatively connected to each application subnet 1067(1) to (N). Application subnets 1067(1) to (N) can be included in their respective container egress VCNs 1068(1) to (N). Container egress VCNs 1068(1) to (N) can be included in their respective customer tenancies 1070(1) to (N). Each auxiliary VNIC 1072(1) to (N) facilitates communication between the untrusted application subnet 1062 included in the data plane VCN 1018 and the application subnet included in the container egress VCN 1068(1) to (N). Each container egress VCN 1068(1) to (N) may be equipped with a NAT gateway 1038 that can communicate with the public internet 1054 (for example, the public internet 854 in Figure 8).

[0176] The Internet gateway 1034 included in the control plane VCN1016 and the Internet gateway 1034 included in the data plane VCN1018 can communicate with the metadata management service 1052 (for example, the metadata management system 852 in Figure 8). The metadata management service 1052 can communicate with the public internet 1054. The public internet 1054 can communicate with the NAT gateway 1038 included in the control plane VCN1016 and the NAT gateway 1038 included in the data plane VCN1018. The service gateway 1036 included in the control plane VCN1016 and the service gateway 1036 included in the data plane VCN1018 can communicate with the cloud service 1056.

[0177] In some embodiments, the data plane VCN1018 can be integrated with the customer tenancy 1070. This integration may be useful or desirable for the IaaS provider's customer in certain cases, such as when they require support when executing code. The customer may provide executable code that may be destructive, communicate with other customer resources, or produce undesirable effects. Accordingly, the IaaS provider may decide whether or not to execute the code that the customer has provided to the IaaS provider.

[0178] In some examples, an IaaS provider's customer might request the IaaS provider to grant temporary network access to attach to a dataplane tier app 1046. The code to perform this function might run in VMs 1066(1)-(N), and the code might not need to be configured to run elsewhere on the dataplane VCN 1018. Each VM 1066(1)-(N) might be connected to a single customer tenancy 1070. Each container 1071(1)-(N) contained within VMs 1066(1)-(N) might be configured to run this code. In this case, there might be two isolations (for example, a container 1071(1)-(N) that may be contained within at least one VM 1066(1)-(N) in an untrusted app subnet 1062 1062 running the code). Having two isolations would help prevent erroneous or undesirable code from damaging the IaaS provider's network or the networks of different customers. Containers 1071(1)~(N) may be communicatively connected to customer tenancy 1070 and may be configured to send or receive data from customer tenancy 1070. 1)~(N) do not need to be configured to send or receive data from other entities in the data plane VCN1018. Once the code execution is complete, the IaaS provider may terminate or discard containers 1071(1)~(N).

[0179] In some embodiments, a trusted application subnet 1060 may execute code owned or operated by the IaaS provider. In this embodiment, a trusted application subnet 1060 may be communicatively connected to a database subnet 1030 and configured to perform CRUD operations in the database subnet 1030. An untrusted application subnet 1062 may be communicatively connected to a database subnet 1030, but in this embodiment, an untrusted application subnet 1062 may be configured to perform read operations in the database subnet 1030. Containers 1071(1) to (N), which may be included in each customer's VM 1066(1) to (N) and capable of executing code from the customer, do not need to be communicatively connected to the database subnet 1030.

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

[0181] Figure 11 is a block diagram 1100 showing another exemplary pattern of an IaaS architecture relating to at least one embodiment. A service operator 1102 (for example, service operator 802 in Figure 8) can be communicatively connected to a secure host tenancy 1104 (for example, secure host tenancy 804 in Figure 8). The secure host tenancy 1104 may comprise a virtual cloud network (VCN) 1106 (for example, VCN806 in Figure 8) and a secure host subnet 1108 (for example, secure host subnet 808 in Figure 8). VCN1106 may comprise an LPG1110 (for example, LPG810 in Figure 8) that can be communicatively connected to an SSH VCN1112 (for example, SSH VCN812 in Figure 8) via an LPG1110 contained in the SSH VCN1112. SSH VCN1112 may have an SSH subnet 1114 (for example, SSH subnet 814 in Figure 8), and SSH VCN1112 may be communicatively connected to control plane VCN1116 (for example, control plane VCN816 in Figure 8) via an LPG1110 included in control plane VCN1116, and may be communicatively connected to data plane VCN1118 (for example, data plane 818 in Figure 8) via an LPG1110 included in data plane VCN1118. Control plane VCN1116 and data plane VCN1118 may be included in service tenancy 1119 (for example, service tenancy 819 in Figure 8).

[0182] Control plane VCN1116 can include control plane DMZ tier 1120 (for example, control plane DMZ tier 820 in Figure 8) which can include LB subnet(s) 1122 (for example, LB subnet(s) 822 in Figure 8) and application subnet(s) 1126 (for example, application subnet(s) in Figure 8 The system may include a control plane app tier 1124 (for example, control plane app tier 824 in Figure 8) which may include a DB subnet(s) 1130 (for example, DB subnet(s) 1030 in Figure 10) which may include a DB subnet(s) 1030 in Figure 10. The LB subnet(s) 1122 included in the control plane DMZ tier 1120 can communicate with the application subnet(s) 1126 included in the control plane application tier 1124, and can communicate with the internet gateway 1134 (for example, the internet gateway 834 in Figure 8), which can be included in the control plane VCN 1116. The application subnet(s) 1126 can communicate with the DB subnet(s) 1130 included in the control plane data tier 1128, and can communicate with the service gateway 1136 (for example, the service gateway in Figure 8) and the NAT (Network Address Translation) gateway 1138 (for example, the NAT gateway 838 in Figure 8). The control plane VCN 1116 may include the service gateway 1136 and the NAT gateway 1138.

[0183] The data plane VCN1118 may comprise a data plane application tier 1146 (for example, data plane application tier 846 in Figure 8), a data plane DMZ tier 1148 (for example, data plane DMZ tier 848 in Figure 8), and a data plane data tier 1150 (for example, data plane data tier 850 in Figure 8). The data plane DMZ tier 1148 may comprise an LB subnet 1122. The LB subnet 1122 can be communicatively connected to trusted application subnets 1160 (for example, trusted application subnet 1060 in Figure 10) and untrusted application subnets 1162 (for example, untrusted application subnet 1062 in Figure 10) of the data plane application tier 1146, and can be communicatively connected to an internet gateway 1134 included in the data plane VCN1118. A trusted application subnet 1160 can communicate with the service gateway 1136 included in data plane VCN 1118, the NAT gateway 1138 included in data plane VCN 1118, and the DB subnet 1130 included in data plane data tier 1150. An untrusted application subnet 1162 can communicate with the service gateway 1136 included in data plane VCN 1118 and the DB subnet 1130 included in data plane data tier 1150. Data plane data tier 1150 may include a DB subnet 1130. A DB subnet 1130 can communicate with the service gateway 1136 included in data plane VCN 1118.

[0184] An untrusted application subnet (multiple) 1162 can have primary VNICs 1164(1) to (N). VNICs 1164(1) to (N) can communicate with tenant VMs (virtual machines) 1166(1) to (N) residing in the untrusted application subnet (multiple) 1162. Each tenant VM 1166(1) to (N) can execute code in its respective container 1167(1) to (N) and can communicate with application subnet 1126. Application subnet 1126 can be included in dataplane application tier 1146. Dataplane application tier 1146 can be included in container egress VCN 1168. Each auxiliary VNIC 1172(1) to (N) facilitates communication between the untrusted application subnet (multiple) 1162 included in dataplane VCN 1118 and the application subnet included in container egress VCN 1168. The container egress VCN1168 may include a NAT gateway 1138 that can communicate with the public internet 1154 (for example, the public internet 854 in Figure 8).

[0185] The Internet gateway 1134 included in the control plane VCN1116 and the Internet gateway 1134 included in the data plane VCN1118 can communicate with the metadata management service 1152 (for example, the metadata management system 852 in Figure 8). The metadata management service 1152 can communicate with the public internet 1154. The public internet 1154 can communicate with the NAT gateway 1138 included in the control plane VCN1116 and the NAT gateway 1138 included in the data plane VCN1118. The service gateway 1136 included in the control plane VCN1116 and the service gateway 1136 included in the data plane VCN1118 can communicate with the cloud service 1156.

[0186] In some cases, the architecture pattern shown in block diagram 1100 of Figure 11 can be considered an exception to the architecture pattern shown in block diagram 1000 of Figure 10, and the architecture pattern shown in block diagram 1100 would be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customers (for example, when the regions are isolated). Each customer has real-time access to each container 1167(1)~(N) contained within VM 1166(1)~(N). Each container 1167(1)~(N) can be configured to call each auxiliary VNIC 1172(1)~(N) contained within application subnet 1126 of data plane application tier 1146, which can be included in container egress VCN 1168. The auxiliary VNICs 1172(1)~(N) can send calls to NAT gateway 1138. NAT gateway 1138 can send such calls to the public internet 1154. In this example, containers 1167(1)-(N), which customers can access in real time, can be isolated from the control plane VCN1116 and from other entities included in the data plane VCN1118. Furthermore, containers 1167(1)-(N) can be isolated from other customer resources.

[0187] In another example, a customer can use containers 1167(1) to (N) to invoke cloud service 1156. In this example, the customer may execute code in containers 1167(1) to (N) that requests a service from cloud service 1156. Containers 1167(1) to (N) can send this request to auxiliary VNICs 1172(1) to (N). Auxiliary VNICs 1172(1) to (N) can send the request to the NAT gateway. The NAT gateway can send the request to the public internet 1154. The public internet 1154 can send the request via internet gateway 1134 to LB subnet 1122, which is included in control plane VCN 1116. In response to the request being deemed valid, the LB subnet 1 can send the request to application subnet 1126. Application subnet 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, and 1100 may have components other than those shown. Furthermore, the illustrated embodiments are only some examples of cloud infrastructure systems that may incorporate embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown, may combine two or more components, or may have different configurations or arrangements of components.

[0189] In certain embodiments, a self-service, subscription-based system is provided with flexible scheduling. This may include a suite of applications, middleware, and database service offerings delivered to the customer in a trouble-free, reliable, and highly available secure manner. An example of such an IaaS system is OCI (Oracle Cloud Infrastructure) provided by the assignee of this application.

[0190] Figure 12 shows an example of a computer system 1200 in which various embodiments of the present disclosure may be implemented. Any of the computer systems described above may be implemented using system 1200. As shown in the figure, 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. The storage subsystem 1218 includes a tangible computer-readable storage medium 1222 and system memory 1210.

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

[0192] The processing unit 1204, which can be implemented as one or more integrated circuits (for example, conventional microprocessors or microcontrollers), controls the operation of the computer system 1200. The processing unit 1204 may include one or more processors. These processors may include single-core processors or multi-core processors. In certain embodiments, the processing unit 1204 may be implemented as one or more independent processing units 1232 and / or 1234, each containing either a single-core processor or a multi-core processor. In other embodiments, the processing unit 1204 may be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0193] In various embodiments, the processing unit 1204 can execute various programs in response to program code and can maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside in the processor(s) 1204 and / or the storage subsystem 1218. With appropriate programming, the processor(s) 1204 can provide the various functions described above. The computer system 1200 may further include a processing acceleration device 1206. The processing acceleration device 1206 may include a DSP (Digital Signal Processor) and / or a dedicated processor, etc.

[0194] The I / O subsystem 1208 may include a user interface input device and a user interface output device. The user interface input device may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or display. The user interface input device may include a touchscreen, scroll wheel, click wheel, dial, buttons, switches, keypad, voice input device with a voice command recognition system, microphone, and other types of input devices. The user interface input device may also include motion detection devices and / or gesture recognition devices, such as a Microsoft Kinect® motion sensor, which enables the user to control and interact with input devices, such as a Microsoft Xbox® 360 game controller, through a natural user interface using gesture commands and voice commands. The user interface input device may also include eye gesture recognition devices, such as a Google Glass® blink detection device, which detects the user's eye behavior (e.g., blinking while taking a picture and / or making a menu selection) and translates the eye gesture into input to an input device (e.g., Google Glass®). In addition, the user interface input device may include a voice recognition detection device that enables the user to interact with a voice recognition system (e.g., Siri® Navigator) by voice commands.

[0195] Furthermore, user interface input devices include, but are not limited to, 3D mice, joysticks or pointing sticks, gamepads 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 rangefinders, and eye-tracking devices. In addition, user interface input devices may include, for example, medical image input devices such as computed tomography, magnetic resonance imaging, positron emission tomography, and ultrasound devices. User interface input devices may also include, for example, audio input devices such as MIDI keyboards and digital musical instruments.

[0196] The user interface output device may include non-visual display devices such as display subsystems, indicator lights, or audio output devices. The display subsystem may include flat panel display devices such as those using CRTs (cathode ray tubes), LCDs (liquid crystal displays), or plasma displays, projection devices, touchscreens, etc. In general, the use of the term “output device” is intended to include all kinds of devices and mechanisms for outputting information from the computer system 1200 to a user or another computer. For example, the user interface output device may include, but is not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, drawing devices, audio output devices, and modems.

[0197] The computer system 1200 may consist of a storage subsystem 1218 which includes software elements currently located in the system memory 1210, as illustrated. The system memory 1210 may store program instructions that can be loaded and executed on the processing unit 1204, and data generated during the execution of these programs.

[0198] Depending on the configuration and type of the computer system 1200, the system memory 1210 may be volatile memory (such as RAM (Random Access Memory)) and / or non-volatile memory (such as ROM (Read-Only Memory) or flash memory). RAM typically contains data and / or program modules that the processing unit 1204 can access immediately and / or are currently operating on and executing. In some implementations, the system memory 1210 may contain several different types of memory, such as SRAM (Static RAM) or DRAM (Dynamic RAM). In some implementations, during startup, etc., the system memory 1210 contains data within the computer system 1200. The BIOS (Basic Input / Output System), which includes basic routines that help transfer information between components, may typically be stored in ROM. For example, system memory 1210 may include application programs 1212, which may include client applications, web browsers, mid-tier applications, RDBMS (relational database management systems), program data 1214, and an operating system 1216. For 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.

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

[0200] The storage subsystem 1200 may also include a computer-readable storage medium reader 1220 which can be further connected to the computer-readable storage medium 1222. Together with the system memory 1210, and optionally in combination with the system memory 1210, the computer-readable storage medium 1222 may comprehensively represent remote storage devices, local storage devices, fixed storage devices, and / or removable storage devices, as well as storage media for temporarily and / or permanently containing, storing, transmitting, and retrieving computer-readable information.

[0201] The computer-readable storage medium 1222 containing code or a portion of code may also include, but is not limited to, any suitable medium known or used in the art, including storage and communication media such as volatile and non-volatile media, removable and fixed media, implemented by any method and technique 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 technologies, CD-ROM, DVD (Digital Versatile Disk), or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices, or other tangible computer-readable media. This may also include intangible computer-readable media such as data signals, data transmissions, or other media that may be used to transmit desired information, and other media that may be accessed by the computing system 1200.

[0202] As an example, the computer-readable storage medium 1222 includes a hard disk drive that reads or writes to a fixed non-volatile magnetic medium, a magnetic disk drive that reads or writes to a removable non-volatile magnetic disk, and an optical disk drive that reads or writes to a removable non-volatile optical disk or other optical medium such as a CD-ROM, DVD, or Blu-Ray® disc. The computer-readable storage medium 1222 may include, but is not limited to, Zip® drives, flash memory cards, USB (Universal Serial Bus) flash drives, SD (Secure Digital) cards, DVD discs, digital videotapes, etc. The computer-readable storage medium 1222 may also include non-volatile memory-based SSDs (Solid-State Drives), such as flash memory-based SSDs, enterprise flash drives, and solid-state ROMs; volatile memory-based SSDs, such as solid-state RAM, dynamic RAM, static RAM, and DRAM-based SSDs; and hybrid SSDs using MRAM (Magnetoresistive RAM) SSDs and SSDs based on a combination of DRAM and flash memory. These disk drives and their associated computer-readable media may provide non-volatile storage for computer-readable instructions, data structures, program modules, and other data for the computer system 1200.

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

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

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

[0206] In addition, the communication 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 is continuous or infinite and essentially has no clear end. Applications that generate continuous data include, for example, sensor data applications, tickers, and network performance measurement tools (e.g., network monitoring and traffic monitoring). Examples may include clickstream management applications, clickstream analysis tools, and vehicle traffic monitoring.

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

[0208] Computer system 1200 can be one of a variety of types, including palm-sized portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), PCs, workstations, mainframes, kiosks, server racks, or other data processing systems.

[0209] Due to the ever-changing nature of computers and networks, the description of the computer system 1200 shown in the figure is merely an example. Many other configurations are possible, having more or fewer components than the system shown in the figure. For example, customized hardware may be used, and / or certain elements may be implemented by hardware, firmware, software (including applets), or a combination thereof. Furthermore, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosures and teachings contained herein, those skilled in the art will be able to see other ways and / or methods for implementing various embodiments.

[0210] While specific embodiments of the Disclosure have been described, various modifications, alternatives, alternative configurations, and equivalents are also included within the scope of the Disclosure. The embodiments of the Disclosure are not limited to operation within a particular data processing environment, but can freely operate within multiple data processing environments. In addition, while a specific sequence of transactions and steps has been used to illustrate the embodiments of the Disclosure, it should be apparent to those skilled in the art that the scope of the Disclosure is not limited to the described sequence of transactions and steps. The various features and aspects of the embodiments described above may be used individually or in combination.

[0211] Furthermore, while embodiments of this disclosure have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments of this disclosure may be implemented using hardware alone, software alone, or a combination thereof. Various processes described herein can be implemented on different processors, either the same processor or any combination thereof. Thus, wherever a component or module is described as being configured to perform a particular operation, such configuration can be achieved, for example, by designing electronic circuitry to perform this operation, by programming programmable electronic circuitry (such as a microprocessor) to perform this operation, or by any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, prior art for inter-process communication, and different pairs of processes may use different techniques, and the same pair of processes may use different techniques at different times.

[0212] The specification and drawings should be considered, as appropriate, as examples only and not strict. However, additions, subtractions, deletions, other changes and modifications to them should not deviate from the broad intent and scope set forth in the attached claims. It will be clear that this is also possible. Therefore, although specific embodiments of the present disclosure have been described, these are not limiting. Various modifications and equivalents are also included in the appended claims.

[0213] The terms “a,” “an,” and “the,” as well as similar terms of reference, in the context describing the disclosed embodiments (in particular, in the context of the appended claims), should be interpreted as including both singular and plural, to the extent that there is no contradiction. The terms “comprising,” “having,” “including,” and “containing” should be interpreted as non-exclusive unless otherwise noted (i.e., “including, but not limited to”). The term “connected” should be interpreted as including, attaching, or joining together, even if something is intervening. The ranges given to values ​​in this specification are merely a means of avoiding individual reference to each individual value within that range, unless otherwise specifically indicated herein, and each individual value is included in the specification as if it were described individually. All methods described herein can be performed in any suitable order, to the extent that there is no contradiction. Any examples or exemplary phrases provided herein (e.g., "such as") are for the sole purpose of illustrating embodiments of the disclosure and, unless specifically claimed, do not limit the scope of the disclosure. No phrase in this specification should be construed as indicating that any unclaimed element is essential for carrying out the disclosure.

[0214] Disjunctive phrases, such as "at least one of X, Y, or Z," should be understood as being within the range of commonly used expressions to indicate that an item or term, unless specifically stated otherwise, could be any combination of X, Y, Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive phrases are not intended to imply, nor are they required, that a particular embodiment must present at least one of X, at least one of Y, or at least one of Z.

[0215] Preferred embodiments of the Disclosure, including embodiments known to be best for carrying out the Disclosure, are described herein. Those skilled in the art will recognize variations of these preferred embodiments by reading the above description. Such variations can be appropriately used by those skilled in the art, and the Disclosure may be carried out in ways other than those specifically described herein. Therefore, the Disclosure includes all variations of the subject matter and equivalents of the claims appended herein as permitted by applicable law. Furthermore, any combination of the elements described above in those anticipated variations is also included in the Disclosure unless specifically indicated herein.

[0216] All references cited herein, including publications, patent application documents, and patent documents, are incorporated herein by reference to the same extent as if each reference were specifically cited and included in its entirety herein.

[0217] While the aspects of the disclosure have been described in the above specification with reference to specific embodiments, those skilled in the art will see that the disclosure is not limited thereto. The various features and aspects of the disclosure described above may be used individually or in combination. Furthermore, embodiments may be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. The specification and accompanying drawings should therefore be considered illustrative rather than restrictive.

Claims

1. It is a method, The computing system includes the step of providing a plurality of honeypot servers, each of the plurality of honeypot servers includes a honeypot type, and the method further includes the step of providing a plurality of honeypot servers, each of which includes a honeypot type, The computing system receives a first request from an attacker that is associated with the characteristics of a specific honeypot type, The computing system establishes a session with the attacker to connect to a specific honeypot server of a specific honeypot type. The steps include: the specific honeypot server of the computing system communicates a response to the attacker in response to the first request; The computing system records at least one of the following: data relating to the attacker and data relating to one or more interactions between the attacker and the specific honeypot server. The computing system includes the step of the specific honeypot server generating a response to a second request from the attacker, The second request above requests the instantiation of a virtual computing instance, A method for indicating that the virtual computing instance has been successfully instantiated as a response to the second request.

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

3. The method according to 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 an SSH (Secure Shell) port 22, an FTP (File Transfer Protocol) port 21, or an SMTP (Simple Mail Transfer Protocol) port 25.

4. The method according to claim 1 or 2, further comprising the step of identifying a particular honeypot server from among the plurality of honeypot servers based on the characteristics of the first request and at least a portion of the honeypot types.

5. The method according to 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. A system, wherein the system is One or more processors, The system comprises non-temporary computer-readable memory containing instructions, and the instructions, when executed by one or more processors, cause the system to perform an operation, and the operation is The computing system includes providing a plurality of honeypot servers, each of which includes a honeypot type, and the operation further includes: The computing system receives a first request from the attacker that is associated with the characteristics of a specific honeypot type, The computing system establishes a session with the attacker to connect to a specific honeypot server of a specific honeypot type, The specific honeypot server of the computing system communicates a response to the attacker in response to the first request, The computing system records at least one of the following: data relating to the attacker and data relating to one or more interactions between the attacker and the specific honeypot server. The computing system includes the specific honeypot server generating a response to a second request from the attacker, The second request above requests the instantiation of a virtual computing instance, The system's response to the second request indicates that the virtual computing instance has been successfully instantiated.

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

8. The system according to 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 an SSH (Secure Shell) port 22, an FTP (File Transfer Protocol) port 21, or an SMTP (Simple Mail Transfer Protocol) port 25.

9. The system according to any one of claims 6 to 8, further comprising the computing system identifying the particular honeypot server from among the plurality of honeypot servers based on the characteristics of the first request and at least a portion of the honeypot types.

10. The system according to 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 perform the method according to any one of claims 1 to 5.

Images