FC6P01 Project Final Report Year 2013/2014...FC6P01 Project: / Olivier Zoude – ID: 10034346 –...

FC6P01 Project

Final Report

Year 2013/2014

Name: Olivier Zoude

ID Number: 10034346

Date: Wednesday 7, May 2014

Supervisor: Tarik Molalign

Project Title: Evaluating Storage Area Networks (SAN)

FC6P01 Project: / Olivier Zoude – ID: 10034346 – LondonMet

Page 2 of 100

Abstract

In this project of “Evaluating Storage Area Networks”, we will implement an iSCSI

SAN by first describing the functionality of the small computer system interface (SCSI)

through its terminology, architecture, command activities, target operations, task

management function, and its error reporting process. Also describing the SCSI

transport protocol in terms of data transfer medium from Target to Initiator and vice

versa, we will show how the SCSI architecture is used as support by the Internet SCSI

(iSCSI) to effectively establish communication between end devices. Then we will

proceed with the iSCSI SAN implementation process by mounting the server disks

with SATA cable for a RAID 3 disk mirroring principal, loading the server with

Openfiler (Linux based-software) as Operating System (OS) to allow the use of its

Graphic User Interface (GUI) for administration purpose and control it remotely from

a client host. The iSCSI SAN implementation will be achieved with an effective

connectivity through a point-to-point topology between its end devices, iSCSI Target

and iSCSI Initiator, which will be configured accordingly for data transfer allowing

encapsulation of SCSI Command Descriptor Block (CDB) into Protocol Data Unit

(PDU) by the iSCSI, passing through TCP/IP network, guided by a quality of service

protocol.


Page 3 of 100

Table of Contents

Abstract ......................................................................................................... 2

Table of Contents ........................................................................................... 3

1. Introduction ............................................................................................... 7

Project Aims and Objectives ....................................................................... 9

2. Background .............................................................................................. 11

2-1 Reason for using SCSI ....................................................................... 11

2-2 SCSI terminologies............................................................................. 12

2-3 SCSI architecture models ................................................................... 14

2-3-1 SCSI Distributed Service Model .................................................. 15

2-3-2 SCSI Client-Server model ........................................................... 15

2-4 SCSI commands Model and their format ............................................ 17

2-5 Basics SCSI target operation .............................................................. 22

2-6 SCSI task management function ......................................................... 26

2-7 SCSI error reporting........................................................................... 28


Page 4 of 100

2-8 SCSI Transport Protocol .................................................................... 29

2-8-1The Fibre Channel (FC): ............................................................... 30

2-8-2 The SCSI over Ethernet (SCSIoE) or over IP-networks: ............. 34

2-8-2-1 The SCSI Encapsulation Protocol (SEP): ............................. 35

2-8-2-2 The Internet SCSI (iSCSI): .................................................. 35

2-9 iSCSI, and FC relying on SCSI architecture as support for SAN ......... 44

3. Work Completed ...................................................................................... 47

3-1 Component of standard iSCSI SAN .................................................... 47

3-2 different iSCSI SAN topologies using RAID system storage ............... 47

3-3 iSCSI SAN topology: ......................................................................... 48

4. Implementation ......................................................................................... 51

4-1 iSCSI Target (server) disks mounting ................................................. 51

4-2 OpenFiler software installation on Server ............................................ 52

4-2 iSCSI Target disks configuration from client device ............................ 57

5. Testing ..................................................................................................... 66


Page 5 of 100

5-1 iSCSI Target volume Discovery ......................................................... 66

5-2 iSCSI Target volume initialization and formatting process .................. 70

6. Analysis and Review ................................................................................. 76

6-1 The iSCSI SAN establishment and connectivity analysis ..................... 76

6-1-1 Use of SCSI Terminology ........................................................... 76

6-1-2 Use of SCSI architecture model ................................................... 76

6-1-3 use of SCSI command models and their format ............................ 77

6-1-4 Use of SCSI Target operation ..................................................... 77

6-1-5 Use of SCSI Task management and for error reporting ................ 77

6-1-6 Use of SCSI architecture by iSCSI SAN for data transfer ............ 77

6-1-6-1 The iSCSI Single session connection process ........................ 78

6-1-6-2 The iSCSI Multiple sessions connection process ................... 79

6-2 The iSCSI SAN data transfer protocol advantages .............................. 79

6-3 The iSCSI SAN security analysis ........................................................ 80

6-3-1 iSCSI SAN security vulnerability ................................................. 80


Page 6 of 100

6-3-2 iSCSI SAN security vulnerability countermeasures ...................... 87

6-4 iSCSI SAN security advantages .......................................................... 88

7. Conclusion ............................................................................................... 90

8. References ................................................................................................ 92

9. Table of Figures ....................................................................................... 95


Page 7 of 100

1. Introduction

“The 90’s witnessed a major shift away from the traditional mainframe with centralized

information, host-centric model of computing to the client/server model for

geographically or locally manageable data”(Ref 1: IBM Redbooks). With today high

demand of data storage, SAN has become an effective solution to government

agencies, organisations, businesses and individual activities in terms of high speed, low

latency, and very low error rate of data transfer. SAN mainly use Small Computer

System Interface (SCSI) “originated from the Selector Channel on IBM-360

computers, and in 1981 was scaled down by the Shugart Associates Company to make

it universal, intelligent disk drive interface. It was called the Shugart Associates

Systems Interface, or SASI pronounced sassy, SCSI became ANSI (American

National Standard Institute) standard in 1986" (Ref 2: Basics of SCSI Fourth

Edition). SCSI is a set standard for physically connecting and transferring data from

one device (Initiator) to another (Target), it is a protocol for end-to-end

communication and its features are based on compatibility with high number of nodes,

metropolitan distance coverage, high reliability and ability to react to failures from the

use of Random Array Independent Disk (RAID) as data storage technology. Therefore

implementing an adequate SAN is a delicate Network task which needs to be fulfilled

with appropriate tools and devices to satisfy efficiently the constant growing demand

of data transfer and very high capacity of data storage in terms of scalability,

availability and manageability.

In this project we are evaluating Storage Area Networks (SAN), defined by the

Storage Network Industry Associate (SNIA) as a Network whose primary purpose is

the transfer of data between computer systems and storage elements using the Small


Page 8 of 100

Computer System Interface, we will describe the SCSI terminology to understand the

need of the SCSI, and the purpose of its principal devices and applications (Initiator-

Target, Logical Unit, Task set...). Describe its architectural model by defining the

purpose of the SCSI for information transfer. This project will allow the description of

the different Architecture models functional performed by the Logical Unit (LUN), the

commands model and their format to explain the use of a command and its parameters

sent in Command Descriptor Block (CDB), we will explain the basic SCSI target

operation involving the understanding of the Initiator-Target pair in which the client

makes requests and is responded to by the server. Then by describing the SCSI task

management function we will investigate the understanding of each SCSI protocol

standard allowing events from the server. The SCSI Error reporting will be analyzed to

understand how SCSI effectively monitors sense data transfer to a client using a

request sense command, an asynchronous event report, and an autosense delivery. The

SCSI Transport protocol will be explained allowing the understanding of the use of

other set of protocols to transmit SCSI data using mainly the iSCSI. Then we will

describe how Fibre Channel protocol characteristics frame, and iSCSI characteristics

rely on the SCSI architecture to support storage Area Network (SAN).

To emphasize the above aspects we will elaborate over the investigation and

application of different SAN Topologies using RAID storage system by explaining the

importance of these topologies in terms of interoperability, client requirement for

mixed applications, servers, operating system and storage systems in a single

environment, and describe the different component needed for a standard SAN to

operate efficiently. We will describe different SAN Topologies over their efficiency

(advantages and disadvantages).Then we will define and explain the best approach

Topology of SAN application, implement best appropriate SAN and then test in


Page 9 of 100

Laboratory the effectiveness connectivity of implemented SAN with respective

components associated with, using Openfiler software as Linux Operating System

(OS) platform. Finally, from our SAN implementation test result, we will discuss over

the security aspect of the iSCSI SAN and propose some eventual security vulnerability

countermeasures in general to tackle hacker activities for iSCSI SAN best

connectivity.

Project Aims and Objectives

Aim 1:

Describe Small Computer System Interface (SCSI) architectural model

Objectives:

1.1 Describe the SCSI terminology

1.2 Describe SCSI architecture models

1.3 Describe SCSI commands Model and their format

1.4 Explain the basic SCSI target Operation

1.5 Describe SCSI task management Function

1.6 Describe SCSI error reporting

1.7 Explain the SCSI Transport protocol

1.8 Describe how Fibre Channel and iSCSI rely on the SCSI

architecture to support storage Area Network (SAN)

Aim 2:

Investigate application of different SAN topologies

Objectives:

1.1 Investigate the main components of a standard SAN

1.2 Elaborate on different SAN topologies


Page 10 of 100

1.3 Define and explain best appropriate topology of SAN application

1.4 Implementing SAN Network using iSCSI as Protocol

communication, point-to-point SAN as Topology and OpenFiler as

software platform

1.5 Test in Lab effectiveness of implemented SAN


Page 11 of 100

2. Background

“In 1979, Shugart Associates, led by storage industry pioneer Alan Shugart, created

the Shugart Associates Systems Interface (SASI)” (Ref 3). SASI is replaced today by

Small computer system interface (SCSI), a parallel interface standard from American

National Standard Institute (ANSI); it is used to attach peripheral devices to computer.

A single cable of SCSI has a maximum length of 25 m and can connect up to 16

devices. It comes in different flavours:

- SCSI-1 using 8 bit bus, obsolete, support data rate of 4Mbps

- SCSI-2 is a SCSI-1 improved with a Common Command Set (CCS) and a

command queuing features. It delivers from 10 to 20 Mbps data transfer rate.

- SCSI-3 uses serial SCSI feature allowing a data transfer of up to 100Mbps

using six-conductor coaxial cable.

- Serial Attached SCSI (SAS), provides a data transfer of 150Mbps using a fast

communication device compatibility Serial Advanced Technology Attachment

(SATA) cable. ATA, “was first approved in May 12, 1994, under the ANSI

document number X3.221-1994 and is an interface used to connect such

devices as hard drives, CD-ROM drives, and other disk drives” (Ref 4).

This rapid improvement of the SCSI in terms of compatibility to other device must be

one of the reasons of its obvious use in computer environment.

2-1 Reason for using SCSI

Prior the implementation of the SCSI, for every external device added to a computer

system, it will need a special configuration to interact and communicate with the

peripheral device to accomplish the task in reading and writing data from Initiator to


Page 12 of 100

Target device. This special configuration often needs a new hardware and software

design. Therefore by the time that design is accomplished the peripherals attached to

the computer become obsolete compare to the computer itself, in other word, the basic

function of the SCSI is to give the computer complete device independence. To allow

connection and transfer of data effectively, SCSI will base its function on its

architecture models.

2-2 SCSI terminologies

SCSI is a standard defining an interface between an Initiator (host or computer) and a

