Editing ISCSI (section)

==Security==
===Authentication===
iSCSI initiators and targets prove their identity to each other using [[Challenge-handshake authentication protocol|CHAP]], which includes a mechanism to prevent [[cleartext]] passwords from appearing on the wire. By itself, CHAP is vulnerable to [[dictionary attack]]s, [[IP address spoofing|spoofing]], and [[reflection attack]]s. If followed carefully, the best practices for using CHAP within iSCSI reduce the surface for these attacks and mitigate the risks.{{Ref RFC|3720|section=8.2.1}}

Additionally, as with all IP-based protocols, [[IPsec]] can operate at the network layer. The iSCSI negotiation protocol is designed to accommodate other authentication schemes, though interoperability issues limit their deployment.

===Logical network isolation===
To ensure that only valid initiators connect to storage arrays, administrators most commonly run iSCSI only over logically isolated backchannel networks. In this deployment architecture, only the management ports of storage arrays are exposed to the general-purpose internal network, and the iSCSI protocol itself is run over dedicated network segments or [[VLANs]]. This mitigates authentication concerns; unauthorized users are not physically provisioned for iSCSI, and thus cannot talk to storage arrays. However, it also creates a [https://www.sciencedirect.com/topics/computer-science/transitive-trust transitive trust] problem, in that a single compromised host with an iSCSI disk can be used to attack storage resources for other hosts.

===Physical network isolation===
{{unreferenced section|date=November 2013}}
While iSCSI can be logically isolated from the general network using VLANs only, it is still no different from any other network equipment and may use any cable or port as long as there is a completed signal path between source and target. Just a single cabling mistake by a network technician can compromise the barrier of logical separation, and an accidental bridging may not be immediately detected because it does not cause network errors.

In order to further differentiate iSCSI from the regular network and prevent cabling mistakes when changing connections, administrators may implement self-defined color-coding and labeling standards, such as only using yellow-colored cables for the iSCSI connections and only blue cables for the regular network, and clearly labeling ports and switches used only for iSCSI.

While iSCSI could be implemented as just a VLAN cluster of ports on a large multi-port switch that is also used for general network usage, the administrator may instead choose to use physically separate switches dedicated to iSCSI VLANs only, to further prevent the possibility of an incorrectly connected cable plugged into the wrong port bridging the logical barrier.

===Authorization===
{{unreferenced section|date=November 2013}}
Because iSCSI aims to consolidate storage for many servers into a single storage array, iSCSI deployments require strategies to prevent unrelated initiators from accessing storage resources. As a pathological example, a single enterprise storage array could hold data for servers variously regulated by the [[Sarbanes–Oxley Act]] for corporate accounting, [[Health Insurance Portability and Accountability Act|HIPAA]] for health benefits information, and [[PCI DSS]] for credit card processing. During an audit, storage systems must demonstrate controls to ensure that a server under one regime cannot access the storage assets of a server under another.

Typically, iSCSI storage arrays explicitly map initiators to specific target LUNs; an initiator authenticates not to the storage array, but to the specific storage asset it intends to use. However, because the target LUNs for SCSI commands are expressed both in the iSCSI negotiation protocol and in the underlying SCSI protocol, care must be taken to ensure that access control is provided consistently.

===Confidentiality and integrity===
For the most part, iSCSI operates as a cleartext protocol that provides no cryptographic protection for data in motion during SCSI transactions. As a result, an attacker who can listen in on iSCSI Ethernet traffic can:<ref>{{cite web|url=http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_41/esx_server_config/securing_an_esx_configuration/c_protecting_an_iscsi_san.html|title=Protecting an iSCSI SAN|publisher=VMware|access-date=3 November 2012|archive-url=https://web.archive.org/web/20160303201737/http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=%2Fcom.vmware.vsphere.esxi_server_config.doc_41%2Fesx_server_config%2Fsecuring_an_esx_configuration%2Fc_protecting_an_iscsi_san.html|archive-date=3 March 2016|url-status=dead}}</ref>
* Reconstruct and copy the files and filesystems being transferred on the wire
* Alter the contents of files by injecting fake iSCSI frames
* Corrupt filesystems being accessed by initiators, exposing servers to software flaws in poorly tested filesystem code.

These problems do not occur only with iSCSI, but rather apply to any [[Storage area network|SAN]] protocol without cryptographic security. IP-based security protocols, such as [[IPsec]], can provide standards-based cryptographic protection to this traffic.