SAN Security

It is easy to think of SANs, especially Fibre Channel SANs, as naturally secure. FC systems are, after all, closed systems. Storage arrays and tape libraries are not directly accessible from desktop machines or the network. They must be accessed from a Fibre Channel host bus adapter that is installed in a trusted server.

The safety of the SAN is, therefore, in the hands of the server. SAN devices have a totally trusting relationship with the servers that access them. The problems start when an intruder gains access to the server. When the intruder has access to the server, he gains an open path to the storage.

It is trust and openness that have made Fibre Channel SANs vulnerable. There is little or no protocol-level security built into Fibre Channel itself. Fibre Channel devices have always operated under the assumption that they are attached to a trusted server in much the same way that Parallel SCSI is. Devices require little or no real authentication for the same reason. When Fibre Channel host bus adapters (HBA) log into a fabric, they are not challenged.

Instead of providing a last stand against an attacker, Fibre Channel SAN architectures introduce new vulnerabilities that can be exploited by malicious hackers and may represent an unacceptable risk to IT infrastructures. IP SANs improve on Fibre Channel in terms of security but do not plug all the holes. Luckily, IP security is highly developed and, with IPSec, inherent in the protocols.

Fibre Channel Vulnerabilities

Some of the vulnerabilities that exist within Fibre Channel SANs are derived from a lack of security features common to other networks and servers. For example, Fibre Channel lacks common access controls and even simple challenge-response protocols that are used to provide authentication. All but the newest Fibre Channel switches secure the management port with only one known login and password. At the root of most of the security problems with SAN is the level of trust that servers have with the Fibre Channel network. All devices are completely trusted and have complete access to the storage devices available on the network. Some of these shortcomings are being addressed by the Fibre Channel standards bodies, others by storage system vendors. Fibre Channel security is getting better but is starting from such an abysmally low level that it will be a while before it is even adequate.

Lack of User Account Authentication

Fibre Channel networks have no native authentication mechanisms. Practically any device can log into the network without challenge. Zoning inhibits only what a host can access, not whether it is allowed into the network at all. Once on the network, host processes have access to the storage devices at a level below the file system and its access controls.

The login process of a Fibre Channel fabric does not support any type of user-level or account-level authentication. It uses only the World Wide Name and port address in the HBA. Users and accounts sit above the HBA in the OS layer and are divorced from the login process. When the HBA logs into the fabric, it is not challenged as to the authenticity of its identity beyond the WWN and port address. The application or file system interacts with the storage devices without challenge as well. If the Fibre Channel and SCSI addresses are as expected, the host can have whatever privileges have been associated with whose addresses.

In all fairness, this is not very different from Ethernet. If you have a valid MAC address, you are allowed onto the network. This is true even if MAC address filtering is being used, because the address is an expected one. What is different is what happens in the upper-layer protocols.

Most applications that are run on Ethernet networks use TCP/IP, IPX/SPX, or NetBIOS as transport protocols. These use higher-level, application-level protocols to communicate between processes and applications. These in turn provide the network services necessary for applications to access resources. Almost all of them require some form of challenge-based authentication, such as a valid username and password or a set of encrypted keys. Even primitive TCP/IP protocols such as Telnet or FTP require at least a simple username and password.

SAN applications behave differently. They access resources directly, using SCSI. SCSI has no native authentication, and its Fibre Channel implementation continues that tradition. Whereas the application-level protocols found on most networks have an intermediary application whose protocols require authentication, Fibre Channel SANs give direct access to resources without any authentication.

This security hole can be used by a malicious insider to run a program on a compromised server that accesses the SCSI driver directly. Using techniques such as WWN spoofing, hackers can also assume the identity of a valid HBA and access the fabric without challenge as though they were that HBA. Any device that has a path to a SCSI device and LUN (Logical Unit Number) can access the blocks on that LUN, whether it should or not. The attacker can then send bad information to the storage devices, produce commands that destroy data, or read the data.

Because there is a lack of user-level authentication, an attacker does not need root or system administrator access to interact with the storage devices on the SAN. She needs only to have enough privilege to be able to issue SCSI commands or use utilities that issue SCSI commands to storage devices. Many user accounts have these privileges so that they can legitimately access data on a disk.

Tip

Hosts attached to a SAN should not allow any user account except root or the system administrator to add programs. This will help keep intruders from downloading utilities that send SCSI commands directly to storage devices.

The only real defense against attacks using SCSI utilities is to secure the server and its applications. When an intruder has control or access to a server on the SAN, he can bypass the file system and attack SAN devices directly.

