Pop quiz: Which presents the most security problems: network-attached storage (NAS) or a storage area network (SAN)?...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Careful, like those tricky SAT questions, the most obvious answer sometimes isn't the correct one.
|Storage security terms|
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
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:
- Use port-based zoning on all zones and ensure you have physical control over your switches.
- Use WWN-based zoning, but don't put hosts with different security levels on the same SAN.
- Investigate one of the newer, certificate-based authentication systems that are starting to come onto the market.