| CHAPTER |
|
| 22 |
Windows Security |
| |
|
The best practices used to secure a Windows system are generally similar to those applied to other operating systems, such as Unix (as described in the previous chapter)—reduce the attack surface, run security software, apply vendor security updates, separate systems based on risk, perform strong authentication, and control administrator privileges. Out of the box, Windows contains many vulnerabilities that leave it open to attack, but those vulnerabilities can be reduced in a number of ways. Whether a server or a workstation, the approach is the same. By following the procedures described in this chapter, you can make Windows much more resistant to attack.
Securing Windows Systems
The following practices provide the most significant improvements to Windows security.
• Disable unneeded services and remove unnecessary software to reduce the attack surface.
• Configure secure settings on remaining software.
• Install additional security-specific software.
• Patch systems regularly and quickly.
• Segment the network into zones of trust and place Windows systems into those zones based on their communication needs and Internet exposure.
• Strengthen authentication processes.
• Limit the number (and privileges) of administrators.
Turning off unnecessary software components and securely configuring those that remain is the first and most important step in locking down a Windows installation (or any operating system platform, for that matter). This is known as hardening the system. It changes the computer from being a well-known target that attackers could easily break into to being a system that is able to defend itself.
Some estimates say a Windows system can survive unprotected on the Internet with an out-of-the-box configuration for only 20 minutes. After that, malware and hackers will have discovered enough well-known vulnerabilities to take control of the system. By hardening the system, you make the attacker’s job more difficult (or preferably, impossible) by removing the most common flaws they know how to exploit.
Hardening the system also has a fringe benefit—a computer that runs less software runs faster. Therefore, by turning off services and removing unneeded software, you’ll also speed up your system. You get security and performance improvement at the same time.
Disable Windows Services and Remove Software
The first thing you should do to secure any computer is to disable or delete software components that aren’t going to be used. Why patch, configure, and secure software that you’ll never use? Just get rid of it, and you’ll not only save yourself work, you’ll also make an attacker’s job harder by cutting down on the overall number of vulnerabilities that they can exploit. This is known as reducing the attack surface.
Don’t Install IIS
Microsoft’s Internet Information Services (IIS) contains many vulnerabilities that are exploitable over the network. In order to reduce vulnerabilities, unless you are building a web server, do not install IIS.
Although modern versions of Windows no longer install IIS by default, many third-party applications ask for it to be installed. Be aware of the applications that your users are employing and determine whether they are installing IIS. If they are, plan for additional layers of protection for those systems.
Do Not Configure Non–File Servers to Use File and Printer Sharing
Desktop systems do not need to share folders on the network. A simple network configuration turns off the ability to do so. If the configuration is not set, shares cannot be created. Servers that are not file servers, or that do not run applications requiring file and printer sharing, should also have the option turned off.
Remove Software You Don’t Need
Remove the following items from the Taskbar and Start menu and remove any associated software components:
• Address Book
• WordPad
• Tour Windows XP
• Synchronize
• NetMeeting
• Program Compatibility Wizard
• Windows Movie Maker
• Remote Assistance (unless you’re planning to use it for support)
• Games
Use Add/Remove Windows Components to uninstall the following:
• Character Map
• Mouse Pointers
• Document templates
• Windows Media Player
• Windows Messenger
• Outlook Express
• MSN Explorer
You should also disable Remote Desktop in System Properties unless you plan to use it for support, and disable startup and shutdown sounds.
Disable Windows Services That Are Unnecessary
The best way to turn off an unwanted service is to set its “Startup Type” to “Disabled.” Other Startup Types aren’t effective at stopping services because applications often start them even when they are set to Manual. Moreover, some services can’t be stopped when they have already started. Thus, setting them to Disabled and rebooting the system is the best way to turn them off.
You can do this within the Services Management interface, services.msc, or within the service security portion of Group Policy Management (computer configuration\window settings\security settings). Another option is to start the Security Templates MMC snap-in, set the Startup Types you want in a security template file, and import that template into a Group Policy Object (GPO).
Before getting rid of all of these, you should test first to make sure that any needed functionality is retained. Look at what each service does, and decide if you need that functionality in your environment before you decide whether to turn it off or keep it. Note that
Table 22-1 is a complete list of Windows services that should be disabled, among the many different versions of Windows. You may not have all these services on your version, so consider only those relevant to you. Out of all the services listed in the table, disable those you find on your system.
Table 22-1 Windows Services to Disable
Securely Configure Remaining Software
Take the following actions on all computers:
• Apply the latest approved service pack and ensure any newly installed software is fully updated with the latest patches.
• Rename the default Administrator account. This way attackers and malware will have a harder time trying to break in. Having to guess the name and password makes their job harder.
• Disable the built-in Guest Account. It’s not needed for anything, and it’s commonly exploited by attackers and malware.
• In Windows Explorer folder options, select Display Full Path in the Title Bar and uncheck Hide Extensions for Known File Types. These settings help the end user confirm that they are working with the correct files and applications. Malware often masquerades as a different file type by exploiting the default settings of these options.
• Set strong permissions on Windows shares. Shares are connection points to Windows file systems and a necessary part of Windows networks. File servers make files and folders available; remote administration and security evaluation products rely on it; and even Windows domain controllers offer this service so users can connect and authenticate to the domain. The default permissions on shares in Windows 2000 and earlier systems is, however, Everyone – Full Control. (Windows Server 2003’s default is Everyone – Read.) Full Control means that unless folder and file permissions are set appropriately, anyone who can connect to the server share can do as they please. Although many systems are protected by excellent permission settings on files and folders, why not provide defense in depth?
• Eliminate or reduce anonymous access. Anonymous access is when a connection can be made to a Windows system without using a user ID and password. And unfortunately, it’s all too easy to enable. Strong permission settings on Windows shares and file folders and files mitigate the effectiveness of such anonymous access, but it’s still possible to gain information about Windows accounts, privileges, and policy settings. Note, too, that in Windows 2000 and earlier, if you connected anonymously, you gained any privilege or permission of access granted to the group Everyone. (In Windows Server 2003 and higher, this is no longer the case.) The best approach is to prevent anonymous connections in general, or reduce access to specific paths. You can make the appropriate settings in the Security Options section of Local Security Policy or in Group Policy. You should realize, however, that some applications require anonymous access, and, therefore, you cannot simply eliminate this feature, nor constrain it, without some testing.
Use Group Policy to Manage Settings
The following Group Policy settings enforce more secure network behaviors across all computers in the domain where the GPO is applied. These settings are recommended for all environments to improve the level of security of Windows systems on the network. You should also go through the entire list of Group Policy settings on your version of Windows to see if there are other settings applicable to your environment, and enforce them across the domain.
Computer Policies
These policies apply to the entire computer, regardless of which user is logged in to it.
Computer Policy: Network\DNS Client—Update Security Level (Enabled, Only Secure) The 2003 version of Microsoft Windows supports secure DNS updates, which allow automatic updates to DNS to be done securely, with authentication and encryption. This prevents unauthorized tampering with DNS, which is required to protect the integrity of DNS information.
Computer Policy: Network\Network Connections—Prohibit Use of Internet Connection Sharing on Your DNS Domain Network (Enabled) Internet Connection Sharing allows end users to connect their home Internet connections, or other untrusted network connections, to the network. This routing of network connections is a risk to the network and should be blocked.
Computer Policy: Network\Network Connections—Prohibit Installation and Configuration of Network Bridge on Your DNS Domain Network (Enabled) Network Bridge allows end users to connect their home Internet connections, or other untrusted network connections, to the network. This bridging of network connections is a risk to the network and needs to be prohibited.
Computer Policy: System—Restrict Potentially Unsafe HTML Help Functions to Specified Folders (Enabled) Many viruses and network worms exploit the unsecure code used in HTML help, which can execute programs on the local system. Restricting this feature reduces the scope of damage that can be caused by hostile software or attackers.
Computer Policy: System\Error Reporting—Display Error Notification (Disabled)
Computer Policy: System\Error Reporting—Report Errors (Disabled) This feature prevents workstations from reporting information about errors directly back to Microsoft.
Computer Policy: System\Remote Assistance—Solicited Remote Assistance (Enabled)
Computer Policy: System\Remote Assistance—Offer Remote Assistance (Disabled) Newer versions of Windows have a Remote Assistance feature that can either be solicited or offered. If offered, unauthorized individuals may be able to gain access to end-user systems by tricking them into accepting offered assistance. Soliciting assistance puts the responsibility of asking for help on the end user.
Computer Policy: System\System Restore—Turn Off System Restore (Enabled) System Restore sounded good when it was first introduced, providing automatic restoration of system files in the event of corruption. But malware writers quickly discovered that System Restore provides an easy way to reinfect Windows systems after a virus, Trojan, or worm has been cleaned. Malware plants itself in the files stored under System Restore, so it can be reinstalled automatically by the system. For this reason, System Restore is dangerous and should be avoided.
Computer Policy: Windows Components\Internet Explorer—Security Zones: Do Not Allow Users to Change Policies (Enabled)
Computer Policy: Windows Components\Internet Explorer—Security Zones: Do Not Allow Users to Add/Delete Sites (Enabled) You would use these settings on a domain where security zones are enforced by IT.
Computer Policy: Windows Components\Internet Information Services—Prevent IIS Installation (Enabled) This setting prevents Internet Information Services (IIS) from being installed. IIS has a high attack surface and should not be used except in protected security zones.
Computer Policy: Windows Components\Task Scheduler—Hide Property Pages (Enabled)
Computer Policy: Windows Components\Task Scheduler—Prevent Task Run or End (Enabled) Scheduled Tasks on a Windows system is a security risk and should be disabled. This feature can be used to run unauthorized software by remote attackers or by worms and viruses.
User Policies
These policies apply to all users in the container to which they are applied. Different groups of users can have different policies that apply when using the same workstation.
User Policy: Control Panel\Display—Screen Saver (Enabled)
User Policy: Control Panel\Display—Screen Saver Executable Name (Enabled)
User Policy: Control Panel\Display—Password Protect the Screen Saver (Enabled)
User Policy: Control Panel\Display—Screen Saver Timeout (5–15 minutes) Screensaver controls are important for two reasons. First, a locking screensaver is required to prevent unauthorized access to network resources from a legitimate user’s account when that user walks away from their workstation. Second, screensaver programs that end users download from the Internet are commonly infested with viruses and should be controlled.
User Policy: Desktop—Prohibit User from Changing My Documents Path (Enabled) Files that end users work with may contain confidential data. This data should be centrally controlled and managed.
User Policy: Desktop\Active Desktop—Disable Active Desktop (Enabled) Unnecessary components of the Windows desktop that may be at risk of exploitation by viruses and worms should be disabled.
User Policy: Network\Offline Files—Remove “Make Available Offline” (Enabled)
User Policy: Network\Offline Files—Prevent Use of Offline Files Folder (Enabled) Offline files may allow end users to copy or expose confidential information outside of the network.
User Policy: Shared Folders—Allow Shared Folders to Be Published (Disabled)
User Policy: Shared Folders—Allow DFS Roots to Be Published (Disabled) End users may work with many files that contain confidential data. This data should be centrally controlled and managed. Confidential data should not be shared directly from shared folders on end-user systems. Additionally, shared folders are commonly exploited by viruses and worms and should be avoided.
User Policy: System—Prevent Access to Registry Editing Tools (Enabled) End users should not be able to make changes to their software image and settings. The Windows registry editor Regedit.exe should only be used by experienced administrators under an approved, managed change process.
User Policy: System\Logon—Do Not Process the Legacy Run List (Enabled) Most viruses and network worms install programs that are invoked in the run and run-once lists. Restricting this feature reduces the scope of damage that can be caused by hostile software or attackers.
User Policy: Windows Components\Internet Explorer—Disable Internet Connection Wizard (Enabled)
User Policy: Windows Components\Internet Explorer—Disable Changing Connection Settings (Enabled) End users should not be able to change their network settings. This function should be centrally managed by IT.
User Policy: Windows Components\NetMeeting—Prevent Sending Files (Enabled)
User Policy: Windows Components\NetMeeting—Prevent Receiving Files (Enabled) Confidential data should not be shared directly from messaging clients on end-user systems. Additionally, files shared by chat clients are commonly exploited by viruses and worms and should be avoided.
User Policy: Windows Components\NetMeeting\Application Sharing—Disable Application Sharing (Enabled)
User Policy: Windows Components\NetMeeting\Application Sharing—Prevent Desktop Sharing (Enabled)
User Policy: Windows Components\NetMeeting\Application Sharing—Prevent Sharing Command Prompts (Enabled)
User Policy: Windows Components\NetMeeting\Application Sharing—Prevent Sharing Explorer Windows (Enabled)
User Policy: Windows Components\NetMeeting\Application Sharing—Prevent Control (Enabled) End users should not share applications from their desktops or allow remote control of their computer through NetMeeting. These settings prevent users from sharing anything themselves. They will still be able to view shared applications/desktops from other users.
User Policy: Windows Components\Task Scheduler—Prohibit Drag-and-Drop (Enabled)
User Policy: Windows Components\Task Scheduler—Prohibit New Task Creation
User Policy: Windows Components\Task Scheduler—Prohibit Task Deletion (Enabled)
User Policy: Windows Components\Task Scheduler—Hide Advanced Properties Checkbox in Add Scheduled Task Wizard (Enabled)
User Policy: Windows Components\Task Scheduler—Prohibit Browse (Enabled) Scheduled Tasks on a Windows system is a security risk and should be disabled. This feature can be used to run unauthorized software by remote attackers or by worms and viruses.
User Policy: Windows Components\Windows Explorer—No Computers Near Me in My Network Places (Enabled) End users should not be able to browse to each other’s computers on the network.
User Policy: Windows Components\Windows Explorer—No Entire Network in My Network Places (Enabled) Prevents users from trying to browse computers and network resources that are outside of the domain.
User Policy: Windows Components\Windows Explorer—Remove CD Burning Features (Enabled) Many files that end users work with contain confidential data. This data should be centrally controlled and managed. End users should not be able to write customer data to nonvolatile data storage. This type of storage lasts for years and may inadvertently expose confidential information in future years.
User Policy: Windows Components\Windows Media Player—Prevent CD and DVD Media Information Retrieval (Enabled) Workstations should not collect information directly from the Internet.
User Policy: Windows Components\Windows Messenger—Do Not Automatically Start Windows Messenger Initially (Enabled) Windows Messenger is automatically loaded and running when a user logs on to a Windows computer. If you don’t want to use Windows Messenger, you can turn off the automatic start with this setting.
Security Configuration and Analysis
When you think of hardening a system, do you imagine having to make individual changes to change default settings? Or do you imagine writing scripts that will repeat the process on as many machines as you care to run it on? If you want to automate as much as possible, you have options.
Legacy Windows
Windows NT 4.0 security required a lot of configuration using multiple security tools: User Manager, Server Manager, Control Panel, Windows Explorer, regedt32—lots of data, lots of activity. Fortunately, everything that you can do in a Windows NT 4.0 GUI, you can do by directly editing the registry. Editing the registry may not be a good idea, as a simple error can render the system unusable. Scripts, written and tested on test machines, can, however, provide an acceptable alternative, and simple security configuration as well as complex or obscure registry entries can be automatically performed.
In addition, System Policy is a GUI-based tool that allows the administrator to configure multiple security settings for users, groups, and individual computers and also configure system settings such as screensavers. The policy file, ntconfig.pol, is placed at the netlogon share and downloaded and applied by Windows NT. A version of the tool exists that you can use to configure security, such as it is, and other features for Windows 98. The Windows 98 policy file, config.pol, is also placed in the netlogon share and downloaded by Windows 98 when users log on from a Windows 98 computer. System policies are customizable—anything that can be done with a registry entry can be done with a System Policy file. There is one drawback: registry entries made via System Policy are permanent. If the policy file is removed from the netlogon share, the registry changes remain on the clients. Create a bad system policy, and you must create a good one to counter it, or directly edit the computer’s registry.
Windows 2000 Through Windows Server 2008 R2
Two tools can be used together to flexibly and automatically configure security for the standalone Windows XP Professional, Windows Server 2003, or Windows Server 2008 computer. (By stand-alone, we mean the computer is not a domain member, not that it is not part of a network.) Security Templates and Security Configuration and Analysis provide the answer to the question: how do I quickly apply a security configuration, maintain it, transfer it to another computer, and analyze either its impact or the current computer’s compliance with an existing security policy?
Security Templates Security Templates are simply configuration files that provide settings (or mark them “undefined”) for major security configuration choices. You use the Security Templates console to copy default templates, modify settings, and create your own templates. Microsoft provides the default templates and additional downloadable ones. Many other templates are provided free of charge by various third-party organizations. Any template can be used by the Security Configuration and Analysis Console to apply a security configuration to a computer.
The configuration choices exposed in a template include the following:
• Account policies Password Policy, Account Lockout Policy, and, for domain controllers, Kerberos Policy
• Local policies Audit Policy, Security Options (registry settings that harden the system), User Rights
• Event log Configure event log size and retention methods
• Restricted groups Restrict group membership
• System services Set service startup or disable services; also, specify who can start and stop them
• Registry Permission settings on registry keys
• File system Permission settings on files and folders
Security Configuration and Analysis Note that security templates only contain settings that can be applied to change certain configuration options. Modifying these settings has no effect on any computer’s security. You have to apply the template to change security. Security Configuration and Analysis is the tool you can use to do this. This MMC snap-in provides the ability to load any template into its database and then either “apply” the security configuration to the local computer or compare the database settings with the actual settings on the local machine.
A command-line tool included with Windows, secedit, can also be used to analyze or configure the machine. Used in a batch file, you can schedule secedit to reapply security periodically to a system, or even to apply diverse templates to diverse machines. Logs record secedit and Security Configuration and Analysis activity. Administrators can use these tools to apply and audit security; auditors often use them to determine security compliance.
Group Policy
Writing scripts to apply templates is easier than individually configuring thousands of computers, but it is not really the most efficient method for managing settings on a large scale. That’s why Microsoft provides Group Policy. Group Policy can be used to set literally hundreds of security and general administrative settings for diverse machines and users. Individually crafted Group Policy Objects (GPOs) can be defined and, when linked to containers in the Active Directory, automatically and periodically apply these settings. Windows Server 2003 introduced the Group Policy Management Console (GPMC), which simplified the management of large numbers of GPOs through consolidated reporting on settings, backups, and restores. Windows Server 2008 introduced Advanced Group Policy Management (AGPM), which turns GPO management into an auditable and delegatable workflow with the ability to separate the functions of GPO creation from GPO approval from GPO linking. It also introduced extremely useful version control with a check-in/ check-out process, and it allows you to revert a GPO quickly to an older “working” state.
Effective Range
GPOs can be linked to the site, domain, and OU objects. Sites represent the physical network by defining the subnetworks that exist at a physical location. They are used to manage replication and to direct local clients to local domain controllers for authentication. GPOs linked to sites can impact every computer and user whose account in Active Directory is located in any domain. If the computer is physically at the site, or if a user logs on from a machine at the site, the GPO will be applied. (There are exceptions to this rule; they are listed in the section “Application and Conflict.”) Domains, of course, are logical collections of computers and users. A GPO linked to a domain object in AD will be applied to every computer and user with an account in the domain. Organizational units (OUs) are subdivisions of domains that can themselves contain user and computer accounts. If a GPO is linked to an OU, its settings apply to those user and computer accounts. OUs can be nested within OUs, and GPOs can be applied to each nested OU. GPOs apply to user and computer accounts within the OU and within an OU nested within it.
Although not a GPO in a strict sense, a Local Group Policy resides on every Windows 2000 and later computer. The Local Group Policy is also applied. Two default GPOs are the Default Domain GPO and the Default Domain Controller GPO. These GPOs set the default security and configuration for the domain.
Application and Conflict
In
Figure 22-1, Fred, a user with an account in the Marketing OU of the domain mydomain.local, who logs on from the computer Computer26, which also has its account in the Marketing domain, will have his security configured by the Local Group Policy, the site GPO, the domain GPO, and the GPO linked to the Marketing OU. The GPOs are applied in that order, in what is called
Group Policy Inheritance (local, site, domain, OU). If a user or computer account is contained in a sub-OU, the GPOs of its parent OU and then of the sub-OU will be applied. Each setting in each GPO is applied to his computer or his account and enables or controls what’s possible for him to access and do. Additional local and network settings add to the security tapestry of Fred’s system, but a large component of security that governs his activity can be found in this combination of GPOs.
Figure 22-1 Group Policy—an example of GPO inheritance
What if there are conflicts between the GPOs? If a conflict exists, the last GPO applied wins, with a few exceptions. First, Domain Password Policy, Account Lockout Policy, and Kerberos Policy are configured in the default domain GPO. If the OU, site, or local GPO indicates something different, that difference will have no impact on Fred when he logs on using his domain account. (Password Policy set in another GPO does set the local computer Password Policy, and this would have an effect on Fred, if he has a local account on the computer and uses it to log on.) Likewise, domain User rights are set in the Default Domain Controller GPO and only this GPO. Although Windows Server 2008 introduced the ability to enforce password policies outside the default domain GPO those password policies are stored in another location.
Additionally, administrators can block GPO inheritance from containers, enforce a GPO’s settings even if it would normally be changed by a GPO applied after it, and use a GPO configuration called loopback to make everyone’s User settings on specific machines the same. These “complications” make tracing the actual implications of settings in GPOs confusing, and best practice dictates that they should rarely be used.
NOTE Group Policy has nothing to do with group membership, and everything to do with where a user’s account, or a computer account, is located. The container within which the account resides, and those that contain this container, are the ones whose linked GPOs affect the user or computer. Security filtering can, however, be used to change this default behavior. The reason a GPO applies to an account within the linked container is that security settings on the container give the “apply to” and “read” permissions to the group Authenticated Users (an implicit group that contains all users currently authenticated to the system). An administrator can remove the permissions and apply them instead to Windows groups. Only the members of these groups, whose accounts reside in the container, will have the GPO applied.
Group Policy Settings
A GPO can be used to set more than security. A GPO can apply the following settings and constructions. GPO capability varies with the operating system, and Microsoft provides a spreadsheet detailing what each setting does and where it can be utilized. This spreadsheet is available at
www.microsoft.com.
• Software settings Software can be installed and uninstalled via this container.
• Scripts Startup, shutdown, logon, and logoff scripts can be applied by placing them in this container.
• Security settings All of the security settings that are in security templates plus those in GPOs reside in this container.
• Wireless Network (IEEE 802.11) policies Wireless network configuration settings (in Windows Server 2003 and XP) can be configured via this container.
• Public Key policies EFS recovery policy and other PKI-related policies can be set via this container.
• Software restriction policies The policies in this container specify what software is allowed and prohibited (in Windows Server 2003 and XP).
• IP security policies on Active Directory This container houses IPSec policies that apply communications security to computers.
• Administrative Templates These templates include hundreds of configuration settings, many of them security related, that can be set via Group Policy.
• Remote Installation Services This container includes settings that control operation of the RIS service.
• Folder Redirection The settings in this container redirect My Documents and others to a specified network location.
• Internet Explorer maintenance This container includes security settings for IE.
When properly designed and implemented, Group Policy can effectively set and maintain security for an entire network of Windows computers. Take care when applying GPOs to the domain level. It is a good practice to reserve this location for GPOs that enforce written policy. The goal of a GPO isn’t to give administrators a giant checklist of things they might like to turn on or off, it’s a mechanism to centrally enforce security policies in an automated fashion.
Evaluating Group Policy, Troubleshooting
Do not underestimate the value of well-designed and well-applied Group Policy, nor should you underestimate the damage that carelessness or misunderstanding can cause. A rogue administrator can use it to their own benefit, and rogue but privileged users can subvert it. Think, for example, of the user who has administrative rights on a computer. When that user logs on locally to the Administrator account, the Group Policy previously applied to the local computer will still control all activities on the computer and on the network, but no new user portion of Group Policy will be applied. Next, if the user removes the computer from domain membership, reboots, and then modifies its security policy, there are no longer any restrictions on what the computer can do. Of course, the user may be limited in the activity that can be performed on the network, but many of these controls can be surmounted as well—for example, since the user has a domain user account and password, that account can be used to access shares on the network and perform other activities. The minute the computer is rejoined to the domain, however, it receives the domain policy for the computer, and the minute the user logs on using the domain account, the computer once again becomes subject to domain Group Policy.
Determining exactly what Group Policy does get applied to a user or computer can also cause some confusion. If a GPO doesn’t seem to be working, how can you tell what’s going on? Is the policy being applied at all? Or is it just not working as you might expect? Are other GPOs, inheritance modifications, or other factors such as DNS or network connectivity the cause? Windows Server 2003 and later versions provide tools that can help. Resultant Set of Policy (RSoP) is a tool that you can use to predict the effects of applying a Group Policy, as well as to actually determine what policies and which parts of them are effective on a specific machine for a specific user. The Group Policy Management Console (GPMC) can be used to examine Group Policy on Windows 2000 through Windows Server 2008 R2 computers. The GPMC provides a way to manage and understand the impact of Group Policy on the network.
Install Security Software
Windows, by itself, is not secure enough to survive all the malware and attack exploits that are rampant on the network. Additional software is required to protect against the most common threats. When choosing third-party security software, look for the following features:
• Full disk encryption
• File encryption
• USB device control and blocking
• Web filtering, site checking, malware blocking, and security
• Anti-malware/antivirus
• Anti-spyware
• Host intrusion prevention system
• Desktop firewall
• Application communication control
• Email filtering/anti-spam/content filtering
Backup software should also be used to provide a way to recover from a serious system corruption, including malware infection. After any significant change, the computer and all its data should be backed up, including all the files needed to boot.
NOTE A note about the browser: I used to say that Internet Explorer was no less secure than any other browser; it was just more widely used and therefore had more known vulnerabilities that attackers could exploit—if you kept it patched, you would be fine. But over the years, I’ve had to change my opinion. I’ve seen too many malware infections that exploited Internet Explorer flaws, even without user intervention. In the old days, we could educate users about the dangers of clicking certain links, but these days, user behavior is not required to infect a system. Poisoned DNS entries, malicious images and web bugs, and ActiveX Trojans are far too plentiful on the Web, and a majority of them take advantage of IE. Thus, I recommend you use a different web browser.
Application Whitelisting
In modern Windows security environments, there has been a shift in thinking from the traditional blacklisting approach to a whitelisting approach. The old method of producing giant lists of “what’s bad” just isn’t a scalable approach any more. Antivirus and anti-malware works this way. They send you an ever-growing list of signatures of known bad things that they block. With whitelists, the approach is “anything I haven’t told you is good is automatically bad.” Administrators can then produce a relatively short list of allowed applications, and anything else, regardless of its intent, is considered bad and not allowed to run. When new legitimate applications are needed, the whitelist is updated and the application is allowed to run. Windows Server 2008 R2 and Windows 7 offer this feature natively through Applocker. Administrators can configure Applocker via GPO to provide a list of what the OS is allowed to run. This list can be based on certificates or on file hashes. In the case of certificate-based rules, entire suites or even software vendors can be whitelisted with a single entry. This approach can be extremely effective as it is not vulnerable to zero-day events that are too new for signatures to be available.
Patch Systems Regularly
All authorities agree that the most important thing that you can do to improve security on the network is to patch systems. Of the compromises for which we know why the attack succeeded, over 90 percent could have been prevented if known vulnerabilities had been mitigated via patches and configuration changes. Worse yet, many of the largest exploits of known vulnerabilities have occurred months after security patches were available.
There are multiple ways to keep Windows systems patched, and many of them can be automated. Options include
• Manual Obtain information on a necessary patch, download the patch, test it, and apply it to relevant systems.
• Windows Update site A free service, the Windows Update site inspects the Windows computer and recommends patches and updates. You can then accept or reject any proffered changes and download and apply those you’ve accepted.
• Automatic Update/Direct with Microsoft Windows XP and later can be configured to periodically connect to Microsoft for inspection and downloading of updates. Systems can be configured to prompt before downloading and prompt before updating.
• Windows Software Update Services (WSUS) A free server application, WSUS can be downloaded from Microsoft. Once installed and configured, the system periodically downloads patches from Microsoft. The administrator has the option to approve or disapprove each patch. Windows systems (Server 2003/Windows XP Professional or higher) can be configured to use the WSUS server and automatically apply approved patches. WSUS also has the ability to produce reports so you can quickly determine if a system is missing a patch or if a patch has failed to reach all systems.
• System Center Configuration Manager (SCCM) with WSUS SCCM is a Microsoft Server product that you purchase separately from Windows operating systems. SCCM provides multiple Windows management services and can now be configured to provide patching services for its clients. Because it is a software distribution tool, it can distribute patches for applications as well as for the operating system. SCCM provides much more robust reporting than WSUS alone and offers a granular system for determining which systems or applications should get what patches.
• Third-party patching products A number of third-party products are available that provide similar services.
Each one of these patching platforms has its strengths and weaknesses. Common complaints are that each is different and it’s hard to know when a system is up to date, that not every Microsoft product is patched (different technologies must be used to keep Microsoft Office patched, for example), and that automated methodologies may break systems if there is a problem with the patch. To determine what type of product to use, you must take into account the availability of products for the OS version you are using, the number of systems to be managed, and the sophistication of your administrators.
Segment the Network into Zones of Trust
Windows computers should be separated from each other based on their function, their sensitivity or criticality, and their exposure to the Internet. You should always assume that Internet-facing systems will eventually be compromised by attackers and limit their access accordingly. If an Internet server were compromised, you should be thinking about what the attacker might attack next from that server. NIST publication SP 800-68 has some recommendations on how to decide which systems should go into differing zones.
Blocking and Filtering Access to Services
Filtering access to services is important. Windows systems provide remote access to data and services via the use of well-known ports. When reviewing open ports on a Windows system, any ports found open should be reviewed to validate that they are legitimately needed.
Mitigating the Effect of Spoofed Ports
The most common ports used on the Internet are TCP 80 and 443, which are HTTP and HTTPS, respectively. These ports are usually allowed through firewalls out to the Internet. Many new services are developed with this in mind and pass through the firewall using TCP ports 443 or 80. Examples include instant messaging, streaming media, and other services. Some services are “port mobile,” which means they will automatically use port 443 or 80 if their native port is closed. And, of course, a Trojan can be designed to listen on any port. Other, specially crafted traffic is designed to look like web traffic and uses these ports to sidestep firewall controls. This means that leaving only port 443 or 80 open is no longer assurance that attacks directed at systems other than web servers will be blocked. Windows systems are no more or less vulnerable here than any others. Mitigation for overuse and misuse of port 443 and 80 consists of implementing these protections:
• Use an application-layer firewall. These firewalls inspect traffic at the application layer and check that characteristics of traffic match those accepted by the application. The packets are dropped if they do not meet application rules.
• Ensure that a port is open only for specific services. This holds for any port, not just port 443 or 80. Utilizing the native firewall in Windows server allows port-specific traffic to only interact with specific executables, exposing only certain services to outside contact.
• Configure Windows systems at the host level with port filtering or IPSec blocking policies that, at the very least, block known troublesome ports. Although determining exactly which ports must be blocked on each class of Windows system is a daunting task, it is well known that port 80, the NetBIOS ports (135, 137, 138, 139, and 445), Telnet, and the SQL server ports are common attack points. There is no reason for any client system to expose these ports for external access, and each server can be configured so that only those services it needs are exposed. Only web servers need port 80; only file servers need the NetBIOS ports; and only SQL servers need the corresponding SQL ports. All other types of servers can block these ports. Doing this is easy for Windows 2003 and later systems and can even be automated via Group Policy (see the previous section “Group Policy”).
Strengthen Authentication Processes
You can do four things to increase the security of authentication. First, improve security on the network by developing a strong password policy and a strong training program that teaches users that they are responsible for creating, using, and protecting strong passwords. Second, and better yet, use some other form of authentication. Third, use additional technology and physical security to protect password databases and authentication material. Fourth and finally, understand that Windows authentication systems are varied, and the need for backward compatibility means less secure authentication may be used even by the most recent version of the operating system. This vulnerability can be addressed, even when earlier versions of Windows operating systems must remain a part of the network.
Require, Promote, and Train Users in Using Strong Passwords
Recognize that your network is only as secure as the least secure part. Users are that least secure part, and anything done to strengthen that part can have an enormous effect on the baseline security of your systems. Develop and ensure users participate in a full-fledged security awareness training program, but seek Windows-specific technical training techniques as well.
Weak passwords are easily guessed and/or cracked. Software exists that can rapidly attack the Windows password database, capture authentication material as it crosses the network, and bombard remote logon software with password guesses. How can these attacks be mitigated?
Cracking Exposed
First, realize that password crackers that are deducing Windows passwords are not decrypting them. These crackers are using some of these multiple attack techniques:
• Dictionary attacks A dictionary, or word list, is used. Each word in the list is encrypted in the same manner that a user password is and then compared to the stored, encrypted passwords. If a match is found, the password is cracked.
• Heuristic attacks Users do similar things when creating passwords. They use common passwords such as “password,” or they use their name or user ID. If asked to use upper-and lowercase letters and numbers, they often use the caps at the beginning of the password and the numbers at the end. A sophisticated attack program also looks for these things.
• Brute-force attacks Each letter, number, and possible character combination is tried, often character by character, in an attempt to deduce the password.
Creating Strong Passwords for Windows Systems
Next, apply this knowledge. Obtain one or more common Windows password-cracking programs and run them on sample databases in which common and uncommon password samples are entered. Trying one out will give you some ideas on useful password creation techniques and point to a technical configuration that can dramatically lessen your system’s vulnerability to attack. You’ll discover the following things:
• By default, the product seeks only to resolve simple password combinations. A more complex password will not be cracked.
• When configured to brute-force all possible combinations, the program will take longer to crack even simple passwords than when it is configured to try simple combinations, such as uppercase letters, lowercase letters, and numbers. If attacking a large database, the attacker might not request all combinations; rather, they might first try the simpler ones. If your passwords are always very complex, the casual attacker may pass you by, and you will still slow down the determined attacker.
• By default, the product attacks the weak LM password hash. Once the weak hash is obtained, the stronger NTLM hash can easily be deduced. (Definitions and more about LM and NTLM are in the later section “Modify Defaults for Windows Authentication Systems.”) Windows systems prior to Windows Server 2003 allow, by default, the use of an LM hash for backward compatibility. An LM hash cannot be longer than 14 characters. If passwords in your database are over 14 characters, by default, they will not be cracked. Group Policy will allow administrators to prevent the use of LM hashes on their network.
• The product can directly crack NTLM password hashes. However, this process takes a much longer time. Even the simple passwords will take a longer time. If you eliminate LM passwords from your systems, you deter many attackers and slow down others. Possibly, by the time the attackers have cracked the passwords, your users will have changed them, and the cracked passwords will not be of any use.
This leads to three conclusions. One, where possible, insist on long passwords. A Windows domain (a logical grouping of computers and users) password policy can be set to require a minimum length password, keep a history of passwords (and not let them be reused), require a password be changed after so many days and not before so many days, and require complex passwords (composed of three out of four things: upper- and lowercase characters, numbers, and special characters). The policy cannot be set to insist on one password length for one group of users and another length for another group; if your organization’s security policy demands this, you will have to find a nontechnical means, or write custom code, to enforce the policy. Two, the more complex a password is, the harder it is to crack. Teach users how to create complex passwords. Third, if LM password hashes can be eliminated from your network, you have gained immense ground in the battle to prevent password cracking.
You’ll also find that the historical method of substituting numbers for letters (as in Pa$$w0rd) is really no different from using a dictionary word. The password cracking tool writers know all about that old chestnut, so they long ago built those substitutions into their word lists. Better ways to create strong (but easy to remember) passwords are listed here, with examples (but don’t use these examples in real-life passwords, since they are written down here for all to see).
• Use the first one or two letters of each word in a phrase, song, or poem you can easily remember. Add a punctuation mark and a number. Thus, “My Dog Has Fleas” can make a password like MyDoHaFl17#.
• Use intentionally misspelled words with a number or punctuation mark in the middle. This can make a password like Coffy&Chocklit.
• Alternate between one consonant and one or two vowels, and include a number and a punctuation mark. This provides a pronounceable nonsense word that you can remember. For example, Menamerskee5.
• Interlace two words or a word and a number (like a year) by alternating characters. Thus, the year 2013 and the word Money combine to become M2o0n1e3y.
• Or, my favorite because it’s easy for me to remember, choose two short words that aren’t necessarily related, and concatenate them together with a punctuation character between them—as in Sweet4Telephone. Better yet, capitalize a different letter like sweEt4telepHone.
You already know that any combination of your name, the names of any family or friends, names of fictional characters, operating system, hostname, phone number, license or social security numbers, any date, any word in the dictionary, passwords of all the same letter, simple patterns on the keyboard, like qwerty, any word spelled backward, or any variation on the words “password” or a company name, make easily guessed passwords, but this bears constant repeating to your user population.
Use Alternatives to Passwords
Passwords are the weakest link in any security system. Despite all your warnings, users share them. They get written down, intercepted over the network, or captured by keyloggers. Ultimately, you can’t rely on the secrecy of passwords. In fact, passwords are really a terrible way to identify someone. What if you could only identify your friends by asking them for a secret word? That’s crazy. In reality, you as a person identify other people by noticing unique characteristics about them. Computers have limitations, but they can do more than simply ask for a shared secret.
By now, we really should be using something other than passwords for authentication. Third-party products are available, and Windows 2003 and later versions have built-in technology to assist in using these technologies. Tokens, biometrics, smart cards, and third-party products can be smoothly integrated into a Windows enterprise. One example is the built-in affinity for smart cards in Windows 2003, Windows XP, and which has only gotten better in newer versions of Windows such as Windows 7 and Windows Server 2008 R2. For example, Windows certificate services are provided as part of the base server product; therefore, a certificate authority (CA) can be installed at no extra cost. Built into the CA are drivers for some common smart card technologies, along with the application programming interfaces (APIs) that enable other third-party smart card manufacturers to develop products that interface in the same way.
Even the ability to work with PINs including offline unblocking is now integrated into the Windows operating system. The actual technical process for implementing the use of commercially available smart cards is very simple. Like all technologies, however, establishing such a public key infrastructure should be carefully planned, implemented, and maintained to ensure proper operation and security. Any security system—any security technology—is subject to attack and is especially vulnerable if not correctly implemented. Smart cards based on the .NET framework are natively supported by current versions of Windows and allow for simplified deployments as no middleware is needed.
Apply Technology and Physical Controls to Protect Access Points
No matter what technical defenses are put into place, if an attacker has physical possession of, or even physical access to, the machine, it is much easier to compromise. Limiting physical access to systems makes an attacker’s job harder.
Chapter 34 covers techniques to accomplish this.
Windows Server 2008 R2 reintroduces the concept of a read-only domain controller (RODC). Administrators who have been around longer will recognize the concept from the Windows NT days when “backup domain controllers” were able to perform authentication but couldn’t initiate changes to objects. RODCs carry the concept further and are designed so they only contain copies of user objects that they’ve authenticated and, even then, user objects can be tagged to never be cached on a given RODC. This means that in locations where physical security isn’t fully trusted, you can deploy an RODC, configuring it to cache only account information for the local users (it will forward authentication to the nearest read-write DC if the account isn’t local). Then, if the box is stolen, your exposure is greatly reduced. By default, the highest privilege accounts can never be cached on an RODC. If an RODC is logically removed from Active Directory, the directory knows the list of all user accounts that were cached on the removed RODC and offers to flag all such accounts to “Must Change Password at Next Logon” to quickly remove the risk of the RODC’s password cache being cracked.
Another area to protect is the transmission of authentication material. Windows domain authentication doesn’t transmit passwords in cleartext over a network; instead, it uses a challenge/response technology. However, some applications (such as Telnet) that require passwords, even Windows passwords, may pass cleartext passwords, and techniques exist for capturing the protected Windows authentication material and cracking it. To mitigate these vulnerabilities, protect the communications process. SSL, for example, can be used to protect the practice of obtaining e-mail via a browser using Microsoft Exchange and Outlook Web Access (OWA). Once configured, the Microsoft Internet Information Server will use SSL, and the entire communication between the client and the IIS server will be encrypted. Communication between systems on a LAN can be protected via Microsoft’s implementation of IP Security (IPSec), which can provide confidentiality (encryption), mutual machine authentication, integrity (to ensure that what is sent is what is received, or else it is dropped), and non-repudiation (to ensure that the communication really did come from the correct machine).
Modify Defaults for Windows Authentication Systems
The network authentication protocol for Windows 95 and Windows 98 was LAN Manager (LM). Windows NT 4.0 preferred NT LAN Manager (NTLM) and could be updated to use NTLMv2. Windows 2000 and later systems joined in a Windows 2000, 2003, or 2008 domain prefer Kerberos. For backward compatibility, Windows NT 4.0 and later, use LM, and Windows 2000 and later use NTLM when Kerberos is unavailable (for example, when there is no domain membership or when an IP address instead of a computer name is used in a mapping to a Windows share).
The authentication protocols range from very weak (LM) to very secure (Kerberos), but the remarkable thing is that there are ways to avoid the use of LM entirely, and to increase the use of NTLMv2 or Kerberos, that are not implemented! Some of the improvements can be gained without product upgrades, but with free client downloads and configuration changes. Doing so does take a commitment in time; however, making these types of changes can do more to secure Windows networks than many other, more expensive and time-consuming security solutions. Here are the techniques that will assist you in this effort:
• Configure legacy systems to use NTLM and/or NTLMv2. First, download the Microsoft Active Directory client and install it, and then make registry configuration changes.
• Configure Windows 2000 and later systems to use NTLM and/or NTLMv2, not LM, when Kerberos cannot be used. (Windows Server 2003, by default, does not accept LM but can be configured to do so—don’t let it be!) These changes can be implemented using Group Policy and automated for large numbers of systems with a few simple keystrokes.
• Configure Windows 2000 and Windows Server 2003 to remove the LM password hash from the password database. This configuration is a registry entry for Windows 2000 and a Group Policy setting for Windows Server 2003 and newer.
• Be sure to test these configuration changes before widely implementing them in your network. Some applications may have a problem, especially with NTLMv2. You may find that you cannot always require the most secure authentication process in all systems; however, this is no reason not to find the systems for which you can provide this security.
• Use computer names when mapping drives (configuring access to Windows Shares); for Windows 2000 and later systems, this means Kerberos will be used.
• Retire legacy operating systems when possible. Not only are they less secure, but there comes a point at which security vulnerabilities will no longer be addressed by the manufacturer. Systems running critical applications or holding sensitive data should never be on unsupported operating systems.
Limit the Number of Administrators and Limit the Privileges of Administrators
The Administrator account, indeed membership in the local Administrators, Domain Admins, and other administrative groups, grants enormous privileges. Windows systems have various default administrative groups built in, and custom groups can be created, which, when privileges are granted to the groups, build new administrative roles. This technique is good to use to limit administrative privileges but it is often not used. It is not unusual to find that the majority of a user population has membership in some administrative group, usually because it makes software easier to run. It is also not unusual to find that all users are members of the local Administrators group on their own desktop or laptop systems. The reasons for the large numbers of administrators, and for little attempt at limiting administrative privileges, are manifold. A few of the more common reasons and ways to deal with them, however, can be addressed.
Individuals should not be given membership in administrative groups unless all other attempts at empowering them to do their jobs are not successful. It should never be necessary to place users or software service accounts in a fully privileged Administrators or Domain Admins group to get them the rights they need. It does require more work though. Here are some common use cases and their solutions.
Applications that Require Admin Access to Files and the Registry
Sometimes applications run fine for administrators, but users can’t run them. File and registry systems in Windows NT and later can be protected by setting permissions on file, folder, and registry keys. Sensitive system files and registry keys are protected from modification by unauthorized users. This is a good thing, and each new version of Windows has more restrictive controls placed on this sensitive data.
Unfortunately, many applications are written such that they require access from the user’s credentials to protected files, often in excess of what the applications really need to do. They may, for example, attempt to open a key for writing as well as reading, when only reading is necessary. Because the ordinary user may be prevented from changing sensitive registry keys but the administrator may not be, the application will run for an admin but not for the ordinary user. Ultimately, the solution is that applications be written to the specifications required.
To resolve this, find the files and registry keys that are causing the problem and grant users the access required. The applications will run, and users will not need membership in administrative groups. Best practices dictate that you create a custom group and grant the access to the group. To provide users with access, give them membership in this group. Users then have the access to run the application but do not have the additional privileges of an administrator.
Additionally, modern versions of Windows support the “runas” concept. This allows you to choose to run a program as a different more elevated account, which means the user can run the application safely most of the time with only user rights, and elevate their privileges using runas for installation and configuration of software when needed.
Elevated Privileges Are Required
A user’s job may require some privilege; for instance, help desk personnel may need to be able to reset passwords when users forget them. This privilege is granted only to administrators in Windows domains. However, many other privileges that a user might require are either available with membership in some other group or can be assigned separately. Examples of these types of privileges can be found in a list of User Rights. User Rights—backup files and folders, log on locally, and so on—vary slightly according to the version of Windows used. They can be set for Windows 2003 and later systems in the Local Security Policy or in Group Policy in a domain setting.
In addition to using default groups that have been assigned the privileges required, or creating custom groups and assigning appropriate user rights to the groups, you can use a security utility called Delegation of Authority with Windows 2003 and higher domains. This utility can be used to give granular control over objects in the Active Directory. For example, a custom group can be given just the privilege of resetting users’ passwords. If this utility is used for this purpose, then you can place help desk operators in the custom group and they won’t need full administrative privileges.
Programmers as Administrators
Programmers have special requirements and are often given administrative privileges on their own computers. Unfortunately, programmers then do all their coding as administrators and produce programs that have never been run by non-administrators. Programmers then also use this elevated account status to access their e-mail, thus making their systems more vulnerable to attack. They may also, in some cases, abuse the privilege by downloading unauthorized materials, changing security settings on their systems, and so on.
Programmers can and should do most programming as ordinary users, instead of the more common practice, and should definitely do ordinary user activities as ordinary users. Programmers, like administrators, can use the runas command when it becomes necessary to perform some administrative privilege.
Requiring Administrators to Use runas
Every holder of a privileged account should have an ordinary account as well. Administrators, for example, should not read their e-mail while logged on as administrators. Many, but not all, e-mail-born attacks are harmless or less damaging if the account used to run them (the logged-on user) does not have administrative privileges.
In Windows, a built-in runas command allows a user to run a program with elevated privileges, by entering the user ID and password for an account that has the required privilege. The newest version of Windows utilizes User Access Control to force even users with local administrative rights to validate that they want to allow something to run with administrator rights. This control prevents malware from using the user’s elevated rights to make changes to the system without the user’s knowledge.
Active Directory Domain Architecture
Analyzing current systems and hardening them against known vulnerabilities, and attempting to determine and then mitigate possible threats, are both strong techniques in developing security for Windows systems. But what do you do to put solid security into place? What are the tools you use in Windows to enforce sound security practice? What activities can protect you against threats and vulnerabilities that no one knows about? How is security functionality organized, and just how do you enforce security policy in the Windows world?
Logical Security Boundaries
The first security boundary in a Windows network is the individual server or workstation. Even early Windows workstations such as Windows 95 and 98 provided a nod to this concept. Although physical access to these computers means essentially administrative access, network access via Windows shares can be password protected. Windows NT introduced to Windows systems, the concept of authentication—local access could be protected by requiring a user account and logon. Degrees of administration and access are controlled by membership in permitted groups or in the application of privileges and permissions to the user account. Network access can be controlled by share permissions, not passwords. Without knowledge of a system-resident account and its password, on a properly hardened Windows NT 4.0 system, resources are protected from all but the determined attacker. Each stand-alone system has its own account database. To provide access to resources on multiple networked computers requires an account and password for each NT 4.0 computer that is not joined in a domain.
The Windows Forest
Windows 2000 introduced the concept of the forest, and Windows Server 2003 and 2008 continue that tradition. The Windows forest is a collection of domains. Each domain in a Windows forest has its own database of user accounts, its own groups, and its own sets of privileges. The database is managed and supported by a domain controller. Unlike legacy Windows NT, each domain controller (DC) supports a live database—the Active Directory. Changes to most types of data can be made at any DC in the domain; replication is multimaster. Some domain information, enough to make forest-wide data searches available from any domain in the forest, is replicated forest-wide.
Figure 22-2 represents a forest with three domains. Note the DCs in each domain and their shared account database. Note also the lines connecting each domain as part of a single entity—the forest. The naming convention for domains follows DNS namespace conventions. This specific forest has only one namespace, or tree.
Figure 22-2 A single-tree Windows forest with three domains
NOTE Forest-wide data is not replicated to every domain controller in every domain; instead, a special role, that of Global Catalog (GC), is assigned to at least one DC in the forest. The GC plays a special role in authentication, as it has knowledge of special forest-wide groups, Universal groups. During authentication, membership in these groups is discovered by access to the GC.
A few operations are controlled by a single DC in the domain, and a couple are controlled by a single DC in the forest. These Flexible Single Master Operations (FSMOs) do such things as control changes to the schema (a catalog of objects and attributes that can exist in the forest) or parcel out RID numbers (RIDs are the unique parts of SIDs, which are security identifiers). FSMOs exist to prevent the problems that multimaster replication might cause for these unique activities.
NOTE SIDs are composed of domain identifiers, and RIDs are thus unique. Each user and computer account and each Windows group has its own SID. Within the system, SIDs, not accounts, are used to identify security principals (users, groups, computers) and note who has what privilege or permission.
Access privileges and permissions can be granted on domain member computers to domain accounts and groups. There are even new group scopes (where groups can be utilized, along with who and what can be a member of the group) and new groups that can be used when domains rid themselves of NT 4.0 DCs. Unlike in NT, a Windows 2003 or higher domain, however, is not a security boundary.
This is true in many ways. First, there are forest-wide groups. A member of the Schema Admins group can modify the schema of the forest—a change that can affect every domain in the forest. A member of the Enterprise Admins group has administrative privileges in all domains in the forest. Second, users and groups from one domain can be granted access to resources and privileges in another.
Figure 22-3 illustrates this principle. Peter, who has an account in mydomain.local, is given access to resources in west.mydomain.local and east. mydomain.local. Mary, with an account at east.mydomain.local, is given access to resources in west.mydomain.local. The access is granted by administrators in the respective domains, but no special configuration is necessary. The same process is followed for accounts from other domains as in the local domain.
Figure 22-3 In forest-wide groups, access can be granted across domains. Managing that access with group membership instead of giving rights directly to user accounts is best.
Finally, a malicious administrator in one domain has sufficient access to configuration information in the Active Directory to elevate his privileges in another domain.
NOTE This vulnerability, which can be perpetrated only by a trusted administrator (or an attacker who has compromised such an account), was not immediately evident when Windows 2000 forests were introduced. Much literature still documents the Windows Domain as the security boundary. Microsoft documentation now correctly identifies this issue. Mitigation of this vulnerability is possible—through vigilant auditing, vetted trust in privileged users, and threat analysis. Think through what someone might do, as opposed to what you think they are authorized to do, and suspend naiveté as to the motives of insiders—this work reveals harsh truths but must be done.
Crossing Boundaries: The Windows Trust
Windows 2000, 2003, and 2008 forests present unique domain security boundary issues precisely because of the solid domain security boundaries in Windows NT. As the numbers of Windows NT systems increased in an enterprise, the number of domains did as well. Although relationships between domains could be forged, little foresight was used in many cases. The architecture of a large number of Windows networks was not planned, it just proliferated. IT was forced to cobble together dispersed domains in order to provide easier access between different domains and their resources, to provide access while reducing the number of accounts and passwords necessary, and to ease administration of large numbers of unique security boundaries.
Windows Trusts The way in which domains can be joined is called a
trust. In Windows, these trusts have to be specified and are one-way. A trusted domain’s users can be granted access to a trusting domain’s resources. If the opposite relationship is also desired, a second trust must be configured. When large numbers of domains exist in an enterprise, large numbers of trust relationships eventually become too confusing to diagram. The maintenance of these trusts can also be an issue, as trusts break and must be removed, then recommitted to ensure user access to resources and maintain administrative control.
Figure 22-4 represents a simple trust relationship between domain A and domain B. Domain B trusts domain A; that is, accounts and groups in domain A can be given access to resources in domain B. Joe, who has an account in domain A, is granted access to a folder on a server in domain B. Alice, who has an account in domain B, cannot be granted any access to any resource in domain A. Furthermore, Windows trusts are non-transitive; that is, although domain A trusts domain B and domain B trusts domain C, there is no trust relationship between domain A and domain C.
Figure 22-4 A simple one-way trust
Trust in the Forest Windows 2000, 2003, and 2008 forests are collections of domains that have automatic, two-way, Kerberos-style transitive trust. This means that every domain in the forest trusts every other domain in the forest. Every domain account can be granted access to any other domain’s resources. Remember, however, that this access must be granted by the local domain’s administrators (with the exception of the malicious elevation of privilege attack mentioned previously). In
Figure 22-5, the lines between the domains represent this trust relationship. This is true whether the forest has one namespace, as shown in
Figure 22-5, or multiple namespaces or trees, as illustrated in
Figure 22-5. Each domain in the forest trusts every other domain in the forest.
Figure 22-5 A multi-tree automatic transitive trust
Each forest, however, does not trust another forest. Users with accounts in one forest cannot be granted access to resources in another forest. This is fine, if this is desired. In fact, we generally don’t want this type of commingling between users and resources in different organizations, and even between some groups of the same organizations. A complete security boundary is sometimes necessary due to legal issues, political issues, or even privacy issues. Think of financial organizations that are international. In order to comply with strict regulations imposed by the countries that they service, and also to separate the institutions they support legally, no possibility of conjoining can be tolerated. The separate forest provides this structure.
External Trust But what if access is required? What if acquisitions, mergers, and even partnerships necessitate commingling of resources and accounts? You cannot simply “snap together” forests or “snap in” trees from one forest into another. You can, however, create trust relationships between domains in separate Windows forests, and you can create forest trust relationships between Windows Server 2003 forests.
Trusts between domains from different forests, called
external trusts, are a Windows NT 4.0–style trust. No Kerberos authentication, no transitivity, and only one way. Trust between domain c.Mydomain.local in one forest and domain 1.yourdomain.local in another forest only provides access for users in one domain to resources in the other domain. As it has been since Windows NT 4.0, the direction of the trust is important, and two one-way trusts can be created to provide similar access in both directions. This external trust provides no access, however, and no ability to assign access to users from any other domain in either forest to any other resource in any other domain in either forest.
Figure 22-6 illustrates this trust. In the figure, two one-way trusts have been made. The shaded areas in each forest represent the limits of these trusts.
Figure 22-6 An external trust
The Complete Forest Trust Although Windows Server 2003 and higher can create external trusts between domains in different forests, they can also create forest trusts. This capability can provide complete Kerberos-style transitive trust between the two forests.
Figure 22-7 illustrates such a trust. The shaded areas, all domains in both forests, represent the breadth of this trust. Every account in every domain in every forest can be given access to every resource in every domain in every forest. Note the word “can”: domain administrators must provide that access.
Figure 22-7 Kerberos-style two-way transitive trust between two forests
Selective Authentication and SID Filtering You may not want external trusts and forest trusts to provide such far-reaching access potential—in this scenario, malicious administrators in someone else’s forest may be able to elevate their privileges in yours. Two things in Windows Server 2003 and higher address this concern.
First, SID filtering is turned on, by default, in forest trusts. This means a malicious administrator in one forest can’t spoof possession of SIDs from another forest and thus gain some advantage in the other forest. SIDs, as you recall, uniquely identify users, computers, and groups. They are used to grant privileges and permissions. If users can pretend that they have the right to a SID, they can obtain the access granted to those authorized to use that SID. SID filtering prevents the spoofing of SIDs.
However, it is sometimes useful to allow SIDs to be intentionally shared by individual users—for example in cross-forest migrations, where the SID history is retained from the old forest to the new forest to maintain access to old resources. But when access in the old forest is no longer needed, SID filtering must be reenabled to protect against a malicious user backfilling the SID of an elevated user into their own SID history.
Second, you can limit the access provided by a trust between two Windows Server 2003 or higher domains in different forests. You do this using selective authentication. When selective authentication is turned on, administrators in the trusting domain must provide users from the other domain with “permission to authenticate” for each server in the domain. Administrators can actually grant the other domain users read permission (or some other permission) on a file, but if the users don’t have permission to authenticate to that file server, they can’t read the file. It’s as if you paid for a seat on the airplane, but airport security won’t let you into the terminal. You still can’t get on the plane.
Selective authentication also can be configured for forest trusts. In this case, users must be granted permission to authenticate to each domain in the trusting forest. Selective authentication provides a way to limit a trust relationship, and this is a good thing. It requires more administration, but it provides tighter control over who can do what.
Role-Based Administration
Security administration is often an exercise in determining just what access should be allowed and then figuring out the best way to grant only that access under the principle of least privilege—to limit users to only the access they need to do their jobs. Windows NT 4.0 and later provide a simple way to do this. Default groups are loosely arranged around roles that a user might play in a network, and custom groups can be created for specific functionality.
Groups
Default groups provide levels of administration or ordinary function. The base groups that are present in all Windows domains are
• Administrators The local all-powerful group. Members of the local Administrators group have all privileges and rights of access on the local system. Although administrative access and privilege of some kinds can be removed, administrators can take ownership of objects and regrant themselves privileges and access permissions.
• Domain Admins All-powerful in the domain, members in this group can administer all domain member computers as well as domain policy.
• Domain Users Ordinary folk, they have simple, basic rights such as the right to log on to a network or to shut down a workstation, which are granted via membership in the local Users group.
• Users These are ordinary folk with rights on a single computer.
• Domain Guests Access is granted to this group through membership in the local Guest group.
• Guests Access granted to this group is available to users who do not have an account on the computer.
• Server Operators This group affords limited administrative privileges such as to start and stop servers and perform some configuration, backup, and restore tasks.
• Account Operators These manage and create accounts and groups. They cannot manage Administrators or Domain Admins groups.
• Print Operators These folks manage printers.
• Power Users Only available on servers and workstations, this is not a domain group. The level of access depends greatly on the version of the OS. Newer versions of Windows operating systems have granted more abilities to Power Users to reduce the need to make users local administrators.
NOTE Security experts avoid Guests and Domain Guests groups, as they grant potential access without accountability. Most advise disabling the Guest account. The Administrators and Domain Admins groups are obvious choices for attackers. The use of groups is a powerful concept and a great flaw. If an attacker gains membership in a powerfully privileged group, those privileges are gained automatically. Group membership should be constantly monitored. Windows 2000 and higher provide a utility, Restricted Groups, which can be used to control membership in a group. If, for example, a local administrator adds a friend to the local Administrators group, and that friend is not also listed in the Restricted Group container as a member of Administrators, then that friend’s account will be removed from the group. Because Restricted Groups is a part of Group Policy, it is under the control of Domain Admins, and the local Administrator cannot modify it. This type of behavior can also be monitored with applications like System Center Operations Manager so administrators are alerted if one of their peers tries to add an unauthorized user to a privileged group.
Each new version of Windows adds new groups and users. Windows 2000 added groups such as Group Policy Owner Creators (users who can create and manage Group Policy), DNS Administrators (users who can manage DNS), and even computer groups such as DNSUpdateProxy (DNS clients that can update DNS records on behalf of some other computer, DHCP servers, for example). Windows XP added the Remote Desktop Operators group (users who can access a desktop remotely) and the Network Configuration Operators group (users who can do some network configuration such as change the IP address and enable and disable a network LAN connection). Windows Server 2003 added two important new default user accounts: Network Service and Local Service. These are accounts with few privileges, which can be assigned to services. Services require the ability to log on and run in the background. Best practice is to give them only the privileges that they require, but in the past, most services ran under the Local System account with too many privileges.
In Windows Server 2003 and newer, role management can be programmed into .NET applications and enforced via the Authorization Manager tool (axman.msc). Windows Groups can be used, as well as groups created specifically for an application and dynamic groups. Dynamic groups are groups created by an Active Directory query. For example, all users who work in the Finance Department can be granted the ability to run specific code within an application. That group membership may change according to user attributes in the Active Directory and does not require administrative group management, just the correct changes to user attributes.
NOTE Default User accounts are few: Administrator, Guest, and now Local Service and Network Service. But any number of accounts can be created.
Access Permissions
Access permissions on objects are the way that access control is managed in Windows. A good explanation of Windows access permissions and how they work can be found in
Chapter 7.
A Role-Based Approach to Security Configuration
The use of user groups can assist in applying role-based permissions and restrictions to user authentication and authorization. In Windows, the same is true for computers. A more comprehensive approach using Group Policy can apply security to computers as well as users. Here’s how that can work.
First, realize that computer roles on the network are distinct from user roles, although the combination of the two ultimately decides what can and cannot happen. Look at computer and user roles separately, and then consider their interaction.
Securing Computer Network Roles
Securing network computer roles consists of a simple process by which roles are identified, security baselines are compiled, and a structure is devised to ensure the proper application of security to each computer role. Specifically, the steps are these:
1. Each computer plays a role on the network. Some servers are file and print servers; others are infrastructure servers such as DNS, DNCP, and WINS; still others are domain controllers, desktops, and laptops. In your organization, list the roles that computers play.
2. Develop a security baseline for each computer role, defining the specific security requirements of each and the requirements that can be recorded in a security template.
3. Determine which different computer roles have security configurations in common. Microsoft has done much of this work, and the result is two basic security baselines, one for servers and one for domain controllers. These templates are a good place to start. Their objective is to apply strict security configurations, and the templates enable services that are absolutely required for basic functioning.
4. Decide what additional security configuration is required for each role that is different from the baseline. For example, infrastructure servers may require the ability to run the DNS server or DHCP server services, or a print server may need the print spooler service.
5. Review the possible security configuration options in the templates and create a role-specific template for each role.
6. Where necessary, create role-specific OUs in the domain and place the computer account for each computer serving that role in the OU. Examples would be an infrastructure OU, a desktop computer OU, and a file and print server OU.
7. Create role-specific GPOs and link them to the related role-specific OUs.
8. Import the security template related to each role into the GPO linked to the role-specific OU. The baseline server template can be imported into a GPO linked to the domain. The domain controller template can be imported into a GPO linked to the domain controller’s OU.
9. Examine each GPO for additional security-specific/role-specific configurations. Administrative templates, for example, can be used to apply further security. Base administrative templates exist, and additional ones are available for some applications. For example, a configured Microsoft Office administrative template could be applied to a GPO linked to the desktop computer OU. (These templates are available with the Microsoft Office Resource Kit and also downloadable from Microsoft.)
10. Test thoroughly, modify where necessary, and then incorporate in your production network.
The implementation of such a plan is a large undertaking; however, help is available. Security administration guides for doing just such a rollout, complete with sample templates for many roles, are available online from Microsoft, DISA, and the NSA.
Securing User Roles
To provide security configurations to manage users on the network, you follow a similar process, but you have extra work. Just as computers are controlled by the application of the computer portion of a GPO, users can be managed by applying the user portion of a GPO. In addition, users are granted access to extensive arrays of resources via their membership in groups and the application of access controls at the resource level. (Computers may also be managed in this fashion.) Most of these additional security applications are not possible through a GPO.
To manage user roles, however, you can follow the process for GPOs outlined in the preceding section with the following differences:
• The portion of the security templates that controls user security is really computer based and includes the extensive account policy and user rights sections of the template. This security should be designed into the security templates applied to computers. Security templates are not available for securing users. Instead, use the user/administrative templates in the GPO to manage user access to common Windows applications and resources such as Internet Explorer, Windows Update, the Control Panel, desktop functions, and so on.
• Design user roles and develop a sound understanding of access controls in order to match permissions and privileges to roles. Create user groups and give the groups the permissions and privileges. Assign users roles via membership in groups.
Compliance with Standards
If you are following a specific security framework, here’s how ISO 27002, COBIT, and NIST tie in to this chapter. NIST has the most specific guidance for configuring Windows, down to the level of how to configure the operating system. ISO 27002 has some higher-level guidance, and COBIT is even higher-level. The following sections describe the relevant provisions of each standard.
NIST
NIST offers specific guidance for securing Windows systems in publication SP 800-68. Although this particular document is focused on Windows XP, the practices it describes are applicable to all flavors of Windows. This guideline specifies the following:
• Protect each system based on the potential impact to the system of a loss of confidentiality, integrity, or availability.
• Reduce the opportunities that attackers have to breach a system by resolving security weaknesses and limiting functionality according to the principle of least privilege.
• Select security controls that provide a reasonably secure solution while supporting the functionality and usability that users require.
• Use multiple layers of security so if one layer fails or otherwise cannot counteract a certain threat, other layers might prevent the threat from successfully breaching the system.
• Conduct risk assessments to identify threats against systems, and determine the effectiveness of existing security controls in counteracting the threats. Perform risk mitigation to decide what additional measures (if any) should be implemented.
• Document procedures for implementing and maintaining security controls. Maintain other security-related policies and documentation that affect the configuration, maintenance, and use of systems and applications, such as Acceptable Use Policy, Configuration Management Policy, and IT contingency plans.
• Test all security controls, including the settings in the NIST security templates, to determine what impact they have on system security, functionality, and usability. Take appropriate steps to address any significant issues before applying the controls to production systems.
• Monitor and maintain systems on a regular basis so security issues can be identified and mitigated promptly. Actions include acquiring and installing software updates, monitoring event logs, providing remote system administration and assistance, monitoring changes to OS and software settings, protecting and sanitizing media, responding promptly to suspected incidents, performing vulnerability assessments, disabling and deleting unused user accounts, and maintaining hardware.
ISO 27002
ISO 27002 contains the following provisions, to which this chapter’s contents are relevant:
• 10.4 Protect against malware.
• 10.5.1 Establish reliable backups: determine the level of backup required for each system and data to be backed up, frequency of backups, duration of retention, and test restores to assure the quality of the backups.
• 10.6.1 Separate operational responsibilities, safeguard the confidentiality and integrity of sensitive data on the network, and log and monitor network activities.
• 10.6.2 Use authentication, encryption, and connection controls along with access control, with rights based on user profiles, and consistent management of access rights across the network with segregation of access roles.
• 11.2.1 Control privileged (administrator) access rights and use unique user IDs for each user.
• 11.2.2 Use privilege profiles for each system, and grant privileges based on these profiles.
• 11.2.3 Perform user password management, or use access tokens such as smart cards.
• 11.2.4 Review user access rights, and perform even more frequent review of administrator rights.
• 11.3.1 Keep passwords confidential and don’t share them; avoid writing down passwords; select strong passwords that are resistant to dictionary, brute-force, or other standard attacks; and change passwords periodically.
• 11.3.2 Ensure that unattended systems are locked, for instance, with a password-protected screensaver.
• 11.4.1 Provide access only to services that individual users have been specifically authorized to use.
• 11.4.3 Limit access to the network to specifically identified devices or locations.
• 11.4.5 Segregate groups of computers, users, and services into logical network domains protected by security perimeters.
• 11.4.6 Filter network traffic by connection type such as messaging, e-mail, file transfer, interactive access, and applications access.
• 11.5.1 Restrict system access to authorized users.
• 11.5.2 Ensure that unique user accounts are assigned for individual use only, avoiding generic accounts such as “guest” accounts unless no tracking is required and privileges are very limited. Also ensure that regular user activities are not performed from privileged accounts.
• 11.5.3 Enforce use of individual user IDs and passwords. Enforce strong passwords, and enforce password change at set intervals.
• 11.5.4 Restrict and monitor system utilities that can override other controls.
• 11.5.5 Ensure that sessions lock after a period of inactivity with a password required to unlock them.
• 11.6.1 and 11.1.1 Restrict access based on a defined access control policy.
• 11.6.2 Segment and isolate systems on the network based on their risk or sensitivity.
• 12.6 Establish a vulnerability management program.
COBIT
COBIT contains the following provisions, to which this chapter’s contents are relevant:
• AI3.2 Implement internal control, security and audit to protect resources and ensure availability and integrity. Sensitive infrastructure components should be controlled, monitored, and evaluated.
• DS5.3 Ensure that users and their activities are uniquely identifiable. Enable user identities via authentication mechanisms. Confirm that user access rights to systems and data are appropriate. Maintain user identities and access rights in a central repository.
• DS5.4 Use account management procedures for requesting, establishing, issuing, suspending, modifying, and closing user accounts and apply them to all users, including privileged users. Perform regular review of accounts and privileges.
• DS5.7 Make security-related technology resistant to tampering.
• DS5.8 Organize the generation, change, revocation, destruction, distribution, certification, storage, entry, use, and archiving of cryptographic keys to ensure protection against modification and unauthorized disclosure.
• DS5.9 Use preventive, detective, and corrective measures, especially regular security patching and virus control, across the organization to protect against malware such as viruses, worms, spyware, and spam.
• DS5.10 Use firewalls, security appliances, network segmentation, and intrusion detection to manage and monitor access and information among networks.
• DS5.11 Exchange confidential data only over a trusted path with controls to provide authenticity of content, proof of submission, proof of receipt, and non-repudiation of origin.
Summary
The most important things that can be done to secure a Windows network are
• Harden systems using known configurations, many of which protect the system against known attacks.
• Develop and enforce security policy.
• Patch systems and report on those patch statuses.
• Segment the network into areas of trust and provide border controls.
• Strengthen authentication.
• Limit the number of administrators, and limit their privileges.
• Give your users the tools they need to be more responsible and secure in how they work.
The Windows-specific tasks to do this job include creating security boundaries using forests, using domains to organize user and resource management, and using role-based administration. Role-based administration is established by providing access to resources and privileges on the systems to groups of users and computers that represent a specific role or job, and by applying security configuration based on the role that computers and users play in the network.
The Windows-specific tools that supplement and enforce security configuration and management are security templates, the Security Configuration and Analysis Wizard, Group Policy, certificate services, and IPSec.
References
Allen, Robbie. Windows Server Cookbook for Windows Server 2003 and Windows 2000. O’Reilly, 2005.
Danseglio, Mike. Securing Windows Server 2003. O’Reilly, 2004.
Danseglio, Mike, and Robbie Allen. Windows Server 2003 Security Cookbook: Security Solutions and Scripts for System Administrators. O’Reilly, 2005.
De Clercq, Jan, and Guido Grillenmeier. Microsoft Windows Security Fundamentals. Digital Press, 2006.
Grimes, Roger, and Jesper Johansson. Windows Vista Security: Securing Vista Against Malicious Attacks. Wiley, 2007.
Honan, Brian. ISO27001 in a Windows Environment: The Best Practice Handbook for a Microsoft Windows Environment. IT Governance LTD, 2010.
Johansson, Jesper. Protect Your Windows Network: From Perimeter to Data. Addison-Wesley, 2005.
Norberg, Stefan. Securing Windows NT/2000 Servers for the Internet. O’Reilly, 2000.
Scambray, Joel, and Stuart McClure. Hacking Exposed Windows: Microsoft Windows Security Secrets and Solutions. McGraw-Hill, 2007.
Shawgo, Jeff. Securing Windows 2000 Step by Step. SANS Institute, 2001.
Sinchak, Steve. Windows 7 Tweaks: A Comprehensive Guide on Customizing, Increasing Performance, and Securing Microsoft Windows 7. Wiley, 2009.
Smith, Ben, and Ben Komar. Microsoft Windows Security Resource Kit, Second Edition. Microsoft Press, 2005.
Tiensivu, Aaron. Securing Windows Server 2008: Prevent Attacks from Outside and Inside Your Organization. Syngress, 2008.