It should be noted that the industry has developed a Fibre Channel protocol that addresses issues of authentication, called FC-SP. The goal of the protocol is to provide a secure connection between Fibre Channel devices. It includes the use of common authentication schemes to identify who has access to particular storage resources or services.

Soft Zoning and World Wide Name (WWN) Spoofing

Fibre Channel fabrics use a technique called zoning to restrict hosts from accessing certain devices on the network. Zoning is a relatively weak form of security, and one form of it, soft zoning, is especially poor as a security mechanism.

Soft zoning restricts access to devices on the Fibre Channel network according to their WWN. This is convenient for system administrators who need to make changes to the Fibre Channel SAN on a regular basis. Because an HBA in the server has a WWN, the identifier for it travels with it if it is moved. If the port to which the server is connected changes, its access privileges remain the same.

This convenience comes at a price. Place the same HBA in a different host, and the zoning stays the same. The access rights to resources on the SAN are those of the original host, because they are tied to the HBA, not the host itself. If an administrator forgets to change the zoning, the new host will access the SAN as though it's the original one.

It is also possible to change the WWN on many HBAs. Changing it to another HBA's valid WWN is known as WWN spoofing. The computer that is spoofing the legitimate WWN will appear to be the same host, but on a different port. With soft zoning, this host will now have the same access as the original. As far as the Fibre Channel switch is concerned, the device has simply moved. All that an attacker needs is a WWN that is properly zoned, and access is assured.

Why Would Anyone Allow WWN Spoofing?

There are legitimate reasons for WWN spoofing. Some controllers and servers use spoofed World Wide Names so that they are able to assume the identity of a failed device. Using this method, a controller will present to applications the same WWN as the failed device and allow I/O to continue without first failing and restarting. Similarly, an HBA in a clustered server may spoof a WWN to appear to the SAN to be a failed host so that it does not have to request that data be resent from a storage device.

Despite these reasonable uses for WWN spoofing, it is a dangerous feature to have enabled on an HBA or a device controller, because it allows an attacker to hijack the identity of a legitimate server.

The best way to avoid successful WWN spoofing attacks is to not use soft zoning. Instead, use hard zoning, which uses the port name and WWN together. It is less convenient but more secure.

No Protocol-Level Encryption

SCSI never anticipated the need for sending data over anything but a closed, dedicated connection. With a closed system, there was no good reason to encrypt data as it moved over the wire. Data may be encrypted on the medium, but it was not worth spending the CPU cycles on encrypting normal I/O. This legacy carried over to the Fibre Channel implementation of SCSI. No protocol support exists for encrypting data in transit in an FC network. Unlike IP networks, which can rely on SSL or IPSec, connection-level protocols do not encrypt data in transit in a Fibre Channel network

It is possible for a host application to encrypt data before sending it out over the network, even without protocol support. In practice, however, this is rarely done. It places a heavy burden on the application programmer and host CPU. It also requires that the device at the other end of the connection be able to decrypt the data before writing it.

Inadequate Isolation

Zoning is a reasonable method of hiding resources from hosts that shouldn't see them. As a security mechanism, it is not particularly robust. Even hard or port zoning can be defeated by plugging an invalid host into a valid port in the zone. Without account-level authorization, only a port ID, port address, or WWN stand between the system and harm. All of these identifiers can be obtained with the right software and spoofed.

Within a standard Fibre Channel switch, zoning does nothing to isolate services such as the simple name server or the zoning service itself. Any malicious code, or even poorly designed code, that causes a disruption in these services disrupts the entire fabric. Zones do not isolate fabric services from failures that could bring down the switch or the entire fabric. This provides an opportunity for a denial of service attack.

There is some good news, though. Many of the latest generation of intelligent Fibre Channel switches provide for virtual fabrics that create better isolation of internal services. Although some errant or malicious code may be able to crash a particular virtual fabric, it is less likely to affect other virtual fabrics or the entire fabric. These are important features to consider when purchasing Fibre Channel switches.

Fibre Channel Arbitrated Loop and LIPs

In the early days of SANs, Fibre Channel Arbitrated Loop (FC-AL) was developed as a less expensive way to implement a SAN. The components were less expensive in large part because they lacked any intelligence and were only minimally managed. This was in contrast to switched fabric implementations that required many more software services and cost much more as a result.

Two services that FC-AL does not provide are a login service and a naming service. The result is that when any device enters an FC-AL SAN, the entire loop is reinitialized. A command called a Loop Initialization Primitive (LIP) begins the process of loop reconfiguration. This is why the process itself is often referred to as LIP, even though that is only the name of the command.

