Windows Firewall

• On-by-Default

  Before SP2, Windows XP shipped with Windows Firewall disabled by default. Users either needed to run a wizard or navigate through the Network Connections folder to enable Windows Firewall. By enabling Windows Firewall by default, the computer will be protected from many network-based attacks. If Windows Firewall had been enabled by default, the recent MSBlaster attack would have been greatly diminished in impact, regardless of whether users were up to date with patches since Windows Firewall discards unsolicited communications such as port scanning.
  
  Windows Firewall On-by-Default may impact existing applications if the application does not work with stateful filtering by default. For example, if the application expects to receive messages from another computer without first sending a message (i.e. act as both client and server), the application may fail. In addition, PCs that are running a Web server will require Windows Firewall to be configured to allow those requests (http://support.microsoft.com/default.aspx?scid=kb;EN-US;320855).
  
   

• Boot Time Security

  In earlier versions of Windows, there is a window of time between when the network stack was running and when Windows Firewall provides protection. This results in the ability for a packet to be received and delivered to a service without Windows Firewall filtering and potentially exposes the computer to vulnerabilities. This was due to the firewall driver not starting to filter until the firewall service was loaded and had applied the appropriate policy. The firewall service has a number of dependencies which causes the service to wait until those dependencies are cleared before it pushes the policy down to the driver. This time period is based upon the speed of the computer.
  
  In Windows XP Service Pack 2, the firewall driver has a static rule, called the boot-time policy. It performs stateful filtering and eliminates the window of vulnerability while the computer is booting. This new policy rule allows the computer to open ports so that basic networking tasks such as DNS and DHCP may take place. It also allows communication with a domain controller to obtain appropriate policies. Once the firewall service is running, it loads and applies the run-time Windows Firewall policy and removes the boot-time filters. (The boot-time policy cannot be configured.)
  
  There is no boot-time security if Windows Firewall/Internet Connection Sharing (ICS) is set to Disabled.
  
   

• Easier Configuration

  Windows Firewall is now easier to configure since it allows global configuration of all interfaces so that changes automatically apply to all existing and new network connections. Individual configurations can also still be performed. In addition, Windows Firewall now allows you to create two sets of firewall policy: one for when the computer is connected to the corporate network and one for when the computer is not. You can specify policy that is less strict when the computer is connected to the corporate network to enable line of business applications to work. You can also have a more aggressive security policy that will be enforced when the computer leaves the corporation network, which helps to protect against Internet-based attacks. However, multiple profiles for Windows Firewall only applies to computers that are joined to a domain. Computers that are in a workgroup only have one profile.
  
  Administrators can now also use the Netsh helper command-line utility (formerly available only with the Advanced Networking Pack for Windows XP) to do the following:

  • Add or remove applications from the Windows Firewall Permissions List
  • Configure the default state of Windows Firewall (Off, Enabled, On with No Exceptions)
  • Configure which ports should be open, including whether ports allow global access or access restricted to the local subnet and whether ports are open on all interfaces or per-interface
  • Configure the logging options
  • Configure the Internet Control Message Protocol (ICMP) handling options
    
    Note that Service Pack 2 also includes new Group Policy Objects (GPOs) to allow network administrators to manage Windows Firewall policy in the corporate environment. These GPOs include Operational mode (On, Off, or On with No Exceptions), Allowed Programs, Opened Ports (static), ICMP settings, and Enable RPC. These can be configured in both the corporate and standard profiles.
    
     

• Application Permissions List (Windows Firewall Permissions List)

  Some applications act as both network clients and servers. When they act as servers, they need to allow unsolicited inbound traffic to come in as they do not know who the peer will be ahead of time.
  
  In earlier versions of Windows, an application needed to call the Windows Firewall APIs to enable the necessary listening ports to be open. This proved difficult in peer-to-peer situations when the port was not known in advance. It was up to the application to close the port again once communication was completed. Without this, there might be unnecessary openings in the firewall if the application terminates unexpectedly.
  
  Additionally, these ports could only be opened if applications were running in the security context of a local administrator. This violates the principle of least privilege by requiring applications to run in an administrative context, rather than only with the minimum necessary privileges.
  
  In Windows XP Service Pack 2, an application that needs to listen to the network can be added to the Windows Firewall Permissions List both administratively and programmatically. If an application is on the Application Permissions List (Windows Firewall Permissions List), Windows opens the necessary port automatically, regardless of the application's security context, for the duration that the application is listening on those ports. An application cannot open a port that it is not using, which might deliberately or inadvertently expose another application or service to network traffic from that port.
  
  This also allows applications that are listening to the network to run as a regular user instead of Administrator, as was the case in earlier versions of Windows.
  
  Applications that don't listen on the network do not need to worry and do not need to be placed on the Application Permissions List. If you do need to add an application to the Windows Firewall Permissions list graphically, an administrator can either select Configure Windows Firewall in the Network Tasks pane when viewing network connections or by clicking on the Settings button in the Advanced tab for a particular network connection. The resulting dialog shown in Figure 1 allows an administrator to turn Windows Firewall On with exceptions (i.e. the white list is active), On with no exceptions (also referred to as "On with No Exceptions", or Off.
  
  
  Figure 1: Windows Firewall General Tab
   

  When the first option is chosen, the Windows Firewall Permissions list available in the Exceptions tab is used as shown in Figure 2.
  
  
  Figure 2: Windows Firewall Exceptions Tab
  
  To add an application to the Windows Firewall Permissions List, the administrator clicks the Add button and configures the application executable as shown in Figure 3. Note that individual TCP and UDP ports can also be enabled in this dialog box.
  
  
  Figure 3: Exceptions Dialog for Windows Firewall
  
  Administrators can also manage the Windows Firewall Permissions List using the Netsh command-line utility mentioned previously.
  
   

• RPC Support

  In earlier versions of Windows, Windows Firewall blocked remote procedure call (RPC) communication. While Windows Firewall could be configured to allow network traffic to the RPC Endpoint Mapper, applications which use dynamic endpoints had RPC traffic blocked by Windows Firewall due to RPC's arbitrary choice of network port.
  
  Many applications and components fail if RPC is not allowed to communicate over the network. Some examples include, but are not limited to, the following:

   

  • File and print sharing
  • Remote administration
  • Remote Windows Management Instrumentation (WMI) configuration
  • Scripts that manage remote clients and servers

  RPC opens several ports and then exposes many different servers on those ports. On a typical workstation or server, there are about 60 RPC servers running by default that listen for client requests on the network. Some servers have more, depending on their configuration. This is the RPC attack surface.

  Since so many RPC servers are included with Windows XP, and since most of them run using the same process image file name (Svchost.exe), Windows Firewall adopts a different approach for RPC servers. When opening a port, a caller might claim that the port is to be used for RPC. Windows Firewall will only accept this claim if the caller is running in the Local System, Network Service, or Local Service security contexts. Windows Firewall supports a profile level flag that enables RPC ports to be opened even if the caller is not on the Windows Firewall Permissions List.

  This is stored in the registry as a REG _DWORD value named PrivilegedRpcServerPermission under the profile key. The values correspond to the NET_FWV 4_SERVICE_PERMISSION enumeration:

• NET_ FWV 4_SERVICE_BLOCK = 0. RPC servers are only allowed to open ports if they are on the Windows Firewall Permissions List.
• NET_ FWV 4_SERVICE_ALLOW_LOCAL = 1. If an RPC server is not on the Windows Firewall Permissions List, the port will be opened, but only accept network traffic from the local subnet.
• NET_ FWV 4_SERVICE_ALLOW_ ALL = 2. If an RPC server is not on the Windows Firewall Permissions List, the port will be opened for network traffic from any subnet.

Note, however, that the authorized application settings always override the generic RPC setting. For example, if the RPC setting is “allow local,” but the RPC server executable is also on the Windows Firewall Permissions List with the local subnet only set to False, the port of the RPC server will be opened for all subnets.

• On with No Exceptions

  Windows Firewall might be configured to allow unsolicited incoming traffic during normal use. This is typically due to needing to enable key scenarios like file and printer sharing. If a security issue is discovered in one or more of the listening Windows services, it might be necessary for the computer to switch into a client-only mode, On with No Exceptions. Switching into this client-only mode configures Windows Firewall to prevent unsolicited inbound traffic without having to reconfigure the firewall. This is configured by selecting the On with no exceptions option shown in Figure 1.

  When in this mode, all static holes are closed. Any API call to open up a static hole will be allowed and the configuration stored, but it will not be applied until the Windows Firewall operational mode switches back to normal operation. All listen requests by applications will also be ignored.

  Keep in mind that viruses, worms, and attackers look for services to exploit. When in this operational mode, Windows Firewall helps to prevent these types of attacks from succeeding. The computer cannot listen for inbound requests from the network, but outbound connections will succeed.