ra2 studio - Fotolia

Get started Bring yourself up to speed with our introductory content.

An introduction to iSCSI security for the cloud

Expert Dejan Lukan looks at iSCSI security, the possible attacks on networks using iSCSI and CHAP security.

The iSCSI (Internet Small Computer System Interface) is a network protocol used to provide centrally managed storage to enterprises. The most commonly used storage architectures include direct-attached storage (DAS), network-attached storage (NAS) and storage-area networks (SAN).

DAS provides storage to each physical machine separately, meaning the storage cannot be shared between multiple machines in the environment. NAS and SAN, however, allow the storage to be centrally managed and used by multiple machines in the environment. NAS is useful in virtualized environments where each virtual machine (VM)'s hard drive could reside in NAS itself. Today it is common for network environments to consist of physical machines running hypervisors like ESX, Xen or virtual PC providing CPU, RAM and graphics resources, while the NAS/SAN systems provide storage resources to VMs, either deployed in the cloud or hosted locally.

An attacker leasing a VM in a public cloud could compromise iSCSI and get access to the data of other customers. If the network in a public cloud is not properly segmented, an attacker might access the iSCSI directly through a VM. Therefore, properly secured iSCSI is a must for every cloud service provider that doesn't want to risk compromise.

iSCSI communication

iSCSI provides block-level access to the storage over the network, where there are two endpoints: the iSCSI initiator and iSCSI target. The iSCSI initiator is a client endpoint that opens the connection to the target through iSCSI commands. The iSCSI target is a server endpoint -- typically on port 3206 -- waiting for commands coming over an established iSCSI session through which data blocks are exchanged. When the iSCSI initiator connects to the iSCSI target, it will request a list of available logical units.

iSCSI communication must be done over a gigabit switch for maximum performance and transfer speeds, otherwise the data transmission is too slow to use in a real environment.

COMPANION ARTICLE

See Infosec Institute's accompanying article on iSCSI Security Considerations in the Cloud.

 

iSCSI naming conventions

iSCSI uses a naming convention to differentiate between endpoints, similar to how IP addresses differentiate between computers on the TCP/IP network. The naming convention is called iSCSI Qualified Name (IQN) and is divided between four fields. The first field is the literal 'iqn' string, followed by the date in yyyy-mm format as the second field. The third field is a reverse domain name, while the last field is an optional storage target name. An example of IQN name is the following: "iqn.1992-01.com.example:storage.tape1.sys1.xyz", which is broken down into four fields as follows:

Field 1: 'iqn'

Field 2: '1992-01'

Field 3: 'com.example'

Field 4: 'storage.tape1.sys1.xyz'

iSCSI security

There are several different attacks possible on the iSCSI architecture, including:

The data exchanged between the iSCSI endpoints is unencrypted, so an attacker is able to reconstruct the data off the wire.

Authentication: Each iSCSI initiator must first authenticate the target before it's allowed to use the logical units. The authentication used by the iSCSI endpoints is optional. This can result in a large number of devices left unprotected since any iSCSI initiator is allowed to connect to the iSCSI target. Alternatively, CHAP (Challenge-Handshake Authentication Protocol) can be enabled in the authentication process, so both endpoints exchange the hash generated from the CHAP ID, a challenge message and a secret password. If the hash matches on both endpoints, the connection is established; otherwise, it is terminated.

Network segmentation: Only trustworthy iSCSI initiators should be able to connect to the iSCSI targets to establish a session to exchange data, while other machines shouldn't be able to see the iSCSI targets. This can be achieved with proper network segmentation, where hardware switches or VLANs are used to isolate the iSCSI targets and iSCSI initiators from the rest of the network.

Authorization: Each iSCSI initiator must first authenticate to the iSCSI target by using a CHAP protocol if enabled. Once the authentication has succeeded, the IQN name is used to authorize the iSCSI initiator to get access to the target LUN (logical unit number). The iSCSI initiator must not be allowed to get access to arbitrary LUNs or it could access data it's not allowed to see. Since IQN names are used to authorize the iSCSI initiators, an attacker can sniff the IQN from the network and spoof it to gain access to certain LUNs. Because iSCSI traffic is exchanged between the endpoints in clear text, an attacker can easily sniff the IQN names from the network.

Data encryption: The data exchanged between the iSCSI endpoints is unencrypted, so an attacker is able to reconstruct the data off the wire -- prior to that, a man-in-the-middle (MITM) attack needs to be executed to sniff the data from the network. Besides data reconstruction, an attacker can also inject data into iSCSI traffic to create, modify or delete arbitrary files on the iSCSI target. To mitigate the risk, the IPsec should encrypt communications between the iSCSI endpoints.

CHAP security

CHAP protocol is used to authenticate the iSCSI endpoints. For this to work, the iSCSI initiator first connects to the iSCSI target, which responds by sending a CHAP ID and a challenge message. The iSCSI initiator responds again with a hash through an MD5 function calculated with the following formula: MD5(ID + password + challenge). The ID and challenge are exchanged between the iSCSI endpoints upon establishing a session, but the secret password is known only to the iSCSI target and iSCSI initiator, and is never sent over the wire. The iSCSI target finally checks whether the hash matches the expected value, in which case the iSCSI initiator is authenticated, otherwise, the connection is terminated.

The CHAP protocol is vulnerable to different attacks including:

Sniffing traffic: Again, since the iSCSI traffic is sent in clear text, an attacker is able to sniff the packets of the wire through an MITM attack. IPsec can protect against such attacks.

Offline password brute force/dictionary attack: An attacker able to sniff the iSCSI authentication handshake from the network will be able to use offline attacks to crack a password. Since the CHAP ID, the CHAP challenge and the resulting MD5 hash will be known, the attacker can use a brute force or dictionary attack in order to crack the password used in the hash calculation.

Message reflection attack: A reflection attack can be used when both endpoints use the same protocol to authenticate the other side. First, the iSCSI initiator -- controlled by an attacker -- must establish the first connection to the iSCSI target, which responds by sending it a CHAP ID and a challenge. At this point the attacker can't respond with an MD5 hash, since it doesn't know the password. To overcome the issue, the iSCSI initiator (the attacker) opens a second connection to the iSCSI target by sending over the received ID and a challenge. The iSCSI target responds with the correct MD5 hash, which an attacker can then use to authenticate the iSCSI target in the first connection. If the MD5 hash is accepted by the iSCSI target, the attack will be successful.

Conclusion

There are some caveats that need to be thoroughly addressed in order to secure iSCSI communication on a network. It's imperative to properly secure iSCSI targets since they play a major role in networks, both in the cloud and on premises. If an attacker were to access the iSCSI target in a virtualized environment, it would be equivalent to compromising all VMs residing on that iSCSI data storage.

To properly secure the iSCSI traffic from attackers, CHAP must be used to authenticate iSCSI endpoints, the network has to be segmented to limit the access to iSCSI targets, and IPsec must be used for iSCSI traffic encryption.

About the author:
Dejan Lukan has an extensive knowledge of Linux/BSD system maintenance as well as security related concepts including system administration, network administration, security auditing, penetration testing, reverse engineering, malware analysis, fuzzing, debugging and antivirus evasion. He is also fluent in more than a dozen programming languages and constantly writes security-related articles for his own website at www.proteansec.com.

Next Steps

Learn how to follow the iSCSI SAN security guidelines

An essential, practical guide to iSCSI storage

Dig Deeper on Cloud Network Security Trends and Tactics

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSecurity

SearchCloudComputing

SearchAWS

SearchCloudApplications

SearchServerVirtualization

SearchVMware

ComputerWeekly.com

Close