Wednesday, 2 November 2011

Firewall Policy creation in Group Policy (Part 1)

Tonight we are going to start by looking at creating an IPSec tunnel in Windows  Server. This will allow us to enforce authentication and connection rules between hosts and to ensure that our systems cannot be intercepted (at least not easily).

We start by loading the MMC (Microsoft Management Console) with the Server Manage plug.

Open, Configuration –> Windows Firewall with Advanced Security (displayed below).


Click, Connection Security Rules under the “Getting Started section”.


This will start with an initial empty set (if no rules have been configured yet). Start by selecting “New Rule” to add a rule.


The first step in creating a rule is to choose the “rule type”. These are displayed in the image below:


In this, we have the rule types:

  • Isolation: This is used to restrict connectivity. There are a number of ways to do this and several reasons. One example would be in restricting access to domain hosts to only allow connectivity to other domain hosts (and hence forcing systems to access the Internet via authorised Proxy Servers). Another reason for this would be in restricting access to systems with a valid “health certificate”and hence isolating or quarantining systems without a valid “health status”. That is, a system that is not patched or has not been set with an up to date anti-malware signature.
  • Authentication Exemption: This rule exempts certain systems from requiring IPSec authentication. Our “Boundary Zone” NAP systems may fall into this category. Windows Firewall can still block connections to selected ports and services, but the server will not require IPSec (AH or ESP) based authentication. Some servers and in particular some services that require this (as they are open) include, DNS, DHCP, public services (HTTP, SMTP etc.) and CAs. Any server that MUST communicate with systems that do not support IPSec or that are outside the Windows domain (including those that have to be involved in the enrolment process) will be here.
  • Server-to-server: This is the typical run-of-the-mill Endpoint–to–Endpoint IPSec policy between hosts. This rule is similar to an Isolation rule but allows you to select the Endpoints.


      • Tunnel: This is a typical IPSec tunnel mode connection. This can be used to create gateways and connectors in a distributed network. These hosts will take traffic from one system, encrypt it, send it and then forward it to another host. Basically, it makes a secure path between systems over insecure networks. This is a traditional gateway to gateway VPN.


  • Custom: You can use a custom rule type to create a rule that requires special settings. This will include creating rules for both authentication as well as encryption for non-domain IPSec hosts. With a little effort, you can configure rules for Linux, Mac and mobile devices using the custom rules. In this setting, all of the wizards that are included with the other pages are included (except the ones that only allow you to create tunnel rules).

The differences between IPSec tunnel and transport mode are displayed in the image (modified from the 6Bone IPv6 training materials) below.


This firewall setting is used to create a Distributed Security Model. The main advantages of this model include:

  • Flexibility in the definition of security policies
  • Protects against internal attacks
  • Doesn’t depend on where the host is connected to

That is, we move away from a crunchy shell. As more and more systems become connected to the net and more users act in isolation from the traditionally protected central enclave, we need to move from the old (and out-dated) model of security in physical zones to one of logical zones.


From the “Rule Type” menu, when we have selected “Isolation” and clicked next, we will be taken to the “Requirements” page.


We can see three options in this page:

  • Request authentication for inbound and outbound connections
  • Require authentication for inbound connections and request authentication for outbound connections
  • Require authentication for inbound and outbound connections

The term “Request” means that we ask a host to authenticate, but still allow it to connect if IPSec is not available.

Require” on the other hand means that we will not allow this host to communicate without a valid IPSec (either AH or ESP) tunnel.

The most secure option is to set all hosts in this zone (this excludes public hosts) to “Require” both inbound and outbound IPSec is used. If you still have a requirement to monitor traffic, AH can be used such that you can see clear-text traffic but that it is authenticated and the integrity of communications is maintained.

On selecting one of these options, the next tab will take you to the authentication page. Here you need to select the type of authentication required by the host.


To use “Health Certificates”, select the “Advanced” option on the page and click “customise”.


Click “Add” to add first the “First Authentication Method” and optionally the second.


We can use “Health Certificates here (configuring these will be covered in a future post). The default methods for authenticating include:

  • NTLMv2
  • Kerberos V5 (Windows version)
  • A CA Certificate
  • PSK (PreShared Key)

The last method, PSK, is not recommended for general use but may be necessary if older devices (such as network switches)  that are not a part of the Windows Domain infrastructure are to be incorporated into the IPSec authentication scheme.

Most newer switches and routers (e.g. Cisco and Juniper) support certificate based authentication for IPSec. Using this, you can manage these devices from Windows using a Windows Radius Server over a secure tunnel. This would fir example allow you to have telnet enabled, but only accessible via an IPSec ESP tunnel between the hosts. Even Telnet, a notoriously poorly deployed protocol can be made secure in this manner.


We continue with this in tomorrow’s post.


Matthew said...

Consider the following scenario:
1. The Secure Trusted zone consists of a single AD domain, configured as you stated in this article.
2. A proxy server is situated in the Secure Trusted zone, which forwards requests to other servers in the Secure Trusted zone.
3. A non-domain client host, or a client host in another AD forest (no trusts between forests), requires access to the proxy server. The client host is not in the Secure Trusted zone, but is on the organization`s network (with appropriate network boundaries, etc, between zones).

How would you configure firewall policy to allow the client host to forward requests to servers in the Secure Trusted zone via the proxy server only? Can this scenario be secured?

If you are going to cover this in another post, that is fine; otherwise, an answer is appreciated.

Thank you,

Dr Craig S Wright GSE said...

I will be covering this scenario soon. This was just a particularly busy week.

Basically, (2) the part trusted Proxy is what I was getting at and will detail. Here there is both outgoing to selected servers that is secured as well as unsecured traffic to the net as a whole and only secured connections to the server in the first place.

For (3), you can have a Certificate or other means. This would be a guest host (e.g. one belonging to a consultant etc).

I will cover this with:
A) Guest passwords
B) Single use keys
C) Certificates
D) Domain Credentials

So much to cover... so little time for everything :)