Security

Exploring The Windows Firewall

Steve Riley

At a Glance:

• Inbound vs. outbound protection
• The Windows Filtering Platform
• The Advanced Security interface
• Network profiles

Back in the days of the paleocomputing era, no one ever thought about installing firewalls on individual computers. Who needed to? Hardly anyone had heard of the Internet, TCP/IP was nowhere in sight, and LAN protocols didn’t route beyond your building or campus. Important data lived on

the mainframe or file servers—the information people kept on their desktop computers was rarely mission critical and the computer’s own weight afforded a certain amount of decent physical security. If there was a connection to the Internet available, there were likely some protocol translators in the way and a packet-filtering router (I mean "firewall") at the edge, probably configured with too many rules and exceptions.

Modern computing environments wildly diverge from those ancient times. Everything is connected to the Internet (and talks TCP/IP now) and portable devices are now the standard. Your employer has likely given you a laptop, not because they care about you, but because they care about getting more out of you—they fully expect you to work anytime you’ve got five spare minutes and a Wi-Fi connection. Laptops might cost more than desktops, but that investment is surely repaid in productivity. You see, it’s the portability that makes them so alluring—to you and your adversaries.

Think about this: of the total amount of time your laptop is powered up and connected to some network, what percentage of that time is it connected to your corporate network? If you’re anything like me, maybe 20 percent max. That means that only 20 percent of the time is my laptop safely within the confines of the Microsoft corporate network, protected by the network’s perimeter defenses from outside attack. But what about the 80 percent of time when my laptop is, for all practical purposes, connected directly to the Internet? (And I’m quite often connected to the most dangerous network in the world: the hotel LAN at a computer security conference!) And those times when I am connected to the corporate network, how about threats posed by other computers within that environment?

Security controls evolve to follow—sometimes too far behind—the threats. Viruses were a client problem because people traded floppy disks, so antivirus programs first appeared on clients. Then as e-mail became popular and malware matured into worms that relied on e-mail distribution, anti-malware programs evolved and appeared on e-mail gateways. With the rise of the Web, malware matured into Trojans and anti-malware followed onto Internet access proxy servers. This is a well-understood evolutionary path that no one quibbles with.

Now let’s apply the same logic to firewalls. While a firewall at your network’s edge was sufficient protection against the threats of yesterday, this is no longer the case as threats are different, they’re more sophisticated, and they’re more prevalent. Not to mention that devices and work styles differ significantly from the past. Many computers carry sensitive information stored locally, and they spend a lot of time away from the corporate network (that is, outside the edge). Therefore, the firewall must evolve into an individual client protection mechanism. Make no mistake: client firewalls are no longer optional. To protect your computers from your own corpnet and from the Internet, client firewalls are required.

Client Firewalls and Security Theater

Many people didn’t realize that the initial release of Windows® XP included a client firewall. That’s not really surprising since the firewall was switched off by default and it was buried behind too many mouse clicks. In its own rather stealthy way, the firewall just showed up without any real indication of its purpose or guidance on how to use it. But it did work. If you had enabled that firewall, it would have saved you from Nimda, Slammer, Blaster, Sasser, Zotob, and anything else that tried to hurl unsolicited traffic at your network port. Realizing the importance of client protection, Windows XP Service Pack 2 (SP2) enabled the firewall by default, created two profiles (Internet and corpnet), and allowed for Group Policy enablement.

Unfortunately, two barriers slowed the adoption of the Windows XP SP2 firewall: application concerns and security theater. Many people worried that the firewall would stop their applications from working correctly. This was rarely the case, though, because of the firewall’s design. The firewall allowed all outbound traffic to leave your computer, but blocked all inbound traffic that wasn’t in reply to some previous outbound request. The only time this design would break an application on a client was if the application created a listening socket and expected to receive inbound requests. The Windows XP firewall allowed for simple configurations of exceptions for programs or ports (but, unfortunately, not through Group Policy).

The bigger deterrent was the security theater performed by manufacturers of other client firewalls. Some people believed that the design of the Windows XP firewall—namely allowing all outbound traffic to leave unfettered—was insufficient functionality for a client firewall. The argument was that a sufficient client firewall should block all traffic, inbound and outbound, unless the user has specifically granted permission.

Now, let’s think this through for a moment. Two scenarios emerge.

