Páginas

28 septiembre, 2019

Backups: Sincronizar datos locales a un bucket de Amazon S3 usando AWSCLI en PowerShell y Bash

Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de "Backups" sino de un sistema de sincronización. Si usando el mismo método almacenara copias durante un periodo de tiempo determinado con una autoeliminación de los backups más viejos, es decir una política de retención donde haiga la posibilidad de disponer de puntos de restauración dentro de las fechas establecidas en la política de retención, así como la posibilidad de almacenar un histórico de copias en frio en fechas más viejas. En ese caso si estaríamos aplicando el concepto de backup.

Esta es una forma sincronizar datos en dos sitios o ubicaciones distintas. Por un lado tenemos los datos locales que queremos salvaguardar y por otro un sitio cloud donde realizaremos la sincronización de dichos datos en un momento programado y definido previamente para que se realice después de manera automática.

Se trata de scripts de PowerShell y Bash Shell Script, compatibles en entornos Windows, Linux y MacOS, para sincronizar datos locales a un bucket S3 (Simple Storage Service) de Amazon Web Services a través de la interfaz de línea de comandos de AWSCLI (serverless). Donde se realiza un push de datos locales a una ubicación remota en un bucket de almacenamiento de Amazon S3.

En mí repositorio personal de Gihub comento en más detalle el procedimiento a seguir e iré actualizándolo con mejoras cuando proceda.
PowerShell
  • Funciones específicas para montar y desmontar unidades externas USB donde se almacenarán las copias de Veeam Backup.
  • Realizar compresiones 7zip cifrada de forma simétrica, usando adicionalmente un método de capas de ficheros comprimidos para almacenar la BBDD + key file de KeePassXC.
  • Sincronizar con AWS CLI los datos locales con el objeto (carpeta/directorio) del bucket S3.
  • Generar un fichero log de todo el proceso.
  • Enviar el fichero de log vía Email.
  • Enviar el fichero de log, contenido en formato de mensaje o ambas vía ChatBot de Telegram.
Bash Shell Script
  • Generar un fichero log de todo el proceso.
  • Sincronizar los datos locales con el objeto (carpeta/directorio) del bucket S3 usando AWSCLI.
  • Enviar el fichero de log vía Email desde el smtp de una cuenta de correo Gmail configurado en SSMTP.
Saludos!

04 septiembre, 2019

WMI Explorer: Restricción en las políticas de grupo GPO aplicando filtros WMI y querys en SCCM System Center

Los filtros WMI (Instrumental de administración de Windows) en las Políticas de grupo (GPO) permiten aplicar políticas de manera más flexible a los clientes mediante el uso de diferentes reglas. Un filtro WMI es un conjunto de consultas WMI (se usa el lenguaje de consulta WMI/WQL) que se puede usar para apuntar a las máquinas a las que se debe aplicar una política de grupo específica.

Por ejemplo, usando el filtro WMI GPO, puede aplicar una política vinculada a una OU solo a las máquinas que ejecutan Windows 10 (una política con dicho filtro WMI no se aplicará a las computadoras con otras versiones de Windows).

¿Para qué se utilizan los filtros WMI en las GPO?

WMI se puede usar cuando varios objetos de dominio (usuarios o equipos) se encuentran en la estructura AD plana en lugar de la unidad organizativa separada, o si se necesita aplicar políticas de grupo, de acuerdo con la versión del sistema operativo, configuración de red, software instalado o cualquier otro criterio que se pueda seleccionar usando WMI. Cuando el cliente procesa dicha política de grupo, Windows verificará el cumplimiento de la consulta WMI especificada, y si se cumplen las condiciones del filtro, la GPO se aplicará en esa máquina.

Lo más habitual en el uso de filtros WMI es distinguir sistemas operativos. Para estes casos las consultas deben hacerse en base al tipo de producto y el tipo de versión del OS.

