Protect your SAN from attack

Think your SAN is secure? Find out the truth by reading Part 1 in our three-part series on storage security.

Pop quiz: Which presents the most security problems: network-attached storage (NAS) or a storage area network (SAN)? Careful, like those tricky SAT questions, the most obvious answer sometimes isn't the correct one.

Storage security terms
Authentication is the process of verifying an entity's identity by asking questions such as: Is this server's name really Elvis? Is this disk drive really drive number XYZ?
Authorization determines which rights an authenticated entity possesses: Is Elvis allowed to read or write this block of data to this disk or tape?
Encryption protects information from unauthorized access by converting it into an unreadable and random format that can only be accessed through appropriate credentials and/or keys. This ensures that if an unauthenticated, unauthorized server were to read a given block of data, it would be unable to use that data for any purpose. This includes encrypting user names and passwords that are used for out-of-band management of your storage area network (SAN).
Auditing is the ability to capture and retain data about certain events. In storage networks, auditing would require a record of which hosts requested which blocks of data, as well as the methods by which those hosts were authenticated.
Integrity is the assurance that an entity hasn't been modified in any way to undermine the authenticity of the entity. If Elvis writes a block of data to a disk drive and then reads that block of data minutes, hours or days later, integrity ensures that the block looks the same as it did when Elvis wrote it.

NAS' vulnerabilities, namely NFS and the common Internet file system (CIFS)--which allow someone to search another computer for a file--are well known to hackers and those whose job it is to foil their efforts. In contrast, the biggest security issue with Fibre Channel (FC) is many storage administrators feel it's a safe network and only the bad guys are currently aware of its security issues.

Obviously, if a network has no authentication (see "Storage security terms") all other areas of security are moot. There's no point in creating different levels of authorization if any entity can simply lie about its identity. For example, encryption is meaningless if anyone can pretend to have a key. An audit wouldn't reveal much if the system was compromised--the audit might also be compromised. And you have no ability to verify the integrity of your data.

Prior to the advent of FC, each storage network consisted of direct-attached SCSI drives that could only be reached via the SCSI interface to which they were attached. To compromise the data on a disk or tape drive, a hacker first needed to compromise the host. If the attack on the host was successful, the hacker only has access to that host's data. Unless remote shell (rsh) was enabled without a password, a hacker couldn't hack into one host and reach another host's data--each host had to be hacked separately. Therefore, a storage administrator could establish hosts with different security levels on the same LAN because compromising one host didn't equate to compromising all hosts.

However, depending on the configuration, it's possible to access one host's data from another host if both hosts store their data on the same SAN. If one host is compromised and it's able to see the other host's disks via FC, a hacker can access the other host's data. Depending on their motivation, hackers could also compromise the other host via its storage. In fact, there are a bunch of attacks that are possible if one compromised host is able to access another host's storage. These attacks range from stealing data that wasn't intended for the recipient to basic denial of service (DoS) attacks. A disgruntled employee could compromise data by:

  • Mounting another system's data drive(s) on the compromised computer and accessing sensitive information such as customer databases, personnel files and engineering drawings
  • Mounting another system's data drive(s) on the compromised computer and simply obliterating the contents via commands such as copy, format, dd, delete and rm
  • Mounting another system's operating system drive on the compromised computer and viewing password files to run crypt against them
  • Mounting another system's operating system drive on the compromised computer and modifying configuration files to get access to the new computer
  • Mounting another system's operating system drive on the compromised computer and obliterating and/or corrupting the contents, resulting in a DoS
  • Mounting home directories from one server to a compromised server or placing Trojan horses in other users' profile files, resulting in the user performing unknown tasks the next time they log in
Another potential source of data theft is unsecured backup tapes. The integrity of your off-site storage vendor is critically important. In my book, Unix Backup and Recovery, I wrote about the importance of doing random checks on your off-site storage vendor. You can request an onsite visit, and then make up some wild story about this incredibly huge project that requires pulling hundreds of tapes. Tell the vault vendor they're more than welcome to stay with you, but you're going to be in there for hours. Their help isn't really necessary. If they leave you alone in the vault with other customers' tapes, fire them immediately and move all of your tapes to another vault. If they'll leave you with someone else's tapes, they'll leave someone else with your tapes. A hacker only needs to find one hole in your security.

FC networks are extremely insecure, but there are ways to make them more secure. The first thing is to change how zoning is done. Most people use soft zoning because most soft zoning is implemented using world wide name (WWN)-based zoning. In WWN-based zoning, the members of the zone are specified using the WWNs of the host bus adapters (HBAs) that belong in the zone. For example, HBA1, HBA2 and HBA3 are members of Zone ABC.

Port-based zoning is where the members of a zone are specified by the physical port on the switch to which they connect. For example, everyone connected to ports 1, 2 and 3 are members of Zone DEF.

The reason most people use WWN-based zoning is because it makes moves, adds and changes much easier. When you need to physically move a server from one switch to another, it doesn't require a change in your configuration. However, if you specified the members of the zone based on the port to which they are connected, then you'd have to change your zoning configuration if you moved a server from one port to another or from one switch to another.

Why is zoning a security issue? A zone is what gives certain servers access to the disk or tape drives on the SAN. If you use port-based zoning--the more secure of the two types--someone would need to gain physical access to your switch in order to spoof membership to a given zone, and thus read the data within that zone. If you used WWN-based zoning, they'd only need to spoof the WWN of the intended recipient to gain access to the zone. It's pretty easy to spoof a WWN: It's built right into the HBA driver.

The WWN is analogous to the MAC address on an Ethernet card. While changing the MAC address on an Ethernet card takes a bit of skill, changing the MAC address of an HBA is often built right into the driver. Why would vendors do this? Believe it or not, they did it to make things easier on you. If you are using WWN-based zoning--which most people use--what happens if you have to replace an HBA, disk or tape drive? You have to redo your zoning. Therefore, they built it right into the driver to be able to change the new HBA to the WWN of the old HBA.

However, this creates a serious vulnerability if one of the hosts on your SAN is compromised. If the hacker is able to obtain (or guess) the WWNs of other HBAs on the SAN, they'll be able to change the WWN of the HBA on the compromised host, then join any zones they want to join, therefore gaining permission to read or write to any disk on the SAN. Of course, the drives might have a SCSI reserve on them, but a simple SCSI bus reset will fix that.

One quick way to thwart this hacker is to:

  1. Use port-based zoning on all zones and ensure you have physical control over your switches.
  2. Use WWN-based zoning, but don't put hosts with different security levels on the same SAN.
  3. Investigate one of the newer, certificate-based authentication systems that are starting to come onto the market.
Part 2 of this series will will help you find what's best for you: soft zoning, WWN-based zoning, port zoning or hard zoning. Look for it in the next issue.

Dig Deeper on Storage management tools

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.