New book: MCTS Self-Paced Training Kit (Exam 70-642): Configuring Windows Server 2008 Network Infrastructure (2nd Edition)

Article
05/17/2011

We’re pleased to announce that MCTS Self-Paced Training Kit (70-642): Configuring Windows Server 2008 Network Infrastructure (2nd Edition) (ISBN 9780735651609; 752 pages) is available for purchase. This training kit is designed for IT professionals who work in the complex computing environment of medium-sized to large companies and who plan on taking exam 70-642, the required exam for the MCTS certification “Windows Server 2008 Network Infrastructure, Configuring.”

This 2-in-1 kit includes the official Microsoft study guide, plus practice tests on CD to help you assess your skills. It comes packed with the tools and features exam candidates want most—including in-depth, self-paced training based on final exam content; rigorous, objective-by-objective review; exam tips from expert, exam-certified authors; and customizable testing options. It also provides real-world scenarios, case study examples, and troubleshooting labs for the skills and expertise you can use on the job.

You can find the book’s table of contents in this previous post.

Here is an excerpt from this training kit:

Chapter 8 Configuring Windows Firewall and Network Access Protection

By their nature, networks can allow healthy computers to communicate with unhealthy computers and malicious tools to attack legitimate applications. This can result in costly security compromises, such as a worm that spreads rapidly through an internal network or a sophisticated attacker who steals confidential data across the network.

Windows Server 2008 R2 supports two technologies that are useful for improving network security: Windows Firewall and Network Access Protection (NAP). Windows Firewall can filter incoming and outgoing traffic, using complex criteria to distinguish between legitimate and potentially malicious communications. NAP requires computers to complete a health check before allowing unrestricted access to your network and facilitates resolving problems with computers that do not meet health requirements.

This lesson describes how to plan and implement Windows Firewall and NAP using Windows Server 2008 R2.

Exam objectives in this chapter:

Configure Windows Firewall with Advanced Security.
Configure Network Access Protection (NAP).

Lessons in this chapter:

Lesson 1: Configuring Windows Firewall
Lesson 2: Configuring Network Access Protection

Before You Begin

To complete the lessons in this chapter, you should be familiar with Windows networking and be comfortable with the following tasks:

Adding roles to a computer running Windows Server 2008 R2
Configuring Active Directory domain controllers and joining computers to a domain
Configuring a basic network, including configuring IP settings

You will also need the following nonproduction hardware connected to test networks:

A computer named Dcsrv1 that is a domain controller in the Nwtraders.msft domain.
This computer must have at least one network interface that you can connect to either the Internet or a private network.

A computer named Boston that is a member of the Nwtraders.msft domain.

Lesson 1: Configuring Windows Firewall

Windows Firewall filters incoming traffic to help block unwanted network traffic. Optionally, Windows Firewall can also filter outgoing traffic to help limit the risk of malware. Although Windows Firewall’s default settings will work well with components built into Windows, they might prevent other applications from functioning correctly. Windows Firewall’s default settings can also be significantly improved to provide even stronger protection by requiring authorization or limiting the scope of allowed connections.

Why Firewalls Are Important

In networking, firewalls analyze communications and drop packets that haven’t been specifically allowed. This is an important task, because connecting to the Internet means any of the millions of other Internet-connected computers can attack you. A successful compromise can crash a service or computer, compromise confidential data, or even allow the attacker to take complete control of the remote computer. In the case of worms, automated software attacks computers across the Internet, gains elevated privileges, copies itself to the compromised computer, and then begins attacking other computers (typically at random).

The purpose of a firewall is to drop unwanted traffic, such as traffic from worms, while allowing legitimate traffic, such as authorized file sharing. The more precisely you use firewall rules to identify legitimate traffic, the less you risk exposure to unwanted traffic from worms.

Firewall Profiles

When you create firewall rules to allow or block traffic, you can separately apply them to the Domain, Private, and Public profiles. These profiles enable mobile computers to allow incoming connections while connected to a domain network (for example, to allow incoming Remote Desktop connections) but block connection attempts on less secure networks (such as public wireless hotspots).

The firewall profiles are:

Domain Applies when a computer is connected to its Active Directory domain. Specifically, any time a member computer’s domain controller is accessible, this profile will be applied.
Private Applies when a computer is connected to a private network location. By default, no networks are considered private—users must specifically mark a network location, such as their home office network, as private.
Public The default profile applied to all networks when a domain controller is not available. For example, the Public profile is applied when users connect to Wi-Fi hotspots at airports or coffee shops. By default, the Public profile allows outgoing connections but blocks all incoming traffic that is not part of an existing connection.

