21 mayo, 2019

Generar un fichero de log de la ejecución de las tareas de CRON con rsyslog

Cuando añadimos nuevas tareas programas a cron la única forma de que estas generen un log del proceso de las acciones que van realizando es redireccionarlas a un fichero de log, en la propia línea que ejecuta la tarea dentro de cron usando la redirección.

Un ejemplo podría ser:
01 14 * * * root /home/user/script.sh >> /logs/script.log 2>&1
Si no queremos ver las acciones de la tarea que se ejecuta y simplemente queremos comprobar si una tarea se está ejecutando y cuando. Podemos consultar el syslog del sistema buscando por la palabra CRON.
tail -f /var/log/syslog | grep CRON 
Si lo que queremos es obtener un fichero independiente con este filtro, es posible crear un fichero de log específico para la ejecución de tareas cron.

RSYSLOG (Rocket-fast system for log processing) es una utilidad que nos permite entre otras múltiples funcionalidades crear un filtro dentro del fichero syslog del sistema y exportar los resultados a un nuevo fichero.

Se creará un fichero cron.log que contendrá solamente las entradas CRON que se muestran en syslog. Hay que tener en cuenta que los trabajos de CRON seguirán apareciendo en syslog.

Por defecto rsyslog está instalado por defecto en Ubuntu, sino lo estuviese.
apt install -y rsyslog
Editamos el fichero
/etc/rsyslog.d/50-default.conf
Buscamos y descomentamos la línea:
#cron.*
Guardamos el fichero.

Habilitamos el servicio automáticamente en el inicio del sistema y reiniciarlo.
systemctl enable rsyslog
systemctl restart rsyslog
Ahora debería existir un fichero de registro cron en:
/var/log/cron.log
Saludos!

10 mayo, 2019

RaspberryPi: Captar temperatura y humedad con sensor DHT22 (AM2302) y enviar datos a ThingSpeak.com

RaspberryPi: Captar temperatura y humedad con sensor DHT22 (AM2302) y enviar datos a ThingSpeak.com.

Requisitos previos

Instalar Python 2

sudo apt update -y
sudo apt install python-pip -y
sudo python -m pip install --upgrade pip setuptools wheel

Instalar librerías Adafruit

git clone https://github.com/adafruit/Adafruit_Python_DHT.git
cd Adafruit_Python_DHT
sudo python setup.py install

Esquema de conexión: Temperatura y Humedad sensor DHT22 AM2302

El sensor DHT22 AM2302 consta de 3 pines:
  • + (positivo) = Voltaje 3V (Power - pin 1)
  • - (negativo) = Tierra (Ground - pin 6)
  • out = Salida de datos (GPIO4 - pin 7)
Podemos hacer otro esquema de conexión siempre que se respete la funcionalidad de cada pin del sensor al esquema de conexión de la RaspberryPi. Hay que tener en cuenta el número de GPIO donde iría conectado el pin "out" del sensor, este nos proporciona la salida de datos captados.

En el script "thingspeak_raspi_dht22.py" establecemos el número de GPIO en la variable raspiNumGPIO.

Test de conexión del sensor DHT22 AM2302

Teniendo las librerías Adafruit ya instaladas una forma de probar la conexión entre el sensor y la RaspberryPi es ejecutar el script de ejemplo para obtener los datos de temperatura y humedad actuales.

Se le pasa como primer parámetro el modelo de sensor "2302" y el número de GPIO del pin correspondiente donde está conectado la salida de datos (out) del sensor, en este caso 4 (GPIO4).
$ python Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 4
Temperatura=21.2* Humedad=57.7%
Figura 1: Esquema de conexión GPIO Raspberry PI 3 B/B+.
Figura 2: Conexión física del sesnor dht22 am2302 a Raspberry Pi 3 B+.

Script Python para el envío de datos a la cuenta de ThingSpeak (thingspeak_raspi_dht22.py)

import sys
import urllib2
import RPi.GPIO as GPIO
import Adafruit_DHT
# Write API Key ThingSpeak.com
miWriteAPIKey = "XXXXXXXXXXXXXXXX"
# Número GPIO de conexión out del sensor dht22 a RaspberryPi
raspiNumGPIO = "X"
def getSensorData():
   RH, T = Adafruit_DHT.read_retry(Adafruit_DHT.DHT22, raspiNumGPIO)
   return (str(RH), str(T))
def main():
   print 'Iniciando...'
   baseURL = 'https://api.thingspeak.com/update?api_key=%s' % miWriteAPIKey
   while True:
       try:
           RH, T = getSensorData()
           f = urllib2.urlopen(baseURL + "&field1=%s&field2=%s" % (RH, T))
           print f.read()
           f.close()
           sleep(5)
       except:
           print 'Terminado.'
           break
