Security
Historically, backups and security
have had almost completely opposite goals. Things such as
.rhosts
files were absolutely necessary to gain
any type of backup automation, and yet they are a well-known security
problem. Fortunately, most modern backup products have worked around
these problems.
Sockets or rsh?
There are very few products left that
communicate via rsh. rsh has
been identified as a security hole, and many sites have disabled it.
The products that still use rsh usually do not
require the ability to rsh as root; instead, they
set up a special user ID that is used only for that purpose. That
way, a .rhosts
entry needs to be set up only for
that user.
Most products now communicate via Berkeley sockets. This means that they need to have some client-side software running with which they can communicate; the process running on the client is called a “daemon.”
Encryption?
More and more people are asking for encryption. Encryption can be accomplished in one of three ways. Some software packages encrypt the commands that they send back and forth, so that a rogue server cannot imitate them and perform unauthorized actions, such as request a restore of data it is not entitled to. Another method is to encrypt backup data in transit but then decrypt it as it is being written to a backup volume. This allows backups over an insecure network but does not require an encryption key to read the volume (think of it as a “backup tunnel”). Then, of course, there are software ...
Get Unix Backup and Recovery now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.