iSCSI protocol and creating iSCSI targets on Linux and Windows Servers

iSCSI allows access to a remote server (target) disk by making it virtually available as a local disk. This is done over normal TCP/IP networks. iSCSI target servers listen on port 3260 and initiators connect using port 860. Since iSCSI uses existing network, it is easier to deploy in comparison to deploying special storage area network.

Since iSCSI uses normal network, we can use traditional firewalls to provide security iSCSI target servers.

Note that accessing an entire disk is quite different than accessing file/folders over CIFS(Windows file sharing or Samba) or NFS. In case of iSCSI the client can choose any file-system supported by client and setup their own ACLs. Further the same iSCSI disk cane be accessed by multiple clients to have some kind of distributed or clustered filesystem for High-Availability (HA).

iSCSI can be used over WAN or over Internet also.

A computer talks to SCSI peripheral device using CDB. Using CDB instructions are given to read specific LBAs from a given LUN to a peripheral device. Similarly write operations can also be performed.

Following information about iSCSI should be noted:

• iSCSI allows an initator (client) to send CDBs to target (server) over TCP/IP. Thus it is possible to access a disk over network. iSCSI initiator can discover many disks (LUNs) provided by the same target and can connect to all of them at same time.
• iSCSI uses iqn naming convention. In this case the initator and target names start with iqn followed by date, naming authority and a custom string (serial number, random number, etc.)
• iSCSI supports cleartext and CHAP authentication. CHAP authentication is susceptible to dictionary attacks, spoofing and reflection attacks.

  Thus, it might make sense to secure iSCSI server using network firewall by allowing only legitimate trusted clients to access iSCSI server. Further, communication between server and client should be protected using techniques such as IPSec, VPN, etc.

• iSCSI protocol operates over plaintext. Hence if packets can be captured anywhere on the path from client to server than entire session can be reconstructed.

Following useful information can be seen during discovery (Note that considerable other information has been omitted) on request

• Opcode: Login Command (0x03)
• KeyValue: InitiatorName=iqn.1994-05.com.redhat:e3ef912f6c7e
• KeyValue: InitiatorAlias=barjatiyarklp
• KeyValue: SessionType=Discovery
• KeyValue: DefaultTime2Wait=2
• KeyValue: MaxRecvDataSegmentLength=32768

Corresponding response has:

• Opcode: Login Response (0x23)
• KeyValue: MaxRecvDataSegmentLength=65536
• KeyValue: DefaultTime2Wait=2

Subsequent queued request:

• Opcode: Text Command (0x04)
• LUN: 0 (Single Level LUN Structure)
• SendTargets=All

Corresponding response:

• Opcode: Text Response (0x24)
• LUN: 0 (Single Level LUN Structure)
• KeyValue: TargetName=iqn.1991-05.com.microsoft:win-3jt3lqt8djg-testtarget1-target
• KeyValue: TargetAddress=192.168.122.45:3260,1
• KeyValue: TargetAddress=[2001:0:9d38:90d7:28ae:1833:3f57:85d2]:3260,1

Request has:

• Opcode: Login Command (0x03)
• KeyValue: InitiatorName=iqn.1994-05.com.redhat:e3ef912f6c7e
• KeyValue: TargetName=iqn.1991-05.com.microsoft:win-3jt3lqt8djg-testtarget1-target
• KeyValue: SessionType=Normal

Corresponding response has:

• Opcode: Login Response (0x23)
• KeyValue: TargetPortalGroupTag=1
• KeyValue: TargetAlias=Test target 1

On subsequent packets you can see request and response CDB's as part of the iSCSI protocol.