Fibre Channel SAN Security

Fibre Channel SAN security deals with a variety of issues ranging from Fibre Channel frame authentication to Fibre Channel switches. Fibre Channel SAN is an emerging technology that still has many items under development, such as management, virtualization and interoperability. Furthermore, although some progress has been made regarding security in Fibre Channel networks, several opportunities exist for growth.

In this section, we discuss some of the security problems in Fibre Channel SANs, at both the frame and device levels. We continue to address some solutions to these security problems and best practices. The following items will be discussed:

• Zoning

• WWN spoofing

• Fibre Channel (FC) frame weaknesses

• Sequence ID and control number

• Disruption of flow control

• MITM attacks (SNS pollution)

• E_port replication

• LUN masking

Zoning

Zones are to Fibre Channel switches as VLANs are to IP switches. Zones are used to segment the fabric into groups, in which certain nodes are a part of a zone and have access to other nodes in the same zone. Storage nodes could be a part of multiple zones or part of a single zone.

Two types of zoning are used, soft zoning and hard zoning. In soft zoning, the SNS in a switch uses an HBA's WWN for zoning. An SNS is a table located in each switch and shared among switches in the same fabric, which separates WWN into the correct zones. Figure 25-5 shows an example of soft zoning. In the figure, WWN 9382108xxxx, 3859658xxxx, and 3582968xxxx have full access to each other. However, if any of these WWNs try to access zone B members , such as 0038283xxxx, access would be denied .

Figure 25-5: Soft zoning in SANs

Hard zoning is not only different from soft zoning but is another term that has multiple definitions. One definition for hard zoning is 'the act of locking physical ports to certain zones.' For example, physical ports 1 through 4 would be zone A, physical ports 5 through 8 would be zone B, and so on. If a WWN was connected to port 2 and tried to access port 6 in zone B, it would be denied access. Figure 25-6 shows an example of this definition of hard zoning.

Figure 25-6: Hard zoning in SANs

Another definition of hard zoning is a routing procedure. If route-based zoning is implemented, certain routes will be publicized for certain storage nodes. For example, if node 1 were allowed to access node A, node 1 would be notified about the route to node A. If node 1 were not allowed to access node A, node 1 would not be notified about node A. However, if node 1 knew the existence and route to node A, hard zoning, according to this definition, would not prevent node 1 from this access. Hard zoning, in this reference, is not a restrictive tool; rather, it's an information tool.

World Wide Name Spoofing

WWN is used to identify an HBA in a storage area network. WWN is used for authorization of data from one particular zone to another. Additionally, WWNs are used in soft zoning procedures on storage switches to separate certain servers and data. Soft zoning separates WWNs into different zones. Because a switch contains an SNS table that matches up each WWN to a particular zone, a particular WWN would be granted or denied access to another storage node based on the results of the SNS zone table.

WWN spoofing is a high-risk problem in storage area networks because WWNs are often used as the only tool for granting authorization. WWN spoofing is as simple as loading up the device drivers included with the HBA and changing the WWN. An attacker can then spoof a WWN and gain access to data. The switches that contain the zone information would grant access to this spoofed WWN because it authorizes the WWN and does not authenticate it. Figure 25-7 illustrates this type of attack.

Figure 25-7: SAN World Wide Name table spoofing

As best practice, hard-zoning procedures can be used to deter spoofing problems. The physical definition of hard zoning would not use WWN for authorization, but rather the physical port numbers . If an attacker spoofs another WWN, the hard-zoning switch would still not grant it access since the physical port on the switch is trying to gain access to another port to which it does not have authorization, regardless of what WWN it claims to be. However, using the route-based definition of hard zoning, WWN spoofing would not be a good alternative. Because the route-based definition is not a restricted tool, but rather a tool used to deliver routing methods , a hard-zoning switch could still be subverted if the attacker knew the address and the route to its target. Therefore, if a WWN were spoofed with route-based hard zoning, access would be permitted.

Frame Weaknesses

Fibre Channel architecture contains five different layers , numbered 0 to 4. Despite the differences between IP and Fibre Channel, Fibre Channel frames contain weaknesses that are similar to current weaknesses in IPv4 packets. These IPv4 weaknesses have been turned into vulnerabilities and exploited at a variety of levels. The weaknesses in Fibre Channel frames are specifically in Fibre Channel layer 2, known as the framing protocol/flow control layer. Fibre Channel layer 2 is where most security issues have been identified. Fibre Channel layer 2 contains the frame header, which contains the 24-bit source address of the frame, the 24-bit destination address of the frame, the sequence control number (Seq_Cnt), sequence ID (Seq_ID), and the exchange information (Exchange_ID).

As shown as Figure 25-8, layer 2 contains the sequence control number and the sequence ID. A sequence is a series of one or more related frames transmitted unidirectionally from one port to another. The sequence series is responsible for keeping the connection alive between two nodes. A given frame must be a part of some sequence between two end nodes. Frames within the same sequence have the same sequence ID (Seq_ID) in the frame header, which is kept to identify frames that belong in the same transmission process between two nodes.

