Storage Basics: Securing iSCSI Using IPSec, Part 2

In a previous Storage Basics article, we looked at securing IP communications using the IPSec protocol.

With many storage implementations moving toward IP-based solutions such as iSCSI, the importance of securing IP transmissions becomes critical, especially considering that many of the programs we use send clear text across the network. Such applications include FTP, Telnet, POP3 and IMAP.

In a heterogeneous environment, we have the option of securing communication at both the application layer, using protocols such as Secure Sockets Layer (SSL) or the Transport Layer Security (TLS), and on the IP level using IPSec. The purpose of this article is to display how communications are secured using IPSec in a Windows 2003 Server.

We know that out of the box IP lacks security, but for many applications this is not a problem. However, for those communications that require security, we need to configure IPSec. Enabling IPSec using Server 2003 is a straightforward process, but getting the right level of security can be tricky.

Setting Security Levels

In general, there are four security strategies from which to choose when securing data with IPSec. These include:

• Block transmissions: Block transmissions tell IPSec to block all transmissions from computer A to computer B. The transmission is simply dropped by the receiving system. Blocking all traffic is a heavy-handed approach to a security strategy and is not often used.
  


• Encrypt transmissions: The encrypt transmissions option is used when it is necessary to allow communications between computers, but the data must be encrypted to prevent eavesdropping. In such an instance, IPSec is configured using the Encapsulating Security Payload (ESP) protocol to encrypt data. Those attempting to look at the data will see only an unreadable stream of bytes.
  


• Sign transmissions: The sign transmissions option is used to prevent "man-in-the-middle" attacks. The Authentication Header (AH) protocol for digitally signing communications adds a bit of data at the end of network packets to verify that the data has not been changed during transit.
  


• Permit transmissions to travel unchanged without signing or encryption: This option is the absence of security. Essentially, this allows all traffic to pass without verifying data integrity.

Page 2: Developing an Overall IPSec Security Strategy

Continued from Page 1

Developing an Overall IPSec Security Strategy

With a basic idea of the security options available using IPSec, the next step is to develop an overall IPSec security strategy. As with other security measures, this involves finding the balance between making information accessible to the largest number of users, while at the same time protecting sensitive information from unauthorized access.

In the security world, there is no exact definition of the measures that define a standard security policy. Security strategies can vary widely, depending on an organization's policies and infrastructures. The following security levels can be considered a general basis for planning your IPSec deployment:

Minimal security: Sensitive data is not passed between computers and, therefore, IPSec is not active by default. In Server 2003, no administrative action to disable IPSec is required.

Moderate security: When network systems such as database or file servers hold or transmit sensitive data, IPSec security measures must be put in place. However, these security measures must be balanced so they do not interfere with daily operations. Server 2003 provides default IPSec policies that secure data but do not force overly prohibitive security measures: Client (Respond Only) and Server (Request Security). Using these default security designs can optimize efficiency without compromising security.

High security: For the data that cannot be tampered with or comprised in any way, a high IPSec security configuration is used. In some cases, a default IPSec security setting, Secure Server (Require Security), will provide the level of security needed. Unsecured communication with a non IPSec-aware computer is not allowed.

Page 3: Configuring IPSec Security

Continued from Page 2

Configuring IPSec Security

Once the level of IPSec security has been identified, the next step is to configure IPSec security. The IPSec policy configuration is the translation of your security requirements into one or more IPSec policies, only one of which can be assigned at the domain, site, organizational unit, or local level. Each IPSec policy consists of one or more IPSec rules, with each IPSec rule consisting of a filter list, filter action, authentication method and connection type.

The filter list determines which IP traffic is to be affected by the security rule. Once the filter list is triggered, then the filter action is applied. The filter actions identify how security will be handled for the IP addresses identified in the filter list. There are three actions that can be taken when configuring IPSec filter actions:

• Permit: The Permit IPSec security option is the absence of security. Packets are allowed to travel around the network without IPSec protection.
  


• Block: On the other side of the security spectrum is the Block option. When the block filter option is used, a protocol that matches the associated IP filter will not be accepted on the network.
  


• Negotiate Security: If an IPSec filter is matched, the Negotiate Security option enables the administrator to set the encryption and algorithms that must be used to secure data transmissions.

