For this to work, you MUST to implement lockdown on the iSCSI side, not on local side.
Ransomware can ALWAYS bypass local security.
Theres two ways you could lock it down:
1: Either you make the iSCSI server completely read-only. To faciliate backup, you instead make so your client "shares" the drive (SAMBA, FTP or iSCSI) to the iSCSI server, and then the NAS/iSCSI server will "pull" the data from the client.
(Note here that its really the iSCSI server that is the client, and your backuped PC that is the server in networking terms, it just to clarify which computers I mean, I use the interchanged role)
This data needs to be written in a incremential way, using for example LVM Snapshots or other incremential way to store the information, so even if a ransomware overwrites local files, causing these local files to be pulled to the iSCSI server, these damaged files will NOT damage prior backups.
2: Another way to solve this, is to make the actual iSCSI endpoint read-write, but the data you write to the actual disk on the iSCSI server, will be incremential. This must be enforced on the server-side, so no matter how hard the ransomware tries to overwrite a file, only the diff will be saved, so you can easily roll-back to the date when the ransomware did NOT overwrite it.
In the first case, you could easily schedule the pull's from the client on the server-side, preventing for example a ransomware from "bombing" the NAS drive by writing unneccessary data until the diff file covers the whole NAS drive.
No matter how much the ransomware fills your local drive with crap, it will only be pulled like 2 times per day.
The second case needs a bit more tough, because in that case, you run the risk that the ransomware will constantly write to the iSCSI endpoint, quickly filling the diff file up. This can mean that a ransomware could secretly fill up the iSCSI endpoint, then hope you don't notice it, and then encrypt the files a month later.
Thats why you need to enforce some sort of staging, so if you have recently written to a file, its diff will instead be overwritten. You can propably code something yourself that enforces this staging with snapshots.
Think like this, that if you write to file X 15:05, then write again 15:06 and then again on 17:01, then write again 22:10, and you have set the staging on 6 hour, then the NAS should contain the pre-15:05 X base file, then a diff between "pre-15:05 X and the 17:01 one" and then a diff between "07:01 one and 22:10 one".
Anyways, make sure to have a reliable notification way from the NAS server to you, for example a GSM modem and SMS communication, that the ransomware cannot touch, that will notify you at for example 75% drive utilitazion on the NAS, so even if the ransomware manages to fill it up, you will get ample warning before its completely filled.
Super-advanced way to solve it:
You could use a PXE booter, like iPXE, to boot into a small backup-only operating system, that has the read-write username/password to your iSCSI NAS, but, At each bootup, it just ask if you want to backup the computer now. Here you could have a PIN code or something for backuping that will only accept 3 retries (before it must be resetted locally at the PXE server), that prevents the ransomware from requesting the backup operating system while Windows is running (which would leak the iSCSI read-write username/password).
By enforcing manual backup, you also prevent the risk that the ransomware overwrites your local data, then your local data to be backuped to the server causing it to overwrite good backups.
In this way, you do a "offline boot" or "cold boot", your main operating system isn't running, and anything malicious inside that cannot run. And in the same way, anything malicious cannot write anything to the backup-only operating system either.
Your local operating system does only have read-only access username/password.