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:
- 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
I'm a senior Linux/Kubernetes sysadmin, so I deal with system security a lot.
I don't run ClamAV on any of my servers, and there's much more important ways to secure your server than to look for Windows viruses.
If you're not already running your servers in Docker, you should. Its extremely useful for automating deployment and updates, and also sets a baseline for isolation and security that you should follow. By running all your services in docker containers, you always know that all of your subcomponents are up to date, and you can update them much faster and easier. You also get the piece of mind knowing, that even if one container is compromised by an attacker, it's very hard for them to compromise the rest of the system.
Owasp has published a top 10 security measures that you can do once you've set up Docker.
https://github.com/OWASP/Docker-Security/blob/main/dist/owasp-docker-security.pdf
This list doesn't seem like it's been updated in the last few years, but it still holds true.
Don't run as root, even in containers
Update regularly
Segment your network services from each other and use a firewall.
Don't run unnecessary components, and make sure everything is configured with security in mind.
Separate services by security level by running them on different hosts
Store passwords and secrets in a secure way. (usually this means not hardcoding them into the docker container)
Set resource limits so that one container can't starve the entire host.
Make sure that the docker images you use are trustworthy
Setup containers with read-only file systems, only mounting r/w tmpfs dies in specific locations
Log everything to a remote server so that logs cannot be tampered with. (I recommend opentelemetry collector (contrib) and loki)
The list goes into more detail.
This is pretty much what I have setup. I’m not logging to a separate server but I do have other things setup like fail2ban, changes default ports, secrets management, etc. Good resource tho
I dont see how anything I said justifies you calling me names and calling me bad at my job. Chill out.
Containers allow for more defense-in-depth, along with their multiple other benefits to maintability, updatability, reproducibility, etc. Sure, you can exploit the same RCE vuln on both traditional VMs and containers, but an attacker who gets shell access on a container is not going to be able to do much. There are no other processes or files that it can talk to or attack. There's no obvious way for an attacker to gain persistence, since the file system is read-only, or at least everything will be deleted the next time the container is updated/moved. Containers eliminate a lot of options for attackers, and make it easier for admins to setup important security systems like firewalls and a update routine.
Obviously containers aren't always going to be the best choice for every situation, architecting computer systems requires taking into account a lot of different variables. Maybe your application can never be restarted and needs to have a more durable, VM solution. Maybe your application only runs on Windows. Maybe your team doesn't have experience with kubernetes. Maybe your vendor only supplies VM images. But running your applications as stateless containers in Kubernetes solves a lot of problems that we've historically had to deal with in IT Operations, both technically and organizationally.
I respectfully disagree. Containers are 100% the right choice in this situation. They provide the defense-in-depth and access controls that combat the threats that OP is targeting by using ClamAV.
The goal isn't securing a single database through a single attack vector. And it's not like ClamAV would help you with that, either. The goal is preventing attackers from using your infra's broad attack surface to get inside, and then persisting and pivoting to get to that database.
It's just not true that you can get the same level of security by running everything bare-metal, especially as a one-man, self-hosted operation.
I think Lemmy is glitching out here. My comment was a reply to a now deleted comment by just_another_person. It seems that after the comment was deleted, it messed up how the thread appears. Sorry for the confusion.
Ah! No worries! I’ve had similar issues with lemmy before.
OP is asking for a guard dog to keep robbers from walking through their unlocked door. I'm telling OP to just lock their door and don't bother with a guard dog.