Which is More Secure: IP or Fibre Channel?


Arguments in the current holy war between advocates of Fibre Channel fabrics and champions of burgeoning IP protocol-based solutions such as iSCSI frequently include a debate over security. FC SAN companies routinely argue that, because of the relative mystery surrounding the Fibre Channel Protocol and the "closed" nature of Fibre Channel "networks" (that is, that they are not connected to LANs), FC SAN topology is inherently more secure than IP storage solutions.

This argument has some merit. The reason that servers on IP networks are so frequently targeted by hackers and virus programs is that they are " open " systems. LANs tend to be interconnected with other networks in order to enable the greatest possible reach and access for applications the broadest possible accessibility to applications and end-users.

Moreover, IP networking protocols are standardized, and information about them are readily available and widely disseminated. This, in turn , facilitates the development of a body of techniques for breaking into IP networking gear.

Some experts estimate that less than 10 minutes will elapse before the first hacker or hacking program visits a server newly deployed to the Internet. The know-how and the tools are available to anyone who wants them ”from systems and network administrators to hackers and script kiddies.

Intuitively, all of the above lend credence to the argument of the FC camp that their "SANs" are more secure than IP LANs. However, objectively, what the FC camp fails to note is that their preferred SAN variant typically lacks the necessary services to support security whether as a function of vendor implementations of the FC protocol on their products, or because of outright deficits in the FC protocol itself.

It is typical for those deploying FC fabrics to also deploy an IP network, making a second connection to every device in the fabric, in order to provide out-of- band management and security functions. The management of devices such as storage arrays and FC switches is accomplished across this IP network using either proprietary management frameworks or Simple Network Management Protocol (SNMP) and SNMP Management Information Bases (MIBs).

SNMP, which is another Internet Engineering Task Force [7] standard, has come under attack recently as a source of vulnerability to hackers. In February 2002, an advisory issued by the Computer Emergency Response Team (CERT )/Coordination Center at Carnegie-Mellon University reported that certain SNMP message handling implementations contained vulnerabilities that could allow unauthorized privileged access, denial-of-service conditions, or unstable behavior. [8] So important is the issue, CERT/CC currently maintains on their website a list of network product vendors annotated to reflect the vulnerability of their products to SNMP problems!

Of course, SNMP vulnerability is only an issue for a FC fabric if the IP network used to manage the FC fabric is "open" ”that is, interconnected with other networks or accessible through clients other than the SNMP management console. If it is closed and physical access to the management console is protected, then the potential exposure is effectively mitigated. The same may be said of SNMP used in an IP storage network.

It should be added that many FC switches provide accessibility to their configuration management interfaces via the TELNET protocol, another IP protocol. As of this writing, only a few vendors have provided on-board security on their FC products that is capable of preventing casual users or deliberate hackers from using TELNET to access configuration controls and change setup parameters. Were this to happen, the disruption of the storage infrastructure could be severe. This again is an exposure that is seldom discussed in the FC versus IP debate.

IP- related vulnerabilities aside, FC SAN advocates typically refer to "zoning" as a guarantor of security. The basic premise of zoning is to control who can access what in a SAN.

Zoning is part of a multi-layer scheme of access management in the view of FC advocates that includes server, storage, switch, and software layers . At the top of this stack is the server, which provides a doorway to the SAN infrastructure.

On any server, there are mechanisms to control what devices an application can see and whether or not the application can talk to another device. At the lowest level, an HBA's firmware and/or driver provide a "masking capability" that determines what devices the server can see. In addition, most server operating systems can be configured to control which devices are mounted as storage volumes . Storage volume management, virtualization, and even file systems provide an extra layer of access control.

If the server is connected to a FC fabric, an additional layer of access control is arguably provided by zoning ”another form of selective presentation of storage assets. The zoning process in a FC SAN switch uses the list of available LUNs on SAN-attached arrays and cross references this information to switch ports. This cross-referencing scheme establishes connections between server nodes and storage nodes that are used to control and shape traffic across the fabric. Simply put, security is provided through zoning by simply ignoring or rejecting access requests from server nodes that do not have permission to access nodes on a given storage node list.

Most, if not all, Fibre Channel switches support some form of zoning to control which devices on which ports can access other devices via other ports. Virtualization may enhance this access control, according to FC SAN advocates.

How exactly does zoning work? In very simple terms, when a node device is attached to the SAN and powered up, it performs a fabric logon and obtains its source address or destination address (SID or DID) from the switch. The device already has its own unique World Wide Name (WWN) as a function of a hardware-based identifier.

When each device logs on to the name server service in the SAN switch and registers itself, the switch builds up a database of all the devices in the fabric ”a process that uses a mapping of the node and port WWNs to a 24-bit address. The login process completes when the server node asks the name server process to send back a list of what other FCP devices it can see in the fabric. This is where zoning policies are applied. The name server only returns a list of those FCP devices that are in the same zone (or a common zone) as the requesting node. In other words, the server only "learns" about the availability of those nodes that it actually is permitted to use.

The server, thus armed with a list of the addresses of all the devices it is supposed to be able to see, then typically performs a port logon to each device in order to discover what kind of FCP/SCSI device it is ”a process that is quite similar to conventional SCSI bus queries. When the process is complete, presumably a secure zone has been established that controls device access in the SAN.

