Vinod Subramaniam

Can Application to LUN Zoning defeat ransomware?

Blog Post created by Vinod Subramaniam Employee on Apr 16, 2018

Traditionally Fiber channel networks have been considered more secure than Ethernet networks. This is owing to the fact that it is hard to snoop traffic on a fiber channel network since one needs a tap to analyze traffic on a fiber channel network.


Basic security in fiber channel networks starts with zoning. Essentially every server that has access to data on an enterprise storage array is populated with two or more fiber channel HBAs. These HBA’s send and receive data from the arrays and are called initiators in the industry parlance. Each array appears as a target for the initiators and virtual disk drives called luns are made available via these targets to the initiators.


Zoning is a basic mechanism whereby one manually specifies which initiator can communicate with which target port. Each enterprise array has multiple target ports to which luns are published.


When an initiator and a target are connected to a fiber channel fabric switch they perform a fabric login called a FLOGI. On successful login, they register their addresses called WWNs with the Name Server running on the fiber channel switch. Each WWN is unique to an initiator or target and is assigned by the manufacturer much like a mac address is assigned to a network card.


As part of the deployment process, a storage administrator configures what is known as zoning whereby he or she creates typically binary sets of initiator-target pairs that may overlap. Once configured the initiator cannot communicate with targets and associated luns outside the binary set.


Now consider a typical server in the datacenter hosting up to 100 virtual disk drives called luns.

50 of these luns may be dedicated to an oracle database server and the remaining 50 may be exported via NFS to clients.  Consider a scenario where a trojan ransomware infiltrates the NFS share and thus gains access to the other 50 luns where Oracle data is stored. It could potentially take over the Oracle database files and lock out the process by encrypting the files.


Now consider a traditional scenario where the zoning mechanism plays out as below.


  1. Initiators and Targets login to the Fiber channel name server via a Fabric Login or FLOGI
  2. Zoning is configured allowing specific initiators to talk to specific targets
  3. On zoning, a state change notification is triggered whereby an initiator that is in the same zone as the target logs in into the target via a PLOGI
  4. Next, a Process Login or PRLI is initiated whereby communication via the FC4 layer typically SCSI can occur between the initiator-target pair


Now, what if an application layer login to the nameserver were introduced after the PLOGI and prior to the PRLI. Each application could be assigned a GUID and an administrator could specify which application can talk to which luns published on the target.


One could take this further with the nameserver on the switch acting as a key exchange server and forcing the application and the target to authenticate using a symmetric or asymmetric key exchange.


The only weak link here is the case where a rogue process manages to spoof GUIDs of authentic processes. This can be potentially worked around by making the GUID partly dependent on a binary hash of the process executable.