Lock the back door

In the last installment of our three-part security series, this article discusses SAN management interfaces, which can give a stealthy hacker an easy way to sneak in and potentially damage your data.

This Content Component encountered an error
This Content Component encountered an error
This article can also be found in the Premium Editorial Download: Storage magazine: Low-cost storage pieces fall into place:

With an amazing number of people leaving the back door of their storage area network (SAN) wide open, it's really time to start thinking about your SAN management interfaces.

If you haven't been following this series over the last two months, here's a quick review. There are five different elements to security. Authentication confirms you are who you say you are. Authorization ensures you're allowed to do what you're trying to do. Integrity makes sure that if you do access it, the data will be what it's supposed to be. Encryption ensures that if someone who isn't supposed to see it does see it, they won't be able to read it. And auditing is a way of double-checking all of the above.

Six Ways to Secure Your Storage
1 Start thinking about security with regards to storage.
2 Start making security a priority when you talk to your storage vendors.
3 Use port-based zoning or port binding--not world-wide name (WWN)-based zoning.
4 Use hardware-enforced zoning.
5 Move your management interfaces off the corporate LAN.
6 Place another layer of security on top of the management interfaces by requiring administrators to access them by going through another server via an encrypted tunnel.

I've also said that storage networks created a much easier way for one server to access another server's data. And storage networks have given hackers a new way to get to your data. They may attempt to to steal it, corrupt it or they may simply try to block your access to it.

Last month's article concentrated on how different zoning methods can change your security level. Proper zoning is a protection method against in-band attacks--attacks from within the storage network. If you're using world-wide name (WWN)-based zoning, a hacker that has access to the storage network might get a server's host bus adapter (HBA) to masquerade as another server's HBA and access a given zone. Port-based zoning prevents that because the hacker would need to physically move cables to access a given zone.

However, all zoning methods can be defeated by someone accessing the zoning configuration via the management interface--an out-of-band threat.

Circumvent your security
Management interfaces on Fibre Channel (FC) switches, storage arrays, network-attached storage (NAS) filers and other storage devices have something in common with the storage networks they manage. While they allow you to easily manage the storage resource from anywhere, they also give a hacker another way to circumvent your security. Here are some ways a hacker might use a management interface to access or damage your data.

Consider a SAN that's using port-based hard zoning. As discussed earlier, this means that only those servers physically connected to the appropriate ports can access the storage in a particular zone. If a given server attempts to access a storage array port not in its zone, it will be denied access. This is about as secure as FC gets these days. What might happen if a hacker gained access to the management interface of one of the switches in this SAN?

With most switches, all a hacker with access to this SAN's management interface needs to do is to add a single WWN to this port-based zone. Now the hacked server has access to the entire zone. Additionally, some switches automatically switch to soft zoning if you use even a single WWN as the member of a domain. The assumption is that if you're using WWN-based zoning, you're not concerned about security.

The hacker would have full access to your data--credit card numbers, secret sauce documents, engineering drawings, future company plans, personnel records--once this has been done.

Denial of service attacks
What if the hacker simply wants to cause a denial of service (DOS) attack? There are a number of ways to do that. In the above scenario, the hacker could do all sorts of damage if they have write access to a given file system. What if they simultaneously deleted every control file from every Oracle database in your environment? Do you know how little fun it is to recover after losing a control file?

The hacker could also delete all storage arrays from every zone, causing all servers to lose access to their data. Before doing that, the hacker could change the password on the switch so you couldn't log into it. That way, you wouldn't be able to determine that the zoning configuration had changed--let alone fix it.

Another DOS attack might be to use the management interface to a storage array, and delete (or reverse) the LUN masking setup from that array. All servers would lose access to their data, wreaking havoc in your data center.

Even worse might be a hacker that doesn't do something catastrophic. What if they just temporarily took access away to a given server, then returned everything to normal a few minutes later? If they permanently took away all access to a given storage array, you might discover too quickly that it's a storage array and go investigate. What if it's a disgruntled employee--or ex-employee--and wants to just keep causing you pain? Intermittent outages that magically fix themselves would cause you and your management to lose all faith in your SAN, and may result in many angry phone calls to SAN vendors that haven't done anything wrong.

Protecting management interfaces
That's why you should protect these management interfaces more than most people are protecting them today. In far too many cases, storage administrators connect their storage devices' management interfaces directly to the corporate LAN, and often don't even change the default password.

Anyone with access to your corporate LAN could access your storage devices if they knew the user name and password. The password is either easily guessable, or easy to determine with a network sniffer. This is because most management interfaces use plain text protocols, such as Telnet or HTTP--instead of SSH or HTTPS. Anyone with a LAN card could potentially sniff the network, capture your login session and gain the only secret they need: the user name and password.

What can we do about these issues? There are two answers: The long-term answer is to start communicating with your storage vendors that security is essential. Tell them that they should offer secure management interfaces such as SSH or HTTPS, and then start supporting vendors that do so. There are already storage vendors that offer management interfaces that don't use plain text protocols. Find out who they are, and start buying from them--and tell the vendor that you didn't buy from why you didn't buy from them. Money talks.

The second answer is to install another layer of security. Place your management interfaces on a separate, nonroutable LAN. Take a multihomed Linux box and connect one interface to this nonroutable LAN, and another to your corporate LAN (make sure the Linux box isn't routing that subnet). All plain text protocols must be deactivated on the Linux box so it's only reachable via SSH.

If your storage resource is managed via Telnet or SSH to the Linux server, then Telnet to the storage resource. This way, your plain text Telnet password will be encrypted inside your SSH session. This protects the password from being guessed. SSH protects its own password because it's already encrypted.

If your storage resource is managed via HTTP, set up SSH to tunnel the X protocol, SSH to the Linux server, set your display back to your workstation and run the Web browser from the Linux server. Again, the X session will be encrypted inside the SSH tunnel.

If you're managing your storage resources via some type of client software loaded on Unix, load the client software on the Linux machine. If your vendor doesn't support Linux, you may have to use a Solaris server for this job. Again, SSH to the server and tunnel your X session back to your workstation through that SSH tunnel.

On the other hand, if you're using Windows-based client software, this security exercise becomes more difficult. Replace the Linux system with a Windows system. Load the client software on that machine, and access the console either directly or via some other secure method.

If you need to find a secure method to run a Windows console remotely, try this: Instead of plugging the second interface of the Windows machine into your corporate LAN, plug it into one interface of a multihomed Linux machine, then plug that machine's other interface into the corporate LAN. Next, install RealVNC server software on the Windows machine and a RealVNC viewer on the Linux machine. When you want to access the Windows-based client software, SSH to the Linux machine, set your display to your workstation and use RealVNC to access the Windows console securely.

Yes, all of this is extra work. Being secure always takes extra work. But you will be glad to know that these extremely important management interfaces are safe.

This was first published in October 2003
This Content Component encountered an error



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: