Efficient implementation of honeypot devices to detect wide-scale network attacks

The present disclosure generally relates to enabling efficient implementation of honeypot devices in a honeypot service environment. Each honeypot device can be implemented as a virtualized device, executing software modified from a production version of a device such that interactions with the honeypot device closely match interactions with a production device. By using virtualization, each honeypot device can be reset to a known good state when a potential security breach occurs. Because network-based attacks are often wide-spread, the honeypot service environment can deduplicate attacks that occur at a large number of devices, discarding duplicate attack traffic to reduce overall load on the environment. While deduplication can be inappropriate for production environments (given the corresponding data loss), deduplication in a honeypot environment can reduce load while still enabling detection of a network attack.

BACKGROUND

Cloud computing, in general, is an approach to providing access to information technology resources through services, such as Web services, where the hardware and/or software used to support those services is dynamically scalable to meet the needs of the services at any given time. In cloud computing, elasticity refers to network-delivered computing resources that can be scaled up and down by the cloud service provider to adapt to changing requirements of users. The elasticity of these resources can be in terms of processing power, storage, bandwidth, etc. Elastic computing resources may be delivered automatically and on-demand, dynamically adapting to the changes in resource requirement on or within a given user's system. For example, an entity might use a cloud service to host a large online streaming service, set up with elastic resources so that the number of web servers streaming content to users scale up to meet bandwidth requirements during peak viewing hours, and then scale back down when system usage is lighter.

Malicious entities occasionally attempt to disrupt the operations of Web services via network-based attacks (“network attacks”). These attacks typically transmit information to a target device via a network with the intent of disabling or hijacking functionality of the device. While any network attack can be problematic, attacks that attempt to hijack functionality are particularly problematic, as a hijacked device can then itself be used for malicious purposes. For example, a hijacked device can be used to implement further network attacks, sometimes forming a “bot net” comprised of multiple hijacked devices. In some instances, hijacked devices can be used to collect information that is not intended to be made available over a network. For example, an “Internet-of-Things” (or IoT) device—a term which as used herein generally refers to a computing device capable of communicating information about a local physical environment, such as a current temperature—may be hijacked to report private information about a local physical environment, such as a video feed of an in-house camera. The richness of information of IoT devices, paired with an all-to-common lack of secureness of such devices, makes these devices prime targets for network attacks. Often, such attacks occur at a massive scale. For example, an attacker may simultaneously attempt to hijack hundreds, thousands, or millions of devices.

DETAILED DESCRIPTION

Generally described, aspects of the present disclosure relate to implementation of a honeypot service environment, enabling client devices to configure virtualized honeypot devices that attract and detect malicious network traffic such that network attacks represented by the traffic can be analyzed and addressed. As used herein, the term “honeypot device” (or simply “honeypot”) refers to a computing device that appears to serve a legitimate purpose, but is in fact created to lure malicious traffic to the device such that the traffic can be captured and analyzed, and configured such that a security breach of the honeypot does not pose provide access to sensitive information or further enable malicious acts. Disclosed herein is a honeypot service environment enabling clients to create virtualized computing devices acting as honeypots, to monitor such honeypots for malicious activity that represents a security breach, and to receive reports of such a breach including traffic monitored as part of the breach. For example, embodiments of the present disclosure may be used to implement a honeypot device that appears to represent an IoT device (referred to herein as an “IoT honeypot”), which type of device is often a frequent target of attack. As discussed herein, use of virtualization technologies can enable creation of high-interaction honeypots, recreating all or a substantial part of a legitimate device's functionalities, while also enabling the honeypot service environment to quickly address breached devices by resetting such devices to a known good state. Moreover, embodiments of the present disclosure can enable efficient handling of wide-scale network attacks, which may be common against IoT devices, by deduplicating attacks within the honeypot service environment. For example, where an attack targets tens, hundreds, or thousands of IoT honeypots in the environment, the environment may select a single IoT honeypot to handle traffic of the attack, reducing the amount of computing resources need to monitor and detect attacks.