• If you’re running as a local administrator and you are infected by malware, the malware will simply disable the firewall. You’re 0wn3d.
• If you aren’t running as a local administrator and you get infected by malware, the malware will cause a third-party firewall to raise a dialog filled with a foreign language involving ports and IP addresses and a very serious question: "Do you want to allow this?" The only answer, of course, is "Yes, you stupid computer, stop harassing me!" And once that dialog goes away, so does your security. Or, more commonly, the malware will simply hijack an existing session of a program you’ve already authorized, and you won’t even see the dialog. Again, you’re 0wn3d.

There’s an important axiom of security that you must understand: protection belongs on the asset you want to protect, not on the thing you’re trying to protect against. The correct approach is to run the lean yet effective Windows firewall on every computer in your organization, to protect each one from every other computer in the world. If you try to block outbound connections from a computer that’s already compromised, how can you be sure that the computer is really doing what you ask? The answer: you can’t. Outbound protection is security theater—it’s a gimmick that only gives the impression of improving your security without doing anything that actually does improve your security. This is why outbound protection didn’t exist in the Windows XP firewall and why it doesn’t exist in the Windows Vista™ firewall. (I’ll talk more about outbound control in Windows Vista in a bit.)

What’s New in Windows Vista?

The Windows Filtering Platform, part of the new network stack, is the foundation for the Windows Vista firewall. Like Windows XP, Windows Vista blocks inbound traffic by default. Depending on which profile your computer is using, there might be some default exceptions for network services (I’ll discuss profiles later). You can, if you wish, write rules to allow inbound connections. Also like Windows XP, Windows Vista by default allows all outbound traffic from interactive processes, but restricts outbound traffic from services that participate in service restriction. And, again, you can write rules to block additional outbound connections.

The big difference between Windows XP and Windows Vista is the new Advanced Security interface and full Group Policy support for configuration and rules (see Figure 1). The old Control Panel UI is still there and it’s mostly unchanged except for logging and Internet Control Message Protocol (ICMP) settings, which are now in the new UI. This new UI, the Advanced Security MMC snap-in, offers all the new features and flexibility. There’s also a new context in the netsh command, netsh advfirewall, through which you can script rule addition and deletion, set and show global and per-profile policies, and display the firewall’s active state. And for you developers, FirewallAPI.dll and Netfw.h provide programmatic control over all of the firewall’s settings.

Figure 1** Windows Firewall with Advanced Security **(Click the image for a larger view)

The Advanced Security MMC is wizard-driven. When creating a rule, you can choose one of four types: program, port, predefined, or custom. These are explained in Figure 2.

Figure 2 Four types of rules

There are many elements that you can reference when writing rules, all of which are available for local rules and rules applied through Group Policy. These include: Active Directory® user and computer accounts and groups, source and destination IP addresses, source and destination TCP and UDP ports, IP protocol numbers, programs and services, types of interfaces (wired, wireless, or remote access), and ICMP types and codes.

Once configured, the firewall processes rules in the following order:

Service Restrictions Some of the services in Windows Vista will restrict themselves to limit the likelihood of another Blaster-style attack. One of the restrictions is a list of ports the service requires. The firewall enforces this and prevents the service from using (or being told to use) any other port.

Connection Security Rules The Advanced Security MMC incorporates IPsec as well as the firewall. Any rules that include IPsec policies are processed next.

Authenticated Bypass These allow specified authenticated computers to bypass other rules.

Block Rules These explicitly block specified incoming or outgoing traffic.

Allow Rules These explicitly allow specified incoming or outgoing traffic.

The firewall rules are stored in the registry, but I’m not going to tell you exactly where. Oh, OK, you’ll find them at these locations:

• HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
• HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
• HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System

Just please don’t edit the rules directly in the registry. If you do, we’ll find you and sell your pet on eBay! Well, maybe not, but the only supported way to edit rules is to use the Advanced Security MMC.

Network Profiles

Windows Vista defines three network profiles: domain, private, and public. When the computer is domain-joined and has successfully logged into the domain, the computer automatically applies the domain profile—you never get to make this choice on your own. When the computer is connected to an internal network that lacks a domain (like a home or small office network), you (or an administrator) should apply the private profile. Finally, when the computer is directly connected to the Internet, you should apply the public profile.

How does Windows Vista decide where to place your computer? Whenever there’s a network change (say it receives a new IP address or sees a new default gateway or gets a new interface), a service called Network Location Awareness (NLA) detects the change. It builds a network profile—which includes information about existing interfaces, whether the computer authenticated to a domain controller, the gateway’s MAC address, and so on—and assigns it a GUID. NLA then notifies the firewall and the firewall applies the corresponding policy (there’s a policy defined for each of the three profiles).

