|
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.
Ev...
To continue reading for free, register below or login
To read more you must become a member of SearchStorage.com
en 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.
|
 |
|
