I’ll keep reading about the whole Internet of Things (IoT) but something I see missing is the security aspect. Sure there are white papers and article out there how an enterprise should deploy IoT in a secure way, but not much for home and SOHO networks. In this blog post I’ll address the problems of current IoT devices and what you can do to mitigate them. I’ll concentrate on typical IoT devices used/designed for home users.

Why the security of IoT devices sucks

Just remember one mantra – IoT devices suck at security – and here is the why.

Many of these devices are build by Start-ups, which have one goal. Get the product out as fast as possible and get the company bought by someone and hit pay day. Even if not, they need to get enough revenue first and to start than fixing the security problems.

If the device is not build by a Start-up than it got build by an established manufacturer in the area the IoT device is build for. The problem is the manufacturer has no idea about connected devices and that Internet stuff – Its called “Neuland” :-). They will make every error the IT industry did 10-15 years ago. Yes, if you’re that long in the business as I’m you’ll see the same security holes you saw in the first years of this millennium for normal PCs now for IoT devices.

Usability and security is not easy .. so most of the time the easy to use and insecure variant is used

If the IoT device is for a semi established area like IP cams / baby cams the devices are build and designed by a Chinese company and sold under various labels. The company selling the devices does not know anything about the internal workings. If a security problem is found and somehow the OEM vendor in China fixes the problem, you’ll wont get an update from the company that sold the devices.

Automatic updates of the devices is not the norm, so most devices wont get any updates. While in the PC marked it is for years now common that software get updates automatically, the same is not true for most IoT devices. And lets be honest who is checking for security updates of the light bulbs on a regular base?

But before we can talk about automatic updates lets don’t forget that for most IoT devices you’ll get updates only for a short period of time. The vendor wants to sell his next product, so why support the old one? To make the problem bigger most IoT will get used longer than a typical mobile phone, which also suck at security update time frames. No one will replace his/her IP cam every 2 years like a mobile phone (ok, that’s also not true, but its typical a shorter interval)

UPNP was a bad idea and still is one. Some IoT automatically open ports from the internet so any security flaw can be exploited directly from anywhere in the world. Oh, joy! 🙂

Even if the device does not use UPNP it often connects per default directly to a cloud service, over which you (and potentially an attacker) can access your device. e.g. accessing the baby cam via the mobile phone app via and cloud service. There have been some horrible security flaws in the past, like a consecutively numbered ID without password or the MAC address of the device as ID (really heard the guess an MAC address if you know the vendor ID 😉 ).

There are some more points I could made, but these should be already depressing enough.

ps: yes, there are some IoT devices with good security but these are less than 5% of the total market.

Theoretical mitigating the problems

As we’ve established that the security is not good, we need ways to mitigate the problem, within the scope of a home network. To be honest that can’t be done by your typical mum, but needs some one technical minded – but others would not read my blog anyway.

Securing or hardening IoT devices is sometimes possible but for most consumer ones that won’t work. So lets accept that the device will have security problems. In some cases that will be a big problem in its own right, e.g. a IP cam that can be watched from anyone world wide. In other cases e.g. a light bulb that can be controlled from anyone world wide is more a nuisance that a real problem. The same is true for weather station that is readable world wide.

For the first case there is nothing that can be done on the network level as general rule, as disabling the Internet connection for the device will prevent it from working in the first place. Sure there are cases where the cloud connection is not needed, in these you can deactivate or block it. But for the second case there is something. Let’s assume the attacker got access to the IoT device, which is by itself in this example case not that bad, surely a nuisance but not a big problem. The problem arises now from the fact that the IoT device is controlled by the attacker and what he can do with that. So lets look at some possible scenarios.

If the device is connected via WiFi the attacker has now the WPA2 PSK key from your WiFi.

If the family NAS provides the shares without username/password an attacker can access it

Maybe the router can be configured without a secure password or has also a weakness. The attacker can use this to change the DNS servers to allow MiTM attacks

ARP spoofing and similar attack are also possible.