if __name__ == '__main__':
main()

Configuración de la cuenta de ThingSpeak.com

  1. Registrarse en https://thingspeak.com
  2. Si no tenemos cuenta previa en MathWorks. ThingSpeak nos redirigue, con la posibilidad de usar el mismo email, hacia el registro de https://www.mathworks.com.
  3. Crear un nuevo channel en nuestra perfil y agregar dos field chart (Temperatura y Humedad).
  4. Obtener el "Write API Key" del channel creado.
  5. Establecer el "Write API Key" en el script "thingspeak_raspi_dht22.py" en la variable miWriteAPIKey.
  6. Podemos usar y personalizar plantillas de código Matlab para la visualización de los datos registrados en los field chart del channel de ThingSpeak.

Programar el envío de datos a ThingSpeak.com (crontab)

Añadimos una tarea programada en cron (/etc/crontab) que ejecutará el script "thingspeak_raspi_dht22.py" enviando los datos captados a nuestra cuenta de ThingSpeak.
@hourly root python /thingspeak/thingspeak_raspi_dht22.py
Channel ThingSpeak: https://thingspeak.com/channels/769908/

Figura 3: Ejemplo de tablas de campo (field chart) del envío de datos a la cuenta de ThingSpeak.
Saludos!

17 abril, 2019

Migración de replicación FRS a DFSR entre controladores de dominio Windows Server [dfsmig]

En el caso que tengamos un controlador de dominio Windows Server 2008 R2 con replicación FRS (File Replication Service) y se necesite migrar a unos nuevos controladores de dominio Windows Server 2019 que haga uso de del sistema de replicación DFS (Distributed File System) habría que realizar una migración de los controladores viejos a un sistema de replicación DFS.

Elevar el nivel funcional

Primero será necesario elevar el nivel funcional del dominio en los controladores de dominio viejos. El nivel funcional determina las características de los Servicios de dominio de Active Directory (AD DS) que están habilitadas en un dominio o bosque. El nivel funcional del bosque limita al nivel funcional del dominio y solo afecta a los servicios de AD de los controladores de dominio, en el el caso de tener un servicio DHCP, IIS, WSUS, etc. no se verían afectados.

En los controladores de dominio viejos. Dominios y confianzas de Active Directory.

Figura 1: Elevar el nivel el nivel funcional del dominio...

Figura 2: Elevar el nivel funcional del domnio disponible al nivel más alto posible.

Verificar que la replicación antes de realizar la migración a través una cmd:
repadmin /showrepl
repadmin /replsummary

Comprobar que el servicio de "DFS Replication Service" está corriendo en modo automático en todos los DCs de dominio.
sc qc DFSR


Tipos de estado de migración FRS a DFSR

Estados Estables / Estados Globales de Migración
  • STATE 0 START
  • STATE 1 PREPARED
  • STATE 2 REDIRECTED
  • STATE 3 ELIMINATED
Estados de Transición / Estados Locales de Migración
  • STATE 4 Preparing
  • STATE 5 Waiting for initial sync to complete
  • STATE 6 Redirecting
  • STATE 7 Eliminating
  • STATE 8 Undo redirecting
  • STATE 9 Undo preparing

Una vez que hemos pasado al estado 3 ELIMINATED ya no hay posibilidad de hacer rollback a una situación anterior.

Más info: https://blogs.technet.microsoft.com/filecab/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process

Migración RFS a DFSR

Se hará uso de la herramienta en línea de comandos dfsrmig.
dfsrmig /setglobalstate 1
Estado 1 glocal (PREPARED) se crearán todos los objetos necesarios para la replicación DFS-R. Se crea un nuevo recurso compartido SYSVOL_DFSR (C:\Windows\SYSVOL_DFSR) dejando de momento el actual SYSVOL. Podemos usar "dfsrmig /getmigrationstate" para comprobar el estado actual de la migración.

Figura 3: Migración RFS a DFSR - Estado 1 global (Prepared).

Estado 2 global (REDIRECTED) lanzará el proceso de migración desde SYSVOL a SYSVOL_DFSR.
dfsrmig /setglobalstate 2
Figura 4: Migración RFS a DFSR - Estado 2 global (Redirected).

El editor ADSI (Active Directory Services Interfaces) es un editor del directorio de bajo nivel basado en LDAP que permite la edición y visualización de atributos de los objetos del bosque.

Además nos permite modificar aquellos atributos que no podemos trabajar desde las otras consolas de administración del directorio como Usuarios y equipos de Active Directory, Sitios y servicios u otras.

AD LDS (Active Directory Lightweight Directory Services) es un servicio de directorio LDAP que proporciona almacenamiento y recuperación de datos a aplicaciones habilitadas para el uso de directorios, sin las dependencias necesarias para los Servicios de dominio de Active Directory.