Target (server or storage). The interface is referred to as electric signal, connectors,

cables and command protocols that allow communication between Initiator and

Target. The Logical Units (LUNs) are subset of Target device allowing scalability. The

Queue, also known as task set, keeps on hold pending tasks that the Target will

execute.

The main two types of device in SCSI bus architecture are:

The SCSI Initiator device starts the Input and Output (I/O) process

The SCSI Target device responds to a request to perform I/O process

Figure 1 Representation of typical SCSI system


Page 13 of 100

Figure 2 Principal SCSI Terminologies (Ref 5)

The Initiator starts the arbitration (Taking control of the SCSI bus) and selects the

Target. The corresponding Target then requests a command from Initiator. A

Command Descriptor Block (CDB) is then sent by the Initiator to the Target. The

Target executes the CDB received and returns the appropriate response. A further

level of abstraction is achieved in SCSI with the introduction of concept of logical

block addressing (LBA). If a computer needs access to data, it is addressed in terms of

certain Logical Block Address.

- The Logical Units (LUNs) stated above is represented by the following model

below:

Figure 3 Logical Unit Model (Ref 6)

- The Initiator device model stated above is represented by the following model

below:


Page 14 of 100

Figure 4 Initiator device model (Ref 6)

- The Target device model stated above is represented by the following model

below :

Figure 5 Target device model (Ref 6)

2-3 SCSI architecture models

The purpose of the SCSI architecture is to (Ref 6):

- Provide a basis for the coordination of SCSI’s standard development.

- Identify areas for developing and provide a common reference for maintaining

consistency among SCSI related standards.

- Provide the foundation for application compatibility across all SCSI interconnect

and protocol environments.

SCSI has two principal architecture models:

- SCSI Distributed Service Model

- SCSI Client-Service Model


Page 15 of 100

2-3-1 SCSI Distributed Service Model

In a SCSI Distributed Service model, Client-Server transaction is represented as a

remote procedure call with input supply by the Client. The procedure is processed

by the server returns output and a procedure status (Ref 6). In this model the SCSI

is a client-server protocol. The Initiator issues requests to the server, the Target

receives, executes, and returns Initiator requests and associated responses. From

the Initiator perceptive, requests become pending when passed through its Service

Delivery Subsystem and completed when Target response is received or failure

notification is sent. From the Target perspective, the request is pending upon

receipt and completes when the response is passed through its Service Delivery

Subsystem to be returned to the Initiator (Ref 6). This aspect introduces a time

skew between the Client and Server’s perception.

Figure 6 SCSI Distributed Service model (Ref 5)

2-3-2 SCSI Client-Server model

As Figure 7 shows, in SCSI Client-Server, a single Initiator has multiple application

clients, the Target has one task manager, one or more Logical Unit (LUN)

numbered and has a Device Server which processes operations and direct them to a

specific LUN.

The task manager function is to:

- Controls the sequencing of one or more task within a LUN.


Page 16 of 100

- Carries out the task management functions.

- Have authority to change service requests already received by the Target.

Figure 7 SCSI Client-Service Model (Ref 5)

The sequence of events associated with the task manager function can be described

as follow (Ref 6):

Figure 8 Task Management Processing Events (Ref 6)

- 1. The Application Client issues a request to the Task Management using the

“Send Task Management Request” SCSI protocol service.

- 2. The Task Management is notified through the “Task Management Request

Receive” SCSI protocol service and start processing the function.

- 3. The Task Manager performs the request by using the “Task Management

Function Executed” SCSI protocol service to notify the Application Client.

Therefore the “Service Response” SCSI protocol service parameter is set to

“Function Completed”


Page 17 of 100

- 4. A “Received Function-Executed” SCSI protocol service confirmation is

received by the Application Client.

The SCSI architecture model is therefore the basis for an efficiency of its commands

using respective model and format to allow transfer of request from client and

response from server. An analytic comparison of both architecture models revealed

that the time skew perception between the Initiator and the Target appear as a

disadvantage to the SCSI distribution architecture model in terms of latency of

commands transfer.

2-4 SCSI commands Model and their format

A SCSI command is generated by the initiator (on the host) and sent to the Target

(server) during the command phase, allowing the Target to request command

information from the Initiator. A command and its parameters are sent as block several

bytes long called the Command Descriptor Block (CDB).

SCSI commands are classified into 3 groups of command based on the length of their

CDBs:

- Group 0, uses 6-byte CDBs

- Group 1, 2, uses 10-byte CDBs

- Group 5, uses 12-byte CDBs

The general format for all CDBs except the CDB for operation code 7Fh is shown

below in Figure 9.


Page 18 of 100

Figure 9 General format of CDBs except operation code 7Fh (Ref 6)

Using SCSI command in READ (6) command as example, the first byte of the CDB is

the Operation Code (OP code). It is followed by the Logical Unit Number (LUN) in

upper three bit of the second byte and by the Logical Block Address (LBAs) and

transfer length field (READ and WRITE commands) or other parameters. The last

byte of each CDB is the control byte. This byte contains two importance bits, the

LINK and the Normal Automatic Contingent Allegiance (NACA).

- The LINK bit: Is used to continue a task across multiple commands.

- Normal ACA bit: Is used to control the rules for handling error condition

create by failure to execute a command (Ref 6)

Figure 10 Example of six byte CDB, READ command, Format (Ref 7)


Page 19 of 100

Figure 11 Description of SCSI READ command format (Ref 5)

A command is executed by sending a CDB to the target and for each CDB, the

first byte is the Operation Code and the last byte is the Control Byte. Both

Operation Byte and Control Byte format are identical for every SCSI command.

Figure 12 Different type of CDBs format (Ref 5)

The SCSI command PDU and its response PDU are mainly used to carry the CDBs

and the logical unit (LUN) of the end devices as shown respectively in Figure 13

and Figure14 below.


Page 20 of 100

Figure 13 SCSI command PDU (Ref 8)

Figure 14 SCSI response PDU (Ref 8)

The execution of SCSI commands can be described in 8 distinct phase sequences:

- Bus Free Phase: Indicates no current I/O process and SCSI is available for

connection.


Page 21 of 100

- Arbitration Phase: Allows one SCSI device to gain control of the SCSI bus to

initiate or resume an I/O process.

- Selection Phase: Allows an Initiator to select a Target to initiate some Target

function (READ or WRITE command)

- Reselection Phase: Optional phase that allows a Target to reconnect to an

Initiator to continuous operation previously suspended by the Target.

- Command Phase: Allows the Target to request command information from

the Initiator.

- Data Phase: It consists of the Target to request DATA IN to be sent to the

Initiator from the Target and it allows the Target to request the DATA OUT to

be sent from the Initiator to the Target.

- Status Phase: It allows the Target to request that status information to be sent

from the Target to the Initiator.

- Message Phase: It allows the Target to request The MESSAGE IN to be sent

from the Target to the Initiator. And it allows the Target to request the

MESSAGE OUT to be sent from the Initiator to the Target.

The normal sequence of Phase as described by the standards is shown below in Figure

15. This permits an effective flow of basics SCSI Target operation through respective

commands. But definitely these 8 phase sequences have an impact over the latency of

the SCSI commands delivery procedure due to its non-flexible process base on the fact

that the SCSI bus cannot be simultaneously used by both Initiator and Target device.


Page 22 of 100

Figure 15 SCSI Phase sequences (Ref 7)

2-5 Basics SCSI target operation

Once it is power on and selected, the SCSI Target should be able to respond to the

following basic commands (used to configure the system, test device, and return

information for error and exception conditions):

- TEST UNIT READY: This command checks if the selected drive is ready or

not.

Figure 16 TEST UNIT READY command format (Ref 9)

- INQUIRY: This command transfers the parameter information of the controller

to the host computer.


Page 23 of 100

Figure 17 ENQUIRY command format (Ref 9)

- REQUEST SENSE: This command returns the sense data of the unit

describing the “check condition” status indicated to the host computer.

Figure 18 REQUEST SENSE command format (Ref 9)

- SEND DIAGNOSTIC: This command requests the controller to perform

diagnostic on the controller and the selected LUN.

Figure 19 SEND DIAGNOSTIC command format (Ref 9)

In the example of SCSI Client-Service Model, chosen for accuracy and low

latency over SCSI command transfer, to execute a SCSI command, the

Application Client refers to the following remote procedure (Ref 9):


Page 24 of 100

Service response = Execute Command (Task Address, CDB, [Task

Attribute] [Data-Out Buffer], [Command Byte Count],[Autosense

Request] || [Data-In Buffer], [Sense Data], Status);

The above remote procedure is described as:

- INPUT PARAMETERS, are composed of:

Task Address: Acting as the Initiator port responsible for this command along

with the Target id and LUN to which this command is transmitted

CDB: The SCSI command which is to be executed

Task Attribute: Nature of the Task (Simple, Ordered, Head of Queue, ACA)

Data-Out Buffer: Buffer containing command specific information such as

data or parameter lists needed to execute the command

Command Byte Count: The maximum number of bytes to be transferred by

the command

Autosense Request: Argument requesting the return of automatic sense data

when the execution of the SCSI command fails

- OUTPUT PARAMETERS, are composed of:

Data-In Buffer: Buffer containing command specific information returned by

the LUN.

Sense Data: A buffer containing sense data returned by the LUN by means of

an autosense mechanism.

Status: A one-byte field containing command completion status.

In the above model the Initiator (Client) makes requests which are responded by

the Target (Server). When the Initiator issues a command, the data buffer required

by the command are already allocated with a READ or WRITE command within


Page 25 of 100

the Initiator by the user space application when the command is transmitted to the

Target. Consequently before the Client (Initiator) issues the READ command to

the Server (Target), the buffer to receive the READ command is already allocated.

From the Target, the READ command is received, the buffers are allocated, the

command is executed and the buffers are filled. But on the Target side, the WRITE

command data flow is from the Initiator to the Target. Therefore the Target has

not acknowledgment of the size of the data from the Initiator to pre-allocate its

buffers until the WRITE command is received. This mechanism does not allow the

Initiator to send automatically the WRITE command to the Target until it (Target)

has allocated the necessary buffer space and informed the Initiator about it, using

the Low-Level protocol (Ethernet, FC, internet protocol IP, etc...). That is where

the flow control mechanism to control the Low-Level Protocol takes place and

provides effective and efficient data transfer (WRITE command) from the Initiator

to the Target.

For an accurate WRITE command response from the Target to the Initiator, the

three steps below, which determine the flow control mechanism, must be observed

(Ref 9):

- Allocating the data buffers, which is control by the Low-Level protocol

- Informing the Initiator about the type of data it should send, which is specific

to the Low-Level protocol

- The execution of the command when the data arrives, again under control of

the Low-Level protocol.

Obviously the low-level protocol used for the SCSI command transfer determines the

quality of the Initiator request and the Target response command.


Page 26 of 100

These three steps, guide the criteria’s to be imposed to a SCSI Target implementation

to allow the efficiency of its task management function.

