The Audit Finding That Changed Our SAN Design
A security audit found that any workstation on our campus network could initiate iSCSI connections to the SAN, and only the lack of initiator credentials prevented data access. I was standing behind the auditor when he ran discovery from a regular Windows engineering workstation and watched our storage targets answer from a network segment that had no business seeing them.
My first reaction was defensive. I assumed CHAP would make the finding low risk, because the LUNs were not mounting and the auditor could not authenticate. I was wrong. The SAN was deployed on a shared VLAN because it was “internal only,” and the assumption that internal equals trusted is the root cause of most storage security failures I have seen in manufacturing networks.
That mistake was ours.
Our environment had FortiGate firewalls running FortiOS 7.4.3, Ubuntu 22.04 jump hosts, VMware ESXi 8.0 hosts, and a Python 3.11 validation script I used to test discovery paths. Before the change, 184 workstation VLAN hosts could reach TCP 3260 on the storage targets. After isolating the SAN to a dedicated /27 storage VLAN with firewall enforcement, the pen test team confirmed zero SAN discovery was possible from the workstation VLAN.
I do not treat SAN exposure as a theoretical issue anymore; if a workstation can ask storage what it owns, the network design is already too permissive.
Why iSCSI Needs Network Isolation
iSCSI is practical because it rides on Ethernet, but that convenience is exactly why I do not want it living beside desktops, printers, badge controllers, and vendor laptops. A host does not need special hardware to attempt discovery. If it can route to the target portal, it can send iSCSI requests and learn whether storage is listening.
In our case, the array did not hand over data without credentials, but it still responded enough to prove visibility. That visibility mattered. A compromised workstation would have had a short path from initial foothold to storage reconnaissance, and ransomware crews love short paths.
Flat networks lie.
My preferred design is boring: storage initiators and targets sit in a dedicated storage VLAN, routed only where we explicitly allow it, with firewall policy denying workstation, guest, wireless, and general server VLANs by default. For our facility, that meant a /27 SAN network, no default workstation route to it, and FortiOS 7.4.3 policies that allowed only ESXi host vmkernel IPs and backup infrastructure to reach TCP 3260.
I also prefer logging denied attempts, because a workstation trying to talk iSCSI is either a bad scan, a misconfigured admin tool, or a compromise worth investigating.
Treat CHAP as a Lock, Not a Fence
We used CHAP authentication, and I still use it. I just no longer pretend it is enough by itself. CHAP protects the login exchange between initiator and target, but it does not remove the target from view, reduce scan noise, or prevent every unauthorized host from trying the door handle.
The fix was layered. We kept CHAP, rotated secrets, reviewed initiator names, and removed stale server IQNs that had survived too many maintenance windows. Then we moved enforcement closer to the network path, because access control that only lives inside the storage appliance is too late for my taste.
Defense should fail closed.
Here is the kind of validation I ran from an Ubuntu 22.04 workstation VLAN test box before and after firewall enforcement:
sudo apt-get install -y open-iscsi
iscsiadm -m discovery -t sendtargets -p 10.40.18.11
nc -vz 10.40.18.11 3260
sudo nmap -Pn -p 3260 10.40.18.0/27Before segmentation, discovery returned target portal information from multiple hosts. After segmentation, discovery timed out, TCP 3260 failed, and the firewall logs showed explicit denies from the workstation VLAN. I trust that result more than I trust a password prompt on exposed infrastructure.
Use Zoning and LUN Masking as Real Access Control
Network isolation controls who can reach the SAN. Zoning and LUN masking control what approved hosts can see once they are there. I want both, because storage mistakes rarely fail in one clean place. They fail through a chain of small allowances that nobody meant to combine.
For iSCSI, I map the concept of zoning to initiator-to-target access rules, target portals, host groups, and dedicated network paths. LUN masking then limits which volumes each host or cluster can see. In our VMware environment, the ESXi 8.0 production cluster did not need to see backup repository LUNs, and the backup server did not need to see every production datastore.
What I didn’t expect was how many stale mappings we found.
- Old initiator IQNs from retired ESXi hosts
- Temporary migration LUNs still visible to production clusters
- Backup targets reachable from general server networks
- Documentation that listed hostnames but not initiator IDs
- Firewall rules named for projects that no longer existed
Cleaning that up took longer than creating the new VLAN. The technical work was simple; the inventory work was not. My rule now is that every LUN presentation needs an owner, a ticket, a host group, and a reason I would be willing to defend during an incident review.
You may also find this useful: Check out our guide on Python Network Config Backup: Automating Multi-Vendor Device Snapshots for more practical tips.
I think storage access without current ownership is unmanaged risk wearing an infrastructure label.
Dedicate NICs for Performance and Containment
I like dedicated NICs for SAN traffic because they solve two problems at once. They reduce noisy contention from general workloads, and they make the security boundary visible in the physical and virtual design. On our hosts, storage vmkernel adapters use separate uplinks, separate switch ports, and separate VLAN tagging from workstation or management traffic.
That separation made troubleshooting easier. When latency spiked during a shift change, we could look at storage uplinks without mixing in desktop login storms, print traffic, camera streams, or random vendor traffic. Performance graphs became cleaner, and security conversations became less abstract.
Clean paths matter.
I still tune MTU, multipathing, queue depth, and switch buffers, but I do not let performance tuning become an excuse for broad access. Jumbo frames on the wrong shared network do not make a SAN design mature. They just make a bad design faster.
For manufacturing, I also care about operational blast radius. If a workstation VLAN gets noisy because a plant-floor system starts scanning, I do not want that event competing with storage replication or datastore access for critical virtual machines. Dedicated NICs and isolated VLANs are not luxury design choices in that environment; they are what keep ordinary incidents ordinary.
My opinion is blunt: if storage carries production workloads, it deserves its own path.
Enforce the Boundary Before Trusting the Array
I now review SAN reachability the same way I review internet exposure: prove who can connect, prove who cannot, and keep evidence. We test from workstation VLANs, server VLANs, wireless, VPN pools, and management networks. Then we compare the results against the intended initiator list instead of assuming the diagram is still true.
The practical control set is not complicated. I want a dedicated storage subnet, deny-by-default firewall rules, CHAP, current initiator records, LUN masking, clean host groups, and logs that show rejected attempts. None of those controls is exotic. The difference is whether we treat the SAN like a protected data plane or just another internal service.
Trust is not a subnet.
The audit finding embarrassed me at first, but it improved our environment. We moved from a shared internal VLAN where 184 workstations could attempt SAN discovery to a dedicated /27 storage VLAN where the pen test team confirmed zero discovery from the workstation VLAN. That is the kind of before-and-after number I care about, because it proves the design changed attacker options.
I believe every storage network should be built as if one internal workstation is already compromised, because sooner or later one will be.