Comprobamos que FRS como DFSR siguen activos en este punto de la migración.

Figura 5: Comprobación de estado de FRS y DFSR en el editor ADSI.

Estado 3 global (ELIMINATED) eliminará la carpeta SYSVOL y deshabilitará el servicio FSR. En este punto como ya se comentó anteriormente no hay posibilidad de vuelta atrás.
dfsrmig /setglobalstate 3
Figura 6: Migración RFS a DFSR - Estado 3 global (Eliminated).

Una vez finalizada la migración comprobamos a través del editor ADSI que que el servicio FRS ya no se esté usando.

Figura 7: Comprobación de eliminación de FRS en el editor ADSI

Comprobamos en la consola de servicios (services.msc) que FRS está en estado deshabilitado y DFSR está en ejecución.

Figura 8: Comprobar el estado de los servicios FRS y DFS-R.

Por último, comprobamos la correcta replicación entre todos los controladores de dominio.
repadmin /replsummary
Figura 9: Comprobar finalmente la correcta replicación entre todos los controladores.

Saludos!

12 abril, 2019

Fallos en la replicación FRS y DFSR en Active Directory: Como forzar la sincronización no-autoritativa y autoritativa [Burflags]

Replicación FRS y DFSR

  • FRS (File Replication Service) servicio para distribuir archivos compartidos y objetos de directiva de grupo entre controladores de dominio a través del recurso C:\Windows\SYSVOL. Windows Server 2003 R2 y Windows Server 2008 son compatibles con DFS (Distributed File System) y el servicio de replicación de archivos.
  • DFSR (Distributed File System Replication) disponible por defecto a partir de Windows Server 2008 R2, reemplaza al sistema FRS para la replicación del recurso SYSVOL en los servicios de dominio de Active Directory. DFS replica los objetos de configuración almacenados de Active Directory.

Restauración "no autoritativa" y "autoritativa"

  • Restauración No-Autoritativa: conserva los USN (Update Sequence Number) de los objetos del Directorio Activo desde la fecha que se creó la copia de seguridad del estado del sistema (System State). El sistema de replicación de Active Directory utiliza este número para detectar y propagar los cambios de Active Directory entre los distintos servidores de la organización. Debido a que el USN del servidor restaurando siempre será anterior a los USN actuales, los datos de este servidor nunca se replicarán con el resto de controladores de dominio. Por el contrario, si existen datos más recientes en los otros servidores, el sistema de replicación de AD los utilizará para actualizar los datos restaurados. Este procedimiento se suele realizar cuando queremos restaurar algún complemento del Sistema Operativo como una cuenta de usuario, equipo, DC, etc.
  • Restauración Autoritativa: debemos de realizar primero una restauración no autoritativa y luego mediante la utilidad NTDSUTIL realizar una restauración autoritativa. De esta forma se consigue que los Objetos restaurados se les cambie el número de secuencia de actualización USN para que sea mayor al de cualquier otro USN del directorio. Así el servidor restaurado se asegura de que cualquier dato u objeto sea replicado y distribuido adecuadamente en todos los controladores de dominio.

Fallo de replicación FRS

En el caso de que tengamos dos o más controladores de dominio y que se apague un controlador de dominio el cual no esté correctamente sincronizado. Posteriormente, se levante un nuevo controlador de dominio con un sistemas operativo más actual que PDC (Primary Domain Controller) si el DC viejo se volviese a levantar puede que ocurra fallos en la sincronización.

Figura 1: Mensaje de fallo de replicación FRS en servicios de Active Directory.

Registro de evento Id. 1308: KCC (Knowledge Consistency Checker) ha detectado errores. KCC Es un proceso integrado que se ejecuta en todos los controladores de dominio y genera la topología de replicación de bosque de Active Directory.

Figura 2: Comprobador de coherencia de la información KCC . Id. 1308.

Registro de evento Id. 13508: Problemas en la replicación de objetos de los servicios de AD entre uno de los controladores de dominio. En este caso el servidor "X3550" no sincroniza con el servidor "SRVDOMINIO".

Figura 3: Fallo de sincronización de uno de los controladores de dominio. Id. 13508.

¿Cómo reinicializar o forzar la sincronización de replicación autoritativa o no autoritativa? 


El valor del registro Burflags genera la copia de cada controlador de dominio del árbol de volumen del sistema (SYSVOL) en todos los controladores de dominio de Active Directory.

Los valores D2 y D4 Burflags son los que controlan como se replica FRS entre los controladores de dominio.

  • Si se inicia FRS con valor del registro Burflags establecido en D4 (sincronización autoritativa):
