Chapter 10books.mhprofessional.com/downloads/osborne/... · Hard / Hardening Windows Systems / Bragg / 225354-1 / Chapter 10 Another mechanism is the mandatory access control (MAC),

Chapter 10Harden Data Access

■ Use the NTFS File System

■ Use DACLs to Secure Data

■ Use EFS to Secure Data

333

Hard / Hardening Windows Systems / Bragg / 225354-1 / Chapter 10

P:\010Comp\Hard\354-1\ch10.vpFriday, April 16, 2004 12:55:35 PM

Color profile: Generic CMYK printer profileComposite Default screen

t is easy to forget that a major reason for hardening computers and networks is toprotect the data that is stored on them. We spend so much time talking about andlearning how to perfect network perimeter defenses and control access to the

computer, that we often forget the reason for this protection: our data. Soundperimeter, computer, and applications controls do assist in providing confidentialityand integrity for our data. If an attacker cannot get into your network, he cannot stealor damage the data on it. If an attacker cannot connect to a specific computer, shecannot steal or directly damage the data on it. However, once the attacker breaksthrough network defenses, once she penetrates controls on the network interface of acomputer, what prevents her from damaging and stealing its data? Application-leveldefenses may prevent the success of an attack based on using that application, but filesystem permissions and encryption can add another layer of defense. In addition toother defenses, you must develop protection for the data that resides on your systems.

TIP Don’t confine your idea of data to documents, spreadsheets, and reports. Think also ofconfiguration data, objects in the Active Directory, and even your ability to protect access tooutput devices such as printers. Once you understand how to use discretionary access controllists (DACLs), you can provide protection for those items as well.

On Windows systems that are built on Windows NT technologies, the NTFS filesystem can be used to provide discretionary access control lists (DACLs) and encryptioncan be used to provide greater protection.

Use the NTFS File SystemIn NTFS, some default DACLs are set to protect Active Directory objects and registrykeys. If the NTFS file system is used, additional protection is also available, includingthese forms:

■ If NTFS is selected during installation, default DACLs for drive roots andoperating system files are applied.

■ Permissions can and should also be managed to assist you in providingprotection for application and data files.

■ The Encrypting File System (EFS) can be used to encrypt files.

No hardening effort is complete without putting these capabilities to good use.

HARDENING WINDOWS SYSTEMS

Hard / Hardening Windows Systems / Noonan / 225354-1 / Chapter 10



TIP If FAT or FAT32 is selected during installation, the file system can be converted to NTFS.The operation will convert the drive to NTFS and leave your data intact. While it is very unlikely thatyou would experience any problems, you should, nevertheless, back up your system and data as aprecaution. You should also ensure that any applications that you run can run on NTFS (some veryold applications do not). You must then set appropriate DACLs for drive roots and operating systemfiles.

To convert a file system to use NTFS:

1. Do a complete backup.

2. Open a command prompt.

3. Enter convert drive_letter: /fs:ntfs, where drive_letter is the drive letter toconvert followed by a colon; for example, convert C: /fs:ntfs.

Use DACLs to Secure DataA DACL, or discretionary access control list, is a list of access control entries (ACEs)that specifies who can do what with a specific object. In the Windows OS, objects arefiles, folders, shares, printers, registry keys, and Active Directory objects. Each type ofobject has its own set of possible permissions.

ACEs define the security principal (user, group, or computer), whether or not thepermission is allow or deny and no matter what the permission is. (SACLs, or systemaccess control lists, are similar and are used to generate audit information. As such,they will be described in Chapter 13.) ACEs may be set by object owners, and byanyone with the permission permission. The local administrators group, by default,has this permission.

Chapter 10: Harden Data Access


The Windows 9x and Windows ME operating systems do not use the DACLconcept and therefore are not discussed in this chapter. Access to every object andpart of the standard Windows 9x and Windows ME computer is available to anyonewho has physical access to the computer, since no logon is required and no filepermissions can be set.

HEADS UP!



To properly use DACLs to secure Windows data, you must first understand thebasic permission principal. In all cases where DACLs are properly used, there are threeoptions:

■ Explicit allow Permission is granted, an ACE exists■ Explicit deny Permission is refused, an ACE exists.■ Implicit deny Neither an allow nor deny ACE exists; therefore, no

permission exists.

It is not necessary to deny access, since access is implicitly denied to those who donot have specific access allowed. The explicit deny can be used to prevent access byusers whose membership in one group might allow them access, but who should notbe allowed access to a specific object. An example of such usage is provided in the latersection “Use DACLs for Separation of Duties.”



It is possible to code an application in which a NULL DACL is applied. A NULLDACL is different from an empty one. An empty DACL does not list a group oruser account that has access to the object. In this case, no group or user has access.The object owner can give a group or user access (by creating an appropriateACE), but until he does so, no one has access. (In addition, an administrator, orsomeone with the take ownership right, can take ownership and set an ACE thatprovides access.) A NULL DACL is the opposite; it defaults to provide default fullcontrol to anyone. Applications should not be written which assign NULL DACLsto objects, and this is an item that should be included in any software securityreview.

HEADS UP!