The problem with loop initialization is that it can cause disruptions in the I/O that is currently in progress. The loop effectively halts while the reinitialization sequence proceeds. A node that enters and leaves the loop repeatedly, or that issues excessive LIPs, can cause an arbitrated loop to basically shut down while it tries to figure out how to reconfigure it. One of the most common causes of this type of behavior is a hub port that goes on- and offline several times in a row.

This behavior represents a security threat. A hub or device port can be made to go in and out of bypass mode effectively, taking the node in and out of the arbitrated loop quickly. One method of doing this would be to gain access to the management interface of a hub or other FC-AL device via an IP network and use it to turn ports on and off. An intruder could exploit this behavior, causing disruptions within the entire FC-AL portion of the SAN or storage device.

Most storage system architects no longer build FC-AL SANs. The stability problems far outweigh the cost savings. One area where FC-AL is still prevalent is in the internal architecture of storage arrays, both tape and disk. There may be vulnerabilities inherent in the use of FC-AL in the internal architecture of arrays. If an intruder has gained access to the array's management interface, she is capable of creating a denial of service attack that would be hard to distinguish from other loop problems. Using managed hubs and securing the management port of FC-AL devices is the best method for halting these type of problems.

Fibre Channel over IP: Effects of Gateway Devices

Although still a relatively new part of the SAN architecture, the need to support data protection applications, such as remote copy, is continuing to drive investment in what is commonly referred to as SAN extension.

As described in Chapter 2, there typically are two ways to connect SANs over long distances: directly, using a long fiber optic cable, or using existing WAN and MAN capabilities available from most data communications providers. Using the AN/MAN infrastructure requires the use of special devices or switch blades that provide the interface to the data communications infrastructure. These must also implement one of the common long-distance Fibre Channel protocols. The most commonly used protocols are FCIP (Fiber Channel over IP) and iFCP (Internet Fibre Channel Protocol).

There are no special security concerns associated with the direct Fibre Channel connection method. Unless someone can physically tap the fiber optic cable, it is a closed transmission and difficult to tamper with. There are, however, several security issues with moving Fibre Channel frames over WAN and MAN connections.

To begin with, they are susceptible to many of the same attacks that IP connections have. Leased lines and similar private data communications are more secure, because traffic doesn't move across a public network, such as the Internet, and is inaccessible to the outside world. That said, security can be breached when the same network infrastructure is used for storage and the Internet. In this case, portions of the storage infrastructure are now exposed to typical intrusion and denial of service (DoS) attacks.

Most exposed is the IP gateway device, which naturally has to be connected in some fashion to the LAN or WAN infrastructure. Many IP SAN gateways are designed to connect Fibre Channel to interior IP networks. These networks are vulnerable themselves and provide an attacker a direct channel to storage that didn't exist before. Most IP gateways do not provide firewall capabilities and must be married with a firewall product even for internal connections.

Because FCIP encapsulates Fibre Channel in IP packets, it would be very difficult to read or change the data in a way that would not cause the data to be corrupted. Probably the worst that can happen is that the data stream becomes so corrupted that the transactions fail, causing a DoS situation. The ability to launch an attack on a SAN extension gateway device would seem to be very difficult but not impossible, given the right set of circumstances.

Management Interfaces: IP and Vendor API

The Achilles heel of many Fibre Channel storage networking system components has been the management interface. Rarely afforded the level of security that the rest of the network has, the management interface often has only a single login and password, which then yields complete access to the device. Most do not use authorization schemes, encryption, or other standard security measures that one would expect from a server or network device.

System administrators can access many FC SAN devices from insecure web browsers or simply telnet in to them. This represents an excellent vector for an intrusion. Most IT professionals place management ports on separate networks, completely isolated from the main user network. Those that do not isolate the management port place their systems and companies at great risk. A management port should never be accessible through the main LAN and, especially, over a WAN.

Because they use embedded servers, management interfaces also suffer from similar vulnerabilities as most servers. Typically, intruders have used buffer overruns and poor exception handling to place arbitrary code on an operating system's program execution stack. This, of course, allows the attacker to run rogue programs at will. Although this is much harder in embedded systems, owing to the specialty of the embedded software, it has happened to networking equipment in the past. Many storage devices are based on commercial operating systems rather than proprietary ones. The knowledge to write dangerous programs for these software platforms is readily available and often exploited. This is yet another reason why management interfaces need to be physically isolated from other portions of the network.

Bypassing the File System

