Removing headers sent externally is definitely a step up in security. However, that’s the only thing your caddy proxy currently adds in terms of security.
Things to add to your checklist:
most important!! set up HA to know it’s receiving requests from a proxy. Without letting HA know that it’s getting requests from a proxy and to look for the x-forwarded header, HA will think ALL requests come from just your proxy’s IP on your network. This means both legit and abuse requests will come from that IP, and if you set up HA to block failed attempts it’ll end up blocking your legit logins as well. Or worse, outside logins will look like they’re coming from internal, since HA can no longer tell what the original IP was.
authentication for the proxy. Right now you’re just forwarding traffic to HA and trusting HA’s authentication system, the proxy doesn’t add any additional checks.
brute force protection. If HA responds with bad requests or auth multiple times, your proxy should block off the request because someone is likely trying multiple URLs to see what goes through. Might as well block it at the proxy instead of letting HA do it.
IP blocking. Don’t know about cauddy specifically, but you can usually set up whitelists on proxies easily to only allow access from your country. This vastly reduces the number of Russia/China/India etc attempts that have zero reason to be able to contact your IP at all.
On point one, is that not what ‘X-Forwards-For=true’ in the HA config file does or have I missed something?
I’ll look into points 2 and 4, sounds good. Point 3, I have fail2ban reading HA’s log files and then adding a drop rule to iptables. HA will also message me that someone has been banned.
Ah yes. I don’t know how I missed that line, but yes, that’s exactly what you need to do.
Now after that’s done, the last step is to TEST. Now that nearly everyone has data on their phone it’s much easier to test “external” and “internal” connections, just turn off wifi on the phone and see if HA properly asks for password when coming from the data connection instead of wifi.
Thanks, yep being testing as I’ve been going. Just added geoblocking in caddy.
With this setup, is it safe to use the trusted-networks for internal addressing & X-Forwards-For features together in HA again, or would something still make this insecure?
I’ve got caddy replacing the X-Forwards-For with the clients IP instead of trusting the client.
Edit: Cool exercise to get geoblocking working but it broke Google Assistant and the addresses were all over the place… world.
I was able to get oauth2_proxy setup with Google, but it allows any legitimate google account login through. I’m probably just missing something simple, but how do I restrict to a few specific gmail accounts? Thanks.
EDIT: I still use an API password so more of a work in progress than a gaping hole.
It should be safe. There could always be other unknown things that make it insecure still, but you’ve done enough to hopefully make your install difficult enough that an attacker would just move on and try someone else.
Okay thanks for clarifying. I did deactivate UPnP again and this time then Chromecast still worked. Don’t know what happened last time though.
Can an intruder - even though I don’t know if I have had any - do much harm since it is Hassio? Meaning getting to other parts of the network or sniffing passwords etc?
Thanks. Thats extremely helpful. I get it to load the authenticated_emails file (according to the log), but when I go to the page and login with a gmail account NOT in that list, it still goes through. Do you have any other information you can share, like the command line string you’re using to start the proxy? Thanks again.
I’m not doing anything special, but here is where I start the container with compose. I just re-verified that only the approved emails are allowed access. Not sure how you set it up, but I am using it with the auth_request directive in Nginx documented here.
That will be fine. Enabling (as you have) guest mode enables access to the file system without a username or password. If you’ve then also forwarded ports for it, then that’s a major problem. If you haven’t however, then you should be ok still.
Unfortunately it’s not. A UPnP router will open the ports needed and give access to HA. I know, this happened to me and I had a username and password set and trusted networks in the samba config. It’s the stupid enabled guest that is the open door and I see that there are moves to fix that.
Samba doesn’t have any UPnP support, there’s nothing in it that’ll cause a port to be opened for it. If you had that happen then it was done by something else on the system - finding what that is would be useful.
Finally got it. I was using a different Docker image and I think it was setup differently. I ended up using yours from your example. I also had some weird things going on with Nginx that I got straight. Everything works as it should as of now.
Only saying what I saw, SMB ports were open to the outside world, seen with nmap from a remote Linux box. Turned off samba and UPnP and they closed leaving only the port I had programmed (443) in the router. This was after a wipe and re-install of my Pi to start from scratch so was an out of the box install. There are currently 83 HA boxes exposing SMB on Shodan, I find it hard to believe that in every case the end user has deliberately opened the required ports.
No problem. You may also want to look at my nginx config in there. I implemented Naxsi as a WAF to block any requests that look like funny business. Only piece I haven’t added is fail2ban, but that’s on the list.
For what it’s worth, I’ve been running Samba with UPnP capable routers for well over a decade now. It has never opened a port on the router. There’s not even any signs of support for UPnP in the Samba code. That’s why I’m saying the source of the open ports isn’t Samba, but something else.
Also, only 83 people? That’s well in the plausible region of deliberate (if ill-informed) choice. Currently there are over 2 million exposed port 445 and over one million exposed port 137 systems. Eighty three is but a drop in the ocean
- finding what that is would be useful.