send/receive for encrypted backup purposes

send/receive for encrypted backup purposes

[Martin Steigerwald]

Hi!

Given that the Omnia Turris router has an mSATA slot and two USB 3 connectors, 
I am pondering the feasibility for using it for backups of my home dir.

I pondered checking out zbackup, attic or obnam for that, of which at least 
zbackup and obnam can do encrypted backups¹²³.

Yet then I thought why not using btrfs send and receive directly? I found two 
answers:

Client doesn´t encrypt. And even tough I think the Omnia will be pretty secure 
unless I configure a hole into it, I´d not feel that comfortable putting my 
whole home directory there unsecured.

So my question is, would it be possible to have btrfs send/receive encrypted? 
So far I have only three ideas about it, the first two are similar:

1) Mount a dm-crypted loopback file formatted with BTRFS from the router on 
the client. Of course dm-crypt stuff need to happen on the client then. And I 
wonder whether I would loose most of the probably performance benefit of using 
btrfs send/receive this way. I could export the file with nfs for example.

2) Export a block device from the Omnia directly wie NBD or iSCSI or whatnot 
and use it with dm-crypt on the client.

3) Have all home directories crypted via ecryptfs and only send/receive the 
subvolumes with the ecryptfs files.


Any other ideas?


Something like this would also be nice to have to store on cloud storage. 
Something along the line to send a crypted btrfs send/receive stream. Ideally 
target could be a directory on some storage that doesn´t even need to be a 
BTRFS. But I bet that would be a lot of work to implement.

[1] http://zbackup.org/
[2] https://attic-backup.org/
[3] http:/obnam.org

Thanks,
-- 
Martin

Re: send/receive for encrypted backup purposes

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Fri, 2016-01-08 at 14:44 +0100, Martin Steigerwald wrote:
> So my question is, would it be possible to have btrfs send/receive
> encrypted? 
What exactly do you mean? Encrypting between the send (happening on one
system) and the receive (happening on another)?

Shouldn't any crypto that can read from stdin and write to stdout do
that?
E.g. simply ssh.

hostA$ btrfs send foo | ssh hostB btrfs receive bar


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: send/receive for encrypted backup purposes

[Swâmi Petaramesh]

Le vendredi 8 janvier 2016, 15:00:46 Christoph Anton Mitterer a écrit :
> Shouldn't any crypto that can read from stdin and write to stdout do
> that?
> E.g. simply ssh.
> 
> hostA$ btrfs send foo | ssh hostB btrfs receive bar

It works, I do this on a regular basis…

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

L'idée que chacun se fait du nombre un, quelle qu'elle soit, doit être
soigneusement distinguée du nombre un, comme les idées de la lune doivent
être distinguées de la lune elle-même.
– Gottlob Frege, Les lois de base de l'arithmétique, 1893

Re: send/receive for encrypted backup purposes

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Fri, 2016-01-08 at 15:02 +0100, Swâmi Petaramesh wrote:
> Le vendredi 8 janvier 2016, 15:00:46 Christoph Anton Mitterer a écrit
> :
> > Shouldn't any crypto that can read from stdin and write to stdout
> > do
> > that?
> > E.g. simply ssh.
> > 
> > hostA$ btrfs send foo | ssh hostB btrfs receive bar
> 
> It works, I do this on a regular basis…

One should perhaps only ask some SSH experts, whether their crypto is
actually safe for such use case.
I mean depending on what kind of data is send (e.g. often repeating
patterns and so on) some crypto schemas may be more pron to statistical
attacks than other.

But I wouldn't see much problems... ssh has rather problems with
statistical attacks when measuring keystroke times...


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: send/receive for encrypted backup purposes

[Austin S. Hemmelgarn]

On 2016-01-08 09:07, Christoph Anton Mitterer wrote:
> On Fri, 2016-01-08 at 15:02 +0100, Swâmi Petaramesh wrote:
>> Le vendredi 8 janvier 2016, 15:00:46 Christoph Anton Mitterer a écrit
>> :
>>> Shouldn't any crypto that can read from stdin and write to stdout
>>> do
>>> that?
>>> E.g. simply ssh.
>>>
>>> hostA$ btrfs send foo | ssh hostB btrfs receive bar
>>
>> It works, I do this on a regular basis…
>
> One should perhaps only ask some SSH experts, whether their crypto is
> actually safe for such use case.
> I mean depending on what kind of data is send (e.g. often repeating
> patterns and so on) some crypto schemas may be more pron to statistical
> attacks than other.
>
> But I wouldn't see much problems... ssh has rather problems with
> statistical attacks when measuring keystroke times...
>
The send data stream is (from what I can tell) about as structured as 
HTML over HTTP (although with binary data, not text), so it's likely 
similar security to using HTTPS (SSH uses essentially the same 
techniques as TLS, it's just part of the protocol as opposed to an 
intermediary layer).  That said, if you're using forced compression on 
the source FS, that may weaken things a bit.

