Many components in SAN security relate to SAN design, and the decision to use these components depends on installation requirements rather than network functioning or performance. One clear exception is the zoning feature that is used to control device communication. The proper use of zoning is key to fabric functioning, performance, and stability, especially in larger networks. For more information, see 10.5, “Zoning” on page 260. Other security-related features are largely mechanisms for limiting access and preventing attacks on the network (and are mandated by regulatory requirements). They are not required for normal fabric operation.

This chapter includes the following sections:

One way to provide limited accessibility to the fabric is through user roles. FOS has predefined user roles, each of which has access to a subset of the CLI commands. These roles are known as role-based access controls (RBACs), and they are associated with the user login credentials. When you log in to a switch, your user account is associated with a predefined role or a user-defined role. The role that your account is associated with determines the level of access you have on that switch and in the fabric. For more information about RBAC, see the “Managing User Accounts” chapter in the Fabric OS Administrator’s Guide, which you can find at the following website:

FOS offers four predefined accounts: Admin, factory, root, and user. Although the root and factory accounts are reserved for development and manufacturing, the password for all default accounts should be changed and secured during the initial installation and configuration of each switch. Recovering passwords might require significant effort and fabric downtime.

In addition to the default permissions assigned to the roles of root, factory, admin, and user, Fabric OS supports up to 252 additional user accounts on the chassis. These accounts expand the ability to track account access and audit administrative activities.

Each user account is associated with the following things:

Security protocols provide endpoint authentication and communications privacy by using cryptography. Typically, the user is authenticated to the switch while the switch remains unauthenticated. This authentication means that you can be sure that you know with whom you are communicating. The next level of security, in which both ends of the conversation are sure with whom they are communicating, is known as two-factor authentication. Two-factor authentication requires public key infrastructure (PKI) deployment to clients.

Table 11-1 shows the security protocols that are supported by Fabric OS.

Access control lists (ACLs) are used to provide network security through policy sets. FOS provides several ACL policies, including a Switch Connection Control (SCC) policy, a Device Connection Control (DCC) policy, a Fabric Configuration Server (FCS) policy, an IP Filter, and others. The following sections briefly describe each policy and provide basic guidelines. A more in-depth description of ACLs can be found in the Fabric OS Administrator’s Guide, which you can find at the following website:

The SCC policy restricts the fabric elements (FC switches) that can join the fabric. Only switches that are specified in the policy are allowed to join the fabric. All other switches fail authentication if they attempt to connect to the fabric, resulting in the respective E_Ports being segmented because of the security violation.

Use the SCC policy in environments where you need strict control of fabric members. Because the SCC policy can prevent switches from participating in a fabric, it is important to regularly review and properly maintain the SCC ACL.

The DCC policy restricts the devices that can attach to a single Fibre Channel (FC) port. The policy specifies the FC port and one or more worldwide names (WWNs) that are allowed to connect to the port. The DCC policy set comprises all of the DCC policies that are defined for individual FC ports. Not every FC port must have a DCC policy, and only ports with a DCC policy in the active policy set enforce access controls. A port that is present in the active DCC policy set allows only WWNs in its respective DCC policy to connect and join the fabric. All other devices fail authentication when they attempt to connect to the fabric, resulting in the respective F_Ports being disabled because of the security violation.

Use the DCC policy in environments where you need strict control of fabric members. Because the DCC policy can prevent devices from participating in a fabric, it is important to regularly review and properly maintain the DCC policy set.

Use the FCS policy to restrict the source of fabric-wide settings to one FC switch. The policy contains the WWN of one or more switches, and the first WWN (that is online) in the list is the primary FCS. If the FCS policy is active, then only the primary FCS is allowed to make or propagate fabric-wide parameters. These parameters include zoning, security (ACL) policies databases, and other settings.

Use the FCS policy in environments where you need strict control of fabric settings. As with other ACL policies, it is important to regularly review and properly maintain the FCS policy.

The IP Filter policy is a set of rules that are applied to the IP management interfaces as a packet filtering firewall. The firewall permits or denies the traffic to go through the IP management interfaces according to the policy rules.

As a preferred practice, non-secure IP protocols that are used for switch management such as Telnet and HTTP should be blocked. SSH is enabled on the default IP Filter policy and SSL should be configured to use HTTPS for web access.

The IP Filter policy should be used in environments where you need strict control of fabric access. As with other ACL policies, it is important to regularly review and properly maintain the IP Filter policy.

Fabric Operating System (FOS) supports both Fibre Channel Authentication Protocols (FCAPs) and Diffie-Hellman CHAPs (DH-CHAPs) on E_Ports and F_Ports. Authentication protocols provide extra security during link initialization by ensuring that only the wanted device/device type is connecting to a given port.

Security Policy Database Distribution provides a mechanism for controlling the distribution of each policy on a per-switch basis. Switches can individually configure policies to either accept or reject a policy distribution from another switch in the fabric. In addition, a fabric-wide distribution policy can be defined for the SCC and DCC policies with support for strict, tolerant, and absent modes. This setting can be used to enforce whether the SCC or DCC policy must be consistent throughout the fabric.

The Policy Database Distribution has three modes:

Together, the policy distribution and fabric-wide consistency settings provide a range of control on the security policies from little or no control to strict control.

IBM b-type Fibre Channel (16 Gbps) platforms support both in-flight compression and encryption at a port level for both local and long-distance inter-switch links (ISLs). In-flight data compression is a useful tool for saving money when either bandwidth caps or bandwidth usage charges are in place for transferring data between fabrics. Similarly, in-flight encryption enables a further layer of security with no key management impact when transferring data between local and long-distance data centers besides the initial setup.

Enabling in-flight ISL data compression or encryption increases the latency as the ASIC processes the frame compression or encryption. The approximate latency at each stage (encryption and compression) is 6.2 microseconds. For example (see Figure 11-1), compressing and then encrypting a 2 KB frame incurs approximately 6.2 microseconds of latency on the sending Condor3-based switch, and approximately 6.2 microseconds of latency at the receiving Condor3-based switch to decrypt and decompress the frame. This combination results in a total latency time of 12.4 microseconds, again not counting the link transit time.

Figure 11-1 shows the total accumulated latency when encryption and compression are in use.

Consider these in-flight encryption and compression guidelines:

When you implement ISL encryption, using multiple ISLs between the same switch pair requires that all ISLs be configured for encryption, or none at all.

No more than two ports on one ASIC can be configured with encryption, compression, or both when running at 16 Gbps speed. With FOS V7.1, additional ports can be used for data encryption, data compression, or both if the system is running at lower than 16 Gbps speeds.

Encryption is not compliant with Federal Information Processing Standards (FIPS).