Towards Automatic Identification and Blocking of Non-Critical IoT Traffic Destinations

by   Anna Maria Mandalari, et al.

The consumer Internet of Things (IoT) space has experienced a significant rise in popularity in the recent years. From smart speakers, to baby monitors, and smart kettles and TVs, these devices are increasingly found in households around the world while users may be unaware of the risks associated with owning these devices. Previous work showed that these devices can threaten individuals' privacy and security by exposing information online to a large number of service providers and third party analytics services. Our analysis shows that many of these Internet connections (and the information they expose) are neither critical, nor even essential to the operation of these devices. However, automatically separating out critical from non-critical network traffic for an IoT device is nontrivial, and requires expert analysis based on manual experimentation in a controlled setting. In this paper, we investigate whether it is possible to automatically classify network traffic destinations as either critical (essential for devices to function properly) or not, hence allowing the home gateway to act as a selective firewall to block undesired, non-critical destinations. Our initial results demonstrate that some IoT devices contact destinations that are not critical to their operation, and there is no impact on device functionality if these destinations are blocked. We take the first steps towards designing and evaluating IoTrimmer, a framework for automated testing and analysis of various destinations contacted by devices, and selectively blocking the ones that do not impact device functionality.



There are no comments yet.


page 1


Blocking without Breaking: Identification and Mitigation of Non-Essential IoT Traffic

Despite the prevalence of Internet of Things (IoT) devices, there is lit...

Rapid IoT Device Identification at the Edge

Consumer Internet of Things (IoT) devices are increasingly common in eve...

A Haystack Full of Needles: Scalable Detection of IoT Devices in the Wild

Consumer Internet of Things (IoT) devices are extremely popular, providi...

A Cybersecurity Guide for Using Fitness Devices

The popularity of wearable devices is growing exponentially, with consum...

Automating Internet of Things Network Traffic Collection with Robotic Arm Interactions

Consumer Internet of things research often involves collecting network t...

Network Service Dependencies in Commodity Internet-of-Things Devices

We continue to see increasingly widespread deployment of IoT devices, wi...

Ask the Experts: What Should Be on an IoT Privacy and Security Label?

Information about the privacy and security of Internet of Things (IoT) d...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Consumer Internet of Things (IoT) devices are increasingly seen in our households, including smart TVs and speakers, surveillance cameras and doorbells, connected kitchen appliances, infrastructure monitoring devices, and wearables. While these devices often come with interesting and beneficial services, they open the door to a variety of privacy and security risks. Privacy risks, at the network and application layers, have been extensively covered in previous research [7, 4, 8]. IoT devices often contact a large number of destinations [7] that can be classified as: First party, manufacturer of the IoT device responsible for providing and supporting the device functionality; Support party, any companies providing outsourced computing resources, such as CDN and cloud providers; and Third party, any party that is not a first or support party, including advertising and analytics companies.

While a number of experimental and commercial IoT Security solutions are available for blocking malicious or otherwise undesirable connections (see Section V for more), these often rely on user configuration for each device, and often provide an all-or-nothing connectivity option for traffic destinations without considering whether blocking traffic will break device functionality. There is a need for an approach that can block network traffic with little-to-no user configuration, and without breaking a device’s primary functionality. Doing so can substantially reduce the privacy and security attack surfaces for IoT devices. A key requirement for this approach is to establish and maintain a list of network destinations that are essential for device functionality, and thus should not, in general, be blocked.

In this paper, we make a first attempt at providing an automated framework for detecting and isolating such non-critical communications from IoT devices. We design and implement IoTrimmer, a tool for rigorously testing the network connections made by each device against their functionality, and establishing whether limiting those specific connections adversely affects the device functionality. In a way, IoTrimmer works like a firewall or an ad blocker [5] for IoT devices that can be implemented on a home gateway. By using the device companion apps (on smartphones), IoTrimmer is able to automatically control IoT devices and trigger their actions.

Our key research contributions include:

  • Designing and implementing automated experiments and self-validation for the interaction between IoT devices and their respective smartphone companion apps.

  • Understanding DNS behavior for each device, i.e., collecting the set of destinations based on DNS requests.

  • Automatically detecting if such destinations are critical, i.e., required for proper device functionality, and iteratively filtering the non-critical ones.

