views:

269

answers:

5

If I have a server with a database if top secret data in PostgreSQL and my password is practically impossible to crack (128 character string of all sorts of weird chars, generated by hand). The server password is also uncrackable in theory (basically, ignore the possibility of a password crack).

Aside from a password crack, 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.

+1  A: 

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/

Robert Harvey
great answer. Thanks for that resource.
orokusaki
+2  A: 

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.

Paul Nathan
@Paul Do most colos include insurance if your server is stolen? Can you sue them for losses typically in this type of case. What experience do you have with that?
orokusaki
I don't have experience in that area at this point in time. You should review your service agreement if this was being held by a third-party server company. I advise consulting a lawyer specializing in intellectual property for the specific legal actions.
Paul Nathan
+1  A: 

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.

Rook
andora
+2  A: 

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.

Will Hartung
+3  A: 

"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.

bethlakshmi