In "Meet Windows Firewall" (May 2004, InstantDoc ID 42293), I introduced Windows Firewall, a Windows XP Service Pack 2 (SP2) feature that was called Internet Connection Firewall (ICF) in its previous incarnation. In this column, I want to look more closely at the feature and show you how to fine-tune it for your network's needs. (This article is based on a prerelease version of SP2, and Microsoft might make modifications in the final release.)
Let's look at the nine new Group Policy settings for Windows Firewall and at their corresponding commands. You can find Windows Firewall settings in the Computer Configuration\Administrative Templates\Network\Network Connections\Internet Connection Firewall folder. In that folder, you'll see two subfolders: Domain Profile and Mobile Profile. A computer that has Windows Firewall installed chooses the policy settings for Domain Profile when that computer is logged on to a domain; otherwise, it chooses the settings for Mobile Profile. Both subfolders contain the same nine policy settings.
I showed you the first setting, Operational Mode, last month. The Operational Mode setting gives you three options: Disabled turns off the firewall, Protected turns the firewall on, and Shielded turns the firewall on but isolates the computer from the network more than the Protected setting, which lets you open particular ports. To set the firewall to Disabled, Protected, or Shielded, you use the
netsh firewall ipv4 set opmode
command, followed by either disabled, enabled, or shield. (The command-line commands often describe options with slightly different words than the Group Policy settings.) Thus, to raise the drawbridge and shield your NIC, you'd type
netsh firewall ipv4 set opmode shield
This command strikes me as a good one to put into a batch file. You could then create a shortcut on your desktop to that batch file, call the shortcut Shield this System, then double-click it any time your network falls under attack. To find out how the firewall is set, you can use the command
netsh firewall ipv4 show opmode
Modify Firewall Settings
The next Windows Firewall policy setting is Allow User Preference/Group Policy Settings Merge—a setting that can be confusing. The Windows Firewall documentation states that if this setting is enabled, local administrators can modify the firewall's settings. But does "modify" mean "turn the firewall on or off" or "tweak it by opening or closing ports"? In this case, "modify" means the latter: If enabled, this policy lets a local administrator open or close a port on a system—but not override the Disabled, Protected, or Shielded setting set by a domain policy, assuming that a Windows Firewall-relevant domain policy exists. If you set the policy to Disabled, local administrators have no power over the firewall's behavior.
Confusion sets in when a local administrator tries to override the Windows Firewall settings that a domain Group Policy Object (GPO) creates. A local administrator who types
netsh firewall ipv4 set opmode disable
will get an OK result, and a subsequent Netsh Firewall command will report that the firewall is disabled. However, a look at the properties of the NIC in the Network Connections folder will reveal that the firewall is enabled. A few tests show that the GUI is telling the truth: The domain settings win. Let's hope that this behavior doesn't make it into the final release version.
But the GUI can't always be trusted either. If you set Allow User Preference/Group Policy Settings Merge to Disabled, the GUI is grayed out, and the radio buttons for turning Windows Firewall on or off become unusable. That makes sense. But try enabling the setting, then returning to the Windows Firewall configuration screen. The radio buttons to enable or disable the firewall are now enabled. You can click them and choose OK, and you won't get an error message—but you won't see a change, either. However, as a local administrator, you can use either the command line or gpedit.msc to open and close ports. No command-line equivalent of the Allow User Preference/Group Policy Settings Merge policy setting exists.
Whatever the Program Needs
The next policy setting is the first of seven settings that let you open or—in some cases—close a particular port. The difficult aspect of configuring firewalls to pass a particular kind of traffic (e.g., Web traffic, Active Directory—AD—authentications, email downloads) is knowing which port that traffic needs. The Define Allowable Programs policy setting simplifies that aspect. Recall that, by default, Windows Firewall doesn't block outbound traffic but does block unsolicited inbound traffic. That functionality works fine when your workstation acts as a client that initiates a conversation, such as when you ask your mail server for your mail or a Web server for information. But it doesn't work when your workstation provides a service for others on the network—for example, if you run an email server on your workstation—because the firewall would rebuff clients trying to initiate a conversation with that server program. It also doesn't work in peer-to-peer (P2P) situations such as Instant Messaging (IM), in which two or more systems communicate but act both as clients and servers. Thus, running a server or performing P2P scenarios require opening some ports.
But which ports do you open? By naming a particular program in the Define Allowable Programs setting, you answer the question by simply having Windows Firewall open whatever ports that program needs. To do so, you point the policy setting to the location of the program, determine whether to enable it or disable it (e.g., you might want to create a policy to disable ports for a particular program if that program were a Trojan horse loose on your network), and determine whether to open those ports for the whole world or just for the local subnet.
Suppose I've got an email server program running on my computer at C:\myprogs\serverprog.exe. I don't know which ports it opens, but I want those ports open only to systems on the same subnet as the server. I'd enable the Define Allowable Programs setting, then click Show to get a dialog box that lets me punch in the information for my email server. In that dialog box, I'd type
This line specifies four items, each separated from the rest by colons. The first item is the complete path to the program. You can use environment variables such as %ProgramFiles%, if you want. The next item, LocalSubnet, says to accept incoming traffic on that server's ports from only systems on the same subnet. The third item, enabled, says to permit the traffic. And the fourth item, E-mail server, is merely a label that Windows Firewall can use when reporting on its activity. You can add as many programs as you want.
Opening Particular Ports
The remaining settings open particular ports. The first, Allow Dynamically Assigned Ports for RPC and DCOM, is a bit of a conundrum—to enable or not to enable? I'm a big fan of Windows Management Instrumentation (WMI)-based tools such as WMI VBScripts and the Microsoft Management Console (MMC) Manage Computer snap-in, and WMI needs Remote Procedure Calls (RPCs). You can't use the Manage Computer snap-in to control a system remotely without using WMI, so if you want to leave Windows Firewall in place but still use Manage Computer to control remote systems, you'll have to enable this setting. The problem with opening ports for RPC is that Microsoft has discovered some scary bugs in RPC in the past 2 years, perhaps the most memorable of which led to MSBlaster. So enabling a firewall but also opening ports for RPC might be a self-defeating exercise, like installing locks on all your doors but leaving the front door unlocked for convenience: Burglars will find it convenient, too. Like the previous setting, this setting lets you open ports to all IP addresses or just to the local subnet, but that option doesn't seem very helpful either. In many cases in which MSBlaster attacked a business, the attack launched from an infected laptop that someone carried into the company. So think long and hard before you enable this setting.
The File and Print Sharing, Remote Assistance Support, and Universal Plug and Play settings work the same way as the RPC setting: You can turn them on or off, and if you turn them on you can restrict them to the local subnet. You can enable all but Remote Assistance support from the command line by using the
netsh firewall ipv4 set service
command, followed by type= and the name of the service (i.e., FILEANDPRINT, RPCANDDCOM, or UPNP), as well as scope= and either all (the entire Internet) or subnet (the local subnet). For example, to enable file and print sharing for only the local subnet, you'd type
You can append profile= and interface= to any command, so if you wanted to open file and print services on your wired Ethernet connection only when your system was connected to the domain, you'd use the command
interface="local area connection"
Whereas Group Policy refers to Domain and Mobile profiles, command-line tools refer to corporate and other profiles.
Two policy settings remain. Allow ICMP Settings affects the Internet Control Message Protocol (ICMP) subsystem. In general, you don't need to worry much about ICMP, but you probably will care about one aspect of it: Ping. By default, firewalled systems block all ICMP requests and therefore ignore pings. A look at the Allow ICMP Settings Properties shows nine types of ICMP requests that Windows Firewall permits. For ping purposes, you need to enable only Allow Inbound Echo Request. This setting has no option for restricting ICMP traffic to the local subnet.
From the command line, you'd open up ICMP with the command
netsh firewall ipv4 set icmpsetting
followed by type= and a number (3, 4, 5, 8, 10, 11, 12, 13, or 17) or the word all. Each number refers to one of the nine ICMP settings, and the one you want—incoming echo request—is number 8. To make your system respond to pings, then, you'd type
netsh firewall ipv4 set icmpsetting type=8
Again, you can add profile= or interface= to make the command more specific.
What if you want to open a port for a service that I haven't discussed? Just use the ninth policy setting, Define Custom Open Ports. Enable it, then click Show as I explained for Define Allowable Programs. Next, specify the number of the port you want Windows Firewall to open, whether the port is TCP or UDP, whether to open it up to the world or just the local subnet, and whether to enable or disable it. Optionally, you can give the port a descriptive name. For example, your mail server might want TCP port 25 open to the whole world, so you might specify
where 25 is the port number, TCP is the protocol, the asterisk (*) opens the port to the whole world (the alternative is subnet), enabled opens the port instead of closing it, and SMTP is a descriptive phrase. From the command line, use the command
netsh firewall ipv4 add portopening
followed by protocol= (with tcp, udp, or all), port= (with the number), name= (with a name), mode= (with enable or disable), and scope= (with all or subnet). To enable your mail server, you'd type
protocol=tcp port=25 name=SMTP
If you don't specify a mode, enable is assumed, and if you don't specify a scope, subnet is assumed.
If you change your mind and want to close a port, use the command
netsh firewall ipv4 delete portopening
along with the protocol and the port number to identify which port you want to close. For example, to close your email server's port, you'd type
Playing around with these settings, you might get confused—Hey, I closed that port, why is it still open?—unless you understand an important difference between how the firewall behaves when controlled by a Group Policy setting and how it behaves when controlled from the command line. Command-line commands typically take effect immediately. Group Policy changes can take a while to appear. You can make local Group Policy changes in Windows Firewall take effect immediately by using the command
Wait for the command to finish, then go to Services in the Manage Computer snap-in and restart the Internet Connection Firewall service. (Microsoft might rename this service by the time SP2 debuts.)
That's the extent of the Group Policy settings for Windows Firewall, but the command line can do a few other things. Recall that Windows Firewall has two profiles: Domain and Mobile. Suppose you want to know which profile your system is using. The following command determines whether you're running the Domain Profile (corporate) or the Mobile Profile (other):
netsh firewall ipv4 show currentprofile
If you want to know more about what the firewall is doing, you can use the Set Logging command, which takes four optional parameters: Filelocation= tells Windows Firewall where to put the ASCII log file, and maxfilesize= lets you specify how large the file can grow. You specify the file size in kilobytes, and the largest value it can take is 32767. The droppedpackets= and connections= parameters take the value enable or disable and tell Windows Firewall whether to log blocked and successful connections. For example, if you want to log both successful and blocked connections to a file called C:\firelog.txt and give it a maximum size of 8MB, you'd use the command
The log can grow large, but if you're trying to track down a regular attacker, you'll be glad you have a complete log of every TCP and UDP connection and refusal. You can use the following command to determine the current logging settings:
netsh firewall ipv4 show logging
For a comprehensive overview of your firewall settings, use the command
netsh firewall ipv4 show config
For different details about what your firewall is doing, replace config with state in that command. To get a smaller report that shows only the open ports, replace config with icmpsetting or portopening.
Too Much Work?
Windows Firewall comes with a lot of new things to understand. However, if your system lacks a personal firewall, Windows Firewall can make your system more secure at no greater cost than a little time to create a GPO to open whatever ports you need. In return, you get the benefit of knowing that a firewalled system is much less vulnerable to the latest worm.