I need to self-host several small websites but fear of intrusive exploits has kept me from implementation. Linux containers seem to be a perfect solution. I’m a long-time Linux user, once managed a software development company, have co-written a successful book on an Erlang web framework, have read everything I can find on the web re Linux containers and LAN/server security for years now, and have even requested help from this forum. I’ve executed the “Try it Yourself” Incus app several times. Now I ask myself, why do I still not feel confident in self-hosting Linux container-based websites?
Realization: the Incus documentation simply assumes too much for dummies like me with too many acronyms and inside baseball to inspire confidence. I have fiber Internet, domain names, static IP addresses, HTML and CSS experience, and server hardware running Linux. But the thought of actually exposing Linux container-based websites through my Verizon FIOS router gives me the willies. Nevertheless, I’m determined to do so. But I do need patient help from kind souls who can keep me from shooting myself in the foot. I’d be more than happy to feed back what I learn in simple step-by-step prose that may well help other dummies who feel as intimidated as I do. But as of now, too many steps are a mystery.
Many thanks,
LRP
understand your concerns on how dangerous the internet is and that’s where I think Incus can help to isolate or build layers for you. Running secured isolated containers on Incus is definitely more save than have every thing on a single host. It comes with some administrative overhead to set it up but what you gain out of it is a joy…
The way how I see it is that you just install the minimum of required services on your host system and harden the security as much as you can. I usually start with a bare minimum OS and what Incus requires to run. On default Incus crates a private bridge “incusbr0” for you for network isolation. Any containers you deploy will use the default profile and assign the private “incusbr0” network to it. They can reach the internet but not the other way around. To host multiple websites you need to install a reverse proxy like Nginx-Proxy-Manager or traeffic etc. Add two proxies on port 80 and 443 to your reverse proxy and it will route to your backend containers (based on your configuration).
This is more or less what is required to setup a multiple Websites with Incus in a secure way. Of course this is just the beginning and you can do a lot of more to keep it secure etc.
When you self-host your own small websites, the Internet typically knows your residential IP address.
In the old times you would use virtual hosts and Apache (or server blocks with nginx). This is required so that you can serve multiple websites from the same single IP address. Your Web server in that case would be directly exposed to the Internet. Quiet risky, especially if there was some vulnerability with the Web server software, or a vulnerability in any of the Website CMS software, etc. The same single Web server process would handle all websites in this setup.
An improvement is to do what @osch and @ciphermenial describe, use a reverse-proxy, a separate piece of software that would perform the handling of different websites on the same IP address. The reverse-proxy would then redirect each request to the appropriate separate Web server. You can use Incus and put the reverse-proxy AND each of the Web servers in separate system containers. In such a setup, you would create a VM on your server, in that VM install Incus with the mentioned system containers (reverse proxy and each web server). (see this dated guide that still works for Incus) If an attacker were to escape from such a setup, they would have to escape from the system container, then escape from the VM. It would not be trivial.
A further improvement is to use feature what Cloudflare offers (for free, on the free tier), and it’s called Cloudflare Tunnels. Compared to the previous setup, here you are off-loading the reverse proxy task to Cloudflare. Cloudflare would perform the TLS termination for you, which means that Cloudflare would handle the TLS certificate (and be able to see your traffic, hence be able to give an added feature of a Web Application Firewall). It is less self-hosted. Here, you would be creating a VM on your system, add Incus in it, then create separate system containers for each website. Since you will be using Cloudflare Tunnels, you would need to install an additional Cloudflare service in each system container. Each such Cloudflare service would create a tunnel to Cloudflare and the aim is that you are not exposing you public IP address to the Internet. You are exposing it only to Cloudflare in order to server your websites. If someone was scanning the Internet to find Web servers, they would not find your public IP. Your websites are only exposed through a tunnel to Cloudflare. An attacker would initially not know your public IP address. They would need to get access to one of your websites. Still, if they achieve that, they would not know your public IP address. They would then need to escape from a system container and reach the VM. Still no public IP address. They would need to also break out of the VM.
Many thanks to all for thoughtful replies to my plea for help. The many tips definitely help inspire confidence.
It will be several weeks before I can devote significant time to my web hosting project, but meanwhile I’ll continue my research and outline what I think I know and what I’ve learned from your generous responses and post it back here. No doubt I’ll have additional how-to questions. If all goes as I hope, I’ll eventually be able to post a detailed how-to outline or tutorial to help other dummies in my situation.