FRS trata inicialmente los archivos y carpetas de su copia local del árbol de SYSVOL como autorizados para el conjunto de réplicas. Si tenemos varios controladores de dominio, Burflags se debería establecer con valor D4 en un controlador de dominio único y en D2 en los demás controladores de dominio de ese dominio. Esta configuración se conoce como "Restauración autoritativa".

  • Si se inicia FRS con el valor del registro Burflags establecido en D2 (sincronización no autoritativa):
FRS realiza una sincronización completa de los archivos y carpetas desde un asociado de replicación directo o transitivo que aloje la copia autorizada de los archivos y carpetas del conjunto de réplicas. Esta configuración se conoce como "Restauración no autoritativa" aunque no se produzca ninguna restauración del estado del sistema (System State). La configuración D2 regenera la parte de FRS del controlador de dominio como si fuera nuevo.


Configurar las réplicas de SYSVOL como autoritativo

[1] - Detener el servicio FRS de todos los controladores de dominio.
[2] - En el PDC (Principal Domain Controller). (podemos averiguar el PDC haciendo un "netdom query fsmo"). Nos situamos en la siguiente rama del registro.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID
GUID (Globally Unique Identifier) del conjunto de réplicas del volumen del sistema del dominio.

[3] - Creamos o modificamos el valor DWORD BurFlags y lo establecemos a D4.

Figura 2: Repliación FRS: Sincronización autoritativa BurFlags con valor D4.

[4] - Reiniciamos el controlador de dominio principal y comprobamos que los servicios de Active Directory estén nuevamente sincronizados.

Más info: https://support.microsoft.com/es-es/help/315457/how-to-rebuild-the-sysvol-tree-and-its-content-in-a-domain

Después de forzar la sincronización entre los controladores de dominio, puede que nos interese transferir los roles FSMO y hacer purgado de los servicios del dominio (de darse el caso). Transferir roles FSMO Windows Server y hacer purgado de los servicios del dominio.

Saludos!

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!

11 febrero, 2019

Resetear la password SSO Administrator@vsphere.local de VMware vCenter (VCSA)

Para resetear la password SSO del usuario "Administrator@vsphere.local" de vCenter. Accemos a la gestión del VCSA (vCenter Server Appliance) por el puerto 5480 con el usuario root y password.
https://IP-vCenter_o_hostname:5480
Una vez en el appliance de vCenter, en la sección de Acceso marcamos:
  • Habilitar inición de sesión en SSH.
  • Habilitar el shell Bash.
Figura 1: Habilitar el acceso SSH y Shell Bash para VCSA.

Nos conectamos por SSH al vCenter y habilitamos el uso de acceso a Shell Bash y entramos en la Shell.
shell.set --enabled true
shell
Una vez estamos en el Shell prompt ":~ #" ejecutamos vdcadmintool desde su ruta absoluta.
/usr/lib/vmware-vmdir/bin/vdcadmintool
Este ejecutará un menú de opciones, para este caso elegirémos la opción 3 "Reset account password". Establecemos la cuenta SSO "Administrator@vsphere.local" y nos generará una password aletoria. Con la opción 0 salimos del menú.

Figura 2: Resetear passworrd SSO Administrator desde vdcadmintool.

Accedemos ahora a vSphere Web Client.
https://IP-vCenter
Nos identificamos con el usuario SSO Administrator@vsphere.local y la password generada anteriormente.

Figura 3: SSO Administrator@vsphere.local vSphere Web Client.

Una vez logueados cambiamos la password por la que queramos establecer.

Figura 4: Cambiar password SSO Administrator@vsphere.local.

Por último podemos configurar que la password nunca expire. Configuración > Directivas > Directiva de constraseñas, editamos la directiva y establecemos a 0 días la duración máxima en la que la contraseña se debe cambiar.

Figura 5: Configurar que la password de SSO Administrator@vsphere.local nunca expire.

Saludos!

06 febrero, 2019

Habilitar virtualización anidada VT-x/AMD-V en Virtualbox cuando no se puede activar (nested virtualization)

[1] - Habilitar la virtualización a nivel de BIOS/UEFI en el host anfitrión. Opción VT-x (procesadores Intel) o AMD-v (procesadores AMD).

[2] - Comprobar que no haiga otro hypervisor (VMware o Hyper-V por ejemplo) usándose o con una mayor prioridad que no sea Virtualbox instalado en el host anfitrión.

[3] - La característica de viritualización anidad o nested virtualization en Virtualbox solo está disponible en versiones igual o superior a 6.0.

Esta característica es visible y se puede habilitar en: Sistemas > Procesador > Habilitar PAE/NX y Habilitar VT-x/AMD-V anidado.