An important distinction to understand, however, is the difference between "hard" and "soft" zoning. Soft zoning refers to the security afforded by "not being told what you don't need to know." One often hears a metaphor for soft zoning used at conferences and elsewhere. Soft zoning is described as the equivalent of having an unlisted phone number. While your telephone number is not published, someone could still dial your number at random or by mistake, and your phone would still ring. The difficulty with this type of zoning from a security standpoint is that it leaves storage assets exposed to random access by unauthorized devices. Any device connecting to a soft zoned FC fabric could use an "unzoned name server query" to discover devices to which access has not been formally provided.

By contrast, hard zoning prevents unauthorized access. Metaphorically, it is like having a call block set up on your phone so that even if someone guesses your phone number, your phone does not ring. Hard zoning is a more secure approach. However, while many switch vendors claim to support it, the actual level of support provided varies greatly from vendor to vendor. Some switches implement hard zoning through a proprietary scheme of naming (i.e., via a specific port-ID syntax) that only works with switches of the same type or from the same manufacturer. Confusion arises when the term "hard zoning" is used interchangeably for SAN zone naming schemes based on node and port IDs ”which is not the same thing.

Understanding hard zoning is important to understanding evolving FC SAN technology, like Cisco Systems' Virtual SAN (VSAN). VSAN addresses a key security and resiliency issue in FC fabrics with a new approach supported currently only on Cisco/Andiamo switches. The issue has to do with the recommended design strategy of running two, separate fabrics with each node connected to both fabrics. This design presumably affords fault tolerance by insulating devices from a discrete link failure or port failure affecting one of the fabrics.

However, even such dual fabric designs are subject to a single point of failure: the name server service in a switch. There is a small possibility that a misbehaved device could disrupt the name service to the extent that all devices on the fabric, not just those in the same zone, would be impacted. This would obviate the resiliency value of the dual wiring topology.

VSAN is proposed as a higher-level construct than the name server with a totally separate name server database, rather than one common to all zones. It may even run as a totally separate service within the switch, so the possibility of cross contamination is lower and problems are more localized. Affording some enhanced security, VSANs show promise. Of course, if a device is connected to two separate VSANs and misbehaves, then it can potentially bring down both VSANs.

As of this writing, VSAN has not been standardized. Cisco and Andiamo are actively seeking backers both at ANSI and at IETF. When and if VSAN is adopted, significant changes will need to be made to the manner in which node discovery is performed (unzoned name query, for example) across an FC SAN organized into VSANs. Implications for security remain to be fully explored, but advocates claim that they may provide more secure fabrics in much the same manner that VLANs augmented the security of messaging networks.

Not to be upstaged by Fibre Channel competitors , IP storage advocates make the inverse claim that iSCSI-based SANs are more secure than their FC counterparts because they can leverage existing standards-based, in-band security protocols, like IPsec. For the obvious reason that IPsec is complex and difficult to administer, which has limited its adoption and deployment in the real world, this claim is difficult to justify.

Efforts to develop IP SAN-specific security standards (or storage security standards generally ) are in their infancy. If Cisco Systems' Virtual SAN (VSAN) effort is any indication, quasi-security-related technologies like Virtual Private Network (VPN) will find their way into storage networks shortly.

In the world of LANs, a VPN establishes a secure or "private" network within a public network by encrypting traffic between two communicating end points. Some VPNs also use "tunneling" technology for greater security. Tunneling, as the name implies, establishes a special low-level connection between the communicating devices and a reserves and exclusive path between the devices for use during the entire period of the communications session. The Internet Engineering Task Force (IETF) recommends a combination of tunneling and encryption as part of its IP Security (IPsec) standard, though considerable debate exists around the need for tunneling in non-IP networks such as ATM that already provide secure virtual circuits.

A tunneling protocol for moving Fibre Channel “transported storage I/O across an IP link (FCIP) has already been developed by the IETF. Co-developed by Cisco Systems and Brocade Communications Systems, the protocol was intended to facilitate the interconnection of isolated Fibre Channel fabrics (so-called "island SANs") across existing, lower-cost, IP backbone networks within companies or IP Wide Area Networks connecting geographically remote locations. The one potential drawback of FCIP is that it creates from all of the island SANs a single fabric, so incompatibilities in switch gear, node naming schemes, and zoning schemes must be considered carefully before joining two or more FC SAN islands together via this method.

Fibre Channel has also been mapped to IP directly with the Fibre Channel over Internet (iFCP) protocol. Unlike FCIP, iFCP operates Fibre Channel Protocol as an application across an IP network. This provides the ability to use IP to connect various FC fabrics, but also enables each connected fabric to retain its own unique naming and zoning conventions because the unique identity of each island fabric is preserved.

When FCIP or iFCP are deployed, the security issues that the FC community argue are the bane of IP come back to haunt them. At present, the truth about the security of any of the current manifestations of networked storage is best summarized in an observation once made by a former National Security Agency manager: "The only way to keep information secure in a network is not to put it there."



The Holy Grail of Network Storage Management
The Holy Grail of Network Storage Management
ISBN: 0130284165
EAN: 2147483647
Year: 2003
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net