6 ms·

I like the idea of isolating every client, or certain clients at least, but I don't see why this needs special apps or services. Just treat these clients as exi

I like the idea of isolating every client, or certain clients at least, but I don't see why this needs special apps or services. Just treat these clients as existing on their own VLAN segments and either get rid of the GTK (forcing broadcast/multicast to go through the AP) or generate a different one for each such segment (separating the broadcast domains).

fidotron 2y ago
Clients shouldn't connect to the Internet by default, and when they do it should be domain/IP whitelisted only. For example, an IoT lightswitch in your home should only talk to what looks like an MQTT broker in the AP. It doesn't need to have any concept what that topic it publishes to does. Similarly, the receiving light doesn't need to know what caused it. This way those devices literally never need any external network access at all. I started working on this idea by playing with OpenWrt hosted video relays, and learned that it works, and am now extending it: https://github.com/atomirex/umbrella https://github.com/atomirex/umbrella Right now I am on HN procrastinating when I should be producing a video of ingesting from a TP Link security camera (really) into a webrtc SFU on the AP, sending it to another SFU, and watching the result.
- kbolino 2y ago
  I like this vision, but I'm not optimistic about it coming to fruition. IoT vendors want their devices phoning home over the Internet, it gives them traceability and platform lock-in.
- simoncion 2y ago
  > ...when they do it should be domain/IP whitelisted only. In practice, this will work very poorly. Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... which doesn't really stop anything. I work at a BigCo that tries to do what you're proposing and it works so, so badly. Thankfully, we can turn off the "security" software that does this on our workstations. Unfortunately, cannot do the same for our software that runs on datacenter-hosted hardware that IT manages. > Clients shouldn't connect to the Internet by default... I have a couple of VLANs on my LAN that don't provide Internet access just for this reason.
  - fidotron 2y ago
    > Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... Why?
    - simoncion 2y ago
      Because * A huge-ass slice of the things hosted on The Internet are hosted in or behind one or more of Azure, GCP, AWS, and CloudFlare. * Recording the set of "cloud provider"-provided IP addresses spoken to by a piece of client software is a bit of a fool's errand. The nature of those services is that one can change the IP address assigned to one's deployed software at a whim... and it's often cheaper to set things up so that one doesn't have an IP address for one's services that survives a VM reboot.
  - ndriscoll 2y ago
    I think what's being said here is that if we're going to talk about what "needs" to be done about security (especially if government regulation is to be involved), and if we're going to ban something, then it ought to be devices that need to talk to "the cloud". Saying we "need" APs to segment VLANs is missing the point. The cloud servers are known to be malicious (e.g. that company that intentionally bricked people's inverters the other day). As you say, it's impossible to have reasonable filters when everything wants to talk to the entire world. What we "need" is for IoT devices to communicate through purely local networks and have no Internet access. e.g. mandate a standard to discover a local MQTT broker (which the router may also provide). In that world, there's no reason for a device to ever talk to anything other than e.g. 192.168.1.1, so filtering is easy and can be made default.
    - simoncion 2y ago
      > The cloud servers are known to be malicious... Malicious software is malicious regardless of whether it's running as a VM on Someone Else's Server, or a Linux process on personally-owned bare metal. > Saying we "need" APs to segment VLANs is missing the point. > What we "need" is for IoT devices to communicate through purely local networks and have no Internet access. [They will do this via a mechanism using MQTT where they're required to declare if they're bad.] a) Who said anything about APs? While I do have WiFi Access Points (that I did not mention), I also have hard-wired VLAN segmentation. [0] b) From a network design perspective, it's a lot easier and more efficient to provide a VLAN that doesn't have Internet egress than to attempt to sort out which of a mess of hosts are permitted to talk to the Internet from which aren't, and ALSO prevent MAC- and/or IP-address spoofing to evade any such filtering. c) I have no idea why you're invoking MQTT (specifically), but any scheme that requires a potentially-untrusted host running potentially-untrusted hardware and software to declare whether or not it's to be trusted is doomed to failure right off the bat. [0] Sure, I'm a power user. But, a "VLAN-isolated network for untrusted machines" feature shouldn't be something that only power users get. This SHOULD be a baseline feature in consumer-grade WiFi APs and switches. (The race-to-the-bottom feature of the "market" for consumer gear is very sad.)
generj 2y ago
Because less than 5% of the population knows what a VLAN is yet alone how to set one up for their IOT devices. Ideally Apple will resurrect the Airport and make it easy to have privacy and security in the home. An Airport-HomePod combo could do a lot of neat AI things in-house / on-prem.
- kbolino 2y ago
  I wouldn't expect the average person to set anything up. I'd expect the AP to isolate all devices by default. Most of these devices and their corresponding apps are just reaching out to "the cloud" anyway. It's not like they actually treat the LAN they're on as a LAN. That having been said, I don't know for sure that most generally available consumer devices would actually work under this arrangement.
  - 9x39 2y ago
    Client isolation (whether wireless, by broadcast domain, IP filtering) is in conflict with ubiquitous device casting/streaming/detection features common in apps, which often do expect the ability to find each other on a LAN. I think throwing those features out is a tough sell for the home consumer market, but makes sense in the SMB and above area.
    - fidotron 2y ago
      That's why you replace those features with things like a local mqtt broker. That way devices communicate only via the local services. I tried doing real time video first because it's widely assumed to be the hardest. Multicast is widely exploited for fingerprinting by smart TVs, unfortunately, much as I think mdns is a beautifully elegant idea.
    - kbolino 2y ago
      I've never gotten local streaming to work, but that might just be down to the age of my "smart" TV though (which is now disconnected from the network due to lack of updates). But I have noticed that setting up a network printer is a lot easier than it used to be, and I assume that's because of LAN-based discovery, though I haven't dug that deeply into how it works.

