[NBLUG/talk] Crypt Filesystems

[Jacob Appelbaum]

Walter Hansen wrote:
> Jacob Appelbaum wrote:
>> Walter Hansen wrote:
>>>> I suggest not having a copy of the passphrase on the system in
>>>> question --
>>>> if you need it to be automated, perhaps storing it on another system,
>>>> available via inetd, with tcp.wrappers only allowing its IP to get the
>>>> passphrase...
>>>>
>>>> The idea is that the bad guy who physically removes the drive will find
>>>> that
>>>> the key is nowhere to be found on the drive -- and, can't get the key
>>>> without
>>>> being (at the very least) on the backup system's network.
>>>>
>>>> Just more 2cents...
>>>>
>>>>  -Scott
>>>
>>> You missed the one detail that makes it a non issue. We're not
>>> looking for
>>> on the server security. The backup drive is swappable (almost hot). The
>>> concern is that a backup drive could be lost or stolen off prem and the
>>> backup used for evil intent. The solution is to encrypt the data and not
>>> keep the key and passphrase with the backup drive. In the solution I
>>> make
>>> a couple CDs with the passphrase/key and store them to a different
>>> loacations (send one home with each of two bosses). Then if the building
>>> burns down I take one of the backup drives, get a key cd from one of the
>>> bosses and (with $20,000) re-create our entire business in a new
>>> location
>>> in one week. At least that's the idea.
>>>
>>
>>
>> I think that Scott has a pretty solid idea actually. Though I'd use a
>> combination of iptables and ssh-keys for authentication and access.
>>
>> This way you could keep the drive encrypted on site and the drive
>> encrypted off site as well. This would help prevent with an issue of
>> theft of your backup server and if the information is important enough
>> to encrypt in the first place, it's probably best to not let it touch
>> the disk unencrypted.
>>
>> Protecting against one threat is good but the extra effort it takes to
>> protect against several more in this case is just a few more minutes of
>> setup (namely setting a second device to be encrypted rather than just
>> one).
> 
> ???

!!!

> Does sonic.net encrypt the drives of the servers in it's data room?

I sure hope that they encrypt the servers that have their customers data
on it. (Care to chime in Scott?) If my credit card is stored (and it is
with sonic) on their servers I'd hope they have something other than
physical security protecting my personal data. Disk encryption can
provide another hurdle for an attacker and it's one that most attackers
aren't going to get past. Especially a disgruntled employee that's not
in the IT department.

> It's a high performance machine. It would be a waste to encrypt the
> drives on it. The security guard, locks and alarm system protect the
> actual machine.

Loop-aes is pretty fast and if you're talking about such a small set of
data that it can fit on *one* disk, you could create a stripe and speed
much of the access up. You could get an AES accelerator card if you find
the load is CPU bound. Do some benchmarks and decide. It's a trade off,
I understand.

The security guards, locks and alarms don't provide perfect protection.
Most of the time they don't even provide protection, they provide the
feeling of being protected. Still, they probably only provide a single
layer and it's possible to augment this with other layers of protection.

> Also the drive in question is a mirror of a non-removable drive on the
> system that is not and never was encrypted.

I understand. I guess if anything, I'm suggesting that if the data is
important enough to encrypt when backing up, you might want to encrypt
the data across the board. You'd probably have much to gain and little
to lose.

> And if the drives were encrypted it would offer little or no protection
> for an online attack as the drives would be mounted. Funny thing is you
> can encrypt and protect the drive or use it; when it's physically
> connected and in use it's not protected.

It's defense in depth. Use servers behind lock and key, keep your data
encrypted on the drive, encrypt your backups, hire smart people that
won't give out access willy nilly, etc

When the time comes that your drive dies or you have upgraded to a newer
drive, you'll be happy you encrypted your disks. If you'd encrypted the
data from the start, you could wipe the disk in software and/or degauss
it without too much worry. It would be pretty impractical for anyone to
get the data back and if they did, they'd be recovering noise.

But most companies don't encrypt their drives. They throw their old
disks in the trash. They sell them on ebay. They do this and perhaps
they think they're secure because they encrypt their backups. :-)

> The possibility of having a drive lost or stolen in transit or off site
> is very real. I'm trying to protect against that possibility.

I totally understand and think it's great you're defining the scope of
your problem. My suggestions are merely additions that cover a few other
bases that you might benefit from.

> At this point though this is all for nothing though as I haven't been
> able to get encryption to work ever. I haven't given up on it, but I
> think I may have to re-compile the kernel and have concerns about things
> working the debian way. I'm wondering about other encryption mechanisms.
> I wonder if there is even just a program that I could use as the backup
> disk could just be standard ext3 with a single encrypted backup file
> that would be useless without a considerable key.

Hrm. That's a shame. I don't suggest you recompile your kernel for this
as it's not needed. Loop-aes is only a patch to the loop module and thus
it's not required to recompile anything unless the loop device is
compiled in (which it's not by default in debian).

And yeah you can use aes-pipe and tar for your backups if you want
something really simple.

If we're on irc, I can help you do this in real time and we can start
over to make sure we get it right.

Best,
Jacob