One thing I would say in this case is to avoid using SSH compression. 
If you're on a local link, it's wasteful for bulk transfers; and even 
with non-local connections, it's not usually beneficial unless you pay 
per-unit transferred (like happens on a lot of cell networks).

Re: send/receive for encrypted backup purposes

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Fri, 2016-01-08 at 09:40 -0500, Austin S. Hemmelgarn wrote:
> That said, if you're using forced compression
> on 
> the source FS, that may weaken things a bit.
The compression oracle it typically only then a problem, when the
attacker can control the encrypted data.
So that would depend mostly on his content...

But better safe than sorry... compression should usually be avoided
with crypto.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: send/receive for encrypted backup purposes

[Austin S. Hemmelgarn]

On 2016-01-08 09:49, Christoph Anton Mitterer wrote:
> On Fri, 2016-01-08 at 09:40 -0500, Austin S. Hemmelgarn wrote:
>> That said, if you're using forced compression
>> on
>> the source FS, that may weaken things a bit.
> The compression oracle it typically only then a problem, when the
> attacker can control the encrypted data.
> So that would depend mostly on his content...
>
> But better safe than sorry... compression should usually be avoided
> with crypto.
Oh, definitely.  And that goes double for cases where the compression 
algorithm is known in advance by the attacker (because if you pay 
attention, a lot of compression algorithms produce certain patterns, 
which makes breaking things a lot easier, even if you don't control part 
of the plaintext).

Re: send/receive for encrypted backup purposes

[Austin S. Hemmelgarn]

On 2016-01-08 08:44, Martin Steigerwald wrote:
> Hi!
>
> Given that the Omnia Turris router has an mSATA slot and two USB 3 connectors,
> I am pondering the feasibility for using it for backups of my home dir.
>
> I pondered checking out zbackup, attic or obnam for that, of which at least
> zbackup and obnam can do encrypted backups¹²³.
>
> Yet then I thought why not using btrfs send and receive directly? I found two
> answers:
>
> Client doesn´t encrypt. And even tough I think the Omnia will be pretty secure
> unless I configure a hole into it, I´d not feel that comfortable putting my
> whole home directory there unsecured.
>
> So my question is, would it be possible to have btrfs send/receive encrypted?
> So far I have only three ideas about it, the first two are similar:
>
> 1) Mount a dm-crypted loopback file formatted with BTRFS from the router on
> the client. Of course dm-crypt stuff need to happen on the client then. And I
> wonder whether I would loose most of the probably performance benefit of using
> btrfs send/receive this way. I could export the file with nfs for example.
This really depends on what you are using it for, and how it's 
configured.  In the case of the backup side, I wouldn't worry as much 
about performance, as backups are ideally write once, read once 
(assuming you verify them that is), and therefore aren't really 
performance critical.  If you can get the router set up with dm-crypt, 
you could transfer the send stream over SSH (or something similar) and 
avoid some of the networking overhead.
>
> 2) Export a block device from the Omnia directly wie NBD or iSCSI or whatnot
> and use it with dm-crypt on the client.
This is probably your best bet as far as efficiency goes.  In general, 
I'd recommend NBD over iSCSI for this type of thing, as it's a lot more 
lightweight (and thus more efficient in most respects).  If you only 
ever need to access the device locally on the network served by the 
router however, I'd actually suggest ATAoE over iSCSI or NBD, it's a lot 
more efficient and technically more secure because it's non-routable (it 
runs directly over the link layer, which means you avoid the overhead of 
IP and TCP, and has the added advantage that you technically don't need 
anything but the kernel driver on the client side).
>
> 3) Have all home directories crypted via ecryptfs and only send/receive the
> subvolumes with the ecryptfs files.
This would work, but has the potential to be highly error prone, and 
likely very inefficient (at least, as compared to either of the above 
options).  There's also small amounts of metadata that get inherently 
leaked by using in-line encryption at the VFS layer (the impact of this 
is small for most people, but should still be considered).
>
>
> Any other ideas?
>
>
> Something like this would also be nice to have to store on cloud storage.
> Something along the line to send a crypted btrfs send/receive stream. Ideally
> target could be a directory on some storage that doesn´t even need to be a
> BTRFS. But I bet that would be a lot of work to implement.
>
This actually isn't all that hard to do.  The send stream can be stored 
just fine as a flat file on your target system, and thus can easily be 
compressed and/or encrypted.  This is actually what I used to do before 
I realized that incremental backups were saving me absolutely no time, 
and almost no space.  (I've actually switched to using SquashFS for 
backup storage, as it's space efficient, and has the added advantage 
that I can directly boot my backups to use as a recovery environment).

