SAN security

With DataCore (and other products as well) it's quite easy nowadays to deploy a geographically distributed storage system to raise availability beyond the scope of a singe datacenter. As it is so easy to implement most companies forget to think about the impact on security such a scenario will bring. When we look at the way datacenters are connected then we talk about fibre glass cables that are used to connect the switching infrastructure most of the time. This connection is considered to be safe by itself but is it really?

The answer is yes but only if you talk about using fibre connections that are owned and managed by yourself and if you can be really sure that no unauthorized person will ever get physical access to these wires.

But what if you use "public" lines, owned and managed by providers? This is a typical scenario as you normally do not have own lines between your sites. So you rent lines from providers, lines that are using public infrastructure, are layed over public area. Can you be sure that noone will ever get physical access to these wires? Probably not. In America, some lines that carry government traffic are physically secured against intrusion but this is very expensive to setup and manage so "normal" lines will probably not be secured in that way.

Is this really a problem? Fibre is considered to be safe. Well, it isn't at all. It's quite easy to grap traffic from public fibre lines once you have physical access to the cable. Optical fibre sniffers cost less than 1000$ and can be used to grap traffic from the lines without ever being discovered by the providers.

Once again, is this a problem? Let's have a look at how DataCore works. Imagine you have two sites with a DataCore node in each site. The two sites are connected by several fibre cables used as inter switch links (ISL) between your SAN infrastructure. Even if you configure your servers to access only the local DataCore host, with every write the data has to be sent over the ISLs to the second node for synchronous mirroring. Things are even worse if you let remote servers access the local node for reads as well.
So every block that has been written (or read) can be potentially grabbed by the attacker and stored for further analysis. As the attacker only gets parts of the traffic it will take a lot of time and storage until he really gets a considerable amount of useful information but what if you have to resync a whole vdisk after a failure for example? In this case, all data from that vDisk will be transferred over the ISLs in a perfect way to be grabbed by the attacker.

Sure, this scenario is not really probable and even if the attacker grabs a huge amount of data, the abstraction layer DataCore adds to the data blocks will keep the attacker away from using the data for a long time but it is possible. So if you think about implementing a geographically distributed storage system keep the ISL security (no matter if you send FC or iSCSI or even NFS traffic over the wire) in mind.

One more thing to note: this ISL "problem" is not exclusively in DataCore environments. Every product that can be installed in a similar way is affected.

But what can you do to secure ISLs? There are different ways to do so. You could use encryption appliances that are installed in the data path and will encrypt/decrypt data on the fly. These appliances are available for Ethernet and FC traffic. They are quite expensive and especially if you have high-speed SAN connections based on 8 or 16GBit these appliances have to be really powerful as you already have increased latency caused by the ISLs itself. If you now add additional latency through the encrpytion engines your SAN performance will probably suffer. This can be a big problem for latency-sensitive applications like databases.

Especially in the FC environment there is a good alternative for these appliances. Brocades Gen5 SAN switches (6500 series based on 16GBit FC) include ISL encrpytion technology at no additional cost. Simply enable encryption on the e-ports and let the switch do the rest. This is ridiculous easy to implement and will add a good piece of security to your data.

But ISL security is not the only thing you should keep in mind when it comes to your SAN. Most attackers will avoid the cost of attacking the ISLs when there are easier ways to get the data. That's the reason why you should also implement standard security features like authentication, FC port security and monitoring of your infrastructure. Only to separate SAN traffic from the "normal" traffic is not enough when it comes to security.

If you don't know what you now have to do to add more security to your SAN, here is a very good ebook about SAN Security published by Brocade. A must-have for alle Brocade SAN adminstrators that care about security.

HTH.   

Leave your comments

Post comment as a guest

0
Your comments are subjected to administrator's moderation.
  • No comments found
Powered by Komento
joomla templatesfree joomla templatestemplate joomla
2017  v-strange.de   globbers joomla template