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.
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
- 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
- Configure the logging options
- Configure the Internet Control Message Protocol (ICMP)
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
Application Permissions List (Windows Firewall Permissions
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
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",
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
Figure 3: Exceptions Dialog for Windows Firewall
Administrators can also manage the Windows Firewall
Permissions List using the Netsh command-line utility mentioned
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)
- 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
- 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
- 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.