Network Analysis On a Storage Area Network Using Wireshark

Wireshark, originally known as Ethereal, is probably the most famous open source packet sniffer and network analysis tool available.

This application supports about 1300 protocols through a vast number of filters. Functionalities such as traffic, protocol analysis, and packet dissector make it an extremely versatile tool for security experts, network engineers, and system administrators.
Wireshark can be used during a proactive analysis to identify potential network bottlenecks, to monitor “live” what is happening to data flow, and to decode packets in transit, displaying information in readable format. The tool can be installed on any computer connected to the network and equipped with a NIC card. Using specific API or libraries, such as WinPcap under Windows or libpcap for Unix, it enables data capture and allows analysis of packets travelling over the carrier.
Commonly, Wireshark is used on Ethernet technology or Wireless networks, but it’s also possible to use it for SAN (Storage Area Network) to analyze FCP (Fiber Channel Protocol) over Optical Fiber Cables.

The Storage Area Network Architecture

SAN (Storage Area Network) is generally defined as a dedicated storage network using Fibre Channel technology to provide disk volumes on the target host.
The SAN environment can be designed to have a disk array directly attached to a host or through a SAN Switch (a SAN Network Director similar to an Ethernet Switch) in order to connect multiple hosts to a single array and enable Business Continuity and Disaster Recovery capabilities.
Disks’ capacities are presented as logical volumes called LUNs (Logic Unit Number). The provisioning is performed by connecting the Array, Switch and HBA (Host Bus Adapter, a fiber card adapter installed on the Host system) using two different operations called LUN Masking and Zoning (Figure 1).
With Zoning, we connect the ports of the devices, also called initiators, to be logically linked. While performing the LUN Masking, we present the LUN (disk capacity) to the target host.
The SAN directors are accessible by Storage and Network Administrators via the Terminal Access Controller Access-Control System (TACACS) or Remote Authentication Dial In User Service (RADIUS).
The main difference between NAS and SAN volume
provisioning systems is the protocol used to provide storage
capacity. NAS uses NFS or CIFS protocols while
SAN uses the FCP (Fiber Channel Protocol).

Fiber Channel Protocol

The FCP (Fibre Channel Protocol) is a transport protocol similar to TCP/IP, approved as ANSI standard around 1994. FCP mainly transports SCSI commands using the Optical Cable as a carrier (Figure 2).
This protocol was invented to enable higher performances and distance insensitivity, to facilitate the system boot from external devices, and to support enterprise storage flexibility and scalability.

Fiber Channel Traffic Analysis

Network analysis on a fiber channel is not the same as over the Ethernet. There’s no equivalent promiscuous mode for nodes, so you can’t listen to traffic moving through the network. To achieve traffic analysis, first of all, you need to tap into the network between the source and destination ports you wish to analyze. Dedicated hardware is necessary to “read” the packets and specific software to analyze the frames.
Some examples of external frame analyzers are: Xgig Protocol Analyzer Family from JDSU or LeCroy FC Protocol Analyzers.
FC frame analyzers are often accompanied by dedicated TAP (Traffic Access Point) network hardware. This device is physically inserted into the network and when turned on, it copies all frames headed for a specific port to a specific TAP port. Using TAP hardware means that the frame analyzer can be plugged into the TAPped port and then removed without causing an interruption in the FC network flow. Of course, in order to initially install the TAP hardware, you have to interrupt the network flow.
Preferably, these devices should be permanently connected because each time you insert and remove the analyzer, you interrupt the FC network flow. This may result in serious repercussions for the system, such as Data Loss and Kernel Panic.
In some cases, this has been made easier by vendors such as Cisco and Brocade, providing a Switched Port Analyzer (SPAN) feature, which copies most traffic going to a specific port to another switch port called “mirror port”. In that case, the frame analyzer or PAA (Protocol AnalyzerAdapter) can be plugged into the SPAN switch port and analyzes the traffic flow (Figure 3).
Cisco and Brocade provide native command line tools to allow local fiber channel control traffic passing through the local supervisors to be copied into a text file that is stored in a chosen location on the switch or redirected to the IP Address.
The default behavior is to store the output in a volatile storage area. This can later be copied to a remote server for analysis with Wireshark.
It is also possible to specify a remote IP address to send the data to, and Wireshark can be used to analyze the data in real time, as it’s collected.
Cisco MDS Switches with the SanOS operating system provide an FC Analyzer command line called: fcanalyzer (portlogshow is the command line on brocade).
In order to configure the system to perform traffic analysis, we must configure the Switch in passive remote mode using the command line as follows:
MDS3(config)# fcanalyzer remote 172.xxx.xxx.xxx
MDS3(config)# exit
MDS3# show fcanalyzer
PassiveClient = 172.xxx.xxx.xxx
MDS2#
Next, we instruct Wireshark to connect to it remotely using the graphical interface (Figure 4). Or, we may try to connect to it using the Wireshark CLI (Figure 5). Now, we are ready to start a new capture session and verify which type of raw data we can get out of the FC analyzer.
Wireshark can capture a huge amount of information, when installed between the disk array and the host machine. It could potentially intercept all the SCSI commands passing through these two devices. At the same time, it is possible to inspect what is happening at the switch level and use the data for troubleshooting and debugging purposes.

