Using Windows Firewall With Advanced Security console

The Windows Firewall control panel is designed to enable administrators and advanced users to manage basic firewall settings. For full access to the Windows Firewall configuration settings, you must use the Windows Firewall With Advanced Security snap-in for the MMC.
To open the console, open Server Manager and, from the Tools menu, select Windows Firewall With Advanced Security. The Windows Firewall With Advanced Security console opens, as shown in Figure 6-23.

FIGURE 6-23 The Windows Firewall With Advanced Security console

Configuring profile settings
At the top of the Windows Firewall With Advanced Security console’s middle pane, in the Overview section, there are status displays for the computer’s three network location profiles.
If you connect the computer to a different network (which is admittedly not likely with a server), Windows Firewall can load a different profile and a different set of rules.
The default Windows Firewall configuration calls for the same basic settings for all three profiles, as follows:
- The firewall is turned on.
- Incoming traffic is blocked unless it matches a rule.
- Outgoing traffic is allowed unless it matches a rule.
You can change this default behavior by clicking the Windows Firewall Properties link, which displays the Windows Firewall With Advanced Security On Local Computer dialog box.
In this dialog box, each of the three network location profiles has a tab with identical controls which enable you to modify the default profile settings. You can, for example, configure the firewall to shut down completely when it is connected to a domain network and you can configure the firewall to turn on with its most protective settings when you connect the computer to a public network. You can also configure the firewall’s notification options, its logging behavior, and how it reacts when rules conflict.

Creating rules
The allowed applications that you can configure in the Windows Firewall control panel are a relatively friendly method for working with firewall rules. In the Windows Firewall With Advanced Security console, you can work with the rules in their raw form.
Selecting either Inbound Rules or Outbound Rules in the left pane displays a list of all the rules operating in that direction, as shown in Figure 6-24. The rules that are currently operational have a check mark in a green circle next to them; the rules not in force are unavailable.

FIGURE 6-24 The Inbound Rules list in the Windows Firewall With Advanced Security console

Creating new rules by using this interface provides much more flexibility than the Windows Firewall control panel. When you right-click the Inbound Rules (or Outbound Rules) node and select New Rule from the shortcut menu, the New Inbound (or Outbound) Rule Wizard takes you through the process of configuring the following sets of parameters:

- Rule Type Specifies whether you want to create a program rule, a port rule, a variant on one of the predefined rules, or a custom rule. This selection determines which of the following pages the wizard displays.
- Program Specifies whether the rule applies to all programs, to one specific program, or to a specific service. This is the equivalent of defining an allowed application in the Windows Firewall control panel, except that you must specify the exact path to the application.

- Protocol And Ports Specifies the network or transport layer protocol or the local and remote ports to which the rule applies. This enables you to specify the exact types of traffic that the rule should block or allow. To create rules in this way, you must be familiar with the protocols and ports that an application uses to communicate at both ends of the connection.
- Predefined Rules Specifies which predefined rules defining specific network connectivity requirements the wizard should create.
- Scope Specifies the IP addresses of the local and remote systems to which the rule applies. This enables you to block or allow traffic between specific computers.
- Action Specifies the action the firewall should take when a packet matches the rule. You configure the rule to allow traffic if it is blocked by default or block traffic if it is allowed by default. You can also configure the rule to allow traffic only when the connection between the communicating computers is secured using IPsec.
- Profile Specifies the profile(s) to which the rule should apply: domain, private, or public.
- Name Specifies a name and (optionally) a description for the rule.

The rules you can create by using the wizards range from simple program rules, like those you can create in the Windows Firewall control panel, to highly complex and specific rules that block or allow only specific types of traffic between specific computers. The more complicated the rules become, however, the more you have to know about TCP/IP communications in general and the specific behavior of your applications. Modifying the default firewall settings to accommodate some special applications is relatively simple, but creating an entirely new firewall configuration is a formidable task.

