By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In Chapter 2of Securing Storage: A Practical Guide to SAN and NAS Security, author Himanshu Dwivedi examines how man-in-the-middle attacks affect Fibre Channel security and provides self-assessment exercises that administrators can use to determine if their organization is at risk.
Before we can begin to understand the idea about a Fibre Channel man-in-the-middle attack, let's first understand the concept using the IP protocol. An entity using IP, such as a switch or an operating system, will send out ARP requests when it is trying to communicate with other entities. For example, if server A wanted to communicate with server B, which has the IP address of 172.16.1.1 and the MAC address of 00-0A-CC-69-89-74, server A would send out an ARP request asking, "Who is 172.16.1.1?" Then the switch or the operating system would respond, replying with its MAC address, which is 00-0A-CC-69-89-74. The issue with ARP, which we will also address with Fibre Channel name servers, is that any malicious entity could send out an ARP reply instead of the actual server. For example, if you stepped outside your home and yelled out, "What is the address of the post-office," a malicious neighbor could say, "I am the post-office; please send your mail to me." If you believed this malicious neighbor without asking for proof, then your mail would be compromised. This is how ARP works, without any authentication. A malicious user could send out ARP replies with the incorrect information.
Since there is no authentication with ARP, similar to how there is no authentication with PLOGI in Fibre Channel fabrics, an entity receiving an ARP reply from an attacker would update their routing table with the incorrect information. Furthermore, even if a node did not send out an ARP request, which would request the MAC address of a specific IP address, it doesn't mean it won't receive an ARP reply and update its own routing table. For example, a malicious user could send out ARP replies to the entire network segment, telling each entity that the MAC address of the router, which is 172.16.1.1, is actually the MAC address of the malicious entity. When one node tries to communicate to any other node by going through the default router, it will actually be going to the malicious entity first, since it is using the MAC address of the malicious entity for layer 2 routing.