Introduction
The Windows Firewall has come a long way since it was first introduced in Windows XP and Windows Server 2003 SP2. In fact, with the Windows Firewall with Advanced Security, there’s no reason to even use a 3rd party firewall, although some administrators may prefer to do so for specific features or purposes. The Windows Firewall with Advanced Security (WFAS) has everything you need to create a secure networking configuration. In addition, the new WFAS adds to the firewall features and includes Connection Security Rules, which are IPsec rules that make it easier than ever to create secure IPsec connections between clients and servers, and from servers to server, on your network.
In this article, we’ll go over some of the new and cool WFAS features that are included in Windows Server 2008 R2 and Windows 7.
Assign Different Firewall Profiles to Each NIC
In the Windows Firewall of the past, you could only have one firewall profile can be active at a time. If a computer is connected to more than one network, then the profile that had the most restrictive rules was applied to all NICs. The Public profile was the most restrictive, then the Private profile, and finally the Domain profile. This could cause problems by unnecessarily restricting access on domain and private networks.
Now this works as it should: each NIC is assigned its own profile. Traffic sent to or arriving from each network is processed according to the rules that are appropriate for the NIC that connects to each network.
Party Down with Dozens of Firewalls
WFAS is a lot more than just a simple host-based firewall. In addition to the firewall, it includes:
- IPsec connection security rules
- Network service hardening
- Boot time filters
- Firewall filters
- Stealth filters
In the past, turning off the firewall meant also disabling all of the other services the Windows firewall provided. That meant that if you installed a different firewall that didn’t provided all the services Windows firewall does, you lost those Windows firewall services (and possibly exposed the system to threats). Now when another host-based firewall is installed, the firewall’s installer can disable components of the Windows Firewall that conflict. Other Windows Firewall services remain enabled.
Got Intermediate CAs? No Problem!
In the past, the connection security rules only used certificates issued by a root Certification Authority. You can now use certificates issued by intermediate CAs for your IPsec based Connection Security Rules.
Not Everyone Needs to Show His Papers
You can now create firewall rules that specify exceptions to the authorized list. This allows you to create firewall rules that say “everyone except a, b, and c” can access the host. Traffic from computers or users you specify in the exception list is blocked even though traffic from all other members of the authorized list are permitted. You can also create rules for outgoing traffic specifying authorized computers and exceptions to the authorized list.
Use the GUI to Configure Ports and Protocols for Connection Security Rules
Now you can use the MMC to create Connection Security Rules that specify port numbers or protocols. Only network traffic to or from the specified ports, or using the specified protocol, are subject to the IPsec requirements of the connection security rule. In the past you had to go to the “dark place” and use the netsh command to create these rules. Why would you want to live in a 1960s command line world when you have a cool and useful GUI? Now you don’t have to!
Configure Firewall Rules that Support an Entire Range of TCP or UDP Ports
Now you can configure rules that include ranges of port numbers. For example, you can apply a rule that uses ports 5000 through 5010. You can also use port ranges in Connection Security Rules that specify authentication exemption.
The Windows Firewall Now “B” Suite!
Connection Security Rules now support the “Suite B” set of algorithms that are defined in RFC 4869. In the past you had to drive yourself nuts trying to create Suite B rules by using the netsh tool. This is great news for all of those admins who had been afraid that the “soul of Windows” was fading away into a Linux like command line nightmare (a.k.a. PowerHell). Don’t get me wrong; the command line is great for certain tasks, and some folks prefer to do most of their work there. But others like Windows specifically because of its graphical interface, and I like having both options.
Authenticate While Making the Network Guys Happy at the Same Time
You can now create Connection Security Rules that enable IPsec authentication but with no Encapsulating Security Payload (ESP) or Authenticated Header (AH) protection on the data packets. That’s right! You get authentication without encryption. This makes authentication possible when the network guys spaz out and tell you that you can’t use ESP or AH because they put the company in hock by paying inflated prices for network IDS device that no one ever looks at. This new feature allows you to authenticate with the connection attempt, but there is no IPsec encryption, so the IDS can see everything moving over the wire.
Get IPsec Protection for Mobile Devices
Now you can get IPsec protection even when you can’t predict what the IP address of both sides of the connection will be. In the past, you couldn’t create IPsec rules for situations when one of the hosts would be assigned a dynamic IP address.
IPsec Tunnel Mode Gets a Boost
Now you can configure IPsec tunnel mode to allow both authenticated and authorized computers and users to establish a tunnel to your IPsec gateway. This is something that DirectAccess takes advantage of to allow both user and computer authentication for the infrastructure and intranet tunnels.
You can create tunnel-mode rules that define authentication that can authenticate a computer or user. Then the computer or user account is compared to the authorized list and then the tunnel is established and data can be exchanged if the user or computer is authorized. If the account is not authorized, then the connection fails. You can also specify exceptions, which allows you to create “everyone except UserA” rules in the console. One limitation is that Tunnel-mode authorization only works for inbound tunnels.
What’s the Diffie (Hellman) with AuthIP?
Authenticated IP (AuthIP) is used instead of IKEwhen you create rules that have settings that are not supported by IKEv1. AuthIP uses the secret generated by the authentication method requested. For example, if you use Kerberos V5 authentication, then the Kerberos secret is used instead of the secret generated by a Diffie-Hellman exchange. However, you might want to use Diffie-Hellman. If so, now you can require that Diffie-Hellman be used in all IPsec main mode negotiations, even when AuthIP is used for authentication.
Use different Diffie-Hellman algorithms in main mode proposals
In Windows Vista and Windows Server 2008, you can specify only one Diffie-Hellman algorithm that is used in all IPsec proposals. This restricted you to ensuring that all computers in your organization used the same single Diffie-Hellman algorithm for IPsec negotiations. Starting with Windows 7 and Windows Server 2008 R2, you can specify a different Diffie-Hellman algorithm for each main mode proposal that you create.
Feeling the Love for IPv6 Transition Protocols
Sure, there’s Teredo and 6to4, but those are so yesterday. How about something new and improved and created by Microsoft? That’s what you get with IPv6 over HTTPS, also known as IP-HTTPS. IP-HTTPS is a new IPv6 transition technology that embeds IPv6 packets inside an HTTPS header. IP-HTTPS allows IPv6 traffic to move over an IPv4 Internet and performs a function similar to Teredo and 6to4. However, unlike Teredo, you don’t have to open a special port on the firewall to allow access to IP-HTTPS, since everyone knows that TCP port 443 is the universal firewall bypass port.
However, you can still use Teredo. Like IP-HTTPS, Teredo is a tunneling protocol that attaches an IPv4 header onto IPv6 packets. For a Windows Firewall inbound rule, you can set the UDP port to Edge Traversal instead of a specific port number to have Windows Firewall automatically recognize and handle the connection appropriately.
Don’t Encapsulate Unless you Have To
In the past, when network traffic that was IPsec protected was sent through an IPsec tunnel, it was wrapped in an IPsec and IP header. That’s a lot of headers! Now when you want to configure a tunnel-mode rule, network traffic that is already IPsec protected will be exempted from the tunnel, and it moves to the tunnel endpoint without additional encapsulation.
Get a Clear View of Firewall Events in the Viewer
In the past, all firewall events were considered “audit”events, and were generated only if the appropriate audit category was enabled. Now some of these events are considered “operational” events, and appear in the Event Viewer without having to be enabled first. They appear under Applications and Service Logs \ Microsoft \ Windows \ Windows Firewall with Advanced Security. This makes it a lot easier to troubleshoot any number of firewall related scenarios.
Summary
The Windows Firewall just keeps getting better and better! In this article, we went over a number of new and improved features included in the Windows 7 and Windows Server 2008 R2 firewall. If you already know the Windows Firewall with Advanced Security, you’re aware of the power you get with this built in host-based firewall. If you’re new to the Windows Firewall with Advanced Security, then you should be getting the impression that the built in firewall included with Windows is all you need, and there is often no reason why you would need to install a third-party firewall (which frequently creates a situation where you have system instability and finger pointing). Also, keep in mind that the Windows Firewall with Advanced Security is much more than just a firewall. Its main duty outside of host-based firewall is its responsibility for IPsec connections, which depend on Connection Security Rules.