fidotron 2y ago

Clients shouldn't connect to the Internet by default, and when they do it should be domain/IP whitelisted only. For example, an IoT lightswitch in your home should only talk to what looks like an MQTT broker in the AP. It doesn't need to have any concept what that topic it publishes to does. Similarly, the receiving light doesn't need to know what caused it. This way those devices literally never need any external network access at all. I started working on this idea by playing with OpenWrt hosted video relays, and learned that it works, and am now extending it: https://github.com/atomirex/umbrella https://github.com/atomirex/umbrella Right now I am on HN procrastinating when I should be producing a video of ingesting from a TP Link security camera (really) into a webrtc SFU on the AP, sending it to another SFU, and watching the result.

kbolino 2y ago
I like this vision, but I'm not optimistic about it coming to fruition. IoT vendors want their devices phoning home over the Internet, it gives them traceability and platform lock-in.
simoncion 2y ago
> ...when they do it should be domain/IP whitelisted only. In practice, this will work very poorly. Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... which doesn't really stop anything. I work at a BigCo that tries to do what you're proposing and it works so, so badly. Thankfully, we can turn off the "security" software that does this on our workstations. Unfortunately, cannot do the same for our software that runs on datacenter-hosted hardware that IT manages. > Clients shouldn't connect to the Internet by default... I have a couple of VLANs on my LAN that don't provide Internet access just for this reason.
- fidotron 2y ago
  > Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... Why?
  - simoncion 2y ago
    Because * A huge-ass slice of the things hosted on The Internet are hosted in or behind one or more of Azure, GCP, AWS, and CloudFlare. * Recording the set of "cloud provider"-provided IP addresses spoken to by a piece of client software is a bit of a fool's errand. The nature of those services is that one can change the IP address assigned to one's deployed software at a whim... and it's often cheaper to set things up so that one doesn't have an IP address for one's services that survives a VM reboot.
- ndriscoll 2y ago
  I think what's being said here is that if we're going to talk about what "needs" to be done about security (especially if government regulation is to be involved), and if we're going to ban something, then it ought to be devices that need to talk to "the cloud". Saying we "need" APs to segment VLANs is missing the point. The cloud servers are known to be malicious (e.g. that company that intentionally bricked people's inverters the other day). As you say, it's impossible to have reasonable filters when everything wants to talk to the entire world. What we "need" is for IoT devices to communicate through purely local networks and have no Internet access. e.g. mandate a standard to discover a local MQTT broker (which the router may also provide). In that world, there's no reason for a device to ever talk to anything other than e.g. 192.168.1.1, so filtering is easy and can be made default.
  - simoncion 2y ago
    > The cloud servers are known to be malicious... Malicious software is malicious regardless of whether it's running as a VM on Someone Else's Server, or a Linux process on personally-owned bare metal. > Saying we "need" APs to segment VLANs is missing the point. > What we "need" is for IoT devices to communicate through purely local networks and have no Internet access. [They will do this via a mechanism using MQTT where they're required to declare if they're bad.] a) Who said anything about APs? While I do have WiFi Access Points (that I did not mention), I also have hard-wired VLAN segmentation. [0] b) From a network design perspective, it's a lot easier and more efficient to provide a VLAN that doesn't have Internet egress than to attempt to sort out which of a mess of hosts are permitted to talk to the Internet from which aren't, and ALSO prevent MAC- and/or IP-address spoofing to evade any such filtering. c) I have no idea why you're invoking MQTT (specifically), but any scheme that requires a potentially-untrusted host running potentially-untrusted hardware and software to declare whether or not it's to be trusted is doomed to failure right off the bat. [0] Sure, I'm a power user. But, a "VLAN-isolated network for untrusted machines" feature shouldn't be something that only power users get. This SHOULD be a baseline feature in consumer-grade WiFi APs and switches. (The race-to-the-bottom feature of the "market" for consumer gear is very sad.)

generj 2y ago

Because less than 5% of the population knows what a VLAN is yet alone how to set one up for their IOT devices. Ideally Apple will resurrect the Airport and make it easy to have privacy and security in the home. An Airport-HomePod combo could do a lot of neat AI things in-house / on-prem.

kbolino 2y ago
I wouldn't expect the average person to set anything up. I'd expect the AP to isolate all devices by default. Most of these devices and their corresponding apps are just reaching out to "the cloud" anyway. It's not like they actually treat the LAN they're on as a LAN. That having been said, I don't know for sure that most generally available consumer devices would actually work under this arrangement.
- 9x39 2y ago
  Client isolation (whether wireless, by broadcast domain, IP filtering) is in conflict with ubiquitous device casting/streaming/detection features common in apps, which often do expect the ability to find each other on a LAN. I think throwing those features out is a tough sell for the home consumer market, but makes sense in the SMB and above area.
  - fidotron 2y ago
    That's why you replace those features with things like a local mqtt broker. That way devices communicate only via the local services. I tried doing real time video first because it's widely assumed to be the hardest. Multicast is widely exploited for fingerprinting by smart TVs, unfortunately, much as I think mdns is a beautifully elegant idea.
  - kbolino 2y ago
    I've never gotten local streaming to work, but that might just be down to the age of my "smart" TV though (which is now disconnected from the network due to lack of updates). But I have noticed that setting up a network printer is a lot easier than it used to be, and I assume that's because of LAN-based discovery, though I haven't dug that deeply into how it works.