Você sabia que é possível monitorar praticamente todas as ações no Windows? Não, você não precisa comprar algum software sofisticado. A infraestrutura monitora eventos como o início e a parada de serviços, quando alguém cria um arquivo ou pasta, e muito mais, tudo já está lá por meio 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 adquirir as habilidades para construir algumas ferramentas úteis!
Vamos lá!
Pré-requisitos
Você verá muitas demonstrações neste tutorial prático. Se você quiser acompanhar alguma 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 locais.
- Windows PowerShell 5.1 ou PowerShell 6+ – Este tutorial usará o PowerShell v7.1.2.
Compreensão do WMI e CIM
Antes de começar com os eventos do WMI, é importante entender a infraestrutura sobre a qual eles são construídos. Embora este tutorial não aprofunde no WMI, você sempre pode consultar a documentação do WMI da Microsoft para aprender mais.
WMI e seu modelo de dados relacionado Common Information Model (CIM) são modelos incorporados no Windows que armazenam praticamente qualquer informação relacionada ao funcionamento interno do Windows e do que está sendo executado nele em um repositório.
WMI e CIM são ferramentas poderosas que os administradores utilizam para gerenciar o Windows tanto localmente quanto remotamente. Usando WMI ou CIM, os administradores podem consultar informações em um sistema Windows, como aplicativos instalados, status dos serviços, arquivos no sistema de arquivos e praticamente tudo mais.
WMI e CIM são a forma como muitas soluções de monitoramento empresarial coletam informações sobre a saúde do sistema operacional e dos 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 à medida que 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 é o CIMv2, que contém a maioria das classes do sistema operacional. No entanto, todos os namespaces estão localizados no grande namespace único chamado 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). Mas, 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. Quando você gerencia um sistema Windows com WMI, o Windows usa 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 uma máquina Windows.
Para trabalhar em uma rede, DCOM usa Chamada de Procedimento Remoto (RPC). Para se comunicar em uma rede, RPC usa faixas de portas dinâmicas, o que às vezes é um desafio para firewalls e dispositivos de Tradução de Endereços de Rede (NAT).
Se você estiver tendo problemas com RPC, confira o artigo Testar Conexões RPC com as Portas Dinâmicas.
A Microsoft decidiu aproveitar o CIM para oferecer 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 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 formas de interação 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á cmdlets com nomes semelhantes, como Get-CimInstance, Get-CimClass, e Remove-CimInstance.
Qual cmdlet 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 poder lidar com eventos do WMI, você deve entender como consultar o WMI com o PowerShell. Consultar informações do repositório do WMI é o uso mais comum dos dados do WMI.
Para consultar dados do WMI no mundo do PowerShell, o Get-CimInstance cmdlet é seu amigo. Este cmdlet tem algumas maneiras diferentes de consultar dados do WMI. Mas, este tutorial vai se concentrar no parâmetro Query. O parâmetro Query permite que você forneça uma consulta da Linguagem de Consulta do Windows (WQL) para consultar o WMI.
Por exemplo, talvez você queira encontrar todas as instâncias do WMI na classe Win32_Service. Semelhante ao SQL, você usaria a consulta Select * from Win32_Service, como mostrado abaixo. O asterisco (*) indica 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 as 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 esse o caso, você definiria a cláusula WHERE como Where State='Running', conforme mostrado abaixo.
Como pode ser visto abaixo, o Get-CimInstance retorna apenas as instâncias de serviço em que a propriedade State é igual a Running.
Eventos do 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-as como fez acima, mas também possui um recurso menos conhecido; eventos do WMI.
No Windows, a qualquer momento, centenas de eventos podem estar ocorrendo. Quando você usa várias funcionalidades do Windows, como criar arquivos, interromper e iniciar serviços, instalar software ou qualquer outra coisa, um evento do WMI provavelmente é acionado.
Praticamente toda ação realizada no Windows pode ser exposta por meio de um evento do WMI. Quando uma ação é executada no Windows, o Windows dispara um evento por meio de sua infraestrutura interna. Por padrão, você não pode ver esses eventos; eles estão ocorrendo em segundo plano. Para visualizá-los, você deve subscrever a eles.
Construindo um Script de Monitoramento de Serviço com PowerShell
Para demonstrar como os eventos do WMI funcionam, em vez de entediá-lo com toneladas de informações, vamos construir uma ferramenta útil. Como os eventos do WMI ocorrem quando um evento acontece no Windows, você pode criar algumas ferramentas úteis de monitoramento usando-os.
Talvez queira escrever uma mensagem para 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 ele é acionado, você pode realizar alguma ação como fazer log em um arquivo, enviar um e-mail, ou praticamente qualquer outra coisa que você possa fazer com o PowerShell.
Em vez de comprar alguma solução de monitoramento cara, um simples script do PowerShell pode ser uma ótima ferramenta de monitoramento para o pobre homem! Se estiver pronto, abra o seu console do PowerShell e vamos começar!
Encontrando a Classe CIM
Dentro do WMI, como instâncias estáticas, eventos sã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 “principal” namespace onde quase todas as classes interessantes do Windows estão armazenadas.
Você pode ver abaixo, no entanto, que muitas classes são retornadas.
Talvez você tenha feito algumas pesquisas e finalmente percebido 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 examinar. Quando o valor de uma propriedade da 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 PowerShell CimClassProperties na instância da 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!
Construindo uma Assinatura de Evento WMI: Visão Geral de Alto Nível
Construir uma assinatura de evento WMI pode ser uma tarefa confusa se você nunca criou uma antes. Para ajudá-lo a manter a ação direta, 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:
- Elaborando 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 datastore, você deve empregar alguns componentes mais complicados na consulta, como classes do sistema e verificar 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 um status de serviço é iniciado, interrompido, criado ou removido, o consumidor dispara uma ação.
- Vinculando o filtro de eventos ao consumidor – A cola que conecta a consulta WMI do Windows ao consumidor. O vínculo é o que notifica o consumidor quando o filtro de eventos recebe uma correspondência.
Ao juntar cada um desses itens, você cria uma assinatura.
Elaborando 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.
Já que a consulta WQL pode parecer assustadora à primeira vista, 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 dessa classe, mas em vez de uma consulta WQL que parece com isto:
Em vez disso, a consulta começará da seguinte forma. A classe principal que você está consultando não é a classe que contém a instância na qual você gostaria de ser notificado. Em vez disso, a classe é uma classe do sistema.
Classes do sistema são classes internas que representam o tipo de alteração que o evento causa. Um evento WMI possui quatro tipos de classes do sistema:
- InstanceModificationEvent – Verifica quaisquer alterações nos valores das propriedades de uma instância em uma classe. Esta é a classe que você usará porque deseja monitorar o valor da propriedade
Statusde uma instância (serviço) da classeWin32_Service. - InstanceCreationEvent – Verifica se há novas instâncias. Se, por exemplo, você deseja monitorar a criação de novos serviços, usaria essa classe do sistema.
- InstanceDeletionEvent – Verifica se há instâncias removidas. Se, por exemplo, você deseja monitorar a remoção de serviços, usaria essa classe do sistema.
- InstanceOperationEvent – Essa classe do 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 será como o seguinte:
Os nomes das classes do sistema WMI sempre começam com dois sublinhados (__) seguidos pelo nome da classe.
O Ciclo de Verificação
Em seguida, você tem o ciclo de verificação. O ciclo de verificação inclui a palavra-chave within e um valor representando um intervalo de pesquisa representado em segundos.
Os eventos do WMI não são em tempo real, então você deve definir um certo intervalo para sua assinatura verificar as alterações. Se, por exemplo, você definir o ciclo de verificação para 10, a assinatura verificará 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 dependendo da classe do sistema dentro do intervalo de pesquisa, a alteração não será detectada! Considere a frequência necessária, mas certifique-se de que seja amigável à CPU e à 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
Por fim, para completar a consulta WQL, você deve definir um filtro para limitar as instâncias retornadas da classe do sistema. Você deve definir esse filtro no formato abaixo. Neste caso, a classe CIM que você gostaria de monitorar é chamada de TargetInstance.
ISAé um operador que aplica uma consulta às subclasses de uma classe especificada.
Como o tutorial está construindo uma assinatura para monitorar serviços do Windows, você criaria o filtro como abaixo:
Como está, o filtro procura todas as instâncias de Win32_Service. Se você deseja monitorar apenas uma propriedade, 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) agora está completo como o trecho de código abaixo.
Criando o Filtro de Eventos
Agora que você tem o filtro de consulta, o resto do processo fica 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 namespace 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, cria um hashtable contendo cada uma das propriedades necessárias e os valores que o filtro de evento precisa. Em seguida, executa o New-CimInstance cmdlet para criar o filtro de evento finalmente.
O objeto de instância 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
A seguir, é hora de criar o consumidor ou a ação que ocorrerá 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
Assegure-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 registro 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, portanto, 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 completar esta assinatura e vincular o filtro de eventos e o consumidor juntos! Como você pode ter imaginado, criar o vínculo 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 um hashtable que define as propriedades necessárias para criar uma nova instância. Em seguida, é passado para New-CimInstance como antes para criar o vínculo.
Como sempre, confirme se o vínculo foi criado executando Get-CimInstance novamente.
Como você pode ver, o vínculo tem informações sobre tanto o Filtro quanto 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 simplesmente reinicie-o com o cmdlet Restart-Service.
Espera cerca de 10 segundos e verifica o C:\MyCIMMonitoring.txt. Agora deverias ver o Texto no ficheiro de registo que definiste ao criar o consumidor.
Para monitorizar toda a atividade de eventos WMI, verifica o registo de eventos do Windows no caminho Applications and Services Log\Microsoft\Windows\WMI-Activity\Operational.
Parar e Limpar a Subscrição
Quando terminares com a subscrição, é hora de a limpar. Para parar e remover a subscrição de eventos WMI, deves remover o filtro de eventos, o consumidor e as instâncias de ligação.
Remove o filtro de eventos encontrando primeiro a instância com Get-CimInstance.
Em seguida, remove o consumidor da mesma forma.
Finalmente, remove a ligação. A propriedade para encontrar a ligação é um pouco diferente. Em vez da propriedade Name, a instância de ligação tem uma propriedade Filter que é na verdade um objeto com uma propriedade Name.
Conclusão
WMI/CIM é um sistema útil e poderoso para encontrar informações sobre o Windows e monitorizá-lo com eventos WMI. Monitorizar alterações com eventos WMI dá-te uma grande 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/