Most servers are always connected to a domain environment. To ensure consistent operation even when a domain controller is not available, configure the same firewall rules for all three profiles when configuring a server.

Filtering Inbound Traffic

By default, Windows Firewall (as well as most other firewalls) blocks any inbound traffic that hasn’t been specifically allowed. By default, the Public profile allows absolutely no incoming connections—this provides excellent security when connecting to public hotspots or other untrusted networks. The Domain and Private profiles allow some incoming connections, such as connections for file and printer sharing.

If you install or enable a Windows feature that requires incoming connections, Windows
will automatically enable the required firewall rules. Therefore, you do not need to manually adjust the firewall rules. Figure 8-1 shows the default inbound firewall rules for a Windows Server 2008 R2 computer configured as a domain controller. As you can see, rules exist to allow each of the protocols required for a domain controller.

If you install an application that does not automatically enable the required firewall rules,
you will need to create the rules manually. You can create firewall rules by using the standalone Windows Firewall With Advanced Security console, or you can apply the rules with Group Policy by using the same interface at Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall With Advanced Security\Windows Firewall With Advanced Security.

To create an inbound filter, follow these steps:

1. In the Windows Firewall With Advanced Security snap-in, right-click Inbound Rules, and then choose New Rule. The New Inbound Rule Wizard appears.

2. On the Rule Type page, select one of the following options, and then click Next:

Program A rule that allows or blocks connections for a specific executable file,
regardless of the port numbers it might use. You should use the Program rule type
whenever possible. The only time it’s not possible to use the Program rule type is when a service does not have its own executable.
Port A rule that allows or blocks communications for a specific TCP or UDP port
number, regardless of the program generating the traffic.
Predefined A rule that controls connections for a Windows component, such as
Active Directory Domain Services, File And Printer Sharing, or Remote Desktop.
Typically, Windows enables these rules automatically.
Custom A rule that can combine program and port information.

3. Complete the page or pages that appear after you select one of the rule types. The
page or pages you see will vary depending on the rule type you selected. Click Next.

4. On the Action page, select one of the following options, and then click Next.

Allow The Connection Allows any connection that matches the criteria you specified
on the previous pages.
Allow The Connection If It Is Secure Allows connections that match the criteria you specified on the previous pages only if those connections are protected with IPsec. Optionally, you can select the Require The Connections To Be Encrypted check box, which requires encryption in addition to authentication. Selecting the Override Block Rules check box configures the rule to take precedence over other rules that
might prevent a client from connecting. If you select this rule type, the wizard will
also prompt you to select users and computers that are authorized to establish this
type of connection.
Block The Connection Drops any connection attempt that matches the criteria
you specified on the previous pages. Because inbound connections are blocked by
default, you rarely need to create this rule type. However, you might use this action
for an outbound rule if you specifically want to prevent an application from initiating
outgoing connections.

5. On the Profile page, choose which profiles to apply the rule to. For most servers, you should apply the rule to all three profiles, because servers are usually continually connected to a single network. For mobile computers in domain environments, you typically need to apply firewall rules only to the Domain profile. If you do not have an Active Directory domain or if users need to use the firewall rule when connected to their home networks, apply the rule to the Private profile. Avoid creating firewall rules on mobile computers for the Public profile, because an attacker on an unprotected network might be able to exploit a vulnerability exposed by the firewall rule. Click Next.

6. On the Name page, type a name for the rule, and then click Finish.

The inbound rule takes effect immediately, allowing incoming connections that match the criteria you specified.

Filtering Outbound Traffic

By default, Windows Firewall allows all outbound traffic. Allowing outbound traffic is much less risky than allowing inbound traffic. However, outbound traffic still carries some risk:

If malware infects a computer, it might send outbound traffic containing confidential data (such as content from a Microsoft SQL Server database, email messages from a Microsoft Exchange server, or a list of passwords).
Worms and viruses seek to replicate themselves. If they successfully infect a computer, they will attempt to send outbound traffic to infect other computers. After one computer on an intranet is infected, network attacks can allow malware to rapidly infect computers on an intranet.
Users might use unapproved applications to send data to Internet resources and either knowingly or unknowingly transmit confidential data.

By default, all versions of Windows (including Windows Server 2008 R2) do not filter outbound traffic. However, Windows Server 2008 R2 does include outbound filters for core networking services, enabling you to quickly enable outbound filtering while retaining basic network functionality. By default, outbound rules are enabled for:

Dynamic Host Configuration Protocol (DHCP) requests
DNS requests
Group Policy communications
Internet Group Management Protocol (IGMP)
IPv6 and related protocols