Importing and exporting rules
The process of creating and modifying rules in the Windows Firewall With Advanced Security console can be time-consuming, and repeating the process on multiple computers even more so. Therefore, the console makes it possible for you to save the rules and settings you have created by exporting them to a policy file.
A policy file is a file with a .wfw extension that contains all the property settings in a Windows Firewall installation and all its rules, including the preconfigured rules and those you have created or modified. To create a policy file, select Export Policy from the Action menu in the Windows Firewall With Advanced Security console, and then specify a name and location for the file.
You can then duplicate the rules and settings on another computer by copying the file and using the Import Policy function to read in the contents.

-------------------------

NOTE: IMPORTING POLICIES
When you import policies from a file, the console warns you that all existing rules and settings will be overwritten. You must therefore be careful not to create custom rules on a computer and then expect to import other rules by using a policy file.

------------------------

Creating rules by using Group Policy
The Windows Firewall With Advanced Security console makes it possible to create complex firewall configurations, but Windows Firewall is still an application designed to protect a single computer from intrusion. If you have a large number of servers running Windows Server 2012 R2, manually creating a complex firewall configuration on each one can be a lengthy process. Therefore, as with most Windows configuration tasks, administrators can distribute firewall settings to computers throughout the network by using Group Policy.
When you edit a GPO and browse to the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsWindows Firewall With Advanced Security node, you see an interface that is nearly identical to the Windows Firewall With Advanced Security console.
You can configure Windows Firewall properties and create inbound, outbound, and connection security rules, just as you would in the console. The difference is that you can then deploy those settings to computers  anywhere on the network by linking the GPO to an AD DS domain, site, or OU object.

When you open a new GPO, the Windows Firewall With Advanced Security node contains no rules. The preconfigured rules that you find on every computer running Windows Server 2012 R2 are not there. You can create new rules from scratch to deploy to the network, or you can import settings from a policy file, just as you can in the Windows Firewall With Advanced Security console.
Group Policy does not overwrite the entire Windows Firewall configuration like importing a policy file does. When you deploy firewall rules and settings by using Group Policy, the rules in the GPO are combined with the existing rules on the target computers. The only exception is when you deploy rules with the identical names as existing rules. In that case, the GPO settings overwrite those found on the target computers.

Creating connection security rules
Windows Server 2012 R2 also includes a feature that incorporates IPsec data protection into the Windows Firewall. The IP Security (IPsec) standards are a collection of documents that define a method for securing data while it is in transit over a TCP/IP network. IPsec includes a connection establishment routine, during which computers authenticate each other before transmitting data, and a technique called tunneling, in which data packets are encapsulated within other packets for their protection.
In addition to inbound and outbound rules, the Windows Firewall With Advanced Security console enables you to create connection security rules by using the New Connection Security Rule Wizard. Connection security rules define the type of protection you want to apply to the communications that conform to Windows Firewall rules.

When you right-click the Connection Security Rules node and select New Rule from the shortcut menu, the New Connection Security Rule Wizard takes you through the process of configuring the following sets of parameters, as follows:
- Rule Type Specifies the basic function of the rule, such as to isolate computers based on authentication criteria, to exempt certain computers (such as infrastructure servers) from authentication, to authenticate two specific computers or groups of computers, or to tunnel communications between two computers. You can also create custom  rules combining these functions.
- Endpoints Specifies the IP addresses of the computers that will establish a secured connection before transmitting any data.
- Requirements Specifies whether authentication between two computers should be requested or required in each direction.
- Authentication Method Specifies the type of authentication the computers should use when establishing a connection.
- Profile Specifies the profile(s) to which the rule should apply: domain, private, public, or a combination thereof.
- Name Specifies a name and (optionally) a description for the rule.

Using Windows Firewall control panel applet

The Windows Firewall control panel applet provides the easiest and safest access to the firewall controls. These controls are usually sufficient for most server administrators, unless the system has special requirements or you are working with custom server applications.
When you open the Windows Firewall window from the control panel, as shown in Figure 6-20, you see the following information:
-Whether the computer is connected to a domain, private, or public network
-Whether the Windows Firewall service is turned on or off
-Whether inbound and outbound connections are blocked
-The name of the currently active network
-Whether users are notified when a program is blocked

