Tag Archives: authentication

Fibre Channel Protocol in a Zero Trust world

By | | , , , , , , , , ,
1 Comment

Fibre Channel SANs (storage area networks) are touted as more secure than IP-based storage networks. In a way, that is true because Fibre Channel is a distinct network separated from the mainstream client-based applications. Moreover, the Fibre Channel protocol is entirely different from IP, and the deep understanding of the protocol, its implementations are exclusive to a selected cohort of practitioners and professionals in the storage technology industry.

The data landscape has changed significantly compared to the days where FC SANs were dominating the enterprise. The era was the mid 90s and early 2000s. EMC® was king; IBM® Shark was a top-tier predator; NetApp® was just getting over its WAFL™ NAS overdose to jump into Fibre Channel. There were other fishes in the Fibre Channel sea.

But the sands of storage networking have been shifting. Today, data is at the center of the universe. Data is the prized possession of every organization, and has also become the most coveted prize for data thieves, threat actors and other malefactors in the digital world. The Fibre Channel protocol has been changing too, under its revised specifications and implementations through its newer iterations in the past decade. This change in advancement of Fibre Channel as a storage networking protocol is less often mentioned, but nevertheless vital in the shift of the Fibre Channel SANs into a Zero Trust world.

Zones, masks and maps

Many storage practitioners are familiar with the type of security measures employed by Fibre Channel in the yesteryears. And this still rings true in many of the FC SANs that we know of today. For specific devices to connect to each other, from hosts to the storage LUNs (logical unit numbers), FC zoning must be configured. This could be hard zoning or soft zoning, where the concept involves segmentation and the grouping of configured FC ports of both the ends to “see” each other and to communicate, facilitated by the FC switches. These ports are either the initiators or the storage target, each with its own unique WWN (World Wide Name).

On top of zoning, storage practitioners also configure LUN masking at the host side, where only certain assigned LUNs from the storage array is “exposed” to the specific host initiators. In conjunction, at the storage array side, the LUNs are also associated to only a group of host initiators that are allowed to connect to the selected LUNs. This is the LUN mapping part.

Continue reading →

iSCSI old CHAP

By | | ,
Leave a comment

For folks working on iSCSI, especially the typical implementation engineers, they like to have things easy. “Let’s get this thing working so that I can go home” and usually done without the ever important CHAP (Challenge Handshake Authentication Protocol) enabled and configured.

We are quite lax when it comes to storage security and have always assumed that storage security is inherent in most setup, especially Fibre Channel. Well, let me tell you something, buddy. IT’S NOT! Even Fibre Channel has inherent vulnerability; it’s just that not many technical folks know about the 5 layers of Fibre Channel and it doesn’t mean that Fibre Channel is secure.

As the world turns to more iSCSI implementations, the fastest and easiest way to get a iSCSI connection is to do it without CHAP in the LAN, and CHAP authentication is not enabled by default. And this is happening in the IP world, not Fibre Channel, where there are more sniffers and hackers lurking. But even with CHAP applied, there are ways that CHAP can be broken and iSCSI security can be compromised easily. Below is the typical Windows iSCSI connection screenshot.

First of all, CHAP communication goes through back and forth in the network in clear-text, and the packets are easily captured. Then the hacker can take its own sweet time brute forcing to obtain the CHAP’s encrypted password, challenge and username.

iSCSI communication happens over the popular TCP port of 3260. This gives the hacker a good idea what he/she is able to do. They could sniff out the packets that is going through the wire from their computer but the hacker probably won’t do that. They would use another computer, one that has been compromised and trusted in the network.

From this compromised computer, the hackers would initiate a man-in-the-middle (MITM) attack. They can easily redirect the iSCSCI packets to this compromised computer to further their agenda. I found a nice diagram from SearchStorage about the iSCSI MITM attack and I shared it below.

A highly popular utility used in MITM attacks is one called Cain and Abel. Using a technique called ARP Cache Poisoning or ARP Poison Routing (APR), the compromised computer is able to intercept the iSCSI communication between the iSCSI initiator and the iSCSI target. The intercepted iSCSI packets can then be analyzed by Wireshark, the free and open source packet analyzer.

As Wireshark is capturing and analyzing the iSCSI packets, all the iSCSI communication that is happening between the initiator and the target is read in clear-text. The IQN number, the username are in clear-text as well. As Wireshark follows the TCP stream, the hacker will be looking out for a variable called “CHAP_N=iscsisecurity” and followed by “CHAP_R“ which equates to the encrypted password in the CHAP authentication. It will probably be in hexadecimal and begins with “Ox….“.

Voila, your encrypted iSCSI password, which now can be hacked in brute-force offline. It’s that easy folks!

Either way, having configured CHAP enabled is still better than no authentication at all (which most of us are likely to do during iSCSI setup). There are other ways to make the iSCSI communication more secure and IPSec is one of the considerations. But usually, we as techies have to balance between security and performance and we would end up choosing performance, relaxing the security bit.

But the exposure of iSCSI in the IP world is something we should think more about. Instead of having the easy way out, at least enable CHAP, old chap. OK?