In Windows 2000, Microsoft introduced Encrypted File System (EFS) – a new feature built into the operating system that makes securing user files much better than just file system permissions that have been available on NTFS partitions in previous versions of Windows.
The main reason for this enhancement is that NTFS security can be easily circumvented once an attacker gains physical access to the computer. A number of readily available third-party tools can be used to provide read and write access to data stored on NTFS partitions by circumventing protection provided by the operating system. Once the system is booted from a floppy containing the third-party NTFS driver, the disk and all of its data becomes easily accessible.
Although you can password protect the BIOS and restrict which devices are bootable, this still does not prevent someone from removing the hard drive, attaching it to another computer, and accessing it via another Windows 2000/XP installation or installing another instance of Windows altogether. Fortunately, EFS can help provide privacy of your data in such scenarios.
EFS uses the combination of symmetrical and public/private key encryption to secure content designated by the user in files residing on NTFS partitions. The symmetrical key (created dynamically at the time of encryption and different for each encrypted file) is used to perform the encryption process and is stored together with the encrypted file. The public key is used for encryption of the symmetrical key and is also stored along with the encrypted file. The private key, necessary for decryption, resides within the user profile. This way the information stored on the hard drive, although still accessible via third-party utilities, is in an unreadable format and therefore useless without the private key.
There are, however, still some possible security issues with the EFS that users should be aware of:
· Encrypted files are accessible to anyone who possesses a private key, which is used to retrieve the symmetrical key encrypted with a public key (from the same key pair that the private key belongs to). This applies to the user who encrypted these files and to another Windows account, designated as Data Recovery Agent (DRA). By default, on Windows 2000, this is the Administrator account (local Administrator on stand-alone systems and domain Administrator in the domain). Since it is possible to use third-party tools to reset the password of the local Administrator or any other local account (providing physical access to the target computer is available), stand-alone systems are inherently insecure.
· While in the Windows 2000 domain environment, resetting the local Administrator password will not impact the security of the computer’s local files protected by EFS; however, the users’ private keys might be compromised as long as they are available on the local computer. Since environments in which EFS is implemented typically rely on roaming profiles (this ensures that the same private key is used across all encrypted files for the same user), the user profile is copied to the local system during every login. To ensure that attackers will not be able to take advantage of copies of private keys stored in these profiles, you should use Group Policy to force the removal of roaming profiles at logoff. You should also designate a dedicated Disaster Recovery Agent account and ensure that its private key has been backed up and stored in a safe location.
Both problems described above have been eliminated on Windows XP Professional systems due to two changes to the EFS implementation:
· There is no longer default DRA. Also, unlike in Windows 2000, DRA is no longer necessary for the EFS to function. Administrators of Windows 2000 environments should keep this in mind. It was possible to prevent encryption the Windows 2000 domain environment on the domain level by initializing Empty Policy for Encrypted Data Recovery Agents. This was done by launching a Group Policy MMC snap-in, selecting group policy object linked to your domain, drilling down to Computer Configuration->Windows Settings->Security Settings->Public Key Policies->Encrypted Data Recovery Agents, right clicking on the last-level folder labeled Encrypted Data Recovery Agents, and selecting Initialize Empty Policy from the context-sensitive menu. This was sufficient to remove the capability to use EFS from users on any Windows 2000 system that is a member of the domain.
With Windows XP, this is no longer possible. To disable EFS on the domain level in an environment where Windows XP computers are used, you must launch Microsoft Management Console from a Windows XP Professional computer that was a member of the domain, load Group Policy Editor, and set the focus to the domain Group Policy object. Once the snap-in is loaded, drill down to Computer Configuration->Windows Settings->Security Settings->Public Key Policies->Encrypting File System folder, right click on it, and select Properties from the context-sensitive menu. After the dialog box with a single checkbox “Allow users to encrypt files using Encrypting File System (EFS)” is displayed, make sure that you clear the checkbox (which is checked on by default).
· EFS introduces another additional level of encryption, which utilizes the user’s password to secure the private key residing in user’s profile. On the one hand, this prevents a situation in which an attacker resets the password on any local account in an attempt to gain access to EFS encrypted files (since once the password is reset, the private key stored in the profile can no longer be used). On the other, it creates a problem if users forget their passwords (hence the need to ensure password recovery by using Password Recovery disk).
As you can see, a number of considerations must be kept in mind when deploying EFS in a Windows 2000/XP Professional environment. Increased security has its price in terms of administrative overhead, but it is well worth the extra effort in the long run.
Pre-Installation Preparation
1. Secure hardware. Is the location of the test network sufficiently physically secure so that additional security isn’t necessary? Consider adding physical locks and/or establishing smart card or biometric authentication once the system is installed.
2. Configure hardware and BIOS. Remove the floppy drive. (After installation, consider removing the CD ROM.) Reducing the attack surface of systems is always a sound principle. Remove unnecessary physical ports, if possible, or disable them in the BIOS. Ensure that the system isn’t accessible by other machines on the test network unless an installation server is in use. Disconnect the test network from the Internet and add sufficient internal drives so that appropriate installation of components to separate drives is possible. Consider a BIOS password for this computer.
Installation
This list isn’t a step-by-step how-to for installing Windows Server 2003. Rather, it’s a list of points during installation when you must make security choices.
1. Note the license agreement. Significant changes include statements on digital rights management technology (MS DRM) for securing digital content. They imply Microsoft’s right to access this system to update the technology. Any access to the DC from outside your organization should be, at a minimum, scrutinized. Forward the license agreement to your legal team.
2. Rename the system folder. Default names for system folders are known by attackers. While it’s easy to discover which folder is the system folder, many attack scripts are simplistic and hard-code the name of the “Windows” folder. Renaming the folder foils those scripts.
3. Don’t check the box that includes support for East Asian language (unless, of course, you need this in your environment) on this server. I know of no vulnerabilities that this might introduce, but the less code running on the system, the fewer the opportunities for later exploitation.
4. Uncheck “Yes, download updated setup files.” Instead, check “No, skip this step and continue installation.” If you don’t, your system will attempt to access Microsoft across the Internet to locate updated files. What is Microsoft thinking? Any system is vulnerable during installation and shouldn’t be exposed to the Internet.
5. Partition drives and format with NTFS. Period. There’s no reason to use anything else. You can’t secure FAT drives or promote this system to a DC without an NTFS partition.
6. Select a computer name that doesn’t reveal the computer role of this system. Do not, for example, name it “DC1.”
7. Enter a strong password for the Administrator account and write it down. While it’s true that you should memorize passwords and not write them where others may find them, it’s equally true that, during an installation, it’s easy to forget that password. Write it down and keep it safe until you’ve memorized it, changed it, or replaced it with other technology. Note that Windows 2003 tries to help you here, supplying a warning if you attempt to use blank passwords, common words or passwords that don’t meet complexity requirements.
8. Configure custom network settings. All DCs should have static addresses; set them now. Also, set gateway and DNS server addresses. If the first DC will also be a DNS server, point the server to itself. You’ll find error messages in the log until you add the DNS service, but you won’t forget this basic step when you promote the server to a DC. Disable NetBIOS over TCP/IP if no pre-Windows 2000 computer needs to communicate with this server.
9. Install the server in a workgroup and rename the workgroup. You’re just adding a little obscurity.
Server-to-DC Promotion
1. Use some time to examine the environment between installation and the selection of the DC role. There are several steps you can take to lock down the system. While you may want to do these after DC promotion, spend time examining them now, with this first system. Promoting a server to a DC changes some settings and you’ll want to know both the default server and basic DC environments.
2. Note which services are disabled by default and which aren’t. Can you disable additional services without preventing promotion? Which are they? Windows 2003 is an interim OS. While it doesn’t completely fulfill the Trustworthy Computing mandate, it’s a step along the way. One security feature is that many services are disabled by default or, like IIS, not installed at all. A future column will detail what services are used for and what happens when they’re disabled, as well as offer advice on when to disable them.
3. Open the System applet in Control Panel and, on the Update tab, uncheck “Keep my computer up to date” (Figure 1). You should be managing system updates on DCs, if not all systems, in some other manner. You don’t want to risk instability or compromise because you’re unaware of code changes on key systems. Updates need to be tested and don’t need to be downloaded individually to each machine. To do so is an incredible waste of resources and a potential source of instability.
4. Also in the system applet, but on the Remote Access tab, make sure the Remote Assistance and Remote Access check boxes are blank. After setup is complete, configure and secure remote access for administration and use Group Policy to establish a remote access/assistance policy for the domain. For now, you want to ensure that no extraneous access to the system is possible.
Note: You may recall that the ability for an ordinary user to provide remote assistance was first provided in Windows XP. All a user has to do is send out an invitation via e-mail or instant messenger, and another user can remotely connect. With the original user’s permission, this person can make changes to the user’s machine. The issue, of course, is that you want to manage any access to systems. The innocent request for help using remote assistance can open any computer on your network to penetration from less-than-friendly sources. It’s got no place on your first DC of the forest.
5. There’s an improved interface to the Managing Your Server applet (Figure 2). The concept of assigning roles to computers and securing them with attention to their roles isn’t new. What is new are the extensive documentation, step-by-step details and security references available through this interface. In these days of reduced training and travel budgets, you’ve got a whole course of securing your Windows 2003 network right on the desktop. Take advantage of it. Just think of it: If every one of you reads and takes this information to heart, your network will be safer-and so will the entire Internet.
6. Start your studies by examining the DC role. Don’t forget to review the “Next Steps” (things you do after you bring up the DC), which outlines many helpful security plans and tasks. Use the “Manage Your Server” applet to apply the server role to the DC. When you select “Domain Controller” as this computer’s role, promotion will include an option to select a DNS server on your network or to install the service on this DC. I recommend the latter option, as you can then secure DNS information as part of your DC strategy.
7. Select an appropriate DNS name for the domain. If policy doesn’t dictate and you’re selecting a domain name that won’t be registered on the Internet, be sure to use the correct format. Don’t use a name that lacks a period, as additional configuration is necessary. You may not only find that this is difficult, but it’ll hamper your attempts to apply domain-wide security. If computers can’t locate and connect to DCs, Group Policy can’t be replicated and security settings won’t be applied.
8. Store the Active Directory database (%system folder%NTDS) on a different drive than the logs (logNDS). This will improve performance and make recovery easier.
9. Select compatibility mode as Win2K and higher. If the compatibility with legacy systems mode is selected, security is relaxed on the system; this includes anonymous access to shares.
10. Set a strong Directory Services Restore Mode Administrator password and make it different from the Domain Administrator password. These accounts are different. Only the Directory Services Restore Mode account can be used to restore a System State backup. By giving these accounts different passwords, you can separate duties-always a good security idea. Be sure to write down and store the password in a secure place. The need for it may be long after the person who installs this server has left the company.
Post-Installation
1. Ensure access to a timeserver. By default, the system is pointed to time.windows.com; but after you promote this machine to be the first DC in the root domain, it becomes the time source for all computers in the forest. You should set it to synchronize with a reliable time source.
2. Check DNS. Specifically, look for error messages that registration didn’t occur and check the DNS server for evidence of the proper addition of all entries for this DC. Remember, problems with DNS can mean that carefully constructed security settings are never applied.
3. Review default security settings. For example, note that an Audit policy is set. This is excellent. Figure 3 displays the default settings. Note, however, that items are turned on for success only. You may want to revise these policies to record failure events, too. The default settings are a welcome change!
4. Disable EFS. By now, you should be aware of the need to educate all users before EFS usage is allowed, as well as establish recovery methods. Window 2003 offers key recovery in addition to file recovery, but both these solutions must be thoroughly understood and require configuration and training. Disable EFS until your policy and solution are in place by unchecking the “Allow Users to Encrypt Files using the Encrypting File System” check box on the Property page of the Public Key Policy in the Security settings of the Default Domain Security Policy.
This is different than the procedure followed for Win2K. Figure 4 shows this dialog box. In the background, you can see the recovery certificate for the domain. There’s no need to remove this certificate to disable EFS. Windows 2003 doesn’t need to have a Recovery Agent certificate to use EFS but one is provided by default, and files encrypted on computers in the domain use this certificate.
5. Examine use of the Everyone group in User Rights. While Windows 2003 doesn’t include the anonymous SID in the Everyone group, you should still refrain from using this group where possible. Be careful! Removing this group without understanding that groups need to be added to provide appropriate access can be disastrous. Consider that Everyone includes the operating system. You don’t want to remove permissions for the operating system.
6. Note the default application of communications security in Security Options. SMB message signing and banning the use of LAN Manager does much to secure network communications between Windows computers but also prevents some legacy systems from communicating at all. Others need configuration to do so.
7. Secure Remote Desktop for Administrators by using Group Policy.
8. Remove the Administrator account from membership in Schema Admins. If modification of the Schema is necessary, it can be added back in. By removing the account now, you make the review of these types of modifications more likely, because no one can simply install an application that will modify the schema by accident.
9. Develop and implement a comprehensive baseline security for DCs.
References
Adi Shamir, Eran Tromer, “On the cost of factoring RSA-1024”, RSA CryptoBytes. Vol.6, No.2, 10-19, 2003
A.J.Menezes, P.C. Van Oorschot, and S.A.Vanstone, “Handbook of Applied Cryptology”, Chapters 3.2.6-3.2.7, pp.95-98, 1997
Arjen K. Lenstra, Adi Shamir, “Analysis and optimization of the TWINKLE factoring device”, Proc. Euro-crypt 2002, LNCS 1807 35-52, Springer-Verlag, 2000
Arjen K. Lenstra, Adi Shamir, Jim Tomlinson, Eran Tromer, “Analysis of Bernstein’s Factorization Circuit”, Proc. Asiacrypt 2002, LNCS 2501, 1-26, Springer-Verlag, 2002
Daniel J. Bernstein, “Circuits For Integer Factorization: A Proposal”, NSF DMS, 2001
“Factoring Large Numbers: Fun or Applied Science?”, http://www.cwi.nl/publications/annualreports/1999/AR/PDF/factoring.pdf
Sashisu Bajracharya and Han Sang, “Comparison of Factorization Algorithms for Large Numbers – Project Specification”, 2004
