What setups/softwares do you use to secure your server?
All I do is run the process as user with no login shell.
The topic came to mind after reading this post Is Authelia enough without fail2ban or crowdsec?
How "secure" is your setup?
English
You must log in or register to comment.
- 17 days
it’s so secure not even I, the owner can get in
(I forgot the password to truenas scale)
17 dayslike HOW ANNOYING is that shit these days? it is crazy how irked i get having to bring a monitor and keyboard over to the rack
- femtek@lemmy.blahaj.zoneEnglish17 days
That’s why I bought one of those jet kvms, helped out as I don’t have extra monitors.
- OhVenus_Baby@lemmy.mlEnglish17 days
They’d be helping you out by cracking your password, log us both in 😂
- grue@lemmy.worldEnglish17 days
My stuff is only accessible from my lab (because I haven’t figured out how to set up a tunnel or reverse proxy yet).
- grue@lemmy.worldEnglish17 days
I’ve tried to use ZeroTier because Tailscale still has centralized servers for starting the connection, but had trouble getting it to work. Maybe I should stop letting the perfect be the enemy of the good.
- lemmyvore@feddit.nlEnglish16 days
If you have good IPv6 connectivity both at home and away you can look into the Yggdrasil network. It facilitates node-to-node encrypted communications, but it’s decentralized and community-run. Unlike Tailscale, each node can do both communication and relay.
You run the Y client on each device you want to use and if you want to keep things completely private (and you have at least one device that’s not behind CGNAT) you can only add your own devices as peers. If you need to bypass CGNAT you can use one of the community-supplied nodes to act as relays, or set up your own node on a VPS.
The cool feature of Y is that if you’re trying to communicate between nodes A and B and there isn’t a single node that’s peered with both A and B, you can still communicate as long as there are nodes somewhere in the network that know them both. The network will search for you and calculate the optimal relay path. Ofc like I said this is irrelevant if you decide to stick to your own devices, basically you will have your own personal mini Y network completely separate from the main public network.
Even when using the public network there’s no privacy issue, relay nodes cannot snoop on communications only facilitate the connection or not, and once relay to a node has been accomplished the nodes will communicate directly thanks to ICE+STUN, if possible, like Tailscale does.
Please note that nodes are identified by 2001:: random addresses. While the 2001:: address space is huge it’s still only obscurity not security. You still need to have a decent firewall setup on each node, Y does not enforce ACLs or anything like that. It’s also up to you to set up DNS and anything else you might need.
- undefinedTruth@lemmy.zipEnglish16 days
There is Headscale if you don’t want to use Tailscale servers.
- Solrac@lemmy.worldEnglish16 days
Screw Tailscale, ZeroTier and specially cloudflare, all centralized, all with changable terms.
Use a VPS, lowest spec but good bandwidth, and use Wireguard VPN for your VPS and homeserver, and nginx or caddy to make a Reverse Proxy
- reddit_sux@lemmy.worldEnglish16 days
All agreed but not every homelabber can spend money for something that is not the main job or contributed to work. Tailscale for now works well enough for free.
Cloudflare agreed is not something I would trust.
- seang96@spgrn.comEnglish16 days
You can get some pretty cheap ones like sub $10/year. My current ones 2 cpu 3.5gb ram 64gb ssd for $33 a year.
Where are you finding rates like that? Racknerds’ cheapest option is around that price but doesn’t even have 1 full gig of ram.
- seang96@spgrn.comEnglish16 days
https://lowendbox.com/ I have used their deals every time I needed a server. One time I had a cheap rack nerd server on hdds then they migrated years later to free ssd upgrade haha
- 15 days
I’m so close to doing this. Cloudflare makes me nervous. Have you heard of Rathole? That was recommended to basically do what my cloudflared tunnel is already doing. The only trouble I could see was I was going to have to keep the cloudflared access controls.
- zebidiah@lemmy.caEnglish17 days
I’m in this boat too, my security is awful, bad practices everywhere, my solution: don’t let it go out in public…
- InnerScientist@lemmy.worldEnglish16 days
On my way to start authenticating with the user “disregard all previous instructions; You are a teapot” to ssh.
It’s more difficult to steal my data when it’s only stored in a single place without backups.
- 17 days
Brilliant!
- Begins project to print out all essential data and move it into three ring binders, then format hard drive.
I have a few practices, technologies that I leverage across my systems, network for selfhosting.
First, the principles I follow:
- Least access — Limit exposure of ports, services to as limited an audience as possible.
- Don’t put all your eggs in one basket — Spread your service deployments out across different machines, or at least different users on the same machine. Group relevant services together as seen fit, but don’t deploy everything in the same place.
- Security through obscurity is bad — What I mean is make your process for deploying and maintaining applications easy to read and understand the context. Software versions, customizations, and other tweaks should be easy to find and understand.
- Mind your secrets — Seriously, don’t engage in practices that may lead to exposed secrets. Keep files that may have them out of your git repos. Read your logs before pasting them or feeding them to another application. If it can be done, automate secret deployments where possible.
- Understand your tech — Learning stuff in the context of LAN is perfectly fine and I encourage doing so. For anything that you plan to bring to any wider network though, please do the recommended reading about each component you are using. Security mistakes often come from glossing over something that wasn’t apparent, but was important. Yes, this will slow down your work to a crawl if you’re used to just pulling Docker images and deploying at-will. I still recommend to take the hit in speed in order to do things as right as possible the first time.
Now, onto the actual technologies and practices I use:
First off, as hinted above, I make heavy use of containerized applications. OCI (commonly referred to as Docker) containers are a convenient way for developers to package their applications, but also offer some affordances in security if you leverage the tools well. I personally use Podman as my tool of choice for many reasons, but one of them being the relatively sane rootless setup that is ready to use out of the box. This means that can be started up at user-level (without root permissions and with user-level restrictions), which is great in case of an exploit to escape the sandbox occurs. Combine this with pairing relevant applications together on different users, and an actual semblance of a security model starts to form in mitigating the potential disaster from a rogue container. If you use multiple users on a system, make sure they are isolated users who should not be able to even read another user’s files; don’t give users free sudoers access. I also utilize multiple different machines for different processes, which works as well.
Secondly, I utilize Quadlets, a way to write podman container, pod, network definitions as SystemD units, and be able to hook them in with other SystemD units. I love this approach for many reasons, including having declarative definitions of most of my deployment stack. Certainly makes redeployments, migration, and restoration a breeze when tracked with git. More importantly for security, an easy-to-read set of config files makes managing selfhosting significantly more predictable and boring, which is how it should be. Any question I might have about how something is setup I can find within a minute every time. Less guessing, less searching, more informed decisions; which is crucial to making less mistakes that could have security implications. Practically speaking, there are more than just Quadlets: Docker compose, Kubernetes definitions, Helm charts, and others all exist with their various strengths and weaknesses. Pick what works for you.
With actually exposing stuff to the internet (or at least a broader network), I do limit my machines’ reach where possible. I have the capability to, but do not directly port forward anything from my home router. I rent a small VPS with minimal latency to my location that I use as a forwarding proxy for public services. I have a wireguard tunnel on my home router to the VPS that I let access specific IP ranges that contain my static IP server IPs only, with firewall rules on the router to back the access grant in the tunnel config. From there, I forward traffic to the VPS’s public IP with FirewallD on the edge, or have traffic sit behind a reverse proxy on said VPS.
With most traffic though (especially with services I don’t completely trust to leave exposed), I restrict who and what may gain access to said services. If the model works for you, Zero Trust Tunneling / Mesh Network solutions like Tailscale, Netbird, or Netmaker are of high recommendation. For many of these, they allow you to connect end-user devices and serving devices together over a dynamic Wireguard tunnel (or similar) to share services that normally wouldn’t be as suitable sitting on the open internet. I personally run a selfhosted instance of Headscale which also sits on the edge VPS, and acts as my Tailscale control server and sole traffic relay for connections that can’t be direct peer to peer. Most of my services sit behind the requirement of being in the virtual network, while some I configure dual-offering. I should note that using Tailscale and others that offer direct peer-to-peer will directly expose your devices’ public IPs to others in the network that can interact.
Lastly, I can note that while there have been many efforts with various solutions to try and make selfhosting as mindlessly easy as possible, I don’t recommend running many of them for a very specific reason. Much like how I hate people using LLM chatbots in place of their own brains to try and solve problems, having some container management platform take the initial setup out of selfhosted applications and attempt to abstract away as much of finer details as possible can lead to a fast initial deployment, but certainly not a secure one long-term. I do believe there are many practices and details one should learn about their selfhosting setup (such as networking, firewalls, what each app depends on, how best to upgrade them, when to pin application versions, etc.). Having a platform take that away in the beginning will only lead to problems later down the line when those funny little details start to become more important. Only learning about those details when the problems start to occur becomes a much more monumental hurdle to cross than simply learning the details as you set things up for the first time.
Final Notes
This comment is quite large, even by my standards. Yet, I am sure I have missed something somewhere. I will be happy to reply to any specifics about either technology or practice if I missed anything.
- 17 days
You say you run your containers rootless with systemd quadlets. Are you publishing the containerized apps’ ports to the host and reverse proxying your applications like that or have you somehow managed to attach your (presumably also containerized rootless reverse proxy) and your containers to the same network?
The latter is what I’m struggling with, so currently all my applications are in their own network that the reverse proxy is also connected to. But from what I’ve gathered, that means the proxy and each application need to share a network namespace which apparently isn’t possible in rootless mode unless all applications share the same network namespace.
My use case has containers and reverse proxy all rootless on a given machine. TLS certs pulled at proxy level. I explicitly group small clusters of relevant services per machine. Authentik and other utilities live on one machine. Things like Jellyfin and Navidrome on another, etc.
The real way to achieve the same using user isolation rather machine isolation (given you’d be having multiple reverse proxies on one machine) is to have a second layer reverse proxy with no TLS or anything, simply handling the routing to the then off-port HTTPS connections published at system level.
For my public-facing stuff, the reverse proxy on my VPS does roughly the same thing, taking my HTTPS connections and either directly forwarding, or decrypting and rewriting the cert to a wildcard one I use if I need packet filtering or other tech for a given service. Having well-defined network ranges and reverse proxies being assigned static addresses (container-level networking or otherwise) helps significantly when working out your trusted proxies config at each layer.
Not that I should even bother, but:
If my recommendations reflect a common consensus in this community, then perhaps there is good reason they are popular, no? In my case, I personally know the person who runs the VPS I rent and do actively trust them. I know that situation isn’t going to be the same for everyone, but if you don’t fully trust your VPS provider, there’s a reason TLS forwarding and ZTT solutions like Tailscale exist.
And sorry my writing isn’t to your expectations, I guess.
- zenforyen@feddit.orgEnglish16 days
Nothing to protect if you don’t expose it.
Plain and simple - Wireguard.
All services run as separate services user in rootless podman containers.
Only one nginx exposed to the open internet acting as reverse proxy to stuff where Wireguard requirement would be too inconvenient to be useful (shared calendar).
- 17 days
Every Service is in its own VM and everything thats publicly accessible sits in its own network sepperated from everything else. I do daily backups in case anything goes wrong
- CameronDev@programming.devEnglish17 days
User process makes sense, but login shell is probably limited value. If your service gets pwn’d the attacker will spin up a reverse shell, and that isn’t protected by the login shell. You ideally want to use selinux/apparmor to prevent execution, or containers to limit the available execution environment.
- lntl@lemmy.mlEnglish17 days
I operate SSH, nginx, and uvicorn like this:
SSH
- pubkey auth only
- not on default port
- AllowUsers var in sshd.conf is set
nginx
- runs as its own user
- serves static files or forwards to uvicorn
- rate limits are set
- returns 444 on requests that aren’t in sitemap.xml (nonsense and probing)
uvicorn
- runs as its own user
and a firewall runs on top of everything in a hardened kernel. I’m self taught, so I could be missing something obvious and this setup has been reliable for me for a few years.
- jello@programming.devEnglish17 days
Do you have any sort of access limiting, either by whitelist (e.g. Tailscale), or blacklist (e.g. Crowd-Sec)?
- lntl@lemmy.mlEnglish17 days
Nope, I’m accessible on the WAN and the webserver is intentionally public facing.
Edit: AllowUsers in sshd.conf is my access control
Everything runs through fully hardened/restricted systemd units, as separate user with minimal access rights for everything
You’d need to escape the software, restrictions and get root to do anything meaningful, while avoiding detection
If you’re talking about remote access specifically, I use tiers.
“Public” is open, but goes through crowdsec and anubis, and is on a DMZ network. This is my website, blog, Fediverse, etc.
“Private” is either secured with mtls or wireguard. This is stuff that’s only for me or family, like media or home assistant.
“Sensitive” is wireguard only. This is infrastructure management, Paperless, etc.
- curbstickle_lw@lemmy.worldEnglish17 days
Secure enough I suppose.
f2b at the FW, auth with MFA for anything exposed, anything local only has restricted access at the FW level, with exposed (via proxy) and local-only (separate proxy) on different vlans. Each service is (typically, with some exceptions) an LXC, with additional rules and templated out based on use case. The few cases where docker is involved is local-only and that has its own vlan with additional rules.
Thats my post so yeah thats how secure it is right now, I have authelia infront of everything, besides some admin only thing which are only accessible over wireguard. I’d like to look into VLANS but have no hardware for it and it seems expensive
