Windows Firewall Auditing

Configuring a firewall has never been a trivial task, but more recent versions of Windows Firewall (though still pre-Windows Vista) make the task a bit easier. The concept is simple: The firewall blocks all incoming traffic except the entities that you list as exceptions. An exceptions list (aka filter) defines specific network traffic that you don’t want blocked: program and port traffic that you choose to allow through the firewall. When you add an exception to the exceptions list, the firewall permits all traffic to that program or port. The long-established best practice of firewall security is to block everything and allow only minimal exceptions. For each exception, you should use the most restrictive setting that will still allow access.

Note: The Windows Vista firewall—which includes some key features that go beyond those of the Windows XP Service Pack 2 (SP2) firewall, such as the ability to block outbound traffic—won’t be covered in this article. For information about the Vista features, see Jeff Fellinge’s article “Vista’s Firewall,” August 2006, InstantDoc ID 50377.

Many organizations use Group Policy to enforce specific settings, such as firewall settings. Sometimes, however, Group Policy might not be the best choice for your particular environment or you might need to let users control firewall settings themselves. For many users, firewall configuration is straightforward; it requires (and gets) little thought. Over time, certain misconfigurations can occur that compromise the firewall’s ability to protect a system. Because misconfigurations can accumulate, you should regularly audit the firewall configurations of the systems you manage. You can easily automate firewall audit reports with a short script that will query any number of systems on your network. After I review common misconfigurations, I’ll note best practices for your firewall exceptions list and take you through the script in Listing 1, which you can use to audit your firewalls.

Common Firewall Mistakes

Firewall misconfigurations can be serious, exposing systems to significant risks. A misconfigured laptop, for example, can potentially bring malicious software (malware) into an enterprise, completely bypassing all protections at the network gateway. Therefore, it’s vital to recognize and check for the most common firewall problems.

The first and most common mistake results from someone turning a firewall off for a particular purpose or in a particular way and forgetting to turn it back on. This oversight is far more common than it should be. I often see situations in which someone has
• turned a firewall off for testing—and not turned it back on
• turned a firewall off for a one-time purpose (rather than creating an exception)—and not turned it back on
• turned a firewall off from the properties of one network adaptor, thinking that doing so will disable the firewall for the particular adaptor only (but inadvertently disabling other systems’ firewalls)—and not turned it back on

Depending on your version and configuration, Windows won’t always warn you if your firewall is off. Of course, you can use other methods to manage your firewall (e.g., use a Group Policy Object—GPO—that prevents turning the firewall off), but you can easily check your firewalls by auditing your systems with the HNetCfg.FwMgr object, which Listing 1 shows.

Windows Firewall has two profiles—a domain profile to use when users are connected to your Windows domain and a standard profile to use when users are disconnected from (not logged on to) your Windows domain. The standard profile is used, for example, when laptop users connect to a foreign network (e.g., home, hotel, coffee shop). Note that when users connect to your Windows domain, Windows will always use the domain profile, even if your domain doesn’t specifically configure the firewall through Group Policy.

Because the firewall has two profiles, the code first establishes which profile the script will audit. If you run the script without specifying a profile, the script will run the audit for the currently loaded profile. The code at callout A in Listing 1 accesses the firewall policy, setting the objPol to the specified profile. Next, it establishes the type of policy and prints the global firewall settings.

In addition to being globally enabled, you can enable or disable the firewall for each individual interface, as Figure 1 shows. The Windows Firewall dialog box indicates that the firewall is disabled on interface LAN3. Because it’s important to know the settings for every interface, the script will discover all the settings, as the code at callout B in Listing 1 shows.

Note that for a network interface to be protected, the firewall must be enabled globally as well as on the interface itself. If the firewall is off in either place, it won’t filter traffic on that interface.

Configuring Firewall Exceptions

Another common mistake can occur when you set up firewall exceptions. However, before I discuss problematic exceptions, let me offer you some background. In general, exceptions lists can create problems and must be managed. You should review them frequently. They are often too liberal in terms of the number and scope of the exceptions listed. An example of a dangerously broad exception is allowing all traffic for a particular application, which in turn permits any connection to any port that the application opens. This situation might not be desirable because some applications open many ports, including many that you might never use but that intruders might access.

