How does an IoT device receive a command from the internet?

[Swampledge]

I have done a bunch of searching, but have not found a clear explanation of how a device like a wireless thermostat or a wireless light switch receives a command to change its state. I ask this because I know from general experience that my router firewall does not allow packets from the internet to pass to devices if that packet wasn’t authorized or requested by a device inside my network. For example, back in the days when I was playing with a Raspberry Pi, I had to open a port so I could access it from a remote location, just like you need to do to access the server within Blue Iris if you haven’t set up a VPN to tunnel in.

I thought that possibly each IoT device would ping the manufacturer’s website periodically to see if there was an instruction waiting, but a review of my router’s logs don’t show enough of that to support my hypothesis. I even brought up my router’s log while I sent a command to a wireless tstat, but didn’t see any record of activity passing through. I don’t think these devices are smart enough to communicate within my network when I’m home, but maybe some of them are.

Are there ports that are, by default, left open to support specific IoT protocols? My searching led to some pretty esoteric explanations of a variety of protocols used by IoT devices, but not a higher level explanation of what happens when my app (I assume) contacts the device‘s manufacturer’s server.

TIA for any explanations or references.

 

[biggen]

The IoT device is creating and maintaining a tunnel with the endpoint which it can get instructions from. You can easily block its external communication by assigning it a static IP address to the IoT device and just block all outgoing traffic from that IP.

 

[Swampledge]

The IoT device is creating and maintaining a tunnel with the endpoint which it can get instructions from. You can easily block its external communication by assigning it a static IP address to the IoT device and just block all outgoing traffic from that IP.

Thanks. I have no desire to block the device, which would keep it from functioning. If it creates a secure tunnel to the endpoint, then it shouldn’t be susceptible to hacking unless the endpoint is hacked, right? And shouldn’t my router log those endpoint accesses when they occur? I can see records of each device (like my phone or wife’s iPad) being allowed to access the internet, and each time one of my IP cams is denied access to the internet.

 

[Holbs]

Wireshark will be your friend in this situation

 

[Swampledge]

Thanks, Holbs. I see the potential there, but I’m not at that level yet. Are you implying/suggesting that yes, there are packets passing through (there must be, since the stuff works) that my router doesn’t log because it’s allowed?

 

[Holbs]

I do not know the level of your log, how good it even logs. I do not know the capacity of your firewall (is it good? or is bare bones?). I only know with a Ubiquiti UDM router and related firewall duties, it does it's job. Sadly, Ubiquiti forgot to easily view these logs. I have to resort to using Wireshark to see what's going on.

 

[Holbs]

Since you are asking about an IoT switch and thermostat, that is related to each device talking to the cloud probably through P2P (I have not researched how it connects to the cloud if you lock down your firewall). Wireshark is the only way I know to tell for sure what IP packets are being sent from a device and to where. Follow the bread crumbs.

 

[Mike A.]

Thanks. I have no desire to block the device, which would keep it from functioning. If it creates a secure tunnel to the endpoint, then it shouldn’t be susceptible to hacking unless the endpoint is hacked, right? And shouldn’t my router log those endpoint accesses when they occur? I can see records of each device (like my phone or wife’s iPad) being allowed to access the internet, and each time one of my IP cams is denied access to the internet.

It's not necessarily secure. Generally the connection will be using HTTPS so it's "secure" in that sense and case but doesn't mean that it's not subject to some other vulnerabilities or intrusion. e.g., P2P-type services of that sort have been shown to expose credentials, could be accessed by others, potentially subject to worms, etc.

 

[biggen]

Thanks. I have no desire to block the device, which would keep it from functioning. If it creates a secure tunnel to the endpoint, then it shouldn’t be susceptible to hacking unless the endpoint is hacked, right? And shouldn’t my router log those endpoint accesses when they occur? I can see records of each device (like my phone or wife’s iPad) being allowed to access the internet, and each time one of my IP cams is denied access to the internet.

