12 marzo, 2019

Gestión de backups de recurso compartido CIFS a un servidor FTP remoto de forma sincronizada con rsync

Una forma de  realizar backups de ficheros o directorios independientes entre un sistema Windows y servidor FTP remoto y los ficheros a realizar el backup están en un recurso compartido CIFS (SMB) de Windows, si disponemos de un sistema Linux podremos montar en dos directorios el recurso compartido Windows y el servidor FTP remoto. A posteriori realizar la copia sincronizada con rsync entre el directorio montado con CIFS y el directorio remoto FTP donde se almacenará la copia.

Accedemos al sistema linux e instalamos los paquetes cifs-utils para poder montar sistemas de ficheros compartidos desde un sistema Windows y curlftpfs para montar el servidor FTP remoto.
sudo apt install -y cifs-utils
sudo apt install -y curlftpfs
Creamos un directorio para montar el recurso compartido Windows y otro para montar el espacio del servidor FTP remoto y otorgamos permisos de control total, aunque esto dependerá de la gestión de usuarios y grupos de como tengamos configurado el entorno Linux. (Como ejemplo se montará partiendo de /mnt).
mkdir /mnt/ftpbackup ; chmod -R 777 /mnt/ftpbackup
mkdir /mnt/cifsbackup ; chmod -R 777 /mnt/cifsbackup
Montamos el recurso compartido cifs de Windows.
mount -t cifs //server/compartida /mnt/cifsbackup -o username=user,password=passw,domain=dominio
  • //server/compartida: Será el recurso compartido cifs de Windows.
  • /mnt/cifsbackup: Directorio que se usará para montar el recurso cifs de Windows en la máquina Linux.
  • User, password y dominio: Será el usuario, contraseña y dominio si se trata de un usuario de dominio, si se trata de un usuario local de Windows sería el hostname de la máquina Windows.

Montamos el directorio del servidor FTP remoto en el directorio local de la máquina Linux. (Como ejemplo se montará partiendo de /mnt.)
curlftpfs user:passw@serverftp /mnt/ftpbackup
  • user: Usuario de acceso al servidor FTP.
  • passw: Password de acceso al servidor FTP.
  • serverftp: URL, IP o hostname de acceso al servidor FTP.
  • /mnt/ftpbackup: Directorio donde se montará el servidor FTP remoto en la máquina Windows.

Una vez montados ambos recursos solo queda realizar el backup y que sincronice los datos desde el recurso compartido cifs de Windows hacia el servidor FTP remoto, al estar montados en el sistema Linux estos se tratarían como directorios locales.
rsync -rtvp --log-file=/var/log/ficherolog /mnt/cifsbackup /mnt/ftpbackup
  • r: Recursividad entre directorios.
  • r: Preserva la modificación de fechas.
  • v: Vervose, muestra más detalles.
  • p: Preserva los permisos de los ficheros y directorios.
  • --log-file=/var/log/ficherolog: Almacena los resultados en un fichero de log.
  • /mnt/cifsbackup: Datos origen.
  • /mnt/ftpbackup: Datos destino.

Para desmontar los recursos de los directorios.
umount /mnt/ftpbackup
umount /mnt/smbbackup
Para automatizar este proceso podemos crear un fichero bash script .sh que monten ambos recursos, realize el backup con rsync, enviarse el fichero de log a una dirección de correo electrónico y finalmente desmontar ambos recursos para que no permanezacan en la máquina Linux si no lo deseamos.

Si queremos programar la ejecución de este script .sh a una fecha/hora concreta añadimos el script a una nnueva línea en /etc/crontab de modo que se ejecute de forma programada.

Saludos!

27 febrero, 2019

vSphere Web Client: Opciones deshabilitadas en la máquina virtual

Este troubleshooting está recogido en la base de conocimiento https://kb.vmware.com/s/article/2048748.

El no poder ver las opciones habilitadas para poder editar la configuración entre otras de la VM pueden ser por debido a varias causas, las más habilitales puede ser por la configuración de permisos o por tareas ejecutándose en segundo plano.

Figura 1: Opciones deshabilitadas en la máquina virtual en vSphere web client.

