Chapter 11
Storage Area Network Security
Abstract
This chapter talks about how to best secure your storage area network. This chapter talks about general solutions and tries to avoid storage array specific topics.
Keywords
storage array security
zones
LUN assignments
Information in this chapter
• Securing the Array
• Securing the storage switches
Securing of the data does not end with the Windows server which runs the SQL Server service. It also includes properly securing the storage array and the storage area network. Because each storage array and switch vendor does things differently this chapter talks only about basic concepts instead of providing specific walk through information for specific platforms.
Securing the Array
Data security does not end with the SQL Server service or the Windows OS. There are plenty of other ways that an intruder could access the data which is stored in your SQL Server database. One potential attack vector is the storage array itself. This can be done through a variety of techniques which include the following.
• Logging into the storage array
• Disks being presented to multiple servers
• Snapshots being presented to servers
• Accidental LUN (Logical Unit Number) deletion
• Accidental removing of LUNs
• Attacking the OS of the storage array
Locking Down the Management Ports
Storage arrays are simply powerful computers which have large amounts of storage connected to them (granted there is often some custom hardware in there). Storage arrays are configured in such a way that they can present storage to multiple servers, typically over a dedicated network. These networks can either use fiber channel or iSCSI in order to present the storage from the storage to the server. These storage arrays may run typical operating systems on them such as Windows or Linux or other more custom OSs such as Cisco’s SAN-OS or FreeNAS. Older storage arrays did not have very strong storage authentication security or auditing capabilities built into them. Because of this it is highly recommended that the software which runs the storage array be kept up to date with the newest versions which are supported on the hardware platform. This will provide the greatest possible level of authentication by introducing more enhanced security processes into the storage arrays. This includes multiple storage admin roles allowing for logins which have minimal rights to the array such as read only rights, or security administrator rights where users only have the right to manage security but not the actual storage array itself.
While the storage arrays may run traditional operating systems on them, keeping this operating systems fully patched with the OS provided patches is typically not recommended. This because the storage vendor does not test every patch against their hardware. The only patches which should be installed on the storage array should be patches which have been approved by the storage array vendor. Typically the storage array vendor would publish the list of patches which can be installed via their website or bulletins which the vendor sends out. They only test specific builds of the operating system to be compliant with their hardware and software packages. Because of this it is recommended that the Ethernet ports which host the management of the storage array be configured on their own VLAN with access to connect to those ports limited to only the personal who need to manage the equipment and only via the specifically needed network ports. Many storage arrays are introducing integration features between the VMware vCenter server in virtualization environments which use the VMware platform. Due to this integration access between the vCenter server and the storage array would also be needed. While each storage array may need different TCP ports open between the administrators and the storage array typically the storage array communication is done over TCP ports 80 (http), 443 (https) and/or 22 (sh). Check with your storage array vendor to find out exactly which network ports are required to be opened for this software to function as expected.
Some storage arrays will run software on the servers which are connected to the servers to assist in the failover from one storage processor to another within the storage array. This software will need access to the storage array, typically via the management ports on specific TCP ports. These ports will need to be opened between the servers and the storage array, often in both directions. Consult with your storage vender to determine which TCP ports need to be opened and in which direction.
The management ports for the storage array should never be connected to the public Internet; no matter how much security is in place on the storage array.
Authentication
Every administrator who needs access to the storage array should have their own login, preferably one which is tied directly to Active Directory. There is always a default login on the storage array, typically called admin, administrator, or root (the username may vary depending on the storage array vendor which you use) which should be secured with a very long, secure password and which should never be used. If possible the username for this account should be changed and recorded. This account should not be disabled, especially if all other accounts are using Active Directory for authentication because if there is a problem with using Active Directory for authentication you do not want to lose connectivity to the storage array.
User Access to the Storage Array
It should go without saying that only currently employed systems administrators who are qualified to manage the storage array should have logins to the storage array. All accounts on the storage array should be either configured with very strong passwords, or preferably configured to use Active Directory logins so that the authentication is handled by the Windows Active Directory domain allowing for the logins to be disabled automatically when the employee leave the company. In the event that an employee who has rights to the storage array leaves the company their account should be immediately disabled to prevent any accidental logins to the storage array.
Locking Down the iSCSI Ports
If the storage array supports iSCSI then there are additional Ethernet ports which should be secured to prevent a potential attacker from attacking the iSCSI target on the storage array. The only TCP port which should need to be accessed on the iSCSI ports on the storage array is TCP ports 860 and 3260. Access to any ports besides this TCP port should be blocked from any computer on the network and access to any TCP network ports including ports 860 and 3260 should be blocked from any IP address which is not a computer on the iSCSI network. This includes admin workstations, other server IP addresses, etc. If possible the iSCSI network should be totally isolated with no network routes from the iSCSI network to the rest of the company network to prevent users from accessing the iSCSI ports of the servers or the storage, and to prevent any possible network flooding with the data from the iSCSI network.
Fiber Channel over Ethernet (FCoE) ports are not as susceptible to this sort of attack because they do not use traditional IP (Internet Protocol) Addresses on the FCoE ports like iSCSI ports do. While FCoE ports use the same kinds of Ethernet cables as iSCSI and traditional networking the data is transferred using the Fiber Channel protocol instead of using TCP (Transmission Control Protocol).
LUN Security
LUNs should be configured in such a way that they can only be presented onto a single server (or cluster when using clustering) at a time. By default LUNs are presented to servers in read/write mode which allows the LUNs to be written to by the server. However it is possible to present LUNs to an additional server or servers where the other server(s) could have the LUN mounted as a read only LUN. This would allow this server to read all the files from the LUN without the source system knowing that this was happening. In the case of SQL Server database files which are normally locked for exclusive use by the SQL Server service, this locking would not be honored on the additional server(s) which had the LUNs mounted in read only mode as the OS of the additional server(s) would not know about the request to lock the files. This would allow someone who was logged into that LUN to copy the database files to another disk or server, or upload the files to their favorite file sharing site so that they could later attach the database files to a SQL Server instance and get the information from the database.
If LUNs were incorrectly mounted to multiple servers at once in read/write mode and more than one server attempted to write to the disks, which Windows will often do as soon as the drive is opened in the “My Computer” window, the file system on the LUN can become corrupt causing all the data which is on the LUN to instantly be lost.
Moving LUNs
Whenever a LUN is being moved from one server to another, extreme care must be taken to ensure that the LUN is only presented to one server at a time. It only takes a few seconds for the file system of a LUN to become corrupt and typically the only way to restore is from a full backup typically requiring hours of downtime.
Deleting LUNs
When a LUN is being removed from a server and the LUN is being deleted the storage administrator and the database administrator need to work together to ensure that only the correct LUN is removed and deleted. Whenever possible LUNs should be removed from the server and placed into a holding area for at least a couple of days to ensure that the correct LUN was removed before the LUN is deleted. This is because storage arrays do not have a recycle bin like Windows does. When the storage array is told to delete the LUN there is typically a single confirmation followed by the LUN being completely deleted. Once a LUN has been deleted the only way to recover the data would be from a backup.
Snapshots and Clones
Snapshots and clones should be carefully protected within the storage array. These virtual LUNs contain copies of the data from the source LUN and the snapshots and clones can be presented to other servers for reading and writing. This can lead to someone copying the data from the snapshot or clone without ever needing to touch the production LUNs. Snapshots and clones should only be kept around for as long as needed for space, performance and security reasons.
Securing the Storage Switches
The storage switches which pass the storage network traffic should be secured to prevent someone from watching the storage traffic or reconfiguring the network switch to redirect a copy of the storage traffic to another machine. While this is easiest to do in iSCSI and Fiber Channel over Ethernet (FCoE) environments as in these cases the network traffic is using more traditional Ethernet switches, it is possible to do this in a traditional Fiber Channel environment.
Fiber Channel
Within fiber channel networks the risk of an attacker viewing data which is being passed across the fiber channel switch is minimal as to do so the attacker would need to be able to physically connect a fiber optic cable to the fiber channel switch. If the attacker is able to get into the data center and connect a computer to the fiber channel switch using a fiber optic cable the attacker could configure the fiber channel switch for port mirroring. Like the name sounds port mirroring is a special configuration where every bit of data which is sent to the port which is being mirrored is duplicated and is also sent to the second port which was configured to be the mirror. Data capture software can then be run on the machine which is connected to the mirror port which would then receive and store all the data which is being sent to the port. An example of a network switch is shown in Figure 11.1 which shows a storage array connected to port 1 and port 2, and servers connected to ports 3, 4, 5, and 6. The attacker then connects to the network switch and configures port 3 to be mirrored to port 10 which the attacker has connected a laptop to.
Figure 11.1 Showing a fiber channel switch.
In the configuration shown in Figure 11.1 the attacker would see all reads and writes which were made between the SQL Server connected to port 3 and the storage array which is connected to ports 1 and 2.
iSCSI
iSCSI network traffic is a little easier to intercept than fiber channel traffic by an attacker. While the attack vector is the same, using port mirroring, Ethernet switches have had port mirroring for a much longer period of time. In additional to this it may be less suspicious looking within the data center to have a laptop connected to a network switch than it would to a fiber channel switch.
There are some Ethernet switches which have implemented a virtual Ethernet port which can be used for port mirroring which would then allow the attacker to not need to be physically connected to the network switch in order to configure the port mirroring. The virtual Ethernet port would then be configured to redirect the network traffic to a different IP address on the network, potentially allowing the attacker to place the device anywhere on the network, possibly even on the Internet at another site if the virtual port was configured to route the network traffic to a public IP address.
Because iSCSI uses TCP as the protocol for the data transfer between the server and the storage array, any TCP data capture application can be used on the attackers computer to capture the iSCSI traffic from the mirrored port and safe it to disk.
Fiber Channel Over Ethernet
Capturing Fiber Channel over Ethernet (FCoE) is the hardest method of exchange to capture data. While the same port mirroring which can be used to capture iSCSI traffic is possible Fiber Channel over Ethernet traffic is not transferred by TCP like the iSCSI traffic is. There for the data being transferred by the fiber channel protocol cannot be simply rerouted like the iSCSI traffic can. Instead the same kind of fiber channel capture software that would be used for a fiber channel switch must be used, and the device must be directly connected to the FCoE switch. Because Fiber Channel over Ethernet is not a routable protocol there would also be no need to connect the Fiber Channel over Ethernet switches to the rest of the routable network which would also cause the attacker to need physical access to the network switches in order to connect and capture the data.
Management Ports
No matter the technology to get from the servers to the storage array, the switches which handle the transport will have management ports. These management ports should be isolated from the rest of the network with only the users who need to manage the switches having access to the network ports. This access can be blocked at the switch level through the use of Access Control Lists (ACLs) or via a firewall between the subnets which the general company users are on and the subnet which the management ports for the switches are connected to. Like the storage array management ports these ports should not be connected to the public internet.
Authentication
Ever administrator who needs access to the switches which carry the storage traffic should have their own login, preferably one which is tied directly to Active Directory. There is always a default login on the switches, typically called admin, administrator, or root (the username may vary depending on the switch vendor which you use) which should be secured with a very long, secure password and which should never be used. If possible the username for this account should be changed and recorded. This account should not be disabled, especially if all other accounts are using Active Directory for authentication as if there is a problem with using Active Directory for authentication you do not want to lose connectivity to the network switches.
Zone Mapping
The zone mapping or zone configuration files are what tell fiber channel switches which ports are allowed to talk to which ports within the fiber channel storage area network. These zone files should be backed up and stored in a location other than the default location within the switches in the event that an attacker was to break into the switches and damage or erase the zone configuration. Without the zone file the fiber channel switch would have no idea which servers were allowed to talk to which servers and would prevent all traffic within the switch. Having a backup of the zone file stored outside of the switch would allow for this mapping to be quickly put back in place after an attack.
Summary
There are a variety of attack vectors which an attacker can use to gain access to data or to cause problems within the storage environment. This includes attacking both the storage array as well as the switches which pass the traffic from the servers to the storage array. While using encryption (as talked about in Chapter 2) can make any data which was captured useless, if an attacker can get into the system to gather data they can get into the system to reconfigure the system to prevent reads and writes from functioning as expected causing major system downtime which can be very hard to troubleshoot.