En la siguiente screenshot se muestra como la característica es visible pero no nos permite habilitarla, pero esta opción se puede forzar para habilitarla en la máquina virtual seleccionada.

Figura 1: Caracteristica extendida - No es posible habilitar la virtualización aninada para la VM seleccionada.

[4] - Listar el nombre e ID de las VMs creadas con Virtualbox en nuestro host afitrión, esto lo haremos con la utilizada de comandos de VBoxManage.exe de Virtualbox. En el caso de Windows, desde una CMD accedemos a la ruta donde se encuentra este binario.
C:\Program Files\Oracle\VirtualBox
[5] - Listamos las VMs disponibles.
VBoxManage list vms
[6] - Modificamos la característica de la VM seleccionada, forzando así que se habilite la virtualización anidada con el parámetro --nested-hw-virt on.
VBoxManage modifyvm "Nombre-VM o {ID-VM}" --nested-hw-virt on
Referencia: https://docs.oracle.com/cd/E97728_01/F12469/html/nested-virt.html

Figura 2: Virtualización anidada habilitada para la VM seleccionada.

[7] - Si se habilitó correctamente la virtualización anidada podemos comprobarlo desde la VM seleccionada.

En el caso de usar un procesador Intel.
cat /proc/cpuinfo | grep vmx
En el caso de usar un procesador AMD.
cat /proc/cpuinfo | grep smv
Si todo a salido correctamente se debería mostrar contenido resultante que contiene "vmx" (en este caso de ejemplo se trataba de un procesador Intel). De no estar habilitada la virtualización anidada para la máquina virtual seleccionada no nos mostraría nada como resultado del cat.
 
Figura 3: Comprobación de que la virtualización anidada está habilitada en la VM seleccionada.

Saludos!

30 enero, 2019

Túnel SSH port forwarding: Local, remote y dynamic [Explicado]

¿Qué es SSH?

ssh-tunnelingSSH (Secure Shell) es un protocolo de comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor que permite a los usuarios conectarse a un host remotamente para su posterior administración. A diferencia de otros protocolos de comunicación remota como FTP o Telnet (Telecommunication Network), SSH cifra la sesión de conexión y la comunicación ofreciendo también una infraestructura de autenticación PKI (Public Key Infrastructure) para la conexión con el host remoto.

Para poder establecer una conexión a un host que tenga implementado el rol de servidor SSH es necesario disponer de un cliente SSH. El puerto por defecto de escucha del servicio SSH es el 22.

Una vez se disponga de una comunicación establecida al servidor SSH se pueden usar los protocolos SFTP (SSH File Transfer Protocol) o SCP (Secure Copy) para la transferencia segura de ficheros entre cliente/servidor.

¿Qué es un tunel SSH?

Es una técnica que consiste en encapsular un protocolo de red sobre otro o un determinado tráfico de red. En el caso de usar conexión SSH se trata de realizar esta técnica de forma segura añadiendo una capa de seguridad en la que los datos viajan de forma cifrada a través del túnel SSH, realizando un reenvío o redirección de puertos (port forwarding) desde una máquina local a otra remota (o viceversa) para establecer una comunicación a un recurso o servicio accesible solamente desde uno de los extremos de la red.

Suele usarse para conectarse a un servicio remoto que solo se tiene acceso desde la red local remota. A través de un cliente SSH nos podemos conectar a un servidor SSH remoto que tenga acceso a la red remota a la que queremos acceder, especificar un reenvío de puertos para establecer las conexiones a ese servicio y así poder ejecutarlo de forma local desde la máquina que inició la conexión SSH. El método más habitual suele ser el reenvío de puertos local.

¿Tipos de reenvíos de puertos? (port forwarding)

  • Reenvío de puerto local (Local por fortwarding)
  • Reenvío de puerto remoto (Remote port forwarding)
  • Reenvío de puerto dinámico (Dynamic port forwarding)

SSH Local port forwarding

Local (Redirección de puertos local): Reenvía un puerto local a un host remoto.

Si un servicio se ejecuta en la máquina remota en la que establecemos la conexión y queremos ejecutar este servicio en la máquina local que inicia la conexión, se puede acceder a este servicio de desde nuestra máquina local usando la dirección local de lookback (127.0.0.1 o localhost) haciendo referencia al puerto mapeado a través de la conexión de inicio de la sesión SSH.

Pongamos un escenario de ejemplo de una conexión local port forwarding de escritorio remoto RDP realizando pivoting a otro equipo dinstinto al servidor SSH.

