|
Home > Archive > Unix administration > January 2004 > Re: Tar backups creating secure tape image?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Tar backups creating secure tape image?
|
|
| Chris Mattern 2004-01-23, 4:34 pm |
| Marc David Ronell wrote:quote:
> Is there a good method to use tar to create secure tape backups? The
> goal is to encrypt each file individually and then put the encrypted
> file into the archive. Encrypting the archive would seem to yield a
> fragile backup and is not desired.
>
Encrypting backups strikes me as a rather poor idea. The last thing you
need is to be locked out of your backups when you need them. Tapes are
offline when not being used anyways. Maintain proper physical security
of your tape vault and that should take care of your security requirements.
Chris Mattern
| |
| Marc David Ronell 2004-01-23, 4:35 pm |
| >>>>> "Chris" == Chris Mattern <syscjm@gwu.edu> writes:
Chris> Marc David Ronell wrote:[QUOTE][color=darkred]
Chris> Encrypting backups strikes me as a rather poor idea. The
Chris> last thing you need is to be locked out of your backups
Chris> when you need them. Tapes are offline when not being used
Chris> anyways. Maintain proper physical security of your tape
Chris> vault and that should take care of your security
Chris> requirements.
Most places I have been in do not, unfortunately , have a tape vault.
Also, doesn't it seem silly to have logins and password protection on
normal machine access, but not on backups? If one cannot break into a
machine, it is trivial to borrow a recent backup tape.
Marc
| |
| Marc David Ronell 2004-01-23, 4:35 pm |
| >>>>> "Chris" == Chris Mattern <syscjm@gwu.edu> writes:
Chris> Marc David Ronell wrote:[QUOTE][color=darkred]
Chris> Encrypting backups strikes me as a rather poor idea. The
Chris> last thing you need is to be locked out of your backups
Chris> when you need them. Tapes are offline when not being used
Chris> anyways. Maintain proper physical security of your tape
Chris> vault and that should take care of your security
Chris> requirements.
Most places I have been in do not, unfortunately , have a tape vault.
Also, doesn't it seem silly to have logins and password protection on
normal machine access, but not on backups? If one cannot break into a
machine, it is trivial to borrow a recent backup tape.
Marc
| |
| Michael Vilain 2004-01-23, 4:35 pm |
| In article <m3fzjotj9s.fsf@cadence.glidepath.org>,
Marc David Ronell <marc_ronell@highstream.net> wrote:
quote:
>
> Chris> Marc David Ronell wrote:
> Chris> Encrypting backups strikes me as a rather poor idea. The
> Chris> last thing you need is to be locked out of your backups
> Chris> when you need them. Tapes are offline when not being used
> Chris> anyways. Maintain proper physical security of your tape
> Chris> vault and that should take care of your security
> Chris> requirements.
>
> Most places I have been in do not, unfortunately , have a tape vault.
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Any site that doesn't keep mission critical backups offsite in a tape
vault is asking for trouble.
Unless you take significant precautions to secure the passphrase (much
more than 8 characters, I would hope), those tapes will be useless if
the manager or whomever needs to do a restore without it.
Other than having to write your own backup system, I think you have way
to much time on your hands to worry about this.
Just get the backups running, the disaster recovery plan written and
tested, and a system performance and capacity planning monitor in place
by Friday. _THEN_ you can work on encrypted backups...
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Michael Vilain 2004-01-23, 4:35 pm |
| In article <m3fzjotj9s.fsf@cadence.glidepath.org>,
Marc David Ronell <marc_ronell@highstream.net> wrote:
quote:
>
> Chris> Marc David Ronell wrote:
> Chris> Encrypting backups strikes me as a rather poor idea. The
> Chris> last thing you need is to be locked out of your backups
> Chris> when you need them. Tapes are offline when not being used
> Chris> anyways. Maintain proper physical security of your tape
> Chris> vault and that should take care of your security
> Chris> requirements.
>
> Most places I have been in do not, unfortunately , have a tape vault.
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Any site that doesn't keep mission critical backups offsite in a tape
vault is asking for trouble.
Unless you take significant precautions to secure the passphrase (much
more than 8 characters, I would hope), those tapes will be useless if
the manager or whomever needs to do a restore without it.
Other than having to write your own backup system, I think you have way
to much time on your hands to worry about this.
Just get the backups running, the disaster recovery plan written and
tested, and a system performance and capacity planning monitor in place
by Friday. _THEN_ you can work on encrypted backups...
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Chris Mattern 2004-01-23, 4:35 pm |
| Marc David Ronell wrote:
Please don't email *and* post to the newsgroup; I had no idea that
this reply went to the newsgroup. Just reply to the newsgroup
unless you have a need to talk to me privately. Thank you.
quote:
>
>
> Most places I have been in do not, unfortunately , have a tape vault.
Really? I've never worked in a data center that didn't have one.
quote:
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Trivial? Once again, every place I've ever worked, only ops and the
admins had physical access to the backup tapes. Frankly, if any user
can walk in and grab your backup tapes, you have no backups that you
can count on. Even if they're encrypted, your user can still just
wipe the tape (or steal it).
Physical security of your machines and media is step one in securing
your servers. Without that, you might as well not bother, because
you don't have any security.
Chris Mattern
| |
| Chris Mattern 2004-01-23, 4:35 pm |
| Marc David Ronell wrote:
Please don't email *and* post to the newsgroup; I had no idea that
this reply went to the newsgroup. Just reply to the newsgroup
unless you have a need to talk to me privately. Thank you.
quote:
>
>
> Most places I have been in do not, unfortunately , have a tape vault.
Really? I've never worked in a data center that didn't have one.
quote:
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Trivial? Once again, every place I've ever worked, only ops and the
admins had physical access to the backup tapes. Frankly, if any user
can walk in and grab your backup tapes, you have no backups that you
can count on. Even if they're encrypted, your user can still just
wipe the tape (or steal it).
Physical security of your machines and media is step one in securing
your servers. Without that, you might as well not bother, because
you don't have any security.
Chris Mattern
| |
| Marc David Ronell 2004-01-23, 4:35 pm |
| >> "Marc" == Marc David Ronell <marc_ronell@highstream.net> writes:
The backup plan is in place and weekly backups are running, which is
enough to suit the requirements. Recovery is not a problem and has
been tested. Concerns about passwords are not an issue either.
I am at the stage where I would like to encrypt the backup, but still
keep the backup tape resilient enough for proper recovery if one file
on the tape gets hosed.
Has anyone accomplished secured tar'ed backups to tape?
Thanks,
marc
| |
| Marc David Ronell 2004-01-23, 4:35 pm |
| >> "Marc" == Marc David Ronell <marc_ronell@highstream.net> writes:
The backup plan is in place and weekly backups are running, which is
enough to suit the requirements. Recovery is not a problem and has
been tested. Concerns about passwords are not an issue either.
I am at the stage where I would like to encrypt the backup, but still
keep the backup tape resilient enough for proper recovery if one file
on the tape gets hosed.
Has anyone accomplished secured tar'ed backups to tape?
Thanks,
marc
| |
| Chris Mattern 2004-01-23, 4:35 pm |
| Marc David Ronell wrote:quote:
>
> The backup plan is in place and weekly backups are running, which is
> enough to suit the requirements. Recovery is not a problem and has
> been tested. Concerns about passwords are not an issue either.
>
> I am at the stage where I would like to encrypt the backup, but still
> keep the backup tape resilient enough for proper recovery if one file
> on the tape gets hosed.
>
> Has anyone accomplished secured tar'ed backups to tape?
Seriously, I'd would be much, much more concerned that it is "trivial"
for your users to borrow your backups than anything to do with
encryption. Properly securing your tapes would do everything
encryption could do and would accomplish a lot encryption will not.
Chris Mattern
| |
| Joe Durusau 2004-01-23, 4:35 pm |
| Chris Mattern wrote:quote:
>
> Marc David Ronell wrote:
>
> Seriously, I'd would be much, much more concerned that it is "trivial"
> for your users to borrow your backups than anything to do with
> encryption. Properly securing your tapes would do everything
> encryption could do and would accomplish a lot encryption will not.
>
> Chris Mattern
I addition to what Chris said, I sauspect that the O.P. is
implying that users have physical access to the hardware. This is,
in the case of truely untrusted users, pure poison. There are
a myriad of ways this could create a disaster in mere seconds.
Rare indeed is the system in which a 'hiccup' of a few seconds would
not be written off as "Oh, well, who knows ..." and that's all it
takes.
Speaking only for myself,
Joe Durusau
| |
| Chris Mattern 2004-01-23, 4:35 pm |
| Marc David Ronell wrote:quote:
>
> The backup plan is in place and weekly backups are running, which is
> enough to suit the requirements. Recovery is not a problem and has
> been tested. Concerns about passwords are not an issue either.
>
> I am at the stage where I would like to encrypt the backup, but still
> keep the backup tape resilient enough for proper recovery if one file
> on the tape gets hosed.
>
> Has anyone accomplished secured tar'ed backups to tape?
Seriously, I'd would be much, much more concerned that it is "trivial"
for your users to borrow your backups than anything to do with
encryption. Properly securing your tapes would do everything
encryption could do and would accomplish a lot encryption will not.
Chris Mattern
| |
| Joe Durusau 2004-01-23, 4:35 pm |
| Chris Mattern wrote:quote:
>
> Marc David Ronell wrote:
>
> Seriously, I'd would be much, much more concerned that it is "trivial"
> for your users to borrow your backups than anything to do with
> encryption. Properly securing your tapes would do everything
> encryption could do and would accomplish a lot encryption will not.
>
> Chris Mattern
I addition to what Chris said, I sauspect that the O.P. is
implying that users have physical access to the hardware. This is,
in the case of truely untrusted users, pure poison. There are
a myriad of ways this could create a disaster in mere seconds.
Rare indeed is the system in which a 'hiccup' of a few seconds would
not be written off as "Oh, well, who knows ..." and that's all it
takes.
Speaking only for myself,
Joe Durusau
| |
| Doug Freyburger 2004-01-23, 4:35 pm |
| Marc David Ronell wrote:quote:
>
> Has anyone accomplished secured tar'ed backups to tape?
You've gotten several explanations of why this is a bad idea
and no reports that anyone has done it. This is a case where
anyone who can won't and anyone who wants to can't. That's
a pretty convincing argument in my opinion.
There are plenty of options to encrypt the entire stream, GNU
tar does it with a switch. To do it file by file you would
have to roll your own. The process would have side effects
of setting modification dates in the inodes and as such
messing up the incremental backups.
| |
| Doug Freyburger 2004-01-23, 4:35 pm |
| Marc David Ronell wrote:quote:
>
> Has anyone accomplished secured tar'ed backups to tape?
You've gotten several explanations of why this is a bad idea
and no reports that anyone has done it. This is a case where
anyone who can won't and anyone who wants to can't. That's
a pretty convincing argument in my opinion.
There are plenty of options to encrypt the entire stream, GNU
tar does it with a switch. To do it file by file you would
have to roll your own. The process would have side effects
of setting modification dates in the inodes and as such
messing up the incremental backups.
| |
| Timo Felbinger 2004-01-23, 4:35 pm |
|
On 29 Aug 2003, Marc David Ronell wrote:
quote:
> Someone offline suggested find using -exec and then piping the
> encrypted file results to tar. I will probably test that approach.
What, exactly, was your reason for not tar-ing first, and then
encrypting the tar archive? If you are afraid that a single
bit error might corrupt the whole archive, consider this:
- A symmetric block cipher (like, 3des), used in a suitable feedback
mode (like, CFB), does not suffer from this problem: only the
immediately affected block (64 bits, typically), and the block
following it, will be corrupted.
- Are you _sure_ that your tape drive will let you read the remainder
of an archive after an error on the tape in the first place?
I seem to remember some drives which, when an error occurred, did
let me forward the tape to the beginning of the next archive, but
would not allow me to read the rest of the current archive.
Regards,
Timo Felbinger
| |
| David Magda 2004-01-23, 4:35 pm |
| Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
quote:
> What, exactly, was your reason for not tar-ing first, and then
> encrypting the tar archive? If you are afraid that a single bit
> error might corrupt the whole archive, consider this:
[...]
In general, doesn't tar(1) have an issue that if one block is
corrupted then the rest of the archive is hosed?
Or am I thinking of another backup program?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
| |
| Timo Felbinger 2004-01-23, 4:35 pm |
|
On 29 Aug 2003, Marc David Ronell wrote:
quote:
> Someone offline suggested find using -exec and then piping the
> encrypted file results to tar. I will probably test that approach.
What, exactly, was your reason for not tar-ing first, and then
encrypting the tar archive? If you are afraid that a single
bit error might corrupt the whole archive, consider this:
- A symmetric block cipher (like, 3des), used in a suitable feedback
mode (like, CFB), does not suffer from this problem: only the
immediately affected block (64 bits, typically), and the block
following it, will be corrupted.
- Are you _sure_ that your tape drive will let you read the remainder
of an archive after an error on the tape in the first place?
I seem to remember some drives which, when an error occurred, did
let me forward the tape to the beginning of the next archive, but
would not allow me to read the rest of the current archive.
Regards,
Timo Felbinger
| |
| David Magda 2004-01-23, 4:35 pm |
| Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
quote:
> What, exactly, was your reason for not tar-ing first, and then
> encrypting the tar archive? If you are afraid that a single bit
> error might corrupt the whole archive, consider this:
[...]
In general, doesn't tar(1) have an issue that if one block is
corrupted then the rest of the archive is hosed?
Or am I thinking of another backup program?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
| |
| Timo Felbinger 2004-01-23, 4:35 pm |
|
On 31 Aug 2003, David Magda wrote:
quote:
> Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
>
> [...]
>
> In general, doesn't tar(1) have an issue that if one block is
> corrupted then the rest of the archive is hosed?
>
Maybe some tars behave like this, but usually there should be some
way to skip over the bad block and restart reading at the next file
header.
But what would that have to do with whether you do the encryption
before or after the tar (or use no encryption at all)? If your tar
can't resume reading after a bad block, the rest of the archive is
hosed anyway, whether encrypted or not.
Decryption _will_ be able to resume after a bad block (provided that
a decent algorithm is used, of course).
Timo Felbinger
| |
| Timo Felbinger 2004-01-23, 4:35 pm |
|
On 31 Aug 2003, David Magda wrote:
quote:
> Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
>
> [...]
>
> In general, doesn't tar(1) have an issue that if one block is
> corrupted then the rest of the archive is hosed?
>
Maybe some tars behave like this, but usually there should be some
way to skip over the bad block and restart reading at the next file
header.
But what would that have to do with whether you do the encryption
before or after the tar (or use no encryption at all)? If your tar
can't resume reading after a bad block, the rest of the archive is
hosed anyway, whether encrypted or not.
Decryption _will_ be able to resume after a bad block (provided that
a decent algorithm is used, of course).
Timo Felbinger
| |
| Chris Mattern 2004-01-23, 4:46 pm |
| Marc David Ronell wrote:quote:
> Is there a good method to use tar to create secure tape backups? The
> goal is to encrypt each file individually and then put the encrypted
> file into the archive. Encrypting the archive would seem to yield a
> fragile backup and is not desired.
>
Encrypting backups strikes me as a rather poor idea. The last thing you
need is to be locked out of your backups when you need them. Tapes are
offline when not being used anyways. Maintain proper physical security
of your tape vault and that should take care of your security requirements.
Chris Mattern
| |
| Marc David Ronell 2004-01-23, 4:47 pm |
| >>>>> "Chris" == Chris Mattern <syscjm@gwu.edu> writes:
Chris> Marc David Ronell wrote:[QUOTE][color=darkred]
Chris> Encrypting backups strikes me as a rather poor idea. The
Chris> last thing you need is to be locked out of your backups
Chris> when you need them. Tapes are offline when not being used
Chris> anyways. Maintain proper physical security of your tape
Chris> vault and that should take care of your security
Chris> requirements.
Most places I have been in do not, unfortunately , have a tape vault.
Also, doesn't it seem silly to have logins and password protection on
normal machine access, but not on backups? If one cannot break into a
machine, it is trivial to borrow a recent backup tape.
Marc
| |
| Michael Vilain 2004-01-23, 4:47 pm |
| In article <m3fzjotj9s.fsf@cadence.glidepath.org>,
Marc David Ronell <marc_ronell@highstream.net> wrote:
quote:
>
> Chris> Marc David Ronell wrote:
> Chris> Encrypting backups strikes me as a rather poor idea. The
> Chris> last thing you need is to be locked out of your backups
> Chris> when you need them. Tapes are offline when not being used
> Chris> anyways. Maintain proper physical security of your tape
> Chris> vault and that should take care of your security
> Chris> requirements.
>
> Most places I have been in do not, unfortunately , have a tape vault.
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Any site that doesn't keep mission critical backups offsite in a tape
vault is asking for trouble.
Unless you take significant precautions to secure the passphrase (much
more than 8 characters, I would hope), those tapes will be useless if
the manager or whomever needs to do a restore without it.
Other than having to write your own backup system, I think you have way
to much time on your hands to worry about this.
Just get the backups running, the disaster recovery plan written and
tested, and a system performance and capacity planning monitor in place
by Friday. _THEN_ you can work on encrypted backups...
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Chris Mattern 2004-01-23, 4:47 pm |
| Marc David Ronell wrote:
Please don't email *and* post to the newsgroup; I had no idea that
this reply went to the newsgroup. Just reply to the newsgroup
unless you have a need to talk to me privately. Thank you.
quote:
>
>
> Most places I have been in do not, unfortunately , have a tape vault.
Really? I've never worked in a data center that didn't have one.
quote:
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Trivial? Once again, every place I've ever worked, only ops and the
admins had physical access to the backup tapes. Frankly, if any user
can walk in and grab your backup tapes, you have no backups that you
can count on. Even if they're encrypted, your user can still just
wipe the tape (or steal it).
Physical security of your machines and media is step one in securing
your servers. Without that, you might as well not bother, because
you don't have any security.
Chris Mattern
| |
| Marc David Ronell 2004-01-23, 4:47 pm |
| >> "Marc" == Marc David Ronell <marc_ronell@highstream.net> writes:
The backup plan is in place and weekly backups are running, which is
enough to suit the requirements. Recovery is not a problem and has
been tested. Concerns about passwords are not an issue either.
I am at the stage where I would like to encrypt the backup, but still
keep the backup tape resilient enough for proper recovery if one file
on the tape gets hosed.
Has anyone accomplished secured tar'ed backups to tape?
Thanks,
marc
| |
| Chris Mattern 2004-01-23, 4:47 pm |
| Marc David Ronell wrote:quote:
>
> The backup plan is in place and weekly backups are running, which is
> enough to suit the requirements. Recovery is not a problem and has
> been tested. Concerns about passwords are not an issue either.
>
> I am at the stage where I would like to encrypt the backup, but still
> keep the backup tape resilient enough for proper recovery if one file
> on the tape gets hosed.
>
> Has anyone accomplished secured tar'ed backups to tape?
Seriously, I'd would be much, much more concerned that it is "trivial"
for your users to borrow your backups than anything to do with
encryption. Properly securing your tapes would do everything
encryption could do and would accomplish a lot encryption will not.
Chris Mattern
| |
| Joe Durusau 2004-01-23, 4:47 pm |
| Chris Mattern wrote:quote:
>
> Marc David Ronell wrote:
>
> Seriously, I'd would be much, much more concerned that it is "trivial"
> for your users to borrow your backups than anything to do with
> encryption. Properly securing your tapes would do everything
> encryption could do and would accomplish a lot encryption will not.
>
> Chris Mattern
I addition to what Chris said, I sauspect that the O.P. is
implying that users have physical access to the hardware. This is,
in the case of truely untrusted users, pure poison. There are
a myriad of ways this could create a disaster in mere seconds.
Rare indeed is the system in which a 'hiccup' of a few seconds would
not be written off as "Oh, well, who knows ..." and that's all it
takes.
Speaking only for myself,
Joe Durusau
| |
| Doug Freyburger 2004-01-23, 4:47 pm |
| Marc David Ronell wrote:quote:
>
> Has anyone accomplished secured tar'ed backups to tape?
You've gotten several explanations of why this is a bad idea
and no reports that anyone has done it. This is a case where
anyone who can won't and anyone who wants to can't. That's
a pretty convincing argument in my opinion.
There are plenty of options to encrypt the entire stream, GNU
tar does it with a switch. To do it file by file you would
have to roll your own. The process would have side effects
of setting modification dates in the inodes and as such
messing up the incremental backups.
| |
| Timo Felbinger 2004-01-23, 4:47 pm |
|
On 29 Aug 2003, Marc David Ronell wrote:
quote:
> Someone offline suggested find using -exec and then piping the
> encrypted file results to tar. I will probably test that approach.
What, exactly, was your reason for not tar-ing first, and then
encrypting the tar archive? If you are afraid that a single
bit error might corrupt the whole archive, consider this:
- A symmetric block cipher (like, 3des), used in a suitable feedback
mode (like, CFB), does not suffer from this problem: only the
immediately affected block (64 bits, typically), and the block
following it, will be corrupted.
- Are you _sure_ that your tape drive will let you read the remainder
of an archive after an error on the tape in the first place?
I seem to remember some drives which, when an error occurred, did
let me forward the tape to the beginning of the next archive, but
would not allow me to read the rest of the current archive.
Regards,
Timo Felbinger
| |
| David Magda 2004-01-23, 4:47 pm |
| Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
quote:
> What, exactly, was your reason for not tar-ing first, and then
> encrypting the tar archive? If you are afraid that a single bit
> error might corrupt the whole archive, consider this:
[...]
In general, doesn't tar(1) have an issue that if one block is
corrupted then the rest of the archive is hosed?
Or am I thinking of another backup program?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
| |
| Timo Felbinger 2004-01-23, 4:47 pm |
|
On 31 Aug 2003, David Magda wrote:
quote:
> Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
>
> [...]
>
> In general, doesn't tar(1) have an issue that if one block is
> corrupted then the rest of the archive is hosed?
>
Maybe some tars behave like this, but usually there should be some
way to skip over the bad block and restart reading at the next file
header.
But what would that have to do with whether you do the encryption
before or after the tar (or use no encryption at all)? If your tar
can't resume reading after a bad block, the rest of the archive is
hosed anyway, whether encrypted or not.
Decryption _will_ be able to resume after a bad block (provided that
a decent algorithm is used, of course).
Timo Felbinger
| |
| Chris Mattern 2004-01-23, 5:00 pm |
| Marc David Ronell wrote:quote:
> Is there a good method to use tar to create secure tape backups? The
> goal is to encrypt each file individually and then put the encrypted
> file into the archive. Encrypting the archive would seem to yield a
> fragile backup and is not desired.
>
Encrypting backups strikes me as a rather poor idea. The last thing you
need is to be locked out of your backups when you need them. Tapes are
offline when not being used anyways. Maintain proper physical security
of your tape vault and that should take care of your security requirements.
Chris Mattern
| |
| Marc David Ronell 2004-01-23, 5:00 pm |
| >>>>> "Chris" == Chris Mattern <syscjm@gwu.edu> writes:
Chris> Marc David Ronell wrote:[QUOTE][color=darkred]
Chris> Encrypting backups strikes me as a rather poor idea. The
Chris> last thing you need is to be locked out of your backups
Chris> when you need them. Tapes are offline when not being used
Chris> anyways. Maintain proper physical security of your tape
Chris> vault and that should take care of your security
Chris> requirements.
Most places I have been in do not, unfortunately , have a tape vault.
Also, doesn't it seem silly to have logins and password protection on
normal machine access, but not on backups? If one cannot break into a
machine, it is trivial to borrow a recent backup tape.
Marc
| |
| Michael Vilain 2004-01-23, 5:00 pm |
| In article <m3fzjotj9s.fsf@cadence.glidepath.org>,
Marc David Ronell <marc_ronell@highstream.net> wrote:
quote:
>
> Chris> Marc David Ronell wrote:
> Chris> Encrypting backups strikes me as a rather poor idea. The
> Chris> last thing you need is to be locked out of your backups
> Chris> when you need them. Tapes are offline when not being used
> Chris> anyways. Maintain proper physical security of your tape
> Chris> vault and that should take care of your security
> Chris> requirements.
>
> Most places I have been in do not, unfortunately , have a tape vault.
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Any site that doesn't keep mission critical backups offsite in a tape
vault is asking for trouble.
Unless you take significant precautions to secure the passphrase (much
more than 8 characters, I would hope), those tapes will be useless if
the manager or whomever needs to do a restore without it.
Other than having to write your own backup system, I think you have way
to much time on your hands to worry about this.
Just get the backups running, the disaster recovery plan written and
tested, and a system performance and capacity planning monitor in place
by Friday. _THEN_ you can work on encrypted backups...
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Chris Mattern 2004-01-23, 5:00 pm |
| Marc David Ronell wrote:
Please don't email *and* post to the newsgroup; I had no idea that
this reply went to the newsgroup. Just reply to the newsgroup
unless you have a need to talk to me privately. Thank you.
quote:
>
>
> Most places I have been in do not, unfortunately , have a tape vault.
Really? I've never worked in a data center that didn't have one.
quote:
> Also, doesn't it seem silly to have logins and password protection on
> normal machine access, but not on backups? If one cannot break into a
> machine, it is trivial to borrow a recent backup tape.
Trivial? Once again, every place I've ever worked, only ops and the
admins had physical access to the backup tapes. Frankly, if any user
can walk in and grab your backup tapes, you have no backups that you
can count on. Even if they're encrypted, your user can still just
wipe the tape (or steal it).
Physical security of your machines and media is step one in securing
your servers. Without that, you might as well not bother, because
you don't have any security.
Chris Mattern
| |
| Marc David Ronell 2004-01-23, 5:00 pm |
| >> "Marc" == Marc David Ronell <marc_ronell@highstream.net> writes:
The backup plan is in place and weekly backups are running, which is
enough to suit the requirements. Recovery is not a problem and has
been tested. Concerns about passwords are not an issue either.
I am at the stage where I would like to encrypt the backup, but still
keep the backup tape resilient enough for proper recovery if one file
on the tape gets hosed.
Has anyone accomplished secured tar'ed backups to tape?
Thanks,
marc
| |
| Chris Mattern 2004-01-23, 5:00 pm |
| Marc David Ronell wrote:quote:
>
> The backup plan is in place and weekly backups are running, which is
> enough to suit the requirements. Recovery is not a problem and has
> been tested. Concerns about passwords are not an issue either.
>
> I am at the stage where I would like to encrypt the backup, but still
> keep the backup tape resilient enough for proper recovery if one file
> on the tape gets hosed.
>
> Has anyone accomplished secured tar'ed backups to tape?
Seriously, I'd would be much, much more concerned that it is "trivial"
for your users to borrow your backups than anything to do with
encryption. Properly securing your tapes would do everything
encryption could do and would accomplish a lot encryption will not.
Chris Mattern
| |
| Joe Durusau 2004-01-23, 5:00 pm |
| Chris Mattern wrote:quote:
>
> Marc David Ronell wrote:
>
> Seriously, I'd would be much, much more concerned that it is "trivial"
> for your users to borrow your backups than anything to do with
> encryption. Properly securing your tapes would do everything
> encryption could do and would accomplish a lot encryption will not.
>
> Chris Mattern
I addition to what Chris said, I sauspect that the O.P. is
implying that users have physical access to the hardware. This is,
in the case of truely untrusted users, pure poison. There are
a myriad of ways this could create a disaster in mere seconds.
Rare indeed is the system in which a 'hiccup' of a few seconds would
not be written off as "Oh, well, who knows ..." and that's all it
takes.
Speaking only for myself,
Joe Durusau
| |
| Doug Freyburger 2004-01-23, 5:00 pm |
| Marc David Ronell wrote:quote:
>
> Has anyone accomplished secured tar'ed backups to tape?
You've gotten several explanations of why this is a bad idea
and no reports that anyone has done it. This is a case where
anyone who can won't and anyone who wants to can't. That's
a pretty convincing argument in my opinion.
There are plenty of options to encrypt the entire stream, GNU
tar does it with a switch. To do it file by file you would
have to roll your own. The process would have side effects
of setting modification dates in the inodes and as such
messing up the incremental backups.
| |
| Timo Felbinger 2004-01-23, 5:00 pm |
|
On 29 Aug 2003, Marc David Ronell wrote:
quote:
> Someone offline suggested find using -exec and then piping the
> encrypted file results to tar. I will probably test that approach.
What, exactly, was your reason for not tar-ing first, and then
encrypting the tar archive? If you are afraid that a single
bit error might corrupt the whole archive, consider this:
- A symmetric block cipher (like, 3des), used in a suitable feedback
mode (like, CFB), does not suffer from this problem: only the
immediately affected block (64 bits, typically), and the block
following it, will be corrupted.
- Are you _sure_ that your tape drive will let you read the remainder
of an archive after an error on the tape in the first place?
I seem to remember some drives which, when an error occurred, did
let me forward the tape to the beginning of the next archive, but
would not allow me to read the rest of the current archive.
Regards,
Timo Felbinger
| |
| David Magda 2004-01-23, 5:00 pm |
| Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
quote:
> What, exactly, was your reason for not tar-ing first, and then
> encrypting the tar archive? If you are afraid that a single bit
> error might corrupt the whole archive, consider this:
[...]
In general, doesn't tar(1) have an issue that if one block is
corrupted then the rest of the archive is hosed?
Or am I thinking of another backup program?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
| |
| Timo Felbinger 2004-01-23, 5:01 pm |
|
On 31 Aug 2003, David Magda wrote:
quote:
> Timo Felbinger <Timo.Felbinger@quantum.physik.uni-potsdam.de> writes:
>
> [...]
>
> In general, doesn't tar(1) have an issue that if one block is
> corrupted then the rest of the archive is hosed?
>
Maybe some tars behave like this, but usually there should be some
way to skip over the bad block and restart reading at the next file
header.
But what would that have to do with whether you do the encryption
before or after the tar (or use no encryption at all)? If your tar
can't resume reading after a bad block, the rest of the archive is
hosed anyway, whether encrypted or not.
Decryption _will_ be able to resume after a bad block (provided that
a decent algorithm is used, of course).
Timo Felbinger
|
|
|
|
|