7

Recently one of our customers undertook an IT network audit from another (third party) IT audit firm. The results were generally good, although they pointed out that we had used iSCSI client on Windows Server as a means of connecting to the NAS, instead of creating an SMB share on the NAS. They suggested this was a bad idea:

"There is [also] a security risk with iSCSI and Ransomware attacks, where illicit encryption can be undertaken to the iSCSI disk leaving data unreadable. From a security perspective it is advised to retire this method of data sharing and adopt a share approach."

What do they mean by this? Is it referring to the fact that iSCSI operates on a lower OSI layer (session) than SMB does (application), and an iSCSI disk presents to the application layer the same way as a locally attached disk does, therefore easier to compromise?

If so, is that correct?

I am not an security forensics expert, although our work is often forensic in nature. My understanding is that ransomware is just as likely to attack data on an SMB share accessible to a given Win machine as it would be to attack an iSCSI disk.

Is my understanding correct, or have I missed something?

Additional context to the question

  1. CHAP password is set on the iSCSI server, so I would presume the point they are making is related to a compromise of the Win Server that has the iSCSI client installed.

  2. Only one iSCSI client is ever connected, and very strong "cyber hygiene" is adopted to ensure this password is not at any point entered into any other server or machine on or off the network.

  3. Generally, our preference is to stick with iSCSI for making NAS disks available to the Windows Server We have found that when Windows takes care of the file system, we don't have any problems with advanced access control entries (ACEs) within the DACL. For example QNAP's implementation has in the past been buggy in relation to ACE ordering which can be problematic. We also found a bug with setting CONTAINER_INHERIT_ACE on child objects (communicated to QNAP, but to this day never resolved). This point is not strictly relevant to this question, but provides some context for why we prefer iSCSI.

  4. Contrary to my above point, in the case of this particular customer, the iSCSI attached disk in question is formatted with ReFS, because it's used as a Veeam backup store. Although not technically required, Veeam recommends the use of ReFS over NTFS for performance reasons so we tend to prefer this option. (Here is a good article explaining ReFS vs NTFS for backup.) These gains are only possible if we use iSCSI, not if we moved the NAS to SMB.

  5. I have read around this subject already a little bit, and have not been able to find any supporting evidence that iSCSI is more subject to ransomware than connecting over a network share, however I remain open-minded.

  • 1
    I can understand the merits of iSCSI in the scenario of your client and I would use it also. I can't really get the auditor's line of thought. Perhaps they believe that since iSCSI volume is essentially local storage for the iSCSI target is more vulnerable - in contrast to a remote CIFS share? In that case, it's a matter of proper NTFS/ReFS ACL settings, whether it's a local volume or a remote share. In conclusion, I haven't ever been suggested that iSCSI is a potential security risk in auditing. On the contrary, SMB/CIFS vulnerabilities come to surface much more often. – Krackout Aug 25 '20 at 11:06
  • Thanks for your comment. I tend to agree. One additional thought I had would be to set up a secondary NAS which somehow "pulls" the Veeam backup data from the primary NAS. The secondary would have read-only access set on its LUN. That way the secondary NAS cannot be written to, therefore not vulnerable to attack. – hazymat Aug 25 '20 at 13:21
8

Any online writable disk can be corrupted by a malicious software or user. Underestimating them by assuming they cannot find a file share is a mistake.

Last line of defense for important data is always tested, cold offline backups. And in this case, the important data may include backups themselves! Think about the possible ways to make backup archives impossible to change. Removable media (tape), immutable cloud storage with credentials only used for backup, dedicate the NAS to backup and don't connect anything else, firewall everything but the backup software ports, disable file sharing.

Another control is allow listing software, significantly restricting running unknown things.

Context you provided indicates you have thought about this, explaining your use of the protocol is good. Think a bit higher level than this question and include in the response what protections exist in the business continuity plan.

  • When was the last backup restore test, did it meet the recovery point and recovery time objectives?
  • Has anyone proven the cold backups are not online and vulnerable, such as through a red team exercise?
  • When was the last time you had problems with ransomware, and what was done to improve technical or process controls?
7

Leaving the question of iSCSI vulnerability when using it without a clustered file system but with multiple initiators aside, I can hardly find any clear reason why file sharing protocol would be more secure in terms of ransomware comparing to iSCSI. You get CHAP to strengthen authentication and IPSec to secure data transfer over the network. Here is a good overall reading of why iSCSI: https://www.starwindsoftware.com/blog/complete-an-infrastructure-project-for-your-organization-with-iscsi-san

Otherwise, it is more a question of backup server overall security like having it separated from your main production environment, outside the domain and with a separate account (not domain admin) and so on. Anyway, if you manage to get ransomware to the backup server, it won’t matter much if you are using, for example, SMB share as a backup repository (https://helpcenter.veeam.com/docs/backup/vsphere/smb_share.html?ver=100) or an iSCSI storage.

5

Yes, any file-level network data access protocol is SAFER compared to the block (iSCSI, FC, FCoE etc) one due to inability to damage the volume with "network redirector", which is super-easy to do with an improperly configured clustered or any local file system (EXT3/4, ReFS, XFS etc). Whole story is covered well here:

https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392

  • 1
    Can you please be more specific. If an attacker has gained either user or administrator access to a Windows server, is it not the case that the attacker can just as well encrypt files on the network share as they can on the local disk? The link you posted appears to be a discussion thread about multiple concurrent connections to an iSCSI target, which does not apply here. Can you please explain how it is relevant to your interesting sounding point about "network redirector"? – hazymat Aug 25 '20 at 13:14
  • 3
    If attacker occasionally will break clustered file system configuration (which is quite easy) his encryption will actually destroy data in unrecoverable way. – BaronSamedi1958 Aug 25 '20 at 13:27
  • @hazymat : Are you conflating "encrypt files on a disk" (which SMB and iSCSI permit) with "encrypt a disk" (which iSCSI permits, because full-disk encryption requires block access, not just filesystem access)? – Eric Towers Aug 25 '20 at 19:02
  • @EricTowers You make a good point, although I did not conflate the two, just didn't delineate between them in my comment above. I am still in the dark about what Baronsamedi1958 means by "network redirector" and am confused that he has posted a link to a forum post saying the story is covered there, but I cannot find any mention of "network redirector" in that post, nor does the post seem relevant to the question. It just seems to reference the general subject of iSCSI. Would appreciate a follow-up from BaronSamedi1958 on that one. Thanks – hazymat Sep 1 '20 at 11:07
  • 2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.