I have no idea if it's secure. I'd hope so but you really have no way of knowing with packet capturing. If it's a wireless device you may be able to capture its traffic on Wifi. If it's a wired device, then you would have to run packet capturing software right at the router in a switched network.

 

[Swampledge]

Thank you everyone for your responses. Somehow, though, it’s just not “clicking” for me as to how this is working. If you’ll indulge me just a little bit more, maybe I should simplify my question thusly:

Why do I have to open a port to communicate with my RaspPi or BI server from outside my LAN, but not to allow an Iot’s server to send instructions to that device?

 

[biggen]

Its just like any other request started from inside your LAN to the outside. You are accessing this forum now that is outside your LAN. It's sending information to you (from the outside) because you performed a "GET" request first. Because you started the request, the router tracks what packets were passed and where to send the answers back. Its complicated and it has to do with how routing works at the OSI Layer 3 level. I don't pretend to know it all either. I've forgotten most of it from my Cisco training. But if you want the nitty gritty you need to do research on layer 3 and you will see exactly how packets are forwarded and the data that is contained inside of each one. It's really miraculous how it all works together.

 

[Swampledge]

Its just like any other request started from inside your LAN to the outside. You are accessing this forum now that is outside your LAN. It's sending information to you (from the outside) because you performed a "GET" request first. Because you started the request, the router tracks what packets were passed and where to send the answers back. Its complicated and it has to do with how routing works at the OSI Layer 3 level.

Okay, that makes sense. I guess what you are saying is that, even if I send a request from my phone from outside my LAN, the packet(s) sent from the device’s “endpoint” (or what I called the manufacturer’s server), contain a frame or frames that signal to my router that the packet was requested. If I’ve got that right, why couldn’t my BI app or Putty terminal for RaspPi be structured similarly?

Hoping that these questions might be useful for somebody else and I’m not sounding like a 2 year old that keeps asking, “Why?”

 

[biggen]

Okay, that makes sense. I guess what you are saying is that, even if I send a request from my phone from outside my LAN, the packet(s) sent from the device’s “endpoint” (or what I called the manufacturer’s server), contain a frame or frames that signal to my router that the packet was requested. If I’ve got that right, why couldn’t my BI app or Putty terminal for RaspPi be structured similarly?

Hoping that these questions might be useful for somebody else and I’m not sounding like a 2 year old that keeps asking, “Why?”

I don't have an answer for that. I'd have to dig out my old Cisco CCNA books and see exactly what data the router adds into the packet header to keep track of what is doing what. Essentially what's important is that if a device from inside the LAN initiated the connection and maintains it, then the endpoint outside the LAN can talk to the device inside the LAN. However, if the connection hasn't been initiated and maintained, then the endpoint outside the LAN can no longer communicate with said IoT device.

Hope that is clear as mud.

 

[mikeynags]

Okay, that makes sense. I guess what you are saying is that, even if I send a request from my phone from outside my LAN, the packet(s) sent from the device’s “endpoint” (or what I called the manufacturer’s server), contain a frame or frames that signal to my router that the packet was requested. If I’ve got that right, why couldn’t my BI app or Putty terminal for RaspPi be structured similarly?

Hoping that these questions might be useful for somebody else and I’m not sounding like a 2 year old that keeps asking, “Why?”

You are correct. In the thermostat scenario, it builds a tunnel to the manufacturer's "cloud". Your phone is not talking to the thermostat when you access it via the app, it's talking to the manufacturer's cloud which is already maintaining connectivity to your thermostat via that "secure" tunnel the thermostat initiated from "inside" your network.

It's really all about where the connection is initiated. In your Pi example, in order for you to access it remotely, you had to open up ports because the connection was initiated from "outside" your network. Most IoT devices with a manufacturer cloud in the middle operate in this way. Hope this helped.

 

[mat200]