SCSI is by far the most widely deployed storage protocol in FC SANs. The key advantage to SCSI over Fibre Channel is that the applications written for Direct Attach Storage do not have to change dramatically. For more information about SCSI over Fibre Channel, consult Chapter 2, "An Overview of Storage Technology."

When host security is compromised, an attacker has not only access to the file system to create mischief, but also the host SCSI commands. It is possible to run a program on a host that directly issues all kinds of SCSI commands to devices on the SAN. Because there is no SCSI packet filter on the network ensuring that these are legitimate packets, it is conceivable that a host that has been breached by an intruder can be used to do considerable damage to devices on the storage network.

There are a number of attacks an intruder can execute using SCSI commands. An intruder may choose to use SCSI commands for a DoS attack, for example. One way of doing this is to use something known as FC Ping. The legitimate function of FC Ping is to discover whether a device on a network is still operational, which is similar to the IP version. It is not, however, based on the same IP primitive command as IP Ping, the ICMP Echo command.

There is a variety of implementations of FC Ping. One freely available version, called fc ping, uses the SCSI Inquiry command to detect responses from devices on a SAN. This software and its source code are freely available on the Internet. It would not be difficult for an intruder to modify the source code to send SCSI Inquiry commands repeatedly to a device on the SAN.

This would be one way of launching a DoS attack against a SAN, similar to the Ping of Death. If it is sent to enough devices at the same time, other problems would occur in the FC SAN, including traffic bottlenecks and device timeouts. Situations such as this have occurred by accident due to badly behaving HBA driver code. A determined attacker could do much worse.

Having access to other SCSI commands means that data blocks could be changed or manipulated without the host file system or database being any wiser. With access to SCSI Media Control commands, an attacker could even manipulate or damage backups.

The good news is that other types of SCSI-based attacks would be very difficult because of the way FC HBAs are constructed. Most FC HBAs put both the Fibre Channel command processing and the SCSI command processing in silicon on board. Without altering the HBA microcode, it is very difficult to launch an attack based on SCSI commands.

Using Fibre Channel Analyzers

One possible way to do extreme damage to an FC network is through use of a Fibre Channel analyzer or test instrument. These are invaluable tools to engineers and system administrators trying to debug problems in Fibre Channel equipment. In the hands of a knowledgeable malcontent, they can be used to siphon off information and to disrupt an FC network. The analyzer taps into the network but is usually invisible to the network. Better analyzers can decode FC commands and SCSI commands in a human-readable form and inject FC commands into the network.

This is a very difficult way to attack a SAN. To begin with, FC analyzers are hard to use and need considerable training and practice. Second, they are expensive enough as to be rare in most organizations. If one were to go missing for a while to be used as a tap, it would most certainly be noticed. Finally, the people who are trained in the use of an FC analyzer tend be highly paid and well-treated members of an engineering or IT organization. They have less incentive to do damage to the SANs they design and manage.

The real threat with a Fibre Channel analyzer is that it will be stolen by someone inside the organization. These analyzers are quite expensive, usually costing tens of thousands of dollars, and only as big as a laptop. They are valuable and easy to steal, making FC analyzers prime candidates for theft. FC analyzers need to be kept under lock and key, and subject to signout procedures.

In a Nutshell: All Are Trusted

Fibre Channel is a network designed like a closed environment. Security was a major concern at the beginning of the technology's development. The same was true for other types of networks, which had back doors and security holes long before the Internet exposed them. Even now, there are many preventable security problems with networks at all levels.

One can sum up one of the key deficiencies of Fibre Channel from a security perspective by saying that all devices are considered trusted. Like PCs, which were treated as an extension of the mainframe environment, and the Internet, which was treated as an extension of the network environment, SANs were designed to extend the Direct Attach Storage (DAS) model. In the DAS model, all devices are trusted, there being a one-to-one relationship between the storage device and the host. In this type of relationship, there is no need to not trust the host or the device.

The Fibre Channel SAN concept opened up the DAS model and provided much greater connectivity and access. Unfortunately, it maintained the DAS trust model. Zoning, virtual fabrics, and LUN masking and locking are attempts to limit access between devices for the purpose of management, not security. If access has been granted to a WWN or port, it is assumed that the host attached to it is trustworthy. This is simply not always the case.

IP-Based SAN Vulnerabilities

As SANs based on the IP networking protocols iSCSI SANs, for example become more popular, a new set of security concerns is introduced into the storage arena. IP SANs have the benefit of mature IP security features, yet many storage security holes remain.