In accordance with embodiments of the present disclosure, clients of a honeypot service environment may provide the environment with a device image corresponding to a device that the clients wishes to test for security vulnerabilities, such as an IoT device. A used herein, “device image” generally refers to a set of data, such as contents of a disk drive, sufficient to enable a corresponding device (including a virtual device) to implement a desired functionality. For example, a device image may represent an operating system, software, libraries, etc., such that no additional software is required to implement a device's functionality. Illustratively, where a typical consumer device, such as a physical IoT device used in a production environment, is pre-installed with a specific LINUX™ distribution and software that implements IoT functionality, a device image for the device may also include that distribution and software. In some instances, the software of a device image may be modified in accordance with the image's use as a honeypot device, as opposed to a production device. For example, software of a production device may obtain data from sensors of the device, whereas software of a honeypot device image may obtain data from a “dummy” data file, which file includes data that appears similar to an actual sensor.

On receiving a device image, the honeypot service environment can then provision a virtual computing device with the device image and execute the software of the image, such that the virtual computing device represents a honeypot that appears—from a network perspective—to represent a production device. The honeypot service environment can further expose the honeypot to a network with potentially malicious actors (e.g., the Internet), such that attacks against this type of production device might be directed to the honeypot.

After exposing the honeypot to a network, the honeypot service environment can monitor network traffic to and from the honeypot to detect whether a security breach has occurred. As discussed in more detail below, the honeypot service environment may maintain one or more rules related to network attacks, and compare traffic to a honeypot to the rules to identify security breaches. For example, a service may maintain a “whitelist” indicating acceptable network traffic for a honeypot that is not indicative of a security breach, and a “blacklist” indicating network traffic for the honeypot that is indicative of a security breach. Illustratively, the whitelist may identify traffic that the honeypot or a corresponding production device is expected to transmit without external user interaction (e.g., periodic requests to a server of a provider of the device), while the blacklist may identify traffic that should not occur from the honeypot (e.g., traffic that would occur at a production device only from authorized user access of the device, which access is unexpected at the honeypot). In some instances, a client utilizing the service may create such rules. In other instances, the service may be configured with rules for multiple honeypots, in addition to or alternatively to rules of a client. Illustratively, the service may maintain a rule that similar traffic observed at multiple honeypots representing a given type of device (e.g., coordinated traffic to hundreds of devices) is indicative of a network attack.

In accordance with aspects of the present disclosure, the honeypot service environment disclosed herein can further implement de-duplication techniques to reduce computing resources required to operate honeypots for a given type of device (e.g., a given type of IoT device) and to detect attacks on such devices. Generally, honeypots are utilized to monitor and analyze network attacks, such that they can be addressed by developers of a device (or software used by a device). As such, benefits of recording multiple copies of an attack are small or zero relative to recording a single instance of the attack. Moreover, because attacks can be widespread (spanning hundreds, thousands, or millions of devices), absorbing, monitoring, and analyzing multiple copies of an attack can significantly increase computing resources. For example, each honeypot device may be required to receive traffic of an attack and respond to it (as the traffic may not, at that point, be recognized as an attack), requiring computing resource usage of each device in terms of processing power, memory, network bandwidth and the like, and the honeypot service environment may further be required to analyze each set of traffic to determine whether it corresponds to an attack, consuming still more computing resources.

To address this problematic over-usage of computing resources, the honeypot service environment can be configured in embodiments of the present disclosure to de-duplicate multiple related network attacks. Illustratively, where the environment hosts multiple honeypot devices and similar traffic is received at each device, the environment may select a subset of (e.g., one) instances of the traffic to forward to a fewer than all honeypot devices (e.g., one device), while dropping remaining traffic. This may enable the service to monitor and analyze a single instance of a network attack (providing benefits associated with detecting such an attack on the environment), without incurring the resources required to handle all instances of the attack. In some embodiments, a response of the single device may be provided to a source of the one instance of traffic, such that other instances of the traffic go unanswered. In other embodiments, to preserve an appearance of functionality of the multiple honeypot devices, a response of the single device may be provided as a response to all instances of the traffic, such that all attackers receive a copy of the response, thus maintaining an illusion that multiple devices received and processed the traffic. In this manner, the computing resources required to host and manage honeypot devices on a network are reduced.

