Offtopic: Safety and Rate Limits

[pprotschka]

hey guys, tasmota was just what is was looking for. thanks to the devs! i understand that there are a lot of feature requests but is there some sort of rate limit/safety feature implemented? i can not find any information on it. I think a rate limit and min power cycle time is essential to protect equipment and ensure safe operation. From assholes sending fast get request on an unsecured network to a loop in a shell script that runs way too fast i think the argument can be made that this is can happen and is not something paranoid.

How do you guys protect against this? Has this happened to anybody?

[davidelang]

the software does not have any rate limiting

[khcnz]

Just to add to this 1) You should ideally separate your IOT devices from rest of your network with a separate SSID & VLAN 2) If you are worried about "unsecured" requests - set an admin password, which is supported in the firmware.

[arendst]

And disable the webserver.

What kind of rate limit did you have in mind? If it's current you'll need a fuse for safe results.

Fast switching is implemented on request (blink) where the relay would toggle op to every 0.2 second..

[pprotschka]

well a simple number field with max switch frequency would be more than enough perhaps defaulting to 1HZ (1/sec). The question is what todo with the commands arriving in the meantime. Drop them? Buffer and queue them?

i dont feel this is an immediate threat but most industrial controllers would implement this as a simple failsafe. Plausibility fail safes are great! Is it reasonable to switch this Device 30 x per second... NO! Given that i am experiment with node red and some shell scripts i feel this is where i need to be more careful now just so i dont send super fast requests.

well fuses and turning of the web server are certainly good starting points although the webserver is of course nice to have. Creating a separate ssid and vlan are also great ideas. thanks for that.

as we all know bad things can happen when switching AC at high frequencies. I doubt most people have a need for faster switching than 1/sec. The mechanical relay is probably able to handle a little more but with high load devices arcing/welding/surge currents can become and issue.

I certainly wouldn't want to switch my garage door motor faster than 1/sec.... especially directional changes would hurt the motor and mechanics.

[davidelang]

On Fri, 28 Jul 2017, Phil Pro wrote:

I certainly wouldn't want to switch my garage door motor faster than 1/sec.... especially directional changes would hurt the motor and mechanics.

what if you were using these things to control Christmas lights and hooking them to sync with music? there could be times that you would want to switch them far more than once/sec.

[davidelang]

if you are worried about people on your local network, you need to make sure the network is encrypted, otherwise they can just sniff the connection and get any password that you have set.

[stefanbode]

@davidelang: I can add a general section into the Wiki about best practices IoT devices and WLAN. I have quite good knowledge here and can share. The separate WLAN is only one component.

[davidelang]

go for it, we can debate any specific recommendations that you make after we have something in place. k

[PeggyFree]

I'm interested in reading about this. Just bought a ubiquiti access point to get separate SSIDs, but I'm still wondering why it would be better to set up a wlan.

Le jeu. 3 août 2017 23:03, David Lang notifications@github.com a écrit :

go for it, we can debate any specific recommendations that you make after we have something in place. k

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/650#issuecomment-320089512, or mute the thread https://github.com/notifications/unsubscribe-auth/AcMo5Si9k6jNShqmnumQCpoIw9fdr99Dks5sUjWSgaJpZM4Oll4e .

[stefanbode]

@PeggyFree: I started the wiki about "Secure Setup" The page is not 100% ready but at least 80%. Take a look at some scenarios. You can also reach me on skype. Security in IoT is essential but knowledge is quite limited.

[davidelang]

Please reorganize things a little bit, you mix a bunch of things together and I don't think it's clear to most people what is what.

You have a reasonably good start in listing the reasons to protect your devices, but I think you need to clarify things afterwords. You don't tie any of the actions to secure things back to the threats.

Threat classification:

1. network threats

   use WPA. (I don't think the length of the key really matters, it mandates a minimum character key)

   are you exposed to the Internet? If so, you are at significantly more risk than if you aren't (Yes you can work to secure it, bit it's always more risk than not being exposed). I don't buy that you are better off exposing your devices to the Internet than having them talk to your local network.

   switching to a different port number is of minimal value, anyone who can watch your traffic (or see your config) can figure out what port you are using.

   risk of guests on your network attacking your devices. How much/how little do you trust people that you give your network key to? Most home networks have a high amount of trust

   setting a password on the sonoffs is a good defense here.

   attacks via MQTT server. you touch on securing this, but what you are 

   suggesting will break buttontopic/switchtopic. At the very least you need to call this out and explain how to fix this

