Implement Windows Logcollector Module

[cborla]

Description

This issue is a section of #201, focuses on implementing the Windows Logcollector module in the Wazuh Agent 5.0.0. The Windows collector will utilize the Event Channel (eventchannel) API to gather system logs, ensuring seamless integration and log management on Windows platforms.

Functional Requirements

• Windows Collector Implementation
  • [ ] Develop a collector that leverages the Windows Event Channel API to collect system and application logs.
• Persistent State Management
  • [ ] Store and manage the persistent state specific to Windows logs, including:
  • [ ] Reading Position: Track the last read event to resume log collection accurately after restarts.
• State Reload on Startup
  • [ ] On agent startup, reload the stored state and resume log collection from the last known position to maintain consistency.
• Log Transmission
  • [ ] Queue collected Windows logs as stateless messages in a json wrapper.

Non-functional Requirements

• Default Configuration
  • [ ] Provide a default configuration for the Windows collector within the codebase, enabling out-of-the-box functionality.
• Module Integration
  • [ ] Ensure that the Windows collector is implemented as part of the Logcollector module rather than as a standalone executable, maintaining modularity and ease of integration.

Deliverables

1. Wazuh Agent Executable with Windows Collector
   • [ ] An updated Wazuh Agent build that includes the implemented Windows collector within the Logcollector module.
2. Design Documentation for Windows Collector
   • [ ] Comprehensive documentation detailing the architecture, components, and workflow of the Windows collector.

Acceptance Criteria

• The Windows collector successfully collects system and application logs using the Event Channel API.
• Persistent state (reading position and last modification date) is correctly stored and reloaded on agent startup.
• Logs are queued as stateless messages without data loss.
• Default and customizable configurations are properly implemented and documented.
• The module integrates seamlessly into the Wazuh Agent executable without introducing regressions.

[LucioDonda]

Update 7/10/2024 and 8/10/2024

Analysis and comparisson of libraries:

1) *Windows Event Log API** (EvtQuery, EvtNext, etc.) :

• Older and more traditional C-style approach
• Part of the Windows SDK
• Provides direct access to event logs
• Can be used with C++, but may require more wrapper code for modern C++ integration
• Pros: Well-documented, stable, and widely supported
• Cons: More verbose, may require more boilerplate code in C++

2) Event Tracing for Windows (ETW):

• More modern approach to event tracing and logging
• Provides real-time and historical event collection
• Offers high-performance event tracing
• Can be used with C++ and integrates well with modern C++ features
• Pros: High performance, flexible, supports real-time monitoring
• Cons: Steeper learning curve, may be overkill for simple event log queries

3) krabsetw:

• Open-source C++ library for ETW
• Provides a modern C++ wrapper around ETW functionality
• Designed to work well with C++11 and later
• Pros: Easier to use than raw ETW, good C++ integration
• Cons: Third-party library, may have less documentation compared to official Microsoft solutions

4) Integrating PowerShell:

• Allows using PowerShell cmdlets from C++ code
• Can leverage PowerShell's Get-WinEvent cmdlet for querying event logs
• Requires setting up PowerShell hosting in C++
• Pros: Flexible, can use PowerShell's rich event querying capabilities
• Cons: Additional overhead of PowerShell runtime, may be slower for large-scale querying

First Approach

Some basic design and tentative approach on how can this be achieved, this should be double checked based on the different libraries limitations and needs:

Class Diagram:

classDiagram
    class EventChannelQuerySystem {
        - Session session
        - Provider provider
        - Consumer consumer
        -BookmarkManager bookmarkMgr
        -QueryBuilder queryBuilder
        +initialize()
        +startQuery(channelName, queryString)
        +stopQuery()
        +getResults()
        +setReconnectTime(time)
        +rotateLog()
    }
    class Session {
        -sessionName
        -sessionProperties
        +open()
        +close()
        +enableProvider(provider)
    }
    class Provider {
    }
    class Consumer {
        -eventCallback
        +processEvent(event)
        +setEventCallback(callback)
    }
    class BookmarkManager {
        -bookmarks
        +createBookmark(event)
        +getBookmark(id)
        +saveBookmarks()
        +loadBookmarks()
    }
    class QueryBuilder {
        +buildQuery(channelName, conditions)
        +addWildcardMatch(field, pattern)
    }

    EventChannelQuerySystem -- Session
    EventChannelQuerySystem -- Provider
    EventChannelQuerySystem -- Consumer
    EventChannelQuerySystem -- BookmarkManager
    EventChannelQuerySystem -- QueryBuilder

1. EventChannelQuerySystem: The main class that orchestrates the entire querying process.
2. Session: Manages the ETW session, including opening, closing, and enabling providers.
3. Provider: Represents an ETW provider, which can be enabled or disabled.
4. Consumer: Processes the events received from the ETW session.
5. BookmarkManager: Handles the creation, saving, and loading of bookmarks.
6. QueryBuilder: Constructs queries, including support for wildcard matches.

Flow chart:

1. The system starts by initializing the ETWQuerySystem.
2. It opens an ETW session and enables the required provider.
3. The ETW consumer is set up to handle incoming events.
4. Bookmarks are loaded from persistent storage.
5. A query is built using the QueryBuilder, incorporating channel name and specific query conditions.
6. The query is started, and the system enters an event processing loop.
7. For each received event:
   • The event is processed.
   • Bookmarks are updated.
   • Log rotation is performed if needed.
8. The system checks if reconnection is needed and performs it if necessary.
9. When the query is stopped, bookmarks are saved, and the session is closed.

graph TD
    A[init] --> B[Initialize - ETWQuerySystem]
    B --> C[Open - ETWSession]
    C --> D[Enable - ETWProvider]
    D --> E[Set up - ETWConsumer]
    E --> F[Load Bookmarks -> store]
    E --> W[(Store)]
    F --> G[Build N Queries]
    G --> H[run]
    H --> I{While Event Received?}
    I -->|Yes| J[Process Event]
    J --> K[Update Bookmark]
    K --> I
    I -->|No| N{Query Stopped or shutdown signal ?}
    N -->|Yes| O[Save Bookmarks]
    O --> P[Close Session]
    P --> Q[End]
    N -->|No| R{Reconnect Needed?}
    R -->|Yes| S[Reconnect]
    S --> I
    R -->|No| I

[LucioDonda]

Update 9/10/2024

• Working on a base example for getting events in real-time on windows.