This article can also be found in the Premium Editorial Download "Storage magazine: Comparing the top data backup packages."
Download it now to read this article plus other related content.
Device:switch communication are conversations flowing from management applications such as Veritas' SANPoint Control to the management server at the well-known address FFFFFA in your fabric switches. Additional conversations are the administrative talk that hopefully occurs on a segregated LAN designed for access only by IP tools, (e.g., Telnet) management applications (e.g., HP's OpenView) or at the very least, behind a secured socket connection.
Also included in this group is the exchange of information that occurs when connecting an FC device to an FC switch port. That conversation entails exchanging the world wide name (WWN)--along with other identifying information--between the connecting device and switch port for verification purposes.
If you haven't changed the default admin password, please do so now. I've been on professional service engagements with companies who have had their SAN gear in production for months and the administrators have yet to change the default password.
As quickly as you can, include your SAN networking devices with the list of systems that need their passwords changed on a regular basis and after employment changes.
In addition, if you're managing ten or more switches, you'll want a SAN security product that provides some kind of centralized password management feature. This will ease the burden of having to change the passwords locally on each piece of SAN hardware. However, this feature should also provide protection for itself should the primary application providing passwords fail, similar to the way Sun's Network Information System employs a master and slave configuration.
With regards to the WWN, the verification process merely checks the format of the WWN to determine its correctness. By default, any correctly formatted WWN would be accepted. This is most certainly not adequate--a person at a system containing any supported host bus adapter (HBA) can login into the fabric and possibly launch denial of service attacks on your fabric resources.
SAN security products should have the ability to limit which management applications or hosts can discover the fabric or otherwise gain access to the management interface of any one switch. In this way, multiple instances of a management application won't be able to query or update management data via the management service (FFFFFA) without your knowledge.
The Telnet tool is probably the most widely used access method into the SAN management interface. Although reliable, its communication isn't secure because the username/password authentication isn't private. Those values go across an unsecured LAN in clear text for all to see. If you have a SAN security product that encrypts this login authentication and limits access to the management service, this will certainly hinder any attempts by a hacker to eavesdrop on administrative data.
Switch:switch conversations happen over E_Ports (ISLs) and include application data and switch management frames (Class_F traffic) used to query, respond to or trap distributed fabric-related data to the FC services at each well-known address. By default, any compatible switch can obtain an E_Port on another switch by simply connecting the appropriate cable. Then any devices connected to that joined switch can potentially access resources on the other side of the newly formed ISL. You ordinarily wouldn't want to allow this to happen without your knowledge. Much of protecting switch:switch traffic is accomplished by not allowing unused ports to initialize as E_Ports. Most--if not all--switch vendors provide commands to control the auto configuration of ports on their switches.
In addition to not allowing unused ports to be initialized as E_Ports, security products should provide access controls that limit E_Port access to a predetermined list of switches. When this functionality is implemented remotely from the SAN interconnect device, security in the switch:switch realm is enhanced further because you have another layer of security if an individual switch's administrative interface has been compromised. In this scenario, even if the attacker obtained access to the command line interface of the switch, they still couldn't force the joining of another switch into the fabric unless they also had access to the remote data containing the list of approved switches.
This was first published in March 2003