FIGURE 6-20 The Windows Firewall control panel
On the left side of the window is a series of links, which provide the following functions:

- Allow An App Or Feature Through Windows Firewall Opens the Allowed Apps dialog box, in which you can select the applications that can send traffic through the firewall
- Change Notification Settings Opens the Customize Settings dialog box, in which you can adjust the notification settings for each of the three profiles
- Turn Windows Firewall On Or Off Opens the Customize Settings dialog box, in which you can toggle the state of the firewall in each of the three profiles
- Restore Defaults Returns all firewall settings to their installation defaults
- Advanced Settings Launches the Windows Firewall With Advanced Security console
- Troubleshoot My Network Launches the Network and Internet troubleshooter

Customizing settings
Several of the links in the Windows Firewall window point to the same place: a Customize Settings dialog box that contains controls for some of the most basic firewall functions.
The Customize Settings dialog box, shown in Figure 6-21, is organized according to three areas, corresponding to the three profiles on a Windows computer. Windows Firewall uses these profiles to represent the type of network to which the server is connected. The profiles are as follows:
- Public The public (or guest) profile is intended for servers that are accessible to unauthenticated or temporary users, such as computers in an open lab or kiosk.
- Private The private profile is intended for servers on an internal network that are not accessible by unauthorized users.
- Domain The domain profile is applied to servers that are members of an AD DS domain in which all users are identified and authenticated.

FIGURE 6-21 The Customize Settings dialog box for Windows Firewall
In Windows Firewall, the three profiles are essentially separate sets of rules that apply only to computers connected to the designated network type. Administrators can control the environment for each type of network by configuring separate rules and settings for each profile.
The Customize Settings dialog box has the following controls for each of the three network profiles:

- Turn On/Off Windows Firewall Toggles the Windows Firewall on and off for the selected profile
- Block All Incoming Connections, Including Those In The List Of Allowed Apps
Enables you to increase the security of your system by blocking all unsolicited attempts to connect to your computer
- Notify Me When Windows Firewall Blocks A New App Causes the system to notify the user when an application’s attempt to send traffic through the firewall fails

Allowing applications
There are times when administrators might be required to modify the firewall settings in other ways, typically because a specific application requires access to a port not anticipated by the firewall’s default rules.
To do this, you can use the Allowed Apps dialog box in the Windows Firewall control panel, as shown in Figure 6-22.

FIGURE 6-22 The Allowed Apps dialog box for Windows Firewall

Opening up a port in a server’s firewall is an inherently dangerous activity. The more open doors you put in a wall, the greater the likelihood that intruders will get in. Windows Firewall provides two basic methods for opening a hole in your firewall: opening a port and allowing an application. Both are risky, but the latter is less so. This is because when you open a port by creating a rule in the Windows Firewall With Advanced Security console, the port stays open permanently. When you allow an application through the firewall by using the control panel, the specified port is open only while the program is running. When you terminate the program, the firewall closes the port.

-------------------

Note:Previous versions of Windows refer to allowed applications as exceptions, meaning that they are exceptions to the general firewall rules closing off all the computer’s ports against intrusion. Exam candidates should be prepared to see questions containing either term.

-------------------

The applications listed in the Allowed Apps dialog box are based on the roles and features installed on the server. Each listed application corresponds to one or more firewall rules, which the control panel activates and deactivates as needed.
Unlike earlier versions, the Windows Server 2012 R2 version of the Windows Firewall control panel does not provide direct access to port numbers. For more precise control over the firewall, you must use the Windows Firewall With Advanced Security console, which you can access by clicking Advanced Settings in the Windows Firewall control panel or by selecting it from the Tools menu in Server Manager.

Working with Windows Firewall

Windows Firewall is a single program with one set of rules, but there are two distinct interfaces you can use to manage and monitor it. The Windows Firewall control panel applet provides a simplified interface that enables administrators to avoid the details of rules and port numbers. If you just want to turn the firewall on or off (typically for testing or troubleshooting purposes) or work with the firewall settings for a specific Windows role or feature, you can do so by using just the control panel. For full access to firewall rules and more sophisticated functions, you must use the Windows Firewall With Advanced Security console.
In many cases, administrators never have to work directly with Windows Firewall. Many of the roles and features included in Windows Server 2012 R2 automatically open the appropriate firewall ports when you install them. In other situations, the system warns you of firewall issues.

