Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
ptg
Although these components can be set up manually, the process of turning on these
services is streamlined through the use of the Configure Your Server Wizard.
Securing a Server Using Server Manager
With the list of roles that a server will perform in hand, the ideal utility for turning on
these roles and securing them is the newly renovated Server Manager. By default, if a
server is a DNS server but does not do file and print services, Server Manager not only
opens the ports required for DNS, but also blocks any file and print access to the server.
Windows Server 2008 R2 Server Manager, shown in Figure 13.8, allows for individual roles
to be enabled on a server. After being enabled, those roles are turned on and the proper
ports to run those roles are opened on the server.
Files secured on Windows Server 2008 R2 are only as secure as the permissions that are
set on them. Subsequently, it is good to know that Windows Server 2008 R2 does not
grant the Everyone group full control over share-level and NTFS-level permissions. In
addition, critical operating system files and directories are secured to disallow their unau-
thorized use.
Despite the overall improvements made, a complete understanding of file-level security is
recommended to ensure that the file-level security of a server is not neglected.
430
CHAPTER 13
Server-Level Security
FIGURE 13.8
Viewing Server Manager.
ptg
Understanding NT File System (NTFS) Security
The latest revision of the NT File System (NTFS) is used in Windows Server 2008 R2 to
provide for file-level security in the operating system. Each object that is referenced in
NTFS, which includes files and folders, is marked by an access control entry (ACE) that
physically limits who can and cannot access a resource. NTFS permissions utilize this
concept to strictly control read, write, and other types of access on files.
File servers should make judicious use of NTFS-level permissions, and all directories should
have the file-level permissions audited to determine if there are any holes in the NTFS
permission set. Changing NTFS permissions in Windows Server 2008 R2 is a straightfor-
ward process; simply follow these steps:
1. Right-click the folder or file onto which the security will be applied, and choose
Properties.
2. Select the Security tab.
3. Click the Advanced button.
4. Click the Change Permissions button.
5. Uncheck the Include Inheritable Permissions from This Object’s Parent check box.
6. Click Remove when prompted about the application of parent permissions.
7. While you’re in the Advanced dialog box, use the Add button to give access to the
groups and/or users who need access to the files or folders.
8. Check the Replace All Child Object Permissions with Inheritable Permissions from
This Object check box, as shown in Figure 13.9, and click OK.
Examining File-Level Security
431
13
FIGURE 13.9
Setting NTFS permissions.
9. When prompted about replacing security on child objects, click Yes to replace child
ptg
object security and continue.
10. Click OK and then click OK again to close the property pages.
Examining Share-Level Security Versus NTFS Security
Previous Windows security used share-level permissions, which were independently set. A
share is a file server entry point, such as \\sfofs01\marketing, that enables users to have
access to a specific directory on a file server. Older file systems such as FAT, HPFS, and
FAT32 did not include file-level security, so the security was set instead on the share level.
Although share-level security can still be set on files, it is preferable to use NTFS-level secu-
rity, where possible. Share-level security is not very secure because it cannot secure the
contents of subdirectories easily.
Auditing File Access
A good practice for file-level security is to set up auditing on a particular server, directory,
or file. Auditing on NTFS volumes enables administrators to be notified of who is access-
ing, or attempting to access, a particular directory. For example, it might be wise to audit
access to a critical network share, such as a finance folder, to determine whether anyone is
attempting to access restricted information.
NOTE
Audit entries are another example of security settings that can be automatically set via
security templates in Windows Server 2008 R2. It is wise to consider the use of securi-
ty templates to more effectively control audit settings.
432
CHAPTER 13
Server-Level Security
The following steps illustrate how to set up simple auditing on a folder in Windows
Server 2008 R2:
1. Right-click the folder or file onto which the auditing will be applied, and choose
Properties.
2. Select the Security tab.
3. Click the Advanced button.
4. Select the Auditing tab.
5. Click the Edit button.
6. Using the Add button, enter all users and groups that will be audited. If you’re audit-
ing all users, enter the Everyone group.
7. On the Auditing property page, select all types of access that will be audited. If
you’re auditing for all success and failure attempts, select all the options, as indi-
cated in Figure 13.10.
ptg
FIGURE 13.10
Selecting what to audit.
8. Click OK to apply the settings.
9. Click OK twice to save the settings.
Additional Security Mechanisms
433
NOTE
An effective way of catching “snoops” in the act is to create serious-looking shares on
the network, such as Financial Statements, Root Info, or similar such shares, and
audit access to those folders. This mechanism, known as a honeypot, has been suc-
cessfully used to identify internal (or external) saboteurs before they could do some
serious damage.
Encrypting Files with the Encrypting File System
13
Windows Server 2008 R2 continues support for the Encrypting File System (EFS), a method
of scrambling the contents of files to make them unintelligible to unauthorized users. EFS
has proven to be valuable for organizations that desire to keep proprietary data, especially
those stored on laptops, out of the wrong hands. A more comprehensive approach to
client encryption is with Windows 7/Vista BitLocker Drive Encryption, which encrypts all
files on the entire hard drive, with the exception of a few files required for startup.
Additional Security Mechanisms
ptg
In an insecure world, a server is only as secure as the software that runs on it. Windows
Server 2008 R2 is the most secure Windows yet, and includes many built-in mechanisms
to keep a server secure. Additional security considerations such as antivirus options and
backup should be taken into account, however, as they directly affect the overall security
of the operating system itself.
Antivirus Precautions
Viruses might be one of the most dangerous threats faced by servers. Many viruses are
written to specifically exploit key vulnerabilities that are present in server infrastructure.
Others infect files that might be held on a server, spreading the infection to clients who
download files. Consequently, it is extremely important to consider the use of an enter-
prise antivirus solution on all file servers in a network. All the major antivirus manufactur-
ers include robust file-level scanners, and administrators should consider using them.
Microsoft itself has released a line of antivirus products with tight integration with the
Windows Server line. This is part of the Forefront line of security products. An advantage
to using the Forefront product suite is that it uses five antivirus engines all running at the
same time. This way, if one of the engines doesn’t catch a virus or isn’t updated quickly
enough, there is a good chance that one of the other vendors’ engines will detect the virus.
More information on the Forefront line can be found at www.microsoft.com/forefront.
An aggressive plan should be in place to keep antivirus patterns and engines up to date.
Because virus outbreaks can wreak havoc worldwide in a matter of hours, rather than
days, it is wise to have servers check for updates at least daily.
434
CHAPTER 13
Server-Level Security
Deploying Backup Security
Although the need for a backup strategy might seem obvious to most people, it is often
surprising to find out how inadequately prepared many organizations are in regard to
their backups. All too often, a company will discover that it is very easy to back up a
server but often more difficult to restore. In addition to disaster recovery issues, the issue
of backup security is often neglected.
File server backups require that an authenticated user account with the proper privileges
copy data to a storage mechanism. This requirement ensures that not just anyone can back
up an environment and run off with the tape. Keeping this point in mind, the tapes that
contain server backups should be protected with the same caution given to the server itself.
All too often, a big pile of server backup tapes is left out on unsecured desks, and there is
often no mechanism in place to account for how many tapes are in which location.
Implementing a strict tape retention and verification procedure is, subsequently, a must.
Using Windows Server Update Services
One of the main drawbacks to Windows security has been the difficulty in keeping servers
and workstations up to date with the latest security fixes. For example, the security fix for
ptg
the Index Server component of IIS was available for more than a month before the Code
Red and Nimbda viruses erupted onto the scene. If the deployed web servers had down-
loaded the patch, they would not have been affected. The main reason that the vast major-
ity of the deployed servers were not updated was that keeping servers and workstations up
to date with the latest security patches was an extremely manual and time-consuming
process. For this reason, a streamlined approach to security patch application was required
and realized with the formulation of Windows Server Update Services (WSUS).
Understanding the Background of WSUS: Windows Update
In response to the original concerns regarding the difficulty in keeping computers prop-
erly patched, Microsoft made available a centralized website called Windows Update to