Normalmente, implantamos a nuestros clientes un sistema de copia integral, que realiza una imagen del equipo protegido sobre un disco interno adicional que luego se replica sobre dos (o más) discos externos en rotación. Si se rotan con la periodicidad debida y se mantiene al menos uno de los discos externos siempre fuera del lugar de trabajo, las posibilidades de recuperación ante cualquier situación (pérdida de datos, borrado accidental, robo de equipo, virus, etc..) son muy elevadas, tanto en el caso de querer recuperar un simple archivo como de querer recuperar una máquina completa.
Sin embargo, desde la llegada de los virus criptográficos, la posibilidad de que los medios de backup se vean afectados y encriptados es real y la seguridad pasa a depender exclusivamente del medio externo que no haya sido contaminado. No quedan libre de esta problemática los discos online tipo Onedrive o Google Drive, que sincronizarán el contenido local infectado con la nube tan pronto se registre un cambio en los archivos. Y, que alguien me corrija, pero intentar mantener en el cloud imágenes de gran tamaño (2TB en adelante para un servidor, por ejemplo), que es lo que se requiere si se tiene que poder restaurar un equipo por completo, es a día de hoy, cuando menos, complicado.
Todo técnico sabe además, que el eslabón más debil de la cadena de seguridad es áquel que depende del propio usuario. ¿Seguirá nuestras instrucciones? ¿Rotará los discos con la periodicidad adecuada?
Una medida de contención práctica es que las unidades de backup estén conectadas únicamente el tiempo necesario para realizar las tareas de copia. Evidentemente, no es una solución que garantice nada, pero al menos, reduce el área expuesta al tiempo de ejecución del backup. Tiempo que generalmente coincide con horario nocturno, en el que, generalmente también, los usuarios no están en sus puestos de trabajo y por tanto la probabilidad de lanzar el virus al realizar alguna acción maliciosa (correo infectado, etc…) es menor.
Lo que os ofrezco aquí es un ejecutable denominado DSKENDIS.EXE, que es realemente un script VBS empaquetado en un EXE de 32 bits gracias a VBSEdit, que realiza la tarea de conexión y desconexión de un disco local del equipo que lo ejecute. Internamente, el script utiliza los comandos WMIC y DISKPART para conseguir el resultado esperado.
De momento, está probado sobre Windows 10 y Windows 2012 y es posible que requiriese algún ajuste para otras versiones de Windows.
La conexión y desconexión funciona a nivel de disco, no de unidad lógica o partición y equivale a la acción ‘Sin conexión’ y ‘En línea’ que podemos ejecutar desde la consola de Administración de discos de Windows, como podéis ver en estas imágenes:
Dado que los comandos que se utilizan para conectar y desconectar un disco, se basan en el índice del disco y que éste puede cambiar en función de las unidades que estén conectadas al equipo en un momento dado, DSKENDIS.EXE usará el nº de serie del disco y la firma para localizar el índice del disco y realizar la operación deseada.
Descarga DSKENDIS.EXE haciendo clic aquí.
Funcionamiento:
DSKENDIS HELP muestra la ayuda del comando.
DSKENDIS LIST muestra una lista de discos que incluirá el nº de serie y firma que se usan luego con las opciones ENABLE y DISABLE
DSKENDIS ENABLE /SERIAL:[xxxx] /SIGNATURE:[yyyy] conectará el disco con nº de serie xxxx y firma yyyy.
DSKENDIS DISABLE /SERIAL:[xxxx] /SIGNATURE:[yyyy] desconectará el disco con nº de serie xxxx y firma yyyy.
Notas:
– Se deben respetar las MAYÚSCULAS
– Los corchetes son obligatorios y no hay que dejar espacios tras los ‘:’
Espero que os sirva de ayuda!
1/3/2018: UPDATE
Un error presente en el comando WMIC en Windows 7 y 2008R2 puede producir el error ‘ Error analyzing WMIC header’ cuando se ejecuta DSKENDIS.EXE.
Microsoft tiene un parche que puedes descargar aquí.