Create IoT Group, similar to "Guest"

Submitted by -
Status: New Idea

I'd like to see the category of IoT client that behaves similar to how the Guest controls work.

 

I'd like to be able to assign clients as "IoT" category and have rules/policies/controls automatically applied to that client as a member of the IoT group. We could then assign blanket rules to that entire category, such as "Exclude|De-Emphasis in WUX" and "Apply IoT Firewall Rules" and "Assign to IoT Network/VLAN" types of things.

 

This would be useful for easily managing IoT network segmentation and improving the adoption of security best practices.  

Comments
by
on ‎02-07-2019 07:40 AM
by
on ‎02-07-2019 08:07 AM
@Novalog yes correct, the firewall is configurable to allow or reject inter-network traffic.
by
on ‎02-08-2019 10:28 AM

I think @gacattack is saying he wants it basically streamline and batch configured - same way you can manually replicated the guest network or use the built in configuration.

 

Seems like a reasonable feature request to me 😀

by
on ‎02-16-2019 09:37 AM

This is more difficult than it seems, because IOT devices are messy. From a blog post I've been working on off and on:

 

IOT Gotchas

There are several things that IOT devices do that will force you to loosen your networks restrictions. Here are some.

 

DHCP

One of the ways to restrict what a device can do is to block broadcast data: You don't let it talk to everyone else at once. You can't do that with many IOT devices. Take the Leviton Dimmer, for example. The original firmware (1.4.3) used unicast DHCP (DHCP is how devices get their network address). In this mode, the dimmer asked DHCP to send the IP address back to it directly, and this worked fine. However, when they updated the firmware to 1.4.12, they changed to broadcast DHCP: This is where the dimmer tells DHCP "just broadcast the IP address to the world, and I'll pick it up". If the rules block broadcast data, the dimmer will never get an IP address, which means nobody will ever be able to talk to it. 
 
Remediation:
With the Unifi AP, you can specify that the router (which hands out the IP addresses) is allowed to broadcast, which is probably reasonable and solves this issue.

 

ARP?

I think we need to allow general broadcasting to let devices ARP, but I have to test again. NOTE: 99% sure that some devices use ARP to find your phone for software updates.

 

Talk Amongst Yourselves

Another way to restrict what devices can do is to prohibit them from talking to each other: If they can't talk to each other, they can't infect each other. A good way to do this is to drop any outgoing packet to the 3 private network blocks. Unfortunately, this restriction often fails miserably. For example, the firmware update mentioned above took place between the phone and the dimmer directly...over unencrypted HTTP: The phone got the update packets from the server and fed them to the dimmer.
 
Remediation:
You can limit the local devices that your IOT device can talk to by only allowing it to talk to devices on the same subnet. This of course assumes that you only need the connection for things like firmware updates and not for everything (which seems reasonable so far) and will connect your phone to the IOT subnet to do those maintenance tasks.
by
‎02-16-2019 10:25 AM - edited ‎02-19-2019 12:30 PM

I certainly didn't mean to suggest it would be easy. It won't be.

That's an excellent list you've compiled-- thanks for sharing it!

by
on ‎02-16-2019 03:28 PM

No, I didn't mean to say that you did.

 

I have heard other folks--who haven't really looked into it--think that they can just create an isolated subnet where nothing can talk to anything, and that it will work. Since I actually headed down that path, I wanted to share some of the bumps that I found along the way.