Para consultar las tareas en background de la VM afectada, nos nos conectamos por SSH al host ESXi y listamos sus VMs.
vim-cmd vmsvc/getallvms
Listar tareas de esa VM (vmid)
vim-cmd vmsvc/get.tasklist <vmid>
Hay tareas corriendo, si el resultado es algo como:
(ManagedObjectReference)
['vim.Task:haTask-8-vim.VirtualMachine.createSnapshot-534613324',
'vim.Task:haTask-8-vim.VirtualMachine.powerOn-534613303']
No hay tareas corriendo en background, si el resultado es algo como:
(ManagedObjectReference) []
Figura 2: Finalizar procesos VMs en host WMware ESXi.

Finalizar procesos

ps | grep vmx
kill <pid>
Si con simplemente kill no se finalizan, usar el parámetro -9
kill -9 <pid>
Esperamos unos 30 segundos aproximadamente y volvemos a listar los procesos con ps para comprobar que se finalizó correctamente.

Más info: https://kb.vmware.com/s/article/1014165.

Establecer permisos en la VM

Otorgar permisos a vSphere Web Client cambiando el rol de este grupo a Administrador.

Figura 3: Cambiar el rol del grupo de vSphere Web Client a permisos de Administrador.

Figura 4: Permisos de Administrador al grupo vSphere Web Client.

Comprobamos que las opciones vuelven estar disponibles y habilitadas para la VM.

Figura 5: Opciones habilitadas de la VM en vSphere Web Client.

Saludos!

24 febrero, 2019

NETSH portproxy: Port forwarding local en Windows

Un método para crear túneles haciendo un reenvío de puertos usando un sistema Windows es el uso de la utilidad de comandos NETSH.

Netsh tiene una propiedad llamada portproxy la cual actua como un proxy en las redes y aplicaciones IPv4 e IPv6.

Mostraré un ejemplo que podría ser típico, se trata de un reenvío de puertos local con el fin de establecer una conexión de Escritorio Remoto (RDP) entre dos máquinas Windows.

Si se trata de un reenvío de puertos entre redes IPv4 la sintaxis sería:
netsh interface portproxy add v4tov4 listenport=<Puerto-Local> listenaddress=<IP-Local> connectport=<Puerto-Remoto> connectaddress=<IP-Remota>
En siguiente ejemplo se reenvía desde la máquina local y puerto local de escucha 9090 a la máquina remota 10.0.0.19 y puerto remoto al que nos conectaremos 3389.
netsh interface portproxy add v4tov4 listenport=9090 listenaddress=localhost connectport=3389 connectaddress=10.0.0.19
  • listenport: Puerto IPv4 local en el que se escucha.
  • connectaddress: Dirección IPv4 local a la que conectarse.
  • connectport: Puerto IPv4 remoto al que conectarse.
  • listenaddress: Dirección IPv4 remota en la que se escucha.
Figura 1: Reenvío de puertos con Netsh estableciendo una conexión RDP entre dos máquinas Windows.

Para comprobar las reglas añadidas de reenvío de puertos con Netsh porproxy podemos consultar la tabla de reglas.
netsh interface portproxy show v4tov4  #Lista reglas en redes IPv4.
netsh interface portproxy show all     #Lista todas las reglas.
Para "romper" la conexión o eliminar las reglas establecidas.
netsh interface portproxy delete v4tov4 listenport=9090 listenaddress=localhost
Figura 2: Comprobar reglas añadidas y puertos de Netsh portproxy en una conexión RDP y eliminar reglas.

Saludos!

16 febrero, 2019

Plink SSH: Auto aceptar hostkey fingerprint al crear un túnel local port forwarding en SSH versión 2

Hostkey o fingerprint SSH

Cuando nos conectamos a través de un cliente SSH como PuTTY, por primera vez en una conexión se nos mostrará una alerta de seguridad indicando que el host key no está cacheado en el registro, no es más que la huella digital o fingerprint de la máquina remota a la que nos conectamos usado como método de confianza para garantizar la autenticidad de la máquina remota.

Esta host key al no estar registrada o cacheada por la máquina cliente que establece la conexión por primera vez, nos alerta de que no hay garantía de que el servidor remoto sea quien creemos que es.