2-6 SCSI task management function

The task management permits the Initiator to accomplish one or more tasks. Every

task management function is a service requested by the Initiator to recover the Target

from task detected as error by itself. The Target returns a response to the requested

function as completed, rejected or as a delivery/Target failure preventing the command

to be delivered. A task is represented by the definition of the work to be performed by

the LUN in form of command or group of linked commands. The task object is either a

tagged task represented by I_T_L_Q nexus (gathering definition of work to be done by

the LUN) or untagged task represented by I_T_L nexus (gathering definition of work

to be done by the LUN with a task attribute (x)). A tag is described as a field

containing up to 64 bits representing a component of I_T_L_Q nexus. The nexus

object describes a relationship between a SCSI Initiator port, a SCSI Target port, and

optionally a task and a LUN.

Figure 20 Mapping Task Management Function (Ref 6)


Page 27 of 100

The task management functions provided by the SCSI Target are as follow (Ref 6):

- “Abort Task” function: Service response = Abort Task ( IN(I_T_L_Q nexus))

This Function is required to be supported by LUN if it supports tagged tasks

and may be supported by LUN if it does not support tagged tasks. The task

manager shall abort the specified task if it exists.

- “Abort Task Set” function: (Service response = Abort Task Set ( IN(I_T_L

nexus))

In this function the task manager is required to abort all tasks in the task set

that were created by the Initiator. It shall be supported by all LUNs.

- “Clear ACA” function: Service response = Clear ACA ( IN(I_T_L nexus))

This function is to be implemented by LUNs that support tagged task and

optional for LUNs that do not support tagged task.

- “Clear Task Set” function: Service response = Clear Task Set ( IN(I_T_L

nexus))

This function is required to be supported by all LUNs, except if the LUN does

not support the tagged task or the LUN support the basic task management

model.

- “Logical Unit Reset”: Service response = Clear Task Set ( IN(I_T_L nexus))

This function required to be supported by all LUNs

- “Target Reset”: Service response = Target Reset ( IN(I_T nexus))

In this Function, an Initiator should issue “Logical Unit Reset” only to the

LUN it is using instead of issuing a “Target Reset”. This prevents resetting of

LUNs that other Initiators may issue.

- “Wakeup” : Service response = Target Reset ( IN(I_T nexus))


Page 28 of 100

This function may or may not be defined by SCSI protocol. It may be

supported by SCSI protocol that interconnection supports a shared wakeup

signal or individual wakeup signal for each SCSI Target port. It may also be

supported by SCSI devices on SCSI protocol supporting the function.

The task management function allows the Target to be more or less error free and

giving ability to the Initiator to prevent the Target from errors. But this function is not

sufficient to guaranty to the Target a complete error free.

To overcome efficiently the service requested by the Initiator task to recover the

Target from command detected as error, the SCSI error reporting method is used by

the Initiator.

2-7 SCSI error reporting

In the scenario where command completes successfully and passes all checking

conditions status even for error, for the SCSI good command operation, LUN should

make the sense data accessible to the Initiator via the following methods describing the

SCSI error reporting:

- The REQUEST SENSE command (shown below), sent from the Initiator,

instruct the Target device to transfer sense data to the application client.

Figure 21 The REQUEST SENSE command (Ref 7)


Page 29 of 100

- An asynchronous event report:

A LUN uses an asynchronous event reporting to signal the Initiator that one of

the following asynchronous events has occurred (Ref 7).

1- An error condition happened after command completion

2- A newly initialized device is available

3- Other type of unit attention condition has happened

4- An asynchronous event has occurred

- An autosense delivery:

It indicates an automatic return of sense data to the application client in relation

with SCSI command. If autosense request occurred and the SCSI transport

protocol or LUN do not support it, the Target device should specify no sense

data was returned. Therefore the application client shall issue a REQUEST

SENSE command in order to retrieve sense data.

The SCSI error reporting, in terms of efficiency, still affected by the type of low-level

(Ethernet, FC, internet protocol IP, etc..) transport protocol quality, used as main data

transfer medium from Initiator to Target device and vice versa. It is therefore crucial to

use an appropriate SCSI transport protocol when implementing a SAN to allow an

effective and efficient data transfer enabling a very low SCSI error reporting.

2-8 SCSI Transport Protocol

The limitations observed above, from the SCSI command model application down to

its error method reporting, related to the SCSI data transfer efficiency, bring to our

attention that implementing a robust SAN will require a dedicated SCSI transport

protocol to efficiently permit a data transfer over greater distances for greater number

of devices using different low-level interconnect, defined by standards organisation


Page 30 of 100

such as T10 (Technical committee on SCSI storage interface), the INCITS

(International Committee on Information Technology Standard) in collaboration with

IETF (Internet Engineering Task Force) (Ref 5 and 6). These respective organisations

put in place two main set of SCSI transport protocol approaches:

- The Fibre Channel

- The SCSI over Ethernet

2-8-1The Fibre Channel (FC):

- Basic of FC topologies

Developed by ANSI in 1988, FC is the general name of integrate set of

standards (Ref 7). It is a high speed data channel allowing bi-directional

connectivity between two ports. FC main objectives are to provides

multiple physical interface types

A support to connect these physical interfaces

High speed of data transfer

Prevention of logical protocol being transported over physical interface

Common physical interface as medium transport to multiple protocols

Efficient solution over growing set of physical interface toward

manufacturer multitude choices.

Fibre Channel devices are called nodes and are referred to N-port providing at

least one access to the outside world. Each N-port resides within a hardware

entity as shown in Figure22.


Page 31 of 100

Figure 22 Two Fibre Channel nodes connected through a Fabric (Ref 10)

Each F-port providing switch capability is also called FL-port.

In (Fig 21), for node A to talk to node B, the data is sent to F-port A, the

Fabric then makes an internal connection to F-port B, then the information is

passed to node B. With multiple existing nodes, different path may be used by

the data from node A before getting to node B.

FC model functionality is based on three basic topologies which are:

Point-to-point topology, where N-ports are directly connected to each

other permitting non-blocking connection.

Figure 23 Point-to-point topology (Ref 11)

Fabric topology, gathering multiple N-ports connected to at least one

switch via F-ports makes the FC network extensible.


Page 32 of 100

Figure 24 fabric topology (Ref 11)

Loop topology, using a maximum of 127 L-ports sharing a link

bandwidth.

Figure 25 loop topology (Ref 11)

- Basic of FC functionality

FC topologies are all govern by five hierarchical function levels allowing

devices connected to deal with specific functionality allocated to them for

reliable and testable links or recovering from missing frame (Ref 10):

The FC-0, defines the physical part of the FC (i.e. connectors needed

for ports)


Page 33 of 100

The FC-1, defines the transmission protocol of the FC (i.e. errors

detection)

The FC-2, defines the signalling and framing protocol of the FC (i.e.

frame header content)

The FC-3, defines the common services between ports and nodes of the

FC

The FC-4, defines the mapping on both traditional channels and

traditional networks called upper-level protocols.

Figure 26 CF functionality hierarchical structure levels (Ref 10)

- Basic of SCSI over FC:

The FC implementation helps extend the SCSI bus data transfer; it allows

SCSI-3 devices to communicate over FC interface at greater distance and

throughput at the upper-level protocols level. This communication process is

achieved through the SCSI Fibre Channel Protocol (SCSI-FCP) defined by (4)

management functions:

Link management


Page 34 of 100

Task management

Device management

Process login/logout management

Both, device and task management, defined the SCSI function mapping shown

in Figure 27 table below.

Figure 27 mapping function between SCSI and FC (Ref 10)

The above mapping function allows, in the contrary of simple SCSI data transfer, an

effective greater distance and throughput data transfer using the SCSI-FCP at the

upper-level protocol. But SCSI data transfer based on FC protocol (SCSI-FCP)

compare to the SCSI over Ethernet (SCSIoE) shows that SCSIoE has better efficiency

in terms of distance and throughput of data transfer in particular using Internet SCSI

(iSCSI).

2-8-2 The SCSI over Ethernet (SCSIoE) or over IP-networks:

The increasing use and development of SCSI-FC dragged us towards the concept of

Storage Area Networks (SAN) using the Transmission Control Protocol / Internet

Protocol (TCP/IP) as protocol for data transfer and then the development concept of

SCSIoE infrastructure has emerged. The most popular proposed protocols that

transmit SCSI over Ethernet are the Internet SCSI (iSCSI) and the SCSI

Encapsulation Protocol (SEP).


Page 35 of 100

2-8-2-1 The SCSI Encapsulation Protocol (SEP):

In the SEP concept, the IP connection is enabling the “Connect and Negotiate”

message to the LUN, and then the “Negotiation Response” message will

indicate a connection establishment between the Initiator and Target devices,

allowing the Initiator transmitting SEP Header to the Target responding with

SCSI data, status or message. In this aspect the data flow control is similar to

the one in FC using the principle of SCSI data request from the Initiator

(packets transfer does not stop until after the receiver’s buffer overflow and

packets are already lost). But the downside with the SEP is that, it does not

operate error recovery for eventual dropped connection.

2-8-2-2 The Internet SCSI (iSCSI):

The iSCSI was developed by the Internet Engineering Task Force (IETF). Its

draft was initiated by IBM and CISCO in January 2000 and submitted to the IP

Storage group of IETF in August 2000 for standardization (Ref 12). The most

obvious aspect now day is that data centres are quickly moving from

distributed to centralized storage. Therefore iSCSI taking that advantage

through a familiar SCSI and TCP/IP standard gives more benefits to customer

due its inexpensive implementation aspect in comparison to FC SAN

deployment.

a) iSCSI technology

The iSCSI is an IP-based storage networking connecting data storage devices.

As a transport protocol operating over TCP/IP, it facilitates and transmits SCSI

commands CDB over IP networks infrastructure encapsulated into Protocol


Page 36 of 100

Data Units (PDU) and handed over to TCP/IP protocol stack for delivery (see

Fig 28 below).

The iSCSI residing below the SCSI on the protocol stack as show in Figure28 is

described as the less expensive alternative protocol in comparison to FC.

Figure 28 iSCSI protocol stack (Ref 12)

Figure 29 SCSI / iSCSI data flow

In term of layer mapping, the iSCSI fits into the top 3 layers (Session,

Presentation and Application) of the Open System Interconnection (OSI)

model and its packet format is presented as shown in Fig 28:


Page 37 of 100

Figure 30 iSCSI packet format (Ref 13)

The iSCSI PDU header description fields will show that:

- The Opcode, (of 6 bits) indicates what type of iSCSI PDU the header begins,

and it separates values for Initiator PDUs and Target PDUs.

- The Opcode Specific, (of 24 bits) gives different meaning for different

Opcode Types.

- Length of data, (of 24 bits) determines the data segment payload length with

no padding.

- The LUN or Opcode-Specific, (of 64 bits) identifies the LUN for respective

operations or use Opcode-Specific way if Opcode not related to LUN.

