What you will learn about security your iSCSI SAN: Learn how segregating an iSCSI SAN, securing the management interface, employing authentication and disabling unnecessary network services can protect your data from malicious attacks.
The Internet SCSI (iSCSI) protocol allows storage networks to be created using Ethernet connectivity rather than Fibre Channel (FC). iSCSI promises good storage performance through low-cost, readily available Ethernet components, but iSCSI technology has also raised serious security concerns. The ubiquitous availability of interoperable Ethernet devices allows iSCSI data to be compromised easily.
For example, an improper iSCSI configuration might let an un...
To continue reading for free, register below or login
To read more you must become a member of SearchStorage.com
authorized user mount an iSCSI LUN volume on their laptop across a simple wireless Ethernet link. "This is an example of the kind of stupid things you can do with a general purpose network like Ethernet/IP," says Stephen Foskett, director of strategy services at GlassHouse Technologies Inc. If you plan to deploy iSCSI technology, it's important to utilize the security features already available in iSCSI products.
Overcoming the isolation of FC
Contrary to popular belief, FC SANs are not more secure than iSCSI SANs. Instead, FC installations have indirectly benefited from their complexity and relative isolation within the data center -- it's virtually impossible to accidentally connect a laptop to a FC SAN. "In general, people have terribly insecure FC SANs," Foskett says. "But there's very little risk, because people just don't have the hardware, software or expertise to do anything about it."
By comparison, iSCSI supports a fairly comprehensive set of security features, including access control lists (ACLs), the IP security protocol (IPSec), the challenge handshake authentication protocol (CHAP) and the use of virtual private networks (VPNs). The problem, analysts say, is that iSCSI is frequently implemented improperly in the data center, and security features are used inconsistently, if at all. Consequently, leaving an iSCSI SAN unsecured across an Ethernet LAN or WAN can be an open invitation to hackers and other malicious users. Whenever an iSCSI SAN reaches beyond the data center, storage administrators must take the steps neecessary to secure access to it.
Security guidelines
The trick with iSCSI security is not to find the right tools for the job, but rather to employ best practices and make constructive use of the tools that are already available:
Segregate the iSCSI SAN. The first mistake that many users make is connecting their iSCSI devices the same way as other Ethernet devices -- often routing an iSCSI SAN through the existing Ethernet LAN just as they would integrate NAS devices. This not only exposes iSCSI storage to the open LAN, but can also compromise management control which is usually handled in-band over Ethernet. Analysts suggest establishing an iSCSI SAN island that is physically isolated from the everyday network, noting that there's no reason to connect an iSCSI array to anything other than appropriate storage servers in the data center. "Data center managers will often segregate their external, internal, management and (sometimes) their data networks," says Brian Garrett, analyst at the Enterprise Strategy Group. "So a best practice in iSCSI is to secure and isolate the iSCSI network from other traffic." Traffic can easily be segregated using existing network technology like VLANs.
Secure the management interfaces. Storage management consoles control the way that data is allocated and accessed. If a management interface is left unsecured, hackers or disgruntled employees can easily alter access rules that can potentially expose sensitive data. This frequently happens with Web-based configuration tools that can be accessed from any Web browser. When using this kind of tool, always change the default password and use a VPN to access the management interface from a dedicated console within the data center itself. Some storage administrators may find this tactic inconvenient, but it can be a very effective way to prevent unauthorized management changes, and it can stop escalation if a security breach does occur.
Disable unneeded network services. Network services such as DHCP, DNS and WIN servers automate many client configuration tasks. For example, DHCP automatically assigns an IP address when a computer connects to the network. On an iSCSI SAN, however, such services are unnecessary, and can actually facilitate malicious activity by helping hackers connect to your network. "Suppose a visiting diagnostic technician accidentally plugs into your [iSCSI] SAN," Foskett says. "They won't get an IP address." While it's still possible to assign an IP address manually, the process demands more knowledge of Ethernet and the configuration of your particular network.
Employ CHAP and other authentication wherever possible. Analysts agree that iSCSI SAN deployments should employ the strongest authentication method available. ACLs are helpful, but their protection is weak -- lists can be fooled and IP addresses can be spoofed. CHAP is the preferred authentication method for iSCSI SAN use, and is often employed in addition to ACLs. CHAP is already used by VPNs and Windows login, and is supported by most iSCSI devices. "Use the best authentication you can because (in the absence of encryption) authentication is really all you have to protect your [iSCSI] array," Foskett says.
Employ IPSec or other encryption when necessary. IPSec is a solid general-purpose encryption and authentication protocol. Unfortunately, IPSec is a very performance-intensive process that slashes network performance by as much as 50%. Analysts note that IPSec use within a segregated iSCSI SAN is unnecessary -- and certainly not encouraged. However, IPSec encryption may be absolutely essential when using iSCSI over any kind of open network (such as for replication or WAN tasks). Storage and network administrators must decide if the need for encryption justifies the performance impact.
Key management is another concern with any type of encryption. Lost keys can leave vital data inaccessible, causing an irreparable loss of data to the company. "If you need to rebuild a server in a crisis, you may not have the proper key," Foskett says. "So, encryption can sometimes be more trouble than it's worth."
Do you know…
the difference between ISCSI vs. FC performance?
How to backup your system with iSCSI?