The foregoing aspects and many of the attendant advantages of this disclosure will become more readily appreciated as the same become better understood by reference to the following description, when taken in conjunction with the accompanying drawings.

FIG. 1depicts an example computing environment100including a honeypot service environment120, client devices102, and malicious devices106. In accordance with embodiments of the present disclosure, clients, via client devices102, may configure the service environment120to provide network-accessible honeypots, intended to capture traffic from malicious devices106represent network attacks to the honeypots.

InFIG. 1, the honeypot service environment120, client devices102, and malicious devices106are in communication via a network104, which may include any wired network, wireless network, or combination thereof. For example, the network104may be wide area network (WAN), including global area networks (GANs) such as the Internet, cable network, satellite network, cellular telephone network, or combination thereof. The network104may be a publicly accessible network, or may be a private or semi-private network, such as a corporate or university intranet. The network104may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network. The network104(as well as networks118and122) can use protocols and components for communicating via the Internet or any of the other aforementioned types of networks. For example, the protocols used by the network104may include Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and the like. Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art and, thus, are not described in more detail herein.

Client devices102and malicious device102illustratively represent any computing device accessing the honeypot service environment102, including for example desktop computers, laptops, smartphones, tablets, e-readers, gaming consoles, and the like. In some instances, malicious devices106may be controlled directly by malicious actors. In other instances, malicious devices106may be controlled indirectly by malicious actors, such as by operation of a virus, spyware, or the like execution on the malicious devices106.

The honeypot service environment120includes a number of elements enabling clients102to configure honeypots within the environment. InFIG. 1, elements of the honeypot service environment120are interconnected by a network08, which illustratively represents an internal network of the honeypot service environment120.

As shown inFIG. 1, the environment120includes a control plane interface122, a data store124, and a set of host devices130implementing virtualized devices134and a device monitor132. The control plane interface122represents one or more devices provide “control plane” functionality of the environment120, such as configuring and managing honeypots. In network computing environments, “control plane” functionality, used to configure a system, can broadly be contrasted with “data plan” functionality, representing use of the configured system. The control plane generally includes one or more control plane computing devices components distributed across and implemented by one or more control servers (collectively represented by interface122). Control plane traffic generally includes administrative operations, such as system configuration and management (e.g., resource placement, hardware capacity management, diagnostic monitoring, and system state information). Thus, in accordance with embodiments of the present disclosure, the control plane interface122can enable client devices102to request creation of honeypots, manage state of honeypots, receive monitoring information of honeypots, and the like.

To facilitate creation of honeypots, the environment120further includes a set of host devices130, which correspond to physical computing devices configured to host one or more virtualized devices134. Illustratively, the host devices130may implement an operating system (in some cases referred to as a “hypervisor”) and software that enables creation of virtualized devices134, such as a LINUX distribution implementing the QEMU™ machine emulator and virtualizor or the Kernel-based Virtual Machine (KVM) Linux module. Each virtualized device134may be configured in accordance with the type of production device desired to be virtualized, for example by matching a CPU type, CPU speed, memory type, memory speed, etc., of a typical production device. Thus, when provisioned with a device image, each virtualized device134can appear, from a network prospective, as a typical production device. However, each virtualized device134can generally be isolated from other devices, such that a “blast radius” of a security breach of the device134is minimized. For example, the virtualized devices134may not have access to a typical production environment that would exist with a corresponding production device. Moreover, the devices134may be configured without access to other virtualized devices134, and limited to accessing external resources through a host device130, which, as discussed below, can detect potential breaches of the device134and revert of a state of the device134to a known good state in the case of such a breach. Device images may be submitted by client devices102through the control plan interface122and stored within the data store124, corresponding to any of a variety of known data stores, such as hard disk drives, solid state drives, network accessible storage devices, storage area networks, etc., for use by host devices130.