- Initiator-task tag, (of 32 bits) determines the tag assigned by iSCSI Initiator

to each iSCSI task it issues.

- Opcode-Specific, (of 224 bits) determines the Opcode-Specific fields or

padding.

b) iSCSI naming

Initiator and Target require iSCSI names which are location dependent. The

iSCSI name is given following 2 methods:


Page 38 of 100

- Using the iSCSI Qualify Name (iqn) or

- Using the Extended Unique Identifier (eui)

Figure31 below shows the standard iSCSI naming structure.

Figure 31 iSCSI naming structure (Ref 13)

c) iSCSI discovery and addressing

As in SCSI and FC, iSCSI Initiators need to locate available Target and to do

so it will need an IP address, a TCP port number and iSCSI Target name

information in the scenario of small networks for static configuration.

In the discovery process, an Initiator log into an iSCSI Target using session

type of discovery then request a list of Target World Wide Unique Identifier

(WWUI) through SendTargets command. The iSCSI addressing method is

governed by both Target and Initiator session ID and its nodes identifying

Initiator and Target have respective network portal as shown in Figure 32.


Page 39 of 100

Figure 32 Relation between iSCSI portals and nodes (Ref 13)

A session takes place between a single iSCSI Initiator (host) and a single iSCSI

Target (server) and it consists of one or more iSCSI (TCP) connection with a

login phase follow by SCSI command deliver in order.

d) iSCSI error recovery

The iSCSI has three levels of Error Recovery (ER) which are level 0, 1 and 2

described as follow:

- ER level 0: Involving session recovery, closing all TCPs connecting an

initiator to the target and all pending commands on the SCSI are send with

appropriates error status, the new iSCSI session is started between initiator and

target.

- ER level 1: Involving level 0 capabilities and digest failure recovery,

occurring when iSCSI driver detects invalid data digest which need to be

rejected. Command related to that corrupted data will be completed with error

indication.

- ER level 2: Involving level 1 capabilities and connection recovery, is used

when TCP connection is broken then iSCSI driver complete the pending

command or transfer the SCSI command to another TCP connection.


Page 40 of 100

e) iSCSI data transfer model

The iSCSI model in Fig 30b shows iSCSI on TCP transport layer therefore in a

SAN concept, for an iSCSI Initiator to communicate with an iSCSI Target a

session needs to be established enabling exchange of data and commands

shown in Fig 30b. The iSCSI command execution has three phases: Data,

Command and Status response, described as follow:

- Command phase: the SCSI command defined by CDB (describing operation

of LBA and length of requested data negotiated by “MaxBurstLenght”

parameter) is encapsulated into an iSCSI command PDU.

- Data phase: During this phase, PDUs are sent from Initiator to Target. In

normal circumstances the Initiator must wait for the message “Ready to

Receive (R2T)” before sending the requested data but using the parameter

“FirstBurstLenght”, both Initiator and Target will accelerate data transmission

with no delay. Furthermore with “ImmediateData” parameter enables during

the parameter “Negotiation”, greater speed is reached over data transfer

allowing one data PDU to be embedded in the command PDU.

- Status response phase: It is the phase where messages are encapsulated into

TCP/IP packets size bounded by Maximum Segment Size (MSS), identified by

the smallest frame size sent to its destination, in TCP.


Page 41 of 100

Figure 33 iSCSI model and its command execution sequence (Ref 14)

For communication to be established between iSCSI Initiator and iSCSI Target, three

phases of session establishment are determined in the Current Stage (CSG) field of

iSCSI login PDU: Security Negotiation Phase (SNP), Login Operation Negotiation

Phase (LONP), and Full Feature Phase (FFP), using the iSCSI Login Request PDU

and the iSCSI Login Response PDU as shown respectively in Figure 34 and Figure 35

below.

Figure 34 iSCSI Login Request PDU (Ref 15)


Page 42 of 100

Figure 35 iSCSI Login Response PDU (Ref 15)

f) iSCSI security

In the use of SCSI over IP-network storage or iSCSI SAN, security concerns is

being addressed by the principal of iSCSI security based on security mechanism

and authentication methods, implementation providing protection against

passive and active attacks from hacker, described as follow (Ref 12).

- Security mechanism: The entities of iSCSI security are:

Initiator

Target

IP communication end point

For a scenario of multiple Targets, Initiators and IP communication end points,

iSCSI uses two different mechanisms:

In-band authentication between Target and Initiator through iSCSI

login connection to PDUs. It provides end-to-end trust between iSCSI

Initiator and Target.

Packet protection by IPsec at the IP level. It provides well secure

channel between IP communication end points.


Page 43 of 100

- Authentication methods: the authentication methods used for iSCSI security

implementations are as follow (Ref 12):

Challenge Handshake Authentication Protocol (CHAP):

Using a three way handshaking, CHAP is used to periodically verify

identity of the peer. It also provides security against playback attacks by

peer using incrementally changing identifier. CHAP authentication is

based on the “secret” which is not sent over the link is known only by

the authenticator and the peer.

Figure 36 CHAP authentication process (Ref 16)

Secured Remote Password (SRP):

SRP is used to negotiate secure connections, via user supplied

password, tackling issues related to reusable passwords. It performs

secure key exchange authentication for security layers involving privacy

and integrity protection enable during session.

Kerberos Version 5 (KRB5):

Kerberos performs authentication under identities verification of

workstation user or a network server on unprotected network by using

conventional cryptography like shared secret key.

Simple Public Key Mechanism 1 and 2 (SPKM 1 & 2):


Page 44 of 100

Using public-key infrastructure, SPKM 1 & 2 permits authentication,

data confidentiality, and data integrity via online distribution. Also

applications using security through Generic Security Services

Application Program Interface (GSS-API) calls can use SPKM as a

drop-in replacement.

Digests:

Enable checking of end-to-end. It is characterized by non-cryptographic

data integrity beyond checks provided by the link layers covering

communication path and element which may change the network level

PDU.

Internet Protocol security (IPsec):

IP security is used for encryption and IP level protection using

authentication header (AH), encapsulation security payload (ESP), and

internet key exchange (IKE). IPsec is a set of protocols implemented by

IETF to enable secure exchange in IP layer and virtual private network

(VPN). It supports two encryption methods: Transport and Tunnel.

iSCSI as described above through its technology, error recovery and data security

aspect is an ideal SCSI data transfer protocol in terms of cost effective, data

transfer throughput, data integrity, and data security in comparison with FC data

transfer protocol for a SAN implementation.

2-9 iSCSI, and FC relying on SCSI architecture as support for SAN

SAN provides block-oriented I/O data transfer between Target and Initiator. It may

use FC or iSCSI for host and storage connectivity for scalability, availability, and

security of data transfer. Also iSCSI and FC use SCSI architecture models as basis for


Page 45 of 100

efficiency of commands transfer using two principal SCSI model s: SCSI Distributed

service model and client-server model. Both SCSI command transfer models are

therefore used by iSCSI and FC to support SAN requiring a dedicated SCSI transport

protocol to permit data transfer over greater distances for greater number of devices

using software architecture as shown in Figure 37 and Figure 38.

Figure 37 SAN relaying on iSCSI or FC for data transfer protocol (Ref 17)

Figure 38 Storage transport protocols (Ref 17)

The description of the SCSI through our project primarily session has guided us

towards the use of iSCSI protocol as data transfer for the implementation of our SAN


Page 46 of 100

due to the reliability, cost effective, robust security, scalability and availability of its

network technology called iSCSI SAN.


Page 47 of 100

3. Work Completed

To emphasize over the investigation for application of different SAN topologies,

second session of our project, as stated in our introduction, we will mainly describe the

component of a standard iSCSI SAN, expose over the iSCSI SAN topologies and

explain our best appropriate SAN topology application to be used for the iSCSI SAN

we intend to implement based on the requirement and devices available to us in the

laboratory (Lab).

3-1 Component of standard iSCSI SAN

The standard iSCSI SAN system has two main entities: Hardware and software entity.

The hardware entity has at least four components listed as follow:

- iSCSI Initiator, it resides on the device that handles communication with the

iSCSI Target .

- iSCSI Target: it could be a server

- One or more servers

- Ethernet network

The software entity: It is defined by a typical OS used and can be Linux based-

software (OpenFiler) or Windows server Installed on the iSCSI Target (server).

3-2 different iSCSI SAN topologies using RAID system storage

Based on our Laboratory requirement and using a point-to-point topology, the iSCSI

SAN topologies will only differ over the use of different Redundant Array of

Independent Disk (RAID) allowing specific performance to the disk drives installed

inside the iSCSI Target device (server).


Page 48 of 100

RAIDs basics:

RAID either divides or duplicates the task of one hard disk and helps improve its

performance by creating redundancy. RAID technology mainly allows performance

like:

Stripping: Which permits data splitting between multiple drives and its

aim is to merge maximum capacity in one volume disk. We have RAID

0 which stripes data between each disk and require at least two disks.

Mirroring: Allows copy of data of more than one disk. Mirrored RAID

arrays allow failure of a disk without loss of data depending on the

RAID level. We have RAID 3 which applies disk mirroring and require

at least three disks.

Fault tolerance: Permits the RAID array to continue working even

when disk failure occurs. We have RAID 6 applying fault tolerance and

require at least three disks.

There are many standards RAID levels based on the number of disk and performance

or combined performance used with iSCSI SAN topology.

3-3 iSCSI SAN topology:

The topology therefore to be used for our iSCSI SAN, based on the ideal hardware

and software entities will be a point-to-point topology described in Figure 39 and

composed as follow:

One iSCSI Target as server mounted with three hard drives of

respectively 160 GB, 80 GB and 80 GB interconnected with Serial

Advanced Technology Attachment (SATA) cables ready for RAID 3

performance with mirroring capability. iSCSI Target will be loaded with


Page 49 of 100

Linux software-based (OpenFiler 2.99.1 to be precise) and will have

Network Interface Card (NIC) installed for Local Area Network (LAN)

or internet connection.

The Target will have as features:

8 GB RAM, 320 GB HD (for total hard drive capacity),

Pentium 4 as processors at 2.49 GHz CPU speed,

Cache size of 3.00 MB

One iSCSI Initiator as host or client ideally running windows XP or 7

as OS and will have NIC installed to enable LAN or internet

connection.

Ethernet Network using Network Interface Card (NIC) installed on

Client and Server devices to allow connection over the LAN or internet

to permit communication and data transfer via TCP/IP, used by iSCSI

protocol, between both devices iSCSI Initiator and iSCSI Target.

Figure 39 iSCSI SAN point-to-point topology

- Client and Server OS selection:


Page 50 of 100

Client OS Software:

As stated above, the Client (Initiator) device will use Windows 7 as OS in the

sense that it will help us configure the iSCSI Initiator to connect with the iSCSI

Target using its preinstalled iSCSI tool “iSCSI Initiator properties” from

“Control Panel”.

Server OS Software:

Also as stated above, after going through the installation of CentOs 6.5 and