ssh:ed25519 se trata de un esquema de firma digital EdDSA. Mantiendo la seguridad de otros esquemas con la principal ventaja de aportar más velocidad, más info aquí.

Figura 1: Alerta de seguridad - Host key de la primera conexión SSH.

Usando PuTTY las SSH host keys se cachean almacenándose en el registro de Windows.
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
En un tipo de valor de cadena (REG_SZ).

Figura 2: Registro Windows - SSH Host Keys de Putty.

Conexión SSH con Plink

Comentado lo anterior, vamos a ver entonces con Plink (utlidad de comandos de Putty) como podemos conectarnos por SSH estableciendo un túnel port forwarding auto aceptando el hostkey.

Pero que pasa si no tenemos una interfaz gráfica ni un Putty y solo disponemos de una terminal de comandos en la que podemos incorporar un Plink.

Cuando nos conectamos directamente al servidor SSH con Plink lo hacemos del siguiente modo.
plink <host_servidor_SSH>
De esta forma nos solicitará almacenar o no la hostkey en caché, sería la equivalencia a la ventana de alerta de seguridad de la hostkey que se muestran en las conexiones con Putty. Continuamos (y yes) almacenando la clave, nos pedirá usuario y contraseña. Y vemos que nos conecta al servidor remoto correctamente (independientemente de la mala interpretación en la codificación de caracteres).

Figura 3: Conexión estándar SSH con Plink (Putty).

Creando un túnel SSH port forwarding con Plink

Con Plink al igual que con Putty podemos crear un túnel SSH.
plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>
De esta forma simplemente aceptaremos el cacheo de hostkey y tendremos el reenvío de puertos establecido en la conexión SSH.

Figura 4: Conexión túnel SSH port forwarding con Plink (Putty).

Hay un tip un poco "sucio" que es auto aceptar la host key con: "echo y | plink...". Quedando algo como esto.
echo y | plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>
Figura 5: Auto aceptando hostkey ssh con "echo y | plink..."

Auto aceptar hostkey con Plink creando un túnel SSH port forwarding

Hasta aquí todo correcto. El problema de esto es si queremos conectarnos con un reenvío de puertos forzando una versión particular del procotolo SSH con plink, hay que especificar los parámetros: -ssh -2 (la versión SSH).

De este modo al intentar conectarnos por SSH estableciendo el reenvío de puertos para crear el túnel SSH. Y no tenemos la hostkey inicialmente cacheada en la máquina cliente, nos encontraremos con el siguiente problema.
Connection abandoned.
Disconected: Aborted at host key verification.
Conectándose de este modo, forzando la versión 2 del protocolo SSH, no aparece la solicitud y/n (si o no) para cachear la host key y directamente aborta la conexión.

Figura 6: Intento de conexión abortada con Plink especificando la versión 2 del protocolo SSH.

Aquí el truco sucio de "echo y | plink..." no funciona.

La única forma de auto aceptar el host key de una conexión con plink forzando a la versión 2 del protocolo SSH y que tenga establecido un port forwarding para el uso de un túnel SSH. Sería especificar el parámetro -hostkey seguido del fingerprint correspondiente.

La hostkey la podemos ver en una primera conexión, aunque esta no se establezca abortándose, igualmente se nos mostrará el fingerprint del host remoto correspondiente al servidor SSH.
plink.exe -ssh -2 -batch -v -L <puerto_local>:<host_remoto>:<puerto_remoto> -P <puerto_ssh> -pw <password> <usuario>@<servidor_remoto_ssh> -hostkey <hostkey_fingerprint>
Se especifica la host key correspondiente al servidor remoto SSH y vemos como la conexión se establece automáticamente.

Figura 7: Especificar la hostkey del servidor SSH cuando esta aún no está cacheada en el equipo cliente.

Probamos a conectarnos a través del túnel SSH creado. En este ejemplo era un reenvío de puertos del tipo local para una conexión RDP de Escritorio remoto.

Figura 8: Conexión RDP tunelizado por SSH.

Conexión establecida por RDP a través del tunelizado SSH. En una primera instancia auto aceptando la hostkey del servidor SSH cuando esta aún no está cacheada en la máquina cliente.

Figura 9: Conexión tunelizada por SSH - Conexión RDP establecida.

Saludos!
Entradas Relacionadas