2015-08-15 // Dell EqualLogic PS Series - Security
An initial setup is always a good opportunity to take a more in-depth look at systems, while they are not yet in production. In this case i'm looking at one of the advertised security measures of Dell EqualLogic PS Series systems.
We're currently in the process of implementing iSCSI-based Dell EqualLogic PS Series systems. Specifically we're using PS-M4110E and PS-M4110X models in several Dell M1000e blade chassis. The EqualLogic storages and the hosts they provide storage space for are being connected with PowerConnect M8024-K switches. The switches are located in the slots B1 and B2 of the blade chassis and are dedicated for iSCSI traffic with 10 gigabit ethernet.
Although the separation of SAN and LAN could be considered enough security, i was really pleased to read in the Dell EqualLogic Group Manager Administrator's Manual - PS Series Firmware Version 7.0 (110-6152-EN-R1) that the folks at EqualLogic thought otherwise and added further security measures in order to protect the EqualLogic PS Series systems from unauthorized access to its management functions over the iSCSI network. A quote from page 76 of said document reads:
[…]
About Dedicated Management Networks
For increased security, or if your environment requires the separation of management traffic and iSCSI traffic, you can configure a dedicated management network (DMN) that is used only for administrative access to the group. The management network is separate from the network that handles iSCSI traffic to the group.
- Without a dedicated management network (the default configuration), administrators connect to the group IP address for both administrative access to the group and iSCSI initiator access to iSCSI targets (volumes and snapshots).
- With a dedicated management network, administrators do not use the group IP address for administrative access to the group. Instead, administrators connect to the management network address. All iSCSI traffic, including traffic by replication partners, and access to Dell EqualLogic Auto-Snapshot Manager/Linux Edition (ASM/LE), Dell EqualLogic Auto-Snapshot Manager/Microsoft Edition (ASM/ME), and Dell EqualLogic Virtual Storage Manager for VMware (formerly ASM/VE), continues to use the group IP address. SAN Headquarters can connect to the group using either the management network address or the iSCSI address.
[…]
And further on page 78 of the same document:
[…]
When you complete the management network configuration, administrators cannot log in to the group using the group IP address. Instead, administrators must use the new management IP address. Any open GUI or CLI sessions using the group IP address eventually time out and close.
After configuring a dedicated management network, you might need to:
- Inform administrators of the new management network IP address.
- If you run the Group manager GUI as a standalone application and have a shortcut on the computer's desktop, the group address in the shortcut is not updated with the new management address. You must uninstall and then reinstall the GUI application.
- If you are running SAN Headquarters, you must update the group IP address in the application to the dedicated management address. For more information, see the SAN Headquarters documentation.
[…]
Judging from those two sections it would appear that the EqualLogic PS Series systems have no or at least a very small attack surface on the – potentially untrustworthy – host-facing network dedicated to iSCSI traffic. In open systems this is usually achieved by binding the services which are necessary for the management function to a specific network interface, instead of letting them listen on all available interfaces.
Using a DMN and thus separating the management traffic from the iSCSI traffic resulted in our case in the following configuration example:
group1-grp(member_group1)> eth show Name ifType ifSpeed Mtu Ipaddress Status Errors DCB ---- --------------- ---------- ---- ----------------------------- ------ ------ ------ eth0 ethernet-csmacd 10 Gbps 9000 10.0.0.1 up 0 off eth1 ethernet-csmacd 100 Mbps 1500 123.123.123.123 up 0 off
group1-grp(member_group1)> eth select 0 show _______________________________ Eth Information _______________________________ Name: eth0 Status: up Changed: Mon Jul 20 12:23:15 2015 Type: ethernet-csmacd DesiredStatus: up Mtu: 9000 Speed: 10 Gbps HardwareAddress: B0:83:FE:CC:52:C1 IPAddress: 10.0.0.1 NetMask: 255.255.0.0 IPv6Address: Description: group1 iSCSI Interface SupportsManagement: no ManagementStatus: normal DCB: off
group1-grp(member_group1)> eth select 1 show _______________________________ Eth Information _______________________________ Name: eth1 Status: up Changed: Wed Jul 29 08:33:35 2015 Type: ethernet-csmacd DesiredStatus: up Mtu: 1500 Speed: 100 Mbps HardwareAddress: B0:83:FE:CC:52:C2 IPAddress: 123.123.123.123 NetMask: 255.255.255.0 IPv6Address: Description: group1 Management Interface SupportsManagement: only ManagementStatus: mgmt DCB: off
Here the lines with the SupportsManagement options could be construed in the way, that management access is not possible over the eth0 interface, which in this configuration is the connection to the host-facing iSCSI network.
From previous lessons learned not to be overly trusty of lofty vendor promises, i decided to double check this with the simple use of the nmap network and port scanner. The results of the TCP and UDP port scans against both the member and the group IP address are shown below.
Member IP - TCP scan:
root@host:~$ nmap -sS -p 0-65535 10.0.0.1 Starting Nmap 6.00 ( http://nmap.org ) at 2015-07-15 11:14 CEST Nmap scan report for ******** (10.0.0.1) Host is up (0.000097s latency). Not shown: 9991 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http 443/tcp open https 2606/tcp open netmon 3002/tcp open exlm-agent 3003/tcp open cgms 3260/tcp open iscsi 9876/tcp open sd 20002/tcp open commtact-http 20003/tcp open unknown 25555/tcp open unknown MAC Address: B0:83:FE:CC:52:C1 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 107.66 seconds
Member IP - UDP scan:
root@host:~$ nmap -sU -p 0-65535 10.0.0.1 Starting Nmap 6.00 ( http://nmap.org ) at 2015-07-20 09:27 CEST Nmap scan report for ******** (10.0.0.1) Host is up (0.000086s latency). Not shown: 65532 closed ports PORT STATE SERVICE 0/udp open|filtered unknown 123/udp open ntp 161/udp open snmp 65519/udp open|filtered unknown MAC Address: B0:83:FE:CC:52:C1 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 2.55 seconds
Group IP - TCP scan:
root@host:~$ nmap -sS -p 0-65535 10.0.0.2 Starting Nmap 6.00 ( http://nmap.org ) at 2015-07-15 11:17 CEST Nmap scan report for ******** (10.0.0.2) Host is up (0.00010s latency). Not shown: 9991 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http 443/tcp open https 2606/tcp open netmon 3002/tcp open exlm-agent 3003/tcp open cgms 3260/tcp open iscsi 9876/tcp open sd 20002/tcp open commtact-http 20003/tcp open unknown 25555/tcp open unknown MAC Address: B0:83:FE:CC:52:C1 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 103.71 seconds
Group IP - UDP scan:
root@host:~$ nmap -sU -p 0-65535 10.0.0.2 Starting Nmap 6.00 ( http://nmap.org ) at 2015-07-20 09:28 CEST Nmap scan report for ******** (10.0.0.2) Host is up (0.00013s latency). Not shown: 65532 closed ports PORT STATE SERVICE 0/udp open|filtered unknown 123/udp open ntp 161/udp open snmp 65519/udp open|filtered unknown MAC Address: B0:83:FE:CC:52:C1 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 3.07 seconds
These scan results are pretty disappointing with regard to the expected additional security measures mentioned above.
An actual login test via SSH and FTP was successful and i guess a login via Telnet would have been successful too, if the protocol hadn't already been disabled in our configuration. This means there is also no filter on the application layer preventing access to the management functions, which wouldn't have been recognized by the simple port scan above.
As described earlier it shouldn't be too hard binding the services which are necessary for the management function to a specific network interface. I can't help but wonder why EqualLogic didn't follow through with this, especially since it's already described in the product manual. Maybe there were too many feature requests from the customer side or even technical requirements to better integrate the EqualLogic PS Series systems with certain host systems. Even then i wonder why EqualLogic didn't at least provide some means of selectively enabling or disabling the access to the management function from the iSCSI network with some kind of configuration parameter. In any case, the situation at hand – describing one thing and implementing another – seems to be the least favorable one to me.
