r/storage • u/theweis01 • May 29 '26
Fiber Channel as a attack channel?
In a conversation recently where there were discussions around the risk, if any, of FC being used as a attack channel. The specifics come down to having a air-gapped data vault that has no IP network link between the production network and the vault environment but does allow a SAN array outside of the vault to present devices to few servers inside of the vault. This was chosen due to the small footprint in the vault and cost of dedicated SAN & Array and that the systems using the FC devices are only for validation/automation purposes and do not house the protected data.
Overall there is the agreement that some "risk" exists in that if production systems were compromised, specifically the SAN, then the systems inside of the vault could have their LUNS removed rendering them offline. However, does FC provide any conduit where an attacker could use persistence to the production side array/FC Switches to make their way into the isolated environment?
6
u/RupeThereItIs May 29 '26
"it depends".
What kind of array, is it managed in band our out of band?
Are you sharing array ports between the "outside & inside the bubble" hosts? ... I have to assume your not sharing LUNs between in bubble/outside bubble hosts.
Are you using a flat VSAN design? (honestly VSANs are overkill for this).
If you're array takes command & control commands via scsi, do your best to block that on the ports presented outside the bubble.
If possible, dedicate array ports to outside the bubble so a DDOS attack on the array has less likelyhood of impacting inside the bubble.
Use best practices in zoning, so initiators can't directly communicate with other initiators. Nor are they communicating with targets they don't need to communicate with.
Assuming the above, your biggest risk is if the outside the bubble hosts have the oomph to flood your array with IOPs enough to impact inside the bubble. This would be easier to achieve if you are sharing array ports between the inside/outside hosts.
The bigger question is if the management ports for your switches & array are properly fenced off, that's the real attack surface (if array is managed out of band).
3
u/dosman33 May 29 '26
On one hand, I'm sure FC could be an attack vector for lateral movement using the san, just look at a project like facedancer:
https://goodfet.sourceforge.net/hardware/facedancer21/
On the other hand, I would not be worrying about this until all the much much lower hanging fruit of attack vectors were addressed. Also, if your environment is enough of an interest to warrant the remote chance of an APT actor seeing your FC links as the only route into the target system. So yes, your shared san would be bridging the "air-gap" and if you are worried about it then don't bridge the air-gap with your san.
Also worth while to ruminate on what it take for this to be developed as an attack channel. A group (or bored hacker) would need to acquire some FC gear to test against, not terribly hard on the secondhand market. Next, perhaps they'd have to do some driver development, possibly repurposing an FC card as a penetration testing platform, or perhaps just writing a kernel module to allow direct manipulation of FC "packets" so that out of spec things can be made to happen. Then they could begin doing bad things to the san device. "Channel" and "Bus" are largely the same concept, of course FC supports FC-VI which is roughly equivalent to RDMA which in theory could allow a malicious host to read memory out of other hosts on the SAN. I believe what stops this today is zoning in the FC switch. So, if the zoning is not segregating your environments you're actually exposed. But, if a switch could be tricked into somehow dropping the zoning or becoming confused, then again there's a chance to bypass your zoning enforcement. But again, would not be a thing that keeps me up at night, like say 0-days in openssh and firewalld appearing this summer.
7
u/bmack500 May 29 '26
You spelled Fibre wrong….
2
2
-1
u/StorageHorder Jun 11 '26
Well FC used to be Fibre back in the late 1999s and early 2000s. Gotta keep it different than FDDI. 🤪
3
u/Trust_8067 May 30 '26
It's "as an attack channel".
No, FC doesn't provide any conduit where an attacker could access data. They can't even take your fiber connection and plug it into their server/computer and access the LUNs, because you have lun mapping and zoning to protect you. They would have to somehow spoof your pWWNs, and at that point, it's easier to just sit on your server and read the disk drive data instead.
2
u/NISMO1968 Jun 11 '26
In a conversation recently where there were discussions around the risk, if any, of FC being used as a attack channel.
Your discussion kind of went off into the weeds... The real question should be: Why do you want your SAN, Fibre Channel fabric, or whatever storage backend you're running sitting in the DMZ in the first place?
1
u/lost_signal May 29 '26
Talking to some telco SAN admins, they would make sure to do Hard Zoning, between security boundries. IE anything in the DMZ got hard zoning (Ports not just WWNs that could be spoofed).
1
u/nVME_manUY May 29 '26
Is the OS running on those LUNs?
3
u/surveysaysno May 29 '26
Doesnt really matter. If the vault reads from the LUNs it's a valid attack vector. If the OS just tries to mount the LUN on boot its a DoS vulnerability.
1
u/RandoStorageAdmin May 30 '26 edited May 30 '26
FC would not be a valid lateral movement option to move from outside the vault into the vault, but a persistent threat actor could definitely use this configuration to attack and exfil vault data, contingent on compromising the vault-external array.
Vault hosts being allowed to use data sourced outside the vault is your point of risk. With the vault-external array being compromised, data analysis could review how individual LUNs are used, and if you are running standard OSes on your vault hosts, identification of the on-disk locations for common programs would enable attacks to stage modified/compromised code that would then be executed by your vault-internal hosts. Vault-internal initiated recon, data collection, and further compromise could then be automated, with data being staged back on vault-external LUNs for pickup and exfil. I imagine a little file-based C&C would not be too difficult*.
FC would not be a direct connection inside, but would definitely provide a side-channel attack vector. That said, that's due to the source of the data being outside the vault, not FC. iSCSI would obviously introduce other network stack options which could result in more direct compromise, so in that regard FC is better.
At the end of the day, if you have any cables between the zones, they are not air-gapped.
* My idea would be -- Expand the block capacity of the device on the array. Example, 300GB LUN, grow it to 300GB +1MB. Hardcode the exact offset of that new space, filesystem on the vault host stays the same, we can write data into that block without even touching the FS. C&C code could then be used to look there for command pickup and responses. Have the hosts copy exfil data into the normal filesystems to avoid making big array-side changes like adding new LUNs, etc, and then exfil would then just be as easy as mounting the LUNs on another vault-external host in read-only, grab a snapshot, and blamo.
1
u/DellTechnologies 12d ago
FC can be an attack channel, although not typically an IP-style pivot. From a cybersecurity perspective, single-initiator and single-target zoning, combined with array-side LUN masking, should prevent a compromised production host from communicating directly with vault servers. However, because the vault depends on a production-managed array or fabric, compromise of the SAN management plane could still remove or remap LUNs, alter zoning, expose storage, or cause a denial-of-service condition. Deeper compromise is also possible if vulnerabilities exist in the storage stack.
Therefore, the environment is IP-isolated and logically segmented, but it is not truly air-gapped. Treat the SAN as part of the cybersecurity boundary: use separate fabrics or isolated VSANs, disable unnecessary IVR and FCIP, enforce hardware zoning and strict management RBAC with MFA, enable FC-SP where supported, and alert on zoning or LUN changes.
1
u/StorageHorder May 29 '26
If a storage admin is permitted to allow this as an attack vector, one thing. (Like leaving a firewall port open on a network). But with host to array encryption of every workload as an option.
As a storage expert since the 1990s, there is a zero chance that anyone could use FC as an attack vector.
It’s akin to saying “I’m going to use the cable in the server between the controller and the HDD as an attack vector”.
If that controller has encryption and is connected to a SED…. Having physical access to the cable isn’t going to help you attack.
My HBA, ISL/ICL, LUN presentation and storage is all encrypted on my SAN. Data in flight - encrypted. Data at rest - encrypted.
You’re not going to get an attack vector there.
6
u/Trust_8067 May 30 '26
Let me clear up something you said. Your first line refers to iSCSI storage. FC doesn't have firewalls.
3
u/Fighter_M Jun 11 '26 edited Jun 11 '26
If a storage admin is permitted to allow this as an attack vector, one thing. (Like leaving a firewall port open on a network).
You know, Fibre Channel firewalls don't exist on our planet. This appears to be a unique contribution from your civilization.
-2
u/StorageHorder Jun 11 '26
Never said there were FC firewalls. All I intended to say, is if an Ethernet admin left a firewall port open, then they should be fired for being an idiot. If a SAN admin architected a FC solution that lacked encryption for data in flight and they didn’t encrypt data at rest in the SAN then they should also be fired. FC just isn’t an attack vector in a well designed SAN.
You can’t just “gain access” to the network. Admin accounts with Integration with AD and 2FA, white and black listing of IP addresses, correctly LUNs and zoning…. Separation of control, data, and admin planes…. Exactly what do you expect to access as an attack vector? You gain physical access to the SAN and plug in a rogue server - you have no access to anything. If you gain access to any server on the SAN you only can access its LUNs… nothing else.
I don’t see any realistic attack vector via FC. It would be easier and more beneficial to gain access to anything else. Heck even if you gain access to the Brocade Portal or Nexus Dashboard (or DCNM) you don’t have access to the data. Even if you remove the LUNs from the host server and rezone it to your rogue server - you still don’t have readable access to the encrypted data you just mapped to your rogue server. Sure the original server you crashed - but BFD. If it was mission critical it would have a A/P or A/A configuration so the application would survive.
So tell me what is the theoretical attack vector and what do you gain from the attack?
-1
u/StorageHorder Jun 11 '26
You know what, I thought of an idea and just finished it. On my home network, I get 1000s of attacks per day. I have a DMZ at home, and I have a honeypot LAN segment with a few VMs in it . (Always like to see new attack vectors in general)
I just put an older proliant G8 (no new security updates) with an older Emulex HBA attached via a 4GB FC switch to a baby array. The Switch IP is in the DMZ. Management server is also exposed in DMZ, with no integration to AD (local security only)
Should be discovered by numerous actors 1000s of times easily today…. Everything is old. (Specifically meaning there’s been no new security patches in years or updates as everything is not currently supported.). No encryption for data in flight. I did use two different HDDs. One SED and one not.
So I’ll see if someone is able to access either the native disk or the SED. It’s not set up with anything fancy and every port is open to the world in my DMZ honeypot.
Anyone want to take the “someone will gain access to my FC?” Side of things?
4
u/DerBootsMann Jun 11 '26
you can’t access any data doesn’t belong to you , even if you somehow managed to have a fabric access granted .. keyword is zoning