In some embodiments, the data store124may further store other information used by the honeypot service environment120. For example, the data store124may include attack vector templates, representing information usable to identify a specific attack (or type of attack) represented by one or more network communications. For example, each attack vector template may include one or more regular expressions identifying a pattern in network communications that represents a specific type of attack (e.g., according to an identifier assigned to the type of attack by, for example, the security community). As discussed below, these templates may be used in identifying attacks against honeypot devices or in generating reports regarding operation of honeypot devices.

In addition to virtualized devices134, host devices130include a device monitor132, representing software executed on the host device130to detect security breaches on a virtualized device132. As discussed in more detail below, each monitor132may compare traffic to or from devices134to a set of rules to determine whether the traffic indicates a security breach of the device134and, if so, to take action in response to that breach, such as transmitting a report to a client device102associated with the device134and resetting the device134to a known good state. In addition and in accordance with embodiments of the present disclosure, a device monitor132may monitor traffic to multiple devices134in order to deduplicate such traffic, reducing computing resource usage of host devices130. While shown inFIG. 1as co-located with virtualized devices134on a host device130, the device monitor132may be partially or entirely implemented in a distinct device. For example, deduplication functionality of a monitor132may be implemented “up stream” from host devices130, such as in a load balancer device included within the network108.

With reference toFIG. 2, illustrative interactions for creating one or more honeypots on the honeypot service environment120will be described. The interactions begin at (1), where a client, utilizing a client device102, submits to the control plane interface122a request for creation of one or more honeypot devices based on a device image, which is illustratively provided by the client device102. As discussed above, the device image illustratively represents software enabling creation of a virtualized device134replicating functionality of a production device, such as a physical IoT device, including software such as an operating system, libraries, applications, etc. The device image is illustratively modified relative to a similar image that may be provisioned onto a physical device, such that production data that would be available to a corresponding production device (e.g., sensor data of a physical environment) is replaced with fabricated data intended to appear, to a malicious device106, as production data. In some instances, the request to create one or more honeypots may also specify configuration information for a virtualized device134, such as hardware to be virtualized to execute the software of the device image (e.g., a processor type and speed, memory type and speed, etc.).

In addition, at (2), the client device102submits to the interface122a set of execution parameters for the honeypot devices. The execution parameters can include options such as a number of honeypot devices to create, a time of execution of the devices, a location of the devices (e.g., geographic, where host devices130exist in various geographic locations; network, where host devices130can assume a variety of network addresses, etc.), or other options relating to implementation of virtualized devices134on the host devices130as the honeypot devices (as opposed to operation of the virtualized devices134themselves, which can be expected to be configured within the device image). In addition, execution parameters can indicate one or more rules for detecting a security breach at the honeypot devices. For example, parameters may include a whitelist of expected, non-breach-indicating traffic from honeypot devices, a blacklist of traffic indicating a security breach, or the like. Execution parameters can further include notification options for the honeypot devices, such as a storage location (e.g., a client device102or other network-based storage) to which to transmit a notification of expected breach and a report of traffic associated with the breach.

At (3), on receiving the request and the execution parameters, the control plane interface122stores the device image within the data store124. In addition, at (4), the interface122instructs the host devices130to implement the one or more honeypots according to the execution parameters. The host devices130, in turn at (5), retrieve the device image from the data store124.

The host devices130can then, at (6), create one or more virtualized devices134(e.g., in number equal to the desired number of honeypots) from the device image. Specifically, the host devices130can generate virtualized devices134corresponding to a desired configuration (e.g., a desired processor type and speed, memory type and speed, network configuration, etc.), provision each device134with access to the device image, and “boot” each virtualized device134. Each virtualized device134may be implemented, for example, as a KVM or QEMU device with an operating system of the host device130. Because each virtualized device134implements a device image intended to replicate functionality of a “real” production device (e.g., as used for non-honeypot purposes, such as installed in a home or business), each virtualized device134illustratively appears—from a network perspective—as such a production device. As such, each virtualized device134represents a honeypot that can be expected to attract network attacks in a manner similar to a production device. In one embodiment, each virtualized device134is configured to communication with the network104with limited or no protections against network attacks, other than protections included within the device image. For example, traffic to the virtualized device134may avoid any firewalls, intrusion detection systems, scanners, or the like. This lack of additional protections can increase a likelihood that the honeypots attract malicious traffic.