Some argue, however, that IP SANs may even be less secure then FC SANs. That argument is usually based on the fact that an external attacker can directly access IP storage devices without first having to go through a server or other host, and the devices are accessible from anywhere on an IP network. At least one layer of security has been removed, the skills needed to launch an IP-based attack are more common, and there are more avenues of approach for an attacker to use.

IP SAN devices may also be susceptible to a long-distance threat. For most FC SAN attacks to be successful, the attack has to come from inside the network. A person in the IT organization is the most likely attacker, which limits the pool of people capable of attacking the SAN. IP SANs are on the IP network and can expose storage devices to external intruders. An attacker capable of breaching the network defenses can now attack storage and servers separately, using different modes of attack. This greatly complicates system security by adding a new dimension to the overall security picture.

IP SANs do have a certain advantage from a security perspective. There are secure protocols, both open and proprietary, for IP networks. This is not the case for FC networks, especially those that use FC SCSI. IP networks can use various methods of securing data in transmission, including IPSec and SSL. In addition, IP networks have well-understood, field-tested, and commonly deployed authentication methods, including CHAPS and Kerobos. FC networks are still waiting for these.

Authentication in iSCSI

iSCSI, being IP based, allows for authentication of hosts. This is superior to Fibre Channel, which is only beginning to deploy authentication protocols. Unfortunately, the iSCSI authentication is host based, not user based. This presents a problem if a host is compromised. It is usually easier for intruders to break into a user or guest account that has very limited access to resources. In the case of iSCSI, this type of account is usable for launching an attack. This is another reason that a firewall must be between the iSCSI target devices and the hosts that access them, and that the firewall must be able to filter on users.

SCSI Attacks from Unknown or Spoofed Hosts

One key advantage that FC has is that an attacker almost always needs to access the SAN from an internal and (ideally) trusted host. This creates a significant barrier to intrusion. For an attacker to access a Fibre Channel storage device, he would first have to penetrate the perimeter defenses (firewalls, secure routers, Intrusion Detection Systems, and so on) and then breach host security and perhaps even application security.

With iSCSI, one layer of protection host security has been bypassed. SCSI commands iSCSI, in this case can be sent directly from some point on the LAN, the WAN, or even the Internet to the storage devices. This has several effects. Unlike Fibre Channel, iSCSI devices on the IP SAN are now subject to malformed SCSI commands, similar to malformed URL attacks. The effect of this is unknown, but it may expose iSCSI devices to buffer overflow and exception handling problems that are more common among Internet-accessible devices.

Another possible effect is that correct iSCSI commands may be sent to a storage device that are designed to do damage. Assuming that the attacker can spoof a valid host (which is not hard to do), she will be able to retrieve, alter, or delete blocks of data from a remote computer.

DoS Attacks

Any IP device is vulnerable to IP-related DoS attacks. This is true for IP SAN devices. iSCSI devices are also vulnerable to an attack similar to the fc ping attack. It is possible to send repeated SCSI Inquiry commands to a device, overwhelming it as it tries to respond. This type of attack can now be carried out without use of a compromised host simply with a breached network perimeter. The normal Ping of Death attack can also be used against an IP SAN device. Other, similar IP DoS attacks can be launched against iSCSI devices.

IP SANs are susceptible to another form of DoS attack, one not aimed at the iSCSI devices but at the infrastructure supporting them. Because iSCSI is built on Internet technology, attacks that can disrupt portions of that infrastructure may affect the ability to access iSCSI SANs.

Although these attacks are not likely to destroy data, they disrupt the ability to use the data. Continued loss of availability can have an effect on a business that is as profound as data loss.

Naming and Discovery Services

A particularly vulnerable portion of the IP SAN is the naming and discovery infrastructure used by iSCSI. iSCSI uses a URI type address to name resources. This has the advantage of allowing changes to the IP addresses of devices on the network without having to reconfigure all the hosts. Under-neath these names are still IP addresses. If the hosts are using standard network directory technology like DNS, LDAP, or SLP to provide for discovery and translate iSCSI names into IP addresses, the IP SAN can be brought down by attacks on these network services, many of which are well documented and common.

This differs from Fibre Channel, in which the directory services are provided by the Simple Name Server (SNS) built into the Fibre Channel switches themselves. This network service is accessible only from nodes connected directly to the fabric. Access to SNS happens at such a low level that it would be incredibly difficult to attack it even from a compromised host. There is no FC naming and directory that can be accessed from outside the SAN to cause a DoS attack.

Firewalls Do Not Speak iSCSI