Thanks. I have no desire to block the device, which would keep it from functioning. If it creates a secure tunnel to the endpoint, then it shouldn’t be susceptible to hacking unless the endpoint is hacked, right? And shouldn’t my router log those endpoint accesses when they occur? I can see records of each device (like my phone or wife’s iPad) being allowed to access the internet, and each time one of my IP cams is denied access to the internet.

Hi @Swampledge

"If it creates a secure tunnel to the endpoint, then it shouldn’t be susceptible to hacking unless the endpoint is hacked, right? "

IoT and secure are incompatible words ...

IoT many exploits and attacks .. do not trust them to remain secure ..

 

[looney2ns]

How to Secure Your Network (Don't Get Hacked!) | IP Cam Talk

Resource Guide on IP Technology for all Noobs

First off - Welcome to the forum. This forum is a great wealth of knowledge and can most likely get you where you need to go as well as cause you to spend way to much money :) Here are some guides for you to use in getting up to speed on IP technology if you are a novice or even someone just...

ipcamtalk.com

VPN Primer for Noobs | IP Cam Talk

 

[The Automation Guy]

Thanks. I have no desire to block the device, which would keep it from functioning. If it creates a secure tunnel to the endpoint, then it shouldn’t be susceptible to hacking unless the endpoint is hacked, right? And shouldn’t my router log those endpoint accesses when they occur? I can see records of each device (like my phone or wife’s iPad) being allowed to access the internet, and each time one of my IP cams is denied access to the internet.

First, as already noted, we can't assume the tunnel between the device and the manufactures "cloud" server is secure. But that is only part of the security issues.

