Firewall Management
Firewall management with Windows Vista will require some thought. Not only do you need to think about what you want to accomplish, but there are several different interfaces, and it is not always intuitive which one you should use. In this section, we will try to resolve some of the confusion and explain how to manage the firewall in various scenarios.
Firewall Profiles
One of the main complaints over ICF was that you could not configure the system to behave differently if the computer were inside the corporate network versus if it were not. In Windows XP SP2, Microsoft "borrowed" a concept that many other personal firewalls were already using and introduced firewall profiles. In Windows Vista this concept is further extended. This is probably the first thing users notice about the firewall because already during setup they will be asked to select a firewall profile for the current network, as shown in Figure 1.
The two profiles in Windows XP SP2 were the domain profile and the standard profile. The domain profile was automatically invoked when the computer could find a domain controller; otherwise the standard profile was used. This functionality gave powerful control for a security administrator. It meant that the system could be locked down completely when the user was roaming, while still allowing all the remote management functionality needed on the organizational network. However, it presented certain problems for some users, notably those that had networks at their homes, but without a domain. Since the standard profile was always used if the system was unable to reach the domain controller, it means the system would be locked down also from computers at the user's home.
Windows Vista resolves this issue by introducing a third profile: the private profile. Both the Home and Work profiles in Figure 1 actually map to the private profile. The Domain profile is not shown in the dialog box because it would be automatically selected if the computer can reach a domain controller. The Public location maps to the public profile, which has taken the place of the standard profile from Windows XP.
When you connect the computer to a new network, it will ask you whether that network is public or private and configure the system appropriately. It remembers this selection each time you connect to that network, based on network parameters presented to it by the infrastructure servers on the network.
This is not foolproof functionality by any means, but it does help. It is now possible to have a public profile that turns the computer into a black hole, while still allowing users to have some networking functionality at home. We have one big concern with this though.
The problem centers on the connotation of the word "home." As you can see, the dialog box in Figure 1 does not exactly give the user a lot of information on how to make an intelligent security decision. Far too many users still have no firewall in their house, or it is not configured properly. It does not take much to imagine a Holiday scenario where a user plugs his shiny new Windows Vista computer directly into his cable modem. Windows Vista comes up and asks what type of network it is on. The user looks around, sees the dog eating the couch, big brother tugging at little sister's hair, grandmother pouring brandy into her egg-nog,, and grandpa hard at work breaking junior's new train set. With a big sigh, the user clicks Home and opens his shiny new computer to the big bad Internet, when the appropriate option would have been Public.
By default, all networks are in the public profile until the computer is configured otherwise, or until a domain controller is detected. Manually setting the profile to anything other than public requires administrative privileges.
The detection logic for whether the system is on the domain has been much improved. There is a new Network List Service (NLS) which is integrated with Network Location Awareness (NLA). It notifies the firewall each time NLA detects a change in the network. This results in a faster and more reliable transition. The transition happens within 200 milliseconds of a change in network status. The net effect is that fewer computers are using the public or private profiles when they are actually on the domain.
A common question is what happens if a host is connected to the domain with only one of several interfaces, or more generally, what if two interfaces in the host are on different network categories. The profiles have a precedence order based on which is considered to be more restrictive. The order, from least to most restrictive, is domain, private, public. Thus, let's say a computer has two network interfaces. One of them can see the domain controller. The other interface can not see the DC, nor has it been assigned to a private network. The second interface would therefore be in the public profile, and in this case the firewall will use the public profile for all interfaces. This behavior holds even if the computer is on a VPN connection. The most restrictive profile would still be used. Therefore, if you wish to allow certain traffic into the computer when it is connected via VPN, you must create rules in the public and private profiles that apply only to VPN interfaces. We will discuss that in more detail later.
Management Interfaces
Management of Windows Firewall has become much more complex with all the new features. Perhaps the biggest complication is that there are a number of new management interfaces available. In this section, we briefly introduce each of them. In later sections, we show how to manage the firewall with them.
Windows Firewall Control Panel
The Windows Firewall control panel, shown in Figure 2, is the simplest of the interfaces. It enables you to see the current configuration of the firewall and also presents links on the left that enable you to do basic management.
The Windows Firewall control panel allows non-administrators to very quickly see the status of the firewall. However, any modification of the firewall requires administrative privileges,. This is evident from the presence of the little shield icon on the links. All three links (Change settings, Turn Windows Firewall on or off, and Allow a program through Windows Firewall) open the Windows Firewall Settings dialog box, shown in Figure 3.
The Windows Firewall Settings dialog box is almost identical to the Windows Firewall control panel in Windows XP. Some of the language has changed, and on the advanced tab the Security Logging, and ICMP settings are gone.
The Windows Firewall control panel is primarily used for very simple operations and is really designed for home users to see a quick overview of the state of the firewall. It only shows settings for the currently active profile, for instance. While you can add basic rules in the control panel, we recommend you use a more powerful and flexible interface. You really get the feeling after a while that the Windows Firewall control panel primarily exists because people are familiar with using it. It no longer provides any compelling functionality.
Security Center
Security Center, shown in Figure 4, provides similar information to the Windows Firewall control panel. It is also designed primarily for home users, but gives a better overview of the aggregate security state of the system.
The Security Center uses the new style for control panel applets and presents links to related options in the left-hand pane. If you click the Windows Firewall link, you get to the Windows Firewall control panel.
We should note that the reason the malware protection status in Figure 4 is yellow is that the system in the screenshot is an almost completely clean installation of Windows Vista, which does not come with an antivirus program. We do not necessarily recommend that you keep it that way.
Windows Firewall with Advanced Security
The most powerful of all the interfaces for managing Windows Firewall is the Windows Firewall with Advanced Security MMC snap-in, wf.msc. It is available under the Administrative Tools folder and is the first time we really notice all the new features in the firewall. The introductory screen is shown in Figure 5. In subsequent sections, we take a deeper look at how to use this interface.
Group Policy Editor
The settings in the Windows Firewall with Advanced Security snap-in are also available in Group Policy. Figure 6 shows the first screen of the Group Policy interface in a beta copy of Windows Longhorn Server.
For backward compatibility, the settings to configure the Windows Firewall in Windows XP SP2 and Windows Server 2003 Service Pack 1 (SP1) and higher are also present in Group Policy in Windows Longhorn Server. The root of those settings is shown in Figure 7.
Unless you have Windows XP SP2 and Server 2003 SP1+ computers in your environment, you should not configure the older settings. Stick with the new ones. In the section on management in a mixed Windows XP and Windows Vista environment, we will look at how the interoperability works.
Netsh
Netsh is a command line tool that has been available in several versions of Windows now. Netsh operates on a menu-based principle with contexts that contain commands and more contexts. To launch netsh just type netsh at a command prompt.
There are several contexts that are related to the firewall:
-
advfirewall: This is the context used to manage the Windows Vista firewall. It allows you to manage the new features that were not available in Windows XP.
-
ipsec: This context allows you to manage IPsec rules. It existed also in Windows Server 2003, but not in Windows XP. The commands are the same as in Windows Server 2003.
-
consec: Connection security rules (also IPsec filters) are managed in the advfirewall consec context.
-
firewall: This context existed in Windows XP and Server 2003 as well. You can perform the same tasks in the "advfirewall firewall" context-but it is highly recommended that you do not use it! Rules set in the firewall context are configured using the old Windows XP SP2 mechanisms, and do not comply with the new profiles in Windows Vista. The firewall context is included primarily for backward compatibility with old scripts.
Nobody ever accused netsh of being a simplistic tool. It is quite complicated, and extremely powerful. The number of times you use it depends entirely on your management style, as there are numerous other tools, however, which can perform the same tasks. For good measure, we will use it later to configure a rule as a way to demonstrate what it can do.
Application Programming Interfaces
The firewall obviously comes with a set of Application Programming Interfaces (API) you can use to programmatically configure the firewall. These are primarily designed for third-party developers who need to configure the firewall to allow their programs, or who wish to provide status information on the firewall. However, they can also be used by administrators who are interested in the same type of features. You may, for instance, want to create a VPN logon script that queries whether the firewall is active or not, and turns it on if it is not. Here is a VBScript that will do that:
'IsFirewallActive.vbs
option explicit
Dim CurrentProfile
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
CurrentProfile = fwPolicy2.CurrentProfileTypes
if fwPolicy2.FirewallEnabled(CurrentProfile) <> TRUE then
WScript.Echo("Windows Firewall is disabled.")
fwPolicy2.FirewallEnabled(CurrentProfile) = TRUE
WScript.Echo("WindowsFirewall is now on")
else
WScript.Echo("Windows Firewall is enabled.")
end if
You may also want to find out which profile is active. Here is a sample VBScript that tells you:
' WhichFWProfile.vbs
Option Explicit
Dim CurrentProfile
Dim Message
' The profiles are bitmasks with the following values
Const NET_FW_PROFILE2_DOMAIN = 1
Const NET_FW_PROFILE2_PRIVATE = 2
Const NET_FW_PROFILE2_PUBLIC = 4
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
CurrentProfile = fwPolicy2.CurrentProfileTypes
Message = "The following firewall profile(s) is/are currently active" + vbCrLf
if(CurrentProfile AND NET_FW_PROFILE2_DOMAIN) then
Message = Message + vbCrLf + "The Domain profile"
end if
if(CurrentProfile AND NET_FW_PROFILE2_PRIVATE) then
Message = Message + vbCrLf + "The Private profile"
end if
if(CurrentProfile AND NET_FW_PROFILE2_PUBLIC) then
Message = Message + vbCrLf + "The Public profile"
end if
WScript.Echo Message
Both of these scripts are available on the Web site accompanying the book. Full details on how to program to the Windows Firewall, along with many more samples, are available in the MSDN library, at http://www.msdn.microsoft.com/library/en-us/ics/ics/using_windows_firewall_with_advanced_security.asp.
Rule Types
There are several ways to categorize rules in the Windows Firewall. On the one hand, we have per-program rules versus per-port rules. On the other hand, we can distinguish between rules that filter based on ports, and those that filter based on other traffic parameters, such as which computer is on the other side of the connection. Historically, the former has been performed by stateful firewalls, although they could of course also put an IP address or a hostname into the rule as a way to restrict the traffic from going only to certain computers. However, an IP address is a very poor authentication token since it can be changed, or spoofed. A much better one is a digital certificate or other cryptographic authentication token. Rules that filter on those were the domain of IPsec until Windows Vista.
As mentioned earlier, the firewall and IPsec have now been combined. Within the Windows Firewall you can create standard firewall rules, which we will refer to as "directional rules" here (Microsoft calls them "firewall rules" but we find that term confusing since all rules are specified within the firewall). Within the same interface you can also create connection security rules that are used to limit connections to only particular hosts or even users. With the integration of IPsec and the firewall, you can control connections down to the individual user. Figure 8 shows the dialog box that controls this.
To get to this dialog box you would right-click the inbound rule you want, select properties, and then go to the Users and Computers tab. You can only configure authorized users on inbound rules and obviously only if you allow only authenticated traffic. Two additional items must also be present for peruser rules to work. First, you must have a connection security rule-or some other IPsec policy-that defines this traffic. Second, the IPsec rule must use credentials that carry Active Directory user information, such as Kerberos or certificates with a certificate-to-account mapping.
Directional Rules
You would normally configure directional rules in the Windows Firewall with Advanced Security, although you can configure them in the Windows Firewall Settings dialog box as well. The drawback of using the Windows Firewall Settings dialog box is that you give up control. For example, if you allow a program to listen, it allows the program to listen on any port, TCP and UDP, but only in the current profile.
With the Windows Firewall with Advanced Security interface you get tremendous control over the rules. This allows you to solve problems that were previously unsolvable. Later we will use the ability to permit traffic only over certain interface types to allow management traffic over a VPN connection.
The types of things you can do with directional rules are more or less what you would expect. You get full five-tuple configuration: local program, local address/interface, local port, remote address, and remote port. You also get the ability to bind an IPsec policy to the rule, allowing you to require authentication of the remote address and, optionally, encryption. If you elect to use authenticated traffic, the rule uses IPsec with Encapsulating Security Payload (ESP) but without an encryption key (ESP NULL). This saves processing time and permits you to use normal network monitoring tools to inspect traffic.
You may recall that there is an authentication header (AH) option on IPsec. However, AH cannot traverse network address translation boundaries and is opaque to most management tools. Therefore, it is rarely used.
Connection Security Rules
Connection security rules define the protection parameters for connections between computers. To draw an analogy, the directional rules are essentially your traditional firewall rules, whereas the connection rules, which govern encryption and authentication, are like the IPsec rules used in conjunction with the firewall in Windows XP SP2.
By combining the firewall with IPsec into the same interface several very interesting scenarios are enabled. One of the most valuable is the ability to isolate systems from one another and permit only the communications patterns you need in your network. Microsoft calls this Server and Domain Isolation.
For some systems you cannot enforce authentication. For instance, for DNS resolution, you probably do not want to require authentication. For those systems, you need an authentication exemption rule. An authentication exemption rule is exactly what it sounds like-it exempts the traffic from IPsec requirements.
A server to server rule is a bit misnamed in the sense that it might be used with clients as well, although it is more commonly used with servers. It simply sets up the authentication parameters for a connection. This is different than an isolation rule. Not only does an isolation rule require authentication, it also requires fulfillment of some additional criteria, such as domain membership or health state.
Tunnel rules will likely be rarely used with Windows Vista. A tunnel rule defines a site-to-site VPN and is used to define the tunnel between the gateways. It is unlikely that Windows Vista will be used in a gateway capacity.
Finally, you can create a fully custom rule. Selecting this option gives you the ability to customize all the parameters of the rule.
When to Use Which Rules
Generally speaking, directional rules define which traffic is allowed. Connection security rules define how the traffic that is allowed is authenticated and/or encrypted. You typically use directional rules to permit the services you need and optionally specify authentication requirements on them. You use connection security rules to enable the authentication.
Rule Precedence
The rule precedence order is a bit complicated at first glance, but the key to understanding it is really to forget about ordering. It is really a matching issue, not so much ordering. Take inbound traffic, as an example. Inbound traffic is blocked by default if it does not match any rule that allows it. While you may consider this to be an ordering that says "Allow rules are considered first," that would be incorrect. If a specific packet is matched by both an allow rule and a block rule, the block rule has priority. That means that the ordering, simplistically, is as follows:
-
Block rules: If a packet or connection matches one of these, it is discarded.
-
Allow rules: If a packet or connection matches one of these, it is allowed.
-
Default directional profile behavior: If no block or allow rules match, the traffic is treated according to the behavior specified as the default for traffic in that direction in that profile. In the inbound direction in all profiles that means blocking the traffic in a default configuration.
You also have to add authenticated bypass (IPsec) rules to this, which allows authenticated traffic to always reach the system. This enables you to easily block traffic from unauthenticated hosts, while allowing it from everyone else. You can consider that rule 0, if you will. In other words, the complete rule order list is:
-
Authenticated bypass rules
-
Block rules
-
Allow rules
-
Default directional profile behavior
It does not really matter if there are multiple rules within each class that match the traffic pattern. As soon as any rule matches, processing stops and the traffic is allowed or blocked depending on the rule.
Firewall Scenarios
Now that we have gone over the basic management interfaces, we can look at some scenarios. We cannot cover all possible scenarios where you might want to use the Windows Firewall, but we can certainly go over a few common and valuable ones, demonstrating different functionality in the process.
Restricting Access Based on End-Point
The first thing you might want to do is to open up a port for only a particular host. For instance, maybe you are hosting a SQL Server, but you only want a particular middleware server to connect to it. You can build a rule to allow this a few different ways. One is to build a program rule-a rule that ties it to a particular program, SQL Server in this case. The other is to build a port rule-a rule that ties it to a particular port. Generally, if you can tie it to a program you are better off. The firewall will only open the port to that particular program, which means that if the program is not running, the port is closed. If the program is running, only that program gets to listen on the port. By contrast, when you open a port, the port is always open, regardless of whether you need it or not. The ability to restrict access to specific programs is one advantage of a host-based firewall.
To get started open the Windows Firewall with Advanced Security interface, click Inbound Rules, and click New Rule under the Actions. We are greeted with the dialog box in Figure 9.
Select Program and click next. You now have to define which program you wish to apply the rule to, as shown in Figure 10.
We want to open a port for Microsoft SQL Server 2005, so we will enter the path to the executable for the default instance. Click next and you get asked whether you wish to use IPsec to authenticate the connection. We do, but we do not need encryption, as we are pretty certain the channel is secure and traffic cannot be intercepted and decoded. This is shown in Figure 11.
Figure 11 shows only the directional rule that specifies whether we will accept the connection or not. In order for traffic authentication to actually take place, and for the traffic to actually be allowed in, we also need to create a connection security rule. We will do that later.
When you click Next you get to finally specify which computers, and optionally, from which users you wish to allow these connections, as shown in Figure 12.
Keep in mind at the stage shown in Figure 12 that when you create the connection security rule, you must select an authentication method that contains the Active Directory account information for the objects you wish to allow. Generally, that means you have to use either Kerberos or certificates with a certificate-to-account mapping.
Click Next again and you get to decide which profile you wish to allow this traffic in. Since we are requiring IPsec authentication, there is no harm in allowing it in all three, as shown in Figure 13.
When you click Next, you get to pick a name for the rule, and then you are done with the directional rule portion. Now you need to configure the corresponding connection security (IPsec) rule. To do so, start out by clicking Connection Security Rules in the left-hand pane and then click New Rule under Actions. You will get the dialog box, as shown in Figure 14.
You can use either a server-to-server rule or an isolation rule. The remaining steps are almost identical between the two. Let us pick a server-to-server rule to ensure that we cover all the bases. Select that and click Next. At this point you need to define the two end-points. We do not really care about the end-points in this case since we already specified them in our directional rule. All we really need to do is ensure that the computer will request IPsec authentication. Therefore, we leave the end-points as Any IP address, shown in Figure 15.
We now need to select when we want the connection authenticated. We do not require all connections to be authenticated. We only want to enable authentication so we can restrict traffic as per our directional rule. Therefore, we select "Request authentication on inbound and outbound connections" in Figure 16.
Next, we get to select our authentication methods. We are in a domain environment, so we wish to use Kerberos. The authentication method dialog box, in Figure 17, does not include Kerberos as a choice. If we picked an isolation rule in Figure 14, it would have included Kerberos, but because we used a server-to-server rule we must customize the options, as shown in Figure 18.
To use Kerberos, click the Customize button. This brings up a dialog box, as shown in Figure 18, where you get to choose which authentication methods you wish to use. Click Add in the first authentication method dialog box and select Computer (Kerberos V5). Click OK to close the dialog box.
You now click Next and select which profiles the rule is used in. Then save the rule and you are finished. It is a bit complicated, but if you ever tried to configure IPsec rules, and particularly IPsec rules in conjunction with firewall rules in older versions of Windows, you can surely appreciate just how radical a departure this new interface is. The IPsec configuration wizard in Windows 2000–2003 was virtually the poster child for user unfriendliness. The new wizards have some way to go, but are a very welcome change indeed.
Blocking Outbound SMB in Public Profile
The ability to tie authentication rules to a particular type of network prevents the system from volunteering too much information and trying to connect to systems on untrusted networks. This is really one of the areas where the integration of the firewall and IPsec starts paying off.
Using these new rules, you can also provide some restrictions that were not previously possible. For instance, for many years attackers have been attempting luring attacks to get users to make SMB (Windows networking) connections to untrusted hosts, thereby forcing an authentication sequence giving them a challenge response pair that can be used to crack passwords. Older versions of this attack were also used to downgrade to clear-text authentication, or to "reflect" the user's challenge-response pair back to the originating computer. The former attack was broken years ago, and the latter in Windows XP SP2, but volunteering challenge-response pairs is nevertheless unwise.
To prevent this, you could use another new function in the Windows Vista firewall-outbound filtering. An administrator could decide, for instance, to block all outbound SMB connections (those terminating at ports TCP 135, 139, 445, and UDP 137, 138, 445) in the public profile. This would prevent a computer from being accidentally used in a luring attack to gain challenge-response pairs. Again, this is certainly not foolproof functionality. For example, if the computer has already been compromised, this rule would not stop it from communicating out, as the attacker can simply disable the rule. However, as a measure that protects well-behaved but potentially exposed computers, particularly those with users prone to be easily lured into connecting to rogue sites, it could be useful.
Because we have already used the wizard to configure one rule, we will use the netsh tool to configure this one. The requirements are quite simple. We wish to block traffic destined for any computer on ports TCP 139, 445; UDP 137, 138, 445. For good measure we will also block RPC end-point mapper traffic, traffic going to port 135. To do this we use the netsh advfirewall firewall context, and the add command, which has this syntax:
add rule name=
dir=in|out
action=allow|block|bypass
[program=]
[service=|any]
[description=]
[enable=yes|no (default=yes)]
[profile=public|private|domain|any[,...]]
[localip=any||
|||]
[remoteip=any|localsubnet|dns|dhcp|wins|defaultgateway|
||||]
[localport=0-65535|RPC|RPC-EPMap|any[,...] (default=any)]
[remoteport=0-65535|any[,...] (default=any)]
[protocol=0-255|icmpv4|icmpv6|icmpv4:type,code|icmpv6:type,code|
tcp|udp|any (default=any)]
[interfacetype=wireless|lan|ras|any]
[rmtcomputergrp=]
[rmtusrgrp=]
[edge=yes|no (default=no)]
[security=authenticate|authenc|notrequired (default=notrequired)]
We actually need to run two commands. We can specify several ports, but not several port/protocol combinations, so we need one command for TCP and one for UDP. Here are the commands we run (note that the lines are wrapped):
Netsh advfirewall firewall add rule name="OB SMB TCP" dir=out 
action=block description="Block all outbound SMB and RPC traffic" 
enable=yes profile=public localIP=any remoteip=any localport=any 
remoteport=135,139,445 protocol=TCP interfacetype=any
Netsh advfirewall firewall add rule name="OB SMB UDP" dir=out 
action=block description="Block all outbound SMB and RPC traffic" 
enable=yes profile=public localIP=any remoteip=any localport=any 
remoteport=137 protocol=UDP interfacetype=any
It is important to reiterate in this context that just as in Windows XP SP2, only one profile can be active at a time. If there are two network interfaces live in the system and one of them is on the domain but the other is on a public network, the public firewall profile will be applied to all of them. This actually leads us to our next topic. We may want to modify these rules so they only apply to traffic over wired and wireless interfaces, but not VPN interfaces. Otherwise, they will significantly interfere with domain traffic while we are connected to a VPN.
Allowing Management Traffic via VPN
To modify our outbound SMB blocking let's use the GUI this time. Open Windows Firewall with Advanced Security and click Outbound Rules in the left pane. Highlight the OB SMB TCP rule and select properties. Click the Advanced tab and click the Customize button by Interface Types. You get the dialog box shown in Figure 19.
We want the rule to apply only to wired and wireless interfaces, but not to VPN connections, so we uncheck the Remote Access dialog box. Click OK a few times, and then do the same with the OB SMB UDP rule.
Of course, the astute reader would argue that we could have saved ourselves this roundtrip into the GUI by simply modifying our netsh script as follows:
Netsh advfirewall firewall add rule name="OB SMB TCP" dir=out 
action=block description="Block all outbound SMB and RPC traffic" 
enable=yes profile=public localIP=any remoteip=any localport=any 
remoteport=135,139,445 protocol=TCP interfacetype=wireless, lan
This is, of course, correct. You can specify the interface type in Netsh too. We leave figuring out how to do this for the UDP rule as an exercise for the same astute reader.
Managing Firewall in a Mixed or Down-Level Environment
If you are in a mixed environment with down-level (that is, Windows XP SP2, or older unsupported clients, and/or Windows Server 2003 servers), there are a few special considerations for managing the firewall, mostly to do with how to get the proper set of policies to apply to both Windows Vista and down-level systems. The most common problem in this type of environment is that the Windows Vista systems end up without a firewall running at all. Many organizations have purchased a third-party personal firewall, and have consequently configured Group Policy to turn off the Windows XP SP2 firewall. This is done using the legacy firewall settings shown previously in Figure 7.
If there are no Group Policy settings made in the Windows Firewall with Advanced Security section, the settings in the legacy node will take precedence and Windows Vista will configure its firewall as per these settings. In an environment where you were using a third-party firewall on Windows XP, but you wish to use the built-in firewall in Windows Vista, this results in Windows Vista being unprotected.
To further complicate this issue, there is no precedence order for this setting. Consider the following scenario.
-
Use the down-level settings, shown previously in Figure 7, to disable the Protect all network connections setting in the domain profile.
-
Then use the Windows Vista interface, shown previously in Figure 6, to turn on the firewall in the domain profile.
-
Force a group policy refresh on a member system. You will find that the firewall is turned on in the domain profile on all systems, regardless of operating system.
-
Check the setting for the Protect all network connections setting in the down-level area. If you have closed and reopened the group policy editor after Step 2 it will say "enabled," otherwise it will say "disabled."
The two interfaces actually configure the exact same setting. In fact, if you check the values in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall, you will find four profiles there: DomainProfile, PrivateProfile, PublicProfile, and StandardProfile, assuming you have configured all four. The DomainProfile setting is used for both the down-level and the Windows Vista firewall. The StandardProfile setting is used in Windows Vista only if there is no configuration for the Public and Private profiles. If either has been configured, most StandardProfile settings are ignoredfirewall. However, any exceptions configured in the StandardProfile are copied to the PublicProfile and PrivateProfile areas. Likewise, the PublicProfile and PrivateProfile settings are used only by Windows Vista.
To work around this problem, you need to think carefully how you want the firewall configured on the different platforms. Then you need to implement two (at least) Group Policy objects (GPO); one per platform. If you want to keep the third-party firewall on Windows XP, but use the built-in firewall on Windows Vista, you would create a GPO for Windows XP, using the legacy settings, which turned off the firewall. Then you would create a GPO for Windows Vista, using the Windows Firewall with Advanced Security settings that turned on the firewall.
Next, you have two options for how to get the GPOs to apply only to the computers they are intended for. One option is to use separate Organizational Units-one for Windows XP-based computers and one for Windows Vista-based computers. You would have to manually move each computer into the proper OU. If a computer gets upgraded, it needs to be manually moved into a different OU.
A better option is to use WMI filtering. A WMI filter allows you to run a query against the Windows Management Instrumentation data store and filter group policy objects based on the results. Figure 20 shows a WMI filter that selects only computers running Windows Vista, based on the version of the operating system.
The query used in the WMI filter in Figure 20 returns a set of values if the version of the OS on the Group Policy client is 6.0.6000. The Group Policy engine on the client essentially puts application of the GPO within an if statement based on this query. If the query returns anything, then the GPO gets applied. If the query returns nothing, the GPO does not get applied. This is a very effective way to filter GPOs because if a system gets upgraded no change needs to be made to Active Directory to get the proper policies to apply.
The only caveat to this is that you need the right OS version to filter on. For Windows Vista, as noted previously, it is 6.0.6000. For Windows XP it is 5.1.2600. If you wish to verify for yourself, or if you have some other version of Windows and want to learn what version it is, you can run this script:
' GetOSVer.vbs
Option Explicit
Dim objWMIService, objItem, colItems, strComputer
strComputer = "."
'Run the query
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery ("Select * from
Win32_OperatingSystem")
For Each objItem in colItems
Wscript.Echo "OS Version on this computer is: " & objItem.Version
Next
WScript.Quit
Copy this to a file called GetOSVer.vbs and double-click it. You can also find this script on the Web site accompanying the book, along with another script called GetOSData.vbs that returns all the values in the Win32_OperatingSystem collection-essentially everything you would ever want to know about your operating system.
RPC
We discussed, very briefly, that it might be a good idea to block RPC outbound in the public profile. One oft requested feature has been to control who can perform RPC lookups and connect to dynamic RPC ports inbound. RPC is an extremely common interprocess communications mechanism that uses a directory service of sorts. When a service that receives RPC traffic starts, it asks for one or more random ports. Once it gets that information, it registers its endpoints with the RPC Endpoint Mapper. A process on a remote computer that needs to communicate with the service would first ask the end-point mapper on the target computer where the particular service is. The end-point mapper would respond with the port number, and the remote process would then connect to the port.
From a security perspective, we might want to restrict who can connect to RPC ports on our computer. Restricting access to the end-point mapper is simple. It listens on TCP 135. Restricting access to the individual services is considerably more difficult. The new Windows Firewall gives us two features that can be helpful, however.
The first helpful feature is the pre-defined rules. Open the Windows Firewall with Advanced Security snap-in. Click Inbound Rules and click New Rule. Select Predefined: and you get the dialog box in Figure 21.
The predefined rules are written for particular services only, but they make the job a lot easier if you want to restrict only those services. However, if you want to restrict all dynamic RPC traffic, they do not help much. In that case, select a custom rule instead, and click Next. Then select All programs (or only a particular program or service if you so desire) on the next screen, and click Next again. On the Protocol and Ports screen, shown in Figure 22, select the TCP protocol, and then click the Local port dropdown.
In the Protocols and Ports screen you get an option to restrict traffic to local dynamic RPC ports. This is exactly what we wanted but could not do in prior versions of the operating system. It is hard to decide which feature of Windows Firewall we like best, but this is definitely in the top-five or so of the list.
|