For example, the first time you open File Explorer and try to access the network, a warning appears, informing you that Network Discovery and File Sharing are turned off, preventing you from browsing the network.
Network Discovery is just a set of firewall rules that regulate the ports Windows uses for network browsing, specifically ports 137, 138, 1900, 2869, 3702, 5355, 5357, and 5358. By default, Windows Server 2012 R2 disables the inbound rules associated with these ports, so the ports are closed, blocking all traffic through them. When you click the warning banner and choose Turn On Network Discovery And File Sharing from the shortcut menu, you are in effect activating these firewall rules, thereby opening the ports associated with them.
In addition to the menu commands accessible through the warning banner, you can control the Network Discovery and File Sharing rules in other ways. The Network and Sharing Center control panel, through its Advanced Sharing Settings page, provides options that you can use to turn Network Discovery, File Sharing, and other basic networking functions on and off.
The Windows Firewall control panel has an Allow An App Or Feature Through Windows Firewall link, which opens the Allowed Apps dialog box. The Network Discovery check box in this dialog box enables you to control the same set of rules as the Network Discovery control panel in the Network And Sharing Center.
Finally, you can access the individual Network Discovery rules directly by using the Windows Firewall With Advanced Security console. When you select the Inbound Rules node and scroll down in the list, you can see nine Network Discovery rules.
As you can see by examining the rules in the console, Network Discovery is a complex Windows function that would be difficult to control if you had to determine by trial and error which ports it uses. This is why Windows Firewall includes a large collection of rules that regulate the ports that the applications and services included with the operating system need to operate.

Understanding Windows Firewall settings

Windows Server 2012 R2 includes a firewall program called Windows Firewall, which is activated by default on all systems. In its default configuration, Windows Firewall blocks most network traffic from entering the computer. Firewalls work by examining the contents of each packet entering and leaving the computer and comparing the information they find to a series of rules, which specify which packets are allowed to pass through the firewall and which are blocked.
The Transmission Control Protocol/Internet Protocol (TCP/IP) is used by Windows systems to communicate functions by packaging application data using a series of layered protocols that define where the data comes from and where it is going. The three most important criteria that firewalls can use in their rules are as follows:

- IP addresses IP addresses identify specific hosts on the network. You can use IP addresses to configure a firewall to only allow traffic from specific computers or networks in and out.
- Protocol numbers Protocol numbers specify whether the packet contains TCP or User Datagram Protocol (UDP) traffic. You can filter protocol numbers to block packets containing certain types of traffic. Windows computers typically use UDP for brief message exchanges, such as Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) transactions. TCP packets usually carry larger amounts of data,
such as the files exchanged by web, file, and print servers.
- Port numbers Port numbers identify specific applications running on the computer. The most common firewall rules use port numbers to specify the types of application traffic the computer is allowed to send and receive. For example, a web server usually receives its incoming packets to port number 80. Unless the firewall has a rule opening port 80 to incoming traffic, the web server cannot function in its default configuration.

Firewall rules can function in two ways, as follows:
- Admit all traffic, except that which conforms to the applied rules
- Block all traffic, except that which conforms to the applied rules

Generally, blocking all traffic by default is the more secure arrangement. From the server administrator’s standpoint, you start with a completely blocked system, and then begin testing your applications. When an application fails to function properly because network access is blocked, you create a rule that opens up the ports the application needs to communicate.
This is the method that Windows Firewall uses by default for incoming network traffic. There are default rules preconfigured into the firewall that are designed to admit the traffic used by standard Windows networking functions, such as file and printer sharing. For outgoing network traffic, Windows Firewall uses the other method, allowing all traffic to pass the firewall except that which conforms to a rule.

Using AppLocker

