Before wading into an explanation of how to implement IPSec, we should first take a moment to introduce you to, or refresh your knowledge of, this free and very effective method of securing network transmissions.
On a theoretical level, IPSec is a framework designed to provide security for IP based network traffic. On a practical level, it is a network layer protocol that encrypts data so that it cannot be 'sniffed' from the network and then subsequently read or altered. IPSec achieves this functionality through two protocols called IPSec Authentication Header (AH) and IPSec Encapsulating Security Payload (ESP).
IPSec AH does not actually encrypt data, but it does provide authentication and guaranteed data integrity. In other words, with IPSec AH, someone can read the data in a transmission, but they cannot alter it. Nor can someone fake the source of the data. IPSec ESP, in contrast, focuses on securing the data in the transmission, though it does also provide some authentication, and a measure of data integrity checking.
The good news is that in a Windows Server 2003 IPSec implementation, as with most others, you do not need to choose between IPSec AH and IPSec ESP. You can use both protocols to get the full benefit of IPSec – authentication, guaranteed integrity of data, and encrypted data transfer.
IPSec and Windows Server 2003
Now that we have recapped what IPSec is and does, we can get on with looking at how to implement it.
IPSec functionality is provided on a Windows Server 2003 system through the IPSec Services service. So, the first step in configuring IPSec is to make sure that this is running on your server by looking in the Services MMC. On a
domain controller, the Services MMC can be accessed through the Administrative Tools menu. The IPSec service is configured to start automatically by default, so unless it has been stopped or disabled, your check should be nothing more than cursory.
The next part of implementing IPSec is choosing and assigning an IPSec policy. IPSec policies, once assigned, define what actions should be performed on incoming network traffic that does or does not meet a specified criteria.
IPSec policies, and their components, are configured through the IP Security Policy Management MMC snap-in. There is no shortcut to this MMC on the Administrative Tools menu, so you'll need to open a blank MMC and then add the snap-in to it. Once you have done this, you'll be able to start working in the IP Security Management MMC snap-in as shown in Figure 1.
Structure of Policies
The properties of an existing rule can be viewed by double-clicking the rule from within the IPSec Security Policies snap-in. The properties page for one of the default policies, which are discussed in a moment, is shown in Figure 2.
As discussed, policies define what actions are performed on network traffic when the server is using IPSec. Policies are comprised of rules that define what traffic should be covered by the policy, what kind of authentication mechanism should be used (more about the options for authentication later in this series), and what happens to traffic when it does or does not meet the criteria specified in the policy. This last process is known as the filter action. You can also define whether or not this rule applies to all network connections, just those originating from the LAN, or just from remote connections.
As you can see from Figure 2, there are three rules in this policy. The first defines that security should be requested for all IP traffic, and that the security should use Kerberos (
define) for authentication and encryption. The second rule defines that all ICMP traffic (such as that associated with ping and tracert) (
define) is permitted with no request for security. The third rule (<default>) defines what happens to traffic that does not conform to either of the first two rules.
Default IPSec Policies
Because the configuration of the IPSec rules can be somewhat complex, and because many environments will have the same level of need for their IPSec implementations, Microsoft includes three IPSec policies with Windows Server 2003. These policies are worth looking at before going to the effort of creating your own brand new policies. The three policies are Client (Respond Only), Server (Request Security) and Secure Server (Require Security). Each contains certain rules that define exactly how that policy affects IPSec traffic, but they can be summarized quite simply as follows:
When Client (Respond Only) is used, a Windows Server 2003 system will allow and provide for an IPSec connection if a client system requests it. All other connections will be allowed without IPSec. When Server (Request Security) is used, the Windows Server 2003 system will ask all incoming client connections to use IPSec. If the client is able to use IPSec, then it does precisely that.
If the client is not able to use IPSec, for example if the connection originates from an operating system that does not have an IPSec client, then the connection is till permitted to continue, though obviously without the security provided by IPSec. As the name suggests, when the Secure Server (Require Security) policy is used, all incoming requests to the server must be able to use IPSec encryption. If they cannot, then that connection is refused. The only exception in the rules that make up the Secure Server (Require Security) policy is that ICMP traffic is allowed to connect without encryption.
For the purposes of our discussion, we'll be using the Client (Respond Only) policy, but in a real-world scenario, you might find that you need to consider creating your own IPSec policies from scratch. As discussed, this is quite an involved process, and beyond the scope of this article. However, there are numerous excellent sources of information on this process, including Microsoft knowledgebase articles.
Assigning Policies
As we discussed in
part one, IPSec implementations on Windows Server 2003 are governed by policies. Once defined, these policies are assigned to the system and subsequently dictate behavior in respect to IPSec communications. As we also mentioned in the first part, Windows Server 2003 comes with three default IPSec policies. We'll be using two of these policies – Client (Respond Only) and Server (Request Security) – for the purposes of this demonstration.
The Client (Request Security) is considered the most liberal of the three default policies. A server assigned this policy will provide an IPSec-secured connection for clients that request one, but otherwise will allow connections to be completed as normal. In this article, we'll assign the Client (Request Security) policy to our Windows Server 2003 system. Then, when our client system asks for an IPSec connection, the server can provide it.
Before moving onto the configuration of IPSec, we should talk briefly about authentication systems. By default, the IPSec policies provided with Windows Server 2003 are configured to use Kerberos (
define) authentication. Kerberos is the default authentication protocol associated with Windows Server and Active Directory, so it's an obvious choice as an authentication mechanism for IPSec on Windows platforms. However, IPSec on Windows Server 2003 also supports digital certificates for authentication, as well as preshared keys.
A requirement of using Kerberos is that all systems involved in the IPSec process (client and server) are members of a
domain in Active Directory. Therefore, if you are configuring IPSec for non-Windows systems, you'll need to use one of the other authentication methods.
Before discussing policy assignment, we should issue a disclaimer. You should never run test configurations or try out new features like IPSec on a production server. The steps that follow are only intended for use on a test server. Although we are not going to suggest anything that might render a live server unavailable, not performing the steps as described could do exactly that. So, in the best interests of everyone, please keep your experiments to a test server.
To assign an IPSec policy, simply select the policy in the right-hand pane of the IP Security Policy Management MMC Snap-in, then right-click and choose Activate. A small green '+' sign appears on the folder icon of the policy to indicate that it is assigned. You can see an example of an assigned policy in Figure 1.
It should be noted that only one policy can be assigned at a time. You can't combine policies. If an existing policy does not meet your IPSec needs, you'll need to create a new one that does.
Because we are using the local security policy on the server, once you have assigned the chosen policy, there is no need to manually refresh the policy. However, you should keep in mind that if you were deploying IPSec through Group Policy, you would need to trigger a manual refresh of the policy or wait for the scheduled update cycle before your new settings would take effect.
That's it! Your server is now ready to respond to requests for incoming IPSec connections. All that is needed is a client system using IPSec to make use of the new functionality.
Client Side Configuration
The process of configuring IPSec on Windows XP Professional is basically the same as on Windows Server 2003. For the purposes of this discussion, we will enable IPSec functionality manually, but if you intend to deploy IPSec to more than just a few computers, you should consider using Group Policy to make the necessary client side changes.
On a Windows XP Professional system, the IPSec Policies can be configured most easily by accessing the Local Security Policy MMC from Control Panel, Administrative Tools. As you can see from Figure 2, the IP Security Policies snap-in is added to this tool by default. As an alternative to navigating through the Control Panel, you can click
Start,
Run and type
Secpol.msc in the Open field.
Once in the IPSec Security Policies snap-in, you can either use an existing policy, or create a new one. Windows XP Professional comes with the same three default IPSec policies as Windows Server 2003.
For the purposes of this demonstration, we'll enable the Server (Request Security) policy on the workstation. This will mean that requests to non-IPSec enabled hosts, like a Web server on the Internet for example, will be permitted without IPSec. Connections to hosts that do support IPSec will use encryption. This is a fairly common configuration for systems on a wireless network where you want to secure communications to internally hosted servers, but are less concerned about securing things like Web browsing traffic. Of course if you are accessing the Internet through a proxy server that is providing IPSec encryption, browsing traffic will also become encrypted, but that's another discussion.
Once you have assigned the policy, you can establish a connection to the server. The IPSec encryption will occur in invisibly in the background, though you may notice a very slight pause when you first connect to a server. This is because the IPSec communication session needs to be established each time a connection to a new host is made. Other than that, the IPSec encryption establishment and maintenance should be completely transparent. In fact, there is no way to tell that IPSec is being used without actually going and looking for it.
Monitoring and Verifying IPSec Traffic
Once you have set up your trial IPSec configuration, you'll want to be sure that
communications between your test workstation and server are indeed encrypted. There are a number of ways of doing this, but perhaps the easiest is to use the IP Security Monitor MMC snap-in. Once you have added the snap-in to an MMC on your server, navigate to the Statistics folder for your system, following the path shown in Figure 3 The statistics provided include the amount of data that has been sent and received in encrypted form, and the number of current security associations. This number represents the IPSec connections that are currently established between this server and other systems. To see details of these connections, click the Security Associations folder as shown in Figure 4.
As you can see, in this test scenario, there is a single IPSec session established between the server (192.168.1.102) and the Windows XP Professional client (192.168.1.100).
So, Is it Worth it?
At the beginning of Part One, we said that we would answer the question of whether implementing IPSec on your network was worth it. Hopefully we have demonstrated that the implementation process is very straightforward, and its operation completely transparent. In fact, it's hard to find fault with IPSec.
However, one consideration is that IPSec adds an extra layer of complexity to network troubleshooting. Every time you experience a connectivity issue, you have to consider whether the problem is with the underlying network structure, or with IPSec. It may be that IPSec is not the cause of the problem, but it's one more thing to consider, when you probably have enough to think about already. Additionally, on larger networks or those with already high network traffic levels, you should consider whether the additional (though minimal) network traffic associated with the setup and maintenance of IPSec connections would be a problem. Chances are it wont be, but it should be considered.
Ultimately, IPSec makes sense if you either feel that the data on your network is at risk, or if you value the security of your data enough to spend a small amount of time configuring your systems. Given that Microsoft provides all the software and tools need to configure and monitor IPSec, you have nothing to lose by giving it a try in a test environment.
مجوز های ارسال و ویرایش
2سپاس
LinkBack URL
About LinkBacks