If this is a new interface that the computer hasn’t seen before and NLA didn’t choose the domain profile, then you’ll see a dialog box that asks you to indicate what kind of network you’re connecting to. Mysteriously, there are three choices: Home, Work, and Public. You might think that Work means the domain profile, but that’s not actually the case. Remember, you never see the domain profile because NLA automatically selects that when the computer logs onto a domain. In reality, both Home and Work correspond to the private profile. Functionally, they’re equivalent—only the icons are different. (Note: you must be a local administrator, or able to elevate to a local administrator, to select the private profile.) As you’d expect, public corresponds to the public profile.

In Windows Vista, a network profile applies to all the interfaces in the computer. Here’s a rundown of the NLA decision tree:

1. Examine all connected networks.
2. Is any interface connected to a network classified as public? If yes, set the computer’s profile to public and exit.
3. Is any interface connected to a network classified as private? If yes, set computer’s profile to private and exit.
4. Do all interfaces see a domain controller and did the computer successfully log on? If yes, set computer’s profile to domain and exit.
5. Else set computer’s profile to public.

The goal is to select the most restrictive profile possible. There are two obvious side effects, however. First, if your computer’s Ethernet port is connected to your corpnet and its wireless NIC is connected to the Starbucks downstairs, the computer will select the public profile, not the domain profile. Second, if your computer is directly connected to the Internet (in the public profile) or is connected to your home LAN (in the private profile) and you make a VPN connection to your corpnet, your computer will remain in the public or private profile.

What might this mean? The firewall’s policy for the domain profile includes rules for remote assistance, remote administration, file and print sharing, and so on. If you rely on these rules in order to get to a client remotely, you won’t be able to if the client has chosen some other profile. But don’t despair—you can write firewall rules to allow whatever inbound connections you need and then apply them only to VPN connections. Now you can still administer your clients over the VPN even when they aren’t in the domain profile.

Controlling Outbound Connections

Earlier, I said that the typical form of outbound protection in client firewalls is just security theater. However, one form of outbound control is very useful: administratively controlling certain types of traffic that you know you don’t want to permit. The Windows Vista firewall already does this for service restrictions. The firewall allows a service to communicate only on the ports it says it needs and blocks anything else that the service attempts to do. You can build on this by writing additional rules that allow or block specific traffic to match your organization’s security policy (see Figure 3).

Figure 3** New Inbound Rule Wizard **(Click the image for a larger view)

Say, for instance, that you want to prohibit users from running a particular instant messaging client. You can create a rule (in Group Policy, of course) to block connections to the login servers for that client.

There are practical limitations to this approach, though. For example, Windows Live™ Messenger (which you might still know as MSN® Messenger) has a variety of servers it can use to log in, and the list is always changing. Plus, it’ll fall back to port 80/tcp if the default port 1863/tcp is blocked. A rule to block Windows Live Messenger from connecting to its login servers would be too complex and always in flux. I mention this to illustrate that administrative outbound control can be useful, but isn’t a substitute for Software Restriction Policies if you need to maintain tight control over the software users are allowed to install and run.

Protect Your Computer

The perimeter is gone. Every computer must now take responsibility for its own protection. Just as anti-malware moved from the client to the edge, so firewalls must move from the edge to the client. You can take immediate action by enabling the firewall you’ve already got installed.

Whether your systems are running Windows XP or you’re already transitioning to Windows Vista, the Windows firewall is available to all your clients and will provide the protection you need to improve security within your organization—even when your mobile workers are thousands of miles away from the office.

Where to Learn More

• Windows Vista TechCenter: Getting Started with Windows Firewall with Advanced Security
• Windows Vista TechCenter: Windows Firewall with Advanced Security—Diagnostics and Troubleshooting
• Steve Riley’s TechEd Europe Presentation: Windows Vista Firewall and IPSec Enhancements
• The Cable Guy: The New Windows Firewall in Windows Vista and Windows Server "Longhorn"
• Windows Vista Firewall Virtual Lab

Steve Riley, a senior security strategist in the Microsoft Trustworthy Computing Group and contributing editor for TechNet Magazine, jets around the world to speak at conferences and spend time with customers to help them get and stay secure. His latest book is Protect Your Windows Network (Addison-Wesley, 2005). You can reach him at steve.riley@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.