DAC vs. MACAccording the National Institute of Science and Technology (NIST), in specialpublication 800-7 “Security in Open Systems” (http://csrc.nist.gov/publications/nistpubs/800-7/), a Discretionary Access Control (DAC) “. . .is used to controlaccess by restricting a subject’s access to an object. It is generally used to limit auser’s access to a file. In this type of access control it is the owner of the file whocontrols other users’ accesses to the file.”

Using a DAC mechanism, as Windows does, allows users control over accessrights to their files. When these rights are managed correctly, only those usersspecified by the owner may have some combination of read, write, execute, etc.permissions to the file.



Use Inheritance to Manage PermissionsIn addition to permissions granted directly on objects, permission inheritance playsa role. Permission inheritance means that permissions are, by default, inherited fromobjects that exist above the current object in the object hierarchy. This means, for example,that permissions set on a file folder may be applied to subfolders and files beneath thatfolder. It means that permissions set on the root of a drive may be applied to everyfolder, subfolder, and file on the drive. Inheritance makes it easier to set permissions,and permission inheritance makes it possible to make a mess of the intendedpermission settings for folders and file.

NOTE Imagine having to explicitly set permissions on every file or registry key; you just wouldnever get the job done. It’s much easier to set permissions for a large group of objects by settingthem at some hierarchical level, and then, if necessary, set individual additional privileges forobjects beneath that level.

The permissions that are available on any specific object are a combination ofinherited and explicit permissions. You determine these “effective” permissionsdifferently depending on the objects and the operating system used. Inheritance ofpermissions can be also be blocked in some versions of Windows. Table 10-1 listsinformation about inheritance as it is handled by the different Windows versions.



Another mechanism is the mandatory access control (MAC), in which thesystem, not the owner of the data, controls access to the data. Current Windowsimplementations do not use this mechanism.

Feature OS

Permission inheritance is available. NT, Windows 2000, Windows Server 2003, XPProfessional

Inheritance can be blocked. Windows 2000, Windows Server 2003, XP Professional

Inherited permissions are stored with the object. NT 4.0

Preferred order of ACEs: access deny ACEs firstin the DACL.

NT 4.0

Preferred order of ACEs: noninherited accessdenied ACEs are first, followed by noninheritedaccess allowed, followed by access deniedinherited.

Windows 2000, Windows Server 2003, Windows XP

Table 10-1. Permission Inheritance





Avoid Inadvertent Incorrect Permission ApplicationThe different permission features can cause some confusion and misunderstandingof how permissions work. More important, any misunderstanding could mean amisconfiguration that might prevent authorized users from accessing objects, orprovide unauthorized users with access. Misunderstanding or simple ignorance couldalso allow applications to order ACEs in a way that perverts their interpretation. Toavoid this issues, use these simple rules:

Because noninherited permissions (the permissions assigned directly to the object)are evaluated first in Windows 2000, Windows XP, and Windows Server 2003, itis possible that an inherited Deny permission will never be evaluated. This isbecause these OSs evaluate noninherited ACEs first and this process may resultin granting access. If it does, the inherited permissions will never be evaluated.

An example of such a problem can be shown by comparing two sets ofpermissions. First, assume this example is being applied on a Windows XPProfessional computer. In the first set, a folder named Accounts Payable is assignedthe permissions Administrators Allow Full Control, Accounts Payable Clerks AllowChange, and Accounts Receivable Clerks Deny Full Control. A file in this folderinherits these permissions and is also given the additional permission AccountReceivable Clerks Allow Change. Henry, who is a member of the AccountsReceivable Clerks group, uses an application and attempts to read a file in theAccounts Payable folder. The ACEs on the file are evaluated first. So, in ourexample, the permission on the file, which allows Accounts Receivable Clerks groupchange permission, is evaluated first. Since the change permission includes the readpermission, Henry is granted access. The inherited permissions are not evaluated.

In the second set of permissions, permissions are replaced entirely by a newset. The same folder, the Accounts Payable folder, is assigned the permissionsAdministrators Allow Full Control, Accounts Payable Clerks Allow Change, andAccounts Receivable Clerks Deny Full Control. A file within the folder inheritsthese permissions and is also given the permissions Auditors Allow Read. Henry,who is a member of the Accounts Receivable Clerks group and the Users groupand no others, uses an application and attempts to read a file in the AccountsPayable folder. The ACEs on the file are evaluated first. The permission AuditorsAllow Read is evaluated but does not apply to Henry because he is not a memberof the group Auditors. Next the inherited permissions are evaluated. The Denypermissions are evaluated first. The Accounts Receivable Deny Full Controlpermission is evaluated, and Henry is denied access.

Now imagine this scenario if implemented on Windows NT 4.0. Because theprocessing of inherited permissions is different, a Deny permission either inheritedor directly applied on the file will be evaluated first. Henry will not be able to accessthe file.

HEADS UP!





■ Apply recommended hardening for Windows NT 4.0. Default file system rootand system permissions for Windows NT 4.0 are weak and requiremodification. See the later section “Harden File System DACLs.”

■ Restrict user permissions on file system roots and system folders. Onlyadministrators should have the ability to change permissions here, andadministrators must be thoroughly trained before obtaining the ability tomodify these permissions.

■ Where possible and necessary, protect folder-based permissions from changesdue to inheritance by blocking inheritance. See the later section “BlockInheritance of Permissions.”

■ Use Deny permissions sparingly and review their application. Remember, it ispossible that a Deny permission may not be the first permission evaluated. Ifan Allow permission is evaluated first, access will be granted. All applicablepermissions are not read and then selected; only as many permissions as arenecessary to provide or deny the requested access are evaluated.

■ When writing code that may order ACEs in DACLs, follow the Windowspreferred ACE order for the operating system.

Assign Permissions Based on User RoleUse the role-based approach to permissions. That is, provide each user with only theaccess required to do his job. When designing permissions infrastructure:

■ Determine what access to which objects is required for a specific role.■ Create additional custom Windows groups as necessary to fulfill each role.■ Assign permissions to groups, not users.■ Add user accounts to the groups whose role they must perform.

Determine Required AccessDetermining who requires access to what is the difficult part of permissioning. You willhave to use Windows documentation, application documentation, and organizationalinformation to determine the required access. Data owners should be required to provideinformation on who within the organization requires specific access to specific data.

Create Additional Windows Groups as NecessaryAdministrative groups and how to delegate administrative duties are defined inChapter 7. Many other custom windows groups will probably be required, but theexact groups will be dictated by the organization’s composition, business model,and other unique requirements. Group scope will also impact group creation.

Stand-alone Windows computers based on NT technologies have only one type ofgroup scope—the local group. Groups are created in the local account database, andlocal accounts can be added to these groups. Accounts with membership in groupshave object access and user rights assigned to the group.





Windows NT computers joined to a domain have three group scopes: local, global,and domain local.

■ Local groups are those groups created in the local account database. Theycan be granted access only to objects on the same local computer. Theirmembership can be local accounts, domain accounts from the domain the localcomputer is a member of, and domain accounts from trusted domains.

■ Global groups are created in the domain database that is shared by alldomain controllers. These groups can be given access to any domain membercomputers’ resources and to any trusted domain member computers. Membersare domain user accounts.

■ Domain local groups in Windows NT are simply an extension of the localgroup concept. They are local groups created on domain controllers. However,since the domain account database is replicated to backup domain controllers,local groups created on DCs can be granted access to resources on any domaincontroller in the domain.

Windows 2000 and Windows Server 2003 domains also have global groups, buttwo additional group scopes are available:

■ Domain local groups for Windows 2000 and Windows Server 2003 representdifferent group scope. They are created in the account database of the domaincontrollers but can be given access to objects on any domain membercomputer. Members can be domain accounts and domain global groups.

■ Universal groups can be granted access to any resource in the domain andcan have as members any domain member from any domain in the forest,and any global group. Universal groups are possible only when a domain isin Windows 2000 Native mode or at the Windows Server 2003 functional level.

The ability of groups to nest memberships from other groups varies depending onthe OS and domain mode or functional level. In a Windows NT 4.0 domain, the onlynesting is of Windows global groups into local groups. In a Windows 2000 or WindowsServer 2003 mixed-mode (or mixed functional level) domain, the same is true. However,a Windows 2000 Native mode domain, or a Windows Server 2003 domain at Windows2000 and above functional level, also allows additional nesting. Universal groups can benested in local and global groups, global groups in global groups, and domain localgroups within other domain local groups.

Assign Permissions to Groups, Not UsersIn all versions of Windows domains, the preferred group and permission managementstructure can be remembered by using the acronym AGLP. It stands for this process:

■ Assign Permissions to Local groups.■ Nest Global groups within Local groups.■ Place Accounts in Global groups.





If this simple structure is followed, many benefits accrue:

■ The list of ACEs in a DACL is shorter, and performance is improved.■ It is easy to assign a new employee the access he requires. Simply provide him

membership in the group or groups that have been assigned permissions anduser rights that he requires.

■ It is easy to remove a departing employee’s access by disabling his account andthen simply removing his membership from all groups. (When permissions areassigned to accounts, deleting an account immediately may not be best practice,since this may leaves orphan SIDs on objects throughout the entire Windowsinfrastructure.)

■ It is easier to adjust permissions for employees that change jobs within theorganization; simply remove membership from groups necessary for the oldassignment, and add membership to groups required by the new one.

Add Users to Groups According to the Roles They Must PerformOnce the catalog of necessary permissions and user rights for specific roles has beendetermined and the proper group assignment and group infrastructure implemented,it is a simple task to add users to the required groups.

Use DACLs for Separation of DutiesUsing DACLs to implement the security principle “separation of duties” is a step feworganizations take but many should. This is how to set it up:

1. Determine where separation of duties is present—for example, betweenaccounts payable clerks and accounts receivable clerks.

2. Determine objects that each should have access to but the others should not.

3. Create a group to represent each role, for example, a Payables Clerks groupand a Receivables Clerks group.

4. Give each group the Allow permissions on the objects it should have access to.

5. Give each group Deny Full Control on the objects the other group should haveaccess to.

This is an example of how it works:

1. Alice is hired to work in the Accounts Payable department. She is added as amember of the Payables Clerks group. She is able to access appropriate filesand other resources.

2. Alice changes jobs. She now works in the Accounts Receivable department. ITwas not notified, and her membership is not removed from the Payables Clerksgroup. IT is told to add Alice as a member of the Receivables group.





3. While membership in the Receivables Clerk group is appropriate andnecessary for her new job, if she retains membership in the Payables Clerkgroup, then she has access permissions assigned to both groups. This would bea violation of the principle of separation of duties. Alice might be able to issuea fraudulent purchase order and a fraudulent payment on that purchase order.However, since the Deny Full Control permission is assigned to the PayablesClerks group for objects the Receivables Clerks require access to, Alice will bedenied access to those objects. She will not be able to do her job. Since shecannot do her assigned job, action will have to be taken. The action required isto remove her from the Payables Clerks group.

Block Inheritance of PermissionsPermission inheritance can be blocked in Windows Server 2003, Windows XP, andWindows 2000. When inheritance is blocked, the objects do not inherit permissionsassigned higher in the object hierarchy. A good example of this feature is its applicationto protect system files. The WINNT or WINDOWS folder is the folder where operatingsystem subfolders and files are stored. Different permissions are applied here than at theroot, and they are protected from change via inheritance from drive root permissionssettings, as shown in Figure 10-1. The Allow Inheritable Permissions from the Parent. . .check box is unchecked.

If you must set critical folder permissions that should not be modified by changesto folders higher in the object hierarchy, uncheck this box on the Advanced SecuritySettings Permission page for folders in Windows Server 2003 and XP, and on thegeneral Security page in Windows 2000. You can also block permission inheritance forregistry keys and Active Directory objects. Windows NT 4.0 permission inheritancecannot be blocked. Inheritance in printer permissions is not possible.

Use Apply To AppropriatelyWhen adding permissions, Windows 2000, Windows Server 2003, and Windows XPsystems allow setting of the Apply To property. The Apply To property allows settingpermission applicability to a variety of possible scenarios. Use the setting that givesexactly the assignment required for each case. For example, folder permissions can beassigned

■ This folder, subfolder, and files■ This folder only■ This folder and subfolders■ This folder and files■ Subfolders and files only■ Subfolders only■ Files only



Maintain Proper PermissionsOnce permissions are set, they should remain. Unfortunately, permissions may bemodified for many reasons. Changes to permissions may be made in an attempt totroubleshoot access or application failures, to provide temporary access, or duringprogram installation. There are three ways to ensure appropriate permissions aremaintained:

■ Use proper change management procedures and processes. Changemanagement should be formally organized and carried out. When properprocedures are followed, the reasons for changes are evaluated, and if approved,implemented with proper testing and accompanied by documentation. Nochange should be made without using approved procedures.

■ IT should conduct periodic sampling for adherence to approved settings. Thiscan easily be automated using security templates.

■ IT should make proper audits. Whether internal or external auditors getinvolved, appropriate permissions can be checked as part of every IT audit.

The topics of change management and audits are covered in Chapters 13 and 14respectively.



Figure 10-1. Permission inheritance is blocked for the WINDOWS folder.



Secure File Systems and DataObject permission basics apply to file system objects, to folders and files. Each fileand folder permission setting should be considered, designated, implemented, andmaintained appropriately.

Harden File System DACLsDefault file and registry DACLs are set appropriately for Windows Server 2003,Windows 2000, and Windows XP. However, Windows NT 4.0 file system DACLs areweak. Table 10-2 lists the Microsoft-recommended modifications. Note that the changesare for a Windows NT 4.0 domain controller, and that the Installers group is a not astandard Windows group but a placeholder for a recommendation made in the whitepaper “NSA Windows NT System Security Guidelines.” The Installers group is used torepresent all users who have privileges to install applications or systems software.Recommendations are similar for NT Workstation and Server and are located in theBaseline Security Checklists available from www.Microsoft.com/technet/security.



Folder Subfolder/Files Recommended ACEs

C:\ Root and IO.SYS and MSDOS.SYS,AUTOEXEC.BAT, CONFIG.SYS

Installers: ChangeEveryone: ReadServer Operators: Change

BOOT.INI, NTDETECT.COM, NTLDR None

C:\ TEMP Everyone: (RWXD) (not specified)

C:\ WINNT and control.iniWINNT is also shared as ADMIN$

Installers: ChangeEveryone: ReadServer Operators: Change

\WINNT Win.ini Installers: ChangePublic: ReadServer Operators: Change

\WINNT Netlogon.chg None

\WINNT \config Installers: ChangeEveryone: ReadServer Operators: Change

\WINNT \cursors\\fonts\\media\

Installers: ChangeEveryone: ReadServer Operators: ChangePower Users: Change

\WINNT \help Installers: ChangeEveryone: Add & ReadServer Operators: ChangePower Users: Change

WINNT \inf Installers: ChangeEveryone: Read

WINNT\inf *.ADM files Everyone: Read

Table 10-2. Permission Hardening for Windows NT 4.0






WINNT\inf *.PNF Installers: ChangeEveryone: ReadServer Operators: Change

\WINNT \media\*.RMI Everyone: Change

\WINNT\profiles \profiles Installers: Add & ReadEveryone: (RWX) (not specified)

\WINNT\profiles ...\all usrs Installers: ChangeEveryone: Read

\WINNT\profiles ...\Default Everyone: Read

\WINNT \repair None

\WINNT \system Installers: ChangeEveryone: ReadServer Operators: Change

\WINNT \system32 Installers: ChangeEveryone: ReadServer Operators: ChangeBackup Operators: Change

\WINNT\system32 Files Everyone: ReadServer Operators: Change

WINNT\system32\ $winnt$.inf Installers: ChangeEveryone: ReadServer Operators: Change

WINNT\system32\ AUTOEXEC.NT, CONFIG.NT Installers: ChangeEveryone: readServer Operators: Change

WINNT\system32\ Cmos.ram, midimap.cfg Everyone: Change

WINNT\system32\ Localmon.dll, decpsmon.*, hpmon.* Installers: ChangeEveryone: ReadServer Operators: ChangePrint Operators: Change

\WINNT\System32 \Config Everyone: list

\WINNT\SYSTEM32 \Dhcp Everyone: ReadServer Operators: Change

\WINNT\System32 \drivers Everyone: Read

WINNT\System32 \LLS Installers: ChangeEveryone: ReadServer Operators: Change

\WINNT\System32 \OS2 Everyone: ReadServer Operators: Change

\WINNT\System32 \RAS Everyone: Read

\WINNT\System32 \Repl Everyone: ReadServer Operators: Change

\WINNT\System32\Repl Import, export, scripts (import\scripts is thenetlogon directory)

Everyone: ReadServer Operators: ChangeReplicator: Change

Table 10-2. Permission Hardening for Windows NT 4.0 (continued)



Add File System DACLs to Converted or Formatted NTFS DrivesWhen Windows 2000, Windows Server 2003, and Windows XP systems are installed,default file system DACLs are applied. However, when systems are upgraded to theseoperating systems, file system permissions remain as they were. If FAT file systemsare converted to NTFS, the normal default file system permissions are not applied.New file system DACLs are not applied in these cases to prevent the situation wherechanging permissions prevent user access or system operation. You should evaluatethe requirements of applications and data access that is required and then applyappropriate system and file system permissions.

An option, after evaluation, may be to apply default permissions using securitytemplates. Table 10-3 lists the default security templates that provide file systempermission settings. The templates can be applied using Security Configuration andAnalysis, scripts, or Group Policy.

Harden File System SharesFile system shares are access points to drives on a system. This mechanism is used toprovide remote administration and to provide easy access to data across the network.By default, several access points are provided:

■ The root of each drive The C$, D$, and so on■ The system root By default, WINNT or WINDOWS shared as ADMIN$■ Interprocess communications Used for sharing information between

applications by providing support for pipes, mail slots, RPC, windows sockets,and so on; shared as IPC$




\WINNT\System32 \Spool, \drivers, \prtprocs Installers: ChangeEveryone: ReadServer Operators: FullPrint Operators: Change

\WINNT\System32 \printers\, \tmp\ Installers: ChangeEveryone: (RWX) (not specified)Server Operators: Full

\WINNT\System32 \viewers\ Everyone: ReadServer Operators: Change

\WINNT\System32 \wins Everyone: ReadServer Operators: Change

C:\… \*.EXE, *.BAT, *.COM, *.DLL Everyone: Execute

Table 10-2. Permission Hardening for Windows NT 4.0 (continued)



■ Netlogon Used for authentication and for Windows 2000 and WindowsServer 2003 domain controllers; shared as NETLOGON

■ The system volume Stores the server copy of the domain’s public files,including the NELOGON share, logon scripts, and File Replication Service(FRS) staging folders and files that must be replicated (SYSVOL)

■ Additional shares that may be present The FAX clients share (FAX$) and theprinter share (PRINT$)

NOTE Root shares are set for access by members of the local administrators group only, andpermissions cannot be changed. The permissions on these shares should be maintained.

Administrative shares are those shares that cannot be identified by viewing the filesystem. An Administrative share is created by appending a dollar sign ($) to the end ofthe share name. Administrative shares on a specific computer can be viewed by usingadministrative tools. To view shares on a Windows NT 4.0 server, open Server Managerand select the Computer menu Shared Directories as shown in Figure 10-2. To viewshares on a Windows 2000, Windows XP, or Windows Server 2003 computer, use theComputer Management console Shared Folders | Shares node as shown in Figure 10-3.All shares will be shown, not just administrative shares.



OS Template Description

Windows Server 2003/XP Rootsec The permissions on the%System% folder are provided.

Windows Server 2003/XP DC security File and folder permissions arelisted.

Windows Server 2003/XP Compatws Folder permissions that will providecompatibility for legacyapplications.

Windows Server 2003/XP Setup security File and folder permissions asapplied during setup. (Copy from asystems setup on a new install onNTFS.)

Windows 2000 Hisecws File and folder permission toharden Windows 2000Professional.

Windows 2000 Ocfiless and ocfilesw Folder permissions for additionalapplications such as NetMeeting,Outlook Express, FrontPage, etc.

Windows 2000 Basicsv and basicwk Basic folder and file permissionsinstalled for default servers andworkstations.

Table 10-3. Default Security Templates with File Permission Settings



Turn Off File and Printer Sharing When It Is Not RequiredRegardless of the configuration of shares on a Windows computer, the Server servicemust be started, and for Windows 2000, Windows XP, and Windows Server 2003, the



Figure 10-2. Viewing administrative shares on Windows NT 4.0

Figure 10-3. Viewing administrative shares on Windows Server 2003



File and Printer Sharing networking option must be running. For Windows 9x andWindows ME, the File and Printer Sharing networking option must be installed andselected. To turn off file and printer sharing in Windows NT 4.0, disable the Serverservice:

1. Open the Server Manager console through Start | Administrative Tools.

2. From the Computer menu, select Services.

3. Select the Server service and click Startup as shown here:

4. Click Disabled under Startup Type as shown here:

5. Click OK to close, and then click Stop to stop the service.

6. Click Close and then Exit the Server Manager console.







To stop File and Printer Sharing:

1. Open the network connector for the local area connection or other networkinterface (Start | Control Panel | Network Connections).

2. Click Properties.

3. Click to deselect File and Printer Sharing for Microsoft Networks as shown here:

4. Click OK and then click Close.

However, there are many reasons to enable this service:

■ Microsoft Baseline Security Analyzer, a free vulnerability assessment tool, requiresthat File and Printer Sharing be enabled in order to remotely scan Windowscomputers.

■ Windows domain controllers must run File and Printer Sharing in order forusers to authenticate to the domain and for other essential domain servicessuch as Active Directory to function.

■ File and Print Servers must run this service in order for remote computers toaccess their file system and printer.

For domain controllers and file and print servers, the choice is obvious: sharingmust be enabled. Likewise, edge servers, those that may have multiple networkconnections that include connections to untrusted networks, should not have sharingenabled on the external or untrusted interface. The trouble lies with the rest of thecomputers. For many years, sound security advice included preventing shares on





workstation computers and on servers that were not file servers or domain controllers.However, if you need to remotely run vulnerability scanning software against thesecomputers, you may need to enable sharing. Alternatively, terminal services, or localvulnerability scanning, may be the answer for more sensitive systems.

Remove Shares on Drive RootsIf a Windows computer will not be remotely administered, the decision may be madeto remove the shares on drive roots. All shares, including administrative shares, can beremoved by using options in the consoles where they can be viewed. Administrativeshares, however, will return if the system is rebooted. To disable shares on drive rootsand on the system root folder (ADMIN$), add the AutoShareWks DWORD value to theregistry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Set the AutoShareWks value to 0. Should you need to restore these defaultadministrative shares, simply delete the AutoShareWks DWORD value and reboot thecomputer.

Prevent Nonadministrators from Creating SharesSet the permissions of the following key and all of its subkeys to Everyone Read:

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\LanManServer\Shares

Harden Share PermissionsWhen a new share is created, the default permissions on Windows 2000 and WindowsNT 4.0 is Everyone Full Control. Change this immediately to Everyone Read, or to theappropriate share permissions for the specific folder. Windows XP and WindowsServer 2003 shares default to Everyone Read.

Secure PrintersBy default, printers are shared, giving Administrators Full Control, Everyonepermission to print, document owners permission to manage the documents, andPrinter Operators and Server Operators the ability to manage documents and printers.To harden printers, reduce the permissions on all printers. The following permissionsshould be adjusted:

■ Provide only Print Operators with the Manage Printer and Manage Documentspermissions. Remove Administrators and Server Operators.

■ Only authenticated users should have print permission.■ For sensitive printers, such as check printers, create Windows groups for

managing and printing and assign these groups management and printpermissions respectively. Remove the default groups and their permissions.

■ Create a subgroup of Administrators that can manage printers by providingthem membership in the Print Operators group.



Secure Registry KeysRegistry keys, like files and folders, have permissions assigned to protect key systeminformation. In addition, protection from remote access and from anonymous accessshould be provided. To protect the registry from remote administrative access, disablethe remote registry service. Unfortunately, unless you need to administer very fewservers, a better solution is to manage remote access to the registry.

Restrict Remote Registry AccessRemote access to the registry is set by setting permissions on the winreg key located at

HKEY_LOCAL_MACHINE\SYSTEM\Control\CurrentControlSet\SecurePipeServers

Permissions are set in Windows Server 2003 by right-clicking the key and selectingPermissions, and then adjusting the permissions using the object picker. Note in Figure10-4 that by default, only the local Administrators group has full control here, whileBackup Operators and the LOCAL SERVICE have read access.

Windows NT 4.0 does not, by default, set permissions on Winreg; however, this isdone by application of service pack 6, as shown in Figure 10-5. To set permissions inWindows NT 4.0, use the regedt32.exe tool’s Security menu and select Permissions.



Figure 10-4. Permissions set on the Winreg key control remote access to the registry.



In both cases, reduce risk by establishing a special administrators group that isauthorized to remotely administer computers and assign that group Full Control.

Harden Permissions on Registry KeysTable 10-4 lists sensitive Windows NT 4.0 registry keys in the HKEY_LOCAL_MACHINE hive that need permission changes to protect them. (Unless noted, do notapply permissions to the entire tree, but only the path listed.) Table 10-5 lists severalregistry keys that to which access should be restricted for all Windows versions thatcontain them.



Figure 10-5. Windows NT 4.0 permissions on WinReg

Subkey Path Installers Everyone InteractiveApply to EntirePath

Software Change Read None No

Software \classes Add Read None No

Software \Microsoft\Windows\CurrentVersion\AppPaths

Change Read None Yes

Software \Microsoft\Windows\CurrentVersion\Explorer

None Read None Yes

Table 10-4. Registry Permissions Recommendations for Windows NT 4.0



NOTE Permissions on the Run Registry Keys may have to be modified in order to allow theinstallation of some software. Be sure to return the permission sets of these keys to the reducedpermissions indicated in Table 10-5 after the software is installed.



Subkey Path Installers Everyone InteractiveApply to EntirePath

Software \Microsoft\Windows\CurrentVersion\Embedding

Change Read None Yes

Software \Microsoft\Windows\CurrentVersion\Run,RunOnce, Uninstall, andAEDebug

None Read None N/A

Software \Microsoft\Windows NT\CurrentVersion\Font*,GRE_Initialize

Change Add None Do not changeFont Drivers

Software \Microsoft\Windows NT \CurrentVersion\ Type 1Installer\Type 1 Fonts

Change Add None No

Software \Microsoft\Windows NT \CurrentVersion\Drivers,Drivers.desc

None Read None Yes

Software \Microsoft\Windows NT \CurrentVersion\MCI\MCIExtensions

Change None None Yes

Software \Microsoft\Windows NT \CurrentVersion\Ports

None Read Read Yes

Software \Microsoft\Windows NT \CurrentVersion\WOW

None Read None Yes

Software \Microsoft\Windows 3,1Migration Status

None Read None Yes

System CurrentControlSet\Services\LanmanServer\Shares

None Read None Yes

System CurrentControlSet\Services\

None Read None Yes

Table 10-4. Registry Permissions Recommendations for Windows NT 4.0 (continued)





Secure Directory ObjectsDirectory objects also have permission settings. Often these settings do more than grantaccess to objects. Permission settings on Active Directory objects also provide the abilityto manage the object, objects in a path, or properties of objects. Directory objectpermissions are discussed in Chapter 6.

Secure ServicesOnly administrators should have the ability to modify the startup status of systemservices. You can control this right in Windows NT 4.0 by setting the permission toEveryone Read on the registry key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Read permission for Users is set by default on Windows 2000. Windows XP andWindows Server 2003 provide more granular control. Each individual service can becontrolled by using security templates or Group Policy.

1. Expand the Services node in Security Settings | System Service and select theservice to manage.

2. Right-click the service and select properties.

3. Select Define This Policy Setting.

4. Select the service’s startup mode: Automatic, Manual, or Disabled.

Path Keys Permissions

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows\CurrentVersion

Run Everyone: Read


Run Once Everyone: Read


RunOnceEx Everyone: Read


AeDebug Everyone: Read

Table 10-5. Recommended Permissions on Run Registry Keys





5. Click the Edit Security button as shown here:

6. Set permissions using the object picker. Note that the default setting in the nextillustration is INTERACTIVE Read (Administrators and SYSTEM have FullControl.)





Use EFS to Secure DataCorrectly set file permissions can keep users out of files when the operating system isrunning. However, if the computer can be booted to an alternative OS, or if files can becopied to a different computer, then permissions cease to be an effective security tool.Encryption can protect files regardless of the operating system used to attempt accessto the files. The Encrypting File System is available in Windows 2000, Windows XPProfessional, and Windows Server 2003. It can be used to encrypt a single file or, ifapplied to a folder, will encrypt all files placed in the folder. It can be used to encryptlocal files, or used to encrypt files stored on a file server or web server. While Windows2000 EFS-encrypted files cannot be shared, Windows XP and Windows Server 2003EFS-encrypted files can. In order to effectively and securely use EFS, special attentionmust be paid, and training, backup, and recovery procedures developed. The first stepin hardening EFS is to disable it.

NOTE Windows NT 4.0, Windows 98, and Windows ME do not include EFS. These operatingsystems will not be discussed in this section.

Disable EFS Until You Can Securely Implement ItLike any security tool, encryption can be misused and provide a false sense of security.If EFS is not properly managed, its protection can be voided, and worse, users may loseaccess to critical or sensitive files. These are the reasons for these problems:

■ EFS encryption keys are protected by keys bound to the user account. If anattacker can crack, deduce, or otherwise obtain a user’s password, the attackercan log on as the user and read the encrypted files. Users with weak passwordsare at the greatest risk.

■ Windows 2000 EFS stand-alone computers establish the local Administratorsaccount as the EFS recovery agent. The administrator can read every encryptedfile. Alternatively, an attacker who obtains the Administrator password can logon as the administrator and read the files.

■ If the Administrator EFS private key (required to read encrypted files) isremoved from the computer, the Administrator can still, on Windows 2000,reset the users account, log on as the user, and read the files.

■ In a domain, the first domain administrator to log on to the DC will become theEFS recovery agent and be able to read all EFS-encrypted files in the domain.

■ Domain administrators can reset user passwords and thus log on as users andgain access to their files.



■ The user profiles store the EFS certificate and private key. If the profile isdamaged, the user will lose access to his files. If the profile of the localAdministrator (on a stand-alone computer) or of the domain recovery agent isdamaged, then file recovery will not be possible. This actually happens a lot, asproblems with profiles are frequently solved by deleting profiles, and problemswith computers are often solved by reinstalling the operating system.

■ Windows XP stand-alone computers do not make the local Administrator arecovery agent. This is good, since the Administrator cannot read the files, butbad, since there is no recovery.

■ Statements in documentation that indicate keys should be archived are notemphasized, and users frequently don’t read documentation anyway. Keysare not backed up. If EFS encryption keys were backed up, then users couldrecover files. But users don’t, and backing up a large number of EFS keys is animpossible task. There is no default remote administration available for EFSkeys. Windows Server 2003 does offer key archival, but this requires quite a bitof setup.

■ EFS files can be shared. Unfortunately, once an EFS-encrypted file is sharedwith another user, the original owner loses control of the file. The new usercan turn around and share the EFS-encrypted file with others.

■ If EFS files are to be stored on a file server, they are first decrypted, sent acrossthe network in the clear, and then encrypted on the file server. During transport,if captured, the file can be read.

For these reasons, best practices suggest that you disable EFS until you can establisha sound management policy that includes some form of key backup or archival andrecovery management. To disable EFS in Windows 2000 requires only that you removethe recovery agent. Without a recovery agent, Windows 2000 EFS will not work. Toprevent EFS across an entire domain, the EFS policy must also be removed. XP andWindows Server 2003 do not require a recovery agent. To disable EFS in theseenvironments requires a registry setting.

To disable EFS in Windows 2000:

1. Add the local Group Policy Object to an MMC console.

2. Expand the Public Key Policies node through Computer Configuration |Windows Settings | Security Settings.

3. Select the Encrypting Data Recovery Agents folder as shown here:






4. In the details pane, right-click the certificate designated for File Recover andselect Delete.

5. Right-click the Encrypting Data Recovery Agents folder and select DeletePolicy.

To disable EFS in a Windows 2000 Domain, open the GPO for the domain andnavigate to Public Key Policies node via Computer Configuration | Windows Settings |Security Settings and then follow steps 1 to 5.

To disable EFS in a stand-alone Windows XP Professional or Windows Server 2003computer:

1. Open the local Group Policy in an MMC.

2. Expand the Public Key Policies node through Computer Configuration |Windows Settings | Security Settings.

3. Right-click the Encrypting File System folder and select Properties.

4. Uncheck Allow Users to Encrypt Files Using Encrypting File System (EFS).

5. Click OK.

To disable EFS in a Windows 2003 domain:

1. Open the domain GPO and navigate to the Public Key Policies node throughComputer Configuration | Windows Settings | Security Settings.






2. Right-click the Encrypting File System folder and select Properties.

3. Uncheck Allow Users to Encrypt Files Using Encrypting File System (EFS) asshown here:

4. Click OK.

5. Right-click the Encrypting File System folder and select All Tasks, and thenselect Delete Policy.

Windows XP and Windows Server 2003 EFS can also be disabled by directly editingthe registry. Add the DWORD value EFSConfiguration (and give the value of 1) to theregistry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS

Harden EFS PracticesIn order to implement solid, secure, and scalable EFS, many items must be considered.The following EFS practices should be considered as part of your EFS policy andpractice.





Encrypt Folders, Not FilesIf the folder encryption bit is set, each file saved to the folder will be encrypted. Whenfiles are opened by those whose keys have encrypted the EFS encryption keys, the filesare transparently decrypted. This is a very convenient way of operating, as the processis transparent to the user. It is also a more secure way of operating if files are alwayscreated within the folder.

When files are first created and then encrypted, it is possible that data shreds, or cleartext data from the original file, may be left on the disk. The Microsoft cipher.exe tool canbe used to remove any potential data shreds; however, this is a time-consuming process.

Restrict Permissions on Encrypted FilesEncrypted files cannot be opened by users who do not possess the proper keys.However, encryption does not remove a user’s ability to delete a file. If a user has thedelete permission, it does not matter that the file is encrypted; the file can be deleted.Likewise, a user may be able to back up an encrypted file, moving it to another folder.Be sure to use file permissions to restrict access to encrypted files.

Require Strong Password Policies and Enforce ThemIf a user’s password can be cracked, an attacker can log on as the user and open theuser’s encrypted files. A strong password policy will reduce the risk that passwordswill be cracked.

Protect EFS Files in TransportEFS is a file encryption driver that is available as part of NTFS. Normal file transferfrom the local computer to a share on a network server does not transfer the encryptedfile; instead, it decrypts the file, copies it across the network in clear text, and then re-encrypts it. Use IPSec to establish protected communications between client and fileserver. Alternatively, any encrypted transport could be used. SSL or VPNs can beused to protect the transfer of files. IPSec, SSL, and VPNs are described in Chapter 11.

Windows XP and Windows Server 2003 EFS-encrypted files can also be transportedto a web server using WebDAV. When WebDAV is used, the EFS files will remainencrypted during transport.

Backup KeysWhen a user encrypts her first file, a self-signed certificate and matching private keyare automatically created. The certificate binds the user’s account to the public/privatekey pair. The public key is used to encrypt the secret key created by the OS to encrypta file. The private key is necessary in order to decrypt the secret key, which then canbe used to decrypt the file. If the private key is missing or damaged, the file cannot bedecrypted. To ensure that the key is available, the certificate and key should beexported, or backed up. This is a simple process:

1. Add the certificates template to an MMC console.





2. Expand the Certificates file via Certificates | Current User | Personal asshown here:

3. In the details pane, right-click the Encrypting File System certificate and selectAll Tasks and then Export.

4. Click Next on the welcome screen.

5. Click Yes, Export the Private Key, and then click Next.

6. Leave the settings at Personal Information Exchange –PKCS #12 (.PFX) andEnable Strong Protection (Requires IE 5.0, NT 4.0 SP4 or Above) as shown here,then click Next:

P:\010Comp\Hard\354-1\ch10.vpMonday, April 19, 2004 1:20:26 PM


7. Enter and confirm a password and then click Next.

8. Browse to a location (a floppy disk is good) and name the file; then click Next.

9. Click Finish.

If the certificate and key are available, and if Encrypted Files are backed up, filescan be recovered from a different computer using a different user account by importingthe keys into the Certificates store of the new account. Backing up the keys is the firststep. (However, the password should be strong and kept separately from the floppy.)Anyone who knows the password and possesses the floppy disk can import the keysand open the EFS-encrypted files the keys were used to protect.

Manage EFS by Implementing PKIEFS certificates and associated private keys are self-signed. That is, they are not issuedby a certification authority (CA). There is no way to manage them, certificates cannot berevoked, and recovery is based on certificates autogenerated for administrators. The bestand most secure way to implement EFS is to implement PKI. In a domain, certificates arebound to user accounts in the Active Directory. Certificates can be revoked. Recoveryagent certificates can be issued to nonadministrative users, and a carefully designedrecovery program established. With Windows Server 2003, another benefit is keyarchival. If a PKI is established, a key archival database can be configured and keyrecovery agents established. With key archival, if a user’s keys are lost or damaged, abackup copy of the keys can be recovered by the recovery agent. In this scenario, therecovery agent has no access to the EFS-encrypted files. PKI is discussed in Chapter 12.

Train Users and AdministratorsThe most important aspect of a secure and sound EFS implementation is user andadministrator training. When proper EFS procedures are implemented and userstrained, EFS encryption can become a premier methodology for protecting sensitiveinformation. Without training, EFS may prove to be false security.

Provide Protection for Mobile Users of EFSLaptop user data is especially at risk. EFS can provide solid protection if precautionsare taken. Users must understand the risks. If laptops are stolen, a successful passwordcracking attack will provide the attacker with access to EFS-encrypted files if the user’sEFS private key is located on the laptop. Best practices require the user to export thecertificate and private key before traveling with the laptop. When exporting thecertificate and private key, the user should click Delete the Private Key if the Export IsSuccessful as shown in Figure 10-6. If the keys are exported to a floppy disk, the usershould make a copy to leave behind in a safe place and travel with the floppy. However,the floppy should be kept separately from the laptop so that if the laptop is stolen, thekeys are not lost as well. By traveling with the keys, the user can open encrypted files byimporting the keys. Care should be taken to export and remove the private keys whenthe user is done with them.





Manage EFS Encryption AlgorithmsTable 10-6 lists the default and possible EFS encryption algorithms for Windows OSs. Ifa file is encrypted with one algorithm, it must be decrypted using the same algorithm.Care should be taken to not attempt decryption with a different algorithm, as might beattempted if files are moved to different OSs. This many damage the file and will neverresult in file decryption. If users must move from system to system, a registry key maybe used to force EFS on Windows Server 2003 or Windows XP SP1 to use a specificalgorithm. To do so, add the REG_DWORD value Algorithm_ID to the registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS

Use the values for Algorithm_ID shown in Table 10-6.



Figure 10-6. Remember to delete the private key.

Algorithm Algorithm_ID Value Compatible With

3DES ox6603 Windows XP and Windows Server 2003

DESX ox6604 Windows 2000, Windows XP, and Windows Server 2003

AES_256 ox6610 Windows XP SP1 and above and Windows Server 2003

Table 10-6. EFS Encryption Algorithms per OS

