Network security implications of IP SANs

IP storage area networks pose challenges that may be new to network, storage, and security administrators.

By Tom Petrocelli

Click here to enlarge image

The emergence of IP-based storage area networks (SANs), especially those based on the iSCSI protocol, promises to be a boon to IT managers. The potential for gaining the benefits of SANs at a lower cost and with greater ease of implementation is the main attraction of IP SANs. Another benefit that has been suggested is improved security. Since iSCSI runs on the well-known IP protocol, all of the advances in security that have been applied to IP will now be available for iSCSI-based SANs.

However, IP SANs have security issues that are not shared by Fibre Channel or general IP networks. Network and storage security professionals need to address these issues.

Fibre Channel networks have the advantage of being a completely different type of network, with few people having the skills necessary to breach them. They also benefit from being three levels deep into the system infrastructure, sitting behind the network and host servers. To access a Fibre Channel SAN, an external intruder would need to breach the network perimeter with its array of firewalls and intrusion-detection systems.

Next, he/she would have to compromise a host to gain access to storage-related applications, utilities, or low-level SCSI commands. While this is not impossible and should be considered when designing security policies, these actions require a high level of skill as well as an understanding of SCSI and Fibre Channel SANs. With IP SANs, the protection of the host has been removed and the storage devices are directly exposed to the network.

IP networks are vulnerable

The first area of concern for security administrators of IP SANs is the reliance on IP infrastructure to provide access to primary storage. IP networks are vulnerable to a variety of attacks. The skills to do so are widely held. One of the more vulnerable areas is the directory and naming services, such as DNS, that IP networks and IP SANs rely on. iSCSI and other IP SANs need to be able to find resources based on names rather than IP addresses. Otherwise, managing an IP SAN will quickly become an administration nightmare. If the directory and name service is attacked, then the storage may become unavailable to servers since they will no longer be able to find devices on the network. That problem does not exist for other forms of block storage.

Direct-attached storage normally needs fixed SCSI or IDE addresses or addresses assigned by the server to which the storage is attached. With Fibre Channel SANs, the naming service is contained within the switches. These are internal processes that are relatively hard to hack, other than through the management interface.

Management interfaces are usually attached to completely separate LANs for just this reason. Attacking the Simple Name Service in a Fibre Channel fabric requires detailed knowledge of Fibre Channel. With IP SANs, conventional network attacks can now also be levied against the storage infrastructure directly.

Other parts of IP infrastructure are also vulnerable. For example, if an intruder changes routes on the network, access to storage may no longer be available. IP networks are often disrupted by these types of attacks. This may now lead to loss of a connection to a block I/O device, a situation that often causes application failure. In short, IP SANs increase the need for security vigilance.

Spoofed addresses

With iSCSI, administrators need to take care when relying on typical access control and authentication mechanisms. Authentication for iSCSI is host-based rather than user-based. This allows a hacker using a spoofed address to gain access to the IP storage device, without the additional challenge of obtaining root (or similar) access. At that point the intruder could read and write data with the same privileges as the spoofed host. On a Fibre Channel network this would require that a box with an altered host bus adapter be placed physically on the network. With IP SANs this type of attack can be launched from anywhere inside or outside of the corporate network. The use of spoofed addresses opens up the storage infrastructure to other conventional IP attacks, including "man-in-the-middle" attacks.

One might argue that since IP SANs tend to be named services rather than relying directly on IP addresses then this is not much of a threat. However, this is not true for two reasons. First, even when services are accessed via a name (in the same way URLs provide names for Internet-based services), they ultimately resolve to IP addresses. These can be captured and spoofed.

Second, there are several known attacks directed at DNS that place false IP addresses into DNS databases. Using this method, a hacker would be able to change a known, trusted name to another IP address.

There is an assumption that all IP SAN security problems can be eliminated or mitigated by the use of Virtual Private Networks (VPNs) and other common IP security mechanisms. VPNs provide a secure connection over a public network by using encryption. Often, VPN servers contain some form of filtering so as not to pass an attack along in an encrypted data stream from a compromised host.

Unfortunately, VPN servers and appliances do not yet understand block I/O storage protocols. They cannot scan iSCSI packets and so, depending on the security of the system, will either deny all iSCSI traffic or pass all iSCSI traffic. Neither is a good option. Worse yet, use of encryption and VPNs is optional with iSCSI and may be turned off for performance reasons, which would eliminate even the moderate benefits offered by VPNs for iSCSI SAN security.

The same is true for other IP network security products. Recent advancements in application firewalls have greatly enhanced network security. The ability to look at application protocol packets and determine if they are being used to attack a system has increased system security immensely. Unlike TELNET, HTTP, and FTP, no one supports SCSI or iSCSI. This is true of intrusion-detection systems, too. As with the VPN server, application firewalls will either deny or permit all iSCSI traffic depending on rule sets, but they have no way of discerning valid from invalid traffic.

Assuming that no one architects his/her IP SAN to access devices over the Internet, iSCSI devices may still be attacked from inside the corporate network due to a compromised host or disgruntled employee. Wireless access points that lie inside the corporate firewall (which is not a good idea but a common practice) also make for inviting entry points to the interior network. Either way, the lack of user-level authentication makes it much easier to launch an attack against the iSCSI devices, which network defenses and logs may not even notice until the storage is offline or the data is damaged.

One good example of a possible attack is an IP SCSI Inquiry attack. The SCSI Inquiry command is used to interrogate a SCSI device and discover what resources are available. This is a legitimate command. Sending thousands of them a second is not a valid use of the command. If an application firewall or VPN server could understand iSCSI, it would recognize that something is wrong and disallow subsequent commands from the same host to the same device. If the firewall or VPN server is designed to simply pass through the commands it doesn't understand, those thousands of Inquiry commands will hit the device and eventually overflow the command buffers. This is a simple way of launching a denial-of-service attack against an IP SAN.

