Repositorio Linux reforzado e “inmutable”

Nuestra nueva versión 11 de VBR contiene algunas mejoras interesantísimas sobre Linux a tener en cuenta, como la compatibilidad para el resto de modos de transportes en Linux además de HotAdd y la posibilidad de montar el respaldo de cualquier máquina con Linux para restauración granular sin la utilización de un Helper Appliance, así como también un tipo de repositorio reforzado a nivel seguridad para realizar respaldos seguros e “inmutables”.

Veeam contiene múltiples capacidades y herramientas con el fin de asegurar una solución estratégica completa contra un ataque de ransomware, como Datalabs para analizar las VM en un laboratorio, Secure Restore para analizar nuestros respaldos con un antivirus (puede trabajar en conjunto con SureBackup para testearlos en forma regular) y también Veeam One, que detectará un posible ataque con base en el comportamiento de las VM y los respaldos. Sin embargo, en este posteo de blog nos vamos a enfocar en la interesantísima característica de “inmutabilidad” de nuestros repositorios de Veeam, la cual es una novedad que nos permitirá asegurar fuertemente nuestras copias de seguridad, aprovechando características del SO Linux.

Modus operandi del ransomware

Estamos viviendo épocas difíciles en cuanto a ciberseguridad en las organizaciones, y eso impacta claramente en cómo se protegen los activos informáticos, incluyendo los datos. Puntualmente, uno de los tipos de ataques más prevalentes y catastróficos es el ocasionado por ransomware: un tipo de programa dañino que típicamente encripta los datos del sistema de archivos infectado pidiendo un rescate de dinero.

Por lo general, la forma de distribución es mediante la infección de un activo informático de la empresa con un troyano que infecta al Sistema Operativo. El ingreso usualmente puede darse mediante la explotación de una vulnerabilidad crítica del software y/o mediante phishing a alguno de los usuarios de la empresa, entre otros. Luego se iniciará, encriptará los archivos de la compañía con una determinada clave (que solo el creador conoce) y provocará que el usuario solo pueda reclamarla a cambio de un pago.

Resistencia frente a los ataques

Hablando de protección contra el borrado accidental, malintencionado o fortuito de datos, hay ciertos componentes que, en conjunto con el cumplimiento de la regla del 3-2-1 y un monitoreo con Veeam One, nos permiten tener una estrategia de DR completa, con un repositorio ultrarresiliente. Este último tiene alguna o todas las siguientes características: debe ser offline, aislado, e inmutable. Algunos de estos repositorios son la cinta, las réplicas de VM, los snapshots de almacenamiento, los repositorios de Cloud Connect, los discos rotativos y los repositorios de Object Storage inmutables.

Los atacantes de la infraestructura de TI se han vuelto más sofisticados, no solamente encriptan la data en vivo de las computadoras, sino también de los respaldos. No importa si se encuentran en un repositorio local o en la nube, y si esto sucede y no hay algún repositorio fuera de línea disponible, estamos condenados. ¿Entonces qué hacemos si los atacantes obtienen las credenciales de dominio privilegiadas? Ellos probablemente buscarán ir por sus respaldos. En este caso tal vez lo ideal sea separar los sistemas de respaldo del dominio y, aún así, tal vez por alguna vulnerabilidad los atacantes puedan ingresar en el servidor de respaldo. Por ello, siempre es mejor proteger los respaldos contra el borrado de datos.

En este sentido los repositorios resilientes nombrados anteriormente se encuentran protegidos, en especial en el caso de los repositorios de objetos S3 inmutables, que se encuentran en una nube y que convierten los respaldos en solo-lectura, deshabilitando el borrado por un tiempo determinado. Aunque estas opciones son muy interesantes, ¿qué tal si pudiéramos proteger también nuestros repositorios locales del mismo modo, haciendo que sea realmente muy difícil o virtualmente imposible a nivel seguridad el borrado de esos datos por un tiempo determinado?

Veeam V11 al rescate

Aquí es donde adquiere relevancia la nueva capacidad de Veeam en su V11. Aunque los atacantes posean remotamente credenciales de dominio y de los servidores de Veeam, no podrán borrar esos respaldos, porque los componentes de Veeam Backup and Replication no tendrán credenciales para modificar o borrar los mismos. Luego de la utilización de una cuenta desechable, de uso único para agregar el repositorio, deberíamos remover de la cuenta la capacidad de poder elevarse a superusuario con “sudo”, cambiar su contraseña y por último deshabilitar las conexiones mediante Secure Shell (SSH).

Siempre podremos ingresar al servidor mediante consola virtual o física, en cambio Veeam se comunicará mediante su protocolo propio utilizando autenticación vía certificados. De esta forma, aunque los atacantes tengan credenciales y acceso completo a los servidores de respaldo, no podrán llegar a menos que vulneren el código del binario de Veeam, y aun así obtendrían acceso no privilegiado.

Esta capacidad se logra mediante una característica de algunos sistemas de archivos de Unix y Linux, donde, en este último, se permite generar inmutabilidad a un archivo mediante un comando llamado chattr, que activa el atributo FS_IMMUTABLE_FL, lo que convierte al mismo en inmodificable; con esto no se permiten cambios en el contenido de los archivos o sus metadatos. Esta restricción se aplica incluso al superusuario, y solo un proceso privilegiado (CAP_LINUX_IMMUTABLE) puede establecer o borrar este atributo. 

Temas adicionales de seguridad

• Configurar la sincronización con un servidor de tiempo NTP seguro, ya que es crucial poder mantener la hora correcta dado que dependemos de esto para desbloquear los mismos cuando llegue el momento (por cierto: para cambiar el NTP en Linux hace falta poseer root o ser miembro de los “sudoers”).
• Proteger las interfaces de acceso a las consolas físicas (tipo DRAC, ILO, etc.) y las virtuales (VMware/HyperV), además del acceso físico a los servidores. Si es un server físico no virtualizado, tal vez hasta sea posible deshabilitarlas.
• Intentar utilizar lo menos posible el acceso de tipo superusuario con root. Por default Ubuntu no setea un password de root por seguridad (debe dejarse así). Veeam usará una única vez credenciales privilegiadas para realizar el set up del repositorio, y luego nunca más.
• Uno de los servicios de Veeam va a agregar las reglas necesarias de forma dinámica y temporal para que el firewall por software del repositorio deje a su servicio comunicarse; no hay que setear las reglas a mano, aunque se podría deshabilitar permanentemente el acceso al puerto de SSH.

Hablemos de los alcances

• Hoy lo recomendable para realizar ésta configuración de inmutabilidad es poseer un Ubuntu 20.04 LTS ya que posee la mayor compatibilidad con reflink para la utilización de XFS; reflink permite realizar un mapeo lógico de bloques mediante punteros para no duplicar los mismos al hacer una copia. Dicho sea de paso, se recomienda que este repositorio sea formateado con XFS para poseer las ganancias de Fast Cloning de Veeam y obtener operaciones sintéticas reducidas en espacio e instantáneas.
• Al saber que los archivos no pueden ser tocados, solamente podremos crear Forward Incremental con respaldos Full sintéticos o activos, y copias de respaldo con GFS activado. 
• Por ahora, los respaldos tomados como NAS Backup, log shipping y de Enterprise Plugin no son compatibles (pero se planea que lo sean en el futuro).
• No se puede utilizar un rol de Proxy y Repositorio Inmutable a la vez, justamente por las necesidades de utilización de reducción de privilegios en las credenciales de Veeam.

Paso a paso en Ubuntu 20.04 LTS

Iniciamos línea de comandos como usuario administrador:

1. Configuraremos el timezone

 veeam@ubuntu:~$ sudo dpkg-reconfigure tzdata
 Current default time zone: 'America/Argentina/Buenos_Aires'
 Local time is now:      mié feb 10 17:53:05 -03 2021.
 Universal Time is now:  Wed Feb 10 20:53:05 UTC 2021.

2. Instalamos el paquete NTP para ser capaces de sincronizar con un reloj mundial confiable

 veeam@ubuntu:~$ sudo apt-get install ntp

3. En Ubuntu no se usará root sin “sudo” ya que la contraseña de root está deshabilitada por default. Aquí tenemos dos caminos para nuestras credenciales administrativas: crear un usuario administrativo que tendrá permisos “sudo” o cambiar la contraseña de root, lo cual no es tan recomendable. En mi caso uso una cuenta administrativa llamada “veeam” que se crea cuando se instala Ubuntu, la cual no usaremos dentro Veeam Backup and Replication.

4. Crearemos otra cuenta de servicios, en mi caso llamada “repouser“, inicialmente con permisos de “sudo”.

veeam@ubuntu:~$ sudo useradd -m -d /home/repouser -U repouser -s /bin/bash # creamos usuario
veeam@ubuntu:~$ sudo passwd repouser # cambiamos el password
veeam@ubuntu:~$ sudo adduser repouser sudo # le damos permisos de sudo

5. Formateamos y preparamos el disco para montado en booteo.

veeam@ubuntu:~$ sudo fdisk -l # revisamos cuáles discos están montados
Disk /dev/sdb: 200 GiB, 214748364800 bytes, 419430400 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

veeam@ubuntu:~$ sudo mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb # formateamos el disco con XFS

veeam@ubuntu:~$ sudo mkdir /mnt/xfsrepo # creamos una carpeta para nuestro repositorio