To guard against that attacks you need to segment the IoT network from your normal network, even better isolate the various IoT devices from each other.

Practical mitigation – three stupid routers

The segmentation can be achieved in various ways. The first one needs only standard routers …. just more than one … you need 3 routers. Lets take a look at the diagram:

The first router is often provided by the cable or telephone company and you need to buy 2 stupid/cheap routers behind it. One is for the normal internal network and one for the IoT devices that connect a cloud service. For the IoT device router configure the WiFi in client isolation mode (if possible). As both (internal and IoT) routers masquerade their clients a direct connection is not possible. If a connection should be possible a port forwarding needs to be enabled and also make sure that the IP subnets are different. If one IoT devices gets compromised it can not leak the internal WiFi password as it does not have it. Also accessing the NAS is not possible as the ARP spoofing is not possible. Use the provider router for guest which should not be able to get anything except Internet.

The setup is quite simple and also cheap but has its short comings:

Works only for apartments and small houses – if you need more than one access point for you’re house it does not work.

You need multiple routers, which need more power.

You lack flexibility

Practical mitigation – intelligent router / access points

If you move away from the typical stupid routers you can make use of the more advanced features. The exact setup depends on the used network devices, so I’ll can only show a possible setup. Following requirements need to be met by scenario setup.

Three floors, each with its own access point

IoT and internal devices in each flow, cable and wireless connect ones (multiple SSIDs on each access point)

Clients want to move within the building without loosing connection (same SSIDs on all access points)

Just to make it clear, there are other setups possible to fulfill the requirements. Following diagram shows the possible setup.

The router or firewall (could be a router like a Mikrotik or a pfSense firewall) is the gateway for all 3 networks (yes, I through a guest network in for good measure 🙂 ). On it the policy which network is allowed to connect to which other network is configured. All three networks are connected to the managed switch (if the router has enough ports it may can fulfill the role of switch too). On the switch most ports will be configured for one VLAN but the ports to the access points get all three VLANs.

The access points get configured in way that the management IP address is in the internal VLAN and a separate SSID is used for each VLAN. All access points use the same SSID for the same VLAN, so roaming for the clients is possible. Set the SSID for IoT and external use to client isolation mode (one wireless client can’t communicate with an other)

Optional, if the the switch supports it. Configure private VLANs for the IoT and external network, so only the router can talk with all devices

I hope this blog post shows you the basics for readying your home or maybe SOHO network for IoT devices which will surely come.

I love the idea of separating your devices on different vlans but I’ve found that is very specific to what you have and almost impossible to do cleanly.

For example you would like your phone to be able to access all your devices (WoL your Kodi device, control your AC unit, access your NAS etc)
If only one of your devices is controlled through broadcast traffic the whole plan goes to hell.
My phone was in my “safe” zone and I wanted to control my AC Unit on another VLAN but was unable to do so. Found out through wireshark that the App on my phone did a broadcast on a certain port instead of connecting to it through ip 🙁
There goes my separation.
Was wondering how you are approaching this?

I’m using the second method with multiple separated VLANs with firewall rules between them. I’ve also a phone but it is just a standard SIP phone which connects to my Asterisk server, which handles everything else. The various server services run as KVM instances, even in different VLANs for security.

What kind of IoT device is this type of setup good for if you look at the problems you will run in to? (like controlling a AC Unit, Kodi, A receiver from your phone if you separate everything with vlans?
You “could” place your phone and you receiver, kodi device etc in the same vlan..great, so now you can control your appliance and now you want to play a movie from your NAS..then you will run into the next hurdle that all your content will be routed instead of it being directly accessible.
Please enlighten me for I’m trying to achieve the same thing.

[…] in this blog about IoT (often called Internet of Targets ) where about a specific cam or about IoT at home. This article series will be different, it will focus on the IoT in companies. Part one will talk […]

Pingback by Implementing IoT securely in your company – Part 1 | Robert Penz Blog — January 6, 2017 #