Dumbass Home 2.0. How modern IoT works, how to automate your rented box today(vas3k.com)
vas3k.com
Dumbass Home 2.0. How modern IoT works, how to automate your rented box today
https://vas3k.com/blog/dumbass_home/?ref=sn
57 comments
> All that industrial control stuff with MODBUS and SCADA and other brain damage: it has even less security than the IoT junk, i.e. none!
Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them?
The problem is Industrial engineers aren't IT or security experts and that's why we have security issues. Plus they're under constant pressure to get production running and meeting deadlines. Next you'll say "but what about stuxnet! that proved that even air gapping isn't secure enough!" Yup. It also proves that using insecure general purpose operating systems (hint, windows) is stupid as well. But it's cheap and familiar so here we are. The problem isn't with the protocols or hardware, it's ignorance with a side of laziness topped with corner cutting.
Also many industrial protocols don't run over tcp but instead use raw ethernet packets and have dedicated protocol processors running to keep latencies down to microsecond levels for flipping IO bits. An example is Beckhoff's EtherCAT. So security does not apply to those networks and would be difficult to implement.
> Bad as home automation is, it is, incredibly, better than your run of the mill industrial automation!
Apples to oranges.
We recently bought a machine which has an internal automation network between a Siemens 840d, a Siemens safety PLC and a DSP controller from Adwin. Real time communications is over Profibus and CANopen. between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine. I'd trust that more than any home automation built on webshit.
Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them?
The problem is Industrial engineers aren't IT or security experts and that's why we have security issues. Plus they're under constant pressure to get production running and meeting deadlines. Next you'll say "but what about stuxnet! that proved that even air gapping isn't secure enough!" Yup. It also proves that using insecure general purpose operating systems (hint, windows) is stupid as well. But it's cheap and familiar so here we are. The problem isn't with the protocols or hardware, it's ignorance with a side of laziness topped with corner cutting.
Also many industrial protocols don't run over tcp but instead use raw ethernet packets and have dedicated protocol processors running to keep latencies down to microsecond levels for flipping IO bits. An example is Beckhoff's EtherCAT. So security does not apply to those networks and would be difficult to implement.
> Bad as home automation is, it is, incredibly, better than your run of the mill industrial automation!
Apples to oranges.
We recently bought a machine which has an internal automation network between a Siemens 840d, a Siemens safety PLC and a DSP controller from Adwin. Real time communications is over Profibus and CANopen. between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine. I'd trust that more than any home automation built on webshit.
>Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them?
Clearly stuxnet is a myth and bedtime story to frighten children with.
Clearly stuxnet is a myth and bedtime story to frighten children with.
> between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine
What hardware + hardened OS would you recommend for jump boxes? OpenBSD, Linux, pfSense?
What hardware + hardened OS would you recommend for jump boxes? OpenBSD, Linux, pfSense?
At work I build, upgrade and maintain existing machines for in house processes so I don't use jump boxes. I have pfSense running on a PC engines APU2 for the company lan, isolated visitor wifi, and isolated 3rd party machine network. We're a small company so I do some IT and contract the rest to an IT pro friend of mine. I do unixy stuff and automation, he does windows stuff. So I would recommend the BSD's as they have been pretty well battle tested in that arena, OpenBSD being my top pick if rolling your own or pfSense if you want easy. PC Engines hardware all around and I order direct.
As for our 3rd party machines with jump boxes: I view jump boxes as a security risk if directly connected to corporate lan as they can bypass firewalls. So I kept it simple and created an isolated jump box network from the pfSense that gives them 24/7 remote internet access with zero ability to see anything on the company lan.
Our Internal machines are on an isolated network, all hardwired and have static IP addresses, zero internet access. The engineers frequently have to write new CNC programs so I make it easy to share files while isolating the networks; I bridged them using a Debian server running a SAMBA server with two network interfaces. One is connected to the company lan, the other to the dedicated machine lan. The file server has a single share for the engineers with RW access and each machine gets RW access only to its directory in that share. Operators go to the P (program) drive and retrieve the programs. There is no network bridging or routing between the two networks. As far as they know, it's just a file server. That network also terminates in our office and we can connect to it for programming and troubleshooting.
One Idea I've been toying with is developing an internal jump box that allows our machines to connect to the corporate lan giving engineers file access while maintaining network isolation. That way I can ditch the second network and go DHCP with reservations all around.
As for our 3rd party machines with jump boxes: I view jump boxes as a security risk if directly connected to corporate lan as they can bypass firewalls. So I kept it simple and created an isolated jump box network from the pfSense that gives them 24/7 remote internet access with zero ability to see anything on the company lan.
Our Internal machines are on an isolated network, all hardwired and have static IP addresses, zero internet access. The engineers frequently have to write new CNC programs so I make it easy to share files while isolating the networks; I bridged them using a Debian server running a SAMBA server with two network interfaces. One is connected to the company lan, the other to the dedicated machine lan. The file server has a single share for the engineers with RW access and each machine gets RW access only to its directory in that share. Operators go to the P (program) drive and retrieve the programs. There is no network bridging or routing between the two networks. As far as they know, it's just a file server. That network also terminates in our office and we can connect to it for programming and troubleshooting.
One Idea I've been toying with is developing an internal jump box that allows our machines to connect to the corporate lan giving engineers file access while maintaining network isolation. That way I can ditch the second network and go DHCP with reservations all around.
> There is no network bridging or routing between the two networks.
If a fileserver vulnerability helps an attacker to take control of the host, they may be able to move traffic between the network cards.
Might be better to have two file servers. The less-exposed server could periodically connect to the more-exposed server to sync files. Would not need open ports on the less-exposed server.
If a fileserver vulnerability helps an attacker to take control of the host, they may be able to move traffic between the network cards.
Might be better to have two file servers. The less-exposed server could periodically connect to the more-exposed server to sync files. Would not need open ports on the less-exposed server.
This is very true but I look at it like this: If they make it that far, they're in our network so we're thoroughly p0wnd. It's a compromise as air gapping was generating too many complaints from engineers and operators until the boss had enough and said fix it. so we compromised and fixed it.
If one-way data replication is sufficient, a DIY data diode would provide strong isolation, https://www.sans.org/reading-room/whitepapers/firewalls/tact...
It really amazes me the kind of stuff that will slide in this industry. I have seen the web front ends for the datacenter cooling systems of certain large tech companies where the password is simply password. Nobody cares much about these things, so it goes unnoticed.
Move fast and leave the front door open for others to break things
I have a background in traffic control and have just started the SANS ICS410 course. It's scary how much the security depends on the network. No defence in depth.
The only way to win is not to play. It is completely daft to me that all these devices require an Internet connection to function. I will never allow something like that into my house (along with home assistants like Alexa).
I have achieved a decent level of automation using simple timer switches (they have ones that adjust on/off times based on your latitude), completely disconnected motion sensing lights, and by simply reading the manual on how to program my thermostats.
I have considered using ZWave to enable me to use some cron jobs or openHAB, but I will not use WiFi.
I have achieved a decent level of automation using simple timer switches (they have ones that adjust on/off times based on your latitude), completely disconnected motion sensing lights, and by simply reading the manual on how to program my thermostats.
I have considered using ZWave to enable me to use some cron jobs or openHAB, but I will not use WiFi.
Not all, no.
HomeKit and ZWave don't require an Internet connection. I use a bunch of ZWave devices connected via Ethernet through a Raspberry Pi with hassio and a ZWave USB adapter - controlled from my phone when it connects to my wifi network.
To protect your wifi network, make sure you have a decent gateway in place. OpenWRT does a great job, but there are many others as well.
HomeKit and ZWave don't require an Internet connection. I use a bunch of ZWave devices connected via Ethernet through a Raspberry Pi with hassio and a ZWave USB adapter - controlled from my phone when it connects to my wifi network.
To protect your wifi network, make sure you have a decent gateway in place. OpenWRT does a great job, but there are many others as well.
Phillips Hue lights also don't require an internet connection, I've tested mine.
Yeah, I write off any home automation device that uses Wi-Fi. Currently I use a lot of Insteon devices, which aren't mentioned in the article, but are fundamentally very similar to Z-Wave. They have no software update mechanism and can't talk in an IP protocol, so the amount of impact someone can have on them is pretty bloody limited.
I feel the exact same way. Never will anything in my home needlessly connect to some cloud service and give away my data. And even less would I be willing to pay for that...
Plenty of them don’t require an internet connection. My Philips Hue and Harmony hubs are both on a VLAN which blocks all outbound traffic (save for MDNS reflection across LAN subnets so they can still be discovered from other subnets).
I tinkered with home automation in the past, and had the same worries. I felt comfortable enough with Z-Wave, but drew the line at anything networked.
I love this. Someone who recognizes the cesspool of modern tech and actually gives reasonable advice on how to sort of fulfill the promised future.
It's too bad people forgot how to make and sell a thing, and instead are selling a (surprise!) business model.
It's too bad people forgot how to make and sell a thing, and instead are selling a (surprise!) business model.
The version in Russian is significantly more entertaining, though it requires native-speaker level at the language to appreciate it fully.
Now I'm sad. If translation even slightly resembles original version then I'm sad that I'm unable to read it in Russian due to not knowing language.
I like this style of writing, another blog I know where author has slightly similar style is dedoimedo.com
Nice recommendation, thanks.
Also a great blog name. "Dedo i Medo" literally means "Grandpa and the Bear" in a bunch of slavic languages.
Duolingo, my friend. Takes 15 mins a day. Not a paid endorsement.
I found it quite entertaining, after figuring out that the author is Russian, when hearing it in my head with a Russian accent. I thought it well written regardless, with plenty of laughs to start my morning.
I didn't know the author was Russian, but then I read "the stop light for a rabbit"... That totally gave it away. :-)
True, and the English one is not a literal translation. I wish though the English version had a greater quality.
As a native English speaker, I found this really well-written and entertaining. I even signed up for his email newsletter just because I liked the writing style so much.
+1
Wired vs wireless... With anything securityrelated, it should really be wired. At least cameras. It's very, very easy to just run a simple $2 sniffer (eg an esp8266) that sends de-auth packets and thus kicking devices off the wifi.
In our neighborhood, we've had quite a few thefts of skiboxes (the ones that go on top of the car) recently, and several say the security cameras seemed to be unconnected at the time, hinting at some use of de-auther/jammer.
In our neighborhood, we've had quite a few thefts of skiboxes (the ones that go on top of the car) recently, and several say the security cameras seemed to be unconnected at the time, hinting at some use of de-auther/jammer.
That's just not practical for most people. Wiring a house is difficult and/or expensive. It's also not necessarily an applicable argument for z-wave/zigbee (there may be similar attacks, though, I'm not sure).
There's also "hybrid" options for usecases like the "unconnected camera": a wireless camera that has local storage, for example.
There's also "hybrid" options for usecases like the "unconnected camera": a wireless camera that has local storage, for example.
> That's just not practical for most people. Wiring a house is difficult and/or expensive.
That's because we do it stupidly. Why are we running wires in walls where we can't ever get at them? Trim and quarter round could double as conduit.
That's because we do it stupidly. Why are we running wires in walls where we can't ever get at them? Trim and quarter round could double as conduit.
I run Domoticz. While development on, say Home Assistant is a lot more active, Domoticz is far from dead! I chose it because it plays nice with the latest Xiaomi Aqara hub and sensors, as opposed to HA.
This article has a cynicism that feels born of a ton of experience. I’ve only gone as far as a couple different colored lights (Hue and LIFX). And I think I might be replacing most of them with dumb bulbs when I move to a new place in a couple months. They’re just not worth the hassle.
Yeah, I went all-in on smart bulbs (Philips) and they are just impractical. I do however recommend dimmable dumb bulbs along with smart switches like Lutron. They are easy to install, "just-work" and give you 90% of what you need.
Why are the Philips smart bulbs impractical? I was thinking of buying a bunch of them for use with google home.
Good question. I've never had any problems with mine. The official Phillips app has some limitations, such as insisting on using their cloud when you're not on your own LAN. But there are many alternative apps and it's easy enough to write your own. I like one called Hue Pro, which does let you connect from outside without using the cloud.
What an entertaining read. I tried it and then gave up on home automation a long time ago. The reason why home automation can't be made 'smart' is because it lacks the ability to create precise situational awareness. Ie, so much of the 'automation' relies on human input. I started on a side project that would use cameras and facial recognition to provide 'eyes' to the home automation system. I planned to use Home Assistant, that way I can keep everything running without an internet connection, but the software was simply not ready. Lots of missing documentation and constant change deterred me. I'm hoping Home Assistant has gotten better over the years.
Oh my god, as someone who works in the consumer IoT space this is hilarious AND informative for people who don't know how MESSED UP this space is. OP expect a donation when I get home tonight.
Entertaining and informative article. Great State-Of-IoT in 2019.
I don't know why this article keeps saying HomeKit doesn't do bluetooth.
https://developer.apple.com/support/homekit-accessory-protoc...
>[HomeKit Accessory Protocol] supports two transports, IP and Bluetooth LE.
https://developer.apple.com/support/homekit-accessory-protoc...
>[HomeKit Accessory Protocol] supports two transports, IP and Bluetooth LE.
And this article doesn't even mention Bluetooth Mesh. Yes, it's still very new and yet to be deployed to the extent of Z-Wave and ZigBee, but with the ability to directly connect to smartphones Bluetooth Mesh could overtake those protocols in a few years.
This is an amazing post. Every couple of years, I look at the massive clusterfuck that is the IoT ecosystem, and decide it's not worth the bother. This post nicely encapsulates why.
"fancy case to hide that you have no live" hahaha
i moved house recently. people keep buying me IoT housewarming gifts.
i'd rather receive a potato with a telnet chip jammed into it because at least i can turn it into gnocchi.
i'd rather receive a potato with a telnet chip jammed into it because at least i can turn it into gnocchi.
This is the most accurate description of IoT I have ever read.
oulipo(1)
I worked on a safety critical system in which we designed security and fail safe right from the beginning. Hardwired state machine controllers for things that could explode. The hardware engineers think that way (thankfully) so we should too. After I left they junked it all and replaced it with Siemens "HMIs" (very expensive Windows XP systems), fancy process control stuff, and then spent even more on fancy consultants every time they wanted to make a change. But at least it was familiar. (I could still access the systems long after I'd left). At least it explains why the real hardware guys (as in actual iron) don't trust the silicon jockeys or software guys: what they have access to us crap.
Bad as home automation is, it is, incredibly, better than your run of the mill industrial automation!