veeam@ubuntu:~$ sudo blkid # mostramos el UUID del disco
/dev/sdb: UUID="6f546d64-c822-472c-84d7-b1f66bd496f8" TYPE="xfs"

veeam@ubuntu:~$ echo 'UUID=<reemplazar_por_UUID_obtenido_en_comando_anterior> /mnt/xfsrepo xfs nosuid,nodev,nofail,x-gvfs-show 0 0' | sudo tee -a /etc/fstab # Agregamos el disco al archivo de montado de booteo “fstab”

veeam@ubuntu:~$ sudo reboot # Reiniciamos el SO

6. Cambiamos el ownership y permisos para el directorio del repositorio hacia la cuenta de servicios “repouser”.

veeam@ubuntu:~$ sudo chown -R repouser:repouser /mnt/xfsrepo
veeam@ubuntu:~$ sudo chmod -R 700 /mnt/xfsrepo

7. Vamos hacia la consola de Veeam Backup and Replication y agregamos el server del Linux como Managed Servers, utilizando como credenciales “Single Use Credentials for Hardened Repository”. No elegir “Add account to the sudoers file automatically”, simplemente elegir “Elevate account privileges automatically” y “Use ‘su’ if ‘sudo’ fails”.

8. En la misma consola agregamos un repositorio de tipo Direct Attached Storage, Linux y luego habilitamos “XFS reflinx/Fast Clone”, además de “Enable Inmutability for X amount of days” y guardamos.  

9. Comprobamos que el transporte de Veeam muestre conectividad.

veeam@ubuntu:~$ sudo netstat -tpnul | grep -i veeam | sort -n -k2
tcp  0   0 0.0.0.0:6162     0.0.0.0:*    LISTEN   1312475/veeamtransp

10. Opcionalmente podemos cambiar la contraseña del usuario del repositorio, además de reiniciar el servicio.

veeam@ubuntu:~$ passwd veeamrepo
veeam@ubuntu:~$ sudo service veeamtransport restart

11. Removemos permisos de superusuario “sudo” a nuestro usuario de servicios para el repositorio.

veeam@ubuntu:~$ sudo deluser repouser sudo

12. Para verificar la correcta configuración, simplemente tomaremos un respaldo Forward Incremental compatible y nos posicionamos en la carpeta del repositorio, finalmente ejecutamos un par de respaldos y verificamos que la inmutabilidad esté correctamente seteada. El comando siguiente deberá mostrar el flag de inmutabilidad de los respaldos correspondientes.

veeam@ubuntu:/mnt/xfsrepo/backups/Backup to XFSRepo$ lsattr -l ./VMware Backup to XFSRepoD2021-01-25T220206_2D3F.vbk Immutable

13. Si todo salió bien entonces no podremos borrar directamente los archivos, ni siquiera con “sudo” o root. Probamos también eliminarlos mediante Veeam, el cual deberá mostrar un Warning sobre el momento en el cual estará permitido el borrado.

veeam@ubuntu:/mnt/xfsrepo/backups/Backup to XFSRepo$ sudo rm VMware\ Backup\ to\ XFSRepoD2021-01-25T220206_2D3F.vbk
rm: cannot remove 'VMware Backup to XFSRepoD2021-01-25T220206_2D3F.vbk': Operation not permitted

14. Deshabilitamos acceso de Secure Shell al repositorio, a partir de aquí deberemos utilizar consola física o virtual para ingresar a línea de comandos.

veeam@ubuntu:~$ systemctl stop ssh
veeam@ubuntu:~$ systemctl disable ssh

Por último también quiero dar una mención honoraria a nuestro compañero Timothy Dewin que creó una herramienta automatizada para generar éste repositorio en forma fácil, la cual pueden descargar desde su GitHub.

Consideraciones finales

Con esta configuración debemos tener en cuenta que el usuario root o un usuario con “sudo” pueden remover el atributo de inmutabilidad y, por consiguiente, borrar los respaldos; por eso aseguramos los usuarios privilegiados: no los usamos en VBR, usamos sólo un usuario con bajos privilegios y mediante certificados. Por último, deshabilitamos SSH y aseguramos el acceso físico/virtual a la consola, de modo tal que aunque el atacante posea las credenciales del servicio de repositorio o de root, no podrá loguearse, y si lo hiciera abusando de alguna vulnerabilidad en nuestro servicio de transporte, obtendría permisos mínimos, no podría borrar los respaldos.

Esto hace que nuestro repositorio de Linux en la V11 sea ideal para empresas tanto pequeñas como medianas y grandes en cuanto a que, fácilmente, tendremos completa seguridad de que los respaldos están más seguros que nunca contra un ataque malicioso en su infraestructura de Veeam.