this post was submitted on 17 Oct 2023
2 points (100.0% liked)

Self-Hosted Main

504 readers
1 users here now

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.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
communick@selfhosted.forum
2
Worst case scenario after an attack (alien.top)
submitted 1 year ago by Suspicious-Iron-5526@alien.top to c/main@selfhosted.forum
14 comments fedilink hide all child comments
 

As title says, i'm curious about the worst case scenario in which an attacker tries to hit my system.

The system configuration is the following: i have some services (important ones) accessible only trough VPN, like SSH (key-based auth only), Pihole...Others are publicly accessible, like Immich, Jellyfin (and so on...).Public ones are accessible via reverse proxy (Caddy) and protected by CrowdSec (which bans IPs outside my country and those failing auth 3 times).

What could happen if an attacker finds out a vulnerability on some public service? Would he be only able to access service's files (like an appropriate login), or delete/encrypt data (as some cases of blackmail) or even pull out and steal my data?
I'm wondering this because i want to know if CrowdSec+Docker (to preserve permissions on the system) is enough to secure a server.

you are viewing a single comment's thread
view the rest of the comments
[–] adamshand@alien.top 1 points 1 year ago

The answer is, as always, it depends.

Some exploits allow the attacker access to the application (in which case they can do whatever the application allows them to do).

Some exploits allow the attacker to get shell access (in which case they can do anything the permissions of the user allow them to do).

Some exploits allow the attacker to get a root shell (in which case they can do almost anything).

Root exploits are much less common, and typically require much more skill, than application exploits. Getting root almost always requires exploiting an application, and then getting shell first.

This is why security people talk about "defence in depth".

If your application is exploited, what can you do to make it as hard as possible for the attacker to get a shell. If they get a shell, what can you do to make it as hard as possible for them to get root. If they get root, what can you do to restrict the amount of damage they can do. If they do damage, how do you know what they've done and what can you do to repair it.

When people are relying on VPNs for security, they are building what security people refer to as the "crunchy on the outside, chewy on the inside" model. There's no defence in depth, once the attacker is in ... you're screwed.

In a homelab, part of the fun is that we get to decide how much of this we can be bothered with. :-)