2. physical attacks

   This is the only reason to say that you need a separate SSID, because as you say, someone can read the configs from a device. But I question how big a threat this is for most people. Most people are not putting these devices outside their houses (they aren't weatherproof), and someone who breaks into your house can do so much more damage to you and your network (including plugging a device in to the back of your router on a wired port and getting full access, bypassing all your controlls)

David Lang (Computer Security Architect)

[stefanbode]

Hi David,

switching the Port number is only useful with the missing firewall rule "only allowed outbound traffic on this port". It is not to obscure anything. It just does make DOS attacks impossible. IoT device owners should take care that they are not getting part of a botnet.

Regarding your objection "your home WLAN is safe". I totally disagree to this topics. It is the same like companies say: "My LAN is safe". Today there are so many possible ways to get hacked, that I do not agree here. E.g. your Smartphone is hacked -> The hacker gets access to your WLAN -> boom. The time to trust you WLAN/LAN is over. This is also the reason why a webserver password on http does not make any sense. You just listen to the traffic and again BOOM you have the password. Great if this is the same for all devices. Will not work on https that simple. Then you need ARP spoofing and a man-in-the-middle attack.

I do not see a break of buttontopic and switchtopic. The device still listens to the cmnd/ and send updates to the two other. All fine. The trick with the configuration is, that even if you have the MQTT user/password this has no benefit to get deeper into the network.

Regarding physical attacks: There was just a few weeks ago a documentation on television showing that well-educated hacker use the garage door opener, or moisture sensor to break into the home and take over complete control. In my camping mobile in the Netherlands, the SONOFFS are in the garden. Protected by plastic spray and shrink packages. Works for 12 months so far. In my garden there are some WEMOS in waterproof housings. Therefore I want to point out, that physical access is not that unlikely anymore.

I love to discuss this further and make for the community a best in class guideline. Happy weekend David.

[davidelang]

On Sat, 5 Aug 2017, stefanbode wrote:

Hi David,

switching the Port number is only useful with the missing firewall rule "only allowed outbound traffic on this port". It is not to obscure anything. It just does make DOS attacks impossible. IoT device owners should take care that they are not getting part of a botnet.

how does changing the port make a botnet easier or harder to have? if you have firewall rules that allow the devices to only talk to specific things, that works even using the stock ports.

Regarding your objection "your home WLAN is safe". I totally disagree to this topics. It is the same like companies say: "My LAN is safe". Today there are so many possible ways to get hacked, that I do not agree here. E.g. your Smartphone is hacked -> The hacker gets access to your WLAN -> boom. The time to trust you WLAN/LAN is over.

Trust is not binary, we are talking about managing risk. There is a very substantial cost to using TLS on these devices.

Most people are not locking everything down on their local network, and trying to do so is FAR more effort than most people are willing to go through (it breaks too many things that they cannot fix)

This is also the reason why a webserver password on http does not make any sense. You just listen to the traffic and again BOOM you have the password. Great if this is the same for all devices. Will not work on https that simple. Then you need ARP spoofing and a man-in-the-middle attack.

if the network is encrypted, then you need to be on the network to get at the password. As long as you do not go over the Internet, you need people to be on the local network and then they need to do the MITM attacks. Very few people are worth targeting this way (remember, you don't have to outrun the bear, just other people :-)

I do not see a break of buttontopic and switchtopic. The device still listens to the cmnd/ and send updates to the two other.

with buttontopic and switchtopic, the device sends cmnd/ messages, not just receives them.

All fine. The trick with the configuration is, that even if you have the MQTT user/password this has no benefit to get deeper into the network.

access to mqtt has nothing to do with getting further into the network.

Regarding physical attacks: There was just a few weeks ago a documentation on television showing that well-educated hacker use the garage door opener, or moisture sensor to break into the home and take over complete control. In my camping mobile in the Netherlands, the SONOFFS are in the garden. Protected by plastic spray and shrink packages. Works for 12 months so far. In my garden there are some WEMOS in waterproof housings. Therefore I want to point out, that physical access is not that unlikely anymore.

so list this as a seperate threat and list the steps to defend against this in that section. Most people are not using these things outdoors and physical access to the network

I love to discuss this further and make for the community a best in class guideline. Happy weekend David.

There is no "one right way of doing things", there are multiple threats, and multiple levels of sensitivity. It makes no sense to put a bank vault door on a tent, the security of these devices should be in line with the rest of the network.

Just locking the devices down to only be able to access things on the local network eliminates their ability to be part of a botnet (short of someone flashing them with different firmware, and these thigns are cheap enough that someone trying to do that can just provide their own devices)

define the threats, and then tie the different types of defenses to the threats that they protect against.

Remember, most people are running unpatched windows/OSX along with their TV, game console, etc. Just the fact that these are running non-standard firmware makes them much safer than most things on the network.

David Lang

[stefanbode]

Give me a call on skype, if you like: stefan.bode

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.