Discussion Proper network setup for IoT security?

[Fallen Kell]

So I have not seen many topics on this in the past and thought I would start one. I am personally in the process of re-architecting my home network. One of the key items that I want to handle is proper segmentation for various "Internet of Things" devices that I now have attaching to my network for better security (since most of these items receive infrequent if any patches/updates and can be vulnerable to attack which can grant a foothold into my network).

Currently, everything is just connected to essentially one network, with no separation of anything (I am not running any kind of guest wireless network at this time). But I believe I may want 4 or 5 different network VLANs/VAPs to at least in my mind separate and isolate the various devices based on various functional criteria (i.e. does it simply need internet access, do other devices in my network(s) need to talk to it, etc.). I also want to setup a wireless guest network.

So on those lines I am thinking something like the following:
1) A VLAN for my primary network (this would be where I connect my various computers/servers)
2) A VLAN for my management network (this would be where I would connect all the various out of band management devices for my various servers/network equipment) (Accessible from VLAN 1)
3) A VLAN for my guest network (this would have access only to the internet)
4) A VLAN for my IoT devices that need to talk to the internet (this would be things such as my lawn sprinkler control, TV's, game consoles)
5) A VLAN for IoT devices that need to talk to local computers/storage (this would be things like media extenders/firesticks/nvidia shield, which might be used to stream audio/video that I own on my storage server)

I believe the above would cover everything. There may be some overlap in the need to create a virtual access point for wireless network connectivity tied to the various hardwire VLAN networks. I believe the equipment I own should be able to facilitate such a setup (my wireless router is running dd-wrt and I have already previously created static DHCP addresses and MAC address whitelists for all my trusted devices). The hardware is modern enough to support multiple wireless networks from the same physical wireless radios and has full VLAN tagging support for the physical ports. I believe I would simply need to assign a VLAN tag to each of the physical ports and connect to my main network switch with that switch using the same VLAN tags for the connecting ports. My main switch is a layer3 switch which I can setup all the rules for routing between VLANs and create the various routes to the internet from the various VLANs.

 

[ch33zw1z]

What hardware are you using?

I have a Ubiquiti ER-X and a UAP-AC-LR

I used this guide and setup two isolated vlans, one for IoT and one for guest. If you're using similar hardware I can post some notes I made while setting it up.

I wanna say the access point can run 4 separate SSID's.

On the IoT vlan, I also whitelisted the MACs for the IoT devices and one phone to admin them if needed. All my IoT's are Nest, so they report into my account I dont need direct network access to manage them

 

[Fallen Kell]

I have a Ruckus Brocade ICX 6610-24-I switch and Netgear R9000 wireless router (running DD-WRT). I am not sure I can configure the 10G connection on the R9000 as a VLAN trunk (i.e. multiple VLANs on the same physical port), so I was planning on using it for the primary network VLAN, as that is where the majority the traffic will be located (I need to do some more digging and do some tests for what works). What I don't want to run into is various network loops if I need to run individual connections to multiple ports on the R9000 to support the multiple VLANs (and VAPs).

 

[ch33zw1z]

Ddwrt maybe supports trunking

Switched Ports - DD-WRT Wiki

wiki.dd-wrt.com

If not, it's very likely you will run into some problems on VLAN's that aren't isolated.

Not sure how the Netgear soho router will play with vlan's and wireless either.

 

[SamirD]

At almost 100 items on my parent's network and almost 20 each on two other networks I manage (all which are joined by ipsec vpn tunnels), I've considered segmenting the networks and potentially using vlans to do so, and I found that vlans can be more cumbersome than necessary as some simple things can be done with static routes, like blocking iot devices from the Internet or a guest network (just using an old cheap router with that as a feature on the wifi).

Your ideas fall in line with a lot of the best practices I've seen, like the management vlan, but unless you need physical lan segmentation, the same effect can be achieved by having more than one IP range on the same physical lan. For example 192.168.0.x for management and 192.168.1.x for regular access. Limiting iot devices by putting them in 192.168.2.x and having no default gateway or route to the Internet for that subnet, etc. Something to consider. I will be very interested in what you end up with as all my equipment is vlan capable.

 

[VirtualLarry]

Your ideas fall in line with a lot of the best practices I've seen, like the management vlan, but unless you need physical lan segmentation, the same effect can be achieved by having more than one IP range on the same physical lan. For example 192.168.0.x for management and 192.168.1.x for regular access. Limiting iot devices by putting them in 192.168.2.x and having no default gateway or route to the Internet for that subnet, etc. Something to consider. I will be very interested in what you end up with as all my equipment is vlan capable.

That's all well and good, until your IoT things get hacked, and start doing ARP poisoning on the LAN, to intercept traffic (LANMAN hashes, etc.) and forward them off to Mainland China.

 

