• LOGIN
  • No products in the cart.

Network Analysis on a Storage Area Network Using Wireshark by Sembiante Massimiliano

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 dis- sector make it an extremely versatile tool for security ex- perts, 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 en- ables 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 a 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 technol- ogy 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 the 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 Numbers). 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 Mask- ing 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.

Screen Shot 2016-02-04 at 19.46.44

Figure 1. Fiber Channel Zoning

The SAN directors are accessible by Storage and Net- work Administrators via the Terminal Access Controller Access-Control System (TACACS) or the Remote Au- thentication Dial In User Service (RADIUS).

The main difference between NAS and SAN volume provisioning systems is the protocol used to provide stor- age 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 proto- col 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 perfor- mances and distance insensitivity, to facilitate the system boot from external devices and support enterprise storage flexibility and scalability.

Fiber Channel traffic Analysis

Network analysis on a fiber channel is not the same as on the Ethernet. There’s no equivalent promiscuous mode for nodes, so you can’t listen to traffic moving through the net- work. To achieve traffic analysis, you have to tap into the

Screen Shot 2016-02-04 at 19.48.30

Figure 2. Fiber Cable

network between the source and destination ports you wish to analyze. A 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 Pro- tocol Analyzers.

FC frame analyzers are often accompanied by a dedi- cated 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 con- nected, because each time you insert and remove the an- alyzer, you interrupt the FC network flow. This may end up 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.”

Screen Shot 2016-02-04 at 19.48.44

Figure 4. Setting up Wireshark

Screen Shot 2016-02-04 at 19.48.49

Figure 3. Typical SPAN to PAA Configuration

In that case, the frame analyzer or PAA (Protocol Analyzer Adapter) can be plugged into the SPAN switch port and the traffic flow can be analyzed. (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 an 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 analy- sis, 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#

Screen Shot 2016-02-04 at 19.53.19

Figure 5. Remote Connection via Command Line Interface

Screen Shot 2016-02-04 at 19.53.26

Figure 6. Host Login Trace 42

Next, we instruct Wireshark to connect to it remotely us- ing the graphical interface (Figure 4). Or, we may try to connect 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, the Zone-sets operations, or we can display which initiators and nodes are currently active and enabled.

It is possible to verify volumes presented to the hosts and potentially reverse engineer the entire SAN configuration.

If 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’ de- vices existing in all of the SAN area 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 fail- ure, 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 “dia- log” 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 the FCP/SCSI transmission dia- log 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 par- ticipants’ devices).

    We can verify the positive response in the second win- dow. 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 Wire- shark 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 ex- tremely 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 it 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 fil- ter traffic or identify intruders easily.

The Login of a “new” device in the fabric is never reported as a malicious activity and poorly monitored. Moreover a vol- ume 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 SAN protocol presents all the data at block level, but it is still possible to capture and dump, in a sepa- rate 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 re- configure Zoning and Masking, mount the target volume on a different Host, and gain access to 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 en- crypted volumes and never forget that sniffing is an illegal activity when performed without authorization.


Appendix 1

  • http://www.cisco.com/en/US/docs/switches/datacenter/ mds9000/sw/4_1/configuration/guides/cli_4_1/tsf.html
  • http://en.wikipedia.org/wiki/Fibre_Channel
  • http://en.wikipedia.org/wiki/Fibre_Channel_Logins
  • http://en.wikipedia.org/wiki/Fibre_Channel_zoning
  • http://www.jdsu.com/en-us/Test-and-Measurement/Products/a-z-product-list/Pages/xgig-protocol-analyzer-fam-

    ily-overview.aspx

  • http://teledynelecroy.com/protocolanalyzer/protocolstan-dard.aspx?standardid=5
  • http://www.brocade.com/products/all/switches/index.page
  • http://www.cisco.com/en/US/products/hw/ps4159/ps4358/products_configuration_example09186a008026eb55.shtml

About the Author:

SEMBIANtE MASSIMIlIANo

M.S.c. Computer Security Employed at UBS Bank as an IT Security and Risk Specialist. Collaborating as a Research Engineer at R.I.F.E.C. (Re- search Institute of Forensic and E-Crimes) focusing on: New Virus, Mal- ware Analysis and reverse, Digital Forensics, Sandbox bypass, Shell- coding, Testing Overflows and Exploitation, Code corruption, Testing unexpected behavior, Privilege Escalation, Cryptography, Cryptanaly- sis, Data infection analysis, new attack vectors, approaches including new tactics and strategies. Defeating protections, intrusion method- ologies, polymorphic and intelligent masquerading. Antivirus adapta- tion and detection avoidance. Development of Tools and scripts.

Web: www.rifec.com | Email: [email protected]


Article comes from BSD Magazine VOL. 8 No 33 Issue 03/2014 (56)

0 responses on "Network Analysis on a Storage Area Network Using Wireshark by Sembiante Massimiliano"

Leave a Message

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013