With reference toFIG. 3, illustrative interactions will be described for operating a virtualized device134as a honeypot on the honeypot service environment120. The interactions begin at (1), where one or more malicious devices106transmit malicious traffic (e.g., intended to breach security of a honeypot device) to the honeypot device. Because each honeypot device is implemented at a virtualized device134hosted by a host device130, the malicious traffic is received at the host device130. WhileFIG. 3refers to such traffic as “malicious traffic,” the character of the traffic as malicious may not be initially apparent at the host device130or other elements of the environment120.

As discussed above, network attacks against production devices often occur en masse. For example, a bot net of malicious devices106may attempt to conduct a network attack against all known devices of a given type (e.g., a given model of production device, or instances of that device executing a given software version), by transmitting a communication to each known device. However, often only a single instance of an attack need be captured in order to address the attack. Accordingly, it may be unnecessarily taxing on the environment120to service all instances of a network attack. Thus, at (2), the host device130deduplicates the malicious traffic. In one embodiment, deduplication may occur with respect to all communication (e.g., packets) from a given malicious device that includes the same “payload” (e.g., a packet body as opposed to a packet header). For example, deduplication may occur where multiple communications including the same data packet body are transmitted from a single malicious device106to multiple virtualized devices134, such that only a destination network address within a packet header varies among the different communications. In another embodiment, deduplication may occur where multiple communications including the same data body are transmitted from multiple malicious devices106to multiple virtualized devices134, such that only source and destination network addresses within a header varies among the different communications (e.g., packets). In yet another embodiment, deduplication may occur where bodies vary among communications of the traffic, but vary in content that is immaterial to potential security breaches, such as by including randomized data (e.g., in an attempt to avoid detection as a network attack). Illustratively, such content may be specified by a client device102within execution parameters of the honeypot devices. For example, a client device102may specify one or more regular expressions indicating content that is immaterial (or, inversely, the content that is material) to potential breaches, such that deduplication can occur with respect to multiple communications with matching material content.

Deduplication can illustratively occur based on a windowing of traffic, such that all traffic received within a given window (e.g., 10 milliseconds, 100 milliseconds, one second, etc.) is subject to deduplication. In one embodiment, a single instance of a given type of traffic is selected for forwarding after deduplication. In other embodiments, multiple instances (e.g., a maximum number specified in execution parameters) are selected. While deduplication is depicted inFIG. 3as occurring at a host device130, deduplication may additionally or alternatively occur at other devices within a network path to the virtualized device. For example, where virtualized devices134representing honeypots of a given type of device are distributed among multiple host devices130, one or more router or other devices within the network108may obtain all traffic to the given type of device and perform deduplication of that traffic. In some instances, one or more load balancing devices may be utilized to route all traffic to a given type of device to a deduplication device. For example, each load balancing device may inspect traffic to determine a content of that traffic (e.g., by hashing a body of traffic packets) and forward packets with the same or similar content to a deduplication device. Thus, a deduplication device may obtain multiple instances of a given type of malicious traffic and perform deduplication of that traffic.

Thereafter, at (3), the host device130(or other deduplication device), forwards an instance of the malicious traffic to a virtualized device134operating as a honeypot. The device134in turn, processes the traffic and provides a response to the host device130. The host device130may then forward the response as appropriate to the response. For example, if the response is addressed to the malicious device106, the host device130can forward the response to the device106. In some embodiments, where the response is addressed to the malicious device106and other traffic from other malicious devices106was discarded during the de-duplication process, the response of the virtualized device134may also be provided to the other malicious devices106, such that it appears to the other devices106that they have successfully interacted with the device134. If the response is addressed to another network location, the host device130can forward that response to the other network location. For purposes of analyzing network attacks, the content of a response obtained at the host device130is generally sufficient, and as such, further forwarding of traffic from the host device130is not shown inFIG. 3.

