Comunicación efectiva

In the area of profile enforcement, the implemented prototype has a number of limitations. One of those limitations is the fact that domain names in profiles are looked up only upon profile enforcement (see the previous section). Additional limitations are discussed below.

Traffic on the local network

Traffic from or to the Internet flows through the firewall and as such is subject to the rules imposed by the firewall. However, traffic between two local devices does not go through the firewall since the devices are in the samebroadcast domain and as such do not need a router to route packets for them; instead, the packets are sent directly to their neighbors using Ethernet. As such, an enforced profile will not restrict traffic that stays on the local network.

There are solutions to this problem. For instance, Mortier et al. [39] propose and imple- ment a method to force devices to route their local traffic through the router as well. As a short and incomplete summary, the idea is to allocate a /30network for each device in the network. The device is assigned an IPv4 address in this /30 and the router also is assigned an IPv4 address in this /30. Traffic between devices then needs to travel from one /30to the other and as such, it must be routed through the router. Therefore, the router is able to filter such traffic. This method breaks broadcast traffic; broadcast traffic stays inside a/30and as such does not reach other devices inside the network. Mortier et al. deal with this by rewriting the destination address of the broadcast traffic and making sure it is sent to the other device’s/30s as well.

Due to time constraints, this method has not been implemented for this prototype and as such, local traffic is unaffected by the imposed rules. Only traffic from or to the Internet is subject to the enforced profile. To illustrate this, we will use the network from Figure 3.2 as an example. Traffic between the fridge and the Internet would be subject to the profile. However, traffic between the phone and the fridge would not be subject to the profile as the phone and the fridge both reside in the local network.

Portability of the generated firewall rules

The iptables rules that are generated by the profile enforcer are tailored towards the way iptables is used in OpenWRT. As such, in order to use the programs on a “normal” system, the profile generator needs to be adapted slightly.

4.7

Updating a Profile

The last activity, updating a profile, is not depicted in Figure 4.3. That is the case because, as was described in Section 3.4, the process of updating a profile is actually composed of steps that were already implemented previously. During the period in which the prototype was used, it has not been necessary to update the profile. As outlined in Section 3.4, there are two reasons for updating a profile: either the user behavior changed such that updating the profile becomes necessary, or a software update was installed onto the IoT device. However, neither of these events occurred during the testing phase. Therefore, it was not necessary to perform this step. However, since this activity consists of executing steps which were already implemented, updating a profile would be straightforward.

Chapter 5

Evaluation

With the prototype built, it is time to evaluate it. We evaluate the prototype in order to verify that the implemented system matches the expectations encoded in the Research Questions. The evaluation will be performed by defining criteria and verifying whether the prototype meets the criteria. The first step in evaluating the prototype is to determine what properties or statements actually need to be evaluated. The prototype was built based on the Research Questions. As such, the criteria will based on the Research Questions as well, in order to verify whether the prototype meets our expectations.

5.1

Defining Criteria

Research Questions 2, 3, and 4 relate to the properties of the resulting prototype. This is not the case for Research Question 1. Therefore, Research Questions 2, 3 and 4 are suitable for basing criteria on. Guided by those Research Questions, the following criteria are defined. Those criteria correspond directly to Research Questions 2, 3, and 4. We will verify whether the prototype meets those criteria.

Criterion 1

The IoT device is able to function properly once a profile that has been generated for the device is enforced.

Criterion 2

The enforced profile prevents the IoT device from being hacked.

Criterion 3

The enforced profile prevents the IoT device from being misused in an attack if it were successfully hacked anyway.

5.2

Criteria Satisfaction

Now that the criteria have been defined, it will be determined for each of the criteria when they are met. All criteria have in common that in order to meet them, it is necessary to generate and enforce profiles for devices. In other words, all components of the prototype (as shown in Figure 4.3) will be exercised in order to get to the point where a generated profile can be

enforced. Detailed instructions on how to use the prototype are found in Appendix A.2, so they are not repeated here. Instead, this section focuses on how to determine whether the criteria are met, which can be done if the prototype is used according to the provided instructions.

5.2.1 Criterion 1

