Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Oof, sorry, that sucks. I think you could still go the route I described though: For your domain
example.comand example servicemyservice, listen on port:12345and drop everything that isn't requestingmyservice.example.com:12345. Then forward the matching requests to your service's actual port, e.g.23456, which is closed to the internet.Edit: and just to clarify, for service
otherservice, you do not need to open a second port; stick with the one, but in addition tomyservice.example.com:12345, also accept requests forotherservice.example.com:12345, but proxy that to the (again, closed-to-the-internet) port:34567.The advantage here is that bots cannot guess from your ports what software you are running, and since caddy (or any of the mature reverse proxies) can be expected to be reasonably secure, I would not worry about bots being able to exploit the reverse proxy's port. Bots also no longer have a direct line of communication to your services. In short, the routine of "let's scan ports; ah, port x is open indicating use of service y; try automated exploit z" gets prevented.
I think I am already doing that. My Kiwix docker container port is set to 127.0.0.1:8080:8080 and my reverse proxy is only open to port 12345 but will redirect kiwi.example. com:12345 to port 8080 on the local machine.
I've learned that docker likes to manipulate iptables without any notice to other programs like UFW. I have to be specific in making sure docker containers only announce themselves to the local machine only.
I've also used this guide to harden Caddy and adjusted that to my needs. I took the advice from another user and use wildcard domain certs instead of issuing certs for each sub domain, that way only the wildcard domain is visible when I search it up at https://crt.sh/ . That way I'm not advertising my sub domains that I am using.
TBH, it sounds like you have nothing to worry about then! Open ports aren't really an issue in-and-on itself, they are problematic because the software listening on them might be vulnerable, and the (standard-) ports can provide knowledge about the nature pf the application, making it easier to target specific software with an exploit.
Since a bot has no way of finding out what services you are running, they could only attack caddy - which I'd put down as a negligible danger.
Yeah, a few weeks ago a achieved my state of "secure" for my server. I just happened to notice a dramatic decrease in activity and that's what prompted this question that's been sitting in the back of my mind for weeks now.
I do think it's important to talk about it though because there seems to be a lack of talk about security in general for self hosting. So many guides focus on getting services up and running as fast as possible but don't give security much thought.
I just so happened to have gained an interest for the security aspect of self hosting over hosting actual services. My risks for self hosting is extremely low so I've reached a point of diminishing returns on security but the mind is still curious and wants to know more.
I might write up a guide/walkthrough of my setup in the future but that's low priority. I have some other not self hosting related things I want to focus on first.