FreeNAS 9.2 with no success (problem related to disproportionate disk

capacity configuration, SATA incorrect disk interconnection and device

hardware requirements not met) to administratively configure and control the

server remotely, we will use OpenFiler 2.99 (a Linux Operating System open

source free software) with the following hardware minimum requirements:

Host device must have x86 or x64 based computer with at least 500 MHz

CPU, 256 MB of RAM, 10 GB of HD capacity (8 GB for OS installation and 2

GB for swap space) and an optical drive for local installation.

An Ethernet Network Interface, a CDROM or DVD-ROM drive for local

installation, a hardware RAID disk array controller for optimal performance.

From the iSCSI SAN topology designed and described in Fig 33, and using

appropriate component and software requirement for iSCSI Target and iSCSI Initiator,

we will implement our iSCSI SAN using effective equipments to make it practical and

useful.


Page 51 of 100

4. Implementation

We will proceed over our iSCSI SAN implementation following three steps:

- iSCSI Target (server) disks mounting

- OpenFiler software installation on server

- iSCSI Target (server) disks configuration from client device

4-1 iSCSI Target (server) disks mounting

Using the following disks, we mount them inside the Server tower as shown in Fig-

imp1:

- 161 GB (Samsung HD161HJ) disk-1

- 80 GB (HDS728080PLA380) disk-2

- 80 GB (HDS728080PLA380) disk-3

Figure 40 three Hard Drives (HDs) mounted inside the Server tower

Then we join SATA cable (1, 2 and 3) from respective disk to the motherboard as

shown in Fig-imp2.


Page 52 of 100

Figure 41 SATA cables connecting respective disk to motherboard

Mounting properly the server with appropriate disks will help avoid any technical miss

functionality of the server and allow accurate communication and data transfer

between iSCSI Target (server) and iSCSI Initiator (client).

4-2 OpenFiler software installation on Server

Using OpenFiler website, http://www.openfiler.com/community/download, we

download OpenFiler NAS/SAN appliance, version 2.99, x86/64 architecture, of IOS

image type and save it on a blank compact disk (CD). We then install it on disk-1 of

the Server using its CDROM drive as described by installation steps and figures below.

OpenFiler installation steps:

- 1/ Start of OpenFiler screen installation loading the software.

http://www.openfiler.com/community/download


Page 53 of 100

Figure 42 OpenFiler screen installation

- 2/ Selection of appropriate keyboard for system as UK

Figure 43 OpenFiler selection system keyboard

- 3/ Selection of boot locater as x86_64 OS

Figure 44 OpenFiler selection of boot locater

- 4/ Selection of network setting automatically via DHCP


Page 54 of 100

Figure 45 OpenFiler Selection of network setting

- 5/ Selection of time zone as London

Figure 46 OpenFiler selection of time zone

- 6/ Use of “openfiler” as root password

Figure 47 Use of “openfiler” as root password

- 7/ Start of OpenFiler files installation


Page 55 of 100

Figure 48 Starting of OpenFiler files installation

- 8/ Installation of OpenFiler files in progress

Figure 49 Installation of OpenFiler files in progress

- 9/ Confirmation of OpenFiler successfully installed on Server

Figure 50 Confirmation of OpenFiler successfully installation

- 10/ Booting up of OpenFiler on Server


Page 56 of 100

Figure 51 booting up of OpenFiler on Server

- 11/ Confirmation of successful boot up of OpenFiler

Figure 52 confirmation of successful boot up of OpenFiler

- 12/ OpenFiler welcome screen page on Server

Figure 53 OpenFiler welcome screen page on Server

- 13/ OpenFiler welcome screen page details showing version and GUI


Page 57 of 100

Figure 54 OpenFiler welcome screen with GUI website address

4-2 iSCSI Target disks configuration from client device

In this server disks administration part of the iSCSI SAN implementation, we will

focus on the following steps and figures below to create a physical iSCSI Target

volume accessible from an iSCSI Initiator.

By login into OpenFiler web administration GUI at https://10.62.0.25:446/ from the

web browser of the iSCSI Initiator (client), using “openfiler” as username and

“password” as password, we will:

- 1/ Create a disk partition:

From the “volumes” tab we open the “Block device manager”. It shows all

disks available on the server with a preinstall partition on one disk, done

automatically from the OpenFiler software installation, and the other two disks

with no existing partition. We then use the disk labelled “gpt” entire capacity to

create a new disk partition as shown below on Figure 55, Figure 56 and Figure

57.

https://10.62.0.25:446/


Page 58 of 100

Figure 55 Block device showing list of disks mounted on server

Figure 56 Server disk labelled “gpt” proceeded with partition

Figure 57 Block device showing disks labelled “gpt” with one partition


Page 59 of 100

- 2/ Create a new volume group:

In this step, we create a new volume group called “freesan” using “add

volume” tab as shown on Figure 58 below.

Figure 58 New volume group created, called “freesan”

- 3/ Add a volume in the new volume group:

In this step, we will add a new volume called “Myvolume” of 15 GB from the

volume group called “freesan” using “add volume” tab as shown on Figure 59

and Figure 60 below.

Figure 59 New volume added in “freesan” called “Myvolume” of 25GB


Page 60 of 100

Figure 60 List of new volumes created in volume group “freesan”

- 4/ Add a new iSCSI Target volume with its name and settings:

This step will help us configure and attribute an “IQN” name (iqn.2006-

01.com.openfiler:tsn.14d8985c1ad8) to the new volume “Myvolume” making

it a new iSCSI Target volume from “Target configuration” tab as shown in

Figure 61below.


Page 61 of 100

Figure 61 new volume “Myvolume” configuration with IQN name

- 5/ Map LUN to the new iSCSI Target volume:

This step will allow us to map the new iSCSI Target volume created, giving it a

Logical Unit Number Id (LUN Id) as “3” and enable other possible iSCSI

Initiator to access it. Figure 62 and Figure 63 describe the process below, using

“LUN Mapping” tab.


Page 62 of 100

Figure 62 unmapped new iSCSI Target volumes with no LUN Id

Figure 63 unmapped new iSCSI Target volumes with no LUN Id

- 6/ Set the Access Control List (ACL) for the new iSCSI Target volume:


Page 63 of 100

To restraint access of some client device to the new volume created, this step

will help us deny access to any iSCSI Initiator (client) which is not within the

network address set to the iSCSI Target volume created (Network address

10.62.0.0 in this case) by using “Network ACL” tab as shown in Figure 64

below.

Figure 64 Network ACL applied to new iSCSI Target volumes

- 7/ Set the CHAP authentication for the new iSCSI Target volume:

To impose a strong security measure and mitigate attacks from hackers against

the new iSCSI Target volume created, this step will help implement credential

measure (requesting username and password) for accessing Target volumes by

using “CHAP authentication” tab as shown on Figure 65 below.


Page 64 of 100

Figure 65 CHAP authentication configuration on new iSCSI Target volume

- 8/ Set the server services to enable and run the “iSCSI Target” service:

Finally, this step will help enable and run, from “Services” tab, the iSCSI

Target service, allowing communication and data transfer between iSCSI

Target volumes and iSCSI Initiator (client) as shown on Figure 66 below.


Page 65 of 100

Figure 66 Enabling and running of iSCSI Target sService

The iSCSI Target disks configuration has shown that disk partition and security

measures apply to it as CHAP authentication process, to prevent unauthorized access

to Target volumes, are the key steps for effective and secure communication and data

flow connecting iSCSI Initiator to an iSCSI Target disk volume and vice versa creating

an effective iSCSI SAN ready to be used. Therefore, through our iSCSI SAN testing

implementation, we will verify the effectiveness of connectivity between an iSCSI

Initiator (client) and a specific iSCSI Target (server) volume created, enabling

communication and data transfer from one device to another in both directions.


Page 66 of 100

5. Testing

The aim of our iSCSI SAN testing is to show effectiveness of connectivity between an

iSCSI Initiator (client) and an iSCSI Target (Server) disk volume created for the

purpose, using user (client) credentials (username and password) for CHAP

authentication as security measure. Therefore, we will configure the iSCSI Initiator

(client) device running windows 7 as OS and connect it to the iSCSI Target particular

disk volume using user (client) credentials for authentication. To do so we will proceed

by two steps:

- 1/ iSCSI Target volume Discovery (using iSCSI Initiator Properties)

- 2/ iSCSI Target volume Initialization and formatting process (using Disk

Management)

5-1 iSCSI Target volume Discovery

- A) We create on iSCSI Target (server) disk, labelled “gpt”, a new volume called

“ZoudeVolume” of “5 GB” capacity with “IQN” name: iqn.2006-

01.com.openfiler:tsn.e514290910ed. We map it with LUN Id as number “4”

(establishing a new iSCSI Target) we then permit all devices within network address as

10.62.0.0 full connectivity, by enabling “Network ACL” and create four types of

CHAP authentication credentials allocated to it for security access measure as shown

in Figure 67


Page 67 of 100

Figure 67 Target iqn.2006 01.com.openfiler:tsn.e514290910ed2 credentials

- B) From our device (ACER laptop, running windows 7 as OS and with IP address:

10.62.0.14) used as iSCSI Initiator, we open “Control Panel”, “Administrative

Tools” and then “iSCSI Initiator”. From “iSCSI Initiator Properties” screen, we

type in the iSCSI Target IP address (10.62.0.25) within “Target” option space and

click on “quick connect” as shown on Figure 68 below.


Page 68 of 100

Figure 68 Inactive Target: iqn.2006-01.com.openfiler:tsn.e514290910ed

Figure 68 shows clearly the new iSCSI Target volume named iqn.2006-

01.com.openfiler:tsn.e514290910ed is not yet active (cannot be used). We therefore

need to activate it and allow its discovery from our device ACER (iSCSI Initiator),

using appropriate user credentials for CHAP authentication.

- C) As stated above, from iSCSI Initiator properties screen, we select “iqn.2006-

01.com.openfiler:tsn.e514290910ed” from “Discovered targets” list and click on

“connect”. Then from “Connect To Target” screen we press “OK” to display

“Advanced Settings” screen allowing us to type in the user credentials (Username:

Admi1and Password: Admin.Cisco05) for CHAP authentication permitting

connection and discovery of the new iSCSI Target (iqn.2006-

01.com.openfiler:tsn.e514290910ed) as shown on Figure 69, Figure 70 and Figure

71 below.


Page 69 of 100

Figure 69 Selection of inactive iSCSI Target

Figure 70 Connection to inactive Target using appropriate credentials


Page 70 of 100

Figure 71 Target “iqn.2006-01.com.openfiler:tsn.e514290910ed” connected

But to enable full access to the new iSCSI Target “iqn.2006-

01.com.openfiler:tsn.e514290910ed”, it must be initialized and formatted to then allow

access from iSCSI Initiator (Our ACER laptop device).

5-2 iSCSI Target volume initialization and formatting process

- A) Again opening “Control Panel”, “Administrative Tools”, “Computer

Management” and then “Disk Management” we initialize the new disk volume

