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