Software restriction policies can be a powerful tool, but they can also require a great deal of administrative overhead. If you elect to disallow all applications except those matching the rules you create, there are many programs in Windows Server 2012 R2 itself that need rules, in addition to the applications you want to install. Administrators must create the rules manually, which can be an onerous chore.
AppLocker, also known as application control policies, is a Windows feature that is essentially an updated version of the concept implemented in software restriction policies. AppLocker also uses rules, which administrators must manage, but the process of creating the rules is much easier, thanks to a wizard-based interface.
AppLocker is also more flexible than software restriction policies. You can apply AppLocker rules to specific users and groups and also create rules that support all future versions of an application. The primary disadvantage of AppLocker is that you can apply the policies only to computers running Windows 7 and Windows Server 2008 R2 or later.

Understanding rule types
The AppLocker settings are located in GPOs in the Computer ConfigurationWindows SettingsSecurity SettingsApplication Control PoliciesAppLocker container, as shown in Figure 6-19.

FIGURE 6-19 The AppLocker container in a GPO
In the AppLocker container, there are four nodes that contain the basic rule types:
- Executable Rules Contains rules that apply to files with .exe and .com extensions
- Windows Installer Rules Contains rules that apply to Windows Installer packages with .msi and .msp extensions
- Script Rules Contains rules that apply to script files with .ps1, .bat, .cmd, .vbs, and .js extensions
- Packaged App Rules Contains rules that apply to applications purchased through the Windows Store
Each of the rules you create in each of these containers can allow or block access to specific resources, based on one of the following criteria:
- Publisher Identifies code-signed applications by means of a digital signature extracted from an application file. You can also create publisher rules that apply to all future versions of an application.
- Path Identifies applications by specifying a file or folder name. The potential vulnerability of this type of rule is that any file can match the rule, as long as it is the correct name or location.
- File Hash Identifies applications based on a digital fingerprint that remains valid even when the name or location of the executable file changes. This type of rule functions much like its equivalent in software restriction policies; in AppLocker, however, the process of creating the rules and generating file hashes is much easier.

Creating default rules
When enabled, AppLocker blocks all executables, installer packages, and scripts (except for those specified in Allow rules) by default. Therefore, to use AppLocker you must create rules that enable users to access the files needed for Windows and the system’s installed applications to run. The simplest way to do this is to right-click each of the four rules containers and select Create Default Rules from the shortcut menu.
The default rules for each container are standard rules that you can replicate, modify, or delete as necessary. You can also create your own rules, as long as you are careful to provide access to all the resources the computer needs to run Windows.

-----------------

Note: APPLYING APPLOCKER POLICIES
To use AppLocker, the Application Identity service must be running. By default, this service uses the manual startup type, so you must start it yourself in the Services console before Windows can apply the AppLocker policies.

------------------

Creating rules automatically
The greatest advantage of AppLocker over software restriction policies is the ability to create rules automatically. When you right-click one of the rules containers and select Automatically Generate Rules from the shortcut menu, the Automatically Generate Rules Wizard starts.
After specifying the folder to be analyzed and the users or groups to which the rules should apply, you will see a Rule Preferences page, enabling you to specify the types of rules you want to create. The wizard then displays a summary of its results on the Review Rules page and adds the rules to the container.
Creating rules manually
In addition to creating rules automatically, you can do it manually by using a wizard-based interface you activate by selecting Create New Rule from the shortcut menu for one of the rule containers.
The wizard prompts you for the following information:
- Action Specifies whether you want to allow or deny the user or group access to the resource. In AppLocker, explicit deny rules always override allow rules.
-User Or Group Specifies the name of the user or group to which the policy should apply.
- Conditions Specifies whether you want to create a publisher, path, or file hash rule. The wizard generates an additional page for whichever option you select, enabling you to configure its parameters.
- Exceptions Enables you to specify exceptions to the rule you are creating by using any of the three  conditions: publisher, path, or file hash.

Using software restriction policies