Interactions (1)-(4) may occur one or more times during a network attack. For example, a given network attack may depend on a series of interactions between a malicious device106and a honeypot device. Thus, interactions (1)-(4) are shown inFIG. 3as a loop304.

During and after loop304, the host device130, at (5), monitors traffic to and from the virtualized device134to detect any security breaches. As discussed above, one or more rules may be utilized to detect whether traffic to the device134indicates a security breach. For example, in the case of a whitelist, any traffic not conforming to the whitelist may indicate a potential security breach. In the case of a blacklist, any traffic conforming to the blacklist (e.g., traffic indicating use of authenticated APIs, for example) may indicate a potential breach. In some embodiments, the host device130may flag any traffic from the virtualized device134that is responsive to traffic from an external device (e.g., a malicious device106) as indicative of a security breach. For example, the virtualized device134may be configured such that a response is only expected for legitimate users of the device, of which none exist (given its use as a honeypot). As such, any response from the device134may be considered indicative of a breach. In still more embodiments, a host device130may factor deduplication into whether network traffic is identified as a potential breach. For example, a breach may be determined to be more likely when deduplicated traffic provokes a response from the device134, since network attacks may be known to be typically wide-spread.

In addition to monitoring traffic to detect a breach, the host device130may generally monitor traffic of a virtualized device134to detect network attacks on the device (even if a breach does not occur). For example, the host device130may compare traffic to the device130to attack vector templates within the data store124to determine whether traffic represents a known type of attack. In some instances, an attack vector template may also include rules (e.g., regular expressions) specifying when a breach corresponding to the attack of the template has occurred. Thus, on detecting a given type of attack using the template, the host device130may compare traffic of the device130to the rules to determine when a breach has occurred. Comparisons to attack vector templates may further be used to generate information for reporting to a client (e.g., the type of attack that led to a breach, or types of attacks that did not result in breach).

For purposes of illustration,FIG. 3assumes that the host device130detects a potential security breach at the device134. Accordingly, at (6), the device130creates a report of the potential breach. The report may include, for example, one or more of identifying information of the virtualized device134, identifying information of the malicious device106, timing information of the potential breach (e.g., a time at which the potential breach was detected), operational information of the device134(e.g., resource usage, configuration details, etc.), and details of the traffic that resulted in the detection, such as a packet capture log of transmissions to and from the device134. At (7), the host device130transmits the report to a storage location302, which may be specified in execution parameters for a honeypot device. The storage location302may be, for example, a client device102, a messaging server (e.g., an email server), a network-accessible object store, or the like. Illustratively, a client may monitor the storage location302such that they are informed when potential security breaches occur.

Because a potential security breach has occurred, operational security of the device134may have been compromised. As such, at (8), the host device130also reverts the virtualized device134to a known good state. In one embodiment, reversion may include rebooting the device134. For example, the device134may be configured without write access to persistent memory (e.g., via a virtualized hard disk existing within non-persistent memory), and as such, rebooting the device134may reset the device134to a “clean” state. In another embodiment, the host device130may save a state of the device134just after an initial boot (e.g., a clean state), such as by taking a snapshot of the device134. Thus, the host device130can revert the device134by resetting the device134to that saved state. In this manner, the environment120can ensure that a virtualized device134does not become hijacked and potentially act maliciously.

Accordingly, via the interactions ofFIG. 3, network attacks at honeypots implemented by virtualized devices134can be monitored and detected in a secure manner. Moreover, because virtualized devices134are utilized that can closely resemble production devices, the honeypots may be more likely to be effect than other techniques that do not utilize virtualized production devices. Still further, because deduplication can be applied to multiple network attacks, computing resources needed to provide multiple honeypot devices is reduced and efficiency of the environment120is increased.