Supongamos que estamos en una red A y queremos acceder por escritorio remoto a un equipo situado en una red B (192.168.0.10), pero que por restricción del Firewall de la red A solo podemos realizar solicitudes de conexión al puerto 22 de SSH y no al puerto 3389 del servicio RDP. Lo que podemos hacer es crear una conexión desde un cliente SSH desde la red A (172.16.0.20) a un servidor SSH situado en la red B (192.168.0.15), en esa conexión tendremos que especificar un port forwarding local en un puerto aleatorio (mayor del puerto 1024 para que esté fuera del rango de "puertos bien conocidos") por ejemplo el 9090 como puerto origen (puerto local) de la red A y la IP:3389 del equipo de la red B al que nos queremos conectar (192.168.0.10), después de establecer esta parametrización nos conectamos al servidor SSH de la red B para crear el túnel local.

En el host de la red A que estableció la conexión desde el cliente SSH (172.16.0.20) abrimos un cliente de RDP (mstsc Windows, rdesktop o Remmina en Linux) y nos conectamos a "localhost:9090". Esto redirigirá la petición del host localhost (172.16.0.20) del puerto 9090 al servidor SSH de la red B que a su vez este redirigirá la petición al host destino 192.168.0.10 hacia el puerto 3389 y así establecer la conexión RDP.

En el caso de querer conectarse a otro servicio o desde otro host que no sea el propio host que realiza conexión desde el cliente SSH se especificaría: "<host-remoto>:<puerto-remoto>".

Desde una terminal se usa el parámtro -L para port forwarding local.
ssh -L <puerto-local-escucha>:<host-remoto>:<puerto-remoto> <servidor-ssh>
ssh -L 9090:192.168.0.10:3389 mi.servidorssh.com
PuTTY - Local port forwarding SSH Tunneling.
Figura 1: PuTTY - Local port forwarding SSH Tunneling.
  • Cliente SSH (Red A): 172.16.0.20
  • Servidor SSH (Red B): 192.168.0.15
  • Host RDP (Red B): 192.168.0.10
Figura 2: SSH port forwarding - Túnel SSH local.

SSH Remote port forwarding

Remote (Reedirección de puertos inverso): Reenvía un puerto remoto a un host local.

Al contrario que una conexión de túnel local, si un servicio solo es accesible desde una máquina de la red local y se necesita tener conexión a el de forma remota. Se puede usar un puerto específico de escucha para conectarse a esa máquina remota y que esta nos proporcione el servicio a través de ella, pivotando posteriormente esa conexión a la máquina desde la que se inicia la sesión SSH.

Pongamos un ejemplo con los mismos hosts del escenario anterior de una conexión remote port forwarding de escritorio remoto RDP.

Supongamos que estamos en una red A y queremos ofrecer el servicio de escritorio remoto RDP situado en la red A (172.16.0.20), pero este servicio hacía este host solo solamente es accesible desde la red A y no desde otras redes externas. Lo que podemos hacer es crear una conexión con un cliente SSH desde el mismo host de la red A a un servidor SSH situado en la red B (192.168.0.15), en esa conexión tendremos que especificar un port forwarding remote en un puerto aleatorio (mayor del puerto 1024 para que esté fuera del rango de "puertos bien conocidos") por ejemplo el 9090 como puerto origen (puerto remoto) de la red B y la 172.16.0.20:3389 del equipo de la red A del que queremos ofrecer la conexión RDP (sería válido también localhost:3389 ya que se trata del mismo equipo local quien es el cliente SSH que establece la conexión), después de establecer esta parametrización nos conectamos al servidor SSH de la red B para crear el túnel remoto.

La idea es prácticamente la misma que el tunel local, la diferencia está en que la conexión se establece de forma inversa (reverse port forwarding)

En el host 192.168.0.10 de la red B abrimos un cliente de RDP (mstsc Windows, rdesktop o Remmina en Linux) y nos conectamos a "192.168.0.5:9090" (servidor SSH de la red A). Esto redirigirá la petición al puerto 9090 al host destino de la red B 172.16.0.20 hacia el puerto 3389 para establecer la conexión RDP.

En el caso de ofrecer otro servicio o desde otro host que no sea el propio host que realiza conexión desde el cliente SSH se especificaría: "<host-local>:<puerto-local>".

Directivas en el servidor SSH (/etc/ssh/sshd_config)

Para que el servidor SSH permita el conexiones de puertos de reenvío remoto es necesario habilitar principalmente la directiva GatewayPorts. Referencia: https://linux.die.net/man/5/sshd_config

AllowTcpForwarding

Especifica si se permite el reenvío de TCP, de forma predeterminada el valor está establecido a "yes".

GatewayPorts

Especifica si los hosts remotos pueden conectarse a los puertos reenviados para el cliente. De forma predeterminada, enlaza los reenvíos de puertos remotos a la dirección de loopback. Esto evita que otros hosts remotos se conecten a puertos reenviados. Por lo que para poder usarse para el reenvío de puertos remotos debe establecerse a "yes".