(iqn.2006-01.com.openfiler:tsn.e514290910ed) as “Disk 16” and choose Master

Boot Record (MBR) for partition style as shown in Figure 72 below.


Page 71 of 100

Figure 72 Initialization of disk volume and selection of MBR partitioning

- B) Next, from “Disk Management” we right click on the “Unallocated” disk and

select “New Simple Volume” opening “New Simple Volume Wizard” screen to start

Disk 16 partition using MBR style as shown on Figure 73 and Figure 74.

Figure 73 Selection of unallocated “disk 16” for MBR partitioning


Page 72 of 100

Figure 74 Starting of “New Simple Volume Wizard”

- C) Then, going through the “New Simple Volume Wizard”, we specify the volume

size at “5021 MB” (5 GB), assign a drive letter “K” to the partition, choose the format

partition as New Technology File System (NTFS) and finally complete the New

Simple Volume Wizard (for disk formatting process) by clicking on “Finish” option,

as shown on Figure 75, Figure 76, Figure 77, and Figure78.

Figure 75 New volume size specification at 5021 MB


Page 73 of 100

Figure 76 Drive letter “K” assigned to the new volume for partitioning

Figure 77 Partitioning process of volume “K” using NTFS


Page 74 of 100

Figure 78 new volume disk “K” partition completed

The iSCSI Target volume discovery, initialization and formatting process, allow the

complete display of the new volume disk (iqn.2006-

01.com.openfiler:tsn.e514290910ed) created on the server disk (labelled: gpt) to be

virtually visible on the iSCSI Initiator (Client) screen as “New Volume (K)”, ready to

be fully used as shown on Figure 79 below.

Figure 79 “ZoudeVolume” on Server, shown as new volume (K) on Client


Page 75 of 100

Through our testing, we clearly described the effectiveness of connectivity between the

iSCSI Initiator (Client: our ACER device) and the iSCSI Target (Server) new volume

disk (iqn.2006-01.com.openfiler:tsn.e514290910ed) created. The connectivity was

enabled using user credentials (Username: Admin1 and Password: Admin.Cisco05)

for CHAP authentication, implemented to mitigate hacker attacks or unauthorized

access to the iSCSI Target (Server). But can CHAP authentication security measure

and other available iSCSI SAN security hardening tools guaranty its complete security

against technical sophisticated hacker attacks that mostly tend to prevent its

connectivity, therefore its full functionality?

We will try through an analysis over the iSCSI SAN implementation testing result,

based on its functionality and its security aspect, to emphasize over the iSCSI SAN

connectivity establishment and its security vulnerabilities, and then propose some

security threat countermeasures to tackle these vulnerabilities or security issues.


Page 76 of 100

6. Analysis and Review

Through this analysis we will demonstrate how we did achieve our objectives through

the effectiveness of our iSCSI SAN establishment and connectivity. To do so, we will

use two principal analyses:

- The iSCSI SAN establishment and connectivity analysis

- The iSCSI SAN security analysis

6-1 The iSCSI SAN establishment and connectivity analysis

This analysis will allow us to demonstrate the mechanism used by the iSCSI

communication protocol to effectively connect our two main devices used to

implement the iSCSI SAN, through the SCSI as support for data transfer medium.

6-1-1 Use of SCSI Terminology

Our iSCSI SAN implementation test result indicates that we effectively used a SCSI

Initiator (host running Windows 7 as OS) starting the I/O process (as request) and a

SCSI Target (Server running OpenFiler a Linux software-base) responding to the

request with I/O process. This process is determined by an establishment of a session

as main communication link between iSCSI Target (server) and iSCSI Initiator (host

or client) as described in (2-2).

6-1-2 Use of SCSI architecture model

The iSCSI SAN point-to-point topology used has the characteristics of an SCSI

Client-Server model, where by the Ethernet network (using IP address through

standard NIC and TCP/IP) allows the iSCSI Initiator (client) with multiple application

to communicate with the iSCSI Target (server) executing the task management role

and holding one or more LUNs as volume disk as described in 2-3-2.


Page 77 of 100

6-1-3 use of SCSI command models and their format

The SCSI command generated by the Initiator is executed when sent as Command

Descriptor Block (CDB) to the Target. Then the CDB with a specific length is passed

from either an application or a file system to the iSCSI device driver where it is

encapsulated into Protocol Data Unit (PDU) and transfers to the TCP/IP protocol sack

to be delivered, identifying the SCSI/iSCSI data flow, following the eight distinct

phase sequences as described in (2-4).

6-1-4 Use of SCSI Target operation

The SCSI Target deal with the SCSI Initiator request through a “service response”

allowing the identification of iSCSI Initiator port (identify by its respective IQN name)

by respective iSCSI Target id (detected by its respective IQN name) and LUN “task

address” command to which the CDB is addressed and this session is dependent of the

physical connections as described in (2-5).

6-1-5 Use of SCSI Task management and for error reporting

Task management of SCSI is used identically by the iSCSI Initiator to complete one or

more task and allow the iSCSI Target to identify and recover from command with

error. A typical example of iSCSI Target identified error command is an iSCSI

Initiator sending CDB command related to inappropriate credential (detected as error)

for Target LUN (volume) authentication with a failed response providing task

management function as “Abort function” function , described in (2-6 and 2-7).

6-1-6 Use of SCSI architecture by iSCSI SAN for data transfer

The SCSI transport protocol used to enable data transfer between SCSI Target and

SCSI Initiator is mainly used by the iSCSI protocol encapsulating SCSI command


Page 78 of 100

descriptor blocks (CDBs) into PDUs and transfer by TCP/IP (IP network). From 6-1-3

to 6-1-5, we have seen effective establishment of connection taking place between

iSCSI Target and iSCSI Initiator from respective port to port through respective

identified single IQN name.

6-1-6-1 The iSCSI Single session connection process

Using the iSCSI SAN testing scenario used in chapter (5.), the establishment of

communication session between the iSCSI Target (Server) and the iSCSI Initiator

(Client) was made possible through the target disk configuration implementation in (5-

2) where a new volume disk was created and attributed with a single IQN name as:

iqn.2006-01.com.openfiler:tsn.e514290910ed (attributed to a new volume disk in

Figure 67).

From the Initiator, that wants to communicate with a specific Target, it will send to the

Target DataSegment field of its login PDU, the appropriate IQN name, therefore

initiating a security negotiation phase (SNP) for a login request PDU, with no security

through CHAP taking place. The successful login PDU generate a connection ID

(CID) set by the Initiator for session connection (called Portal) from one IP address

(and TCP Port) to another, between Target (10.62.0.25) and Initiator (10.62.0.14) as

shown in Figure 79. The login process between both devices is a simple handshaking of

keywords and possible values, verified in Figure 33.But going through a security

negotiation like CHAP authentication, the Initiator will set its login request CSG field

to Login Operational Negotiation Phase (LONP) to initiate user authentication using

appropriate credential as verified in Figure 70 for the CHAP authentication process

creating a session connection.Then for full connectivity between Server and Client,

involving data transfer, the iSCS SAN establishment session goes in Full Feature Phase


Page 79 of 100

(FFP) as stated in (2-8-2-2 e). This aspect demonstrates that iSCSI SAN uses SCSI as

support for its functionality and also justify its full connectivity taking place between

iSCSI Target (Server) and iSCSI Initiator (Client).

6-1-6-2 The iSCSI Multiple sessions connection process

To enable multiple connections for an iSCSI SAN a Portal Groups will be used and for

a Groups of Target Portals with multiple connections for the same session, a common

ID is attributed and a single Initiator Session ID (ISID) will be set by the iSCSI

Initiator to identify each session connection.

Our iSCSI SAN establishment and connectivity analysis through the different

objectives set above, has demonstrated an achievement over the effectiveness of

connectivity of the implemented and tested iSCSI SAN. But how Network Attached

Storage (NAS) and Fibre Channel (FC) implementation for storage network are less

advantage in comparison to iSCSI SAN?

6-2 The iSCSI SAN data transfer protocol advantages

- In comparison with Fibre Channel SAN (FC-SAN):

As described above on (2-8-1), a simple FC-SAN is composed of single switch

fabric connected to a single management Local Area Network LAN through

IP. It provides multiple physical interface types allowing high speed of data

transfer. But in terms of data transfer protocol quality, iSCSI SAN has IP as

most widely used networking protocol, distributed naming service for more

resilient, allows modification of physical network without disturbance of

network communication, allows multiple physical connections per logical

connection between end device and storage.

- In comparison with Network Attached Storage (NAS):


Page 80 of 100

For a NAS sever or gateway, the principal consist of the use of preconfigured

file server on one or more internal servers with preconfigured disk capacity

usually connected via Ethernet to the LAN. NAS allows data sharing and

works only with qualified applications.

Therefore in comparison to its efficiency of data transfer, the iSCSI SAN has

high availability, data transfer reliability, reduced traffic on the primary

network, configuration flexibility, high performance, high scalability, and

centralized management.

6-3 The iSCSI SAN security analysis

To emphasize over the question asked just above, related to the iSCSI SAN testing

result for effectiveness of its connectivity through the use of CHAP authentication,

using user credentials, we will show, despite a CHAP authentication or other security

measures implemented, that a iSCSI SAN still vulnerable against hacker attacks using

a “Port Scanning” method, to exploit its open ports. The iSCSI SAN security

vulnerability will allow us to discuss over its security issues and propose some security

vulnerability countermeasures to mitigate most hacker attacks against iSCSI SAN

functionality which can be assimilated to a cloud system providing online storage to its

users.

6-3-1 iSCSI SAN security vulnerability

The iSCSI SAN can provide online storage using virtual disk availability through

specific network via internet. iSCSI SAN has more or less a cloud system functionality

using a server for disk storage accessible by any user with allocated credentials for

authentication prior any use of the server services. In that aspect, to show our iSCSI

SAN security vulnerability, we will implement a penetration testing attack using


Page 81 of 100

BackTrack 5 and MetaSploit 4.5.0 hacking tools to operate a port scanning activity

over the iSCSI Target (iSCSI SAN Server) and exploit its open ports vulnerability.

A) Port scanning over iSCSI SAN ports

- Using BackTrack 5, we select a pool of IP address within the hacker network

address from 10.62.0.0 to 10.62.0.30 and apply “nmap –sP 10.62.0.0-30” command

to perform a host sweep and identify which hosts are up as shown in Figure 80.

Figure 80 Detection of live hosts using “nmap –sP 10.62.0.0-30” command

The result in Fig-Ana1 shows the hacker IP address (10.62.0.14) and the potential

victim (server) IP address (10.62.0.25), as live hosts among others.

- Next, we use command “xprobe2 10.62.0.25” for Operating System (OS)

fingerprinting on the victim (iSCSI SAN server) to fully identify its OS as shown in

Figure 81 and Figure 82, giving details information over the OS running on the server

device as Linux Kernel 2.4.30.


Page 82 of 100