A major security concern in IP SANs is that most firewalls are not designed to crack open an iSCSI packet. Different types of firewalls can examine incoming IP traffic and reject packets based on a variety of criteria and at different network layers. Some are able to filter packets at layers 3 through 7 and can even decode malicious HTTP traffic. iSCSI commands are new to firewalls, and none currently looks at that type of payload.

Some firewalls may simply reject incoming iSCSI commands, depending on how permissive the security is. This could cause problems for system architects who envision accessing IP over long-distance connections.

It is also likely that iSCSI traffic would be deployed over a secure VPN connection, which most firewalls will not be able to interpret because the payload is encrypted. It is unknown whether the VPN server's security filters will be able to understand external iSCSI commands and see them as malicious. This may cause undesirable iSCSI commands to pass through a secure connection right to a device. With a VPN, only the connection is secure, not necessarily the host at either end of the connection.

It is important to remember that iSCSI primarily targets small and midsize businesses. These businesses rarely have the most sophisticated network defense devices and often rely on integrated security appliances. If these devices do not know how to identify malicious use of iSCSI commands, use of iSCSI will create potentially dangerous system vulnerabilities. iSCSI is also being promoted as a less expensive way to perform replication and remote copy functions, which are important to disaster avoidance and business continuance. Security appliances set at very restrictive levels that do not understand iSCSI will make these architectures difficult to deploy, and setting them to more permissive levels will expose the SAN to hackers.

Detecting Intruders

Storage systems represent a special difficulty for security administrators. Most tools used to monitor illegal activity do not understand SCSI, Fibre Channel, or other storage protocols. There are many ways to tunnel storage protocols in standard TCP/IP and have it look like normal traffic.

Even if more sophisticated tools do not help much, simple techniques do. Log files on hosts and SAN devices will show some unusual activity and should be checked periodically. Changes in the behavior of the system may also indicate the presence of an attacker.

Unfortunately, the best way of knowing that an intruder has penetrated the security of a SAN system is by the effects. When data blocks begin to change unexpectedly, it may mean that an attack is in progress.

Multiple TCP/IP Connections

When an application creates multiple IP connection to better use available bandwidth, the application data that is carried in the IP packets is spread out among many separate connections. This makes it very difficult for Intrusion Detection Systems (IDS) and firewalls to detect potentially damaging information sent to a device.

This is currently a problem with many packet filtering technologies today, because the firewall has no way of knowing that part of the payload is in a different data stream. Potentially harmful information can be sent to a device without security systems detecting it. Only when the application reassembles the information will the effect be noticed. The onus is on the application to detect harmful data. Because of this, many firewalls will not allow multiple data streams to travel between remote and local hosts and devices.

iSCSI uses multiple TCP connections to make better use of bandwidth in a network connection. Even if the firewall or IDS is capable of cracking and examining iSCSI packets, it may not allow multiple IP streams as part of the same session. If multiple connections are allowed, the security measures may not be able to detect harmful data contained in those connections, and iSCSI devices will have to be able to guard against attacks contained in iSCSI packets.

Software and Configuration Holes Exploitable by External Hackers

iSCSI devices are, by nature, TCP/IP devices. This makes them vulnerable to all the attacks that currently affect network devices. The use of commercial or open-source TCP/IP stacks means that methods of attacking these devices are well known. Fibre Channel benefits by security through obscurity, meaning that the skills and tools needed to attack it are not readily available.

IP SANs have no such advantage. In fact, the network interface may be the real target of a DoS or other type of attack. The attacker may not even know that the iSCSI device is primarily a storage device when launching an attack. The results will still be the same a down or damaged storage device.

Another potential vulnerability is the management interface. If management information is run across the same network as the actual data if both interfaces are connected to the same network there is a chance that SNMP information will announce to an attacker that a storage device is available and what its key features are. An attacker can glean important information about devices from management data being broadcast across the network.

SAN Appliances

It is becoming more common to have special-purpose devices, or appliances, present in SAN architectures. They are commonly used to provide specific services for the storage network. Some examples of these servers are virtualization, backup, remote copy, clustered file services, and management appliances. Some vendors have created large storage servers, which integrate a large number of these features into one device.

Although these devices have an attractive Total Cost of Ownership (TCO) profile and allow functionality to be added incrementally to a SAN, they are basically servers and are vulnerable to many of the same problems as other servers. Often, they are based on a commercial or open-source operating system such as Microsoft Windows or Linux. Vulnerabilities in these operating systems are transferred to these appliances. If the appliance is accessible to a network of any sort, it may be vulnerable to attacks common to the underlying OS.

Attack Vectors Common to All SCSI Storage Devices