During a live-capture session, we can monitor the Fabric behavior and the Zone-sets operations; or, we can display which initiators and nodes were currently active and enabled. It is possible to verify volumes presented to the hosts and potentially reverse engineer the entire SAN configuration.
We can manage to identify all the Zoning and Masking setup, and if the Switch is using features such as VSAN (Virtual SAN similar to VLAN in Ethernet Networks) or IVR (Inter-VSAN Routing), we can trace all the members’ devices existing in all of the SAN areas including all the SCSI command dialogs.
With the help of customized filters, it is possible to use Wireshark for troubleshooting purposes and display (for example, merge conflicts, Fabric Login status, Zoning failure, and so on). A good example is visible in Figure 6. We can see a live capture session with Wireshark tracing a Host Login event. It is possible to trace the entire “dialog” between the Host and the Remote Array through the Switches. There are two active windows in Wireshark:
• Transmit Trace
• Response Trace.
The first one is tracing FCP/SCSI transmission dialog and the second traces the responses.
In the first window, we can see LUNs (remote disks) are in “inquiry status” (seeking to log on to target host) and the FC initiator is attempting to initiate the FLOGI (a link service command that sets up a session between two participants’ devices).
We can verify the positive response in the second window. The Login request is accepted, and we can see the positive response. The trace window is now displaying that LUNs are reported in good status, hence available to be mounted on the target Host.

Conclusions

This article provides a quick overview of using Wireshark in a SAN environment. Although network analyzers are powerful software and can be used to troubleshoot complicated issues, at the same time they can be extremely dangerous when misused or activated through unauthorized access.
Sniffers are difficult to detect and can be applied almost anywhere within the network under analysis, which makes them one of the hackers’ favorite tools.
We need to bear in mind that NO Firewalls or IDS are present in a SAN environment; thus, it is not possible to filter traffic or identify intruders easily.
The Login of a “new” device in the fabric is never reported as malicious activity and poorly monitored. Moreover, a volume can be mounted and shared over multiple hosts and, in most cases, there is no event alert that traces the activity.
It’s true that the SAN protocol presents all data at the block level, but it is still possible to capture and dump, in a separate storage area, a large quantity of traffic to attempt file reconstructions later.
Using Wireshark to perform SAN network cartography may be a good starting point to perform further attacks. One may be able to use the information gathered to reconfigure Zoning and Masking, mount the target volume on a different Host, and access the stored data.
FCP is a protocol that does not provide encryption; thus, all the data travelling is potentially exposed.
Remember to handle all the information gathered with Wireshark carefully in order to avoid data leakage. We should store all the captured files securely, possibly in encrypted volumes and never forget that sniffing is an illegal activity when performed without authorization.

SEMBIANTE MASSIMILIANO
M.S.c. Computer Security Employed at UBS Bank as IT Security and Risk Specialist. Collaborating as Research Engineer at R.I.F.E.C. (Research Institute of Forensic and E-Crimes) focusing on: New Virus, Malware Analysis and reverse, Digital Forensic, Sandbox bypass, Shellcoding, Testing Overflows and Exploitation, Code corruption, Testing unexpected behavior, Privilege Escalation, Cryptography, Cryptanalysis, Data infection analysis, new attack vectors, approaches including new tactics and strategies. Defeating protections, intrusion methodologies, polymorphic and intelligent masquerading. Antivirus adaptation and detection avoidance. Development of Tools and scripts.
Web: www.rifec.com | Email: msembiante@rifec.com