Blocking outbound communications by default will prevent many built-in Windows features, and all third-party applications you might install, from communicating on the network. For example, Windows Update will no longer be able to retrieve updates, Windows will no longer be able to activate across the Internet, and the computer will be unable to send Simple Network Management Protocol (SNMP) alerts to a management host.

If you do enable outbound filtering, you must be prepared to test every application to verify that it runs correctly. Most applications are not designed to support outbound filtering and will require you to both identify the firewall rules that need to be created and then create those rules.

To create an outbound filter, follow these steps:

1. In Windows Firewall With Advanced Security (which you can access in Server Manager under Configuration), right-click Outbound Rules, and then choose New Rule. The New Outbound Rule Wizard appears.

2. On the Rule Type page, select a rule type (as described in the section “Filtering Inbound Traffic” earlier in this lesson), and then click Next.

3. On the Program page, click This Program Path. In the text box, type the path to the
application’s executable file. Click Next.

4. On the Action page, select an action type (as described in the section “Filtering Inbound Traffic” earlier in this lesson), and then click Next.

5. On the Profile page, select the check boxes for the profiles that you want to apply the
rule to, and then click Next.

6. On the Name page, type a name for the rule, and then click Finish.

The outbound rule takes effect immediately, allowing outgoing packets that match the
criteria you specified.

To block outbound connections by default, first create and enable any outbound firewall
rules so that applications do not immediately stop functioning. Then, follow these steps:

1. In Server Manager, right-click Configuration\Windows Firewall With Advanced Security, and then choose Properties.

2. Click the Domain Profile, Private Profile, or Public Profile tab.

3. From the Outbound Connections drop-down list, select Block. If necessary, return to
the previous step to block outbound traffic for other profiles. Then click OK.

You will need to perform extensive testing to verify that all required applications function correctly when outbound connections are blocked by default. This testing should include background processes, such as Automatic Updates.

Configuring Scope

One of the most powerful ways to increase computer security is to configure firewall scope. Using scope, you can allow connections from your internal network and block connections from external networks. Scope can be used in the following ways:

For a server that is connected to the Internet, you can allow anyone on the Internet to connect to public services (such as the web server) while allowing only users on your internal network to access private servers (such as Remote Desktop).
For internal servers, you can allow connections only from the specific subnets that contain potential users. When planning such scope limitations, remember to include remote access subnets.
For outgoing connections, you can allow an application to connect to servers only on specific internal subnets. For example, you might allow SNMP traps to be sent to only your SNMP management servers. Similarly, you might allow a network backup application to connect to only your backup servers.
For mobile computers, you can allow specific communications (such as Remote Desktop) from only the subnets you use for management.

To configure the scope of a rule, follow these steps:

1. In the Windows Firewall With Advanced Security snap-in, select Inbound Rules or Outbound Rules.

2. In the details pane, right-click the rule you want to configure, and then choose Properties.

3. Click the Scope tab. In the Remote IP Address group, select These IP Addresses.

4. In the Remote IP Address group, click Add.

5. In the IP Address dialog box, select one of the following three options, and then click OK:

This IP Address Or Subnet Type an IP address (such as 192.168.1.22) or a subnet
using Classless Inter Domain Routing (CIDR) notation (such as 192.168.1.0/24) that
should be allowed to use the firewall rule.
This IP Address Range Using the From and To boxes, type the first and last IP
address that should be allowed to use the firewall rule.
Predefined Set Of Computers Select a host from the list: Default Gateway, WINS
Servers, DHCP Servers, DNS Servers, and Local Subnet.

6. Repeat steps 4 and 5 for any additional IP addresses that should be allowed to use the firewall rule, and then click OK.

Authorizing Connections

If you are using IPsec connection security in an Active Directory environment, you can also require the remote computer or user to be authorized before a connection can be established.

For example, imagine that your organization had a custom accounting application that used TCP port 1073, but the application had no access control mechanism—any user who connected to the network service could access confidential accounting data. Using Windows Firewall connection authorization, you could limit inbound connections to users who are members of the Accounting group—adding access control to the application without writing any additional code.

Most network applications do have access control built in, however. For example, you can configure Internet Information Server (a web server installed as part of the Application Server role) to authenticate users and allow only authorized users to connect to a web application. Similarly, if you share a folder on the network, you can use file permissions and share permissions to restrict who can access the folder. Application-layer authorization should always be your first layer of security; however, connection authorization using Windows Firewall can provide an additional layer of security. Using multiple layers of security—a technique known as defense-in-depth—reduces risk by providing protection even when one layer has a vulnerability.

To configure connection authorization for a firewall rule, follow these steps:

