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.

Monday, 31 October 2011

Network Access Control (NAC)

With Windows Server 2008, Windows Vista SP1, Windows 8 and Windows XP SP3 we have a simple and effective way to make sure that we have checked and validated systems before they are allowed to access critical files.

NAP allows us to have isolated network segments and quarantine zones using IPSec and the Windows Firewall to restrict untrusted hosts. Microsoft state that there are three (3) zones, but the reality is there are four(4) logical segments that can be constructed. These are the:

  1.  Restricted Zone: All hosts that have not been issued a health certificate lie in this zone. This will include every host that is yet to be validated. Any host that cannot become a part of the Secure zone (such as legacy devices that do not support IPSec) will also reside in this zone. Guest hosts (such as those from consultants and other third parties) will be located in this zone and will be restricted from network communications with the secured systems (hence limiting the effects of malware). Any hosts in the restricted zone are unable to initiate communications with secured hosts and are limited to communications with the hosts in the boundary zone.
  2.  Boundary: This zone contains a set of systems that have health certificate but also do not require those systems that communicate with them to have a health certificate. You would locate Proxy servers that are open to hosts in the network zone, enforcement servers and remediation servers in this zone.
  3.  Secure: This zone requires that all servers have valid health certificates. These health certificates are used to provide IPSec authentication. You can allow any Windows host or server to communicate with any other in this zone or you can use Group Policy and Security Groups to limit the access to either ports, folders or anything else you may wish to configure on a host and user basis.
  4. Isolated: This is not an official zone but an attacker can be logically isolated and blacklisted from communications with even the Boundary network.


The reality of this is that we can create more than these zones with layers of secure zones based on the access requirements as defined in security groups.

Users and hosts can be located anywhere. This means we can have global roaming users connecting to the secure system in full knowledge of how they have been validated and restricted from external access when connected into the secure network.


First, the “Secure Network” is by default allowed to connect to other networks.


Although default access is allowed from the Secure Trusted Zone to anywhere, we would want to restrict this to allowed hosts and servers (logically allowing us to create a secure zone as we are used to doing in the hardware firewall world).

To stop exfiltration of data, always force users (and servers) to exit the secure zone using enforcement points (including proxy servers). This means, only allow selected servers (again such as a proxy server) to send data from *3 to *1.

What is a “Health Certificate”?

A Health certificate is a locally created and signed X.509 certificate. This means that you will need to run the Windows CA (Certification Authority) Service to have NAP as this certificate is used to assert the health compliance of a NAP client host and also is used in authenticating to the secure zone computers using IPSec. Without a health certificate, your host cannot communicate to the systems in the secure zone directly.

In general, health certificates are configured with a short lifetime. This is configurable but is in  on the order of days or hours.

The hosts (NAP client) will use the Health Certificate Enrolment Protocol (HCEP) in order to request a certificate and to update a certificate from a server designated as a Health Registration Authority (HRA).

The HRA is a Windows Server 2008 system with the IIS (Internet Information Server) service running. This system is used to validate the “health” of  client systems. If these systems pass a health check (i.e. Anti virus signatures are up to date and the host has all the latest patches), the HRA will request a health certificates from the domain certification authority (CA). This is done on behalf of the compliant NAP client computers as until they have been issued with a health certificate, they cannot communicate directly with any host in the secure zone and are restricted to communications with hosts and servers located in the Boundary Network.

As a result, the HRA is critical to the implementation of an effective NAP Internet Protocol security (IPsec) enforcement strategy.

What NAP does…

NAP goes through several stages. These are:

  • 1. Policy Validation: System health validator (SHV) servers first check the “health” of client systems that are requesting access to the secure domain. Basically, this stage checks that the client is compliant with the policy used and enforced within the organisation.
  • A NAP health policy server software counterpart to a system health agent (SHA). An SHV verifies the statement of health (SoH) made by its corresponding SHA.

  • 2. NAP enforcement and network restriction: These systems limit network access. They act as go-between’s to the secure network for non-compliant servers and hosts and allow some limited but controlled access to the secure zone.
  • 3. Remediation: Non-compliant hosts can be placed into quarantine and forced to have patches, signature updates and more applied.
  • 4. Ongoing monitoring and auditing: A health certificate does not last forever and can also be revoked. If a system is seen to become non-compliant, it can be isolated from the secure network.


NOTE: This is important!

NAP only works with ACTIVATED hosts and servers. If you have not activated a system, it will not be allowed to play. This is a little something from Microsoft to try and make sure that people have valid software licencing.


The webinar, "How much do I really need to spend on security?" is loaded and available to listen to now.