Any storage device that uses a form of SCSI has certain vulnerabilities. As previously discussed, SCSI was designed for a closed and, hence, trusted environment. SCSI devices traditionally have been held behind and subordinate to a server and inaccessible on their own. Storage networking changed this, opening storage devices directly to rogue hosts and Internet hackers.

Inline Management through SCSI Commands: SCSI Enclosure Services

There exists a set of SCSI command extensions called SCSI Enclosure Services (SES). SES was conceived of as a way for complex DAS systems to communicate information about the operating conditions of the device back to a host. This in turn allowed the host to alter some of the environmental and operational variables. Because the SCSI connection was always present, sometimes the only connection between the host and device, this was convenient. Typically, the host accesses the enclosure as a LUN on the target SCSI address.

There are several implications to having this type of command set at the disposal of an intruder. First and foremost, intruders need information about their intended targets, and SES provides information that would be hard to get otherwise. If the attacker has the ability to access the storage array from an IP network node or the Internet, he may obtain information that would otherwise be available only to someone who was standing in physical proximity to the devices or who had compromised a secondary network reserved for management. Even if an attacker cannot get to the management interface because it has been properly secured and resides on a separate network, it is possible for her to gain management information by using SCSI commands on a compromised host. SES creates a back channel for hackers to get at management features.

Gleaning information about devices is dangerous enough, but SES also provides the ability to change some of the operational parameters of a storage device. This allows management software to manipulate various elements within the storage device, including interfaces and fans. With access to these commands, an intruder can do quite a bit of damage.

LUN Masking and Locking Uncovered

Storage system administrators rely on a feature called LUN masking to help secure storage resources. With LUN masking, devices will not respond to the SCSI Inquiry/Report LUN command unless it comes from an initiator that has permission to receive device information. This tricks the host into thinking that there are no devices available on that LUN. This approach works when certain LUNs must be hidden from certain hosts.

LUN masking is a weak form of protection against attack, because it does not make the LUN truly unavailable; the LUN only appears to be unavailable. Hosts can still send SCSI commands to a masked LUN, and devices will respond to it. There are diagnostic programs that attempt to send SCSI commands to all LUNs at a SCSI address incrementally to see whether any respond, in a manner similar to a TCP port scanner.

An attack on masked LUNs would try to send commands to a LUN and see whether it responds with anything, including an error code. Then it would write erroneous (probably random) information to the device. That could easily damage real information on the device. LUN masking offers no real protection against data loss.

Some storage array manufacturers have instituted a stronger version of LUN masking called LUN locking. With LUN locking, LUNs will not respond in any fashion to any command that does not come from a known initiator with proper permissions. This is clearly a more effective method of securing devices from attack. Even then, this provides no safety if the attack comes from a spoofed or compromised host that has permission to access certain LUNs. Without account-level, two-level authentication, it is still possible to get past LUN locking.

Controllers Susceptible to Server Type Programming Errors

Controllers are used to provide a central access point for individual storage devices, such as the disks in a disk array. Many have higher-level features, including RAID, path failover, device failover, virtualization, and management. Although much of the functionality of a typical controller is in hardware, more advanced functions (management, failover, and virtualization) are provided by software and as such are vulnerable to the same type of security holes as are servers. Buffer overruns, off-the-shelf or open-source TCP/IP stacks, and poor exception handling are primary areas at which a hacker may launch an attack.

Patch management of controllers is as important as with server operating systems.

NAS Security

NAS devices are comprised of three main parts: the disk subsystem, RAID controller, and NAS or file head. The most vulnerable part is the NAS head. Often based on Linux, Microsoft Windows, or a proprietary NOS, the NAS head is still a server and susceptible to many of the same security afflictions that other file servers have, including vulnerabilities in the TCP/IP stack and file system. The good news is that NAS devices typically have had all other functions not vital to serving up files stripped away. This provides a hacker less opportunity to exploit other types of common vulnerabilities even when based on a commercial or open-source OS.

NAS devices, like all file servers, are also open to attacks via the protocols they use. Because all NAS devices use CIFS, NFS, or both, they are also susceptible to attacks aimed at those protocols.

CIFS and NFS Security

There are several security issues with CIFS and NFS. NFS, for example, uses host-based authentication instead of user-level authentication. User-level authentication is necessary to access the host, but when authorized, the user will have access to all exported mounts available from that server.

On the other hand, many implementations of CIFS allow user-level control over access but still show all available shares, including ones that the user can't access. This gives an attacker invaluable information about the resources available on a network.