The larger security issue is that fact that you have given a company unfettered access to your network. The whole point that you don't need to open a port on your firewall/router should scare you into realizing that whatever communication is going on between the device and the manufacturer - your firewall/router isn't able to control it. (You can block it, and maybe monitor it, but not control it). You also have no idea how secure the manufacturer's "cloud" server is and it's totally out of your control. There is no way of knowing if they have been compromised by something like the Solarwinds hack (using that to prove this isn't a "hypothetical" situation) which is allowing nefarious users access to the cloud server and therefore use of that direct, unregulated, potentially "secure" tunnel into your network.

IOT devices are also notorious for piss poor network security and users rarely, if ever update firmware on devices like smart plugs. It's quite possible for someone to locally access your wireless IOT devices using known exploits. The risk here isn't that they are interested in turning your lights on and off, but the fact that they can use the device as a jumping off point to access the rest of your network.

Personally I try to limit the number of "smart" devices that can access the internet. The ones that can access the internet are broken into two categories - Alexa type devices (that require the internet to work) and streaming devices (like Roku and smart TVs). It's bad enough that I let these devices access the internet, but I mitigate the risk by isolating those devices on their own VLAN. They certainly cannot access other computers/devices. I will never allow "smart" plug, switches, appliances, etc to access the internet. How do I make them work then if they cannot communicate with the manufactures cloud server? Well I only use plugs/switches that I can flash a third party firmware called Tasmota to replace the stock firmware. Tasmota takes away any and all internet/cloud reliance to work. So all my wifi smart plugs/switches work just fine being isolated on their own VLAN without internet access.

 

[Holbs]

First, as already noted, we can't assume the tunnel between the device and the manufactures "cloud" server is secure. But that is only part of the security issues.

The larger security issue is that fact that you have given a company unfettered access to your network. The whole point that you don't need to open a port on your firewall/router should scare you into realizing that whatever communication is going on between the device and the manufacturer - your firewall/router isn't able to control it. (You can block it, but not control it). Also, you have no idea how secure the manufacturer's "cloud" server is and it's totally out of your control. There is no way of knowing if they have been compromised by something like the Solarwinds hack (using that to prove this isn't a "hypothetical" situation) which is allowing nefarious users access to the cloud server and therefore a direct, unregulated tunnel into your network.

IOT devices are also notorious for piss poor network security and users rarely, if ever update firmware on their IOT devices like smart plugs. It's quite possible for someone to locally access your wireless IOT devices using known exploits.

Personally I try to limit the number of "smart" devices that can access the internet. The one that can access the internet are broken into two categories - Alexa type devices (that require the internet to work) and streaming devices (like Roku and smart TVs). It's bad enough that I let these devices access the internet, but I mitigate the risk by isolating those devices on their own VLAN. They certainly cannot access other computers/devices. I certainly will never allow "smart" plug, switches, appliances, etc to access the internet. How do I make them work then if they cannot communicate with the manufactures cloud server? Well I only use plugs/switches that I can flash a third party firmware called Tasmota to replace the stock firmware. Tasmota takes away any and all internet/cloud reliance to work. So all my wifi smart plugs/switches work just fine being isolated on their own VLAN without internet access.

less IoT devices, the better. Agreed! Is why I try to use z-wave radio non-IP devices for my Home Assistant smart home automation instead of WiFi devices.
With that being said, I do have IoT stuff that I haphazardly threw into a simple IoT subnet such a 2 vacuum cleaners, weather station, etc. Once I understand Wireshark & my VTO push notification business, I"ll be retackling the IoT subnet to make it more secure.
Trying to stay away from cloud devices but sometimes it's unavoidable such as my robot vacuums and weather stations.

 

[The Automation Guy]

Cloud based "automation" is (relatively) cheap and easy which has made it very successful in the US consumer market. It is not a good way to set up your home however and using cloud based automation is actually a recipe for disaster. There are countless "cloud based automation" companies that have gone under, stopped supporting older devices, or changed their business model from a free one to a paid subscription (I'm looking at you IFTTT). They shut down or block access to their cloud servers and effectively turn their customer's hardware devices into doorstops. If your light switch requires communication with a cloud server to work (even if it is just a heartbeat type connection from time to time), it is going to fail when the server gets shut down. It's not a question of IF, but WHEN.

For this reason, I will never buy an automation device that requires the "cloud" to work. Obviously security is a concern too (see my last post), but the fact that companies can shut down, decide to stop supporting your device, or change their fee model at the drop of a hat which will cause your device to stop working, should be a much larger concern.

PS - I use the term "automation" very loosely here. A smart plug isn't really automation. True automation is a system that brings unrelated systems together so they can work together. For example, my alarm system, HVAC system, media/audio systems, lighting devices, etc cannot communicate with each other. However, my automation system can communicate with each of those systems and therefore I leverage it to tie those systems together into a large cohesive setup. The automation system is the glue that brings those other systems together. Those systems will work fine independently of each other (in case the automation system fails for some reason) and independent of the internet, but the automation system does allow some cool stuff. Now my alarm system IS be able to communicate (through my automation system) with my other systems like HVAC and lighting systems so that when I disarm/arm the system, certain events takes place (HVAC setpoints change, certain lights turn on if its dark out, audio/media devices are shut down, etc, etc, etc). That's one example of real automation.

 

[mat200]

If companies which specialize in security can not keep their products secure .. then I have little hope for others ..

Cybercriminal Gang Just Leaked 500,000 Fortinet VPN Users' Passwords
The hackers ( attackers ) allegedly scraped the login credentials from unsecured devices, then dumped them on a dark web forum.

Cybercriminal Gang Just Leaked 500,000 Fortinet VPN Users' Passwords

The hackers allegedly scraped the login credentials from unsecured devices, then dumped them on a dark web forum.

gizmodo.com

Hackers Leak VPN Account Passwords From 87,000 Fortinet FortiGate Devices

Hackers Leak VPN Account Passwords From 87,000 Fortinet FortiGate Devices

Fortinet says a malicious actor had unauthorizedly disclosed VPN login names and passwords associated with 87,000 FortiGate SSL-VPN devices.

thehackernews.com