iSCSI again

When I first learned that the latest and greatest in nework attached storage (NAS) was using a TCP/IP implimentation of SCSI I heard alarm bells going off.

Back up and recovery is a bandwidth intensive operation that can overwhelm some firewalls. So a lot of folks just string fiber between their servers and their storage devices using non-TCP/IP protocols. All well and good. An attacker cannot get to the storage device becasue the protocols do not run over the Internet.

But when you encapsulate those protocols in TCP/IP you could now be exposing your data storage devices to worms, viruses and attacks. Not good.

So this blog posting caught my eye. As I suspected all sorts of issues with running iSCSI.

So I asked my friend Jeff at Lefthand Networks to address this and his response pretty much defines best practices in implementing iSCSI safely. Here is his response:

Hey Richard, I get this sort of question frequently. One of the key things this blog says is that you are supposed to run this on a back channel network. We enforce this during our implementations. We do not support it if it is not on a dedicated network.

Most of our customers purchase a separate switch, or switches, to run the iSCSI SAN. If they have large chassis-based switches, we then use vlans to segregate the traffic. A dedicated NIC on the server connects to the SAN and another NIC is used to service client requests. Our best practices dictate that you should disable all protocols except TCP/IP on the SAN facing NIC.

We have an implementation of LUN Masking which keeps hosts that are not supposed to see a LUN from seeing or accessing it.

-snip- stuff that criticizes competitors -snip-

Lastly, iSCSI supports two-way CHAP where the initiator must have a password to access LUNs and the SAN has a password to authenticate with the client initiator. When CHAP is used with strong passwords, along with proper layer 2 or layer 3 security, and host-based security, iSCSI is as secure or more secure than fibre channel. The implementation that this guy broke on the Netapp is likely due to the netapp doing dual duty on the client facing LAN.

The common rebuttal to all this is that if the host is compromised on the LAN facing network, then the ISCSI network can then be exploited too. If one does not implement some minor host based security majors, this could be a concern.

I am sure we will hear about many iSCSI exploits in the near future. I would bet that most are due to a lack best-practice type implementations.

Thanks Jeff. This reminds me of VOIP, best practice is to deploy it on separate Cat5 cables.

So to sum up. Separate infrastructure and client to server two way authentication are best practice when deploying iSCSI.