Figure 25-8: Fibre Channel layer 2 and sequence control

In addition, as each frame is transmitted in a sequence, the sequence count number (SEQ_CNT) is incremented by one. Therefore, that transmission can remain initiated and frames can remain ordered by the incrementing process. However, the fact that the sequence ID is a constant value, thus predictable, and the sequence control number is incremented by a predictable number, which is one, makes the sequence series a predictable value. Because the sequence series is responsible for maintaining the session between two nodes, an attacker would be able to launch a session-hijacking attack and take control of the session.

This attack was made popular with IPv4 packets with similar problems of predictability in Initial Sequences Numbers (ISNs). In ISNs, the hijacking packet would simply need to guess the predictable sequence, similar to the Fibre Channel frame, and take control of a management or data session. Figure 25-9 illustrates this attack at a high level.

Figure 25-9: Fibre Channel frame header attack

The use of predictable session information leaves Fibre Channel frames vulnerable. Additionally, in-band management protocols, such as SCSI Enclosure Services (SES), can allow management sessions to be hijacked and exposed to unauthorized users. As in- band management methods and applications grow, the weaknesses of the session information in Fibre Channel frames could amplify and result in loss of data.

The solutions for predictable sequence numbers in Fibre Channel frames needs to be similar to the solutions for IPv4 vulnerability. Operating system settings and encryption technology enabled IPv4 weaknesses to reduce the likelihood of successful hijacking attacks. Similarly, Fibre Channel frames need to make session information unpredictable. This change can come from the HBA drivers that are installed on the operating systems or within the fabric itself. Either solution should be able to address the static nature of sequence IDs and the predictably of sequence control numbers.

While encryption may be a solution for an IPv4 network, using encryption as a solution for Fibre Channel frames is not as easy, since encryption involves extra overhead and bandwidth costs that may not be acceptable in SANs. As a mitigating solution to encryption, separate out-of-band management networks should be deployed to eliminate the possibility of an attacker hijacking management frames to access storage devices and their data.

Disruption of Flow Control

Flow control is responsible for message flow between two Fibre Channel nodes. In Fibre Channel networks, devices transmit frames only when each device is ready and able to accept them. Before these devices can send and receive frames, they must be logged in to each other and must have established a credit level to send and receive the correct amount of frames. The establishment of credit from one storage node to the other is conducted at the Exchange_ID level of the frame header. This credit refers to the number of frames a device can receive at a time. This value is exchanged with another device during login, so each node knows how many frames the other node may receive.

The problem with flow control is that Fibre Channel frames are unauthenticated. An attacker can therefore send out incorrect Exchange_ID information to a variety of addresses, thus creating a temporary denial-of-service between two nodes. For example, because frames are unauthenticated, an attacker could replace valid frames with incorrect frames that contain a higher Exchange_ID number between two nodes. Because one node will now be sending more frames than can be received, the receiving node will be unable to accept the frames properly and will not be able to respond appropriately. Similarly, instead of creating a higher Exchange_ID number, an attacker could lower the number for the Exchange_ID information, thus leaving one node waiting for more frames to process. This would result in the frames being passed slower from one node to the other, delaying the process of data communication.

The solution for the disruption of flow control is authenticated frames. Because the process of exchanging ID information requires logging in to the other node, authentication of the node should also be addressed at this point. However, while this attack is successful for the disruption of flow control, the disruption is actually quite minimal and the fabric has the ability to correct itself quickly.

Man-in-the-Middle Attacks

MITM attacks have plagued IPv4 networks for some time. The problem in IPv4 is the use of Address Resolution Protocol (ARP) packets. ARP is a protocol that matches a machine's NIC address-known as the Media Access Control ( MAC) address of the machine-to an IP address. However, both the IP address on a network and the MAC address can be easily spoofed. Because no authentication of ARP packets is required in IPv4, a spoofed IP address to another MAC address can redirect information to unauthorized users. The attacker could send out ARP packets that match their MAC addresses to a target's IP address. Therefore, when data is sent to the target, the data will be sent to the attacker since the target's IP address matches the attacker's MAC address.

This attack can be partially replicated in Fibre Channel networks. Fibre Channel switches include a table, referred to as the Simple Name Server. The SNS matches up WWN (similar to a MAC address) to the 24-bit address of the storage node. Since Fibre Channel frames are also unauthenticated, an attacker can use any traffic analyzer program to generate frames in the fabric with a target's 24-bit address and the attacker's WWN, thus changing the SNS information. The SNS would have an updated entry for the 24-bit address with a new WWN. When traffic is being sent to the target's 24-bit address, it would go to the attacker's machine since it matches up to the attacker's WWN.