As a proof-of-concept study for IoTrimmer, we use three IoT devices: two security cameras and a smart bulb. By running more than 1,000 automated experiments, we find that some devices make more network connections than needed for them to function normally. There are some commonalities among the non-critical destinations contacted by different IoT devices: some IoT devices contact non-critical destinations outside their region, and out of 9 destinations contacted by our three IoT devices, 4 are unnecessary.

While this short paper covers only a small number of devices at the time of writing, we are expanding our analysis to a much larger set. Based on our initial findings, we argue that our methodology has potential for: (i) Ability to evaluate portability of the filter list from one device to other devices; (ii) Understanding partially-necessary destinations (i.e. those necessary for one functionality but not for others); and (iii) evaluating blocking strategies and their impact on functionality.

Ii Goals and Assumptions

Fig. 1: Overview of IoTrimmer for the TP-Link smart bulb: (a) step 1, power off/on the device and start functionality; step 2, get the list of destinations; step 3, block the destination using DNS override; step 4, test the functionality and perform the auto validation.

In this work we attempt to measure non-critical communication from popular consumer IoT devices to servers in the wild. In particular, we focus on characteristics of the destinations of their IP traffic, whether such communication is needed for the standard functionality of the device. In this section, we define our key questions, challenges, and implications concerning destinations contacted by IoT devices.


The goal of this work is to answer the following research questions.

Do IoT devices communicate with destinations that are not critical to their functionality? When a device initiates a communication with a destination over the Internet, it is by definition exposing some information. Since from our experience the vast majority of IoT traffic is encrypted, we do not know what information is actually exposed. However, we can assume that if the device still works after blocking a destination, that destination is unlikely to be essential to the functionality of the device (and thus the potential information exposure is not needed). To answer this question, we track all the destinations that are not essential for the standard functionality of the device (i.e., considering a smart bulb, destinations that are not necessary for switching the light on/off). From now on we refer to these destinations as blockable destinations.

Are there any patterns or trends on the blockable destinations among different devices? While there are a number of ways to classify destinations, in this short paper we focus only on whether any non-critical destinations are universal—i.e., non-critical for different devices and categories.


We consider as destination the DNS destination, the domain name requested by the device, according to its DNS queries. We further distinguish destinations as follows:

  • Same domain, different ports is considered a different destination.

  • Two different IPs, resulting from resolving the same DNS destination, and contacted on the same port, are considered the same destination.

  • We use IP addresses in place of DNS name if there is no DNS name (i.e. hard-coded IP addresses).

Iii IoTrimmer Architecture

We briefly introduce the mechanisms used by the IoTrimmer to validate the automated experiments. Then, we describe our approach for understanding DNS behavior for consumer IoT devices and demonstrate the IoTrimmer operations.

Testbed Setup and Devices

To test our IoTrimmer, we have built a testbed that currently comprises 122 different IoT devices in two labs, one in the US and one in the UK. We selected these devices to provide diversity within and between different categories: surveillance, video, audio, hub, appliance and home automation devices. In addition to the devices, a Linux server running Ubuntu 18.04 with two Wi-Fi cards for 2.4 GHz and 5 GHz connections, plus two 1 Gbps Ethernet connections for LAN and Internet connectivity are part of the setup. The server sits outside of any firewall and has a public IPv4 address. However, to match a regular home network environment, all IoT devices are behind a NAT setup and cannot be accessed directly from the Internet.

The monitoring software automatically detects connection of a new device to the network, assigns it a local IP address, and starts capturing packets using tcpdump. Each device’s traffic is filtered by MAC address into separate files. The IoT devices can usually be controlled via a companion device such as a smartphone application, an Alexa voice assistant or a Google Home. Our testbed allows us to perform automated experiments on the IoT devices using these companion devices. In this case, the monitoring software captures the network traffic of both IoT and companion devices into separate PCAP files. The testbed allows us to capture several network traces for each device, get destinations and perform self-validating automated experiments under different conditions. Finally, the testbed allows us to block traffic at device level by overriding DNS answers for specific hostnames using bind’s view and RPZ zones.

Self-validating Automated Experiments

The IoT devices can usually be controlled by a smartphone app or other IoT devices. An empowering factor of IoTrimmer is automation. Our IoTrimmer involves automated interactions. For IoT devices that require a companion app, we use Nexus 5X smartphones running Android 6.0.1. We rely on the Monkey Application for Android Studio [6] for automating the interaction between the user and the IoT device. We conduct power experiments and automated interaction experiments to analyze the destinations contacted by each device under various conditions.

