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:
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:
Lessons in this chapter:
To complete the lessons in this chapter, you should be familiar with Windows networking and be comfortable with the following tasks:
You will also need the following nonproduction hardware connected to test networks:
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.
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.
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:
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.
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:
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.
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.
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:
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:
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.
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.
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:
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:
6. Repeat steps 4 and 5 for any additional IP addresses that should be allowed to use the firewall rule, and then click OK.
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.
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:
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.
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:
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.
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.
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.
What about the second edition for 70-640?
The second edition of 70-640 will be released in July 2011.