[Fallen Kell]

That's all well and good, until your IoT things get hacked, and start doing ARP poisoning on the LAN, to intercept traffic (LANMAN hashes, etc.) and forward them off to Mainland China.

Yeah, that is why I wanted true segmentation. Just using different subnets on the same network won't prevent those devices from being able to scan for and find the rest of your network devices (i.e. as simple as opening up the netmask to 255.0.0.0 will open it up to viewing everything on 192.*.*.*).

 

[SamirD]

That's all well and good, until your IoT things get hacked, and start doing ARP poisoning on the LAN, to intercept traffic (LANMAN hashes, etc.) and forward them off to Mainland China.

Not sure how that would happen if the IOT devices don't have a route out to the Internet.

 

[SamirD]

Yeah, that is why I wanted true segmentation. Just using different subnets on the same network won't prevent those devices from being able to scan for and find the rest of your network devices (i.e. as simple as opening up the netmask to 255.0.0.0 will open it up to viewing everything on 192.*.*.*).

That is true, but only if someone is on your network and modifies the IP address. They would have to be familiar with the network to do so as well. Besides, if you really want security, vlans tags can also be spoofed so you would want physical lan separation for true security.

 

[ch33zw1z]

Not sure how that would happen if the IOT devices don't have a route out to the Internet.

The catch 22 is that IoT devices can be less configurable and rely on the internet to work fully. My IoT is all nest, it's all managed thru an account. I can manage it from anywhere as long as the device and I are online.

The thermostat can be manually IP with no GW, but then I can't manage it from my phone or PC, and it's not online to pull down software fixes. Nest doesn't really make it known when those will be upgraded either.

The nest protects cannot be manually IP TMK. It's just DHCP as part of the setup. Bluetooth for local admin

In this case, an isolated vlan was the way to go

 

[SamirD]

The catch 22 is that IoT devices can be less configurable and rely on the internet to work fully. My IoT is all nest, it's all managed thru an account. I can manage it from anywhere as long as the device and I are online.

The thermostat can be manually IP with no GW, but then I can't manage it from my phone or PC, and it's not online to pull down software fixes. Nest doesn't really make it known when those will be upgraded either.

The nest protects cannot be manually IP TMK. It's just DHCP as part of the setup. Bluetooth for local admin

In this case, an isolated vlan was the way to go

This is why I would never buy these type of devices as they are the most susceptible to hacking since their attack vector is so large (24x7 connectivity).

If I had to deal with these things I would do the following:

• block their call home feature/Internet access
• vpn into my network with my device to access it that way
• let it connect once a year to check/download updates and then lock it down again

Even if on their own lan, I'd put a 10Mbps hub (yes, not even a switch) to slow their access and make for a quick way to check their packets.

 

[ch33zw1z]

This is why I would never buy these type of devices as they are the most susceptible to hacking since their attack vector is so large (24x7 connectivity).

If I had to deal with these things I would do the following:

• block their call home feature/Internet access
• vpn into my network with my device to access it that way
• let it connect once a year to check/download updates and then lock it down again

Even if on their own lan, I'd put a 10Mbps hub (yes, not even a switch) to slow their access and make for a quick way to check their packets.

slow down sir, you're points need more pondering.

First, the devices themselves are less prone to hacking than people's poor excuse for passwords and lack of user verification enforcement. Nest users had accounts hacked, and it turned out they used poor passwords and never enabled 2FA.

Second, your points:

Block their call home feature/Internet access - like I said, the devices are designed to be managed thru software, they report in to YOUR account, which should be fully secured. It's not good to be fearful of something we can control

VPN into my network with my device to access it that way - I mean, you are free to do that if you like, but again....my particular case won't work like that. It's entirely possible that other IoT devices will tho.

let it connect once a year to check/download updates and then lock it down again - again, that's up to you. I could block Internet access to my IoT isolated VLAN and do that, but why? The devices are *nix based and I want them to stay current as soon as Nest releases updates to them.

Even if on their own lan, I'd put a 10Mbps hub (yes, not even a switch) to slow their access and make for a quick way to check their packets.
- They're WiFi only. They don't pull much data at all. But, in my case, I can just use the Unifi controller software to create a user group, limit the speeds, and apply that user group to the SSID i created for the IoT VLAN. I verified this works just fine on the Guest WiFi, the two are very similar. When I babysit them from time to time, they pull a few hundred kbps here and there. It's very minimal.

We have technology to solve the problems. I understand your points, and I've most certainly used other methods to isolate hosts from internet access in the past. IoT adds a layer of complexity that means we have to change our tactics.

 

[SamirD]

You're welcome to trust the ecosystem that these companies have made to exploit users, but I definitely won't.