Desde una terminal se usa el parámtro -R para port forwarding remote.
ssh -R <puerto-remoto-escucha>:<host-local>:<puerto-local> <servidor-ssh>
ssh -R 9090:172.168.0.20:3389 mi.servidorssh.com
o también
ssh -R 9090:localhost:3389 mi.servidorssh.com
PuTTY - Remote port forwarding SSH Tunneling.
Figura 3: PuTTY - Remote port forwarding SSH Tunneling.
  • Cliente SSH y Host RDP (Red A): 172.16.0.20
  • Servidor SSH (Red B): 192.168.0.15
  • Client RDP (Red B): 192.168.0.10
Figura 4: SSH port forwarding - Túnel SSH remoto.

SSH Dynamic port forwarding

Dynamic (Redirección de puertos dínamico): Utiliza SOCKS.

Se comporta como un proxy SOCKS, suele usarse si nos necesitamos conectar a un software que espera un reenvío de SOCKS.

La idea es igual que cuando se establece un túnel local SSH. La diferencia es que los datos se enviarían a todos los destinos remotos. Para utilizar este tipo de conexión es necesario que la aplicación del cliente que se conecta al puerto local debe enviar tráfico mediante el protoclo SOCKS. En el lado del túnel del cliente se crearía un porxy SOCKS y la aplicación (por ejemplo un navegador web) utiliza el protocolo SOCKS para especificar donde debe enviarse el tráfico cuando sale del otro extremo del túnel SSH.

SSH creará un proxy SOCKS que escuchará las conexiones en el puerto 9090, al recibir una solicitud enrutará el tráfico a través del canal SSH establecido entre la red A (172.16.0.20) y la red B (192.168.0.15). Para ello, es necesario configurar la aplicación (navegador web) del host de la red A para que apunte al proxy SOCKS en el puerto 9090 en localhost. De ese modo estaremos saliendo con la conexión pública (si el mecanismo NAT está habilitado) a través de este navegador web como si estuviésemos en la red B.

Ejecutándolo desde un cliente SSH desde la red A. Desde una terminal se usa el parámtro -D para port forwarding dynamic
ssh -D <puerto-origen-dinámico-escucha> <servidor-ssh>
ssh -D 9090 mi.servidorssh.com
PuTTY - Dynamic port forwarding SSH Tunneling.
Figura 5: PuTTY - Dynamic port forwarding SSH Tunneling.

Proxy SOCKS navegador web.
Figura 6: Proxy SOCKS navegador web.
  • Cliente SSH (Red A): 172.16.0.20
  • Servidor SSH (Red B): 192.168.0.15
SSH port forwarding - Túnel SSH dinámico.
Figura 7: SSH port forwarding - Túnel SSH dinámico.

Repositorio Github: https://github.com/adrianlois/SSH-Tunnel-Port-forwarding

Saludos!

18 enero, 2019

Cifrar passwords con PowerShell

Con PowerShell podemos generar passwords simétricas y guardarlas cifradas en ficheros.

Esto lo utilizo para cifrar mis copias de seguridad. Hice un repositorio donde referencio el código PowerShell utilizado para realizar estas copias de seguridad.

Uno de los pasos en la realización de estas copias era establecer unas passwords y guardarlas en ficheros de forma cifrada. Dejo la referencia al repositorio: https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell

Crear passwords cifradas con PowerShell para usar desde el mismo usuario

Cuando establecemos una password en Powershell y la volcamos en un fichero, el fichero que contiene la password cifrada solo sería se podría usar desde el usuario que la estableció.

Para establecer una password con Powershell y volcarla a un fichero de forma cifrada convirtiendo la cadena de texto plano establecida a una cadena cifrada segura (ConvertFrom-SecureString).
Read-Host -AsSecureString "Password fichero" | ConvertFrom-SecureString | Set-Content "C:\Passwords\fichero-passw-cifrada"
Llamar al fichero con la password cifrada almacenada en un script Powershell, convertir la cadena cifrada en texto plano (ConvertTo-SecureString).
Get-Content "C:\Passwords\fichero-passw-cifrada" | ConvertTo-SecureString
Repositorio donde se muestra este método y un video demo PoC.
https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell/tree/master/backup-v2.0


Crear passwords cifradas con PowerShell generando un keyfile (portable) para usar desde cualquier usuario o máquina

Otra forma de cifrar la passwords en Powershell sería generar un keyfile (fichero llave único para descifrarlas). De ese modo teniendo el keyfile y referenciándolo en el script de Powershell se pueden cifrar con el keyfile y posteriormente descifrar las password establecida volcada en el fichero.

