PostGreSQL encrypted database information

[Cristian Ancines]

Good morning community, how are you?

I am writing for guidance regarding backups via SFTP.

In my company we have many clients who manage their internal 3CX server.

To avoid data loss, we direct your backups to a virtual machine in our data center.

That virtual machine of backups we can make a snapshot every day as security.

To connect we have a:

- Backup user,
- Password backup user,
- SSH security phrase and
- an openSSH key,

all respecting the 3CX security parameters.

Problem:

A hacker managed to enter one of these 3CX servers and found all the OpenSSH connection information in the database "in clear".

Also managed to encrypt the information of two clients on the Backup machine.

Thanks to our snapshots we did not lose musha information.

Question:

Is it possible to encrypt this information in the database, in order to avoid future problems?

Total thanks.

 

[VoIPTools]

If you are asking whether you can encrypt the running PostgreSQL database 3CX is currently using, the answer is no. Don't much with the operating environment of 3CX ever. How you secure your backups and snapshots is a different question.

 

[Cristian Ancines]

Thank you very much for your reply.

I would like to explain my situation a little better.

Certainly the security of my backups is applied exclusively to SFTP transport, the only way to connect is through a key, a user and a secret phrase (to meet the 3CX backup requirements).

The problem we had was that our client's passwords were very weak (he managed his local PBX) and a hacker used an admin account to make long distance calls.

He also found all the Key SSH information (clearly written in the database), and with that information the hacker managed to encrypt the client's backup folders via SFTP.

My question is:

If only Key SSH information can be hidden or encrypted.

Thanks again

 

[VoIPTools]

I think this is a suggestion for the Ideas forum.

 

[cobaltit]

So you keep saying 'in the database' but it sounds like the 'hacker' was in the web interface. In this case encrypting it in the database won't help anything if it's still available in plain text view in the web interface then encrypting it in the database does no good. I think you're barking up the wrong tree here because the problem is the customer's 3CX instance was 'hacked'. The bigger problem there is the toll fraud. Perhaps you should be asking for 2FA/MFA for the management console instead.