Se si blocca un volume NAS montato su iSCSI (su Windows Server) in modo che gli amministratori abbiano accesso in sola lettura e l'account di backup abbia accesso in scrittura al file system, l'account Administrator può sempre assumere la proprietà dei file, giusto? C'è sempre il rischio che il ransomware possa infettare il sistema ed eseguire qualche escalation di privilegi, quindi assumere la proprietà dei file e delle directory bloccati prima della crittografia, giusto?
Come combatti questo?
Affinché funzioni, è necessario implementare il blocco sul lato iSCSI, non sul lato locale. Il ransomware può SEMPRE bypassare la sicurezza locale.
Ci sono due modi per bloccarlo:
1: O si rende il server iSCSI completamente di sola lettura. Per facilitare il backup, si fa in modo che il client "condivide" l'unità (SAMBA, FTP o iSCSI) sul server iSCSI e quindi il server NAS / iSCSI "estrae" i dati dal client. (Nota qui che è proprio il server iSCSI che è il client, e il tuo PC di backup che è il server in termini di rete, ma solo per chiarire che computer intendo, io uso il ruolo intercambiato)
Questi dati devono essere scritti in modo incrementale, usando ad esempio LVM Snapshots o altro modo incrementale per memorizzare le informazioni, quindi anche se un ransomware sovrascrive i file locali, causando il richiamo di questi file locali sul server iSCSI, questi i file danneggiati NON danneggeranno i backup precedenti.
2: Un altro modo per risolverlo è quello di rendere l'effettivo punto di lettura lettura-scrittura iSCSI, ma i dati scritti sul disco effettivo sul server iSCSI, saranno incrementali. Questo deve essere applicato sul lato server, quindi non importa quanto duramente il ransomware cerchi di sovrascrivere un file, solo il diff verrà salvato, così puoi facilmente tornare alla data in cui il ransomware NON lo sovrascrive.
vantaggi:
Nel primo caso, è possibile pianificare facilmente i pull dal client sul lato server, impedendo ad esempio a un ransomware di "bombardare" l'unità NAS scrivendo dati non necessari finché il file diff copre l'intera unità NAS. Non importa quanto il ransomware riempia la tua unità locale di cazzate, verrà estratto solo 2 volte al giorno.
Il secondo caso ha bisogno di qualcosa di più difficile, perché in questo caso si corre il rischio che il ransomware scriva costantemente sull'endpoint iSCSI, riempiendo rapidamente il file diff. Ciò può significare che un ransomware potrebbe riempire segretamente l'endpoint iSCSI, quindi sperare che non lo si noti e quindi crittografare i file un mese dopo. Ecco perché è necessario imporre una sorta di allestimento, quindi se si è scritto di recente su un file, il suo diff verrà invece sovrascritto. È possibile codificare autonomamente qualcosa che impone questa messa in scena con istantanee.
Pensa in questo modo, se scrivi sul file X 15:05, quindi scrivi di nuovo 15:06 e poi di nuovo il 17:01, quindi scrivi di nuovo il 22:10 e hai impostato la sequenza su 6 ore, quindi il NAS deve contenere il file base pre-15: 05 X, quindi un diff tra "pre-15: 05 X e 17:01" e quindi un diff tra "07:01 uno e 22:10 uno".
Ad ogni modo, assicurati di avere un modo affidabile di notifica dal server NAS, ad esempio un modem GSM e una comunicazione SMS, che il ransomware non può toccare, che ti avviserà per esempio il 75% di utilizzo del NAS sul NAS, quindi, anche se il ransomware riesce a riempirlo, riceverai un ampio avvertimento prima che sia completamente riempito.
Un modo super avanzato per risolverlo:
Potresti usare un booster PXE, come iPXE, per avviare un piccolo sistema operativo di solo backup, che ha il nome utente / password di lettura-scrittura sul tuo NAS iSCSI, ma, ad ogni avvio, ti basta chiedere se vuoi per fare il backup del computer ora. Qui è possibile avere un codice PIN o qualcosa per il backup che accetterà solo 3 tentativi (prima che debba essere resettato localmente sul server PXE), che impedisca al ransomware di richiedere il sistema operativo di backup mentre Windows è in esecuzione (che perderebbe l'iSCSI nome utente / password di lettura-scrittura.
Applicando il backup manuale, si evita anche il rischio che il ransomware sovrascriva i dati locali, quindi i dati locali vengano copiati sul server causando la sovrascrittura di buoni backup.
In questo modo, esegui un "avvio offline" o "avvio a freddo", il tuo sistema operativo principale non è in esecuzione e qualsiasi cosa dannosa all'interno non può essere eseguita. Allo stesso modo, qualsiasi cosa malevola non può scrivere nulla sul sistema operativo solo di backup.
Il tuo sistema operativo locale ha solo nome utente / password di accesso in sola lettura.
Non c'è niente di speciale in questo caso d'uso: se temi che l'accesso in sola lettura possa essere aggirato usando l'escalation dei privilegi, assicurati che l'escalation dei privilegi non sia possibile sul tuo sistema. Se temi che il ransomware possa infettare e danneggiare il tuo sistema, assicurati che non arrivi al tuo sistema. Quindi il problema iSCSI è ridotto ad altri due problemi ben noti.
Poiché entrambi questi problemi noti non hanno una soluzione perfetta, dovresti assicurarti che la singola soluzione perfetta contro il ransomware funzioni ancora: fai regolarmente backup offline.
Leggi altre domande sui tag windows permissions hardening