The Software Restriction Policies node is found in the Windows SettingsSecurity Settings node of the User Configuration or the Computer Configuration node of a GPO. By default, the Software Restriction Policies folder is empty. When you create a new policy, two subfolders appear: Security Levels and Additional Rules. The Security Levels folder enables you to define the default behavior from which all rules will be created. The criteria for each executable program are defined in the Additional Rules folder.
In the following sections, you learn how to set the security level for a software restriction policy and how to define rules that will govern the execution of program files.

Enforcing restrictions
Prior to creating any rules that govern the restriction or allowance of executable files, it is important to understand how the rules work by default. If a policy does not enforce restrictions, executable files run based on the permissions that users or groups have in the NTFS file system.
When considering the use of software restriction policies, you must determine your approach to enforcing restrictions. There are three basic strategies for enforcing restrictions, as follows:
- Unrestricted This approach enables all applications to run except those that are specifically excluded.
- Disallowed This approach prevents all applications from running except those that are specifically allowed.
- Basic User This approach prevents any applications from running that require administrative rights, but enables programs to run that only require resources that are accessible by normal users.
The approach you take depends on the needs of your particular organization. By default, the Software Restriction Policies area has an Unrestricted value in the Default Security Level setting.

For example, you might want to enable only specified applications to run in a high-security environment. In this case, you would set the Default Security Level to Disallowed. By contrast, in a less secure network, you might want to allow all executables to run unless you have specified otherwise. This would require you to leave the Default Security Level set as Unrestricted.
In this case, you would have to create a rule to identify an application before you could disable it. You can modify the Default Security Level to reflect the Disallowed setting.
Because the Disallowed setting assumes that all programs will be denied unless a specific rule permits them to run, this setting can cause administrative headaches if not thoroughly tested. You should test all applications you wish to run to ensure that they will function properly.

To modify the Default Security Level setting to Disallowed, use the following procedure.
1. In Server Manager, on the Tools menu, select Group Policy Management to open the Group Policy Management console.
2. Expand the forest container and browse to your domain. Then expand the domain container and select the Group Policy Objects folder. The GPOs that currently exist in the domain appear on the Contents tab.

3. Right-click a GPO and select Edit. A Group Policy Management Editor window opens.
4. Browse to the Software Restriction Policies node under either Computer Configuration or User Configuration.
5. Right-click Software Restriction Policies and select New Software Restriction Policies.
The folders containing the new policies appear.
6. In the details pane, double-click Security Levels. Note the check mark on the Unrestricted icon, which is the default setting.
7. Right-click the Disallowed security level and, from the shortcut menu, select Set As Default. A Software Restriction Policies message box appears, warning you of your action.
8. Click Yes, and then close the Group Policy Management Editor and Group Policy Management consoles.
You have now modified the Default Security Level for a software restriction policy.

Configuring software restriction rules
The functionality of software restriction policies depends first on the rules that identify software and then by the rules that govern its usage. When you create a new software restriction policy, the Additional Rules subfolder appears. This folder enables you to create rules that specify the conditions under which programs can be executed or denied. These rules can override the Default Security Level setting when necessary.
You create new rules of your own in the Additional Rules folder using a dialog box like the one shown in Figure 6-15.

FIGURE 6-15 The New Path Rule dialog box

There are four types of software restriction rules that you can use to specify which programs can or cannot run on your network:
- Hash rules
- Certificate rules
- Path rules
- Network zone rules
There is also a fifth type of rule—the default rule—that applies when an application does not match any of the other rules you have created. To configure the default rule, select one of the policies in the Security Levels folder and, on its Properties sheet, click Set As Default.
The functions of the four rule types are explained in the following sections.

HASH RULES
A hash is a series of bytes with a fixed length that uniquely identifies a program or file. A hash value is generated by an algorithm that essentially creates a fingerprint of the file, making it nearly impossible for another program to have the same hash. If you create a hash rule and a user attempts to run a program affected by the rule, the system checks the hash value of the executable file and compares it with the hash value stored in the software restriction policy. If the two match, the policy settings will apply. Therefore, creating a hash rule for an application executable prevents the application from running if the hash value is not correct. Because the hash value is based on the file itself, the file will continue to function if you move it from one location to another. If the executable file is altered in any way, for example, if it is modified or
replaced by a worm or virus, the hash rule in the software restriction policy prevents the file from running.

