TP-LINK KASA remote control - how risky?

[peter-h]

This kind of thing
https://www.amazon.co.uk/TP-Link-Radiator-Thermostat-installation-KE100/dp/B0BLZ63QQ9

On the face of it, it is crap because it opens up ports in your router (9999, etc). So they can place packets of their choosing onto your home LAN, because that LAN is on the same subnet as the home WIFI, and in any case the home WIFI is used for lots of personal stuff.

But there are claims that it can be set up to use a (possibly free) intermediate server, so it acts as a client and does not need open ports on the NAT router. The classic IoT security problem

I know TP-LINK is the bottom end of the consumer quality scale, but...

[darkspr1te]

Most people putting IOT or smart home devices in tend to go for ones that can be reflashed to work with Home Assistant, that way the packet never need to leave your network. Example brands are Sonof, Tuya,
both provide the tap style thermostat's and both can be flash with either ESP-HA (a client for esp32 based devices , can be flash direct from home assistant ) or OpenBK which can be flash either via the CloudCutter tool or direct using other methods (well documented on elektroda forum)


brands link tplink and other router makers jumping into the IOT market now tend to have their own in house way of doing things that you may not like or could open you up to DDOS or worse.


so the jist is a closed network with Homeassistant would be better than introducing tplink like devices instead that have to work with cloud site.




darkspr1te

[peter-h]

What is the solution for a non computer geek? Flashing products with custom software is way beyond what most people want to do.

By "cloud" do you mean there is a client mode which doesn't need open ports?

I had a similar thing with a Vodafone "femtocell" product which required a bunch of open ports. I sent it back...

[artag]

A client mode device isn't any safer unless it's on it's own physically separate LAN.

If you open a port on the router, an external host can  send to that port. Assuming it's not a port that's used on your other equipment, only the new device will receive those messages. It may then do something in response, to the LAN it's connected to. You have no control over what it can do to other devices on that LAN but they can't be accessed directly from the external host : they're not listening on the open port. Of course, if it opens a port used by existing services all bets are off but you indicate that's not the case.

If you have a client device that accesses some remote host without opening an external port, it can still receive instructions via the connection and then has exactly the same access to the rest of  the LAN it's connected to.

If you need to put a device you don't trust inside your LAN, it doesn't matter how that device connects with it's vendor, as client or server. You need to put it on it's own physical subnet. You might do this with a router capable of operating several subnets - either wired or with different wifi credentials, or it can be done with a secondary router. The name for this is a DMZ or demilitarized zone and has been used for years to separate devices such as webservers which, even if you set them up initially, may be compromised due to the essential access they have from outside users. The idea is that devices within the DMZ have access to the internet and may be accessed from the internet, but they don't have access to your private systems.

[peter-h]

Assuming it's not a port that's used on your other equipment, only the new device will receive those messages

However, most consumer routers have no physical LAN separation, so all packets go to all devices. It is only after a switch that some IP-MAC mapping gets done.

If you have a client device that accesses some remote host without opening an external port, it can still receive instructions via the connection and then has exactly the same access to the rest of  the LAN it's connected to.

Yes, but only during that time, and for 180 seconds (usually) after the cessation of the data. This is the principal attack on NAT but involves a number of assumptions e.g. knowledge of the IP which the IoT device is calling.

If you need to put a device you don't trust inside your LAN, it doesn't matter how that device connects with it's vendor, as client or server. You need to put it on it's own physical subnet. You might do this with a router capable of operating several subnets - either wired or with different wifi credentials, or it can be done with a secondary router. The name for this is a DMZ or demilitarized zone and has been used for years to separate devices such as webservers which, even if you set them up initially, may be compromised due to the essential access they have from outside users. The idea is that devices within the DMZ have access to the internet and may be accessed from the internet, but they don't have access to your private systems.

Indeed but this is beyond the capability of most people buying these remote home control systems.

[voltsandjolts]

Make your own vpn with zerotier, get ten devices for free, although you can setup one local device to forward to your local net if you want access to more devices IIRC. Use HomeAssistant for controls, or roll your own html server for simple stuff.

[peter-h]

Sure it can be done, and a VPN is a better way to do it (subject to cheap chinese routers having expected back doors in their VPN terminators) but that wasn't the question

[voltsandjolts]

TP-LINK KASA remote control - how risky?

I implied the answer - too risky for me, hence my alternative suggestion (where you control the vpn terminators btw).