Sabia que você pode monitorar praticamente todas as ações no Windows? Não, você não precisa comprar algum software sofisticado. A infraestrutura monitora eventos como quando os serviços são iniciados e interrompidos, quando alguém cria um arquivo ou pasta e muito mais, já está disponível através dos eventos do Windows Management Instrumentation (WMI).
Os eventos do WMI não são uma característica específica do PowerShell, mas uma das maneiras mais fáceis de aproveitar os eventos do WMI e criar algumas ferramentas úteis é o PowerShell. Neste tutorial passo a passo, você aprenderá como aproveitar os eventos do WMI com o PowerShell e obter as habilidades necessárias para construir algumas ferramentas de monitoramento úteis!
Vamos lá!
Pré-requisitos
Você verá muitas demonstrações neste tutorial prático. Se você deseja acompanhar qualquer uma das demonstrações, certifique-se de ter o seguinte:
- Windows 7+ ou Windows Server 2012+ – Este tutorial usará o Windows Server 2019.
- Logado como usuário no grupo de administradores local.
- Windows PowerShell 5.1 ou PowerShell 6+ – Este tutorial usará o PowerShell v7.1.2.
Entendendo o WMI e CIM
Antes de começar com os eventos do WMI, é importante entender primeiro a infraestrutura sobre a qual eles são construídos. Embora este tutorial não entre em detalhes sobre o WMI, você sempre pode consultar a documentação do WMI da Microsoft para saber mais.
WMI e seu modelo de dados relacionado Common Information Model (CIM) são modelos integrados ao Windows que armazenam praticamente qualquer informação em um repositório que você precisa relacionado ao funcionamento interno do Windows e ao que está sendo executado nele.
WMI e CIM são ferramentas poderosas que os administradores usam para gerenciar o Windows local e remotamente. Usando WMI ou CIM, os administradores podem consultar informações em um sistema Windows, como aplicativos instalados, status do serviço, arquivos no sistema de arquivos e praticamente tudo mais.
WMI e CIM são como muitas soluções de monitoramento empresarial coletam informações de saúde do sistema operacional e de aplicativos. Mas você não precisa comprar uma ferramenta de monitoramento cara para aproveitar o WMI; você tem o PowerShell!
Vamos começar com os dois elementos básicos, e conforme avançamos, você aprenderá os outros elementos necessários:
- Classes: As classes são os eventos e propriedades que a aplicação, como o PowerShell, pode chamar para ler e atualizar dados. As classes estão localizadas dentro de um namespace.
- Namespace: O namespace é um contêiner para classes relacionadas ao WMI. Pense nele como uma pasta Minhas Imagens que contém conteúdo relacionado a imagens. Existem vários namespaces, e o mais comum é CIMv2 que contém a maioria das classes do sistema operacional. Mas todos os namespaces estão localizados sob o grande namespace único Root.
WMI vs. CIM
WMI e CIM são ambos métodos para interagir com o repositório em um sistema Windows contendo toneladas de informações e para trabalhar com eventos WMI (mais sobre isso depois). No entanto, ambos os métodos têm algumas diferenças, principalmente na forma como os administradores interagem com eles remotamente.
WMI começou com o Windows NT4 e foi a maneira original (e única) de interagir com o repositório. Ao gerenciar um sistema Windows com WMI, o Windows utiliza Modelo de Objeto de Componente Distribuído (DCOM). DCOM é um protocolo remoto que o WMI usa para expor informações dentro do repositório de dados em um computador com Windows.
Para funcionar em uma rede, DCOM utiliza Chamada de Procedimento Remoto (RPC). Para se comunicar por meio de uma rede, RPC utiliza faixas dinâmicas de portas, o que às vezes representa um desafio para firewalls e dispositivos de Tradução de Endereços de Rede (NAT).
Se você está enfrentando problemas com RPC, confira o artigo Testando Conexões RPC com Portas Dinâmicas.
A Microsoft decidiu aproveitar o CIM para fornecer uma abordagem mais moderna para interagir com o repositório de dados no Windows. Em vez de RPC, o CIM utiliza o WS-MAN (Web-Service for Management), um protocolo HTTP muito mais adequado para o gerenciamento remoto.
Ao longo deste artigo e de outros, WMI e CIM podem ser usados de forma intercambiável. O repositório de dados com o qual ambos os métodos de gerenciamento interagem é geralmente chamado de repositório WMI. Quase todos os termos referem-se ao WMI, enquanto o CIM é geralmente mencionado em cmdlets do PowerShell.
WMI vs. CIM e PowerShell
Felizmente, você tem algumas opções quando se trata de WMI e CIM com o PowerShell. O PowerShell suporta ambas as maneiras de interagir com o repositório de dados. Quando você executa o comando Get-Command no PowerShell, pode notar vários cmdlets Wmi, como Get-WmiObject, Invoke-WmiMethod, Remove-WmiObject, Register-WmiEvent e Set-WmiInstance.
Se você estiver usando o Windows PowerShell 3 ou superior (o que é recomendado!), também verá alguns cmdlets com nomes semelhantes, como Get-CimInstance, Get-CimClass e Remove-CimInstance.
Quais cmdlets do PowerShell você deve usar? A resposta é simples: os cmdlets do CIM. O CIM é o novo padrão no qual a Microsoft está focando. Os cmdlets do WMI nem estão disponíveis no PowerShell Core!
Consultando o WMI: Os Conceitos Básicos
Antes de você poder trabalhar com eventos do WMI, é necessário entender como consultar o WMI com o PowerShell. Consultar informações no repositório do WMI é o uso mais comum dos dados do WMI.
Para consultar dados do WMI no mundo do PowerShell, o Get-CimInstance é seu aliado. Este cmdlet possui algumas maneiras diferentes de consultar dados do WMI. Mas, este tutorial vai focar no parâmetro Query. O parâmetro Query permite que você forneça uma consulta Windows Query Language (WQL) para consultar o WMI.
Por exemplo, talvez você queira encontrar todas as instâncias do WMI na classe Win32_Service. Similar ao SQL, você usaria a consulta Select * from Win32_Service, como mostrado abaixo. O asterisco (*) diz ao WMI para retornar todas as propriedades de cada instância encontrada.
No exemplo acima, você encontrou todas as instâncias de cada serviço na classe Win32_Service, mas e se você só quiser encontrar algumas? Nesse caso, você usaria a WHERE cláusula. A cláusula WHERE cria um filtro para retornar apenas instâncias que correspondam a uma condição específica.
A cláusula WHERE indica ao Get-CimInstance que retorne apenas instâncias em que a propriedade da instância corresponda a um valor específico. Por exemplo, talvez você queira encontrar apenas as instâncias de serviço em que a propriedade State seja Running. Se for o caso, você definiria a cláusula WHERE como Where State='Running', conforme mostrado abaixo.
Você pode ver abaixo que o Get-CimInstance retornou apenas as instâncias de serviço em que a propriedade State era igual a Running.
Eventos WMI: As Ações do WMI
O WMI contém um grande repositório de informações sobre milhares de itens no Windows. Você pode acessar essas informações consultando como fez anteriormente, mas também possui um recurso menos conhecido; eventos WMI.
No Windows, a qualquer momento, centenas de eventos podem estar ocorrendo. Quando você usa várias funcionalidades do Windows, como criar arquivos, parar e iniciar serviços, instalar software ou qualquer outra coisa, um evento WMI é provavelmente acionado.
Praticamente toda ação realizada no Windows pode ser exposta por meio de um evento WMI. Quando uma ação é executada no Windows, o Windows aciona um evento por meio de sua infraestrutura interna. Por padrão, você não consegue ver esses eventos; eles ocorrem em segundo plano. Para visualizar esses eventos, você deve subscrever a eles.
Construindo um Script de Monitoramento de Serviço com PowerShell
Para demonstrar como os eventos WMI funcionam, em vez de entediar você com toneladas de informações, vamos construir uma ferramenta útil. Como os eventos WMI ocorrem quando um evento acontece no Windows, você pode criar ferramentas de monitoramento úteis usando-os.
Talvez você queira escrever uma mensagem em um arquivo de log quando o status de um serviço do Windows muda em um servidor crítico. Então, você pode se inscrever nos eventos WMI que essas ações acionam quando ocorrem. Quando você se inscreve no evento e o evento é acionado, você pode executar alguma ação como fazer log em um arquivo, enviar um e-mail ou qualquer outra coisa que você possa fazer com o PowerShell.
Em vez de comprar uma solução de monitoramento cara, um simples script do PowerShell pode ser uma ótima ferramenta de monitoramento para o homem pobre! Se estiver pronto, abra seu console do PowerShell e vamos começar!
Encontrando a Classe CIM
Dentro do WMI, como instâncias estáticas, os eventos estão contidos em classes. Essas classes contêm todos os dados estáticos que você consultou acima e onde as alterações nessas instâncias são acionadas. Você pode encontrar uma lista de todas as classes CIM na documentação da Microsoft.
Para encontrar todas as classes CIM, execute o Get-CimClass cmdlet sem parâmetros. O cmdlet Get-CimClass, por padrão, retorna todas as classes no namespace ROOT/cimv2. O namespace ROOT/cimv2 é o namespace “principal” onde quase todas as classes interessantes do Windows são armazenadas.
No entanto, como você pode ver abaixo, muitas classes são retornadas.
Pode ser que você tenha feito algumas pesquisas e finalmente percebeu que os serviços do Windows são todos armazenados no Win32_Service. Portanto, quando você souber o nome da classe, use o parâmetro ClassName para especificar o nome, como mostrado abaixo.
Encontrando as Propriedades da Classe CIM
Depois de saber em qual classe procurar, você deve descobrir qual propriedade olhar. Quando o valor de uma propriedade de instância muda (ou uma instância inteira é criada ou removida), um evento é disparado. Você deve capturar essa mudança de estado. Para fazer isso, você deve saber qual propriedade deseja monitorar.
Para encontrar essa propriedade, inspecione a propriedade do objeto CimClassProperties no objeto de classe CIM que você consultou na seção anterior.
Observe abaixo que uma dessas propriedades é a propriedade State.
Agora que você sabe qual classe CIM e propriedade deseja monitorar, é hora de se inscrever no evento WMI!
Criando uma Assinatura de Evento WMI: Visão Geral de Alto Nível
Criar uma assinatura de evento WMI pode ser uma tarefa confusa se você nunca criou uma antes. Para ajudá-lo a manter a ação reta, vamos primeiro cobrir a floresta antes das árvores e esboçar os passos básicos.
Criar uma assinatura de evento WMI requer quatro etapas aproximadas:
- Construindo a consulta WQL – Assim como ao consultar dados estáticos, você deve criar uma consulta WQL que corresponda ao tipo de evento WMI que deseja ver. Mas, ao contrário da consulta ao armazenamento de dados, você deve empregar alguns componentes mais complicados na consulta, como classes do sistema e verificação de ciclos (mais sobre isso depois).
- Criando o filtro de eventos – Depois de criar a consulta WQL, você deve criar o filtro de eventos. O filtro de eventos registra a consulta WQL no CIM.
- Criando o consumidor – O consumidor define a ação a ser tomada quando a consulta do filtro de eventos retorna uma alteração na classe. Por exemplo, sempre que o status de um serviço é iniciado, parado, criado ou removido, o consumidor aciona uma ação.
- Vinculando o filtro de eventos ao consumidor – A cola que conecta a consulta WMI do Windows ao consumidor. A vinculação é o que notifica o consumidor quando o filtro de eventos recebe uma correspondência.
Ao juntar cada um desses itens, você cria uma assinatura.
Construindo a Consulta WQL
A WQL query for a WMI event looks a bit different than performing a simple query with Get-CimInstance. Below you’ll find a typical WMI event query.
Como a consulta WQL pode parecer assustadora no início, vamos dividi-la e entender como cada componente funciona.
A Classe do Sistema
No exemplo de Get-CimInstance, você descobriu que gostaria de ser notificado quando uma alteração em uma instância na classe Win32_Service fosse feita. Você ainda precisa desta classe, mas em vez de uma consulta WQL que se parece com isso:
Em vez disso, a consulta começará como abaixo. A principal classe que você está consultando não é a classe que contém a instância sobre a qual você gostaria de ser notificado. Em vez disso, a classe é uma classe de sistema.
As classes de sistema são uma classe interna que representa o tipo de mudança que o evento acarreta. Um evento WMI tem quatro tipos de classes de sistema:
- InstanceModificationEvent – Verifica quaisquer alterações no valor das propriedades em uma instância de uma classe. Esta classe é a que você usará porque gostaria de monitorar uma propriedade de valor
Statusem uma instância (serviço) da classeWin32_Service. - InstanceCreationEvent – Verifica quaisquer novas instâncias. Se, por exemplo, você gostaria de monitorar por quaisquer novos serviços criados, usaria esta classe de sistema.
- InstanceDeletionEvent – Verifica quaisquer instâncias removidas. Se, por exemplo, você gostaria de monitorar serviços removidos, usaria esta classe de sistema.
- InstanceOperationEvent – Esta classe de sistema verifica todos os tipos de eventos, modificação, criação e exclusão.
Para o nosso script de monitoramento, o início da consulta WQL parecerá o seguinte:
Nomes de classes do sistema WMI sempre começam com dois sublinhados (__) seguidos pelo nome da classe.
O Ciclo de Verificação
Em seguida, temos o ciclo de verificação. O ciclo de verificação inclui a palavra-chave within e um valor representando um intervalo de pesquisa em segundos.
Os eventos WMI não são em tempo real, então você deve definir um intervalo para sua assinatura verificar as alterações. Se, por exemplo, você definir o ciclo de verificação para 10, a assinatura verificará por uma alteração desde o último ciclo de pesquisa a cada 10 segundos. Se uma alteração for encontrada, ela aciona o consumidor.
Se uma instância for alterada, criada ou removida dentro do intervalo de pesquisa da classe do sistema, a alteração não será detectada! Considere a frequência necessária, mas certifique-se de que seja amigável para a CPU e a memória!
Para o exemplo de monitoramento de serviço do tutorial, vamos definir o ciclo de verificação para 10, para pesquisar o WMI a cada 10 segundos em busca de uma alteração em um serviço do Windows. A consulta WQL está crescendo!
O Filtro
Finalmente, para completar a consulta WQL, você deve definir um filtro para limitar as instâncias retornadas pela classe do sistema. Você deve definir esse filtro no formulário abaixo. Neste caso, a classe CIM que você deseja monitorar é chamada de TargetInstance.
ISAé um operador que aplica uma consulta às subclasses de uma classe especificada.
Dado que o tutorial está construindo uma assinatura para monitorar serviços do Windows, você criaria o filtro da seguinte forma:
Como está, o filtro procura por todas as instâncias de Win32_Service. Se você deseja monitorar apenas uma propriedade específica, talvez um serviço específico, você usaria o operador AND.
Os operadores AND ou OR adicionam outras condições para obter resultados mais precisos.
O filtro do tutorial (e toda a consulta) está agora completo, como o trecho de código abaixo.
Criando o Filtro de Eventos
Agora que você tem o filtro de consulta, o restante do processo é muito mais fácil de entender! Agora você precisa criar o filtro de eventos para usar essa consulta. Um filtro de eventos é na verdade outra instância CIM que faz parte da classe __EventFilter dentro do espaço de nomes Root/subscription.
Abaixo você pode ver um trecho de código com tudo o que você precisa. O script abaixo atribui a consulta WQL à variável $FilterQuery. Em seguida, ele cria um hashtable contendo cada uma das propriedades necessárias e os valores que o filtro de eventos precisa. Em seguida, executa o New-CimInstance cmdlet para criar o filtro de evento finalmente.
O objeto CIM resultante é então armazenado em uma variável ($CIMFilterInstance) para uso posterior.
Agora, execute Get-CimInstance para verificar se a nova instância CIM de __EventFilter foi criada.
Criando o Consumidor
Em seguida, é hora de criar o consumidor ou a ação que acontecerá quando o Windows acionar o evento WMI. Ao criar o consumidor, você tem algumas opções, dependendo do tipo de ação que gostaria de acionar.
- ActiveScriptEventConsumer – Executa um script em uma linguagem de script arbitrária, como VBscript.
- CommandLineEventConsumer – Inicia um processo
Certifique-se de que o ACL do executável esteja definido corretamente para evitar que alguém substitua o EXE por um binário malicioso.
- LogFileEventConsumer – Cria um registro de texto.
- NTEventLogEventConsumer – Escreve um evento no log de eventos do Windows.
- SMTPEventConsumer – Envia um e-mail.
Para este tutorial, vamos usar o tipo de consumidor LogFileEventConsumer para escrever em um arquivo de log quando o serviço correspondido na consulta WQL for alterado.
Cada classe de consumidor possui seus próprios parâmetros, então verifique o
CimClassPropertiespara obter mais detalhes sobre cada classe, por exemplo,(Get-CimClass -ClassName __NTEventLogEventConsumer).CimClassProperties.
Depois de criar o consumidor, novamente, verifique sua existência com Get-CimInstance.
Vinculando o Filtro de Eventos e o Consumidor
Finalmente, é hora de concluir esta assinatura e vincular o filtro de eventos e o consumidor juntos! Como você pode ter imaginado, criar a vinculação significa criar mais uma instância CIM. Desta vez, você deve criar uma nova instância na classe __FilterToConsumerBinding.
O trecho de código abaixo está usando as duas instâncias criadas anteriormente (o filtro e o consumidor) como uma tabela hash que define as propriedades necessárias para criar uma nova instância. Em seguida, é passado para New-CimInstance, como antes, para criar a vinculação.
Como sempre, confirme se a vinculação foi criada executando Get-CimInstance novamente.
Como você pode ver, a vinculação possui informações tanto sobre o Filtro quanto sobre o Consumidor.
Testando a Assinatura
Você finalmente terminou! É hora de testar os frutos do seu trabalho! A única coisa que você precisa fazer agora é alterar o status do serviço BITS para ver se o PowerShell escreve uma entrada no arquivo de log em C:\MyCIMMonitoring.txt.
Dependendo do status do serviço BITS, pare, inicie ou apenas reinicie com o cmdlet Restart-Service.
Aguarde cerca de 10 segundos e verifique o C:\MyCIMMonitoring.txt. Agora você deve ver o Texto no arquivo de log que você definiu ao criar o consumidor.
Para monitorar toda a atividade de eventos WMI, confira o log de eventos do Windows no caminho Aplicações e Serviços\Log\Microsoft\Windows\WMI-Activity\Operacional.
Parando e Limpando a Assinatura
Depois de terminar com a assinatura, é hora de limpá-la. Para parar e remover a assinatura de eventos WMI, você deve remover o filtro de evento, consumidor e instâncias de ligação.
Remova o filtro de evento encontrando primeiro a instância com Get-CimInstance.
Em seguida, remova o consumidor da mesma maneira.
Finalmente, remova a ligação. A propriedade para encontrar a ligação é um pouco diferente. Em vez da propriedade Nome, a instância de ligação tem uma propriedade Filtro que é na verdade um objeto com uma propriedade Nome.
Conclusão
WMI/CIM é um sistema útil e poderoso para encontrar informações sobre o Windows e monitorá-lo com eventos WMI. Monitorar alterações com eventos WMI oferece uma ótima visibilidade e uma reação mais rápida a possíveis problemas, facilitando a automação de uma resposta para cada evento.
Para um ótimo exemplo do mundo real, confira Como Rastrear Alterações no Active Directory com Eventos WMI.
Source:
https://adamtheautomator.com/your-goto-guide-for-working-with-windows-wmi-events-and-powershell/