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.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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
The job of a reverse proxy like nginx is exactly this. Take traffic coming from one source (usually port 443 HTTPS) and forward it somewhere else based on things like the (sub)domain. A HTTPS reverse proxy often also forwards the traffic as HTTP on the local machine, so the software running the service doesn't have to worry about ssl.
Be sure to get yourself a firewall on that machine. VPSes are usually directly connected to the internet without NAT in between. If you don't have a firewall, all internal services will be accessible, stuff like databases or the internal ports of the services you host.
What? Only when they are configured to listen on outside interfaces. Which, granted, they often are in default configuration, but when OP uses Docker on that host, chances are kinda slim that they run some rando unconfigured database directly. Which still would be password or authentication protected in default config.
I mean, it is never wrong slapping a firewall onto something, I guess. But OTOH those "all services will be exposed and evil haxxors will take you over" is also a disservice.
I've seen many default docker-compose configurations provided by server software that expose the ports of stuff like databases by default (which exposes it on all host interfaces). Even outside docker, a lot of software, has a default configuration of "listen on all interfaces".
I'm also not saying "evil haxxors will take you over". It's not the end of the world to have a service requiring authentication exposed to the internet, but it's much better to only expose what should be public.
Yep, fair. Those docker-composes which just forward the ports to the host on all interfaces should burn. At least they should make them 127.0.0.1 forwards, I agree.
I'm guilty of a few of these and sorry not sorry but this is not changing.
Often these are written with local dev and testing in mind, and in any case the expectation is that self-hosters will look through them and probably customize them - and in any case be responsble for their own firewalls and proxies - before deploying them to a public-facing server. Larger deployments sometimes have internal load balancers on separate machines so even when reflecting a production deployment, exposing on 0.0.0.0 or running eith network=host might be normal.
Never just run third-party compose files for user services on a machine directly exposed to untrusted networks like the internet.
What service would you recommenced for firewall. The firewall I use on my laptop is ufw, should I use that on the vps or is their a different service that works better?
Firewalld
There are some decent guides online. Also take a look in
/etc/firewalld/firewalld.confand see if you want to change anything. Pay attention to the part about Docker.You need to know about zones, ports, and interfaces for the basics. Services are optional. Policies are more advanced.
I suggest it for your laptop, too.
UFW works well, and is easy to configure. UFW is a great option if you don't need the flexibility (and insane complexity) that manually managing iptables rules offers,
Please don't recommend UFW.
One main problem with UFW, besides being based on legacy iptables (instead of the modern nftables which is easier to learn and manage), is the config format. Keeping track of your changes over track is hard, and even with tools like ansible it easily becomes a mess where things can fall out of sync with what you expect.
Unless you need iptables for some legacy system or have a weird fetish for it, nobody needs to learn iptables today. On modern Linux systems, iptables isn't a kernel module anymore but a CLI shim that actually interacts with the nft backend.
It is also full of footguns. Misconfigured UFW resulting in getting pwned is very common. For example, with default settings, Docker will bypass UFW completely for incoming traffic.
I strongly recommend
firewalld, or rawdoggingnftables, instead of ufw.There used to be limitations with firewalld but policies maturing and replacing the deprecated "direct" rules together with other general improvements has made it a good default choice by now.
ufw is just a fancy frontend for iptables, but hasn't been updated for nftables, yet.
Firewalld is an option that supports both, and if you happen to be running cockpit as well, the cockpit-firewall plugin provides a simple GUI for the whole thing.