Windows Server Hack [Electronic resources] نسخه متنی

Hack 75 Secure Backups

Protect critical business information by
restricting who can back up and restore it.

In a small organization, a
single administrator might be responsible for backing up and
restoring data stored on servers. In a large enterprise, however,
it's more likely that administrative
responsibilities will be delegated among various groups. Windows 2000
and Windows Server 2003 include special built-in groups for such
purposes, but we'll also see how creating custom
groups can give you even greater control over who can back up and
restore your data.

Using Backup Operators

There are actually two different Backup Operators groups in Windows
2000 and Windows Server 2003: a local group and a domain local group.
What's the difference between local and domain local
groups? Local groups are defined in the SAM
database on a member server or workstation, while domain
local groups are stored in Active Directory on domain
controllers. As a result, member servers and workstations have a
built-in local group named Backup Operators, and membership of this
group is modified by using Local Users and Groups in the Computer
Management console.

By contrast, domain controllers have a built-in domain local group
also named Backup Operators, and membership in the group is modified
using the Active Directory Users and Groups (ADUC) console (the group
is located within the Built-in container for each domain).

In the GUI, the domain local Backup Operators group is actually labeled as "Built-in local" instead of "Built-in domain local." This is an error in the GUI.

So, what exactly can members of the Backup Operators group do? First,
they can back up any file or folder on the server on which the group
resides. This means that if you belong to the Backup Operators group
on a member server, you can back up and restore files on that member
server (and only that member server). But if you
belong to the Backup Operators group on a domain controller, you can
back up and restore files on any server in the
domain. Backup Operators can also perform certain other tasks, such
as interactively logging on to the console of the server and shutting
the server down. And members of the built-in Server Operators group
can do everything Backup Operators can, in addition to being able to
create and manage shared folders and printers.

So, who belongs to the Backup Operators group? By default, nobody.
The idea is that these users have a powerful abilityto make
copies of sensitive business data and restore these copies to another
machineso you should think carefully before you make anyone a
member of this group.

How do Backup Operators get these abilities? By the user
rights assigned to them. User rights
indicate authorization or privilege to perform some task
and are assigned by using Group Policy (in an Active Directory
environment) or Local Security Policy (on standalone servers in a
workgroup). In a Group Policy Object (GPO), user rights are found
under Computer ConfigurationWindows
SettingsSecurity SettingsLocal
PoliciesUser Rights Assignment (see Figure 8-5).

Figure 8-5. User rights displayed in Group Policy

By default both the Backup Operators and Administrators built-in
groups are assigned the following user rights:

Back up files and directories

Restore files and directories

Again, on a domain controller, the Server Operators group also has these
rights by default. What's interesting about these
two privileges is that they override any NTFS permissions that files
and directories might have. Thus, even if the Backup Operators group
is explicitly denied Read permission to a folder, members of this
group can still back up the folder and its contents. In other words,
user rights take precedence over permissions.

Mind you, there is a hack that enables a user to back up files and
folders on a machine without assigning them the preceding rights. The
trick is to assign them, at a minimum, the following special NTFS
permissions on the file or folder:

Traverse folder/execute file

List folder/read data

Read attributes

Read extended attributes

Read permissions

You might use this method to grant a user the ability to back up
copies of sensitive documents to a local folder on his workstation.
By assigning these permissions, users can back up the contents of the
folder but can't read the files stored in it. The
rational for using this approach, instead of assigning the necessary
rights to the user, is that for security reasons you might want to
ensure that the user has as few rights as possible, in case the
user's account is compromised by an intruder. In
other words, though this approach is more complicated, it can help
guard against elevation of privilege attacks.

Restricting Access to Backups

A company's disaster recovery
plan often overlooks the fact that
those who perform backups shouldn't necessarily be
the ones who restore from backups when things go wrong.
That's because performing a backup is a routine
administrative task that should be done regularly and delegated to
some responsible user, but restoring a backup can actually provide
the user with access to the backed-up data itself. For example, by
restoring a backup job to a rogue server on the network and then
running cracking tools locally on the server, the user could gain
access to sensitive data and compromise the
company's business.

The solution is to ignore the built-in Backup Operators group and
create two new security groups instead. For instance, you might name
them something mundane, like Backup Group and Restore Group, or
something more creative if you prefer. Then, assign the right to
"Back up files and directories" to
Backup Group and "Restore files and
directories" to Restore Group.
Don't assign any other rights to these two groups.

Now, assign selected users to each group as desired. Typically, the
membership of Backup Group is be more inclusive than Restore Group
and should include both junior administrators (who have actual
responsibility for day-to-day backups) and senior administrators (who
can be there in a pinch if things go wrong). Of course, the junior
administrators should not be members of the default Domain Admins
group; if they are, they will automatically have the
"Restore files and directories"
privilege as well.

The Restore Group, however, should have only senior
administratorsthe most trusted members of your IT
departmentas members. Whether or not they are all domain
administrators is another question; best practice suggests that
membership in Domain Admins should be as highly restricted as
possible, and potential members of this group should be carefully
screened during your company's hiring process. If
you think one bad apple spoils the bunch, wait till you see what one
corrupt administrator can do to your business!

If you assign the "Back up files and directories" right to a group and then find that a user who belongs to this group has difficulty backing up one or more volumes, check the disk quota restrictions on those volumes to ensure they aren't restricting the user from accessing those volumes.

Another approach you can use to secure your backups is to take
advantage of a setting available on the Backup Job Information dialog
box (see Figure 8-6). This dialog box appears after
you start the Backup utility, select the volumes or folders you want
to back up, and click the Start Backup button. By selecting the
checkbox labeled "Allow only the owner and the
Administrator access to the backup data," you
configure permissions on the backup job so that only the individual
who created the backup and the default administrator account can
restore the backup.

Figure 8-6. Allowing only the backup owner and administrator to restore the backup

While this approach is easier than the approach I described earlier,
it doesn't provide the same level of security as
separating those who can restore data from those who back it up.
Also, you can enable this setting only if you are backing up to a new
tape or overwriting an old one; if you're appending
your backup set to an existing tape, the setting is not available. In
other words, the restriction offered by this setting is applied on a
tape-by-tape basis, not a job-by-job basis. So, the lesser degree of
security offered by this approach, coupled with its lack of
flexibility, leads me to suggest you avoid using this setting and
instead use the two-group approach I described
previously.