Securing IP SANs

IP SANs use commodity hardware and industry-standard protocols to provide a cost-conscious, easy-to-manage alternative to Fibre Channel arrays. But with IP comes the issue of security. We detail five ways to make an IP SAN more secure.

This Content Component encountered an error
This article can also be found in the Premium Editorial Download: Storage magazine: Exploring the most innovative midrange systems:

Dos and Don'ts of IP SANs
The IP SAN has arrived. iSCSI enables shared, centralized storage over commodity hardware and protocols. Instead of struggling to deploy an expensive and confusing Fibre Channel (FC) SAN, more businesses are going with iSCSI-based Ethernet SANs, especially in the price-conscious Windows and Linux markets.

But not everyone is happy about IP-based storage. Most potential users welcome the low price of iSCSI, but question its use for critical applications. "There are three things IP storage users worry about: speed, persistence and security," says Zophar Sante, vice president of marketing development at Sanrad Ltd., an iSCSI vendor in Menlo Park, CA. "Security is everybody's worst fear, and it's the hardest to address."

The cause for concern is understandable. Even non-IT people worry about the security of public networks. Everyone knows the dangers of viruses and Trojan horses, and has heard stories about denial of service attacks that have crippled Internet resources. So it's not surprising many people believe these vulnerabilities are somehow related to the IP protocol.

However, IP storage is no less secure than FC, and may actually be more secure (see Myths of Fibre Channel security). "If you trust your [IP] network with your data, why not trust it for storage?" asks Eric Schott, director of product management at EqualLogic Inc., Nashua, NH. There's a grain of truth here: People trust IP and Ethernet for almost every aspect of connectivity, and have developed strong methods to make those networks secure.

In fact, the largest companies currently trust FC for their critical storage connectivity, even though little attention is paid to securing that network.

Because it's based on IP and Ethernet, iSCSI has the potential to connect every server in every data center to centralized storage for the first time. The downside is that hackers know that a single network outage could affect every connected system. And as iSCSI becomes more ubiquitous, it becomes a bigger target for attacks.

Myths of Fibre Channel security
One of the most widely held storage myths is that Fibre Channel (FC) SANs are fairly secure. The truth is often the opposite: Although there are techniques to make FC environments secure, they're not widely deployed. In fact, the most secure thing about the majority of installed SANs is that they're small in terms of size and connectivity.

There are many security cracks in the FC world. Although zoning and LUN masking are widely used, they weren't implemented for security. These techniques were developed to prevent misbehaving host bus adapters and software drivers from stepping on the storage of other systems.

While most storage systems have more advanced security features, they aren't employed very often. Management interfaces are the most vulnerable. For example, EMC's Symmetrix and Hitachi Data Systems' Lightning can be configured in-band, using special gatekeeper LUNs to relay configuration information from the command line interface to the array. Although both systems have features to limit this type of access, they're not often deployed.

Other types of systems, with out-of-band Ethernet ports for management, are also often poorly secured. It's not unusual for these ports to have routed IP addresses on a regular network, allowing anyone on the LAN to access them. (I've even seen cases where they were routed to the Internet.) The fact that some Windows-based storage arrays have become infected with viruses over the last few years illustrates the poor security practices in place.

How to lock the door
The majority of security breaches are crimes of opportunity--an untrustworthy person discovers an open door, walks in and takes what's available (see The three faces of security). Sometimes what appears to be a crime is really nothing more than an accident. One way to deal with these threats is to simply lock the door. We can't assume that intruders, whether malevolent or misguided, won't be rattling our doorknobs.

There are five specific ways to lock the door to an iSCSI SAN. Each one can help to secure your IP SAN, but also has its limitations. Used in concert, however, these methods can vastly increase the security of your storage.

  1. Use access control lists (ACLs). ACLs allow an administrator to limit who can see what in an IP SAN. Most systems support ACLs based on IP address, which is a good start but simple to defeat. Another method is to use the initiator name of an iSCSI client. Like an FC world wide name (WWN) or Ethernet media access control (MAC) address, an initiator name should be a unique identifier for each iSCSI host bus adapter (HBA) or software initiator. However, like a WWN or MAC address, initiator names are simple to override, especially with software-based iSCSI drivers. ACLs, like FC LUN masking, should be seen primarily as a means of dividing storage resources among clients, not as a strong security method.
  2. Use a strong authentication scheme. Authentication protocols like Challenge Handshake Authentication Protocol (CHAP) securely identify clients with user names and passwords. Passwords are never sent over the network in plain text, and the protocol is widely trusted by network administrators. But the passwords must be stored at each end of the connection, sometimes even in a plain text file. Remote Authentication Dial-In User Service (RADIUS) moves password authentication off the iSCSI target to a central authority, but can be tricky to set up and clients can still be breached.
  3. Secure management interfaces. One important lesson from the world of FC security is to focus on securing the management interfaces for storage devices. No matter how secure the SAN is, a user of the management application can reassign storage to change, snoop or destroy data. Keep management interfaces on secure LANs and use strong passwords for management accounts. Make sure your vendors don't leave backdoor accounts with well-known passwords. Role-based security and activity accounting can be helpful forensic tools; if your storage system supports these techniques, use them.
  4. Encrypt exposed network traffic. IP security (IPsec) is a standard protocol for encrypting and authenticating IP packets. IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPsec-compliant device decrypts each packet. For IPsec to work, the sending and receiving devices must share a public key. Vendors and consultants recommend using IPsec to encrypt all iSCSI traffic that leaves a secure network. It can be a strong security measure, but can also greatly impact network performance. For this reason, software implementations of IPsec should be avoided unless absolutely necessary.
  5. Encrypt data at rest. Strong encryption of data on disk is widely available and proven. The question is whether this task occurs on the client (an encrypting file system), in the network (an encryption appliance) or on the storage system. A strong case can be made for the first option--most enterprise operating systems (including Windows and Linux) have excellent file system-based encryption technologies, and encrypting data before it reaches the network ensures that it's encrypted all the way through the wire. If the CPU overhead of such a scheme is a concern, moving the task of encryption to a network- or array-based device is a possibility, although some data protection is lost. One word of caution: Encryption can also lock you out of your own data if you lose the key.