As shown in Figure 25-10, an attacker sends out a modified frame to xFFFFFE to log in to the fabric (FLOGI). The modified frame has a source address of another trusted entity on the fabric, such as another trusted switch, and the WWN of the attacker. The fabric assumes that the attacker is now the legitimate host since the switch's 24-bit address is matched to the attacker's WWN. All frames destined for the real node are passed to the attacker and then to the legitimate node.

Figure 25-10: Man-in-the-Middle attack on SANs

An MITM attack is simply polluting the SNS table with switches. Polluting the SNS could also be conducted when joining the fabric. An N_Port would send a FLOGI (fabric login) to the well-known address of xFFFFFE (similar to a broadcast in the IPv4). The switch receives the frame at xFFFFFE and returns an accept frame (ACC). The service information would then be exchanged. Because no validation is required to receive an accept frame, an attacker could send a modified 24-bit address to xFFFFFE to attempt to corrupt the SNS table in the switch. As soon as the attacker receives the accept frame, the attacker knows that the SNS table has been modified.

LUN Masking

A Logical Unit Number (LUN) is a unique identifier that is used to differentiate between devices, including physical or virtual disks volumes . LUN masking allows nodes to be aware only of other files or data blocks that they are authorized to access. This is implemented by masking off LUNs that may be available. Similar to zoning, LUN masking is a segmentation tool that has been used for security. LUN masking can be implemented at three levels: at the HBA, at the storage controller itself, and using a third-party device in the storage network.

HBA-based LUN masking uses driver utilities that map WWN to LUNs. The HBA drivers contain masking features that allow the WWN to view only a certain set of authorized hosts . Masking at the HBA level offers easy implementation since a third-party device would not be required in the SAN; however, it does require additional system administration resources since each HBA in a storage network would have to be individually configured. This solution may work well for small storage environments, but it is virtually unmanageable in large SANs. In addition, since LUN masking occurs at the HBA level, if the operating system were compromised, an attacker could change the masking information without any other security controls preventing this. This would allow an attacker to load up device drivers and change the allocation to include as many LUNs as desired, thereby negating any security gained by the masking rules.

Conducting LUN masking at the storage controller is another way of implementing LUN security. The storage controller would map access privileges from each HBA's WWN to the authorized LUN. LUN masking at the storage controller level is probably the best alternative for most SANs, since it has the ability to scale in large storage networks and does not require an extra storage device to add undue overhead. In this scenario, however, LUN masking is dispersed across many storage devices instead of being centrally managed at one device.

The third method of implementing LUN security is using a third-party storage device for allocation. The third-party device would be placed between the client nodes and the storage nodes. The device would handle requests for LUNs before they proceeded to the storage controller. Once the requests have been made, the device would grant or deny access. If the request is granted, it is forwarded to the storage devices. This solution scales appropriately to enterprise- sized storage networks and provides a central resource for LUN management. However, it places yet another storage device in the storage network. Furthermore, it adds another layer of overhead from the client node to the storage controller.

Table 25-1 compares and contrasts each type of LUN masking technique and the pros and cons of each.

Table 25-1: LUN Masking Techniques Compared

LUN Masking Type	Pros	Cons
Storage controller	Scaleable to large SANs.No undue overhead with another storage device.Security cannot be subverted by an operating system compromise.	Management of LUN allocation is dispersed throughout the SAN instead of being centrally managed.
Third-party device	Scaleable to large SANs.Centralized management of LUN allocation.Security cannot be subverted by an operating system compromise.	Added overhead by placing another storage device in the SAN.
HBA level	No undue overhead with another storage device.	Only possible in small SANs (not scaleable).Management of LUN allocation is dispersed throughout the SAN instead of being centrally managed.Security can be subverted by an operating system compromise.

E_Port Replication

E_port (FC extenstion ports) replication is a feature in many Fibre Channel switches. Each port on a switch has a particular function (refer to Chapters 14 and 15 for additional information on FC ports). Each type of port holds a different function, whether it connects two client nodes together or connects two switches together. An E_port, for example, connects two switches together, enabling the connected switches to exchange routing and zoning information.

Because no authentication is required, E_port replication security is not guaranteed . If a storage server provider (SSP) were extending its fabric to a client using unauthenticated E_port replication, the simple act of plugging in the storage provider's E_port to the client E_port would exchange routing and zoning information for the entire fabric, not just for a specific zone. This would allow an unauthorized switch to access information.

To prevent accidental E_port replication, port-type locking and key-based authentication between switches can be used. Products from major switch vendors , including Brocade, McData, and Qlogic, can lock port types rather easily. For example, if physical ports 1-11 connect only client nodes to storage nodes, the port type can be locked to n-type. Similarly, if only port 12 is used as an E_port, it can be locked using port-type locking. This would prevent an attacker from replacing a client node with a switch and have an E_port exchange information from the two switches automatically.

Key-based authentication between the switches is also a best practice to prevent unauthorized E_port replication. Key-based authentication would require each switch to authenticate before being added to the fabric. This would disable any type of communication to and from the switch until validation keys or certificates have been exchanged from the joining switch to the existing switches.