The conventional security system vendors are now taking NFS and CIFS security seriously. Application firewall and IDS products are now available that can look at CIFS and NFS packets and scan for attacks. Software has also been introduced that integrates antivirus software into the NAS filer so that viruses and Trojan horses are removed as they are stored, not when a host accesses them.

Securing Files Through Access Control and Encryption

There are many ways to secure a file system. The two most important ones are access control and encryption. The former, access control, determines permissions for each user and process, thereby controlling access to system resources, including file system objects. Access control, in turn, relies on authentication to determine whether the person requesting access to resources is really who she claims to be.

Tip

One of the most common methods of access control is by using an access control list (ACL). An ACL can cause performance problems though. It can take a lot of time to search an ACL to find what permissions a system object has. The most frequently used systems often have very long lists. Sifting through these lists can significantly reduce performance.

Access Control Posture

Access control is part of all file systems, to some extent. What is important to the system administrator is the default posture of the access control system. Many systems are quite permissive, allowing access to all resources unless otherwise stated. It is important to assume a Default DENY posture and set access to be as restrictive as possible within the file system.

Access controls make it difficult for unauthorized users to get at file system objects. Encryption assumes that an attacker can find a way to access an object. Instead, it makes the object useless to attackers, deterring them from trying in the first place. If the attacker tries anyway and is successful at cracking through the access control and other security measures, the data will not be of use to him.

Encryption is simply the encoding of data so that it is unreadable and unusable. Until it is decrypted, or decoded, encrypted data appears to be a jumble of incomprehensible characters. The method by which data is encoded is outside the scope of this book, but many books on security provide good descriptions of the algorithms used.

When to Encrypt: Data at Rest, Data in Motion

A typical problem for system administrators is when to encrypt data. Data can be encrypted while being transmitted over a network (data in motion) or after it has reached its destination (data at rest).

Encrypting data in motion defeats attempts to capture data while it is in transit between two nodes. This is what secure network protocols such as SSL and IPSec do, and it is the backbone of VPN services. If an intruder is able to tap into the data stream, the data will be indecipherable and of no value to the attacker.

Data at rest is often encrypted to secure data on storage devices. Encrypting data at rest is used more often for removable media, making it pointless to steal. With networked storage systems, critical data is also encrypted while at rest to safeguard information from those who might have access to the network.

It is important to encrypt sensitive data in motion and at rest. Both methods deter attackers from bothering with the data by making it unusable to them.

Manual Encryption

There are two ways to encrypt and decrypt data: at a file system level and at a block level. The first is a manual process, and the second uses inline devices and software to automate encryption and decryptions.

With manual encryption, file data is run through a program that encodes the data and saves it to the same file or a new file. This type of program is available as commercial, open-source, and free software. Typically, the program asks for a key, which is a code word or phrase supplied by the user. The file to be encrypted and key are run through one or more algorithms that transform the characters in the file into different characters. PGP (Pretty Good Privacy) is an example of a program of this type.

To decrypt, the file and the key are once again supplied to the program. The data is run through the same algorithms in reverse to produce the original data.

Manual encryption products are a great way of securing small amounts of data. Many commercial programs will allow a user to set up a secure portion of her hard drive and to encrypt and decrypt data automatically. The downside to this process is that the user has to remember the key phrase. Key phrases suffer from the same problems as passwords. Users either forget them and cannot access their data, or they write them down or worse yet, record them in an unencrypted file on their hard drive. When the key is accessible, electronically or physically, the purpose of encryption is defeated, and the data is no longer secure and protected.

Tip

Don't lose your keys. Losing encryption keys is like losing the key to your house or car. The data is locked up, and there is no good way to get at it. Keys must be secured against theft and loss. Copies of keys should be kept in secure devices or locations.

Automated Encryption

Encryption can be automated in several ways. In some cases, encryption is built into software used to write and read data. A prime example of this is backup software. As described in Chapter 3, most backup software vendors have encryption available, either as a feature or as an add-on product. When data is encrypted automatically, it becomes less of a target to an attacker, who can't use it.

Another method of automatically encrypting data is through use of a hardware device, either as an appliance or embedded in a storage device. These devices tend to be much faster than software devices. Another advantage over software encryption is that the devices exist outside the host and are not compromised if a host is. It takes additional attacks to get at the encryption device itself. Finally, one device can act to encrypt data for many hosts, centralizing key management and other security functions. Many encryption devices are also including authentication functions, as well as adding a layer of security to the storage system.

The downside of automated encryption is that a large amount of data is now accessible only if the software or hardware device is also available. Device or host failure can render data inaccessible.