Power experiments. In our previous study [7], we found that many IoT devices transmit significant amount of traffic every time they are powered off and on. Based on this, the power experiments consist of controlling the devices through several TP-Link smart plugs that supports local control using a console application. Thanks to these smart plugs, we are able to control the power status of the IoT devices under test, and power them off and on through scripts. We force the devices to be off for a certain amount of time, then we turn them on and capture the network traffic for two more minutes with no operation. We automatically repeat the operation multiple times for every IoT device.

Interaction experiments. To detect the unnecessary destinations for an IoT device, we conduct interaction experiments. An IoT device can have different functionalities, for example switching on/off the light for a smart bulb is the main functionality, but the app can also provide an option for controlling the brightness. To avoid mixing traffic from previous experiments, we perform interaction experiments every two minutes. After two minutes, and just before the communication begins, we start capturing the traffic and analyze the destinations contacted during the interactions required to trigger the device functionality.

Our interaction experiments include: (i) LAN application functionality, when the phone used for the interaction is on the same network as the IoT device, in which case the IoT device may communicate directly with the phone; (ii) WAN application functionality, when the phone is on another network than the IoT device. In this case the device must use a cloud service for communicating with the phone.

The interaction between the IoT device and the phone app may fail. As part of the interaction experiments, we created a tool for validating them using screenshots matching. Screenshots may change because of dynamic data (i.e., time and temperature, appearance of pop up in the app, etc.), hence we only consider the part of the screen where the functionality is visible and crop that area. Figure 1 Step 4 shows the methodology for such operation.

We perform the auto-validation in 6 steps:

  1. Automatically capturing all the screenshots of a given functionality of the companion app and use those screenshot as baseline for comparison.

  2. Starting the functionality automatically by opening the app using Monkey and sending the proper sequence of presses to trigger such functionality (i.e., switching on the light).

  3. Using adb shell for taking the screenshot after the device interactions have been completed.

  4. Transferring the screenshot from the phone to the processing server.

  5. On the processing server, comparing the current screenshot with the base screenshot, using ImageMagick.111

  6. If the screenshots match, we flag the experiment as successful, otherwise we consider it failed.

DNS Behavior

We created some experiments for understanding the DNS behavior for the IoT device. We perform various power experiments, switching off the devices for 2sec, 4min, 8min, 16min, 32min, 64min, 128min, 188min. This test helps us to understand the minimum duration to switch off a device before getting the list of destinations, in order to get as many DNS queries as possible.

Detecting and Blocking Destinations

IoTrimmer is able to automatically detect the list of destinations contacted by the IoT device and block the ones that are not necessary for the standard functionality of the device. Depending on the outcome of the self-validation, a destination can be either:

  • blockable for all experiments for that device: blocking the destination does not break any functionality of the device.

  • blockable for some experiments: blocking the destination breaks some of the functionalities of the device.

  • unblockable: blocking the destination breaks all the functionalities of the device.

IoTrimmer consists of two main steps, we (i) first gather the list the destinations contacted by the device when powering off and on and while performing the functionality and (ii) secondly we block the destinations one by one by testing the functionality using the auto validation tool.

