Securing Windows Server 2003
Securing Windows Server 2003
Securing Windows Server 2003
Securing Windows
Server 2003
Mike Danseglio
,ch04.4758 Page 45 Monday, November 1, 2004 2:15 PM
Chapter 4 CHAPTER 4
File System Security
Whenever data is stored on physical media, it has the potential to become compro-
mised. For example, secret notes between Napoleon and his generals were compro-
mised and led, in part, to his defeat. Napoleon’s secret notes were written on leather
or paper and sent by fast riders. In a computer context, those secret notes are stored
on a hard drive and either used locally or transmitted across a network to a friend,
coworker, Internet site, or other location beyond your server or organization. In this
chapter, you’ll see who can access those secret notes on the local hard drive and how
to ensure only the desired people and groups can access them. Techniques for ensur-
ing that your data remains secret when transmitted on a network will be covered in
subsequent chapters.
The use of long-term computer data storage, whose benefits are numerous, raises
special security consideration for the system administrator: how do you protect data
so that only the intended user has access while ensuring some level of recoverability
over time? In this chapter, you’ll learn how to use file permissions and EFS—the two
main file protection mechanisms provided by Windows Server 2003—to control user
access to files. You’ll see how to use these mechanisms appropriately and how they
are often misconfigured in ways that prevent desired access. You’ll also learn how to
plan for a number of special security concerns specific to the use of portable comput-
ers. These plans may include Syskey, a special tool for protecting the account data-
base, which I show you how to use properly.
45
You may want to share files on Windows Server 2003 and allow only the HR group
access. File permissions are configurable and flexible enough to work in many differ-
ent scenarios.
Consider our user David Loudon. David has an account in an Active Directory
domain that he logs into daily to perform his work. David is a member of several
security groups, as shown in Figure 4-1.
David wants to open a file on the local hard drive called Super Secret Info.txt.
Because David is concerned with security, he sets permissions on it. He doesn’t want
any other users, including domain administrators, to access the file. He configures
the file with the permissions shown in Figure 4-2.
Figure 4-2. David has restricted the file permissions so that he is the only user with access
David now has full control of the file, and members of the Domain Admins group are
explicitly denied access. Notice that there are no other entries in the ACL. Because
the default behavior of Windows Server 2003 is to deny permission unless granted,
any user that is not on the list will be denied access to Super Secret Info.txt. David
doesn’t need to add a Deny ACE for every user or group in the domain. He simply
needs to ensure that no unintended users or groups are granted permission.
Let’s assume that at some point David is promoted or transferred into a job that
requires him to have different permission on the domain. Don, our security adminis-
trator, adds David to the Domain Admins group to ensure he has the proper permis-
sions. David thinks nothing of this change, as he is being granted additional
permissions that should allow him to perform any task on any computer within the
domain. However, when David attempts to open Super Secret Info.txt, he gets an
“Access denied” error message. This is because NTFS considers the Deny permis-
sion to be most important. Whenever an ACL is interpreted, an explicitly denied per-
mission takes precedence over all other permissions. If David or any group he is a
member of is explicitly denied permission, he is denied permission to access the file,
even in the case of conflicting levels of permission.
A quick way to verify David’s access to the file is the Effective Permissions tab of the
Advanced Security Settings dialog box shown in Figure 4-2. This tab allows an
administrator to type a username and view the effective permissions that the user will
receive. In this case, providing David’s name would show that he has no access. This
tab is currently available only in Windows Server 2003.
To allow David to access his file again, Don temporarily removes him from the
Domain Admins group.
David may have another file that he wants to share among his peers. He wants to
ensure that only his group has access. He also wants to avoid ongoing maintenance
of the ACL on this file, allowing users who enter and leave his workgroup to be auto-
matically added and removed from the file permissions. He sets security on the file as
shown in Figure 4-3. This security has no permissions for individual users, only the
Corporate Accounts Payable group. So as long as the group membership is main-
tained, the file will be accessible by the appropriate users.
This configuration works well for David. Because only the Corporate Accounts Pay-
able group is given access to the file, only members of that group can access the file.
All other users receive the default permission, which is no access. As users join and
leave the corporate accounts payable staff, the group is updated by human resources
and the IT department’s Domain Admins groups. David needs to take no action to
maintain access on the file now that it is configured correctly.
5. Click Remove on the dialog box that appears for all the existing ACEs. The ACL
will now be blank.
6. Add the desired groups and users as shown in Figure 4-6. In our example, David
Loudon’s branch users in Valdosta are the only users with access permission.
Because this group is administered by the IT and HR departments, we can con-
figure the folder so that it will not require maintenance every time an employee
joins or leaves the branch.
7. Click OK to finish configuring the file permissions. Click Sharing to share this
folder on the network. Select Share This Folder and click OK.
You will notice that permissions can also be set on the share. These permissions are
similar to the permissions you just set on the folder, although folder permissions are
more granular. The difference is that you configured the folder permissions so that
access is restricted both locally and on the network. Although share permissions can
be set to be similar to the file and folder permissions, it is not required to meet the
goal of securing the files.
Now the folder is secure. David’s group can access the folder and all its files and sub-
folders. No other users can access the contents, as they are not explicitly granted per-
missions. The permissions will dynamically change as David’s group grows or
shrinks, because the group membership is managed separately. No further security
maintenance on this folder is needed to ensure its security.
7. Add only Brian’s account with Full Control configured as Allow. Because Brian
is a bit paranoid, also add Domain Admins with Full Control configured as
Deny. This is shown in Figure 4-7.
8. Click OK to finish configuring the permissions.
I said earlier that setting Deny permissions on files and folders is a bad
idea. If Brian is ever added to the Domain Admins group, he will be
denied access to the files in this folder. Because this is highly unlikely,
Brian will probably never encounter problems with this permission.
The result of this procedure is that Brian is the only user who has access to his folder
and its contents. Any other user attempting to view his data will receive an “Access
denied” message. However, an administrator could still gain access by simply add-
ing himself to the ACL list. Because Brian is not a local administrator, he cannot pre-
vent this possibility.
the data can be read just like any other data. Because Windows Server 2003 and
Windows XP allow only NTFS to access its own partitions, this security is effective.
If another operating system is used, or if special disk-reading equipment is con-
nected to the hard disk, the data is completely unprotected.
The only way to ensure that data on the hard disk is not susceptible to this type of
attack is to protect it with encryption. Storing the data on the hard drive in an
encrypted state means that the requester must provide the decryption key for the
data to be usable. Without the decryption key, the data is useless to the requester—
regardless of the operating system making the request. Windows XP and Windows
Server 2003 allow files on the hard disk to be encrypted using the Encrypting File
System, or EFS.
The result of all these operations is encrypted data, one or more DDFs, and zero or
more DRFs. This data is then handed back to NTFS. NTFS writes all this data as
provided to the hard drive and additionally marks the file as being encrypted with
EFS. This process of encrypting files with EFS is shown in Figure 4-8.
Data recovery
field (DRF)
DRA’s public key
Data decryption
field (DDF)
User’s public key
If I had a 3#*2nP1'13
hammer...
When an application requests data from an encrypted file, EFS has to decrypt it. To
do so, NTFS retrieves the entire file and passes the information to EFS. EFS exam-
ines the public and private keys of the requester to determine whether any of these
keys can be used to decrypt a DDF or DRF associated with the file. When such a key
is found, the FEK is decrypted and used to decrypt the file data. This decrypted data
is then passed back to NTFS, which provides it to the original requester. Because all
this is handled by NTFS and EFS, applications do not need to be aware of EFS files
or take any special actions to handle them. This process of decrypting files with EFS
is shown in Figure 4-9.
Decryption
Decryption
If I had a 3#*2nP1'13
hammer...
A new feature of EFS in Windows XP and Windows Server 2003 is the ability to have
more than one DDF per file. This allows a user to add users to a file and give those
users the ability to decrypt the file without being recovery agents. This EFS file shar-
ing provides a highly secure way to share data between users when the data is located
either on a local hard drive or on a network file share. The ability to have more than
one DRF recovery agent per file has existed since EFS was first implemented in Win-
dows 2000; it is only the ability to have multiple DDFs that’s new.
This new ability of EFS has one roadblock. The public keys of all additional users
must be available to the file’s owner to add them as potential decryptors of the data.
There are a few mechanisms to aid in locating public key certificates, such as Active
Directory, but this is still largely a manual process. In most cases, the file owner must
ask the desired user to identify, export, and then transfer a public key certificate.
This can be time-consuming and is not a simple operation to perform for the major-
ity of users. For more information on certificate stores and operations, see Chapter 9.
—continued—
There is some good news. Monique says lost laptop instances have signifigantly
dropped off since the Transportation Security Administration (TSA) took over airport
security screening procedures. This is primarily due to the TSA’s security screening
procedures. They now ensure that at least one TSA employee is responsible for ensur-
ing that each screened passenger leaves the area with exactly what she arrived with.
When individuals are screened with greater scrutiny or taken aside, the employee
ensures her items follow. In the long run, this may reduce the number of all items left
in the screening area and help prevent data compromise.
And that would be fine by Monique.
Karen might use an attack commonly referred to as the Nordahl attack to gain access
to Don’s files. In this attack, Karen installs another operating system or boots to
another operating system with the compromised hard drive attached. Karen then
uses tools to reset or overwrite the security information in Don’s SAM database. Very
often, the attacker can overwrite the administrator password with her own. It’s then
a simple matter of booting to the target OS and logging in. The two mitigations to
this type of attack—removing the DRA’s key from the local computer and using Sys-
key to protect the operating system’s account database integrity—are both discussed
in this chapter.
The folder and all its contents, including files and subfolders, are now encrypted.
Because Don did not already have a certificate and private key that EFS could use,
EFS generated one before encrypting the contents.
A public key certificate and associated private key may already exist
for Don. This depends on whether a certification authority has been
installed and configured within Woodgrove Bank and, if so, whether it
is configured to issue EFS-usable certificates. In many cases, Don will
have such a certificate and not know he has one. The only way Don
can determine what certificate is used for EFS is to use the Certificates
MMC snap-in as described later to identify the certificate with the
Encrypting File System listed as its Intended Purpose.
Figure 4-10. Selecting the EFS certificate based on the Intended Purposes field
can decrypt any files encrypted with that private key. Importing a private key from a
saved file is extremely simple:
1. Insert the floppy disk in the disk drive.
2. Click Start, click My Computer, then double-click the floppy drive.
3. Double-click the file saved earlier to import the private key.
4. Enter the password when prompted.
I frequently refer to the use of a floppy disk throughout the book. This
is because the floppy drive is the most universal removable media
device available and has been installed in computers as standard
equipment for decades. However, floppy disks can go bad over time or
with minimal abuse. Many other portable storage solutions—such as
USB key drives, memory cards, and rewritable CDs—are available. In
many cases, these removable solutions will work exactly the same as a
floppy disk. When a floppy disk is specifically required, a note will be
added to indicate that fact.
To avoid data remnants on the disk for an indeterminant period, the disk should be
wiped clean of unused data. This process, while fairly lengthy, can ensure that cur-
rent technology cannot recover the old unencrypted data remnants. The procedure
can be done by following these steps:
1. Click Start ➝ All Programs ➝ Accessories ➝ Command Prompt.
2. Type cipher.exe /w:directory where directory is a directory on the desired
hard drive.
cipher.exe then identifies any portions of the hard drive that are not currently in use
and may contain old unencrypted portions of protected files. It completely eradi-
cates the data from these portions, one at a time, across the entire hard disk. Because
of its thoroughness and the size of most current hard drives, this process can take a
very long time to complete. Use the cipher /w command only occasionally when the
above circumstances exist.
Figure 4-11. Administrator is the data recovery agent for this file
David wants to save some files in a place where both he and Don can access them.
He applies NTFS file permissions to these files and their parent directory. However,
David is aware that many administrators have access to the file server. Because the
data is extremely sensitive, David wants to ensure that even in the event of compro-
mise of the file server, only he and Don can access the files. David also wants to
ensure the availability and redundancy of the data, both of which are provided by a
well-managed and -maintained file server.
To configure EFS to allow only himself and Don to access the files on a file share,
David can take the following steps:
1. Contact the file server administrator and request access to a file share.
2. Map a drive letter to the file share.
3. Create a new subfolder on the file share or identify an existing folder to contain
the protected data.
4. Apply file permissions to the folder as described earlier in this chapter. Ensure
that only he and Don have access to the folder and files.
5. Right-click on each file and choose Properties.
6. Click Advanced.
7. Click Details.
8. Because David is the creator of the folder and file, he already exists as a valid
user. To add Don to the list of users able to decrypt this file, click Add.
9. Select Don’s EFS certificate from the list, or click Find User to browse Active
Directory for Don’s certificate. The former requires that Don’s certificate was
imported to this computer, and the latter requires a CA configured to publish
issued certificates to Active Directory.
Because of the way EFS encrypts the FEK with the user’s public key, Don does not
share his private key with David. David can add any user whose public key certifi-
cate he can access, as long as that public key is configured to support EFS. When a
user attempts to access the file, she must provide her private key, securely, to the file
server. This is because the decryption occurs at the file server. Because this obvi-
ously assumes a high level of trust for the file server, any file server that will work
with EFS must be configured within Active Directory as trusted for delegation. For
more information about trusting a computer for delegation, see Chapter 7.
stored somewhere on the hard drive—if it were stored only in protected volatile
memory, EFS files would not be accessible once a computer was restarted.
The location of a user’s private keys is not a big secret, although it is obfuscated to
keep casual attackers away. The keys are stored in a protected key store database.
These keys are all protected by a single key called a master key. Other keys used by
the system for various cryptographic operations, called protection keys, are also
stored in a similar fashion.
Because an attacker who is able to obtain the master key for that account can decrypt
the stored private keys, it must be protected. To counter this type of attack,
Microsoft provides a utility called Syskey.
The syskey must be stored somewhere, just as the master and protection keys are
stored somewhere. Syskey allows you to choose one of three methods, or modes, of
protection. These modes correspond to different locations and protection levels for
the 128-bit syskey. These modes are:
Mode 1
The syskey is stored on the local computer in the registry. It is hidden from
casual access, but a dedicated attacker can quickly access the key. This mode is
the most insecure, as the key is stored with the data it is protecting. However, it
is the simplest from a user’s perspective. There is no additional interaction or
change of functionality from the user’s perspective when Syskey mode 1 is
enabled.
Mode 2
The syskey is generated from a user-supplied password. This password and its
derivitave key are never stored on the hard disk. The user must supply the pass-
word during system startup. This provides a huge benefit over mode 1, because
the cryptographic key is never stored with the data—in fact, it’s never stored on
disk at all. The downside is that if the user forgets the password, all data pro-
tected by the syskey, including the master key and all protection keys, is lost for-
ever. In addition, someone must type the password onto the local console
whenever the computer is restarted This can be problematic if the computer is in
a remote data center.
Syskey mode 2 allows you to specify any password. There are no mini-
mum criteria applied, even if you have applied password policy on
your domain user accounts. This does not mean that Syskey pass-
words should be any shorter or less complex than your domain user
accounts. Passwords should be as long and complex as possible while
remaining easily remembered. Because this password is supplied only
once per operating system boot, a more aggressive Syskey password
shouldn’t present usability issues.
Mode 3
A pseudorandom syskey is generated and stored on a floppy disk. The mecha-
nism behind this is very simple: a file is created on the disk that contains only
the syskey. During system startup, the user inserts the disk and the syskey is read
into memory to decrypt the data. This mode provides the same benefits as mode
2 and also eliminates the need for a user to memorize a static password. How-
ever, the user must be very careful with the floppy disk. The disk should never
be stored in or near the computer, as this would reduce the security to the same
as mode 1 (by storing the key and data together). Also, floppy disks have a ten-
dency to fail over time. A backup of the disk should be made and stored securely
in case it’s needed.
Syskey does not take the place of other data protection mechanisms such as EFS or
NTFS permissions. It is a complementary technology that protects the operating sys-
tem against a different type of attack. Syskey primarily prevents an attacker from
conducting an offline brute force attack against its password database. Other data,
such as confidential documents and email, must be protected using the other secu-
rity mechanisms described earlier in this chapter.
Rather than showing you how to use Syskey as a standalone utility, it’s much more
useful to look at it as a part of a complete security solution. The following example
shows how Syskey is used as part of an end-to-end procedure for protecting the
information on a portable computer.
Figure 4-12. The initial Syskey dialog allows you to enable Syskey; however, once enabled, it can
never be disabled
Figure 4-13. The Syskey dialog box that allows you to choose the mode for Syskey protection
access. In that case, NTFS permissions are not going to stop the attacker. Although
NTFS permissions might provide some protection against some attacks, only the
encryption provided by EFS will protect the data against this type of physical attack.
So although EFS is more effective against different types of offline attacks, using both
NTFS and EFS may hinder the attacker more than using one or the other.
You protect the datafiles by completing the following process:
1. Create a new directory.
2. Move all files from their current locations to the new directory or a subdirectory.
3. Ensure David has received the domain policy that contains your designated EFS
recovery agents.
4. Have David mark the new directory for encryption and apply the encryption to
existing files within the directory.
The procedures for the preceding steps are all documented earlier in this chapter.
Once the files are centrally stored and encrypted, they can be accessed only by David
or a designated EFS recovery agent.
Run cipher /w
Because David has been using the laptop for some time without using EFS, a large
amount of unencrypted data almost certainly resides on his hard drive. Although
you’ve encrypted his files, the remnants of the unencrypted files could reside on the
disk for a long time. You can ensure that an attacker cannot make use of these unen-
crypted remnants by running cipher /w. You take the following steps:
1. Run a command prompt.
2. Type cipher.exe /w:c:\, then press Enter.
This process will take a very long time, depending on the size of the hard drive and
the amount of free space. I recommend you do this in the evening, lock the com-
puter, and go home. The process should be completed by morning.
Summary
Security settings on files and folders can prevent unauthorized users from accessing
data. Setting file security is appropriate for most files on the hard drive, as it adds no
discernible overhead and works with little or no additional configuration. EFS pro-
tects files from intruders who have physical access to the hard drive (such as when
it’s stolen). Syskey provides strong protection against compromised computers,
because it encrypts a great deal of the registry and helps stop an attacker from using
the existing operating system. When configured correctly, the combination of file
security, Syskey, and EFS helps to ensure that only authorized users may access data.
Summary | 75