Their apps and craps will work fine after you vpn in since you'd be on the same network. It's how I see my cameras when I'm out and about without a hole in the firewall.

nix based stuff is becoming a bigger target and a larger attack vector. A couple of years ago I would have said being nix based was enough, but not anymore.

They should be minimal, but if they got compromised, I would want them physically throttled. But Unifi stuff is pretty solid so them being managed that way I could see it being decently secure.

The tech is the problem 90% of the time. I use the kiss principle a lot to manage these issues since they're usually cheaper to implement and last longer.

 

[ch33zw1z]

You're welcome to trust the ecosystem that these companies have made to exploit users, but I definitely won't.

Their apps and craps will work fine after you vpn in since you'd be on the same network. It's how I see my cameras when I'm out and about without a hole in the firewall.

nix based stuff is becoming a bigger target and a larger attack vector. A couple of years ago I would have said being nix based was enough, but not anymore.

They should be minimal, but if they got compromised, I would want them physically throttled. But Unifi stuff is pretty solid so them being managed that way I could see it being decently secure.

The tech is the problem 90% of the time. I use the kiss principle a lot to manage these issues since they're usually cheaper to implement and last longer.

As I said, your specific IoT devices may work like that. Cameras are not thermostats. I can't start throwing out percentages, because those will be largely anecdotal.

IMXP, users are the problem almost everytime. From homes to data center gear, poorly implemented security or just a complete lack thereof is a far larger problem than the actual tech exploits.

The fact that *Unix system attacks are more common just means I don't sleep on updates. I see a patch, I apply said patch.

IoT covers a huge number of devices, the security mediation methods will change with the tech. If I get cameras in the future, I'm not so rigid as to require them to be on my IoT VLAN. And if they are, I might just have to open another port so they can talk to my main Network.

It's really a hole you can dig for yourself if you're all or nothing and dont adapt as needed.

 

[SamirD]

As I said, your specific IoT devices may work like that. Cameras are not thermostats. I can't start throwing out percentages, because those will be largely anecdotal.

IMXP, users are the problem almost everytime. From homes to data center gear, poorly implemented security or just a complete lack thereof is a far larger problem than the actual tech exploits.

The fact that *Unix system attacks are more common just means I don't sleep on updates. I see a patch, I apply said patch.

IoT covers a huge number of devices, the security mediation methods will change with the tech. If I get cameras in the future, I'm not so rigid as to require them to be on my IoT VLAN. And if they are, I might just have to open another port so they can talk to my main Network.

It's really a hole you can dig for yourself if you're all or nothing and dont adapt as needed.

There's no magic by which the nest thermostats work that other iot devices do or do not. Devices either have local capabilities or rely on outside communication. If the outside communication is an app that can also be local, you can force local only communications.

That is true about users. The will mess up anything if given the opportunity.

You don't need to patch what is not exposed. Like the coronoavirus going around, the guy sitting on an island to himself won't get it. Patching still isn't a bad idea, hence why I would do it at least once a year.

I wouldn't put cameras on a main lan as they are a a huge attack vector and were one of the first type of devices to be compromised. And it's not like the chinese stopped putting back doors in them--they just may be more stealth. Only way to be safe is to disconnect them from the lan and only connect to the nvr for viewing them.

Actually, it's the hole to avoid. The tradeoff for convenience is almost always security, and when you're talking about securing a network, the tradeoff is convenience.

 

[ch33zw1z]

There's no magic by which the nest thermostats work that other iot devices do or do not. Devices either have local capabilities or rely on outside communication. If the outside communication is an app that can also be local, you can force local only communications.

Yea, exactly. IoT is a catch-all term that does cover and will continue to cover a wide range of devices. Adapting the security method to fit the device is a necessity.

You don't need to patch what is not exposed. Like the coronoavirus going around, the guy sitting on an island to himself won't get it. Patching still isn't a bad idea, hence why I would do it at least once a year.

If there's any device exposed at all, then patching anything that device can talk to is a good practice. Each person will do this based on their comfort level. Personally, the IoT devices can get patched asap. When I see a new code level for my ER-X or UAP....I tend to read the change log. If nothing in it applies to me right away, I hold off for a little bit and watch the UI community forums for anyone else having problems

I wouldn't put cameras on a main lan as they are a a huge attack vector and were one of the first type of devices to be compromised. And it's not like the chinese stopped putting back doors in them--they just may be more stealth. Only way to be safe is to disconnect them from the lan and only connect to the nvr for viewing them.

Again, this depends on how those devices are managed. If they were Nest camera's, TMK, they're similar to the other Nest devices.

Actually, it's the hole to avoid. The tradeoff for convenience is almost always security, and when you're talking about securing a network, the tradeoff is convenience.

The hole dug when unable to adapt security measures to a device is definitely one to avoid. My config wasn't exactly convenient, but very effective so far. Using VLAN's and firewall rules is something that will be required going forward if you want to secure a network.