Figure 81 Fingerprinting on 10.62.0.25 (iSCSI SAN server) (1)

Figure 82 Fingerprinting on 10.62.0.25 (iSCSI SAN server) (2)

- Then in the nest command we operate and effective port scanning using “nmap –sT

10.62.0.25” command showing opened ports (22/TCP ssh, 111/TCP rpcbind,


Page 83 of 100

3260/TCP iscsi, 5989/TCP wbem-https) on our iSCSI SAN server which is therefore

expose to hacker attacks for exploitation, as displayed in Figure 83 below.

Figure 83 iSCSI SAN server (10.62.0.25) ports scanning

B) The iSCSI SAN ports vulnerability exploitation and other security issues

- To exploit the iSCSI SAN server ports vulnerabilities, we will use MetaSploit 4.5.0

through several commands for appropriate exploitation setting and finally complete the

exploitation using “exploit” command showing by the reverse shell and a backdoor

command been launched from the hacker device (10.62.0.14:43983) to the iSCSI SAN

server (10.62.0.25:446) allowing possible hacking of the server by the hacker using

open ports vulnerability as shown in Figure 84.


Page 84 of 100

Figure 84 Exploitation of iSCSI SAN using “exploit” command

The above two steps (port scanning and exploitation) allowing hacking activity over

the iSCSI SAN server has shown effective vulnerability of the implemented SAN. The

iSCSI SAN server port vulnerability allows us to emphasize on its other common

security threats used by hacker, as listed below (Ref 18):

- Denial of service (DoS) attack: Hacker use this attack to overflow the iSCSI

SAN network or server with frequent request of service to damage the

network.

- Network sniffing: this type of attack, allow hacker to intercept unencrypted

data communication or packet from Client (iSCSI Initiator) to Server (iSCSI

Target) and vice versa.

- Man in the middle attack: this attack occurs when the secure socket layer

(SSL) is not properly configured, allowing hacker to intercept communication

between two parties (Client and Server). Hacker use layer 2 address resolution

protocol (ARP) poisoning attack to create a fake iSCSI Simple Name Services


Page 85 of 100

(iSNS), which is the software running on the iSCSI device, to replace the real

iSNS and allowing him to view both iSCSI Initiator and iSCSI Target

registrations (IQNs) and modify security settings as shown in Figure 85.

Figure 85 Man in the middle (MITM) attack (Ref 18)

- Browser security attack: In this type of attack, hacker sniffs iSCSI Initiator

(Client) credentials using sniffing packet from Server web browser, permitting

SSL point-to-point communication, when Client log into Server.

- Flooding attack: It is an attack use by hacker emitting several nonsense

requests to a typical server service overloading the sever activities lowering

down its resources and become unable of dealing with normal requests from

users.

- The iSCSI authorization attack: for this type of attack, hacker can sniff iSCSI

communication on port 3260 to get the Initiator node name, change it and gain

access to sensitive data.


Page 86 of 100

- iSCSI authentication attack: In this attack, hacker targets CHAP authentication

to operate username sniffing and off-line brute force attack to identify

password as shown in Figure 86 and Figure 87.

Figure 86 iSCSI CHAP authentication attack (1) (Ref 18)

Figure 87 iSCSI CHAP authentication attack (2) (Ref 18)

The iSCSI SAN port scanning operated for its penetration testing (hacking test) and its

common security vulnerabilities listed above, have shown the iSCSI SAN security


Page 87 of 100

threats effectiveness. Therefore to mitigate these security threats we will propose most

appropriate iSCSI SAN security threat countermeasures to effectively and efficiently

tackle most hackers who tend to prevent good functionality of the iSCSI SAN

services.

6-3-2 iSCSI SAN security vulnerability countermeasures

To tackle the above iSCSI SAN security threats, the following security threat

countermeasures should be applied on the iSCSI SAN system to allow its good

functionality for data transfer efficiency and effective quality of service (QoS) provided

to users.

- Enable mutual authentication, on iSCSI devices (Initiator and Target) and use

random authentication methods.

- Create multiple iSCSI discover domains by using default domain sets with

random registrations.

- Enable on the iSCSI device the Cyclic Redundancy Check (CRC), an error-

detecting code for data raw changing used in digital network, for data integrity

check.

- Require iSNS IP Security (IPSec) where needed.

- Apply variation over iSCSI naming method for security authorization values.

- Enable iSCSI IPSec where possible.

- Enable authentication by default on iSCSI devices.

- Any iSCSI compliant device must implement IPSec with Encapsulating

Security Payload (ESP) in tunnel and transport mode to allow strong secure

data transport.


Page 88 of 100

- Implement strong firewall setting policy over iSCSI devices network to prevent

port attack and close automatically all devices unused ports.

- SSL must be well implemented and configured to avoid communication being

intercepted between iSCSI devices by hackers.

- Also strong data encryption method should be applied over iSCSI data transfer

to tackle communication sniffing from hackers.

These security countermeasures, listed above, will obviously create some very huge

advantages over the use of iSCSI SAN services by businesses and organizations.

6-4 iSCSI SAN security advantages

An iSCSI SAN, with a well implemented security system, brings an enormous

advantage to businesses using its services and this can be verified through the

following business characteristics:

- Increase of storage utilization and reducing total cost of operation.

- Lowers hardware acquisition cost by the use of standardized and inexpensive

Ethernet equipment as Local Erea Network (LAN).

- No cost related to IT staff training who are well familiar to TCP/IP technology.

Therefore no need of expert personnel to install, configure, and manage iSCSI

SAN network in the contrary of Fibre Chanel (FC) that needed most.

- The universal and non-proprietary technology aspect of IP, make iSCSI SAN

technology compatible to devices from different vendors and works seamlessly.

- Being an IP-based protocol, iSCSI benefits from the interoperability of TCP/IP

and Ethernet.


Page 89 of 100

- The iSCSI SAN offers a very simple network storage, based on its data

transfer protocol. Therefore organizations using Gigabit Ethernet network

components can simplify their network storage environment.

iSCSI SAN system security vulnerability and threat from hacker using very

sophisticated technical tools to prevent or damage its good functionality, therefore

efficient and effective data transfer from iSCSI Target to iSCSI Initiator and vice versa

via specific IP network, must be addressed through robust security threat

countermeasures to mitigate their negative impacts over the iSCSI SAN services for

effective improvement, quality of service towards the user, business growth and

continuity, allowing complete satisfactory and huge advantages on both side, iSCSI

SAN service providers and their clients (Users).


Page 90 of 100

7. Conclusion

Small Computer Serial Interface (SCSI) was initiated by the Shugart Associates

Systems Interface (SASI) in the 1979. Its widely use technology is due to the fact that

it gives complete device independence, allowing connection and effective data transfer

via mainly its client-server architecture model using less latency over command

transfer. But this rapid data transfer, through its command execution by eight distinct

phase sequences, is affected by the non-flexible process and the inability of the SCSI

bus of simultaneously being used by both devices, Target and Initiator. Add to this

limitation, the target command response quality to the Initiator request is dependent to

the flow control mechanism determined mainly by the low-level protocol. Therefore

for an effective task management function, giving the ability to the SCSI Initiator to

execute one or more task and prevent the SCSI Target from error, an appropriate

ISCSI transport protocol is needed through iSCSI. The implementation of our iSCSI

SAN, allowing the encapsulation of the SCSI Command Descriptor Block (CDB) by

iSCSI into PDU and transfer through TCP/IP to its destination, has shown an effective

connectivity between its end devices (iSCSI Initiator and iSCSI Target). The iSCSI

SAN connectivity test, describes an effective use of a server as iSCSI Target and a

client as iSCSI Initiator, connected in a point-to-point topology, through client-server

model architecture. Both end devices will be identified by a single IQN name enabling

from the Initiator a login request PDU generating a connection ID (CID). If successful,

a session connection from one end device IP address and TCP port to another will take

place, justifying effective connectivity. The iSCSI SAN, in comparison to FC-SAN and

NAS, is a cost effective, distributed naming service, allows multiple physical

connections, high availability, data transfer reliability and scalability. The iSCSI SAN


Page 91 of 100

has shown security vulnerability despite existing CHAP authentication and other

security measures for mainly data protection. Therefore it is highly recommended to

implement appropriate robust security threat countermeasures as listed in (6-3-2) to

allow iSCSI SAN business improvement, growth and continuity. But can an ideal

iSCSI SAN, in terms of technology and mechanism for data flow and quality of

throughput, completely free of security threat from hackers being implemented using

all available efficient devices and security tools?


Page 92 of 100

8. References

(Ref 1) Jon Tate, Geoff Cole, Ivo Gomilsek, Jaap van der Pijll (May 2000) Designing

an IBM Storage Area Network, IBM Corporation, International Technical Support

Organization Dept. 471F Building 80-E2 650 Harry Road San Jose, California 95120-

6099: IBM Corporation. Page25. Available at:

http://www.redbooks.ibm.com/redbooks/pdfs/sg245758.pdf

(Ref 2) Ancot (1998) What is SCSI?, fourth edition edn., Germany: Manhattan Skyline

GmbH, Wiesbadenerstr. 5a, D-65232 Taunusstein: Ancot Corporation. Available at:

http://www.mskl.de/CONTENT/PDF/Basics_of_SCSI.pdf

(Ref 3) Nabeel ur Rehman, Asad Asif, Junaid Iqbal (2014) SCSI Interface, Available

at: http://www.asadasif.com/es/files/scsi-report.pdf (Accessed: 02 January 2014).

(Ref 4) Computer Hope (2014) ATA, Available at:

http://www.computerhope.com/jargon/a/ata.htm (Accessed: 02 January 2014).

(Ref 5) David Deming, Alain Silber (2014) SCSI - the protocol for all storage

architecture, Available at:

http://www.cs.uml.edu/~bill/cs520/slides_07_scsisnia.pdf (Accessed: 09 January

2014).

(Ref 6) John B. Lohmeyer, George O. Penokie (22 March 2000) SCSI Architecture

Model - 2 (SAM-2), Ralph O. Weber ENDL Texas 18484 Preston Road Suite 102#178

Dallas, TX 75252 USA: T10 Technical Editor. Available at:

http://www.o3one.org/hwdocs/lsilogic/scsi_abstract_sam2r13.pdf

(Ref 7) Ashish A. Palekar, Robert D. Russell (May 2001) DESIGN AND

IMPLEMENTATION OF A SCSI TARGET FOR STORAGE AREA NETWORKS, New

Hampshire: University of New Hampshire.

http://www.redbooks.ibm.com/redbooks/pdfs/sg245758.pdf

http://www.mskl.de/CONTENT/PDF/Basics_of_SCSI.pdf

http://www.asadasif.com/es/files/scsi-report.pdf

http://www.computerhope.com/jargon/a/ata.htm

http://www.cs.uml.edu/~bill/cs520/slides_07_scsisnia.pdf

http://www.o3one.org/hwdocs/lsilogic/scsi_abstract_sam2r13.pdf


Page 93 of 100