The steps are described below:

  1. Powering off the device for two minutes. We capture the traffic for two minutes and get destinations.

  2. Powering off the device again for two minutes. We start the functionality (i.e. switching on the light) and capture the traffic until the functionality execution is complete.

  3. Performing the auto validation as shown in Figure 1 and get the list of destinations contacted during power and interaction experiments.

  4. Blocking the destination one by one by first powering off the device for two minutes. We block the destination using DNS override to map the DNS name to localhost (, effectively sending all traffic for that site to the loopback address.

  5. Starting the functionality (i.e. switching on the light) and wait the necessary time until the functionality execution is complete.

  6. Performing again the auto validation.

  7. Based on the results of the auto validation, we flag the destination as either blockable or unblockable for that specific functionality.

Repeating Experiments

We repeat the experiments at least 30 times per device, per functionality. In order to check the correct functionality of the experiment, IoTrimmer sends a notification to us automatically, if the auto validation fails for more than three times in a row.

Iv IoTrimmer

In this section, we study the destinations contacted by the IoT devices and then present the results from IoTrimmer. As an example, we consider three IoT devices from our testbed: TP-Link smart bulb, Yi Camera, and Bosiwo camera.

Device Activity # of # of Domains/hard-coded IPs
domains hard-coded IPs
TP-Link smart bulb LAN/WAN switch off/on, power 5 0,,,,
Yi Camera LAN/WAN watch, power 2 0 (WAN only),
Bosiwo Camera LAN/WAN watch, power 2 1,,
TABLE I: List of contacted destinations per device.

Domain Destination Analysis. Table I shows the list of domains contacted by the devices during the interactions and power experiments. For example, TP-Link smart bulb contacts five domains during the power and the action of switching on/off the light: two NTP servers for synchronize the time, the TP-Link domains and the Amazon Web Server for the functionality of switching on/off the light.

IPs Destination Analysis and Hard-Coded IPs. Some devices may have hard-coded IPs. The IP address contacted is assigned manually in the settings of the device and does not change. The Bosiwo camera for example contacted a hard-coded IP address. We use WHOIS data for identifying the owner of the IP address as reported by the corresponding regional registry.

DNS Behavior. We study the number of unique DNS queries per device, per duration of the power experiment. Results show that the bulb made 5 queries and the cameras made 2 queries each, regardless of the duration of the power experiment. The test validates that it is safe for each experiment to wait no more than 2 minutes for getting the destinations.

Device Activity Domains Blockable
TP-Link smart bulb LAN switch off/on
TP-Link smart bulb LAN switch off/on
TP-Link smart bulb LAN switch off/on
TP-Link smart bulb LAN switch off/on
TP-Link smart bulb LAN switch off/on
TP-Link smart bulb WAN switch off/on
TP-Link smart bulb WAN switch off/on
TP-Link smart bulb WAN switch off/on
TP-Link smart bulb WAN switch off/on
TP-Link smart bulb WAN switch off/on
Yi Camera LAN watch
Yi Camera WAN watch
Yi Camera WAN watch
Bosiwo Camera LAN watch
Bosiwo Camera LAN watch
Bosiwo Camera LAN watch
Bosiwo Camera WAN watch
Bosiwo Camera WAN watch
Bosiwo Camera WAN watch
TABLE II: List of blockable/unblockable destinations per device.

Blockable Destinations. Table II shows the destinations contacted by the device and whether it is blockable or not (✓, ✗). Among 9 destinations contacted, 4 are blockable (i.e., blocking them does not affect the device functionality for that given experiment). At least one destination is blockable for each device.

Blockable destinations are mostly support parties, needed for clock synchronization (, and logs (, except for the hard-coded IP contacted by the Bosiwo camera. It is not immediately clear why the camera continuously pings that IP address. Our analysis shows that the owner of the IP is Computer Network Information Center in China.

Destination #of Devices Protocol Port Amount of Traffic(%) 1 NTP 123 1.53 1 NTP 123 1.47% 1 TCP 80 2.8% 1 ICMP 123 0.12%
TABLE III: Traffic characterization for the blockable destinations. For each destination we list the number of devices contacting that destination, the protocol, the destination port and the average amount of traffic (in percentage) sent to that destination over the total traffic sent for the entire duration of the experiment.

Table III summarizes the characteristics of the traffic sent to the destinations that are blockable. The traffic includes NTP, TCP over port 80 (HTTP traffic), and ICMP protocols.

Generalization Analysis. We now investigate similarities among blockable destinations (e.g., same port, domain, organization, 2nd-level domain, etc.). This helps to generalize the blocking from one to other devices. Results show that support services such as AmazonAWS are never blockable, while servers for NTP traffic are always blockable for all the experiments and all the devices. Some destinations may be blockable for one functionality and unblockable for others, we do not detect that behavior.

Longitudinal Analysis. We also perform experiments for understanding whether a destination is blockable at given time and not blockable anymore after a certain amount of time. We repeat the experiments in different times for a period of one month. We did not find any significant differences on blockable destinations or destinations contacted.

V Related Work

The increasing awareness in privacy and security risks in the consumer IoT market has led to a number of tools to protect against abnormal IoT traffic. For example, SPIN222

is an open source software tool which focuses on visualizing and blocking traffic to and from IoT devices. Tools and platforms such as ShieldIOT,

333 Fing,444 and Bitdefender555 provide solutions to protect against known vulnerabilities, or to isolate devices from the network based on their MAC/IP address. However, the majority of these solutions depends on existing knowledge of devices and their destinations, which is not easy to obtain and evaluate with an ever-expanding set of devices.

There are a number of existing tools for IoT traffic and privacy risk analysis. For examples, IoT Inspector [3] collects smart home traffic in scale using ARP spoofing. In recent work [7], we studied information exposure from 81 consumer IoT devices from two testbeds in different countries.

One of our main objectives is to analyze and block destinations specifically for a given device, and for specific device-functionality scenarios. IoTrimmer tests the device functionality and blocks the destinations which are blockable without impacting other functionalities. IoTrimmer will also help to define general rules for blocking unnecessary destinations in smart home environments, in manner similar to ad blockers in browsers [1].

Vi Discussion and Conclusion

Having motivated the need for identifying non-critical destinations in IoT environments, we created and tested IoTrimmer, an automated framework that filters those non-critical connections, testing automatically the device functionality.

We presented results from three IoT devices in our lab, two cameras and a smart bulb. We performed more than 1,000 automated experiments and validated them. Most devices make more network connections than needed for them to function normally. Out of 9 destinations contacted by three of our tested IoT devices, 4 are blockable. Some devices, such as the Bosiwo camera, contact destinations located in countries outside of their testbed’s privacy jurisdiction.

In this paper we demonstrated that limiting NTP traffic does not affect the device functionality over the timescale of our study; however time desynchronization may affect other functionalities (e.g., certificate validation) in some cases. As future work, we plan to analyze the cascading effects of limiting that kind of traffic, and alternatives to always blocking (e.g., allowing clock synchronization at randomized intervals). We also plan to detect whether each non-critical destination is used for other important purposes (e.g., updating the firmware of the device). In addition to exploring non-critical traffic for more devices and over longer timescales, we will investigate the potential for blocking traffic between devices in the same LAN, and study differences arising from deploying the same devices in different geographical regions. Finally, we plan to implement and evaluate IoTrimmer on an edge platform such as the Databox [2] as a home gateway device.


We acknowledge constructive comments and feedback from the reviewers of IEEE S&P ConPro’20. This research was partially supported by the NSF CNS-1909020, the EPSRC Databox (EP/N028260/1), and the EPSRC Defence Against Dark Artefacts (EP/R03351X/1) grants.


  • [1] Ashish Kumar Singh and V. Potdar (2009-02) Blocking online advertising - a state of the art. In 2009 IEEE International Conference on Industrial Technology, Vol. , pp. 1–10. External Links: Document, ISSN null Cited by: §V.
  • [2] Crabtree et al. (2018) Building accountability into the Internet of Things: the IoT Databox model. Journal of Reliable Intelligent Environments 4 (1), pp. 39–55. External Links: Document, ISBN 2199-4676, Link Cited by: §VI.
  • [3] D. Y. Huang, N. Apthorpe, G. Acar, F. Li, and N. Feamster (2019) IoT inspector: crowdsourcing labeled network traffic from smart home devices at scale. External Links: 1909.09848 Cited by: §V.
  • [4] H. Mohajeri Moghaddam, G. Acar, B. Burgess, A. Mathur, D. Y. Huang, N. Feamster, E. W. Felten, P. Mittal, and A. Narayanan (2019) Watching you watch: the tracking ecosystem of over-the-top tv streaming devices. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, External Links: Document Cited by: §I.
  • [5] R. Nithyanand, S. Khattak, M. Javed, N. Vallina-Rodriguez, M. Falahrastegar, J. E. Powles, E. D. Cristofaro, H. Haddadi, and S. J. Murdoch (2016-08) Adblocking and counter blocking: a slice of the arms race. In 6th USENIX Workshop on Free and Open Communications on the Internet (FOCI 16), Austin, TX. Cited by: §I.
  • [6] P. Patel, G. Srinivasan, S. Rahaman, and I. Neamtiu (2018) On the effectiveness of random testing for android: or how i learned to stop worrying and love the monkey. In Proceedings of the 13th International Workshop on Automation of Software Test, External Links: Document Cited by: §III.
  • [7] J. Ren, D. J. Dubois, D. Choffnes, A. M. Mandalari, R. Kolcun, and H. Haddadi (2019) Information exposure from consumer iot devices: a multidimensional, network-informed measurement approach. In Proceedings of the Internet Measurement Conference, External Links: Document Cited by: §I, §III, §V.
  • [8] J. Varmarken, H. Le, A. Shuba, A. Markopoulou, and Z. Shafiq (2020) The tv is smart and full of trackers: measuring smart tv advertising and tracking. Proceedings on Privacy Enhancing Technologies 2, pp. 129–154. Cited by: §I.