http://www.pivpn.io/ works great.
I run it on it’s own RPi.
1 Like
its never just 1 minute of downtime.
even restarting HA already takes a few minutes, but also there are always settings that need to be reset/reconfigured.
a light that is already set to on by a motion detector and that should go off after 5 min doesnt go off when HA is restarted in the meantime.
and thats just only a simple automation and i can set the light to off as soon as i detect it was left on when it shouldnt.
of course i can make sure that all things go back to a default after restarting, but that leads to unwanted result. and i could create all kind off automations and logging to make sure that automations get restarted when i restart HA, but thats not something easy and i dont want to start that (yet)
i also could create an automation that restarts HA at a period in time when no automations are running and no motion is suspected, but because there are ALWAYS problems after an update i dont want to restart unsuperviced.
and yeah it is a little better now that they have a test version running in the short period before the release.
but i havent had any update that did go as suspected and i use HA for
in the case from HA its absolutely not recommendable to update to the latest version. the newer the version the more unknown bugs there are.
but we can discuss all we want about updating, but i dont think that would have prevented this breach.
and untill now it was mostly hassio and the samba addon that did cause people trouble, but thats not the case here.
internet > router port 433 > nginx 433 to 8123 > ha with password
and that got breached.
so the question remains how someone could get passed the password?
I wouldn’t just shut down your proxy server and consider yourself “locked down”. There is the possibility that you were “infected” in some other way and that there could still be someone inside your network. I would scan your router logs if you have them, looking for outbound connections to unknown places. Track everything down. I would scan as far back as you might have access to. Shutting down the proxy could have alerted someone to lay low for a while. Do some malware scans from a bootable medium rather than from the OS on your computer(s).
Good luck.
1 Like
thanks and i considered that.
and i will look at other logs i can find, but i kept my eye on it for quite some time now.
and this breach was obviously something manual (there is no other way to turn the switches that were switched) and from the HA gui.
i have no sign at all that someone did reach anything else then the gui from HA.
i did search for changed files but i couldnt find any.
off course if they were inside on other ways they could have been for a long time, but i dont think so.
by the way i didnt only close down the proxy, i also did close the routerports. (but yeah if they have placed malware then that doesnt help either)
So port 443 was the only open port on your router, and pointing to your nginx server? And you’ve never used trusted_networks with HomeAssistant?
Could you share your nginx config? Specifically any server { } blocks that contain a proxy_pass line and anything else related to proxy_.
Do you have anything besides HomeAssistant proxied through nginx? (AppDaemon/HADashboard/Grafana/etc)
When you consider that big companies have small armies of specialized engineers protecting the castle with mountains of sophisticated hardware and software and they get hacked, it is a small wonder that we aren’t all suffering with you.
1 Like
I was checking any vulnerability that aiohttp could have but didn’t find anything.
i’m using external access via 443 and didnt find any vulnerability when scanning from outside …
BTW … i’m using default TLS from letsencryt that uses rsa256 … probably with some fancy CPU power from Azure or AWS they could breach me but at the end, i’m less confident on the ISP router itself …
right only 433 was open and forwarded to nginx.
i never used truted_networks.
nginx settings:
server {
listen 443 ssl;
server_name my.duckdns.org;
ssl on;
ssl_certificate /etc/letsencrypt/live/my.duckdns.org/fullchain.pem; # /etc/nginx/cert.crt;
ssl_certificate_key /etc/letsencrypt/live/my.duckdns.org/privkey.pem; # /etc/nginx/cert.key;
ssl_session_cache shared:SSL:10m;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
proxy_buffering off;
location / {
proxy_pass http://myip:8123;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
i have AD and dashboard but not opened except my AD API port that is setup like:
location /api/appdaemon/ {
proxy_pass http://myip:myport;
no other programs are installed that need access.
there is no sign that the AD api port is used for anything (and i log that closely)
Most NGINX setups aren’t nearly hardened enough (turning off server tokens, blocking bad user agents, returning 444 everywhere possible, using NAXSI + Fail2Ban, etc.). That would be a good first step.
My setup has kept me clean for quite some time: https://github.com/bachya/smart-home/tree/master/settings/nginx/conf
1 Like
you are probably right that my setup wasnt good enough, because i got it from the forum here and i havent really taken the time to study what i could do to make it as secure as possible.
so thats on my to do list now, before i even consider reopening.
nice of you to share your settings, but without an explenation i cannot do much with that 
why do you have your private key on GitHub?
2 Likes
I’m not familiar with the AppDaemon HTTP API. Do you have it protected by anything in nginx, or does it have any kind of built in authentication that you’ve set up?
sorry not able to help as I dont use the NGINX .
but what i can suggest is to check the let’s encrypt instructions and change your passwords of PI , Hass and root user on your OS
test as well your domain here : https://www.ssllabs.com/ssltest/
there was an article and a lil virility about “domestic abuse using IOT devices”. Whereas partners would harass thier other by fiddling with lights, tv etc. Im sure this gave the current generation of script kiddies to have a new playground. If you checked everything about and nothing malicious was done, I’d do the suggestions listed to harden your kit and not give to much worry over it.
1 Like
Those aren’t my actual keys; they’re there for demonstration. Appreciate you checking. 
1 Like
I pulled these from various articles that are easy to find; just search for “harden NGINX” on Google and you’ll be on your way.
1 Like
… ok …
btw … it woudnt be the first that by forgetting , would have them wide open on internet … glad its not the case :slight_smile
Absolutely! Again, appreciate you checking. I’m now realizing that having example keys there doesn’t do very much, so to make sure I don’t alarm future visitors, I will pull them down. 
I will not mention this anymore, but I want to leave you this for your persistance issues: https://github.com/dale3h/homeassistant-config/blob/master/packages/drop-in/persistence.yaml
1 Like
the api has a password and it can only reach the apps that are setup for it. in my case only my alexa app that listens for incoming calls from amazon.
@miguelromao i dont use a PI and i have changed passwords from my linux environment.
but it isnt reachable from the outside anymore unless there is malware installed (which i really dont think so, and if they did a password change wouldnt be effective anyway)
ssllabs doesnt help in this case
@bachya thanks again, i will look into that.
@teachingbirds to bad that doesnt help. my automations are not yaml automations, but appdaemon automations.
1 Like