With reference toFIG. 4, an illustrative routine400for efficiently implementing honeypots in a hosted environment will be described. The routine400may be carried out, for example, by a host device130of the honeypot service environment120.

The routine400begins at block402, where the host device130obtains traffic to one or more honeypot devices (e.g., virtualized devices134). The traffic is illustratively transmitted by a device external to the environment120, such as a malicious device106.

At block404, the host device130deduplications the traffic, such as by discarding all but n instances (e.g., one instance or a threshold maximum number specified in execution parameters for the honeypots) of traffic that corresponds to given traffic pattern, and forwards the de-duplicated traffic (e.g., the n instances) to the honeypots. In one embodiment, the given pattern may be a specific payload of a data packet shared among multiple packets, or a combination of such a payload and a source network address (e.g., Internet Protocol Address). In another embodiment, the given pattern may be shared material content of multiple data packets, which material content may be specified based on filtering rules (e.g., regular expressions) included within execution parameters of a honeypot. In one embodiment, the n instances of maintained traffic communications are selected at random from among all communication instances. In another embodiment, the n instances may be selected based on other criteria, such as based on load-balancing among honeypot devices (e.g., selecting to retain traffic addressed to a honeypot device with greatest load capacity, using round-robin selection, etc.). As discussed above, deduplication can beneficial reduce the computing resources required by the environment120to implement honeypots.

At block406, the host device130monitors traffic of the honeypot device (e.g., both incoming and outgoing traffic) to detect a breach. As discussed detection of a breach may be based on traffic of the device conforming to one or more rules indicative of a breach, such as (but not limited to) traffic confirming to a blacklist, traffic not conforming to a whitelist, traffic indicative of access by an authorized user, traffic responsive to an incoming packet forming part of a wide-scale transmission, or a combination thereof.

On detection of a breach, the routine400proceeds to block408, where a report of the breach is generated. As discussed above, the report can include data usable by a client to analyze a network attack that caused the breach. For example, the report may include identifying information of the honeypot, configuration or operational information of the honeypot, and timing information for the attack. In one embodiment, the report includes a log of traffic to and from the device during or around the time of the attack, such as a packet capture log including n seconds of data prior to a first packet of the attack and n seconds of data subsequent to a final packet of the attack. In some embodiments, the report may include state information of the honeypot, such as a snapshot of a virtualized device134implementing the honeypot before the detected breach, subsequent to the breach, or both.

As discussed above, in some embodiments the host device130may utilize attack vector templates to detect a type of attack that resulted in a breach, which information may be included within the report. In some instances, the report may also include other information, such as a number of detected network attacks on the honeypot device that did not result in a breach. While the routine400discusses generation of a report subsequent to breach, reports may additionally or alternatively be transmitted periodically to a destination location. For example, the host device130may generate a report for a honeypot device every 24 hours, indicating the frequency and type of attack at the honeypot and whether the honeypot was breached.

At block410, the report and a notification of potential breach is transmitted to a destination location, such as a client device102or other network-accessible location specified by a client device102. Accordingly, a client may be made aware of the potential breach, and may analyze information within the report to better understand a mechanism of the breach, such that a configuration of a corresponding production device can be modified to secure the device.

FIG. 5is a block diagram illustrating an example computer system, according to various embodiments. For example, instances of the computer system500may be configured to implement the control plane interface122, host devices130, client devices102, and the like. Computer system500may be any of various types of devices, including, but not limited to, a personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, handheld computer, workstation, network computer, a consumer device, application server, storage device, telephone, mobile telephone, or in general any type of computing device.

Computer system500includes one or more processors510(any of which may include multiple cores, which may be single or multi-threaded) coupled to a system memory520via an input/output (I/O) interface530. Computer system500further includes a network interface540coupled to I/O interface530. In various embodiments, computer system500may be a uniprocessor system including one processor510, or a multiprocessor system including several processors510(e.g., two, four, eight, or another suitable number). Processors510may be any suitable processors capable of executing instructions. For example, in various embodiments, processors510may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the ×86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors510may commonly, but not necessarily, implement the same ISA. The computer system500also includes one or more network communication devices (e.g., network interface540) for communicating with other systems and/or components over a communications network (e.g. Internet, LAN, etc.).

