cea-sec / openwec Goto Github PK

There seem to be instances when if --content-format RenderedText is used in a subscription, windows doesn't send properly formatted XML messages. This in turn causes oenwec to return HTTP error 500 back to the source as it fails to parse the XML (as expected) :

I double checked and I very much doubt the malformed XML is an openwec problem (i'd be happy to hear otherwise), but if you turn on tracing you'll observe that the underlying hyper server reports receiving a malformed payload - which happens before openwec does much processing:

In the above screenshot note how the event is sent with a truncated RenderingInfo XML tag, though it is correct encapsulated in a SOAP event... again leading me to suspect this is a windows problem rather than openwec. This doesnt happen with all events. The same source on the same subscription will send properly formatted events - the issue seems related to those events which contain tabs/newlines/etc in their rendered info (such as most security events)

In this kind of situation, it might be beneficial to accept the event anyway but mark it as malformed, while saving the original content. Like that the source can keep on sending events (rather than stopping at an HTTP 500), and admins can troubleshoot why an event was not accepted.

I realise this is not ideal in all environments since it depends on your use case... in which case maybe the behavior can be controlled by a CLI flag?

I am using this branch to address the above (though the behavior is hardcoded rather than behind a flag as I suggested): https://github.com/CyberSift/openwec/tree/flexible_error

In this branch if the event contains a malformed event it is anyway stored, but we modified the fields stored to contain an error message and the original event content, for example, note the new Error field containing the ErrorMessage and OriginalContent fields:

{
   "System":{
      "Provider":{
         
      },
      "EventID":0,
      "Computer":""
   },
   "OpenWEC":{
      "IpAddress":"127.0.0.1",
      "TimeReceived":"2023-09-29T07:38:13.575037814+00:00",
      "Principal":"demo-client",
      "Subscription":{
         "Uuid":"91E05B32-F8F6-48CF-8AB4-4038233B83AC",
         "Version":"D5FB6FFA-F3FB-4B0D-9655-398EA6114D0F",
         "Name":"my-test-subscription"
      },
      "Errors":{
         "OriginalContent":"<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/><EventID>5061</EventID><Version>0</Version><Level>0</Level><Task>12290</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime='2023-09-29T07:25:36.3365627Z'/><EventRecordID>978308</EventRecordID><Correlation ActivityID='{f59bb999-ec5b-0008-f6b9-9bf55becd901}'/><Execution ProcessID='1440' ThreadID='16716'/><Channel>Security</Channel><Computer>xxxxxxxx</Computer><Security/></System><EventData><Data Name='SubjectUserSid'>S-1-5-20</Data><Data Name='SubjectUserName'>xxxxxxxx$</Data><Data Name='SubjectDomainName'>WORKGROUP</Data><Data Name='SubjectLogonId'>0x3e4</Data><Data Name='ProviderName'>Microsoft Software Key Storage Provider</Data><Data Name='AlgorithmName'>ECDH_P384</Data><Data Name='KeyName'>{6DF73E17-F1C9-481A-9B2F-8B16352E5D6E}</Data><Data Name='KeyType'>%%2499</Data><Data Name='Operation'>%%2480</Data><Data Name='ReturnCode'>0x0</Data></EventData><RenderingInfo Culture='en-US'><Message>Cryptographic operation.&#13;&#10;&#13;&#10;Subject:&#13;&#10;&#9;",
         "ErrorMessage":"Failed to parse event XML"
      }
   }
}

Some SIEM can only receive logs in syslog messages. To support these SIEM, we need to add a syslog output.

cf RFC 5424.

It may be useful to add 2 variant of syslog output for TCP and UDP.

On following the Getting-Started Guide, storing the given config and calling openwec db init as instructed fails with the following error:

An error occurred: Failed to retrieve configuration: TOML parse error at line 1, column 1
  |
1 | # /etc/openwec.conf.toml
  | ^
missing field `logging`

Adding the line

[logging]

to the config resolves the issue.

In some environment (without Active Directory for example), it is necessary to use TLS instead of Kerberos.

# You may define multiple collect servers.
# Each collector must listen on a different (address, port) pair.
# All collectors share the same database.
# This is useful if you want to support both Kerberos and TLS authentication

clearly states it's a possibility but doesn't make it clear how to do this. (This is exactly the scenario I'm attempting to use, with Kerberos for domain-joined so I don't need to use the shirtshow that is ADCS and cert-based (TLS) auth for non-domain-joined.)

We're currently deploying a custom docker image for OpenWEC in a Kubernetes cluster, and would like to switch to the official image.
Since we're dynamically generating secrets, such as the database credentials, supplying the entire openwec.conf.toml file as a single secret would be a bit of a pain. Our current approach is mounting the relevant secrets as environment variables, and then running envsubst on a templated config file on container start.
Being able to completely configure the service via environment variables, i.e., without the openwec.conf.toml file, would simplify our deployment quite a bit.

Windows 7 does support TLS 1.2 however the only cipher suites supported are the following (which means the TLS 1.2 handshake fails) is there any way to support additional cipher suites in rustls (or use native-tls) for openwec?

I've set up openwec using TLS and certs generated using the example scripts (thanks for the clear and comprehensive docs), however have some boxes which are autoenrolled in AD CS. I've managed to have these boxes connect to the wec and mutually auth without error, however I never see Event ID 100 (The subscription my-test-subscription is created successfully). I was wondering if any one can help me generate a compatible key and cert pair through AD CS and what settings specifically are required.