Avoid Risky Rules With Netsh

Windows Firewall is a personal host-based firewall included in the Windows Server 2003 and Windows XP Service Pack 2 (SP2) OSs. You can use Netsh to audit Windows Firewall configurations by enumerating configured exceptions (aka firewall rules) on users' computers. But before I show you how to perform this type of audit, let's look at when you might want to do so.

Special Rules for Special Users
Windows Firewall is popular because it's free and you can centrally manage it with Group Policy. Windows Firewall supports two profiles. The OS uses the domain profile when the computer is connected to the company's network (assuming the company has a domain) and the standard profile when the computer is connected to any other network. Generally, administrators configure the domain profile with broader access rules and lock down the standard profile.

Some power users or users who routinely connect to other networks might require custom access levels, which usually means more open ports or allowed applications in the firewall. You might be able to create a Group Policy Object (GPO) permitting these custom access levels if your company is small or if relatively few users need them. However, many companies don't have the technical or political capability to keep every remote computer locked down by using centrally managed rules and might concede to giving certain users administrative privileges so that those users can create their own exceptions. For example, suppose some developers need to demonstrate Web projects or other network services at clients' sites. These developers might be given the privileges they need to manage their own rules so they can allow the clients' computers to connect to a Web service hosted on their laptops. This situation happens more frequently than you might think. If your business requires this flexibility, you can use Netsh to tailor your security process to accommodate this concession and audit the firewall rules that these users create.

Getting Started
Netsh is a command-line tool that you can use to perform many network configuration tasks. You access its primary functions through contexts. A context is a group of commands specific to a networking component, such as DHCP, RAS, or WINS. In Windows 2003 SP1 and XP SP2, Netsh added the firewall context for inspecting and configuring Windows Firewall.

To run Netsh interactively, type

netsh 

at a command prompt. To enter the firewall context, type

firewall 

From here you can execute firewall-specific commands. For example, you can type

show state 

to see the computer's firewall status. At any point, you can type

/? 

for help or type

.. 

to return to the previous level. (This tool is hierarchical in nature.)

Typing one command at a time is great if you're exploring the tool's capabilities or you want to manually gather network configuration data from a computer. However, when you're automating Netsh through a script or scheduled job, it's expedient to chain your commands together. For example, at the command prompt, you can type

netsh firewall show state 

which will run Netsh and output the firewall's state to the console. However, you'll return to the command prompt instead of remaining in the Netsh UI.

The Netsh firewall context runs locally, which means that you must run the Netsh command on the computer that you want to audit. If you want to configure the firewall context for a remote computer, you need to enable a remote access protocol (e.g., RDP) for a terminal services session or Telnet session and run these commands ad hoc. Alternatively, you can configure a computer startup script or user logon script to run the commands whenever a computer starts up or a user logs on. (Later, I'll show you how to use a logon script to check the configuration of workstations and save the configuration information in a central location.) If you use management software such as Microsoft Systems Management Server (SMS) or LANDesk Software's LANDesk, you can configure a job to regularly run Netsh on remote computers.

Finding the Exceptions
Windows Firewall rules are known as exceptions and are categorized by program-(e.g., Windows Messenger) and port (e.g., TCP port 80). To list all the program and port exceptions on a computer, run the commands

netsh firewall show allowedprogram 

and

netsh firewall show portopening 

respectively. As Figure 1 shows, these two commands return a list of the configured exceptions for both the domain and standard profiles. In Figure 1, the show allowedprogram command's output lists four Microsoft programs (i.e., Remote Assistance, File Transfer Program, Internet Explorer, and Windows Messenger) and two third-party programs (i.e., YAC and dsTermServ Module). Third-party programs can prove interesting if they aren't on your company's approved program list.

The show portopening command's output lists all of the TCP and UDP ports permitted to open communications with the computer and with the allowed programs. In Figure 1, the configurations for the domain and standard profiles include the ports used by Microsoft's file sharing technology. But a keen eye will also notice that TCP 1214 is allowed. This port is used by Kazaa, a popular peer-to-peer file transfer program that's definitely worth investigating if it isn't on your approved program list. You can find the official list of ports on the Internet Assigned Numbers Authority (IANA) Web site at http://www.iana.org/assignments/port-numbers. However, IANA doesn't list the ports used by lesser known peer-to-peer programs or illicit programs. For a broader list, you can try searching the Internet using the keywords TCP UDP ports.

You can use the show allowedprogram and show portopening commands in a logon script to audit the exceptions created by every computer that logs on to your domain. For example, the logon script in Listing 1 generates a list of exceptions for each logged-on computer and copies the results to a log file in a share named FirewallExceptions on a file server named fileserver. To make post-processing easier, the log file is time-stamped and named after the computer that generated the report. The logon script overwrites the log files each time it runs. Thus, if you want to keep the log files, you need to customize the script. For example, you might incorporate the date in the filename by adding the %date% environment variable (e.g., %temp% %computername%-%date%-fwe.log).

After the logon script creates the log files, you can look for usage patterns or noncompliances in them by using a tool such as Windows Grep. (The Grep shareware program is available at http://www.wingrep.com. Alternatively, you can use Windows' FindStr command.) Grep's invert match (-v) parameter lets you filter a list by excluding lines, which highlights the remaining data. For example, the command

grep -v NetBIOS *.log | grep Enable 

goes through each log file, lists all the enabled exceptions, but excludes any lines containing the word NetBIOS. Figure 2 shows the results from this command.

As you can see, it's quick and easy to distill large amounts of data to highlight unique or interesting information. For example, in Figure 2, note that the user of the computer named GENX created an exception for the game Battlefield 2. Armed with the computer name and exception, you can take appropriate action pursuant to your policy.

Some users might take extreme measures by adding a program, then immediately removing it when they're done using it. In such cases, you might consider revoking their administrative privileges or taking disciplinary action. You could use Group Policy to take away their ability to configure the Windows Firewall. If you do that, you probably don't need to use Netsh to monitor the system for firewall changes.

Avoid Risky Rules
Windows Firewall improves security, but not if users create rules that allow risky software. When faced with this challenge, you can use Netsh and Grep to audit these users' custom configurations.