Another feature of iSCSI that may cause security problems is the use of multiple TCP/IP connections to the same device. This allows a device to transfer large amounts of data more quickly than if it relied on a single TCP connection. Firewalls hate this. It is very difficult to scan data from a single data stream that is broken up into multiple connections. This is especially true if you are using a firewall that is trying to keep track of individual application data streams.

It is tempting to say that none of this matters since no one in his right mind would run iSCSI traffic over a public network like the Internet. Firewalls, intrusion-detection systems, and other security devices are not only used to secure traffic to and from the Internet. They are also used to secure sections of internal networks. Traffic moving over leased lines still needs to be secured and monitored since it is passing through someone else's network. This is especially important for network connections to partner organizations, such as suppliers, that terminate in a different organization.


The other side of the IP SAN equation is IP SAN hosts. One real benefit from IP SAN technology will be the ability to connect less-expensive servers, usually based on Linux or Windows, to an existing Fibre Channel SAN in a less-expensive manner. It is likely that many such servers would be aggregated together on a handful of SAN ports since throughput requirements are likely to be less than for hosts attached directly to a Fibre Channel SAN.

To accomplish this, an Ethernet adapter that supports a protocol such as iSCSI would be placed in the host and cabled to the network. It would have connectivity to a Fibre Channel SAN via a gateway product (also on the IP network) such as a stand-alone IP SAN border switch or an iSCSI blade in a Fibre Channel switch. The gateway box or blade provides an opportunity to provide enhanced security. Since each packet has to be cracked open and converted to Fibre Channel frames, software in the gateway can provide filtering and authentication. It is also possible to detect bad behavior such as many SCSI Inquiry commands from a single IP address, traffic coming from an "untrusted" host, or some type of malformed SCSI command. New generations of intelligent SAN switches may do this if customers demand it.

Real danger comes from the host, itself, although it is no worse than if the host were connected directly to a Fibre Channel SAN. If the host is compromised, the hacker will have access to the SAN and any data that is accessible from that host. Where the hosts are in the LAN architecture is more important. If hosts are on a general LAN, then there is potential for them to be breached from an external attacker. If they are placed on their own LAN connected to the main LAN through a packet-filtering router, then they are safer. Isolation is key to good IP SAN security.

Policies and practices

There are some simple things that can be done to safeguard IP SANs. While it would be helpful to have features such as user-level authentication and iSCSI packet filtering, these are not currently available. Instead, consider the following:

  • At the very least, keep IP SAN devices on a physically separate network. Duplicate the key advantage of the Fibre Channel network: its physical separation from the IP network.
  • Use dual-homed hosts so that end-user clients do not have a direct path to the IP SAN devices. While an attacker might still get to the SAN via a compromised and trusted host, at least there will be no direct network connection to the interior or public networks.
  • Do not leave TELNET, FTP, HTTP, or SNMP ports open to network segments outside the IP SAN. Management access should only be allowed to systems within the dedicated IP SAN, with no other connection to the outside world.
  • Place a packet-filtering firewall between the IP SAN and the hosts. By restricting access to the IP SAN storage devices you can make it more difficult for an internal attacker to access the devices. Configure the filtering rules to only allow traffic to and from specific IP SAN ports and addresses. Keep overall posture as DEFAULT DENY.
  • Give the SAN its own DNS and RADIUS servers. Place a DNS server on the inside of the SAN firewall and allow traffic to it to only come from the SAN and the hosts that are connected to it. The only traffic outside the dedicated network would be DNS entry updates. Use an unusual port rather than the well-known DNS port.
  • If possible, keep the hosts themselves on their own dedicated subnet, accessible to other networks through a firewall. In this way access to the SAN would be limited to ports used by the applications on the hosts, but not to ports that the IP SAN devices themselves use. Using a firewall to create a perimeter between the hosts and devices is also a good idea. Once again, overall posture is DEFAULT DENY.
  • Do not allow direct access over the Internet. Even a VPN is dangerous in this circumstance. Allow user traffic via VPN to access the hosts; then have the protected hosts access the storage through the inside firewall.
  • Do not use multiple connections. Unless you are 100% sure that your firewall and intrusion detection system won't be confused by multiple TCP connections, disallow this option and take the performance hit.
  • Treat hosts attached to the IP SAN as if they were bastion hosts. Configure them with only the software needed to run their applications and host-level security.
  • Use firewalls that support Network Address Translation (NAT) to hide the real addresses and port numbers of the IP SAN devices from the outside world. This is especially important if you cannot use a dedicated DNS server.
  • Try to deploy products that can understand iSCSI or other IP SAN protocols. At the very least, demand that application firewall and intrusion-detection system vendors support iSCSI.

These are not new concepts to anyone used to securing network assets. What is unusual is having to secure storage assets this way since they are protected behind interfaces different from the rest of the IT infrastructure. The outcome of a security breach of an IP SAN is also different than other types of breaches. Since many servers may share a single storage device in a SAN, an attack against a single disk array may cause applications on dozens of servers to crash.

IP SANs promise to bring SAN benefits to many environments where Fibre Channel SANs are too expensive. However, special security considerations need to be taken into account when you are planning and deploying IP SANs until security products catch up to this new technology.

Tom Petrocelli is president of Technology Alignment Partners (www.techalignment.com), a research and consulting firm in Williamsville, NY.

This article was originally published on March 01, 2004