CERTIFICATE RULES
A certificate rule uses the digital certificate associated with an application to confirm its legitimacy. You can use certificate rules to enable software from a trusted source to run or to prevent software that does not come from a trusted source from running. You can also use certificate rules to run programs in disallowed areas of the operating system.

PATH RULES
A path rule identifies software by specifying the directory path where the application is stored in the file system. You can use path rules to create exceptions that allow an application to execute when the Default Security Level for software restriction policies is set to Disallowed, or you can use them to prevent an application from executing when the Default Security Level for software restriction policies is set to Unrestricted.
Path rules can specify either a location in the file system where application files are located or a registry path setting. Registry path rules provide assurance that the application executables will be found. For example, if an administrator uses a path rule to define a file system location for an application, and the application is moved to a new location, such as during a network restructuring, the original path in the path rule would no longer be valid. If the rule specifies that the application should not function unless it is located in a particular path, the program would not be able to run from its new location. This could cause a significant security breach opportunity if the program references confidential information.

In contrast, if you create a path rule using a registry key location, any change to the location of the application files will not affect the outcome of the rule. This is because when you relocate an application, the registry key that points to the application’s files is updated automatically.

NETWORK ZONE RULES
Network zone rules apply only to Windows Installer packages that attempt to install from a specified zone, such as a local computer, a local intranet, trusted sites, restricted sites, or the Internet. You can configure this type of rule to enable Windows Installer packages to be installed only if they come from a trusted area of the network. For example, an Internet zone rule could restrict Windows Installer packages from being downloaded and installed from the Internet or other network locations.

Using multiple rules
You can define a software restriction policy by using multiple rule types to allow and disallow
program execution. By using multiple rule types, it is possible to have a variety of security levels.
For example, you might want to specify a path rule that prevents programs from running
from the \Server1Accounting shared folder and a path rule that enables programs to run
from the \Server1Application shared folder. You can also choose to incorporate certificate
rules and hash rules into your policy. When implementing multiple rule types, systems apply
the rules in the following order of precedence:
1. Hash rules
2. Certificate rules
3. Network zone rules
4. Path rules
When a conflict occurs between rule types, such as between a hash rule and a path rule, the hash rule prevails because it is higher in the order of preference. If a conflict occurs between two rules of the same type with the same identification settings, such as two path rules that identify software from the same directory, the more restrictive setting will apply. In this case, if one of the path rules were set to Unrestricted and the other to Disallowed, the policy would enforce the Disallowed setting.

Configuring software restriction properties
Within the Software Restriction Policies folder, you can configure three specific properties to provide additional settings that apply to all policies when implemented: Enforcement,Designated File Types, and Trusted Publishers.

ENFORCEMENT PROPERTIES
As shown in Figure 6-16, the Enforcement properties enable you to determine whether the policies apply to all files or whether library files, such as dynamic link library (DLL) files, are excluded. Excluding DLLs is the default. This is the most practical method of enforcement. For example, if the Default Security Level for the policy is set to Disallowed and the Enforcement properties are set to All Software Files, you would have to create a rule that checked every DLL before the program could be allowed or denied. By contrast, excluding DLL files by using the default Enforcement property does not require an administrator to define individual rules for each DLL file.

FIGURE 6-16 Configuring Enforcement properties
DESIGNATED FILE TYPES PROPERTIES
The Designated File Types properties within the Software Restriction Policies folder, as shown in Figure 6-17, specify file types that are considered executable. File types that are designated as executable or program files are shared by all rules, although you can specify a list for a computer policy that is different from one that is specified for a user policy.

FIGURE 6-17 Configuring Designated File Types properties

