iSCSI as a storage protocol is noted for its administrative simplicity. If an admin knows TCP/IP – and what self-respecting admin doesn’t – then they possess most of the knowledge they need for success in managing iSCSI connections.
iSCSI also benefits from its choices in hardware. In most cases, the very same Ethernet cables and networking equipment lying around will work swimmingly for passing iSCSI traffic.
With all this going for it, the iSCSI protocol for connecting servers to storage systems seems like a shoo-in for primacy across IT environments. But it does have a dark side, one that too often gets neglected in the rush to spin up new servers.
That dark side is iSCSI’s options for securing those connections. Unlike direct-attached storage where connections never leave a server’s chassis and, unlikeFibre Channel’s entirely separate and single-use connectivity infrastructure, iSCSI’s use-it-on-the-network-you-already-have value belies a range of security problems that aren’t obvious to resolve.
But solutions do exist to secure iSCSI network connections. What’s particularly interesting is, these solutions can be layered atop each other to create whatever depth of security data needs. Admins should consider this carefully as they ponder the iSCSI exposure in their environment.
Layer No. 1: Segregating ACL networks. iSCSI’s first layer of protection against prying eyes does not happen within the iSCSI protocol itself. Instead, the architecture that is created in support of iSCSI should be constructed in a way that iSCSI traffic is segregated from other traditional networking.
Necessary for security as well as to assure assurance performance, that segregation can be physical by establishing paths through separated networking equipment. It can also be logical through the use of VLANs and access
control lists (ACL) at the network layer. Configuring Layer 3 (IP-based) ACLs on network equipment ensures traffic is routed appropriately. It also has the effect of masking out iSCSI LUNs that shouldn’t be globally accessible. iSCSI operates by default over TCP port 3260, which introduces the notion that Layer 4 (port-based) ACLs can also provide added security.
Layer No. 2: CHAP authentication. ACLs may ensure iSCSI traffic correctly navigates to the right hosts, but it does nothing for authenticating servers to storage. That process is handled through the protocol’s Challenge-Handshake Authentication Protocol (CHAP) support, using one of two possible configurations. In the first, one-way CHAP authentication, the iSCSI target on the storage authenticates the initiator at the server. Secrets, essentially iSCSI passwords, in one-way CHAP authentication are set on the storage. Initiators on any incoming servers must know that secret to initiate a session.
A second and slightly better option is mutual CHAP authentication, where the iSCSI target and initiator authenticate each other. Separate secrets, one for each half of the connection, are used in this configuration. Each half must know the secret of the other for a connection to initiate.
Layer No. 3: RADIUS authentication. RADIUS, or Remote Authentication Dial-In User Service, has long been associated with telephony and modems. This service has evolved to become a standard for authenticating other protocols as well. Both the iSCSI initiator and the target authenticate not to each other, but to the RADIUS server.
Centralizing authentication to a third-party service improves the management of security. Configuring secrets with CHAP authentication requires entering their character strings across numerous servers as well as storage connections. That distribution of password data introduces the opportunity for mistakes. Just keeping track of the sheer volume of passwords can expose vulnerabilities. Centralizing authentication to a RADIUS server reduces the effort, which diminishes these administrative risks.
Layer No. 4: IPSec Authentication. Unfortunately, CHAP authentication all by itself isn’t a terribly strong mechanism for securing connections. CHAP is reportedly subject to offline dictionary attacks, enabling a persistent attacker to eventually guess the password through brute-force means. It is for this reason that using random strings of letters and numbers is the recommended practice for creating CHAP secrets. Even RADIUS itself is merely a service for managing CHAP passwords, which insinuates that its implementation doesn’t add much to security beyond the aggregation of secrets.
These factors suggest that truly securing connection authentication requires a different approach, one that isn’t limited by CHAP’s vulnerabilities. IPSec can serve those stronger authentication needs. IPSec operates at the IP packet layer, giving it the full functionality of the TCP/IP stack. IPSec authentication can occur using pre-shared keys (similar to CHAP), but it also supports stronger frameworks like Kerberos and certificate-based authentication.
IPSec’s biggest limitation is in its support on storage devices. Whereas CHAP authentication is more closely associated with iSCSI connections, IPSec functionality may not be part of the storage OS’s feature set. Consult the manufacturer’s documentation for information about its support within storage hardware.
Layer No. 5: IPSec Encryption. All the layers of security to this point focus their energies on ensuring two devices are allowed to communicate. That’s the authentication process. None to this point give any attention to securing storage data as it travels through the network. Solving this problem requires encryption, which is another activity supported by IPSec. IPSec encryption represents the final of these five layers because it occurs only after a server’s initiator has been authenticated to a storage device’s target. Resulting traffic is then encrypted at the source, and then decrypted once delivered.
While encrypting traffic indeed provides the highest levels of security, doing so comes with a cost to performance. The activities in encrypting and decrypting simply require more processing, which itself can impact overall transfer speed. As a result, best practices today suggest that encrypting traffic via IPSec be limited to only untrusted networks, or in cases where extreme security is necessary.
iSCSI is indeed a fantastic protocol for routing servers to their storage. Easy to work with, simple to interconnect, and requiring a short learning curve for those familiar with TCP/IP’s fundamentals, iSCSI provides a great service for IT. Yet, beware its oft-forgotten dark side: Lacking the right layers of security, iSCSI could expose storage traffic in easily exploitable ways.
No comments:
Post a Comment