Iomega NAS iSCSI Issues
by Seth Miller
A few months ago, we bought a low end NAS to supplement our SAN and DAS which are in a perpetual state of emergency. I love having a NAS for obvious reasons and it has helped immensely by moving non-critical, non-transactional data off of our primary storage.
The model we have is an “Iomega StorCenter Pro NAS ix4-200r”. Fancy title. It’s four 2TB sata drives in a RAID 5 giving 5.5TB of usable disk. It is a sort of unified storage platform in that it can also do iSCSI and torrent hosting alongside NFS/CIFS.
We had a big boo-boo a couple of months back with the iSCSI. I am familiar with iSCSI because of my experience on our SAN which is EqualLogic. EqualLogic was acquired by Dell a few years back and is strictly an iSCSI product. EqualLogic SANS are relatively easy to set up and manage, but do include fairly extensive security settings for the iSCSI volumes. Along with filtering on IP, you can specify that only a certain initiator can connect and if that’s not enough, you can specify a two-way CHAP security.
The file share security on the Iomega NAS is pretty basic in that you can filter on which IP and which users can connect to which share as well as quotas on the shares. For the iSCSI block storage though, there is no security whatsoever other than limiting which users can log in to the NAS GUI and have access to those volumes. Any server with an iSCSI initiator and knowledge of the NAS IP, can connect and mount up all of the enabled iSCSI volumes.
Do I know this because I read the manual from front to back before racking the NAS? No, we learned the hard way.
We had an Oracle database that was about to exceed the free space on the direct attached storage in its server. This was a data warehouse database and did not need fast disk for this particular tablespace. I created an iSCSI volume and mounted it to the Windoze server that was housing the database. I added the volume as another drive and created a file for the tablespace. Works great!
Another group in the company was looking for additional disk and asked for an iSCSI volume for their server. I went about creating it and told them it would be ready later that afternoon. The NAS takes a couple of hours to format a 100GB volume for iSCSI. Thirty minutes later, the database that just inherited the new file on the first NAS iSCSI volume I created crashed. When looking at the drive, the file and folder were gone. After a short investigation of the logs on the NAS, it was discovered that another server had mounted the same iSCSI drive that was housing my Oracle database’s data file. They had mounted the volume, wiped and created a new partition table and then low-level formatted the entire volume.
It turns out that this other group saw a iSCSI volume from the same location they had asked for it, with the same size they had requested and assumed that I had overestimated the time it took to create their drive. They took the opportunity to mount it, fdisk the partition table (despite seeing an existing NTFS partition) and format it for their use. Yes they were wrong, but the mistake was understandable.
This post is a cautionary tale about lower end unified storage appliances and the security (or lack thereof) they offer on their storage. Be aware of who has access to what with your shared storage appliances.