I'm not saying you're wrong, either. Subnets and static routes have been in use for decades. Both methods have their challenges and benefits.

If you'd like to continue discussing in more detail, we can PM. I don't feel like we're keeping this thread on track, lol. But hey, maybe we kinda are. Old methods versus newer methods.

 

[SamirD]

Yep, different methodologies that both work and you're right that we've probably given the OP an overload of info via our discussion, but I think we took over the thread instead, lol.

 

[ch33zw1z]

So what is this network possible? I have read so much about this technology. However, I still have not gotten a picture in my head of everything going on and how I can use that to my advantage.

Draw your network out on paper, it will help you visualize the flow of traffic

 

[Red Squirrel]

Looks good and what I would do too is restrict the IoT vlan to only the bare essential outbound IP/ports. That way if by chance a device does end up hacked, it will be limited in what it can connect to in the outside world. Personally I'm not a fan of IoT stuff though I stick to arduino/RPI and design my own stuff to run 100% locally.

 

[ch33zw1z]

Looks good and what I would do too is restrict the IoT vlan to only the bare essential outbound IP/ports. That way if by chance a device does end up hacked, it will be limited in what it can connect to in the outside world. Personally I'm not a fan of IoT stuff though I stick to arduino/RPI and design my own stuff to run 100% locally.

what would you do to determine what ports are required by different IoT dev’s?

For example, I have two thermostats, but here’s pretty much all the info Google gives you

Download documents included with your thermostat - Google Nest Help

Nest Learning Thermostat (4th gen) Welcome Guide&nbsp

support.google.com

they Reside in an isolated vlan with port 53 allowed to my pi-holes. But other than that, there’s little other info. I guess I could babysit the router / firewall offs and collect what their IP’s are doing, but seems more of a nuisance when I can just isolate them altogether

 

[Red Squirrel]

what would you do to determine what ports are required by different IoT dev’s?

For example, I have two thermostats, but here’s pretty much all the info Google gives you

Download documents included with your thermostat - Google Nest Help

Nest Learning Thermostat (4th gen) Welcome Guide&nbsp

support.google.com

they Reside in an isolated vlan with port 53 allowed to my pi-holes. But other than that, there’s little other info. I guess I could babysit the router / firewall offs and collect what their IP’s are doing, but seems more of a nuisance when I can just isolate them altogether

One way is to turn logging on at the firewall for the catch all block rule then if the device is not working you can check logs. This can be tricky if the device is trying to connect to all sorts of random IPs though and it can be hard to know what's the right one. The easiest is to just unblock the ports but if you want to be more granular then you can try to figure out the IP ranges it needs. But yeah it's not always that easy.

 

[ch33zw1z]

It’s 99.9% likely to be a VLAN network at this point. Just head on over to Google and search on “what is a vlan” or maybe “how can a VLAN benefit my business”

 

[Fallen Kell]

Think of VLANs as separate, segregated networks (not entirely true, but for the purposes of traffic flow, it is true). It would require breaching of the core-network switch(es) to change in the case of VLAN tagging being applied/performed at the port level and not at the device level (in other words, if they backdoor into a IoT device that hasn't been patched in 5 years, they still can't get to the other VLANs unless you were stupid enough to leave a path open in your router rules or allowed management connection to your switch/routers from the IoT VLAN).

And yes, I was able to do what I had listed with the hardware. The R9000 was a little tricky, as it doesn't fully support VLAN tagging on it's RJ45 ethernet ports, but I didn't need it to as I was connecting via SFP+ 10Gb to it, which if you write some custom startup scripts in DD-WRT, you can get it to properly set and use VLANs and VAPs (Virtual Access Points for the wireless version of a VLAN, and apply tagging to those which then routes out to my core switch over the VLAN tagged SFP+ connection).

It was a little more involved that I thought it would be (mainly due to the R9000). I ended up with something like 12 wifi networks (2 IoT networks, a guest network, and the main production network across 3 different radios/bands). I also decided on letting the R9000 be my DHCP server, so it needed to have all VLANs defined on it, with virtual interfaces created on each VLAN, different DHCP/DNS segments for each VLAN, and firewall rules on the R9000 to prevent connecting to it's management system from all but my management VLAN and firewall rules to prevent routing between the VLANs on the R9000 (and instead send the traffic out to my core switch which would do the routing at wirespeed since it is a L3/L4 switch).

I also had to setup the firewall rules on the core-switch to prevent connections to it except through the management VLAN (or through serial console connection), and rules to allow routing between certain VLANs, and deny everything else... So all in all, quite a bit of doing, but I feel I have a much more manageable network as a result, and one I can more easily secure against a threat with minimal disruption to other devices on my network.