Verifying whether criterion 1 is satisfied consists of two steps: (1) The profile should be generated and enforced (see Section A.2). (2) It should be verified that the device still functions properly. Step (2) consists of two parts: (2a)Use the device and observe whether the device still functions according to expectations. That is done by using the different features a device provides. For instance, in the case of a Philips Hue bridge, the tester could connect a phone and light bulbs to the bridge, turn on the light bulb, change the color of the light bulb, etc. (2b) Analyze the network traffic that is generated while performing the tests. In particular, we verify whether the traffic generated by the device is allowed by the profile. During this observation and while the profile is enforced, it may be the case that the device attempts to contact a domain that is not in the whitelist of the profile1. If that is the case, this possibly indicates that the profile is not complete. This needs to be investigated on a case by case basis. The network traffic is monitored in two ways: (i) the packets dropped by the iptables firewall are inspected (if any), and (ii) during the testing,tcpdumpis used to capture the network traffic such that analysis can be performed later, if necessary. For step (2), it is possible to make the test results more robust by documenting all steps taken while testing the device to ensure reproducibility. However, producing precise but lengthy documentation on how to test the devices is out of scope for this research.

5.2.2 Criteria 2 and 3

Criteria 2 and 3 both revolve around the IoT device being the center of attention of an attacker. The most common way for an attacker to interact with its victims is by sending malicious traffic. Other methods, where the attackers do not pro-actively send traffic, also exist; for instance, registering an expired domain used by the devices and move from there. In order to verify whether criteria 2 and 3 are met, it is necessary to know more about the traffic the attackers are sending to the devices. There are multiple methods of investigating the attackers’ traffic and its effects. Two of such methods are described below.

Replaying attack traffic

One of the methods is to replay attack traffic against a device while the profile is enforced. An advantage of this technique is that a simulation like this comes really close to reality because the attack is not just simulated but actually performed. As such, when the device is protected during this test, it is likely to be protected in the real world. A disadvantage is that, in order to replay attack traffic against a device, it is necessary to actually have network traffic of botnet activity. Such traffic is not always easy to get access to. Additionally, depending on the contents of the replayed traffic and on whether the profile actually succeeds in blocking the traffic, the attack against the device may actually succeed. For instance, if the replayed traffic would immediately add the device to

1_{Note that in this case, while the deviceattempts to contact a domain that is not in the profile, it will not}