There's not anything I know of that actually does this, but it wouldn't 
be hard to write software to automate it.  Keep in mind that storing 
data that way is less efficient than receiving the stream directly onto 
another FS, but I doubt that that will have much practical impact, and 
you can mitigate this by being selective about what you back up.

Re: send/receive for encrypted backup purposes

[Christoph Biedl]

Austin S. Hemmelgarn wrote...

> (...) If you only ever
> need to access the device locally on the network served by the router
> however, I'd actually suggest ATAoE over iSCSI or NBD, it's a lot more
> efficient and technically more secure because it's non-routable (it runs
> directly over the link layer, which means you avoid the overhead of IP and
> TCP, and has the added advantage that you technically don't need anything
> but the kernel driver on the client side).

Although pretty offtopic ... AoE is not routable but don't sell this
as a security feature. If you cannot configure ACLs, you're doomed
anyway. The only security model AoE provides is the client's MAC
address but spoofing is really not a problem.

So in short:

* AoE is really simple to set up but if there's even a remote chance
  some evil guy is in your network (i.e. ethernet broadcast domain),
  just forget it. Also AoE completely relies on the ethernet checksums
  to detect data curruption, and I had some funny experiences because
  of that.

* NBD has (or had the last time I checked some 15 months ago) some
  serious issues on client side if the server becomes unavailable,
  including data loss. Yes, I should debug this one day.

* iSCSI probably provides everything you want. At the price of having
  to understand how to set it up. I failed several times and
  eventually gave up, your mileage may vary.

    Christoph

Re: send/receive for encrypted backup purposes

[Austin S. Hemmelgarn]

On 2016-01-09 14:05, Christoph Biedl wrote:
> Austin S. Hemmelgarn wrote...
>
>> (...) If you only ever
>> need to access the device locally on the network served by the router
>> however, I'd actually suggest ATAoE over iSCSI or NBD, it's a lot more
>> efficient and technically more secure because it's non-routable (it runs
>> directly over the link layer, which means you avoid the overhead of IP and
>> TCP, and has the added advantage that you technically don't need anything
>> but the kernel driver on the client side).
>
> Although pretty offtopic ... AoE is not routable but don't sell this
> as a security feature. If you cannot configure ACLs, you're doomed
> anyway. The only security model AoE provides is the client's MAC
> address but spoofing is really not a problem.
I should have qualified this, I meant it's more secure against 
accidental leaks off network.  I've had issues with this in the past 
with iSCSI where the initiator got confused and tried to contact 
something across the internet.  In addition to that, NBD and iSCSI still 
are no more secure against data loss if your network is actually 
compromised (because of how most home routers are configured (and in may 
cases, are forced to be configured), it's trivial to read all the 
traffic on the network if the router is compromised, and only slightly 
more difficult if you get admin access on a system on the network), they 
just provide better protection against DoS attacks.
>
> So in short:
>
> * AoE is really simple to set up but if there's even a remote chance
>    some evil guy is in your network (i.e. ethernet broadcast domain),
>    just forget it. Also AoE completely relies on the ethernet checksums
>    to detect data curruption, and I had some funny experiences because
>    of that.
Except that if you run BTRFS on it too, that provides further 
protection.  And, if you've got properly working hardware, this degree 
of data protection should be perfectly fine (if you're getting Ethernet 
frames with bad checksums that get through on the recipient, then 
something is wrong with your network).
>
> * NBD has (or had the last time I checked some 15 months ago) some
>    serious issues on client side if the server becomes unavailable,
>    including data loss. Yes, I should debug this one day.
It still has issues, but I don't think they're as bad as they used to 
be.  The only cases I would advocate it's usage for is exposing stuff 
temporarily to VM's that don't allow run-time reconfiguration of block 
storage, and using qemu-nbd to expose disk images to a system as block 
devices.
>
> * iSCSI probably provides everything you want. At the price of having
>    to understand how to set it up. I failed several times and
>    eventually gave up, your mileage may vary.
And the price of efficiency.  iSCSI is over-engineered for 
non-enterprise usage, and largely impractical for people who have no 
experience with it (as you found out several times).