Dave's Bit Bucket

Wednesday February 15, 2006

Dave on SAN Security

I was digging through my email archives, and stumbled on this answer to a question I was asked on SAN security. I think it's worth posting as a distillation of my thoughts on the subject...

NB. "Zones" here are explicitly SAN Zones, not Solaris 10 Zones.

If you use SAN switches which can do hard zoning by ASIC rather than soft zoning by nameserver, and you set your zoning up by WWN for disk arrays and WWPN for hosts, you'll probably be OK.

Zones can be thought of in very much the same manner as VLANs - while VLANs were originally intended to constrain network "chatter" (broadcast / multicast traffic, etc), Zones were intended to constrain RSCNs (SAN reconfiguration notifications). If you have lots of zones with a small number of devices in each, you can mitigate RSCN flood attacks (by which a compromised host could bring SAN traffic in its Zone to a halt).

The question of whether Zones can be breached in the manner of the classic "breach VLANs on old Ciscos / versions of IOS by using macof from the dsniff suite to overload the MAC addr to physical port tables" is pretty moot. Talking to the storage guys over here, they are adamant that, even if a black hat was sufficiently skilled as to write a new kernel driver for the HBA in an attempt to fake WWPNs, the WWPN is assigned right down in the hardware layer and there's nothing which could be done without physical access and, indeed, custom-engineering a new HBA. Think of it as trying to change a host's hostid back before we put it on flash.

Assigning Zones by WWN / WWPN, rather than by physical SAN port, is nicely analogous to applying MAC-level filtering on IP switches. Similarly, LUN masking (which you should also do) feels a bit like IP subnetting.

Some aspects of SANs were clearly thought up by folk who have been through the pain of some of the less pleasant issues IP raises - for instance, there is no SAN concept of Spanning Tree. Instead, ports on a switch are differentiated by type, thus:

G = General
F = Fabric
FL = Fabric Loop
E = Inter-switch

G ports can learn how to behave based on what's plugged into them - FL ports exist so that legacy FC / AL devices can be connected to the SAN. If you can program your switch so that all ports are assigned a non-G type, then you can mitigate the theoretical attack of a compromised host pretending to be a SAN switch (although this attack would require WWN spoofing, see above).

Information about which switches have which zones bound to them, etc, is known (confusingly) as F class traffic, and is only communicated between SAN switches on type E ports. If you hard-assign all switch-to-host or switch-to-array ports to be F type, you can be sure that your F-class traffic is constrained to your inter-switch links.

FC is much more latency-sensitive than IP, so all switches are non-blocking - the fibre or the disk is always the bandwidth bottleneck.

The Achilles heel in most SAN switches is their management interface. Where switches allow management or firmware upload over the FC, turn it off. Also, most switches need to be segregated for IP management in the same manner as the SC on a Sun Fire 6800 (or similar) - usually they don't do SSH, only do SNMPv1 and sometimes can't even be configured to operate SNMP in readonly mode - it's either off or read-write. So be sure to confine the IP interfaces on your SAN switches to a physically separate spur of the management network, have a couple of bastion hosts which can accept SSH logins and which run SNMP proxies, and stick a firewall between this spur and the rest of the management infrastructure.

If you need to make a "stretched" SAN between sites which crosses land outside the control of the datacentre owners, there are several ways to go about securing the SAN traffic against sniffing. As a result of the latency sensitivity above, a stretched SAN will have a box at each end of the inter-site link from someone like Nishan, which will convert between FC and IP. Once you have your data as IP, you can do pretty much what you want with it in terms of encryption - or if, as is usually the case, you only have one or two inter-site fibres over which you need to get SAN and IP network data, the use of DWDM via < a href="http://www.nortelnetworks.com/products/01/optera/long_haul/dwdm/">Opteras or similar will act as a useful obfuscator of what goes over the fibre. Alternatively, if you put a suitable box from Decru, Neoscale or Kasten Chase on the FC side of each of your Nishans, you can get your FC data formally encrypted at SCSI level before conversion to IP and propagation. (2006-02-15 04:05:12.0) Permalink Comments [0]