1. In Server Manager, select Configuration\Windows Firewall With Advanced Security\Inbound Rules or Configuration\Windows Firewall With Advanced Security\Outbound Rules.

2. In the details pane, right-click the rule you want to configure, and then choose Properties.

3. Click the General tab. Select Allow Only Secure Connections. Because the authorization relies on IPsec, you can configure authorization only on secure connections.

4. Click the Users And Computers tab for an inbound rule or the Computers tab for an
outbound rule. Select the proper options based on the rule you selected:

To allow connections only from specific computers Select the Only Allow
Connections From These Computers check box for an inbound rule or the Only
Allow Connections To These Computers check box for an outbound rule.
To allow connections only from specific users If you are editing an inbound rule,
select the Only Allow Connections From These Users check box. You can use this
option only for inbound connections.

5. Click Add and select the groups containing the users or computers you want to authorize. Figure 8-2 shows how the Users And Computers tab appears after you have configured connections for an inbound rule. Click OK.

6. Click OK again.

Any future connections that match the firewall rule will require IPsec for the connection to be established. Additionally, if the authenticated computer or user is not on the list of authorized computers and users that you specified, the connection will be immediately dropped.

Configuring Firewall Settings with Group Policy

You can configure Windows Firewall locally, by using Server Manager or the Windows Firewall With Advanced Security console in the Administrative Tools folder; or globally, by using the Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall With Advanced Security\Windows Firewall With Advanced Security node of a Group Policy Object (GPO). Typically, you edit server-specific policies (such as configuring the range of IP addresses a DNS server accepts queries from) by using local tools, and you configure policies that apply to groups of computers (including IPsec connection security policies) by using GPOs.

You can use Group Policy to manage Windows Firewall settings for computers running Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 by using two nodes:

Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall With Advanced Security\Windows Firewall With Advanced Security This node applies settings only to computers running Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 and provides exactly the same interface as the same node in Server Manager. You should always use this node when configuring computers running these recent versions of Windows because it provides for more detailed configuration of firewall rules.
Computer Configuration\Policies\Administrative Templates\Network\Network Connections \Windows Firewall This node applies settings to computers running Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2. This tool is less flexible than the Windows Firewall With Advanced Security console; however, settings apply to all versions of Windows that support Windows Firewall. If you are not using the new IPsec features in recent versions of Windows, you can use this node to configure all your clients.

For best results, create one GPO for Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008, and create a second GPO for Windows Server 2003 and Windows XP. Then, use WMI filters to target the GPOs to computers running only the appropriate version of Windows.

Enabling Logging for Windows Firewall

If you are ever unsure about whether Windows Firewall is blocking or allowing traffic, you should enable logging, re-create the problem you’re having, and then examine the log files.

To enable logging, follow these steps:

1. In the console tree of the Windows Firewall With Advanced Security snap-in, right-click Windows Firewall With Advanced Security, and then choose Properties. The Windows Firewall With Advanced Security Properties dialog box appears.

2. Select the Domain Profile, Private Profile, or Public Profile tab.

3. In the Logging group, click the Customize button. The Customize Logging Settings
dialog box appears.

4. To log packets that Windows Firewall drops, from the Log Dropped Packets drop-down list, select Yes. To log connections that Windows Firewall allows, from the Log Successful Connections drop-down list, select Yes.

5. Click OK.

By default, Windows Firewall writes log entries to %SystemRoot%\System32\LogFiles\Firewall\Pfirewall.log and stores only the last 4 KB of data. In most production environments, this log will be almost constantly written to, which can cause a performance impact. For that reason, you should enable logging only when actively troubleshooting a problem and then immediately disable logging when you’re finished.

Identifying Network Communications

The documentation included with network applications often does not clearly identify the
communication protocols the application uses. Fortunately, creating Program firewall rules allows any communications required by that particular program.

If you prefer to use Port firewall rules, or if you need to configure a network firewall that can identify communications based only on port number and the application’s documentation does not list the firewall requirements, you can examine the application’s behavior to determine the port numbers in use.

The simplest tool to use is Netstat. On the server, run the application, and then run the
following command to examine which ports are listening for active connections:

Any rows in the output with a State of LISTENING are attempting to receive incoming connections on the port number specified in the Local Address column. The executable name listed after the row is the executable that is listening for the connection. For example, the following output demonstrates that RpcSs, running under the SvcHost.exe process (which runs many services), is listening for connections on TCP port 135.

Similarly, the following output demonstrates that the DNS service (Dns.exe) is listening for connections on TCP port 53:

Although Windows Firewall has existing rules in place for these services (because they are built into Windows), the same technique would allow you to identify the port numbers used by any third-party application.