[receiver/windowseventlogreceiver] Support Remote Event Log Collection via MSRPC

[JonathanWamsley]

Component(s)

receiver/windowseventlog

Is your feature request related to a problem? Please describe.

I'm proposing to enhance the existing windowseventlogreceiver to support remote collection of Windows event logs using the Windows Event Log API (EvtOpenSession and related functions). This feature will allow the OpenTelemetry Collector to gather event logs from remote Windows machines without needing to be installed on the host machine. This capability is especially useful in environments where direct installation on the host is not feasible.

Describe the solution you'd like

I propose leveraging the Windows Event Log API to enable remote event log collection. This enhancement will include:

• Adding configuration options for specifying remote server details, including IP address, port, and authentication credentials.
• Ensuring that the collected event logs retain the same structure and formats as the current local collection, including fields like Provider, EventID, Version, Level, Task, Opcode, Keywords, TimeCreated, EventRecordID, Correlation, Execution, Channel, Computer, and Security.
• Providing comprehensive documentation and examples to facilitate user adoption of the new feature.

An example config:

receivers:
  windowseventlog:
    channels: 
      - Application
      - System
      - Security
    # New fields for remote collection
    remote:
      server: "SERVER"       # IP address or hostname of the remote server
      port: 135              # Default port for MSRPC
      username: "USERNAME"   # Username for authentication
      password: "PASSWORD"   # Password for authentication

Describe alternatives you've considered

Initially, the idea was to create a new msrpceventlogsreceiver. However, after looking at the inputs and output and how the user would interact, I believe adding an enhancement to the existing windowseventlogreceiver can be achieved.

Additional context

• Dependency Concern: The initial proposal to use the go-msrpc library raised valid concerns about security and the lack of history/activity of the repository. Given these concerns, I have tested and validated the use of the Windows Event Log API for remote collection, which is a more established and secure approach.

• Using EvtOpenSession and EVT_RPC_LOGIN: By utilizing these functions, we can securely establish remote sessions to Windows machines and collect event logs without introducing new dependencies. This approach aligns with the standard practices for remote operations in Windows environments.

• Configuration Considerations: The proposed configuration allows specifying multiple remote servers with their respective credentials. This approach is user-friendly and flexible, enabling easy addition or removal of target servers.

[github-actions[bot]]

Pinging code owners:

• receiver/windowseventlog: @djaglowski @armstrmi @pjanotti

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[djaglowski]

I like that the config would only change by the addition of an optional section that implicitly indicates whether remote collection is intended, and that the outputs would be the same.

My biggest concern is with the dependency. Neither the repo or author have any public history. The repo implements a protocol which would allow the collector to make remote procedure calls to external systems. The complexity of the protocol (or at least the implementation) appear very high. All of this makes me question whether we can establish confidence that it does not introduce a security vulnerability. That said, I don't know anything about the protocol it implements so maybe someone else with a more informed opinion would be able to confidently evaluate the risk. (cc @pjanotti in case you want to look into this)

[BinaryFissionGames]

I'm curious whether it'd be easier or not to just use EvtOpenSession and just pass the returned handle into the relevant functions (e.g. as the first param in evtSubscribe).

Are there advantages to using the library over using the existing logic with a session handle from EvtOpenSession?

[pjanotti]

(was about to hit enter @BinaryFissionGames :) saying the same)

The Event API already handles remote operations, see EvtOpenSession and EVT_RPC_LOGIN. So no need to add a new dependency.

The first question that pops on my mind is how much is this user friendly without some kind of automatic way to discover the remote servers. Is it reasonable to to start with a list that requires knowing all targeted servers before hand?

We should also think about the configuration carefully: a single set of credentials for a list of servers seems reasonable, and then multiple of such groups.

[crobert-1]

Removing needs triage as code owners have responded and have a general path forward here.

[JonathanWamsley]

Hey @pjanotti sorry for the delay, I have updated the issue based on feedback. I think starting with a list of targeted servers will work. The way I have it implemented allows for a single set of credentials for a list of servers and or multiple servers with multiple credentials in groups too. I used the EvtOpenSession and EVT_RPC_LOGIN as @BinaryFissionGames and you suggested and got it working 😁.

[JonathanWamsley]

resolved with #33601

[pjanotti]

Thanks @JonathanWamsley!