iSCSI security
iSCSI, as a storage option, has less performance than fibre channel ie. it is limited to the speed of the HBAs or the network card being used, however it is far cheaper and I can leaverage my existing infrastructure to put in an iSCSI SAN. The problem becomes, in a TCP/IP network, how do I protect the data moving between the SAN and the hosts?
To start with, what is iSCSI? Functionally, there is no difference between Fibre Channel, iSCSI and a local SCSI controller. All three send SCSI commands to hard disks. Both Fibre Channel and iSCSI transmit over fiber and TCP/IP networks, respectively; making the network storage appear as “local” storage for the iSCSI client (or initiator).
As I mentioned, iSCSI uses TCP/IP networks to transport the SCSI commands from the initiator to the target (the iSCSI SAN). iSCSI uses the default TCP port 3260 and provides no native security on communication between the initiator and the target.
Here’s where the challenges begin.
To start with, if my iSCSI traffic is shared on a production network there are two problems. The most dangerous is network sniffers for obvious reasons.
The other immediate problem is network contention. If my iSCSI SAN shares the same network as all my production network there is a big problem with performance as my normal traffic will be competing for access with iSCSI.
The solution to both problems is network isolation. This isn’t so much best practice as it is mandatory. Wether the iSCSI network is physically isolated to it’s own infrastructure or using IEEE 802.1Q (VLAN tagging), the iSCSI network should now be invisible and/or inaccessible to the production network. The only notable exception becomes the requirement for servers to access the iSCSI implementation. Easily fixed by the addition of network adapters to the servers. Even if I need to populate each server with additional NICs, this should still be cheaper than the most simple Fibre Channel implementation.
Okay, now we have isolation to provide security but what about securing the communication itself.
The obvious solution is IPSec. The not so obvious problem is the overhead to IPSec. For a storage network, it doesn’t seem optimal to have to encrypt and decrypt each packet as it is transmitted and received. Certainly, as of the writing of this article, there is no support for IPSec in ESX3.5 specifically.
So the only real option left (in ESX particular) is authentication to verify my identity. ESX supports CHAP authentication only for iSCSI initiators and targets.
CHAP (Challenge Handshake Authentication Protocol) is used to verify the identity of clients in a Point-to-point network. Your identity is verifed by using a three way handshake. After the initial link CHAP authentication is done at random intervals during the entire conversation. The one weakness is the reliance on a shared secret ie. the client’s password. ESX does not support per target credentials either. So one CHAP username and password sent to all iSCSI targets.
The CHAP process goes something like the following:
- After the completion of the link establishment phase, the authenticator sends a “challenge” message to the peer.
- The peer responds with a value calculated using a one-way hash function, such as an MD5 checksum hash.
- The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authenticator acknowledges the authentication; otherwise it should terminate the connection.
- At random intervals the authenticator sends a new challenge to the peer and repeats steps 1 through 3.
An example of CHAP authentication can be seen between two Cisco 3640 routers. The network is a fairly simple on and looks like this:
After enabling the serial interfaces between the two routers, I enable and configure PPP encapsulation. On the second router (R2) , I enable CHAP authentication and view debugging information on the first router (R1)
*Mar 1 00:25:39.971: Se1/0 PPP: Using default call direction
*Mar 1 00:25:39.975: Se1/0 PPP: Treating connection as a dedicated line
*Mar 1 00:25:39.975: Se1/0 PPP: Session handle[26000001] Session id[0]
*Mar 1 00:25:39.975: Se1/0 PPP: Authorization required
*Mar 1 00:25:40.255: Se1/0 PPP: No authorization without authentication
*Mar 1 00:25:40.259: Se1/0 CHAP: I CHALLENGE id 1 len 23 from "r2"
*Mar 1 00:25:40.299: Se1/0 CHAP: Unable to authenticate for peer
R2 is waiting for authentication from R1 and is unable to get authentication information. Now I configure CHAP authentication on r1 and observe the following:
*Mar 1 00:26:26.867: Se1/0 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:26:26.867: Se1/0 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:26:26.871: Se1/0 CHAP: O SUCCESS id 12 len 4
*Mar 1 00:26:27.055: Se1/0 CHAP: I SUCCESS id 15 len 4
*Mar 1 00:26:27.059: Se1/0 PPP: Sent CDPCP AUTHOR Request
*Mar 1 00:26:27.063: Se1/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:26:27.071: Se1/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:26:28.055: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up
The shared secret is exchanged between the two and the Serial interface is changed to an up state.