TRUSTED PUBLISHERS PROPERTIES
Finally, the Trusted Publishers properties enable an administrator to control how systems handle certificate rules. In the Properties dialog box for Trusted Publishers, shown in Figure 6-18, the first setting enables you to specify which users are permitted to manage trusted certificate sources. By default, local computer administrators have the right to specify trusted publishers on the local computer and enterprise administrators have the right to specify trusted publishers in an OU. From a security standpoint, in a high-security network, users should not be allowed to determine the sources from which certificates can be obtained.
The Trusted Publisher Properties sheet also lets you decide if you wish to verify that a certificate has not been revoked. If a certificate has been revoked, the user should not be permitted access to network resources. You have the option of checking either the publisher or the time stamp of the certificate to determine if it has been revoked.

FIGURE 6-18 Configuring Trusted Publishers properties

Understanding User Account Control (UAC)

One of the most common Windows security problems arises from the fact that many users perform their everyday computing tasks with more system access than they actually need.
Logging on as an Administrator or as a user who is a member of the Administrators group grants the user full access to all areas of the operating system. This degree of system access is not necessary to run many of the applications and perform many of the tasks users require every day; it is needed only for certain administrative functions, such as installing systemwide software and configuring system parameters.
For most users, logging on with administrative privileges all the time is just a matter of convenience. Microsoft recommends logging on as a standard user and using administrative privileges only when you need them. However, many technical specialists who do this frequently find themselves encountering situations in which they need administrative access.
There is a surprisingly large number of common, and even mundane, Windows tasks that require administrative access, and the inability to perform those tasks can negatively affect a user’s productivity.
Microsoft decided to address this problem by keeping all Windows Server 2012 R2 users from accessing the system using administrative privileges unless those privileges are required to perform the task at hand. The mechanism that does this is called User Account Control (UAC).

Performing administrative tasks
When a user logs on to Windows Server 2012 R2, the system issues a token, which indicates the user’s access level. Whenever the system authorizes the user to perform a particular activity, it consults the token to see if the user has the required privileges.
In versions of Windows prior to Windows Server 2008 and Windows Vista, standard users received standard user tokens and members of the Administrators group received administrative tokens. Every activity performed by an administrative user was therefore authorized using the administrative token, resulting in the problems described earlier.
On a computer running Windows Server 2012 R2 with UAC, a standard user still receives a standard user token, but an administrative user receives two tokens: one for standard user access and one for administrative user access. By default, the standard and administrative users both run using the standard user token most of the time.
When a standard user attempts to perform a task that requires administrative privileges, the system displays a credential prompt, as shown in Figure 6-12, requesting that the user supplies the name and password for an account with administrative privileges.

FIGURE 6-12 A UAC credential prompt

When an administrator attempts to perform a task that requires administrative access, the system switches the account from the standard user token to the administrative token. This is known as Admin Approval Mode.
Before the system permits the user to employ the administrative token, it might require the user to confirm that he or she is actually trying to perform an administrative task. To do this, the system generates an elevation prompt, as shown in Figure 6-13. This confirmation prevents unauthorized processes, such as those initiated by malware, from accessing the system using administrative privileges.

FIGURE 6-13 A UAC elevation prompt

Using secure desktop
By default, whenever Windows Server 2012 R2 displays an elevation prompt or a credential prompt, it does so by using the secure desktop.
The secure desktop is an alternative to the interactive user desktop that Windows normally displays. When Windows Server 2012 R2 generates an elevation or credential prompt, it switches to the secure desktop, suppressing the operation of all other desktop controls and permitting only Windows processes to interact with the prompt. The object of this is to prevent malware from automating a response to the elevation or credential prompt and bypassing the human reply.

Configuring UAC
Windows Server 2012 R2 enables UAC by default, but it is possible to configure its properties and even to disable it completely. In Windows Server 2012 R2, there are four UAC settings available through the Action Center in Control Panel, as shown in Figure 6-14. The four settings are as follows:
- Always Notify Me
- Notify Me Only When Apps Try To Make Changes To My Computer
- Notify Me Only When Apps Try To Make Changes To My Computer (Do Not Dim My Desktop)
- Never Notify Me

FIGURE 6-14 The User Account Control Settings dialog box

Although the Control Panel provides some control over UAC, the most granular control over UAC properties is through the Security Options node in Group Policy and Local Security Policy.