I recently had a client who detected unwanted connections on his laptop while he was traveling. He had been testing a new mail server application on his laptop and had added an exception for the mail server application to allow incoming connections. However, in doing so, he had also allowed connections to every port the software opened—12 ports in all. A better solution would have been to create an exception to allow connections only to the specific TCP ports he needed open.

However, opening a specific port isn’t always better than creating an application exception. The advantage of using an application exception is that the firewall allows the program to accept incoming traffic only while the program is running. A port exception, on the other hand, will continue to accept traffic on the port, no matter what program is listening on the port. The decision about whether to use an application exception or a port exception largely depends upon what the application does and the degree to which you trust what the application does.

Regardless of your approach to exceptions, you should regularly review them. Over time, an exceptions list will accumulate exceptions that you no longer use. You might have exceptions for programs that are no longer on the system or have both application and port exceptions for the same service. Keep all of this information in mind as I offer you a best-practice approach.

Using Exceptions-List Best Practices

When you edit a firewall exception, you have the option of specifying which IP addresses can access that program or port. Choosing to specify IP addresses is important because you might, for example, want to make file and printer sharing accessible to other computers on your network but not accessible from the Internet. Specifying IP addresses will better isolate your network from any foreign network’s threats while still allowing full access to and from the local network.

The firewall’s scope setting plays a crucial role in the effectiveness of the exceptions list, and it’s important to use the most restrictive setting possible. The scope options, which Figure 2 shows, are
• Any computer—allows traffic from any IP address
• My network (subnet) only—allows traffic from any directly reachable network
• Custom list—lets you specify a list of IP addresses that will be allowed access

Selecting the first option, which lets any computer connect, is obviously dangerous unless you’re hosting a public server and want anyone to be able to connect to that port. The second option might seem safe on the surface because it allows connections from your local network only. However, even if you trust your entire subnet, this choice might be problematic—especially when laptop computers are involved.

The problem with laptops is that users often connect to untrusted networks (e.g., in a hotel, at a wireless hotspot). In such cases, Windows Firewall might allow other traffic, including malicious traffic, on to the network because you’ve allowed connections from that subnet. The important thing to remember is that you don’t always know the exact scope of a laptop’s subnet.

The best solution is to use the third option, Custom list, to specify a list of the exact IP addresses and networks you want to allow. The code at callout C in Listing 1 shows how you can list all firewall service, application, and port exceptions along with each exception’s properties.

The code at callout C will show you all the exceptions on the system. Figure 3 presents sample output. After carefully reviewing the list, you’d remove any unnecessary exceptions. Note that as the script lists the application exceptions, it also checks whether a file actually exists. If a file doesn’t exist (e.g., the iTunes file), the script notes in its report that the file is missing.

Creating Per-Interface Exceptions

In addition to global exceptions, you can create exceptions lists for a specific interface. Interface-specific exceptions are more accurately called port mappings because they let you accept an incoming connection to a port and forward that connection to any port on that computer—and even to a port on another computer.

Because the format for per-interface connections are so much different, you must create separate code to list the interface-specific exceptions filters. Because per-interface filters implement features of Internet Connection Sharing (ICS), you use the HnetCfg.HNetShare object, as the code at callout D in Listing 1 shows. In this case, because there are so many built-in per-interface exceptions, only those enabled for that connection are displayed. Notice also that these particular exceptions include no scope settings; you should use the global settings if possible.

Auditing Your Firewall Regularly

As you can see, misconfigurations of Windows Firewall can accumulate over time and make your protection less than optimal. Therefore, it’s important to audit your firewall settings regularly. You’ll probably be surprised at how much clutter can build up in the exceptions list.

Unfortunately, because of the limitations of the Windows Firewall COM interface used in the script in Listing 1, you can’t run the script against remote systems. However, you can easily deploy this script for each individual server to run on startup or user logon. For my standalone servers, I’ve scheduled the script to run once a week and email me the report. With little modification, you should be able to integrate this tool into your own organization.