Following the docs;
Create a file in /share/mosquitto named insecure.conf
As far as I can see you placed the file in /config/share/mosquitto
@gpbenton But I need TLS and hence 8883 for Owntracks. Don’t I?
@sjee I am using hassio and cannot go anywhere else config is my top (visible) folder.
@Tinkerer Thanks, I had considered this a while ago but got cold feet when I saw I would be transmitting my HA HTTP password. As I said many times network security is not my thing (although I am now learning!) but can I assume as you are suggesting Owntracks HTTP that this is not an issue? EDIT I guess as my HA is https; that takes care of it?
Thanks again to all three of you.
The configuration.yaml file defines the connection between your broker and HA. This does not need to be encrypted, and thus you can use port 1883 without certificates. There may be other connections to your broker that are encrypted, but this does not concern HA and does not have to be reflected in configuration.yaml.
But as @Tinkerer says, you are better off using the HTTPS method with owntracks. Under HTTPS the encryption occurs at the TCP level, so your password in the URL is encrypted.
Ouch and that’s what we are talking about in this thread…port forwarding random ports for stuff that isn’t needed.
@gpbenton Thank you.
I will set up Owntracks HTTP later and report back when everything is working and secure 
I really do appreciate the help I’ve had here and if you still want me to I will offer some thoughts on how I got in this mess and how we might be able to help stop it happening in the future.
Yup, as you’re already using HTTPS you’re covered.
I found it a lot easier than getting MQTT behaving.
Sorry I was just voicing my experience with the documentation. I would help if I knew more about the subject.
Let me ask a simple question.
What are the security suggestions for the basic local installation? Just the http password?
There is a whole page of documentation on remote access
A bit more than that. Summarising that page:
- Protect your web interface with a password
- Secure your host
- Restrict network access to your devices
- Don’t run Home Assistant as root
- Keep your secrets safe
Maybe this info should be on the Getting Started guide for the hassio. I will try to write something and propose a change. Encouraging people to set up a password for the web UI right at the beginning.
This is such an interesting topic and browsing the responses from the OP, I notice that the focus seems to be on that of securing HA from external attacks. Attacks that would gain access to the system by way of ports being forwarded and an attacker guessing passwords or other token/keys (such as those used by the camera component)
However, security isn’t just from the perspective of hardening or enforcing firewall rules and strong passwords. The most secure applications are those that understand security in all parts of the code. Unfortunately this is where I feel little to no attention is being place.
For example, as it stands right now contributors who make additional components for HA, lets say to connect to some IoT device are encouraged to place the communication code and such in a 3rd party python library. Then use that library to gather state/entity information for HA and respond to commands by HA for actions such as turning on lights. However, these third party python libraries, are as far as I can tell, arel not even looked at during the code review process. One other poster here on the forum even mentioned that the third party libraries have the same privileges as the user that HA is running under, so it would be possible for a malicious entity to create a component that users wanted, and hide malicious code to read files from the filesystem within the 3rd party library and sends them across the web without the user knowing.
This is extremely concerning and only one example. Since HA is executing the library code, any number of things could be written by a malicious third party to reverse ssh into your HA host, sniff traffic on your local network, etc. Fortunately in my own observation of the components I’ve used, it doesn’t seem that anyone has attempted this malicious attack, but it does certainly raise the need for more in-depth code review, even if that slows down releases and better automated tools for vulnerability scanning of code, which I have suggested and received little feedback on.
At the end of the day I am not confident in the slightest that security is a focus for HA, and while I continue to use HA and accept the risks, all IoT devices/hubs/solutions ought to really be taking such things more seriously.
2 Likes
If you’re able to help the developers with code reviews, automated vulnerability scanning etc, I’m sure they’d love to hear from you.
I notice that is linked, but a new user is exposed to a myriad of new information and it may forget to go back. It’s not intended to replace the security documentation but just kind of start using the secrets yaml from the start.
Do you think is not worthed to give it a try?
I have been following along and what I keep seeing is it is the developers of home assistant job to make sure it is secure. I have to say that is not the case. Yes code could be verified better and added security but at the end of the day it is up to us, THE USERS, to understand what we are installing and running. Home assistant has an option for password. Home assistant has the option to prevent brute force attacks; ip ban if more then x number of failed log on’s. Home assistant doesn’t open ports externally. These are all things the user needs to do and there is documentation on all of it.
Now say g all that I could definitely agree we need those of us that understand the risk to create a page that says “if your going to do “x” then it is recommend and best practices to do “y””, but again that is goi g to be up to the user to read and do.
FYI, I am a user and no way apart of the development team.
2 Likes
As a link to the securing guide, sure. Not duplicating though.
As I work in the IT field. I know my biggest problem isn’t how secure I make my systems but how well I have trained my users to think before allowing something to run or plugging something in.
I do agree with you to some degree @MediaCowboy. That users need to be informed and kept in the loop on the risks, but unfortunately that isn’t the case across the board for the documentation. Components that require third party passwords instead of api tokens are inherently more insecure, because you’re storing your password within the configuration. That is a risk. Components that use insecure protocols to communicate with the IoT device such as telnet, etc. are also a risk.
These are things that need to be addressed and documented so that users can make these informed decisions. Otherwise you’re basically asking the user-base to inspect the code to ensure that things are not poorly written in a way to allow for arbitrary code execution or attack on those insecure protocols.
This again reiterates my post/point above. That all code needs to be reviewed and automated tools created to provide better security and documentation for what components are doing things that are not within the realm of good security practices today.
Yes and no. These components are not developed by the home assistant team. Why should they check to make sure a third-party plugin is secure. They need to focus on their eco system (read native plugins) . If it was a company with staff that could check every third party plugin then by all means check everything. Seeing how this is open source they can’t force that. So I will state it again. Those of us that know better should be the ones to check and make recommendations. That is the openness of open source.