Another key element to IPSec rules is authentication. There are three different authentication methods we can assign to an IPSec rule:

• Kerberos: Kerberos V5 is the default authentication technology used with Server 2003. Kerberos provides the primary security protocol for authentication within a domain. When used, it verifies both the identity of the user and network services. Advantages of Kerberos include interoperability and the fact that it can provide mutual authentication between the user and the server. Kerberos can provide authentication between Server 2003 domains and systems in a UNIX environment that is using Kerberos for authentication.
  


• Public Key Certificates (PKI): PKIs are used to authenticate clients that are not members of a trusted domain, non-Windows clients, or computers that are not running the Kerberos V5 authentication protocol. The authentication certificates are issued from a system acting as a Certification Authority (CA).
  


• Preshared Keys: In preshared key authentication, computer systems must agree on a shared, secret key to be used for authentication in an IPSec policy. Preshared keys are only to be used where certificates and Kerberos cannot be deployed.

Page 4: Predefined IPSec Policies

Continued from Page 3

Predefined IPSec Policies

As mentioned, the rules that we make for IP traffic are used to create IPSec policies. Server 2003 includes three predefined IPSec policies that may meet the security needs of an organization. These security policies may work in their default state or they can be modified to accommodate the unique needs of an organization.

By examining the default options available and reviewing their settings, we get a better idea of what needs to be done when creating a policy from scratch. The default IPSec policies include: Client (Respond Only), Server (Request Security), and Secure Server (Require Security).

Client (Respond Only)

In the Client (Respond Only) configuration, the client tells Server 2003 not to use the IPSec option by default. Instead, IPSec is only engaged when it is requested by another system or network device. In this configuration, the client system will never initiate IPSec security, but will communicate using IPSec when requested to do so.

This default policy is built from what is known as the default response rule. This default rule applies to both inbound and outbound connections. The default configuration settings are:

IP Filter List: <Dynamic>
Filter Action: Default Response
Authentication: Kerberos
Tunnel Setting: None
Connection Type: All

If any of these default settings do not meet our needs, they can be modified or a new policy can be created. For example, if needed, we can change the authentication type from Kerberos to PKI, or we could change the Connection Type from All to LAN or Remote Access only.

Server (Request Security)

The Server (Request Security) option offers more security than the Client option. In this configuration, the system will initially request IPSec secured traffic but will compromise and allow unsecured communications if the other system does not support IPSec. In this way, the entire communication can be unprotected if systems are not IPSec-enabled. To see how this policy is made, we need to take a closer look at the rules used to create the policy. There are three.

Rule 1:

IP Filter List: All IP Traffic
Filter Action: Request Security (Optional)
Authentication: Kerberos
Tunnel Setting: None
Connection Type: All

Rule 2:

IP Filter List: All ICMP Traffic
Filter Action: Permit
Authentication: N/A
Tunnel Setting: None
Connection Type: All

Rule 3 (same default rule as the Client option):

IP Filter List: <Dynamic>
Filter Action: Default Response
Authentication: Kerberos
Tunnel Setting: None
Connection Type: All

Page 5: Secure Server (Require Security)

Continued from Page 4

Secure Server (Require Security)

When enabled, the Secure Server (Require Security) option offers the greatest level of security. The Secure Server policy secures all network traffic to or from the computer on which the IPSec policy is applied. This policy will reject all packets from non-aware IPSec clients. This policy has a rule to require security for all IP traffic, but notice that the rule allows ICMP traffic, and the default response rule is similar to the other predefined policies.

Rule 1:

IP Filter List: All IP Traffic
Filter Action: Require Security
Authentication: N/A
Tunnel Setting: None
Connection Type: All

Rule 2:

IP Filter List: All ICMP Traffic
Filter Action: Permit
Authentication: Kerberos
Tunnel Setting: None
Connection Type: All

Rule 3 (same default rule as the Client option):

IP Filter List: <Dynamic>
Filter Action: Default Response
Authentication: Kerberos
Tunnel Setting: None
Connection Type: All

Conclusions

By examining the various rules in these predefined Server 2003 policies, we now have a better idea of what is needed to design security policies to meet the needs of an organization. Using rules to create policies allows for flexibility in a security design, making it possible for administrators to assign the right level of security required for IP data transmissions.

» See All Articles by Columnist Mike Harwood