Hey guys,
after reading up on selfhosting for weeks now I finally decided to take the plunge today and tried setting up my own nextcloud & jellyfin instances. For this purpose I am using a mini PC. (similiar to an Intel NUC)
Now I would like to make both services available to the internet so I could show images to friends while I’m at their place / watch movies with them.
The problem is I am currently not very educated on which security measures I would have to take to ensure that my server / mini PC doesn’t immediately become an easy target for a hacker, especially considering that I would host private photos on the nextcloud.
After googling around I feel like I find a lot of conflicting information as well as write-ups that I don’t fully grasp with my limited knowledge so if you guys have any general advice or even places to learn about all these concepts I would be absolutely delighted!
Thank you guys sooo much in advance for any and all help, the c/selfhosted community has been nothing but a great resource for me so far!!!
deleted by creator
deleted by creator
Two remarks:
- Containers are (and never were) no security instruments but only fancy ways of bundling things
- You can open up other ports to the internet if you know what you’re doing. My SSH is open to the internet, but only with key based auto, and in case i need pw auth as a backup, only with 2FA enabled
So, putting a process in its own network, file-system, user etc. namespace does not increase security in your opinion?
Indeed. Sure, they have these features, but only if used correctly while introducing vast more complexity (especially when being executed in a k8s environment,but also executed in plain docker). But, you know what also has security when used correctly? Plain linux.
What about 90% of all images on docker hub executing their main payload as root? What about many images bundling unnecessary software like an init system? What about the fact that even if you rm something in a dockerfile, it is still present, if you execute the rm in a different RUN command? What about every user in the docker group being implicit root on the host since they simply can mount the host’s / inside their container? What about the reusing of layers between images like it is even intended?
Doesnt sound like a security tool, does it? Sure, it feels a bit like one, but it was never intended to be one, but a dependency and environment bundling tool which happens to use certain linux APIs which can be used for security. But it wraps lots of abstraction around it.
If you want to use these features for security, access them manually. But, OP said they are kind of a noob. Telling them to just use containers is dangerous and leads to false assumptions.
Source: i work as a cloud/container/devops/k8s expert for over 5 years.
If you want to use these features for security, access them manually. But, OP said they are kind of a noob. Telling them to just use containers is dangerous and leads to false assumptions.
You are absolutely correct. I should have stated explicitly that I didn’t mean docker and/or using pre-built container images. I was talking about something like systemd-nspawn. And you are right that I should not have brought this up in this context. I will edit my original comment.
Great, I accidentally deleted my original comment because the Lemmy web interface doesn’t ask for confirmation when you click the delete button. And the buttons are so small on mobile that it‘s really easy to click the wrong button.
I am using Tailscale.
In the spirit of selfhosting, you can also host headscale. Its an open source implementation of the proprietary tailscale control plane.
It allows you to get over the
5device limit (different depending on tiers), as well as keep your traffic on your devices. And, imo, it is pretty stable.The only issue is that the control plane (by nature) has to be publically accessible. But imo it’s way less of a security target than a massive app like nextcloud.
Edit: device limits were wrong
I went for wireguard VPN instead of exposing services. Its much more safe afaik, but you have to configure each device you want to give access (aka scanning QR code). You also dont need to buy a domain for that. Exposed services would be easier to use, especially if you want to use it on many devices
Duckdns.org for dynamic dns. You can get a domain name like example.duckdns.org for free.
Caddyserver.com to reverse proxy to your running docker services. You’ll be able to set up jellyfin.example.duckdns.org
Crowdsec.net to secure the network
Tailscale for access to running docker services that you don’t need to share with friends.
Could you please be more specific what exactly Crowdsec brings to the table? In which way does it “secure the network”?
There’s even a Traefik Plugins for crowdsec. I guess it’s time to play with my Traefik Config again
i have a lot of stuff exposed to the web. i got a domain from godaddy, attached my public ip and created a subdomain for each service. than i have traefik that manage the tls and route each subdomain to each of the docker containers.
in total i have exposed 80, 443, and a random port i use for ssh. of course ssh is only by public key.
now i’m trying to set up fail2ban on the exposed services since someone could bruteforce them.
My approach was to set it all up internally, create a wireguard VPN accesspoint and only open that up. That way I don’t have as much to worry as much within the network (still use generated passwords for things) and able to access it anywhere.
Granted, you asked about opening up to the www. I’d suggest buying a domain through cloudfront, setting up an nginx instance that proxies traffic (think nextcloud.mydomain.com), and have it only accept connections from cloudfront servers.
That allows you SSL termination, pretty good bot coverage, and a nice domain name to share as needed.
Best advice I can give is to make sure the default virtualhost on nginx/apache just sends a 404 to all requests to your IP, and only serve the apps you want when they’re accessed by the correct hostname. The vast majority of spammy scanners are just hitting all public IPs, so as long as you don’t tell them what you’re hosting you’ll be alright.
Then, I’d advise having some sort of basic web application firewall (WAF). Modsecurity is a common one, NAXSI is another. These take some time to set up, but are quite good at absorbing attempted attacks.
I serve HTTP 403 for all requests to the default vhost and log them, harvest IPs through a log aggregator (or just fail2ban) and tag them as bad bots/scanners, and eternal-ban them on all my hosts. Currently have 98451 addresses or networks in my ipset for these.
For requests to actual domains, I ban after a few unsuccessful authentication attempts. A WAF is nice to have (tedious but fun to set up) - currently working on improving my Modsecurity setup.
Other than that there is already good advice here:
- keep OS/packages/installed services up-to-date
- only run software from trusted (ideally signed) sources
- use host and network-based firewalls
- use strong encryption and authentication everywhere
- only expose what is absolutely required
- implement good privilege separation (even dedicated users for each app/service, proper file ownership/permissions goes a long way)
- run scanners to detect possible misconfigurations/hardening measures (
systemd-analyze securitywas mentioned, I also likelynisanddebsecan) - set up proper logging/monitoring alerting
Yep, banning scanners with
ipsetlists is a great solution. I use a slightly convoluted method to perma-ban abusers, but fail2ban also works great.