Tipo de producto:
  • ProductType 1 = Desktop OS
  • ProductType 2 = Server OS - Solo Domain Controller
  • ProductType 3 = Server OS - Excepto Domain Controller
Versiones de sistema operativo:
  • Windows Server 2019, Windows Server 2016 y Windows 10 = 10.%
  • Windows Server 2012 R2 y Windows 8.1 = 6.3%
  • Windows Server 2012 y Windows 8 = 6.2%
  • Windows Server 2008 R2 y Windows 7 = 6.1%
  • Windows Server 2008 y Windows Vista = 6.0%
  • Windows Server 2003 = 5.2%
  • Windows XP = 5.1%
  • Windows 2000 = 5.0%
Tipo de arquitectura:
  • 32 bits = Win32_Processor where AddressWidth="32" // OSArchitecture="32-bit"
  • 64 bits = Win32_Processor where AddressWidth="64" // OSArchitecture="64-bit"
Algunos ejemplos de filtros WMI aplicados a GPOs:

Windows 7
select * from Win32_OperatingSystem where Version like "6.1%" and ProductType="1"
Windows 10 
select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"
Windows Server 2016
select * from Win32_OperatingSystem where Version like "10.0%" and ProductType="3"
Windows Server 2019
select * from Win32_OperatingSystem where BuildNumber >= 17763 and ProductType="3" and OSArchitecture="64-bit" 
Cualquier Windows Desktop OS de 32-bit 
select * from Win32_OperatingSystem where ProductType="1" and not OSArchitecture="64-bit" 
No ejecutar en Servidores Windows
select ProductType from Win32_OperatingSystem where (ProductType <> "2") and (ProductType <> "3")

En la siguiente imagen se puede ver un ejemplo de filtrado WMI de una sentencia WQL para consultar la versión de OS Windows 10.

Figura 1: Creación de filtros WMI en la Group Policy Management Console.

Después de crear el filtro WMI, elegimos el filtro WMI y lo aplicamos a una GPO existente.

Figura 2: Aplicar filtro WMI a una GPO existente.

WMI Explorer Tool y como nos puede ayudar a encontrar lo que buscamos para realizar Querys en SCCM.

Después de hacer una introducción a la restricciones en las polítcas de grupo mediante filtros WMI. En esta entrada quería dar a conecer el potencial de WMI Explorer y como nos puede ayudar para encontrar los espacios de nombres, instancias, consultas, clases, propiedades, métodos, parámetros de entrada y de salida necesarios para construir sentencias específicas WQL. Aunque también podemos disponemos de una zona de scripting para VBScript y Powershell.

WMI Explorer permite también conectarse a equipos remotos de una red de dominio que tengan el servicio WMI habilitado y permisos para la administración y acceso remoto WMI control.

En mi caso hice uso de esta herramienta para extraer los namespaces y propiedades WMI para consultas sobre el servicio DNS que posteriormente usé para realizar Queys en SCCM (System Center Configuration Manager).

Un ejemplo del resultado de una consulta WQL conectándose a un equipo remoto del dominio.

Figura 3: WMI Explorer - Ejemplo de consulta WQL en equipo remoto.

Búsqueda en una máquina local de propiedades recusivamente con el criterio "DNS".

Figura 4: WMI Explorer - Búsqueda de clases, propiedades namespaces, etc. en base un criterio de búsqueda.

Métodos encontrados en una clase concreta, parametros de entrada y parámetros de salida.

Figura 5: WMI Explorer - Resultado de clases, métodos y parámetros.
Ejecución de script VBScript o Powershell en texto o command promt en referencia a la clase y métodos encontrados.

Figura 6: WMI Explorer - Ejeción de scripting VBScript o Powershell en clases y métodos WMI.

Conclusiones

Es una herramienta en la que de la que se puede extraer mucha información y ayudarnos en la elaboración de consultas WQL y recolección de la información ordenada de una máquina local o remota.


Saludos!

Entradas Populares