La ventaja respecto al método anterior, es que se pueden descifrar los ficheros que almacenan las passwords cifradas desde cualquier usuario de la misma máquina o cualquier usuario de otra máquina distina. Pudiendo así transportar los ficheros de passwords y keyfile para ser utilizados por otros usuarios o máquinas.

Generar el keyfile y establecer la password para volvarla a un fichero asociándola al keyfile (Read-Host -AsSecureString , ConvertFrom-SecureString -key).

$CifradoKeyFile = New-Object Byte[] 32
[Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($CifradoKeyFile)
$CifradoKeyFile | out-file "C:\Passwords\CifradoKeyFile.key"

Read-Host -AsSecureString "Password fichero" | ConvertFrom-SecureString -key (Get-Content "C:\Passwords\CifradoKeyFile.key") | set-content "C:\Passwords\fichero-passw-cifrada"
Concatenar el keyfile para descifrar el fichero password cifrado (ConvertTo-SecureString -Key).
Get-Content "C:\Passwords\fichero-passw-cifrada" | ConvertTo-SecureString -Key (Get-Content "C:\Passwords\CifradoKeyFile.key")
Repositorio donde se muestra este método con generación de keyfile y un video demo PoC.
https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell/tree/master/backup-v2.1


Saludos!

15 enero, 2019

Ejecutar WMIC en equipos remotos de la red local (Windows Management Instrumentation)

Si nos surgen problemas para la ejecución sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos.

Un error puede ser que no esté habiliado las llamadas a procedimientos remotos (RPC).
Error:
Descripción = El servidor RPC no está disponible.
Error - "El servidor RPC no está disponible" (wmic)
Figura 1: Error - "El servidor RPC no está disponible" (wmic).

Otro error común podría ser la falta de permisos para ejecutar WMIC en nodos remotos.
Error:
Descripción = Acceso denegado.
Error - "El servidor RPC no está disponible" (wmic)
Figura 2: Error - "Acceso denegado" (wmic).

Comprobar que el servicio "Instrumental de administración de Windows" (Winmgmt) está habilitado en el tipo de inicio automático y esté en ejecución.

Servicios winmgmt (wmic) en Windows
Figura 3: Servicios winmgmt (wmic) en Windows.

Habilitar la regla por aplicaciones permitidas del firewal (WFAS) de Windows para permitir comunicaciones y llamadas RPC de WMI. Dependiendo cada caso si se trata de una red privada o de dominio.

Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI
Figura 4: Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI.

Verificar que el uso compartido de archivos e impresoras esté activado para el tipo de red según sea el caso. Por defecto en una red de dominio esta característica suele estar activada por defecto cuando un equipo cliente se uno al dominio.

Activar el uso de recurso compartido de archivos e impresoras
Figura 5: Activar el uso de recurso compartido de archivos e impresoras.

Comprobar que en la consola del equipo remoto haiga permisos suficientes para el usuario que ejecutará wmic.

Esto se puede modificar en la consola de Microsoft "wmimgmt.msc", en la pestaña de seguridad, se modifican los permisos para permitir la "Llamada remota habilita" y "Ejecutar métodos".

Permisos de seguridad al Control WMI
Figura 6: Permisos de seguridad al Control WMI.

Por último, y algo fundamental según las pruebas que he realizado, es que independientemente de si el equipo cliente remoto en el que se quiere ejecutar WMI forme parte de una red de dominio o una red privada. Será necesario crear un valor en el registro de Windows "LocalAccountTokenFilterPolicy" algo ya comentado en este artículo.

Desde mi punto de vista esto no es aconsejable a métodos de seguridad, no es para nada una buena práctica, pero si se trata de casos puntuales en los que se necesita realizar una serie de acciones remotas simplemente, por seguridad aconsejo volver a eliminar este valor del registro.

Para poder ejecutar este valor en el registro podemos hacerlo ejecutando una CMD en el equipo remoto a través de PsExec (PsTools de Sysinternals). En este artículo hay se detalla como hacerlo.

El valor LocalAccountTokenFilterPolicy se trata básicamente de "deshabilitar" el UAC (User Account Control) para la ejecución de acciones remotas.

Para añadir el valor LocalAccountTokenFilterPolicy a través de una CMD:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Para posteriormente eliminar el valor LocalAccountTokenFilterPolicy a través de una CMD:
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /f

En el siguiente ejemplo se puede ver como se ejecuta WMIC remotamente desde un equipo local a un equipo remoto usando "wmic /node", especificando la dirección IP local o el hostname del equipo remoto y un usuario/password con privilegios administrativos en la máquina remota.
wmic /node:ip_hostname /user:usuario /password:password bios get serialnumber
Ejecución remota de "wmic /node"
Figura 7: Ejecución remota de "wmic /node".

Saludos!
Entradas Relacionadas