(Ref 8) Ming Zhang (2014) A Not So Short iSCSI Tutorial, Available at:

http://www.cs.uml.edu/~bill/cs560/iSCSI_talk.pdf (Accessed: February 27, 2014).

(Ref 9) Hitachi (2003) SCSI Interface Specification, Tokyo, Japan: Hitachi, Ltd.

(Page 78, 223, 230, 241) Available at:

http://www.hgst.com/tech/techlib.nsf/techdocs/0F4CE416713866ED86256D490065B

F48/$file/15K73_SCSI_interface.pdf

(Ref 10) Gary Stephens and Jan Dedek (1995) Fibre Channel: The Basics,, 4th

Edition edn., Germany: ANCOT Corporation. Available at:

http://www.mskl.de/CONTENT/PDF/Basics_of_Fibre_Channel.pdf

(Ref 11) Raj Jain (2000) FIBRE CHANNEL, New Jersey: Fibre Channel Association:

American National Standards Institute (ANSI). Available at:

http://www1.cse.wustl.edu/~jain/cis788-95/ftp/fiber_channel.pdf

(Ref 12) Ron Dharman, Vinay Jonnakuti (2004) iSCSI SAN Topologies, California:

ECM TechBook. Available at:

http://uk.emc.com/collateral/hardware/technical-documentation/h8080-iscsi-san-

topologies.pdf

(Ref 13) CISCO System Inc (2004) iSCSI Design and Implementation. OPT-

2053 [Online]. Available at: http://www.cisco.com/networkers/nw04/presos/docs/OPT-

2053.pdf (Accessed: February 22, 2014).

(Ref 14) CISCO System Inc (2004) Storage Area Networking Protocols and

Architeture. OPT-T201 [Online]. Available

at: http://www.cisco.com/networkers/nw04/presos/tech/docs/OPT-2T01.pdf

(Accessed: February 22, 2014).

(Ref 15) Christopher Greene (2003) iSCSI Storage Protocol, NY: IETF IP Storage

Working Group.

http://www.hgst.com/tech/techlib.nsf/techdocs/0F4CE416713866ED86256D490065BF48/$file/15K73_SCSI_interface.pdf

http://www.hgst.com/tech/techlib.nsf/techdocs/0F4CE416713866ED86256D490065BF48/$file/15K73_SCSI_interface.pdf

http://www.mskl.de/CONTENT/PDF/Basics_of_Fibre_Channel.pdf

http://www1.cse.wustl.edu/~jain/cis788-95/ftp/fiber_channel.pdf

http://uk.emc.com/collateral/hardware/technical-documentation/h8080-iscsi-san-topologies.pdf

http://uk.emc.com/collateral/hardware/technical-documentation/h8080-iscsi-san-topologies.pdf

http://www.cisco.com/networkers/nw04/presos/docs/OPT-2053.pdf

http://www.cisco.com/networkers/nw04/presos/docs/OPT-2053.pdf

http://www.cisco.com/networkers/nw04/presos/tech/docs/OPT-2T01.pdf


Page 94 of 100

(Ref 16) Surendra Bhat, Lokesh Singh, Santosh Bhadri (2008) Securing iSCSI Storage

Networks. from Dell Power Solutions [Online]. Available at:

http://www.dell.com/downloads/global/power/ps1q08-20080132-Bhat.pdf (Accessed:

February 25, 2014).

(Ref 17) CISCO System Inc (2004) Introduction to Storage Area Networks (SAN).

SAN-1501 [Online]. Available at:

http://maben.homeip.net/static/computers/backup/SAN/cisco/SAN%20fundamentals/In

troduction%20to%20SAN%20SAN-1501(USA,2006).pdf (Accessed: February 25,

2014).

(Ref 18) Himanshu Dwivedi (2005) Securing iSCSI Storage Networks. iSEC Partner

[Online]. Available at: http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-

Dwivedi-update.pdf (Accessed: February 25, 2014).


Page 95 of 100

9. Table of Figures

Figure 1 Representation of typical SCSI system ............................................ 12

Figure 2 Principal SCSI Terminologies (Ref 5) ............................................. 13

Figure 3 Logical Unit Model (Ref 6) ............................................................. 13

Figure 4 Initiator device model (Ref 6) ......................................................... 14

Figure 5 Target device model (Ref 6) ........................................................... 14

Figure 6 SCSI Distributed Service model (Ref 5) .......................................... 15

Figure 7 SCSI Client-Service Model (Ref 5) ................................................. 16

Figure 8 Task Management Processing Events (Ref 6) .................................. 16

Figure 9 General format of CDBs except operation code 7Fh (Ref 6) ........... 18

Figure 10 Example of six byte CDB, READ command, Format (Ref 7) ........ 18

Figure 11 Description of SCSI READ command format (Ref 5) ................... 19

Figure 12 Different type of CDBs format (Ref 5) .......................................... 19

Figure 13 SCSI command PDU (Ref 8) ........................................................ 20

Figure 14 SCSI response PDU (Ref 8).......................................................... 20


Page 96 of 100

Figure 15 SCSI Phase sequences (Ref 7) ...................................................... 22

Figure 16 TEST UNIT READY command format (Ref 9) ............................ 22

Figure 17 ENQUIRY command format (Ref 9) ............................................ 23

Figure 18 REQUEST SENSE command format (Ref 9)................................ 23

Figure 19 SEND DIAGNOSTIC command format (Ref 9) ........................... 23

Figure 20 Mapping Task Management Function (Ref 6) ............................... 26

Figure 21 The REQUEST SENSE command (Ref 7) .................................... 28

Figure 22 Two Fibre Channel nodes connected through a Fabric (Ref 10) ..... 31

Figure 23 Point-to-point topology (Ref 11) .................................................. 31

Figure 24 fabric topology (Ref 11)................................................................ 32

Figure 25 loop topology (Ref 11) ................................................................. 32

Figure 26 CF functionality hierarchical structure levels (Ref 10).................... 33

Figure 27 mapping function between SCSI and FC (Ref 10) ......................... 34

Figure 28 iSCSI protocol stack (Ref 12) ....................................................... 36

Figure 29 SCSI / iSCSI data flow ................................................................. 36


Page 97 of 100

Figure 30 iSCSI packet format (Ref 13)........................................................ 37

Figure 31 iSCSI naming structure (Ref 13) ................................................... 38

Figure 32 Relation between iSCSI portals and nodes (Ref 13) ...................... 39

Figure 33 iSCSI model and its command execution sequence (Ref 14) .......... 41

Figure 34 iSCSI Login Request PDU (Ref 15) .............................................. 41

Figure 35 iSCSI Login Response PDU (Ref 15) ........................................... 42

Figure 36 CHAP authentication process (Ref 16) .......................................... 43

Figure 37 SAN relaying on iSCSI or FC for data transfer protocol (Ref 17) .. 45

Figure 38 Storage transport protocols (Ref 17) ............................................. 45

Figure 39 iSCSI SAN point-to-point topology .............................................. 49

Figure 40 three Hard Drives (HDs) mounted inside the Server tower ............ 51

Figure 41 SATA cables connecting respective disk to motherboard .............. 52

Figure 42 OpenFiler screen installation ......................................................... 53

Figure 43 OpenFiler selection system keyboard ............................................. 53

Figure 44 OpenFiler selection of boot locater................................................ 53


Page 98 of 100

Figure 45 OpenFiler Selection of network setting ......................................... 54

Figure 46 OpenFiler selection of time zone ................................................... 54

Figure 47 Use of “openfiler” as root password .............................................. 54

Figure 48 Starting of OpenFiler files installation............................................ 55

Figure 49 Installation of OpenFiler files in progress ...................................... 55

Figure 50 Confirmation of OpenFiler successfully installation........................ 55

Figure 51 booting up of OpenFiler on Server ................................................ 56

Figure 52 confirmation of successful boot up of OpenFiler ............................ 56

Figure 53 OpenFiler welcome screen page on Server .................................... 56

Figure 54 OpenFiler welcome screen with GUI website address .................... 57

Figure 55 Block device showing list of disks mounted on server .................. 58

Figure 56 Server disk labelled “gpt” proceeded with partition ....................... 58

Figure 57 Block device showing disks labelled “gpt” with one partition ........ 58

Figure 58 new volume group created, called “freesan” .................................. 59

Figure 59 New volume added in “freesan” called “Myvolume” of 25GB ....... 59


Page 99 of 100

Figure 60 List of new volumes created in volume group “freesan” ................ 60

Figure 61 new volume “Myvolume” configuration withIQN name ................ 61

Figure 62 unmapped new iSCSI Target volumes with no LUN Id ................. 62

Figure 63 unmapped new iSCSI Target volumes with no LUN Id ................. 62

Figure 64 Network ACL applied to new iSCSI Target volumes .................... 63

Figure 65 CHAP authentication configuration on new iSCSI Target volume . 64

Figure 66 Enabling and running of iSCSI Target sService ............................. 65

Figure 67 Target iqn.2006 01.com.openfiler:tsn.e514290910ed2 credentials . 67

Figure 68 Inactive Target: iqn.2006-01.com.openfiler:tsn.e514290910ed ...... 68

Figure 69 Selection of inactive iSCSI Target ................................................ 69

Figure 70 Connection to inactive Target using appropriate credentials .......... 69

Figure 71 Target “iqn.2006-01.com.openfiler:tsn.e514290910ed” connected 70

Figure 72 Initialization of disk volume and selection of MBR partitioning ..... 71

Figure 73 Selection of unallocated “disk 16” for MBR partitioning ............... 71

Figure 74 Starting of “New Simple Volume Wizard” .................................... 72


Page 100 of 100

Figure 75 New volume size specification at 5021 MB ................................... 72

Figure 76 Drive letter “K” assigned to the new volume for partitioning ......... 73

Figure 77 Partitioning process of volume “K” using NTFS ........................... 73

Figure 78 new volume disk “K” partition completed ..................................... 74

Figure 79 “ZoudeVolume” on Server, shown as new volume (K) on Client ... 74

Figure 80 Detection of live hosts using “nmap –sP 10.62.0.0-30” command.. 81

Figure 81 Fingerprinting on 10.62.0.25 (iSCSI SAN server) (1) .................... 82

Figure 82 Fingerprinting on 10.62.0.25 (iSCSI SAN server) (2) .................... 82

Figure 83 iSCSI SAN server (10.62.0.25) ports scanning.............................. 83

Figure 84 Exploitation of iSCSI SAN using “exploit” command ................... 84

Figure 85 Man in the middle (MITM) attack (Ref 18) ................................... 85

Figure 86 iSCSI CHAP authentication attack (1) (Ref 18) ............................ 86

Figure 87 iSCSI CHAP authentication attack (2) (Ref 18) ............................ 86

Date post:	01-Sep-2020
Category:	Documents
Upload:	others
View:	8 times
Download:	6 times

FC6P01 Project Final Report Year 2013/2014...FC6P01 Project: / Olivier Zoude – ID: 10034346 –...

Documents