Discussing all things virtualization and storage in the data center.

SAN Storage in a DMZ, Part 2.

Remember my post on SAN storage in a DMZ? If not, check this link.

Well, i haven't been wasting my time.
I've done some research on this topic, but that didn't turn up much information. Maybe my research wasn't extensive enough Wink.
I've had some thoughts on the subject though. Like i said in my previous post, you have to be pretty good to modify the device drivers of a host after breaking in. You'd have to be even better when trying to modify any SAN component or setting without having access to the management interfaces of the SAN components.

Last week I went to the  Storage Expo and i arranged a conversation with Randy Kerns, for those who don't know mr. Kerns.
I presented him with my dilemma. My question is clearified by the image in the post.


Sample to story

So, here's the scenario:

Some malicious dude or dudette has made it through all the defensive arrangements and has gained access to host A. He is able to see all the data available to host A, which is stored on disk A. Only access rights and authorisations on the data could slow things down. Disk B is assigned to host B by means of LUN-to-HBA mapping. The most common way of assigning storage. Assuming that no modifications are made to host A by the intruder, he will not be able to access storage (or data) not intended to be seen by host A. We were all clear on this, mr Kerns and me.

But this person is even more dangerous. He or she is able to modify the device drivers on the system. 

What needs to be done to gain access to storage he or she should not be able to access? Given the LUN mapping protection, he or she should have to perform WWPN spoofing to impersonate host B. This way he or she could gain access to the data on disk B. Some caveats exist though.

  • The intruder has to know the WWPN's in use, in this case by host B.
  • The filesystems used on host B, have to be supported in some way by host A.

So, that's is. Nothing we can do about that. If the intruder is able to spoof the WWPN's of host B, while accessing host A, he or she could compromise sensitive data.  I was hoping that it wasn't this easy. But mr Kerns assured me, by spoofing the WWPN, bad things could happen.
But there is a bit more to it. 

From a storage subsystems point of view, certain controllers and setups depend on affinity from a LUN to a controller. Without a given failover situation caused by path or controller failure, host A could not get access to disk B. Not even when spoofing. But this is not true on all subsystems and all setups. If you use a dual redundant fabric, like in the picture above, all the paths to all controllers are exposed to host A. So the LUN to controller affinity doesn't offer any protection at all.
 
From a fabrics point of view, there are security features available which detect and act on spoofing attempts. Most fabrics in use today are build upon Brocade or McData and Cisco. Brocade has its Secure Fabric OS, which offers port/wwpn binding, as does the McData SANtegrity security add-on. I do not know anything about  the software features from Cisco, but i am confident that they have security features as well. I'll take McData as a sample. From within EFCM (or SANavigator ) you can apply port/wwpn-binding. If the software detects spoofing, you can get to EFCM immediately block the port, thus prevent it from transmitting any frames. Without transmitting frames, it's really hard to gain access to anything.

Summary:
When proper security measures are in place in the SAN (wwpn/port binding) and storage systems ( controller affinity and mapping features ) it is acceptable to expose centralized storage LUN's to a internet connected host. Well, for me it is. Not ignoring the fact that the internet facing host itself should also be protected by the usual techniques.

 Thank you mister Kerns, for the enlightenment Laughing

comments powered by Disqus