Comment on Alternative to ClamAV?
jlh@lemmy.jlh.name 9 months agoI 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.
just_another_person@lemmy.world 9 months ago
The problem if you’re presenting this to people as a solution to a question that has zero to with the valid applications of containers, which you just mentioned. Containers have a purpose, sure. I’m not arguing against that. What I’m incensed by is devs commenting similar awful solutions to a legit problem, and it’s increasingly becoming “use a container for that” for almost any concern, which is not only sending people down the wrong road, it’s just poor advice.
jlh@lemmy.jlh.name 9 months ago
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.
Chobbes@lemmy.world 9 months ago
jlh@lemmy.jlh.name 9 months ago
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.
just_another_person@lemmy.world 9 months ago
Friend, I’m not trying to be rude here, but not only are you failing to understand to question from OP, you’re failing to understand the implications of what you’re also proposing with a container. OP wants to scan static files with an AV solution.
Are you proposing that they store ALL the files from their file server in a container? Are you suggesting they mount the volume to the container at runtime in order to access and scan them? Both are ridiculous solutions for different reasons. The former is just idiotic because it immediately removes the safety of said files and makes the container non-portable, and the latter because you’re just adding a container as overhead with zero benefit or added security to the host instance, just to scan files at regular intervals. A container with a volume mount is exactly the same thing as running the file servers on the host OS. You’re not making any sense.
jlh@lemmy.jlh.name 9 months ago
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.