Recientemente, uno de nuestros clientes realizó una auditoría de red de TI por parte de otra empresa de auditoría de TI (tercera). Los resultados fueron buenos en general, aunque señalaron que habíamos utilizado el cliente iSCSI en Windows Server como medio para conectarnos al NAS, en lugar de crear un recurso compartido SMB en el NAS. Sugirieron que esto era una mala idea:
"Existe [también] un riesgo de seguridad con los ataques iSCSI y Ransomware, donde se puede realizar un cifrado ilícito en el disco iSCSI dejando los datos ilegibles. Desde una perspectiva de seguridad, se recomienda retirar este método de intercambio de datos y adoptar un enfoque compartido".
¿Qué quieren decir con esto? ¿Se refiere al hecho de que iSCSI opera en una capa OSI inferior (sesión) que SMB (aplicación), y un disco iSCSI se presenta a la capa de aplicación de la misma manera que lo hace un disco conectado localmente, por lo tanto, es más fácil de comprometer?
Si es así, ¿es correcto?
No soy un experto en seguridad forense, aunque nuestro trabajo suele ser de naturaleza forense. Tengo entendido que es tan probable que el ransomware ataque datos en un recurso compartido SMB accesible para una máquina Win determinada como lo sería atacar un disco iSCSI.
¿Mi comprensión es correcta o me he perdido algo?
Contexto adicional a la pregunta.
La contraseña CHAP está configurada en el servidor iSCSI, por lo que supongo que el punto que están planteando está relacionado con un compromiso del servidor Win que tiene instalado el cliente iSCSI.
Sólo se conecta un cliente iSCSI y se adopta una "higiene cibernética" muy estricta para garantizar que esta contraseña no se ingrese en ningún momento en ningún otro servidor o máquina dentro o fuera de la red.
Generalmente, nuestra preferencia es seguir con iSCSI para hacer que los discos NAS estén disponibles para Windows Server. Hemos descubierto que cuando Windows se encarga del sistema de archivos, no tenemos ningún problema con las entradas de control de acceso avanzado (ACE) dentro de DACL. Por ejemplo, la implementación de QNAP en el pasado ha tenido errores en relación con los pedidos de ACE, lo que puede ser problemático. También encontramos un error al configurar CONTAINER_INHERIT_ACE en objetos secundarios (comunicado a QNAP, pero hasta el día de hoy nunca resuelto). Este punto no es estrictamente relevante para esta pregunta, pero proporciona cierto contexto de por qué preferimos iSCSI.
Al contrario de lo que dije anteriormente, en el caso de este cliente en particular, el disco iSCSI adjunto en cuestión está formateado con ReFS, porque se utiliza como almacén de respaldo de Veeam. Aunque técnicamente no es necesario, Veeam recomienda el uso de ReFS en lugar de NTFS por motivos de rendimiento, por lo que tendemos a preferir esta opción. (Aquí hay un buen artículo.explicando ReFS vs NTFS para respaldo.) Estas ganancias solo son posibles si usamos iSCSI, no si movimos el NAS a SMB.
Ya he leído un poco sobre este tema y no he podido encontrar ninguna evidencia que respalde que iSCSI esté más sujeto a ransomware que conectarse a través de una red compartida, sin embargo, sigo teniendo la mente abierta.
Respuesta1
Cualquier disco grabable en línea puede resultar dañado por un software o un usuario malintencionado. Subestimarlos asumiendo que no pueden encontrar un archivo compartido es un error.
La última línea de defensa para datos importantes es siempreprobado, copias de seguridad en frío fuera de línea. ¡Y en este caso, los datos importantes pueden incluir copias de seguridad! Piense en las posibles formas de hacer que los archivos de respaldo sean imposibles de cambiar. Medios extraíbles (cinta), almacenamiento en la nube inmutable con credenciales que solo se usan para la copia de seguridad, dedique el NAS a la copia de seguridad y no conecte nada más, firewall para todo excepto los puertos del software de copia de seguridad, deshabilite el uso compartido de archivos.
Otro control es permitir listar software, restringiendo significativamente la ejecución de cosas desconocidas.
El contexto que proporcionó indica que ha pensado en esto y es bueno explicar su uso del protocolo. Piense en un nivel un poco más alto que esta pregunta e incluya en la respuesta qué protecciones existen en el plan de continuidad del negocio.
- ¿Cuándo se realizó la última prueba de restauración de respaldo? ¿Cumplió con los objetivos de punto y tiempo de recuperación?
- ¿Alguien ha demostrado que las copias de seguridad en frío no están en línea y son vulnerables, como mediante un ejercicio del equipo rojo?
- ¿Cuándo fue la última vez que tuvo problemas con el ransomware y qué se hizo para mejorar los controles técnicos o de procesos?
Respuesta2
Dejando a un lado la cuestión de la vulnerabilidad de iSCSI cuando se usa sin un sistema de archivos agrupado pero con múltiples iniciadores, difícilmente puedo encontrar una razón clara por la cual el protocolo para compartir archivos sería más seguro en términos de ransomware en comparación con iSCSI. Obtiene CHAP para fortalecer la autenticación e IPSec para asegurar la transferencia de datos a través de la red. Aquí hay una buena lectura general de por qué iSCSI:https://www.starwindsoftware.com/blog/complete-an-infrastructure-project-for-your-organization-with-iscsi-san
De lo contrario, es más una cuestión de seguridad general del servidor de respaldo, como tenerlo separado de su entorno de producción principal, fuera del dominio y con una cuenta separada (no administrador de dominio), etc. De todos modos, si logras enviar ransomware al servidor de respaldo, no importará mucho si estás usando, por ejemplo, el recurso compartido SMB como repositorio de respaldo (https://helpcenter.veeam.com/docs/backup/vsphere/smb_share.html?ver=100) o un almacenamiento iSCSI.
Respuesta3
Sí, cualquier protocolo de acceso a datos de red a nivel de archivo es MÁS SEGURO en comparación con el de bloque (iSCSI, FC, FCoE, etc.) debido a la incapacidad de dañar el volumen con el "redirector de red", lo cual es muy fácil de hacer con un clúster configurado incorrectamente. o cualquier sistema de archivos local (EXT3/4, ReFS, XFS, etc.). Toda la historia está bien cubierta aquí:
https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392