Because I support the Windows Firewall I often get asked for guidance on deploying it. David Bishop wrote a nice white paper on deploying the Windows Firewall so I won’t repeat it all here but this is my go to link when I am asked about group policy or how to deploy the Windows Firewall.
Windows Firewall with Advanced Security: Step-by-Step Guide: Deploying Windows Firewall and IPsec Policies
The second question I often get is about what other people are doing and what recommendations does Microsoft have? The only real world example I can provide is the Microsoft Deployment and for that I point to the ITShowcase documents linked below. I do not have concrete data on companies outside Microsoft. Some use 3rd Party Firewall products and I won’t fault them for that but I find they have often failed to understand what features the Windows Firewall has… but more on that later.
Another point of confusion is how Firewall rules are processed, where they are stored, and why the display can be different. I am only going to talk about Windows 7 here to keep things simple but basically the same concepts apply to Windows Vista as well.
Firewall rules can come from multiple places or stores and from the command line perspective you can change the store you are using via Netsh advfirewall set store.
Usage: set store local|gpo=<computer name>|gpo=<domain\GPO name>| gpo=<domain\GPO unique ID>
Note: There is a hotfix to add this command to Windows Vista http://support.microsoft.com/kb/973509
As you can see there are three basic ways to identify the store you want. The main confusion here is that by default netsh shows you the local store but the GUI shows you all the stores. So what you are able to see in the GUI will often vary from what you see at the command line.
Note: When using the “Netsh advfirewall set store” command you must stay in the same interactive session, otherwise the store setting is lost which limits the usefulness when scripting.
The fact that rules can be from different stores will also come into play with the “Apply Local Firewall Rules” setting but more about that later. First let’s talk about how firewall rules get applied. The rules are put into buckets and processed from a top down perspective. Within the buckets rules are matched to the most specific match.
The 6 buckets are:
Windows service hardening rule The Windows service hardening rule restricts services from establishing connections. Service restrictions are configured in such a way that Windows services can only communicate in a specific way. For example, you can restrict traffic through a specific port. However, until you create a firewall rule, traffic is not permitted.
Connection security rule The connection security rule defines how and when computers are authenticated by using the IPsec feature. Connection security rules are used to establish server isolation and to establish domain isolation. Additionally, connection security rules are used to enforce the Network Access Protection (NAP) policy.
Authenticated bypass rule The authenticated bypass rule lets certain computers be connected if the traffic is protected by using the IPsec feature regardless of other incoming rules. Specified computers can bypass incoming rules that block traffic. For example, you can enable remote Firewall administration from certain computers only by creating authenticated bypass rules for the computers. Or, you can enable support for remote assistance by calling Helpdesk.
Block rule The block rule explicitly blocks a certain type of incoming traffic or a certain type of outgoing traffic.
Allow rule The allow rule explicitly allows for certain types of incoming traffic or certain types of outgoing traffic.
Default rule The default rule is configured in such a way that the incoming default rule blocks connections, and the outgoing default rule allows for connections.
Note that block rules come before allow rules. This is important because it means a user can’t create an allow rule to bypass a block rule created by an admin. But a user can create a block rule that would prevent access even if the admin created an allow rule. It is the priority that matters not where the rule comes from (Note: One caveat is that you can prevent the processing of local rules). Within buckets it is the most specific match that matters but since the type of rules is the same it is not generally significant. This process is documented in:
Security rules for Windows Firewall and for IPsec-based connections in Windows Vista and in Windows Server 2008
Another question related to this is about how to prevent the local users from being able to create rules. While you can’t prevent the users from creating a rule you can prevent the rules created by users from being applied (BTW the rule will still be displayed in the GUI) by using the “Apply local Firewall Rules” setting. Again a user cannot create a rule to override a block rule from group policy.
In the interest of full disclosure a user could potentially override the “Apply local Firewall Rules” setting as documented in the MSDN article.
http://technet.microsoft.com/en-us/library/cc755191(WS.10).aspx The logging policy can be overridden by the local policy because the merger law is set to on.
Some 3rd party Firewalls have a management console that is used to apply firewall settings and monitor connections. It is difficult to make a direct comparison here because there is not a specific management console for global administration tasks with the Windows Firewall. We use the same management pieces as the rest of the OS would use. Things like Group Policy, Event logs, and SCCM are how we manage all pieces of the OS and by extension the Windows Firewall. It is really apples and oranges when comparing this and is more about how you currently manage the Windows OS in your environment.
Will XP policies affect Win7 and vice versa?
Windows Firewall with Advance Security policies and legacy Windows Firewall polices are store in different places. While this doesn’t matter for rules themselves because they are processed in buckets it can make a difference for other Firewall configuration settings.
Legacy Firewall settings primarily apply to Windows XP and Windows Server 2003 and are stored under:
Computer configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall
Windows Firewall with Advance Security policies primarily apply to Windows Vista\Windows Server 2008 and Windows 7\Windows Server 2008 R2 and are stored under:
Computer configuration -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security
One common issue is that disabling the Firewall in either place will disable the Firewall for all OSes.
In Windows 7 and Windows Server 2008 R2, the predefined IPHTTPS port was introduced:
If you create a rule in group policy using the MMC in Windows 7 or Windows Server 2008 R2, you will have the option to use the IPHTTPS port. If this policy is then applied to a Windows Vista or Windows Server 2008 (not Windows 2008 R2) machine, the port will be translated as “Any” because Windows Vista does not understand the predefined IPHTTPS port. This is particularly important because there is also a predefined rule that uses the IPHTTPS port called “Core Networking – IPHTTPS(TCP-In)” in the Core Networking group:
The problem is that it translates into an “any-any” rule that allows all traffic when applied to Windows Vista or Windows Server 2008. It still doesn’t override a block from the administrator but it does mean that if there is not a specific block the traffic will be allowed because the default rule will never be hit.
As a workaround, you should use a WMI filter to be sure this rule does not apply to Windows Vista or Windows Server 2008, or ensure that any rules using the IPHTTPS port are verified not to allow all traffic.
The recommendation here is to use the defaults – In other words, don’t block outbound traffic.
While the Firewall is capable of blocking outbound traffic, it is not an easy task and in my experience far more complex than most people are willing to manage.
There are generally two concepts that I find behind this kind of request.
The problem with the security argument is that you aren’t talking about unsolicited inbound requests. This is outbound traffic and the application sending it is already on the local machine. If it has permissions (or manages to get them) it can create a rule for itself or even stop the Firewall all together. If security is really the concern you should look into APPLocker http://technet.microsoft.com/en-us/library/ee619725(v=WS.10).aspx for controlling what apps can run on the machine or other OS hardening like the Windows 7 Security Baseline http://technet.microsoft.com/en-us/library/ee712767.aspx
The other reason I often hear is the wish to control what users can access. This gets complex because you have to know every application the user legitimately uses and what ports it might need to connect on. When you start adding in things like Dynamic RPC ports it gets complex pretty fast. Also the Windows Firewall is not a content filtering application. It blocks based on ports and IPs. So for example - if you open port 80 for Windows update the user will be able to surf the web.
The last issue I want to mention is that if you make a mistake and block access to group policy you can’t undo it because you have blocked your ability to update policies.
In short the Windows Firewall is generally not the proper tool for the job of blocking outbound traffic and I don’t recommend you attempt to block outbound traffic without a lot of careful consideration.
This was not meant to be a complete guide to deploying the Windows Firewall. David Bishop’s doc is more suited to that, but I hope it provided you a good starting point to understanding the concepts and things you need to get started as well as highlighting some of the gotchas people come across.
- David Pracht