The three faces of security
There are three primary concerns for data security: confidentiality, integrity and availability. Each has its own challenges, and each can be addressed with different solutions.
Confidentiality is focused on restricting the visibility of data. To ensure confidentiality, you should limit access through passwords and encryption.
Integrity ensures that data can't be modified without authorization. Access control is critical, but accounting is also important. Logging writes to a secure log server can help to identify the cause of scrambled data, and checksums can be employed to detect changes. But beware: A weakness was recently demonstrated in the popular MD5 checksum algorithm.
Availability is the most visible aspect of security, as well as the most common failure. Availability is protected differently than confidentiality and integrity. Standard practices for high availability include redundancy, protection of configuration and management interfaces, and the simple act of deploying highly reliable equipment.
Designing for security
The No. 1 consideration when designing an IP SAN is to treat it like an FC SAN. One of the things that makes FC so strong is that FC networks are small, tightly controlled and separated from other applications. The same precepts should be followed when designing the IP SAN: Only use iSCSI over private, tightly controlled LANs.

"The best IP SAN is an independent LAN using dedicated Ethernet switches," says Sanrad's Sante. So-called "air-gap" LANs are entirely disconnected from other Ethernet networks, and don't share the same hardware. At the very least, segmented VLANs and IP subnets should be employed to keep other traffic types away from your storage. And don't forget to secure the management interfaces on non-routed networks. Ideally, you should create a separate subnet for network management and allow only authorized users to access it through a VPN and firewall.

Without a tightly controlled, segmented network, iSCSI traffic and usage is likely to "leak" out of the data center. It's dangerous to allow PCs to access iSCSI devices from other parts of the network. One of the first things I did when testing an iSCSI array was to mount a LUN on my laptop over wireless Ethernet. Although functional, this type of connectivity is a security nightmare. Therefore, limit the reach of the IP SAN to the data center.

Follow these policies
If you're considering deploying iSCSI, you should follow these policies:

  • Build a SAN, not a LAN. Treat iSCSI just as you would treat FC. Build a dedicated network for storage, and don't share switches or network cards between storage and other network traffic.
  • Divide and conquer. Use ACLs and other LUN masking techniques to limit access to iSCSI LUNs to only valid clients.
  • Lock the door. Use a separate, strong CHAP password for each iSCSI client and consider changing the passwords periodically.
  • Restrict management. Use role-based security and accounting in management applications; limit even your own access to avoid accidents; and build a separate firewalled subnet for management interfaces.
  • Encrypt data. Consider using client-based encryption to protect data across the network and on the disk, but be careful with your encryption keys.

Policy vs. practicality
Security policies shouldn't be so difficult to administer that they're ignored. Put another way, security measures must not be so extreme as to encourage non-compliance.

For example, the management of IP Security (IPsec) keys is one area where practicality might outweigh security. Unless an automated key management system is in place, the headache of tracking keys could cause the system to be bypassed altogether. Similarly, enforcing both strong passwords and requiring frequent password changes often leads people to adopt a system of sequential passwords or, even worse, of leaving unsecured passwords on slips of paper or in computer files. Adopting a policy of strong passwords or one of frequent changes is often preferable to trying to enforce both.

These policies aren't difficult to adopt, but care should be taken to ensure that they're easy to administer. If it becomes burdensome to apply security policies, they may be circumnavigated or ignored (see Policy vs. Practicality, this page). Adding storage devices that aren't networked with FC to the SAN yields dividends, including improved disk utilization and enhanced stability with more systems using enterprise-class hardware. There's also more flexibility to provision storage devices where they're most needed and to deploy advanced features like array-based replication, mirroring and clustering. The key is facing the fact that security is a critical factor in all storage architectures, whether they are based on FC or IP and Ethernet.
This was first published in March 2005
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSolidStateStorage

SearchVirtualStorage

SearchCloudStorage

SearchDisasterRecovery

SearchDataBackup

Close