Summary
In recent years, the emergence of the Internet of Things (IoT) has raised concerns about the security of networked embedded devices. Due to a lack of understanding of IoT security, our team focuses on collecting and capturing attack activities and techniques targeted at IoT through continuous improvement of IoT honeypots. This allows us to perceive and analyze IoT security, and use these insights to enhance IoT security. In the current IoT landscape, most research teams still use low-interaction honeypots for IoT security research. These low-interaction honeypots have limited effectiveness and their characteristics are easily detected. Therefore, it is necessary to develop high-interaction, reliable IoT honeypots that are highly interactive with attackers’ activities, to attract advanced attackers using such sophisticated honeypots. In this work, we propose the SIPHON architecture—a scalable, high-interaction honeypot platform for IoT devices. Our architecture effectively utilizes IoT devices concentrated in a local area and connects them to the Internet through so-called “wormholes” distributed worldwide. The final architecture allows a small number of physical devices to be exposed through a large number of geographically dispersed IP addresses. We demonstrated the proposed architecture in a large-scale experiment with 39 wormhole instances across 16 cities in 9 countries. Based on this, six physical IP cameras, one NVR, and one IP printer appeared as 85 genuine IoT devices on the internet, attracting 700MB of traffic daily over two months. A preliminary analysis of the collected traffic indicates that devices in certain cities attracted significantly more traffic than those in others (ranging from 600,000 incoming TCP connections in the most popular destinations to fewer than 50,000 in the least popular). We recorded over 400 brute force login attempts to the Web interfaces of our devices using a total of 1,826 different credentials, 11 of which were successful. Moreover, we observed attempts to log into the Telnet and SSH ports, with some using credentials found in the recently disclosed Mirai malware.
Keywords: IoT, low-interaction honeypot, high-interaction honeypot, worm, scalability
1.1.Introduction
The Internet of Things (IoT) has gained immense popularity, bridging the gap between the physical world and the internet. According to the International Telecommunication Union (ITU) standards, IoT can be defined as physical objects or sensors connected to the internet, which can be referred to as “things” [3]. This means that unlike traditional network nodes like servers or PCs, IoT devices have a stronger connection to physical reality through their sensors, with behaviors dependent on interactions with the analog world. Over the past decade, rapid advancements in sensor manufacturing and miniaturization have significantly propelled the development of this field. It is projected that by the end of 2016, there will be 6.4 billion IoT devices connected to the internet, increasing to 11.8 billion by 2018 [5].
The Internet of Things (IoT) has driven the adoption of applications such as wearable technology, smart transportation, and industrial automation. As a vast number of IoT devices are commercially utilized or deployed, providing appropriate security mechanisms for these devices becomes increasingly challenging. Misconfigured IoT devices present opportunities for attackers to execute malicious activities, such as compromising critical infrastructure or infringing on personal privacy. It is estimated that by 2017, 90% of organizations with IoT devices installed on their premises will experience attacks on their backend IT systems stemming from IoT device vulnerabilities [6].
In fact, recent distributed denial-of-service attacks on core internet services, such as DYN’s hosted DNS infrastructure, were partially executed using IoT devices (IP cameras) with default or weak hardcoded passwords on Telnet and SSH interfaces [12].
Therefore, there is an urgent need to develop suitable and cost-effective methods to discover vulnerabilities in IoT devices, so that these issues can be addressed before attackers exploit them. In traditional IT security, honeypots [7,29,30] are commonly used to better understand the dynamic threat landscape without exposing critical assets. Typically, honeypots attempt to simulate an interaction (such as a shell login) in a realistic manner, capturing unsolicited connections and possibly trapping attempts to execute (possibly unknown) attacks.
In the context of the Internet of Things (IoT), accurately simulating the interaction of IoT devices poses a significant challenge. For example, consider the case of IP cameras. To virtualize or simulate the behavior of an IP camera authentically, one must not only broadcast some video to an attacker but also respond convincingly to commands such as tilting the camera or zooming in. Although it is not impossible, this requires substantial technical effort. Due to the heterogeneity of IoT devices from different vendors, these technical efforts are not easily reusable and cannot simulate various types of IoT devices.
On the other hand, since IoT devices perceive and interact with the physical world, they may hold different perceived value to attackers depending on their location (e.g., different organizations or countries). This is similar to trends in the botnet underground markets, where internet servers in different regions are rented out at varying prices [18]. Therefore, honeypots exposing IoT devices should ideally be geographically distributed to engage with attackers.
Based on the aforementioned requirements, a framework for deploying an IoT honeypot should: (1) offer a high level of interaction to trap skilled attackers into engaging in activities and exposing vulnerabilities they are exploiting; (2) easily “deploy” IoT devices across a wide range of geographical locations; and (3) conveniently scale to multiple vendors and different types of devices to monitor the dynamic threat landscape.
In this article, we present an abstract architecture for a high-interaction IoT honeypot, focusing on the prototype implementation of this honeypot, which we refer to as SIPHON. Our implementation allows us to deploy over 80 high-interaction devices in various regions worldwide, along with a set of different IPs, by utilizing only 7 actual IoT devices in our lab. We operated SIPHON for two months, collecting 20GB of raw traffic data. Upon initial data analysis, we discovered that instances in different cities received significantly varied levels of attention (in terms of connections and traffic). Moreover, curious users from the internet attempted to forcefully authenticate devices, gaining access to administrative interfaces and interacting with devices in certain cases.
Specifically, we will examine the issues and summarize our contributions as follows.
Problem Statement: IoT devices offer attackers a rich set of potential attack vectors. Our goal is to understand existing and new attack vectors on IoT devices. Specifically, in this work, we focus on collecting unsolicited traffic to IoT devices exposed on the internet. Traditional honeypots use virtualization or emulation to replicate devices under attack and attract attackers. In the context of IoT, replicating devices with virtual machines poses a challenge. Only high-interaction honeypots (e.g., allowing users to move a camera) can effectively ensnare skilled attackers who exploit zero-day vulnerabilities with advanced attack methods. The major question driving this work is: How do we construct a large-scale honeypot composed of high-interaction IoT devices?
MethodWe propose a SIPHON architecture for scalable high-interaction IoT honeypots. Our architecture employs physical IoT devices that connect to various geographical locations through so-called “wormholes.” This architecture is implemented across a large-scale distribution of 85 instances in 16 cities and 9 countries, using only 5 physical IP cameras, 1 NVR, and 1 IP printer (i.e., 7 IoT devices). In our implementation, network traffic is forwarded by leveraging the infrastructure of cloud service providers, which comprises Amazon EC2 instances, DigitalOcean, and Linode. We conducted a preliminary analysis of the collected traffic and gained insights into the volume of interest from different geographical areas and the types of interactions with the devices.
ContributionThe contributions of this article are as follows:
1. We explained the anticipated benefits of high-interaction IoT honeypots and defined the design challenges.
2. We propose an architecture for a high-interaction IoT honeypot using limited physical IoT devices.
3. We proposed an implementation of an architecture based on 7 devices, which are presented as 85 different services on the Internet.
4. We analyze the captured traffic, and it’s crucial to display the geographic location of our wormhole—attackers exhibit a heightened interest in certain locations.
We focus on high-interaction distributed honeypot support for real IoT devices. This setup allows us to capture and analyze traffic and attacks from different geographic locations. To the best of our knowledge, we are the first to propose and implement this architecture.
This work is organized as follows. The background of this work is introduced in Section 2. We present the main architecture in Section 3, and its implementation in Section 4. In Section 5, we analyze and discuss the traffic collected by our implementation. Related work is summarized in Section 6. Finally, the paper concludes in Section 7.
1.2.Background
A honeypot is an infrastructure typically used to direct potential attackers to a controlled and monitored environment without exposing critical assets, with the aim of understanding the threat landscape at a given point in time. It usually consists of real or virtual systems that simulate a production environment. Interactions between attackers and the honeypot are often monitored and logged for further analysis. After researchers analyze the traces collected by the honeypot, they can design appropriate mitigation techniques for the attacks. From an intrusion analyst’s perspective, “honeypots provide another cognitive form of the cyber attack chain” [35].
The method of setting up honeypots may offer convincingly false information that could be tampered with by potential attackers to pique their interest. Additionally, honeypots can assist in redirecting attackers to decoy systems, thereby indirectly safeguarding critical systems or infrastructure from potential harm: if attackers are misled into believing they are interacting with a real system, they will waste time and resources attempting to harm the actual infrastructure.
Security researchers classify honeypots as high-interaction or low-interaction based on the level of engagement afforded to the attacker and the actual vulnerabilities exposed to them. In the following text, we will briefly review these two categories.
1.2.1 Low-Interaction Honeypot
Low-interaction honeypots simulate known vulnerable network services by partially implementing the TCP and IP protocol stack to attract attackers. They do not allow attackers to access real systems but instead permit them to interact with some form of simulated environment. Since they typically do not run fully functional operating systems, they are considered safer in terms of remote exploitation. However, because of their simplicity, the main drawback of low-interaction honeypots is that they are easier for attackers to recognize as contrived, particularly if the attacker is human. Attackers may realize that the actual service is simulated and only partially implemented, leading to a loss of interest. Low-interaction honeypots are not structurally the best method for capturing zero-day vulnerabilities, as by nature these vulnerabilities are unknown at the time of honeypot deployment and cannot therefore be simulated. Low-interaction honeypots can detect a new wave of attacks for a very limited period until they get flagged by attackers and dedicated search engines.
1.2.2 High-Interaction Honeypot
High-interaction honeypots are more advantageous than low-interaction honeypots for observing attacks in a more realistic environment. High-interaction honeypots do not simulate any services, functionalities, or basic operating systems. They allow for deeper insights into an attacker’s tools, strategies, and motivations since they do not constrain the attacker’s actions like low-interaction honeypots do [31]. Consequently, high-interaction honeypots are better suited for monitoring complex interactions between attackers and systems [13].
On the other hand, according to the literature [13], high-interaction honeypots also have drawbacks. Firstly, deploying and maintaining high-interaction honeypots is often difficult and costly. Additionally, they pose greater security risks because attackers can disrupt the normal operation of the device after escalating their privileges and may use the device at will. If someone intends to expose many vulnerabilities that could depend on different hardware/software configurations (such as various operating system versions), there is a need for widespread heterogeneous deployment on real devices. Finally, while high-interaction honeypots are suitable for monitoring a variety of events (such as network traffic and host-based activities like system calls), this usually results in large volumes of logs, making security analysis more challenging.
1.2.3 Wormhole (wormhole)
In the context of wireless communication, the term wormhole refers to an attacker maliciously forwarding communication through an out-of-band channel [21]. Specifically, wormholes can be used to affect routing schemes in dynamic sensor networks [20] or to attack wireless key schemes for automotive purposes [14]. Wormholes are often very challenging or even impossible to detect [19].
In this work, we will use the term “wormhole,” but in a way that’s related to our context: our wormholes are not the offensive ones exploited by attackers, but rather the defensive ones operated by honeypot managers. For attackers, the existence of the wormhole (especially the location of the other end) should be transparent. We will discuss how to achieve this goal in Section 3.
1.2.4 Shodan
Shodan[10] is a search engine that indexes Internet of Things (IoT) devices on the internet, including industrial control system (ICS) devices like programmable logic controllers (PLCs) and household devices like IP cameras. Figure 1 shows a device found within a honeypot on Shodan, corresponding to a camera search at a specific location.
Shodan utilizes port scanning on internet IPs and analyzes the responses received to identify the types of devices discovered. Generally, newly deployed devices take 1 to 2 weeks to be indexed by Shodan[10].
In the following text, we assume that attackers will use Shodan as the primary source of potential target information. Additionally, the Shodan API provides a service that attempts to estimate whether the devices exposed by Shodan are honeypots. This service is called Honeyscore and is also accessible from Shodan’s developer command-line interface API. Honeyscore uses a heuristic approach to classify devices as potential honeypots, providing scores ranging from 0 (likely not a honeypot) to 1 (likely a honeypot).
Figure 1 Example of Cameras Listed on Shodan (in this case, one of our wormholes)
1.3.SIPHON: Scalable High-Interaction Physical Honeypot
In this section, we will introduce the design of SIPHON: a scalable high-interaction physical honeypot. We will first outline our attacker and system models, and then provide an abstract system design.
1.3.1 Problem Statement
Our goal is to understand both existing and novel attack vectors for IoT devices. Specifically, we aim to leverage the intelligence of adversary groups to identify common vulnerabilities. In this effort, we focus on collecting unsolicited traffic from IoT devices exposed to the internet. Traditional honeypots use virtualization or emulation to replicate the targeted devices and lure attackers. In an IoT environment, replicating devices with virtual machines presents a challenge. Only high-interaction honeypots, such as those allowing users to move cameras, are capable of ensnaring skilled attackers using advanced tactics. The primary question driving this work is: how can we construct a large-scale honeypot consisting of a limited number of real IoT devices?
1.3.2 Design Considerations
In the following text, we assume that attackers are using the internet (particularly Shodan[25]) to identify potential vulnerable or insecure IoT devices, such as webcams, smart refrigerators, or similar equipment. Typically, attackers begin with the reconnaissance phase, followed by the attack phase. Attackers can interact in both of these phases using automated tools or manual methods.
Assume that the compromised devices are directly accessible from the internet (i.e., on a public IP address). They will expose one or more services on open ports. Such services could be HTTP, Telnet, SSH, or more specific protocols like RTSP. Devices will be integrated into a real-world environment, meaning cameras will display live images, refrigerators will contain real food, etc. Configuration of the devices will require minimal effort (i.e., they may use default passwords). No dedicated security solutions (such as firewalls or IDS) are in place. If devices are reachable through a NAT service, the exposed services are forwarded by NAT.
Figure 2 Abstract Overview of Distributed Physical Honeypot
1.3.3 Design Overview
Our design (see Figure 2) is based on real physical IoT devices, which are exposed to the Internet through numerous tunnels. These tunnels forward the traffic from the wormhole (remote public IP address) to the local physical IoT devices.
Wormhole: Wormhole devices present numerous open ports on a public IP address to the general Internet. The inbound traffic on these ports can either be locally logged, or it can be transparently forwarded to specific ports on remote physical IoT devices through a forwarder device. There are many options for implementing this forwarding, which we discuss in Section 3.5. Each wormhole can be associated with multiple physical devices, but each forwarded service requires a unique port on the wormhole.
ForwarderTransponders ensure the real-time rewriting of traffic between wormholes and IoT devices to conceal the actual location of devices or the fact that they are communicating with multiple other tunnels. If necessary, transponders can also act as TLS middlemen because they have access to the private keys of the certificates used by IoT devices.
Device Under Attack (DUA)In the SIPHON architecture, the local (IoT) device under attack can be a standard commercial off-the-shelf device. It will expose one or more services over the network, most likely via TCP. The device is capable of maintaining multiple concurrent connections at any given time.
Storage and Analysis Unit (SAU)SAU acquires traffic logs and general logs from the wormhole, aggregating the data for offline analysis. For instance, recorded traffic can be analyzed using suitable frameworks such as Suricata or Snort [8]. Additionally, dedicated analysis frameworks from other honeypot deployments can be utilized (similar to [27]).
1.3.4 Location of the Wormhole
Since IoT devices are embedded in and interact with the physical world, we hypothesize that the physical location of compromised devices is related to their attractiveness to attackers. While the direct physical location of communication partners on the Internet is not easily determined [9], many services on the Web offer IP geolocation services (e.g., [17]).
Therefore, we recommend ensuring that the wormholes have public IP addresses that are localized across a range of physical locations, preferably spanning multiple countries or even continents.
This objective can be achieved through various methods. Although the IPv4 address space is becoming increasingly scarce [32], the simplest way to obtain a public IP address seems to be via a) home users (typically, each subscription receives one IP) and b) cloud servers (cloud providers possess large IPv4 address spaces). In this work, we focus on the latter (see Section 4). To take advantage of the public IP addresses of home users, we also considered preparing devices with specific configurations (such as Raspberry Pi) as tunneling nodes to forward traffic to honey-pot relays. The disadvantage of this approach is that such a home setup may require home users to establish port forwarding on their home NAT devices (commonly referred to as routers in this context). For many users, this configuration process could be complicated, which is why we did not pursue this implementation path.
1.3.5 Forwarding Method
Tunnels between repeaters and wormholes can be implemented using a variety of different repeater technologies. Let’s discuss some of the options we have considered.
Application Layer Proxy: If the honeypot only selectively retransmits a few chosen services, proxies (such as HTTP proxies like mitmproxy) can be utilized on the tunnels for these services. This approach offers numerous advantages, such as caching static information, thereby reducing traffic load on DUAs.
EncapsulationOn the transport and application layers, services like SSH and TLS can be used to encapsulate selected traffic with minimal configuration overhead. In our implementation, we chose SSH tunneling as the method to forward traffic.
Network Layer VPN: There are numerous network-layer VPN services available (such as IPSec), and a detailed comparison is beyond the scope here (we refer to [23]). This type of service may have advantages over selective port forwarding with SSH, as it allows for the forwarding of numerous ports with minimal configuration.
1.3.6 Trade-Offs in Detection and Recovery
Because the SIPHON architecture exposes real devices to attackers, there is a possibility that attackers could completely compromise the devices during an attack. Once compromised, these devices can be used to attack other devices, general nearby infrastructure, or to distribute malware to other attackers. There are several options to mitigate or prevent this situation.
Regular Reset: A simple method to mitigate the impact of compromised devices is to configure all IoT devices used in the lab to periodically reset their configuration and firmware. This approach has several drawbacks (i.e., timeliness and completeness of the reset). On the other hand, it’s relatively easy to set up with some manual intervention.
IPSAn open-source intrusion prevention system like Suricata[8] can be used with custom rules tailored for IoT devices to prevent them from constantly experiencing attack incidents. Additionally, IDS/IPS can be utilized to detect altered behavior of compromised devices to determine if such compromise has occurred.
Complete set of instruments: The most reliable compromise detection can be achieved through low-level instrumentation of IoT devices, such as via JTAG or similar connections. Setting up and maintaining such instrumentation is feasible, but it is expected to be challenging and expensive [16].
1.3.7 Scalability
As we proclaim in the acronym SIPHON, the proposed architecture should be scalable. Our intuition is as follows: For \( n \) physical IoT devices and \( m \) wormholes, without exposing the same device twice in the same wormhole, the maximum number of devices that can be presented to an attacker is up to \( n \times m \). For instance, if \( n = 100 \) and \( m = 1000 \), then up to 100,000 services can be exposed to the internet. Due to port number limitations, the number of services per wormhole is limited to approximately 65,000. The number of wormholes per physical device is constrained by the parallel traffic each physical device can handle. In our practical implementation, due to budget and space constraints, we choose lower values for \( n \) and \( m \) as described below.
1.4.Distributed IP Camera Honeypot
In this section, we will discuss the implementation of the SIPHON architecture for a specific type of IoT devices: IP cameras used for home or public surveillance. We have chosen these devices because the number of IP cameras connected to the Internet is increasing daily, and recent research indicates that IP cameras and Network Video Recorders (NVRs) are susceptible to attacks [12, 27]. Hence, they are more likely to handle unsolicited traffic compared to other IoT devices on the market. Additionally, IP cameras allow access to private videos and commonly enable complex interactions with users (such as manual pan controls).
In our implementation, the camera’s location is spoofed through a wormhole based on cloud service instances. These instances are deployed in various cities around the world. From an attacker’s perspective, the cameras are positioned across cities (e.g., by using the geolocation functionality of search engines like Shodan). All the traffic is routed from the wormhole to our lab for in-depth analysis.
1.4.1 Implementation
Figure 3 illustrates our prototype infrastructure for deploying SIPHON using IP cameras and a Network Video Recorder (NVR). Table 1 lists the devices utilized.
Figure 3 depicts the SIPHON prototype implementation in our laboratory.
By default, all devices expose a password-protected administrative web interface. To facilitate complex interactions with the device, we use default passwords for some cameras and weak passwords for others. Figure 4 shows a screenshot of an HTTP interface of a camera after successful authentication. Using the administrative web interface aligns very well with our goal of capturing high-interaction traffic. They provide attackers with ample opportunity to engage in various device interaction scenarios, such as camera movement and Wi-Fi network scanning. Even though recent attacks, like those using the Mirai malware, completely rely on discovering and exploiting vulnerabilities through Telnet and SSH ports [26], we do not actively seek information about attacks on these ports. The reasons are as follows:
1) Telnet/SSH do not provide a highly interactive environment, particularly one that supports video streaming over HTTP, so it’s not as engaging.
2) IoTPOT has already conducted research on Telnet/SSH in this area [27]
3) None of the IoT devices we use have open Telnet or SSH ports.
Table 1: Details of IoT Devices
Figure 4: Example View of the Device Through the Wormhole
In our lab, the equipment is connected to cloud servers from three distinct cloud service providers located in various cities, specifically Amazon, Linode, and DigitalOcean. During our experiments, a total of 39 servers were deployed, each featuring a unique public static IP. Each cloud server was assigned as a wormhole capable of connecting up to three (3) devices. These devices were connected through different ports on the cloud servers. In total, an attacker could see 85 devices on the Internet, despite only using 8 physical devices, resulting in an average of 10 possible virtual connections per physical device. Shodan employed device fingerprinting techniques, such as parsing devices’ HTTP responses, to gather information about the devices. It published details like the devices’ geographic locations, accessible ports, and other pertinent information, as shown in Figure 1.
Ultimately, all traffic (i.e., device requests or attacks) was redirected to the IP cameras or Network Video Recorders (NVR) in our lab. All traffic was captured using tcpdump on each wormhole server, with the resulting traces stored locally in .pcap format for offline analysis.
1.4.2 Traffic Forwarding Technology Configuration
Our technical setup relies on a network gateway solution, as shown in Figure 2. To implement the forwarder, we used a local server in our lab to manage TCP connections from wormhole instances in the cloud. This server alone handles all communications from m wormholes to n IoT devices. The server itself is a VM client with 1 virtual core and 4GB of RAM, running Ubuntu 16.04.
The connection between the relay and the cloud instance is established through a reverse SSH tunnel, which redirects the traffic on a specific port (i.e., port 80) of the wormhole to a port within the relay. Once the traffic reaches the relay, we utilize the `socat` Linux command to redirect traffic to the IoT device, which also forwards the device’s responses back to the cloud instance through the relay. By using different local ports in the relay for each cloud replica of the physical device (wormhole), this process can be easily automated.
Figure 5: Setup of Cameras and NVR in the Laboratory
IoT devices are isolated from other equipment in the lab using 802.1Q VLAN. This ensures that even compromised devices can interact only with other IoT devices and servers at most.
1.4.3 Location of the Wormhole
For attackers, IoT devices are placed in the city where the actual wormhole is located. Physically, IoT devices can be located in public areas along with the transceiver.
Figure 6 illustrates the deployment locations of honeypots across various cities on different continents. The SIPHON experiment deployment covers the following 16 cities in 9 different countries: a) United States (San Jose, Boardman, Ashburn, New York, San Francisco, Dallas, Fremont, Newark) b) Canada (Toronto) c) Europe (Frankfurt, London, Dublin, Amsterdam) d) Asia (Singapore, Bangalore) e) Australia (Sydney).
Figure 6 shows the prototype wormhole locations of various cities around the world.
The total cost for this setup (39 wormhole instances across three different providers) is approximately $12 per day. We observed that the smallest instance size is typically sufficient for the setup, which helps keep the costs low.
1.4.4 Hidden Honeypot Role
Reference [31] defines various detection methods that attackers use to identify the presence of honeypots. These methods typically vary based on the tools used for honeypot creation. For example, a honeypot created using the “Nepenthes” tool can be detected using NMap, a network open port mapping tool. NMap can identify that among multiple services running on a Nepenthes machine, only one service version is detected. On the other hand, a honeypot created with “Sebek” can be detected by discovering the memory addresses of the system calls “sysread” and “syswrite” and ensuring that the interval between them does not exceed 4096 bytes. Generally, low-interaction honeypots employ tools that partially emulate the network stack (TCP/IP) to lure attackers by exposing vulnerable services. Such network stacks might be susceptible to crafted packets, thereby revealing the presence of the honeypot. Moreover, honeypots built using virtualization are inherently vulnerable to timing attacks. For instance, timestamps in TCP packets on different virtual machines hosted on the same physical machine can show a similar skew over time, unlike the same setup on different physical machines, which do not [31].
While we have not fully explored specific attacks targeting our infrastructure, after operating a distributed honeypot for a period, we checked if Shodan identified its IP addresses as “honeypots.” During the experimental run, Shodan essentially did not detect our IP addresses as honeypots (see Figure 1). In particular, the scores we retrieved from Honeyscore via Shodan’s developer API mostly ranged from 0.0 to 0.5 (not a honeypot), with an average of 0.16, and only one instance was marked as a honeypot with a confidence of 0.8. The precise methodology Shodan uses to detect honeypots is unknown to us, but it is likely based on heuristics from well-known open-source honeypot tools.
1.5.Preliminary Traffic Analysis
In this section, we present the results of our analysis of the prototype that captured traffic. Specifically, we focus on the following aspects:
- a) whether the location of the virtual tunnel affects the attacker;
- b) whether some devices are more attractive to attackers than others;
- c) whether devices listed on Shodan affect unsolicited connections;
- d) the behavior of attackers in the low-interaction version of the environment; and e) the type of interaction between attackers and devices.
1.5.1 Analysis Objective
The interests of attackers may vary due to several factors mentioned above. In this work, the following assumptions have been taken into consideration.
LocationWe hypothesize that attackers prefer to invest more time in certain cities to identify their targets. They search for devices in specific cities of interest and subsequently initiate interaction. For example, this might be due to commercial interests involving local IPs, allowing them to resell post-infection (like botnets [18]), or as a starting point for targeted attacks.
Device TypeLet’s assume attackers target specific models or types of devices with potential known vulnerabilities. For example, attackers might specifically look for vulnerable IP cameras.
Shodan Listing: We hypothesize that attackers may target this device by logging into Shodan and searching for it. We listed the differences in connection attempts found before and after the device was listed on Shodan.
High Interaction vs. Low InteractionWe hypothesize that an attacker’s behavior might vary when exposed to our low-interaction implementation, such as a camera management web service that appears identical to the original device but displays static images instead of video.
To validate the above point, we considered the following interactive factors. First, we wanted to understand how many TCP connections each honeypot received and what type of services (SSH, our HTTP port, etc.) were being queried. This has already revealed how many honeypots were discovered and how much attention they received.
Next, we are interested in determining whether familiar scripts are being used, based on the number of connections received by each honeypot within a short period, the number of different ports accessed on the same honeypot, and the user agents in HTTP sessions (for instance, in the traffic we collected, we identified a masscan agent [2]). Additionally, since attackers need to authenticate to access the management interface of our devices, we are interested in calculating the number of brute force login attempts, counting the successful ones, and further investigating what occurs after a successful login.
In order to further assess the behavior of attackers attempting to access our devices, we assigned default passwords, simple passwords, and strong passwords (Table 1). Then, by analyzing the HTTP responses issued upon a successful login, we can gather statistical data on camera movements or zooms, scan WiFi networks (a feature typically provided in the IP camera’s management interface), and more intriguingly, investigate firmware updates.
1.5.2 High-Interaction IP Camera Honeypot
All network traffic is collected and stored on local machines in our lab. We store the raw PCAP obtained via tcpdump, and then, to perform the aforementioned analysis, we parse the PCAP and store the basic characteristics of each TCP connection in a SQL database.
It seems like your input is incomplete. Could you please provide additional text or context so I can assist you properly?P. After analyzing over two months of data, we observed incoming TCP connections from more than 13,000 distinct remote IP addresses.
Wormhole Connections Between Each CityBased on the geographical distribution of wormholes, we observe that wormholes in some cities receive more attention than those in others. Figure 7 illustrates the distribution of incoming TCP connections received by wormholes in each city. Frankfurt’s wormhole received the most connections (nearly 600,000), while San Jose in the United States received the least (about 50,000).
Wormhole Port: However, we observed that most inbound connections (approximately 97%) were on port 22 (SSH) of the wormhole, while HTTP ports like port 80 and port 8080 only received 1.27% and 1.12% of the total connections, respectively. The other HTTP ports we opened accounted for only 0.25% of the total inbound TCP connections. Figure 8 displays the distribution of inbound TCP connections according to the wormhole ports.
Figure 7 shows the distribution of city TCP connections to the wormhole.
Port distribution connecting to the wormhole in Figure 8.
Figure 9 illustrates connections based on input from the country of origin.
Figure 10 based on incoming connections from the user agent
Attacker’s location: Although not a reliable indicator (as attackers can easily tunnel through IPs located anywhere in the world), we also gathered statistical data on the locations of remote IPs. We analyzed the sources of all incoming connections by country. Figure 9 illustrates the distribution of origin countries for incoming TCP connections. We found that over 70% of the connections originated from China, followed by 8% from the United States. The Netherlands, France, and other countries made up the remainder of the list, as shown in Figure 9.
User Agent Utilized by AttackersNext, we will enumerate the proxies used when connecting to the device. In Figure 10, different user agents used in inbound TCP connections are displayed. Most connections (76%) were established using Mozilla as the user agent. In addition, agents like Chrome, Python Requests, Wget (Linux), Curl, Scanbot, Teleshoreo, and Masscan [2] were also utilized. Other user agents were merged into the “Other” category, accounting for 2.8% of total connections, including IP Camera Viewer, CamFinder, Morfeus F Scanner, Msqq Agent, and others. Multiple detections were made of the use of Nmap. Beyond that, we also noticed approximately 9,000 Shellshock attempts on our device.
The Compromised Device: In Figure 11, we illustrate the aggregate interest volume generated by different physical devices (based solely on HTTP traffic). We observe that the majority of the traffic targets the DLink DCS-930L camera. We speculate that this device garners the most attention from attackers due to recent media reports highlighting vulnerabilities in its firmware [1].
Brute Force Login AttemptWe have set up IoT devices with varying levels of password complexity (Table 1). In certain instances, we retained the default credentials for web interface logins, while in others, we altered the credentials. Some cameras were configured with easily guessable passwords, whereas others were set up with passwords that are difficult to guess. Through this setup, we observed 404 brute force attacks on all devices, executed by a combination of 137 different remote IPs. An attempt is classified as a brute force attempt if the same remote IP tries to log in more than three times within a single HTTP session. In the 404 brute force provocations, we noted that a total of 11 attempts were successful. All successful login attempts occurred on devices with simple passwords, and no logins were recorded on devices with hard passwords. We observed that these simple passwords are commonly found in dictionaries used by most automated brute force attacks. Moreover, these passwords are easily guessed or cracked even during manual attacks.
Device Connectivity’s Impact on Shodan
Another objective of this analysis is to investigate the impact of the wormhole listing on Shodan. We attempt to understand this by calculating the number of TCP connections received before and after the wormhole was listed on Shodan. Typically, Shodan takes about one to two weeks to register an IP address online. Concerning this, we considered the traffic logged a week before and after it appeared on Shodan.
Figure 11 Traffic Decomposition for Devices
Figure 12 Impact of Shodan Going Live on Future Connection Volume
In Figure 12, we present the cumulative impact of Shodan listings on all honeypots. Specifically, we display the average number of incoming connections attracted by the honeypots on a weekly basis before and after being listed on Shodan. In Figure 12, the top bar indicates the average number of connections prior to all honeypots being listed on Shodan. The middle bar represents the average connections during the first week after being listed on Shodan, while the bottom bar illustrates the average connections during the first two weeks post-listing. The surge in connections following the Shodan listing is apparent. We also observed that this spike in connections persists into the second week following the Shodan listing, albeit with reduced growth. Therefore, we can infer that Shodan listings have an immediate impact, prompting attackers to attempt luring devices right after the listing appears on Shodan. In the long term, the number of incoming connections tends to decline.
1.5.3 Other IoT Devices
So far, we have only utilized IP cameras and NVRs in our high-interaction honeypot and have gained knowledge of attacker behavior/interactions with them. However, these devices do not represent the full spectrum of existing IoT devices. We are also interested in collecting data on attackers’ behaviors with other IoT devices. Therefore, we added another IoT device to the honeypot, an IP printer, for approximately four weeks. This IoT device was connected to a DigitalOcean cloud instance located in London. Thus, similar to the IP cameras, even though the device physically existed in our lab, it appeared to be located in London.
After analyzing the network traffic data around the IP printer, we have presented our results.
Wormhole PortWe observed that the majority of connections (99%) are directed at port 22 of the wormhole (SSH), while port 80 (HTTP) receives only 1%. Even in the case of IP cameras, we noticed that the SSH port receives more connections compared to the HTTP port.
The location of attackersSimilar to our observations with IP cameras, we noted that the highest percentage (79%) of incoming connections to IP printers originates from China. This is followed by Taiwan, with 11% of connections coming from there. The remaining connections come from France, India, Kazakhstan, the Netherlands, Ukraine, and the United States.
Brute Force Login AttemptWe have changed the credentials for the IP printer to a password that should be easy to guess (admin: 1234567890). During our experiments, we observed only one brute force login attempt. Similar to the situation with the IP cameras, if the same remote IP attempts to perform more than three login attempts within a single HTTP session, we classify the attempts as brute force. There were a total of four successful login attempts from three different remote IPs, all originating from China.
User-Agent used by attackers: Similar to the case with IP cameras, we attempted to identify which different user agents were employed when connecting to IP printers. We observed that all four successful login attempts were made using the Mozilla user agent. Unlike the IP cameras, we did not notice certain user agents (i.e., cameraviewer, IPcamera finder, Scanbot, Morfeus F scanner, Msqq, etc.). Furthermore, we also did not observe any Shellshock attempts on the IP printers.
Low-interaction honeypot 1.5.4
One assumption we have about low-interaction honeypots is that most attacks are executed using automated bots. We assume these bots cannot distinguish between real devices and virtual or fake devices. Therefore, these bots might repeatedly attempt to interact with the device as if it were a genuine one. Conversely, a human would recognize a fake device and would not continue to interact with it.
We implemented the low-interaction honeypot using the same approach as the high-interaction honeypot. However, in the low-interaction honeypot, we used a Trendnet camera simulator instead of an actual physical device. Therefore, this camera is fake, not real. The entry point of the low-interaction honeypot (i.e., the wormhole) was created using an instance from a cloud service provider, Linode, located in Singapore. Subsequently, we collected data from the low-interaction honeypot for nearly six weeks.
The results of six weeks of data are now presented.
Wormhole PortWe observed that most connections to the fake cameras, particularly the Trendnet camera simulator (87%), occurred on port 22 (SSH), while HTTP ports 8080 and 80 received 12% and 1% of the total incoming connections, respectively. In this regard, the observed behavior is consistent with trends noted in high-interaction honeypots.
User agents used by attackers: Similar to the observations made in high-interaction honeypot scenarios, we noted that the largest percentage of incoming connections identified the user agent as different versions of Mozilla. In addition, attackers utilized WGET (Linux), Python, Masscan, and the Probethenet Scanner. All of these user agents were observed in the high-interaction honeypot.
Login AttemptWe observed three successful login attempts using the default credentials admin:admin with three different remote IPs. These successful logins occurred from China, Russia, and Iran, each logging in once.
We also discovered that attackers did not spend sufficient time exploring the device or its capabilities. They spent an average of about 30 seconds in low-interaction honeypots, while in a real camera, the time spent could be either 1 minute or even 1 hour. The time spent by attackers exploring the device was calculated based on the timestamps of the first and last packets in the TCP session, captured using tcpdump. It is well understood that the session duration is associated with human intervention. Session time will be longer when attackers attempt to explore device functionalities. Unlike automated bots, humans can easily distinguish between still images and streaming video. Therefore, it is easier to identify human attacks using this low-interaction honeypot compared to previous high-interaction honeypots.
1.5.5 Discussion and Commentary on Validity
Through traffic analysis, we observed that the proposed architecture successfully attracted a significant amount of connections, confirming our overall design. Additionally, we noticed engaging interactions during the preliminary analysis of the collected data. In our analysis, we assumed that interactions between attackers and IoT devices over HTTP are easier to perform than scripts, as automating interactions with unknown HTTP interfaces is more challenging [27]. Therefore, our prototype is an effective initial step in learning about IoT security threats.
Through traffic analysis, we discovered that our proposed architecture successfully attracted a significant number of connections, confirming our overall design strategy. Additionally, during the preliminary analysis of the collected data, we were able to observe interesting interaction phenomena. We noted that in our analysis, we assumed interactions between attackers and IoT devices were more likely to occur over HTTP than through script execution, because interactions with unknown HTTP interfaces are more challenging to automate [27]. Thus, our prototype represents a promising first step towards effectively understanding the state of IoT security threats.
We recognize that the current prototype has several issues. First, one might argue that a savvy attacker could identify our honeypots in various ways. For example, an attacker could detect that two wormholes represent the same physical device by logging into the same device from two different wormholes simultaneously. We acknowledge this drawback, but it is important to note that in our experiments, our data indicate that no single IP has discovered all the wormholes; most interact with only a small subset (typically 5 or fewer). Assigning each wormhole to a different physical device could also mitigate this issue. Since we are interested in comparing different locations, we chose to scale the system in a 1-to-n manner rather than establishing a bijective relationship between devices and wormholes.
Compared to related works like [27], we have so far seen few attempts to upgrade firmware, which is a very common target for attackers seeking to propagate botnets or malware. We speculate the following potential explanations. We observed that only a small amount of wormhole traffic is directed to ports that expose the network interfaces of IoT devices. Attackers appear to be more interested in SSH connections, possibly because commonly used automated attack tools are tailored to re-flash firmware using the Shell—an approach that works universally across many devices. We believe the firmware upgrade attempts we received were manually executed, but we also anticipate that such attacks will increase in the future as attack tools automatically adapt this process for different brands. In the future, access to SSH ports on many devices, like home cameras, may be more strictly restricted, and access to the web interface may still be preferable for convenience.
Furthermore, one might argue that an IoT device connecting to the Internet via an IP address owned by Amazon is suspicious from the start. However, considering the amount of attention received in terms of traffic and the existence of some (potentially manual) logins, we believe using an IP belonging to a cloud service might not be deemed suspicious by widespread attackers. In fact, according to Shodan’s honeyscore (0.0), the fact that most of our wormholes are classified as non-honeypots initially indicates that, from a technical perspective, our setup appears to be realistic.
By the way, we noticed that at least six more cloud instances showed cameras on Shodan. All these examples had a honeypot score of 0.5, which in principle makes them even more suspicious than our setup. However, it may indicate that such configurations are not uncommon (if they are not honeypots), or that others have not been as discreet in their honeypot configurations as we have.
1.6.Related Work
Honeypots are a common method for understanding attacker activities within computer networks. The author of [13] provides a classification of honeypots and distinguishes between low-interaction and high-interaction honeypots. Source [7] compares low-interaction and high-interaction honeypots, concluding that high-interaction honeypots offer greater insight into attacker behavior than low-interaction honeypots.
The Honeynet Project[34] is an established initiative focused on monitoring and analyzing attacks on advanced intrusion detection tools. The Honeynet Project does not use emulation but instead employs real systems and applications. Therefore, the Honeynet Project serves as an example of a highly interactive honeypot.
In [15], the author describes honeynets, which can be used to enhance the security of large computer networks. In short, a honeynet is a collection of honeypots.
In [22], a low-interaction honeypot system was implemented. The honeypot monitors behavior and learns about sophisticated attacks that IDS tools might not detect. Attackers’ sessions are redirected to the honeypot system, which then services the attackers’ requests. To achieve this, the authors provided a service daemon and a fake shell so that attackers cannot recognize the system as a honeypot. In the literature [4], the DecoyPort system was proposed, which directs attackers to a honeypot. The system creates decoy ports on active computers that are not used by legitimate services. Whenever any query or request reaches these ports, the system redirects it to the honeypot. This system not only acts as a port forwarder but also controls the network load caused by attackers. Through such a high-interaction honeypot deployment, the authors noted that the likelihood of attacks might increase.
In [11], the author describes the implementation and deployment of honeypots based on numerous real, vulnerable web applications. They hosted all web applications on seven separate virtual machines running on a VMWare server. To limit the attack surface, the author allowed public-facing services to run as non-privileged users. Then, they analyzed the collected data to study the attackers’ behavior both before and after exploiting the web applications. In contrast, we used actual physical IoT devices to establish a highly interactive honeypot.
In studies related to general honeypots, we only identified one research focused on IoT [27]. In this work, a low-interaction honeypot was provided for IP cameras and Digital Video Recorders (DVRs). The authors simulated the Telnet service of these devices. No real devices were used in the deployment of the honeypot. The authors aimed to capture Telnet-based attacks and analyze the relevant IoT devices.
The document [29] describes another intriguing aspect. The authors discuss the necessity of deploying distributed honeypots to monitor local attack trends and location-specific attack behaviors. The authors deployed low-interaction honeypots in various countries, receiving active participation from different academic, industry, and government organizations. These honeypots simulate various operating systems. The authors demonstrated the similarities and differences in attacking honeypots at different locations.
The text [28] presents a game theory model. This paper simulates a scenario where an attacker decides which server in the network to attack. The authors describe a honeypot selection game that will entice the attacker to target a honeypot rather than an actual server. They conducted empirical research and analysis on the behavior of attackers. They have shown that, in addition to honeypot design, strategies should also be emphasized.
A recent paper [24] proposed a Bayesian game for defending against attacks in IoT environments supported by honeypots. This paper describes different game scenarios based on the varying strategies of attackers and defenders. The game underwent systematic mathematical analysis, and the Bayesian model was evaluated through simulation.
Our work focuses on a high-interaction distributed honeypot composed of real IoT devices, compared to existing literature. This setup allows for the capture and analysis of real traffic and attacks from different geographical locations and measures tracking behavior across various sites. To the best of our knowledge, we are the first to propose and implement such an architecture.
1.7.Conclusion
This article proposes a design for a distributed scalable high-interaction IoT honeypot. The design describes the deployment of IoT devices in a single lab as geographically distributed by establishing tunnels between public IP addresses and physical devices. It also facilitates traffic collection for further processing and analysis. We have implemented a prototype of this design with five IP cameras and an NVR, allowing global attackers access to 85 IoT devices. Our implementation enabled us to collect several gigabytes of traffic data, which we have subjected to preliminary analysis, particularly from the perspective of locations that hold higher appeal to attackers.
In the collected data, we particularly noted over 400 attempts to bypass authentication on our devices through brute force attacks, resulting in 42 successful logins to these devices. We’ve observed a significant amount of traffic to our devices, but comparatively fewer interactions with the network interfaces of these devices. We speculate this is because the attack tools used for such assaults are not highly automated, and there’s a relatively low number of manual attacks compared to automated ones. Among all deployed devices, a particular model of DLink camera received approximately 60% of the total traffic, which we speculate is due to the vulnerabilities of this model being resurfaced. Devices in Frankfurt and Singapore attracted the most traffic, confirming our hypothesis that location is crucial.
We have already integrated other IoT devices, such as IP printers, into our high-interaction honeypot and attempted to understand the attackers’ interactions. Additionally, we deployed a low-interaction honeypot using an IP camera simulator to compare the attackers’ behavior with that of the high-interaction honeypot. We observed that attackers demonstrated more interest in genuine IP cameras than in simulators or other devices.
In the future, we plan to add more devices to our honeypots, such as household appliances. We also intend to conduct deeper analysis on the data collected and share our findings with other researchers interested in such analyses. Additionally, we will incorporate intrusion prevention systems to protect our devices from significant harm. Furthermore, we aim to integrate the SIPHON framework with the IoT testbed presented in [33]. By combining SIPHON with the IoT testbed, we have two primary objectives. First, we can use SIPHON as one of the security testing mechanisms for the IoT testbed. This can be achieved by exposing any IoT devices tested on the testbed to the internet through the SIPHON framework as a honeypot, and by utilizing the measurement (monitoring) module on the testbed, we can detect attacks from the internet and potential vulnerabilities in IoT devices. Second, we can use the IoT testbed as a component of the SIPHON mechanism. By placing IoT devices on the testbed, we can leverage the testbed’s entrapment module to enhance the reliability of the SIPHON honeypot. For instance, we can use GPS spoofing to send various GPS locations, simulate networks connected to the IoT, or use the honeypot to mimic user activity.
1.8.References
[1] DLink dcs-930l camera vulnerability.
http://securityaffairs.co/wordpress/49143/breaking-news/d-link.html. Accessed: 2016-08-10.
[2] Masscan the internet port scanner.http://tools.kali.org/information-gathering/masscan. Accessed: 2016-08-10.
[3] 2005. ITU report : The Internet of Things.
[4] The DecoyPort: Redirecting Hackers toHoneypots. Springer Berlin Heidelberg, Sept. 2007.
[5] 2016. Gartner report Forecast: IoT Security,Worldwide.
[6] 2016. IDC report Internet of Things: SecurityPractices.
[7] E. Alata, V. Nicomette, M. Dacier, M. Herrb,et al. Lessons learned from the deployment of a high-interaction honeypot.arXiv preprint arXiv:0704.0858, 2007.
[8] E. Albin. A comparative analysis of the snortand suricata intrusion-detection systems. PhD thesis, Monterey, California.Naval Postgraduate School, 2011.
[9] E. Androulaki, C. Soriente, L. Malisa, and S.Capkun. Enforcing location and time-based access control on cloud-stored data.In Distributed Computing Systems (ICDCS), 2014 IEEE 34th InternationalConference on, pages 637–648, June 2014.
[10]R. Bodenheim, J. Butts, S. Dunlap, and B.Mullins. Evaluation of the ability of the shodan search engine to identifyinternet-facing industrial control devices. International Journal of CriticalInfrastructure Protection, 7(2):114–123, 2014.
[11]D. Canali and D. Balzarotti. Behind the scenes of online attacks: an analysis of exploitation behaviors on the web. In 20th Annual Network & Distributed SystemSecurity Symposium (NDSS 2013), pages n–a, 2013.
[12]Dyn attack 2016. http://dyn.com/blog/
dyn-analysis-summary-of-friday-october-21-attack/.Accessed: 2016-12-06.
[13]W. Fan, Z. Du, and D. Fern´andez. Taxonomy ofhoneynet solutions. In SAI Intelligent Systems Conference (IntelliSys), 2015,pages 1002–1009. IEEE, 2015.
[14]A. Francillon, B. Danev, and S. Capkun.Relay attacks on passive keyless entryand start systems in modern cars. In Proc. Network and Distributed SystemSecurity Symp. (NDSS), 2011.
[15]J. B. Grizzard, S. Krasser, and H. L. Owen. TheUse of Honeynets to IncreaseComputer Network Security and User Awareness. Journal of Security Education,1(2-3):23–37, 2005.
[16]M. Guri, Y. Poliak, B. Shapira, and Y. Elovici.Joker: Trusted detection of kernel rootkits in android devices via jtaginterface. In Proceedings of Trustcom,
volume1, pages 65–73, Aug 2015.
[17]P. Hane. IPWHOIS: A library for RDAP (HTTP)lookups. https://pypi.python.org/pypi/ipwhois, 2015.
[18]T. Holz, M. Engelberth, and F. Freiling.Learning more about the underground economy: A case-study of keyloggers anddropzones. In European Symposium on Research in Computer Security, pages 1–18.Springer, 2009.
[19]Y.-C. Hu, A. Perrig, and D. B. Johnson.Wormhole detection in wireless ad hoc networks. Technical Report Tech. Rep.TR01-384, Department of Computer Science, Rice University, 2002.
[20]Y.-C. Hu, A. Perrig, and D. B. Johnson. Packet leashes: adefense against wormhole attacks in wireless networks. In Proc. of the IEEEConference on Computer Communication (InfoCom), volume 3, pages 1976–1986.IEEE, 2003.
[21]Y.-C. Hu, A. Perrig, and D. B. Johnson.Wormhole attacks in wireless networks. IEEE journal on selected areas incommunications, 24(2):370–380, 2006.
[22]M. Kim, M. Kim, and Y. Mun. Design andimplementation of the honeypot system with focusing on the session redirection.In International Conference
onComputational Science and Its Applications, pages 262–269. Springer, 2004.
[23]I. Kotuliak, P. Ryba´r, and P. Tru´chly.Performance comparison of ipsec and tls based vpn technologies. In Proceedingsof Conference on Emerging eLearning Technologies and Applications (ICETA),pages 217–221. IEEE, 2011.
[24]Q. D. La, T. Quek, J. Lee, S. Jin, and H. Zhu.
Deceptiveattack and defense game in
honeypot-enablednetworks for the internet of things.
IEEEInternet of Things Journal, PP(99):1–1, 2016.
[25]J. C. Matherly. SHODAN the computer searchengine. https://www.shodan.io. Accessed: 2016-08-01.
[26]Mirai malware 2016.http://blog.malwaremustdie.org/ 2016/08/mmd-0056-2016-linuxmirai-just.html.Accessed: 2016-12-04.
[27]Y. M. P. Pa, S. Suzuki, K. Yoshioka, T.Matsumoto,
T.Kasama, and C. Rossow. IoTPOT: Analysing the Rise of IoTCompromises. In 9th USENIX Workshop on Offensive Technologies (WOOT). USENIXAssociation, 2015.
[28]R. P´ıbil, V. Lisy´, C. Kiekintveld, B.Boˇsansky´, and
M.Pˇechouˇcek. Game Theoretic Model of Strategic Honeypot Selection in ComputerNetworks, pages 201–220. Springer Berlin Heidelberg, Nov. 2012.
[29]F. Pouget, M. Dacier, and V. Pham. on the advantages of deploying a large scaledistributed honeypot platform. In Proceedings of the E-Crime and ComputerEvidence Conference, 2005.
[30]N. Provos. A virtual honeypot framework. InProc. of the USENIX Security Symposium, 2004.
[31]N. Provos and T. Holz. Virtual honeypots: frombotnet tracking to intrusion detection. Pearson Education, 2007.
[32]P. Richter, M. Allman, R. Bush, and V. Paxson.A primer on ipv4 scarcity. SIGCOMM Comput. Commun. Rev., 45(2):21–31, Apr.2015.
[33]S. Siboni, A. Shabtai, N. O. Tippenhauer, J.Lee, and
Y.Elovici. Advanced security testbed framework for wearable iot devices. ACMTransactions on Internet Technology (TOIT), 16(4):26, 2016.
[34]L. Spitzner. The honeynet project: Trapping thehackers. IEEE Security & Privacy, 1(2):15–23, 2003.
[35]W. Zhang and B. Qu. Security architecture ofthe internet of things oriented to perceptual layer. International Journal onComputer, Consumer and Control (IJ3C), 2(2):37–45, 2013.