actuallysucceed in doing so since the domain name is not in the whitelist. This event can be recognized from the pcap traces as follows: the device attempts to initiate a TCP connection (i.e., a TCP packet with theSYN

Abbreviation Description Involved protocol(s)

TCP/22 Dictionary attack against SSH daemon TCP, port 22

TCP/23 Dictionary attack against telnet daemon TCP, port 23 or 2323 TCP/80 Vulnerability in HTTP server TCP, port 80 or 8000 Table 5.1: Summary of common methods to gain access to IoT devices used by botnets.

a botnet, the device could become a participant in the botnet. Therefore, when replaying attack traffic against a device, it is necessary to take appropriate precautions to prevent any of such problems.

Analyzing literature and attack traffic

Another method is to analyze literature and attack traffic (if available) and extract char- acteristics of the malicious network traffic. This can be done on different levels. For instance, it is possible to look at packet sizes or packet rates. Alternatively, it is possible to look at which transport layer protocols and port numbers were involved (for instance: telnet on TCP port 23). Furthermore, it is possible to perform deep packet inspection. In the case of the telnet protocol, the traffic is not encrypted. This makes it possible for an observer to determine how the attacker is interacting with the victim. For instance, it is possible to distinguish between failed login attempts and successful login attempts. For this research, a theoretical approach towards gathering information about the attackers’ activity is chosen. As such, literature has been studied and captured traffic will be analyzed for patterns. In particular, traffic will not be replayed against a device. We expect that a literature study and traffic analysis will provide a sufficient amount of information. It is uncertain how valuable replaying attack traffic would be while it would be time-consuming to create a proper setup in which malicious traffic can be replayed against devices in a safe manner.

We now have decided that we are going to use literature as a source of information regarding attackers’ network. However, verifying whether criterion 2 holds needs different information than verifying whether criterion 3 holds. In order to verify whether criterion 2, The enforced profile prevents the IoT device from being hacked, is satisfied, it is necessary to know how attackers compromise devices and add the devices to their botnets. From the literature in Section 2.4, Table 5.1 has been derived which summarizes the common ways unauthorized access to IoT devices is gained. Those methods can be compared against the whitelist of incoming traffic in the generated profiles to see whether the malicious traffic would reach the device or not.

Conversely, in order to verify whether criterion 3,The enforced profile prevents the IoT device from being misused in an attack if it were successfully hacked anyway, is satisfied, the questions that need to be answered are (a) how do the attackers instruct the devices what to attack, and (b) what kind of traffic does the attack consists of. Answers to those questions can also be found in literature. We will use those answers to theorize whether a device would actually be vulnerable, for instance by comparing the generated profiles against the information found in the literature. From the literature reviewed in Section 2.4, we find that the answer to (a) is that the botnet is either controlled via a centralized infrastructure controlled directly by the attacker, or via a peer-to-peer network. In the former case, often HTTP or a custom protocol is used. From the same literature, we find that IoT botnets mostly carry out UDP and TCP floods. This answers (b).

Internet

Valibox

wired connection wireless connection Device A Device B Device C Device D Device E Device F

Figure 5.1: Schematic overview of the network that was used to evaluate the prototype. Legend: Device A: TP-Link LB100; Device B: VStarcam D1 Door Camera; Device C: Sonoff S20; Device D: Samsung TV; Device E: Motorola Moto X Force; Device F: Philips Hue Bridge.

ID Product name Type of device Network connection type

F Philips Hue Bridge Light bulb controller Wired

A TP-Link LB100 Light bulb Wireless

B VStarcam D1 Door Camera Doorbell with camera Wireless

C Sonoff S20 Power socket Wireless

D Samsung TV TV Wireless

E Motorola Moto X Force2 Mobile phone Wireless

Table 5.2: Devices that were used with the developed prototype.

5.3

Network Setup

In order to evaluate the prototype, it was necessary to deploy the prototype into a test network. This section describes the setup of the network that was used to evaluate the prototype. The network closely resembled a typical home network as depicted in Figure 3.2. As is shown in Figure 5.1, the core of the network, consists of the Valibox mini-router (see Section 4.1). If possible, the devices were connected to the network using a wired connection. Those devices were connected to an Ethernet switch, and the Ethernet switch was connected to the LAN port of the Valibox. The other devices were connected to the network via the Wi-Fi access point provided by the Valibox. During the period in which network traffic was collected, the devices could access the Internet without any restrictions. Table 5.2 shows which devices were part of the network.

2_{While this phone is technically not an IoT device depending on which definition of IoT is used, verifying}

Device Criterion 1 satisfied?

Philips Hue Bridge yes

TP-Link LB100 yes

VStarcam D1 Door Camera yes

Sonoff S20 yes

Samsung TV yes

Motorola Moto X Force yes

Table 5.3: Shows per device whether criterion 1 is satisfied or not.

Host Protocol Port number Direction

devices on local network TCP 80 Incoming

bridge.meethue.com TCP 80 Outgoing dcp.cpp.philips.com TCP 80 Outgoing dcs.cb.philips.com TCP 80 Outgoing diagnostics.meethue.com TCP 80 Outgoing fds.cpp.philips.com TCP 80 Outgoing time.meethue.com TCP 443 Outgoing ws.meethue.com TCP 443 Outgoing www.ecdinterface.philips.com TCP 80 Outgoing www2.meethue.com TCP 443 Outgoing

0.openwrt.pool.ntp.org UDP 123 Outgoing

1.openwrt.pool.ntp.org UDP 123 Outgoing

2.openwrt.pool.ntp.org UDP 123 Outgoing

3.openwrt.pool.ntp.org UDP 123 Outgoing

time1.google.com UDP 123 Outgoing

time2.google.com UDP 123 Outgoing

time3.google.com UDP 123 Outgoing

time4.google.com UDP 123 Outgoing

valibox UDP 53 Outgoing

valibox UDP 67 Outgoing Table 5.4: Profile that was generated and enforced for the Philips Hue Bridge.