[Request] Suggestions to improve security

[0crap]

To improve security of the OTGW, I have some suggestions that might help.

• Fix issue #131 Go for a "simple" solution, like pressing the Wemos D1 reset button on powerup, create a initial flash which only allows AP mode once, .... The Wemos D1 is in a socket for a reason. :-)
• Put a username and/or password on the GUI. (http://otgw.local)
• See if the GUI can do https. (A certificate error is fine, at least the data is still encrypted. Just the endpoint can't be verified.)
• Allow the user to disable telnet when it's not needed. (Stop the daemon or don't allow connecting to port 23.)
• Allow the user to disable OTmonitor when it's not needed. (Stop the daemon or don't allow connecting to port 25238.)

- See if telnet can be improved to only allow a secure connection. (SSH, port 22.) Might not be possible because of limited resources on the ESP8266.

MQTT is a good example how it may look like.

In any case, we appreciate the effort and spare time that goes into projects like this. Even if you can put in a few of the above, that would be great!

Thank you!

[rvdbreemen]

Thanks for your suggestions. They are noted as enhancements. I will put them on my backlog for a to be release. If you could have one feature of the list you gave me, what would you implement?

[0crap]

Thanks for your suggestions. They are noted as enhancements. I will put them on my backlog for a to be release. If you could have one feature of the list you gave me, what would you implement?

The WiFi issue seems to be the biggest risk, but probably also the hardest to fix? Next would be to disable unused daemons, or block incoming connections to those ports. Close with that comes a username/password on the GUI, to prevent unauthorized access. (And keep the daemons on/off checkbox save.) https and ssh probably last.

But really, just pick one that seems doable first. 🥇

[DaveDavenport]

In my opinion the wifi creating a public AP is the biggest issue as it is public.

The other items are limited to 'private' and should not be an issue for most. If an otgw is in a network where it could be an issue, this can be resolved on local/network level. (In my network, otgw can access the mqtt server and the ntp server. I can access otgw and that is it).

• Adding ssh is most likely to much for the esp8266 to handle .

[0crap]

In my opinion the wifi creating a public AP is the biggest issue as it is public.

The other items are limited to 'private' and should not be an issue for most. If an otgw is in a network where it could be an issue, this can be resolved on local/network level. (In my network, otgw can access the mqtt server and the ntp server. I can access otgw and that is it).

• Adding ssh is most likely to much for the esp8266 to handle .

Fair enough on the ssh part, scratch that from the list if not possible. And I agree on the WiFi issue being the biggest one.

On the other hand I think the majority of the users has a "flat" LAN IP network. It's good that you have restricted the communication possibilities of the OTGW on your LAN, but most users will never know how to do that. Next to that, the OTGW being a LAN device should not mean we can totally ignore the security aspects of it. It seems you looked at it very well, by restricting the traffic flow from/to it.

[rotilho]

Thank you @rvdbreemen for all your hard work! Your product is fantastic. I wanted to also share my thoughts - in my opinion, the WiFi connection and unauthenticated access are the most pressing concerns. If I had to prioritize them, I would start with addressing the WiFi issue.

[0crap]

Related to #6 and #21