In the illustrated embodiment, computer system500also includes one or more persistent storage devices560and/or one or more I/O devices580. In various embodiments, persistent storage devices560may correspond to disk drives, tape drives, solid state memory, other mass storage devices, block-based storage devices, or any other persistent storage device. Computer system500(or a distributed application or operating system operating thereon) may store instructions and/or data in persistent storage devices560, as desired, and may retrieve the stored instruction and/or data as needed. For example, in some embodiments, computer system500may act as an element of the interface122, and persistent storage560may include the SSDs attached to that element to facilitate storage of device images.

Computer system500includes one or more system memories520that are configured to store instructions and data accessible by processor(s)510. In various embodiments, system memories520may be implemented using any suitable memory technology (e.g., one or more of cache, static random access memory (SRAM), DRAM, RDRAM, EDO RAM, DDR 10 RAM, synchronous dynamic RAM (SDRAM), Rambus RAM, EEPROM, non-volatile/Flash-type memory, or any other type of memory). System memory520may contain program instructions525that are executable by processor(s)510to implement the routines, interactions, and techniques described herein. In various embodiments, program instructions525may be encoded in platform native binary, any interpreted language such as Java byte-code, or in any other language such as C/C++, Java, etc., or in any combination thereof. For example, in the illustrated embodiment, program instructions525may include program instructions executable to implement the functionality of a host device120. In some embodiments, program instructions525may implement the control plane interface122, or other elements of the environment100.

In some embodiments, system memory520may include data store545. In general, system memory520(e.g., data store545within system memory520), persistent storage560, and/or remote storage570may store information usable in implementing the methods and techniques described herein.

In one embodiment, I/O interface530may be configured to coordinate I/O traffic between processor510, system memory520and any peripheral devices in the system, including through network interface540or other peripheral interfaces. In some embodiments, I/O interface530may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory520) into a format suitable for use by another component (e.g., processor510). In some embodiments, I/O interface530may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface530may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments, some or all of the functionality of I/O interface530, such as an interface to system memory520, may be incorporated directly into processor510.

Network interface540may be configured to allow data to be exchanged between computer system500and other devices attached to a network, such as other computer systems590, for example. In addition, network interface540may be configured to allow communication between computer system500and various I/O devices550and/or remote storage570(which may represent, for example, data stores154). Input/output devices550may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data by one or more computer systems500. Multiple input/output devices550may be present in computer system500or may be distributed on various nodes of a distributed system that includes computer system500. In some embodiments, similar input/output devices may be separate from computer system500and may interact with one or more nodes of a distributed system that includes computer system500through a wired or wireless connection, such as over network interface540. Network interface540may commonly support one or more wireless networking protocols (e.g., Wi-Fi/IEEE 802.11, or another wireless networking standard). However, in various embodiments, network interface540may support communication via any suitable wired or wireless general data networks, such as other types of Ethernet networks, for example. Additionally, network interface540may support communication via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol. In various embodiments, computer system500may include more, fewer, or different components than those illustrated inFIG. 5(e.g., displays, video cards, audio cards, peripheral devices, other network interfaces such as an ATM interface, an Ethernet interface, a Frame Relay interface, etc.)

Terminology

The processes described herein or illustrated in the figures of the present disclosure may begin in response to an event, such as on a predetermined or dynamically determined schedule, on demand when initiated by a user or system administrator, or in response to some other event. When such processes are initiated, a set of executable program instructions stored on one or more non-transitory computer-readable media (e.g., hard drive, flash memory, removable media, etc.) may be loaded into memory (e.g., RAM) of a server or other computing device. The executable instructions may then be executed by a hardware-based computer processor of the computing device. In some embodiments, such processes or portions thereof may be implemented on multiple computing devices and/or multiple processors, serially or in parallel.