Blahaj.zone experienced a security breach and is handling it to properly reduce the risk of harm to their users. the current eta for their reture is in about 7 hours.

you are viewing a single comment's thread
view the rest of the comments

[–] moonpiedumplings@programming.dev 1 points 4 hours ago* (last edited 4 hours ago)

weren’t they having access through peertube? you can’t revoke access to something that needs it.

The peertube database did not have the vulnerable extension enabled. They got access but connecting to another database:

We did not have pgcrypto installed in the peertube database, but I overlooked that someone could connect to the main postgres database if they say had a nodejs plugin running.

From that database they escaped. So if they only had access to the peertube database, that path would have been cut off for the attackers.

also at that point, the question arises why not just run everything in qubes OS, each service in its own VM and its own VLAN.

VLAN's suck. They allow for traffic to travel within each VLAN them, unmonitored and unrestricted. Sometimes red teamers call that "hard outside, soft inside, like an eggshell".

Better, is a private VLAN. Private VLAN's enable the firewall to monitor or block all traffic within them. For many usecases, a single private VLAN can replace the complex, many VLAN setups that people spend so much effort setting up. You just block everything within itself from communicating with eachother, and then you can explicitly allow the stuff that actually needs to talk.

Often, there is no reason to allow devices with a VLAN to communicate with eachother. And even if you are allowing intra-pvlan communication within a private VLAN, you can now monitor the traffic, which you can't do with a regular VLAN.

Qubes OS

Yeah. That's basically what virtual machine or application kernel based runtimes are doing. The trick is that they are designed for this usecase, with the goal of making the isolation as cheap and performant as possible. Qubes runs full Linux VM's since it is designed for a desktop isolation usecase.

Anyway. It's a matter of threat model and effort. I like application containers/vm container runtimes due to how simple and easy they are to run, and the clear security benefits they provide. Install in < 30 min, configure the container runtime, restart your containers, done. Switching from a regular Linux desktop to Qubes is not as simple, so it's harder for me to recommend that, and it becomes a matter of threat model.

It's also common to separate services out in different Proxmox VM's, which offers isolation benefits akin to Qubes.

I run 3 separate database servers on the same OS because I made a bad decision at one point, and I regret it. I just don’t have time to merge them.

Congrats on the security isolation!

In all seriousness, you should be able to migrate them into the same database by dumping the database with pg_dump or a similar utility, and then loading them up using pg_restore. Other databases have equivalent tools. I used the Dbeaver open source database GUI to do this a few days ago.