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).
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:
- 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.