Question

If I have a server with a database of top secret data in PostgreSQL and my password is practically impossible to guess (128 character string of all sorts of weird chars, generated by hand). The server password is also practically unguessable.

Aside from a password guessing, how easy is it to get the data out of this database?

Assumptions:

  1. Only the DB exists on the server. There is no password in a PHP script or anything like that
  2. The person who stole the server is a server / DB / hard-drive recovery expert
  3. I'm not using any hard-drive encryption or anything out of the norm for protection
  4. I'm using Ubuntu Hardy (latest stable version)

I'm trying to understand the risks involved with somebody gaining physical access to my server's hard-drives.

Was it helpful?

Solution

"The standard thought is when someone sits down at the server, it's compromised, end of story. Things only get worse if they grab the hard drive and take it to a lab for opening up and analysis."

Ditto.

Once an attacker has permanent physical access (i.e., he walked out of the building with your hard drive in his briefcase), the jig is up - assume that in time the data will be compromised. From there, the scenario is the cost of the delaying tactic vs. the ability to slow down the attacker.

It's a little different if the attacker is an insider, or had only temporary access. In those cases, you might be able to slow him down enough, or force accountability such that the attack becomes infeasible.

Hard drive encryption is a delaying tactic - it will give protection that matches the strength of the algorithm, strength of the key, and strength of the password locking access to the key (or the ability to insert hardware with the key stored separately). Even with encryption the assumption is that it's a delaying tactic. Sooner or later, the attacker will get through the key space and figure out what key decrypts the system.

Tamperproofing is another option - finding a way to electronically erase the hard drive under certain conditions (like physically removing it from the case).

Figure that once physical access is granted, the attacker can work around your passwords - however strong they are - without resorting to brute force. The first one that comes to mind is using the "fix the password" techniques that most systems have built in to help sys admins that have locked out & lost passwords.

Any and all protections come with a price - tamperproofing is expensive, since you need speciality hardware. Encryption can be cheaper, but it affects boot time. Also, I've seen some nasty surprises with how encryption plays with applications - you never really know until you try to use it.

OTHER TIPS

The standard thought is when someone sits down at the server, it's compromised, end of story. Things only get worse if they grab the hard drive and take it to a lab for opening up and analysis.

I would begin with whole-drive encryption, as well as per-field encryption in the database. You might look around to see if there is a way to have a biometric-based access to the hard drive hardware installed on the server. Also, you want to dig up a physical security contractor and get their recommendations for configuration; also hire guards.

I mean, if this is a scenario that might reasonably happen...

edit:

If I had a Postgres DB file I wanted to get into and I had the resources (ie, spending 4K for some cheap Dells), I would use a Beowulf configuration and perform parallel brute-force cracking. Things get worse if I start to have more money and can configure, say, several of those sweet NVidia supercomputer-on-desktop machines plugged in to really start brute-forcing a password.

If the thief is serious about getting into it and you don't have security already planned from Day 0, your DB file is going to be opened like a sardine can.

If you're not encrypting the hard drive/file system, you're pretty much out of luck, as Postgres doesn't offer native encryption. And encrypting the hard drive is the only real method of protection for a stolen server.

Basically, what you would need to do is encrypt the hard drive or filesystem, AND you would have to enter the password when you mount the drive, by hand, each time the machine starts, before Postgres fires up.

This article seems to be especially relevant to your question:

Total security in a PostgreSQL database
http://www.ibm.com/developerworks/opensource/library/os-postgresecurity/

I don't think this is a problem PostgreSQL, or any other database addresses. Even if the database its self is password protected all of the data is in plain text and thats what really matters. Nothing is stopping the attacker from cat'ing the raw database file and piping it though strings. The best solution for this type of attack is to use an encrypted file system. This would require you to type in a password to mount the partition. This also increases overhead.

For the specific question posted (and the one I came searching for an answer to), Postgresql by default stores table data unencrypted. Looking around in files in .../pgsql/9.2/data/base/* I would guess that these store tables in 1.1 gigabyte chunks, and I can successfully find ASCII strings in those files with grep. From inspection of the files it appears that the data is stored in columns.

From this information I believe that I could experiment and write code to reverse-engineer the tables to create a copy on a server which I do not have the password for.

Therefore relying on a strong database password alone does not meet your duty of care if you need to protect against the risk of the physical media being stolen.

PostgreSQL online docs provide some options for encrypting data at various levels, which for this problem seem to be limited to a module for encrypting specific columns or encrypting the underlying media in some way as other respondents have suggested.

A good start is to enable full disk encryption. You can also encrypt at the application layer. (e.g. encrypt data before you send it to the database, store the key not accessible from the database server)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top