Published: 10 Mar 2003
In the early days of storage area network (SAN) deployments, ignorance was our greatest security tool. However, now that system support personnel and would-be hackers have moved up the learning curve, you'll need a more prudent approach.
Unlike direct-attached storage (DAS), SANs allow multiple access points to your data. No longer does a hacker need to bypass the security mechanisms of a host operating system and its layered security applications to gain access to data spinning on disk. Switches, bridges and routers are even closer to the actual data than the host, and therefore impose a new set of practices to prevent and detect intrusion.
Approaching SAN security requires you to examine all of these pathways to ensure both user and administrative data flow within your SAN securely and unencumbered. To date, no storage hardware vendor supplies all of the tools you'll need to completely safeguard your SAN data for free. To do so, you'll need to make full use of your fabric's OS, and add a layered security product on top of your OS for tighter control and increased administrative functionality.
Lock the door
Before you take steps to protect the various weak points, the most basic check you can make is to ensure that access to your SAN gear is limited to authorized personnel only.
Because the Fibre Channel protocol (FCP) enables it, you may be tempted to place interconnect devices (e.g., a departmental switch) further away from the core hardware for management or convenience reasons. There isn't enough that can be said about physically securing such interconnect devices. If a malicious user gained access to this physically isolated switch, its inter-switch links (ISLs) may give them access straight into the data center. Physical security is fundamental, because it's often the last line of defense when countermeasures to software attacks have been circumvented. Therefore, avoid deploying interconnect equipment in unsecured areas.
The second most basic step you can take is to make sure all unused ports on your switches are locked down in a state that doesn't allow the port to initialize to an operational state and requires administrative access to the switch to circumvent this security block. With this measure in place, even if someone did gain physical access to the data center, they won't simply be able to connect their accompanying device to your SAN and perform a fabric login.
After locking the door and barring the windows, now we can develop a SAN security plan to identify the potential weaknesses in your SAN infrastructure. There are four communication paths that can be compromised by an intruder to do their bidding (see "Fighting break-ins on four fronts"):
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.
Device:device interaction occurring between initiators and targets and WWN spoofing is the most likely mechanism to be used by a vandal to gain access to your targets. Zoning and LUN masking will serve as your allies in preventing attacks to individual targets. However, software zoning or LUN masking alone can't provide complete protection. If physical security has been breached, the perpetrator only needs to know the WWN of the interested host to bypass the software zone restrictions you have in place and begin accessing the name server (FFFFFC) and the host's assigned LUNs. Again, we see the importance of physically securing remote switches.
Hardware zoning--the practice of using domain IDs and port numbers to identify zone members--is more secure than software zoning because it requires the intruder to have physical access to the switch port that the interested host is plugged into. In this case, even if the intruder had access to a SAN switch in a remote software development area, they still couldn't access the targets of an accounting server that is physically connected to a more secured switch.
|Fighting break-ins on four fronts|
Apart from physical security, you must guard your SAN from intrusion through four kinds of paths, as shown here.
User:device interaction is limited to those interconnect devices that can be compromised by gaining physical access to a serial port or user interface directly on the device. Unless terminal servers are used, physical access is required for a breach.
Some vendors have chosen to outfit some of their SAN equipment with push-button user interfaces. Although convenient, the consequences of a physical security breach may outweigh the benefits when you consider the number of operations that are available via this interface.
Not only is there a concern that an outside intruder could alter the device's configuration, but we should also consider the inquisitive intern or trainee that has an interest in developing their SAN expertise. These interfaces should always be password protected or otherwise disabled to prevent this.
Accounting and event association with other monitoring and reporting products are essential in establishing SAN security policies. For example, the OS supporting your switching gear should have the ability to report errors and port status changes to a syslogd process on an accessible host. If so, point all of your switch's syslog clients to a host running a syslogd server process, scan the associated log file and then report the event to your network management server.
If your business requirements mandate a more robust security approach, ask your security vendor to provide you with a list monitoring applications that their product provides hooks into. This will give your operations staff eyes into the data center to determine when physical connections have been broken, as well as give you access to the Simple Network Management Protocol's (SNMP) Management Information Base.
Implementing a security plan that protects these four borders and provides additional administrative features provides your applications with heightened security, ease SAN administration and provides a reliable reference for tracking down anomalies that occur in your SAN. You'll have to decide how to implement this plan--whether to exploit the tools available to you through your hardware offering, purchase layered security products or some combination of the two. I recommend the latter as the best approach.