109.36. Windows Event Collector (im_wseventing)
This module can be used to collect Windows EventLog from Microsoft Windows clients that have Windows Event Forwarding (WEF) configured. This module takes the role of the collector (Subscription Manager) to accept eventlog records from Windows clients over the WS-Management protocol. WS-Eventing is a subset of WS-Management used to forward Windows EventLog.
The im_mseventlog module requires NXLog to be installed as an agent on the source host. The im_msvistalog module can be configured to pull Windows EventLog remotely from Windows hosts with a NXLog agent running on Windows. The im_wseventing module, however, like im_wmi, can be used on all supported platforms including GNU/Linux systems to remotely collect Windows EventLog without requiring any software to be installed on the source host. Windows clients can be configured through Group Policy to forward EventLog to the system running the im_wseventing module, without the need to list each client machine individually in the configuration.
The WS-Eventing protocol and im_wseventing support HTTPS using X509 certificates and Kerberos to authenticate and securely transfer EventLog.
Note
|
While there are other products implementing the WS-Eventing protocol (such as IBM WebSphere DataPower), this module was implemented with the primary purpose of collecting and parsing forwarded events from Microsoft Windows. Compatibility with other products has not been assessed. |
109.36.1. Kerberos Setup
Follows these steps to set up Windows Event Forwarding with Kerberos.
The steps and examples below assume these systems:
-
Windows domain controller
ad.domain.com
at 192.168.0.2 -
RHEL Linux node
linux.domain.com
at 192.168.0.3
-
Join the Linux node to the domain.
-
Set the hostname:
# hostnamectl set-hostname linux
-
Set the nameserver and static IP address (substitute the correct interface name).
# nano /etc/sysconfig/network-scripts/ifcfg-enp0s3
Set to:
BOOTPROTO=static IPADDR=192.168.0.3 NETMASK=255.255.255.0 GATEWAY=192.168.0.1 DNS1=192.168.0.2
-
-
Synchronize the time on
linux.domain.com
withad.domain.com
. For example:# ntpdate ad.domain.com
-
Go to the domain controller
ad.domain.com
and create a new userlinux
(the name of the user should match the hostname of the Linux node).-
Go to Administrative Tools → Active Directory Users and Computers → ad.domain.com → Users.
-
Right click and choose New → User.
-
First name:
linux
-
Full name:
linux
-
User logon name:
linux
-
Set a password on the next page.
-
Uncheck User must change password at next logon.
-
Check Password never expires.
-
-
Right click on the new user, click Properties, and open the Account tab.
-
Check This account supports Kerberos AES 128 bit encryption.
-
Check This account supports Kerberos AES 256 bit encryption.
-
-
-
In the DNS settings on the domain controller, create an A record for
linux.domain.com
.-
Go to Administrative Tools → DNS → Forward Lookup Zones → ad.domain.com.
-
Right click and choose New Host (A or AAAA)….
-
Add a record with name
linux
and IP address192.168.0.3
.
-
-
Open a Command Prompt on
ad.domain.com
and execute these commands. Use the same<password>
as in step 3b.> ktpass /princ hosts/linux.domain.com@DOMAIN.COM /pass <password> /mapuser DOMAIN\linux -pType KRB5_NT_PRINCIPAL /out hosts-nxlog.keytab /crypto AES256-SHA1 > ktpass /princ http/linux.domain.com@DOMAIN.COM /pass <password> /mapuser DOMAIN\linux -pType KRB5_NT_PRINCIPAL /out nxlog.keytab /crypto AES256-SHA1
-
Copy the resulting
hosts-nxlog.keytab
andnxlog.keytab
files tolinux.domain.com
. -
Update the Group Policy on the domain controller.
-
Run
gpedit.msc
and go to Computer Configuration → Administrative Templates → Windows Components → Event Forwarding. -
Open and enable the Configure target Subscription Manager setting.
-
Click Show… beside the SubscriptionManagers option.
-
Type into the Value field:
Server=http://linux.domain.com:80,Refresh=30
. -
In the Command Prompt, run
gpupdate /force
.
-
-
Set up Kerberos on
linux.domain.com
.-
Confirm that the Kerberos krb5 client and utility software are installed on the system. The required package can be installed with (for example)
yum install krb5-workstation
orapt install krb5-user
. -
Edit the default configuration file at
/etc/krb5.conf
.-
In section
[domain_realm]
, add:.domain.com = DOMAIN.COM domain.com = DOMAIN.COM
-
In section
[realms]
, add:DOMAIN.COM = { kdc = domain.com admin_server = domain.com }
-
-
Use
ktutil
to merge the two keytab files generated in step 5.# ktutil ktutil: rkt /root/hosts-nxlog.keytab ktutil: rkt /root/nxlog.keytab ktutil: wkt /root/nxlog-result.keytab ktutil: q
-
Validate the merged keytab.
# klist -e -k -t /root/nxlog-result.keytab Keytab name: FILE:/root/nxlog-result.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 5 17.02.2016 04:16:37 hosts/linux.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96) 4 17.02.2016 04:16:37 http/linux.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)
-
Either copy the keytab into place, or merge if there are already keys in
/etc/krb5.keytab
.-
To simply copy the keytab:
cp /root/nxlog-result.keytab /etc/krb5.keytab
-
To merge the keytab and validate the result:
# ktutil ktutil: rkt /etc/krb5.keytab ktutil: rkt /root/nxlog-result.keytab ktutil: wkt /etc/krb5.keytab ktutil: q # klist -e -k -t /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 5 31.12.1969 15:00:00 HTTP/linux.domain.com@PEROKSID.COM (aes256-cts-hmac-sha1-96) 5 17.02.2016 04:20:08 HTTP/linux.domain.com@PEROKSID.COM (aes256-cts-hmac-sha1-96) 5 17.02.2016 04:20:08 hosts/linux.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96) 4 17.02.2016 04:20:08 http/linux.domain.com@DOMAIN.COM (aes256-cts-hmac-sha1-96)
-
-
-
Make sure the port defined in the im_wseventing configuration is accessible from the Windows clients. The local firewall rules on the Linux node may need to be updated.
-
Configure and run NXLog. See the configuration example below.
109.36.2. HTTPS Setup
To set up Windows Event Forwarding over HTTPS the following steps are required:
-
X509 certificate generation using either OpenSSL or the Windows certificate manager,
-
configuration of the NXLog im_wseventing module.
-
configuration of Windows Remote Management (WinRM) on each Windows source host,
These steps are covered in greater detail below.
Note
|
We will refer to the host running NXLog with the im_wseventing module
as server. Under Windows the Subscription Manager refers to the
same entity since im_wsevening is what manages the subscription.
We will use the name client when referring to the Windows hosts
sending the logs using WEF.
|
The client certificate must have the X509 v3 Extended Key Usage: TLS
Web Client Authentication
extension and the server certificate needs
the X509 v3 Extended Key Usage: TLS Web Server Authentication
extension.
You will likely encounter an error when trying to configure WEF and the
connection to the server will fail without these extended key usage
attributes.
Also make sure that the intended purpose of the certificates are set to Server
Authentication
and Client Authentication
respectively.
When generating the certificates please ensure that the CN in the server
certificate subject matches the reverse DNS name, otherwise you may get errors
in the Microsoft Windows/Event-ForwardingPlugin/Operational
eventlog saying
The SSL certificate contains a common name (CN) that does not match the hostname.
Generating the certificates with OpenSSL
If you prefer Windows skip to the next section.
For OpenSSL based certificate generation see the scripts in our public git repository.
Generate the CA certificate and private key:
SUBJ="/CN=NXLog-WEF-CA/O=nxlog.org/C=HU/ST=state/L=location" openssl req -x509 -nodes -newkey rsa:2048 -keyout ca-key.pem -out ca-cert.pem -batch -subj "$SUBJ" -config gencert.cnf openssl x509 -outform der -in ca-cert.pem -out ca-cert.crt
Generate the client certificate and export it together with the CA in PFX format to be imported into the Windows certificate store:
CLIENTSUBJ="/CN=winclient.domain.corp/O=nxlog.org/C=HU/ST=state/L=location" openssl req -new -newkey rsa:2048 -nodes -keyout client-key.pem -out req.pem -batch -subj "$CLIENTSUBJ" -config gencert.cnf openssl x509 -req -days 1024 -in req.pem -CA ca-cert.pem -CAkey ca-key.pem -out client-cert.pem -set_serial 01 -extensions client_cert -extfile gencert.cnf openssl pkcs12 -export -out client.pfx -inkey client-key.pem -in client-cert.pem -certfile ca-cert.pem
Generate the server certificate to be used by the im_wseventing
module:
SERVERSUBJ="/CN=nxlogserver.domain.corp/O=nxlog.org/C=HU/ST=state/L=location" openssl req -new -newkey rsa:2048 -nodes -keyout server-key.pem -out req.pem -batch -subj "$SERVERSUBJ" -config gencert.cnf openssl x509 -req -days 1024 -in req.pem -CA ca-cert.pem -CAkey ca-key.pem -out server-cert.pem -set_serial 01 -extensions server_cert -extfile gencert.cnf openssl x509 -outform der -in server-cert.pem -out server-cert.crt
In order to generate the certificates with the correct extensions the following
is needed in gencert.cnf
:
[ server_cert ] basicConstraints=CA:FALSE nsCertType = server subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth #crlDistributionPoints=URI:http://127.0.0.1/crl.pem [ client_cert ] basicConstraints=CA:FALSE nsCertType = client subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth
Note
|
If you are using an intermediary CA please make sure that the
ca-cert.pem file contains—in correct order—the public
part of every issuer’s certificate.
The easiest way to achieve this is to 'cat' the pem
certificates together.
|
If you have more complex requirements follow this guide on how to set up a CA and generate certificates with OpenSSl.
Generating the certificates with the Windows certificate manager
For more information on creating certificates under windows see this document: Request Certificates by Using the Certificate Request Wizard.
Make sure to create the certificates with the required extensions as noted
above.
Once you have issued the certificates you will need to export the server
certificate in PFX format. The PFX must contain the private
key also, the password may be omitted. The PFX file can then be converted
to the PEM format required by im_wseventing using openssl
:
openssl pkcs12 -in server.pfx -nocerts -nodes -out server-key.pem openssl pkcs12 -in server.pfx -nokeys -nodes -out server-cert.pem
You will also need to export the CA certificate (without the private key)
the same way and convert it into ca-cert.pem
.
Configure NXLog with the im_wseventing module
You will need to use server-key.pem
, server-cert.pem
and ca-cert.pem
for the HTTPSCertKeyFile
, HTTPSCertFile
and HTTPSCAFile
respectively.
Optionally you can use the QueryXML option to filter on specific channels or events.
See the configuration example below
for how your nxlog.conf
should look.
Once the configuration is complete you may start the nxlog
service.
Configuring WinRM and WEF
-
Install, configure, and enable Windows Remote Management (WinRM) on each source host.
-
Make sure the Windows Remote Management (WS-Management) service is installed, running, and set to Automatic startup type.
-
If WinRM is not already installed, see these instructions on MSDN: Installation and Configuration for Windows Remote Management.
-
Check that the proper client authentication method (Certificate) is enabled for WinRM. Issue the following command:
winrm get winrm/config/Client/Auth
This should produce the following output
Auth Basic = false Digest = true Kerberos = true Negotiate = true Certificate = true CredSSP = true [Source="GPO"]
If Certificate authentication is set to false, it should be enabled with the following:
winrm set winrm/config/client/auth @{Certificate="true"}
NoteWindows Remoting does not support event forwarding over unsecured transport (such as HTTP). Therefore it is recommended to disable the Basic authentication:
winrm set winrm/config/client/auth @{Basic="false"}
-
Import the client authentication certificate if you used OpenSSL to generate these. In the Certificate MMC snap-in for the
Local Computer
clickMore actions
-All Tasks
-Import…
. Import theclient.pfx
file. Enter the private key password (if set) and make sure theInclude all extended properties
check-box is selected.NoteAfter importing is completed, open the Certificates MMC snap-in, select Computer account and double-click on the client certificate to check if the full certificate chain is available and trusted. You may want to move the CA certificate under the Trusted Root Certification Authorities
in order to make the client certificate trusted. -
Grant the NetworkService account the proper permissions to access the client certificate using the Windows HTTP Services Certificate Configuration Tool (WinHttpCertCfg.exe) and check that the NetworkService account has access to the private key file of the client authentication certificate by running the following command:
winhttpcertcfg -l -c LOCAL_MACHINE\my -s <certificate subject name>
If NetworkService is not listed in the output, grant it permissions by running the following command:
winhttpcertcfg -g -c LOCAL_MACHINE\my -s <certificate subject name> -a NetworkService
-
In order to access the Security EventLog, the NetworkService account needs to be added to the Event Log Readers group.
-
Configure the source host security policy to enable event forwarding:
-
Run the Group Policy MMC snap-in (
gpedit.msc
) and go to . -
Right-click the SubscriptionManager setting and select Properties. Enable the SubscriptionManager setting, and click Show to add a server address.
-
Add at least one setting that specifies the NXLog collector system. The SubscriptionManager Properties window contains an Explain tab that describes the syntax for the setting. If you have used the
gencert-server.sh
script it should print the subscription manager string that has the following format:Server=HTTPS://<FQDN of im_wseventing><:port>/wsman/,Refresh=<Refresh interval in seconds>, IssuerCA=<certificate authority certificate thumbprint>
An example would be as follows:
Server=HTTPS://nxlogserver.domain.corp:5985/wsman/,Refresh=14400,IssuerCA=57F5048548A6A983C3A14DA80E0626E4A462FC04
-
To find the IssuerCA fingerprint, open MMC, add the Certificates snap-in, select the Local Computer account find the Issuing CA certificate. Copy the
Thumbprint
from theDetails
tab. Please make sure to eliminate spaces and the invisible non-breaking space that is before the first character of the thumbprint on Windows 2008. -
After the SubscriptionManager setting has been added, ensure the policy is applied by running:
gpupdate /force
-
At this point the WinRM service on the Windows client should connect to NXLog and there should be a connection attempt logged in
nxlog.log
and you should soon start seeing events arriving.
-
-
109.36.3. Forwarding Security Events
In adherence to C2-level Security, access to audit data of security-related events is limited to authorized administrators. WinRM runs as a network service and may not have access to the Security log, as such it may not forward Security events. To give it access to the Security Log:
-
Open Group Policy Editor by running
gpedit.msc
. -
Go to Computer Configuration → Policies → Administrative Templates → Windows Components → Event Log Service → Configure Log Access.
-
In the Configure Log Access policy setting, enter:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)
-
Run
gpupdate /force
to apply changes.
109.36.4. Troubleshooting
WEF if not easy to configure and there may be many things that can go wrong. To troubleshoot WEF you should check the Windows Eventlog under the following channels:
-
Applications and Services Logs/Microsoft Windows/Event-ForwardingPlugin
-
Applications and Services Logs/Microsoft Windows/Windows Remote Management
-
Applications and Services Logs/Microsoft Windows/CAPI2
The CN in the server certificate subject must match the reverse dns, otherwise
you may get errors in the Microsoft Windows/Event-ForwardingPlugin/Operational
eventlog saying The SSL certificate contains a common name (CN) that does not
match the hostname.
Also in that case the WinRM service may want to use a CRL url to download
the revocation list.
If it cannot check the CRL there will be error messages under
Applications and Services Logs/Microsoft Windows/CAPI2
such as this:
<Result value="80092013">The revocation function was unable to check
revocation because the revocation server was offline.</Result>
In our experience if the FQDN and the reverse DNS of the server is properly set up it shouldn’t fail with the CRL check.
Unfortunately the diagnostic messages in the Windows Eventlog are in some
cases rather sloppy. You may see messages such as The forwarder is having
a problem communicating with the subscription manager at address
https://nxlog:5985/wsman/. Error code is 42424242 and the Error Message is .
Note the empty error message. Other than guessing you may try looking up the
error code on the internet…
If the IssuerCA thumbprint is incorrect or it can’t locate the certificate in
the certificate store then the above error will be logged in the Windows
EventLog with Error code 2150858882
.
The Refresh
interval should be set to a higher value (e.g. Refresh=1200
),
in the GPO Subscription Manager settings otherwise the windows client will
reconnect too frequently resulting in a lot of connection/disconnection
messages in nxlog.log.
By default the module does not log connection attempts which would be otherwise
useful for troubleshooting purposes. This can be turned on with the
LogConnections configuration directive.
The windows Event Forwarding service may disconnect during the TLS handshake
with the following message logged in nxlog.log
when
LogConnections is enabled.
This is normal as long as there is another connection attempt right after the
disconnection.
2017-09-28 12:16:01 INFO connection accepted from 10.2.0.161:49381 2017-09-28 12:16:01 ERROR im_wseventing got disconnected during SSL handshake 2017-09-28 12:16:01 INFO connection accepted from 10.2.0.161:49381
See the article on Technet titled Windows Event Forwarding to a workgroup Collector Server for further instructions and troubleshooting tips.
109.36.5. Configuration
The im_wseventing module accepts the following directives in addition to the common module directives. The Address and ListenAddr directives are required.
- Address
-
This mandatory directive accepts a URL address. This address is sent to the client to notify it where the events should be sent. For example,
Address https://nxlogserver.domain.corp:5985/wsman
.
- ListenAddr
-
This mandatory directive specifies the address of the interface where the module should listen for client connections. Normally the any address
0.0.0.0
is used.
- CaptureEventXML
-
This boolean directive defines whether the module should store raw XML-formatted event data. If set to TRUE, the module stores raw XML data in the $EventXML field. By default, the value is set to FALSE, and the
$EventXML
field is not added to the event record.
- ConnectionRetry
-
This optional directive specifies the reconnection interval. The default value is
PT60.0S
(60 seconds).
- ConnectionRetryTotal
-
This optional directive specifies the maximum number of reconnection attempts. The default is 5 attempts. If the client exceeds the retry count it will consider the subscription to be stale and will not attempt to reconnect.
- Expires
-
This optional directive can be used to specify a duration after which the subscription will expire, or an absolute time when the subscription will expire. By default, the subscription will never expire.
- HeartBeats
-
Heartbeats are dummy events that do not appear in the output. These are used by the client to signal that logging is still functional if no events are generated during the specified time period. The default heartbeat value of
PT3600.000S
may be overridden with this optional directive.
- HTTPSAllowUntrusted
-
This boolean directive specifies that the remote connection should be allowed without certificate verification. If set to TRUE the remote will be able to connect with an unknown or self-signed certificate. The default value is FALSE: all HTTPS connections must present a trusted certificate.
- HTTPSCADir
-
This specifies the path to a directory containing certificate authority (CA) certificates, which will be used to check the certificate of the remote HTTPS client. The certificate filenames in this directory must be in the OpenSSL hashed format. A remote’s self-signed certificate (which is not signed by a CA) can also be trusted by including a copy of the certificate in this directory.
- HTTPSCAFile
-
This specifies the path of the certificate authority (CA) certificate, which will be used to check the certificate of the remote HTTPS client. To trust a self-signed certificate presented by the remote (which is not signed by a CA), provide that certificate instead.
- HTTPSCertFile
-
This specifies the path of the certificate file to be used for the HTTPS handshake.
- HTTPSCertKeyFile
-
This specifies the path of the certificate key file to be used for the HTTPS handshake.
- HTTPSCRLDir
-
This specifies the path to a directory containing certificate revocation lists (CRLs), which will be consulted when checking the certificate of the remote HTTPS client. The certificate filenames in this directory must be in the OpenSSL hashed format.
- HTTPSCRLFile
-
This specifies the path of the certificate revocation list (CRL) which will be consulted when checking the certificate of the remote HTTPS client.
- HTTPSKeyPass
-
With this directive, a password can be supplied for the certificate key file defined in HTTPSCertKeyFile. This directive is not needed for passwordless private keys.
- HTTPSSSLCipher
-
This optional directive can be used to set the permitted SSL cipher list, overriding the default. Use the format described in the ciphers(1ssl) man page.
- HTTPSSSLProtocol
-
This directive can be used to set the allowed SSL/TLS protocol(s). It takes a comma-separated list of values which can be any of the following:
SSLv2
,SSLv3
,TLSv1
,TLSv1.1
, andTLSv1.2
. By default, the TLSv1, TLSv1.2, and TLSv1.2 protocols are allowed. Note that the OpenSSL library shipped by Linux distributions may not support SSLv2 and SSLv3, in which case these will not work even if enabled with HTTPSSSSLProtocol.
- LogConnections
-
This boolean directive can be used to turn on logging of connections. Since WEF connections can be quite frequent and excessive it could generate a lot of noise. On the other hand it can be useful to troubleshoot clients. This is disabled by default.
- MaxElements
-
This optional directive specifies the maximum number of event records to be batched by the client. If this is not specified the default value is decided by the client.
- MaxEnvelopeSize
-
This optional directive can be used to set a limit on the size of the allowed responses, in bytes. The default size is 153600 bytes. Event records exceeding this size will be dropped by the client and replaced by a drop notification.
- MaxTime
-
This optional directive specifies the maximum amount of time allowed to elapse for the client to batch events. The default value is
PT30.000S
(30 seconds).
- Port
-
This specifies the port on which the module will listen for incoming connections. The default is port 5985.
- HTTPSSSLCompression
-
This boolean directive allows you to enable data compression when sending data over the network. The compression mechanism is based on the zlib compression library. If the directive is not specified, it defaults to FALSE (the compression is disabled).
NoteSome Linux packages (for example, Debian) use the OpenSSL library provided by the OS and may not support the zlib compression mechanism. The module will emit a warning on startup if the compression support is missing. The generic deb/rpm packages are bundled with a zlib-enabled libssl library.
- Query
-
This directive specifies the query for pulling only specific EventLog sources. See the MSDN documentation about Event Selection. Note that this directive requires a single-line parameter, so multi-line query XML should be specified using line continuation:
1 2 3 4 5
Query <QueryList> \ <Query Id='1'> \ <Select Path='Security'>*[System/Level=4]</Select> \ </Query> \ </QueryList>
- QueryXML
-
This directive is the same as the Query directive above, except it can be used as a block. Multi-line XML queries can be used without line continuation, and the XML Query can be directly copied from Event Viewer.
1 2 3 4 5 6 7
<QueryXML> <QueryList> <Query Id='1'> <Select Path='Security'>*[System/Level=4]</Select> </Query> </QueryList> </QueryXML>
- SubscriptionName
-
The default value of
NXLog Subscription
may be overridden by with this optional directive. This name will appear in the client logs.
109.36.6. Fields
The following fields are used by im_wseventing.
The actual fields generated will vary depending on the particular event’s source data.
$raw_event
(type: string)-
A string containing the $EventID, $EventType, $EventTime, $Hostname, and $Message from the event.
$ActivityID
(type: string)-
A globally unique identifier for the current activity.
$Channel
(type: string)-
The Channel of the event source (for example,
Security
orApplication
).
$EventID
(type: integer)-
The event ID specific to the event source.
$EventTime
(type: datetime)-
The timestamp that indicates when the event was logged.
$EventType
(type: string)-
The type of the event, which is a string describing the severity. This is translated to its string representation. Possible values are:
CRITICAL
,ERROR
,AUDIT_FAILURE
,AUDIT_SUCCESS
,INFO
,WARNING
, andVERBOSE
.
$EventXML
(type: string)-
The raw event data in XML format. This field is available if the module’s CaptureEventXML directive is set to TRUE.
$ExecutionProcessID
(type: integer)-
The ID identifying the process that generated the event.
$ExecutionThreadID
(type: integer)-
The ID identifying the thread that generated the event.
$Hostname
(type: string)-
The name of the computer that generated the event.
$Keywords
(type: string)-
The keywords used to classify the event, as a hexadecimal number.
$Level
(type: string)-
The level of the event as a string, resolved from $LevelValue. Possible values include:
Success
,Information
,Warning
,Error
,Audit Success
, andAudit Failure
.
$LevelValue
(type: integer)-
The level of the event.
$Message
(type: string)-
The message from the event.
$MessageID
(type: string)-
The unique identifier of the message.
$Opcode
(type: string)-
The Opcode string resolved from OpcodeValue.
$OpcodeValue
(type: integer)-
The Opcode number of the event as in EvtSystemOpcode.
$param1
(type: string)-
Additional event-specific data (
$param1
,$param2
, and so on).
$ProviderGuid
(type: string)-
The globally unique identifier of the event’s provider. This corresponds to the name of the provider in the $SourceName field.
$RecordNumber
(type: integer)-
The number of the event record.
$Severity
(type: string)-
The normalized severity name of the event. See $SeverityValue.
$SeverityValue
(type: integer)-
The normalized severity number of the event, mapped as follows.
Event Log Severity Normalized Severity 0/Audit Success
2/INFO
0/Audit Failure
4/ERROR
1/Critical
5/CRITICAL
2/Error
4/ERROR
3/Warning
3/WARNING
4/Information
2/INFO
5/Verbose
1/DEBUG
$SourceName
(type: string)-
The event source which produced the event.
$Task
(type: string)-
The task defined in the event.
$UserData
(type: string)-
Event-specific data. This field is mutually exclusive with $EventData.
$UserID
(type: string)-
The Security Identifier (SID) of the account associated with the event.
$Version
(type: integer)-
The version number of the event.
109.36.7. Examples
This example collects Windows EventLog data using Kerberos.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
SuppressRepeatingLogs FALSE
<Extension json>
Module xm_json
</Extension>
<Input wseventin>
Module im_wseventing
Address http://LINUX.DOMAIN.COM:80/wsman
ListenAddr 0.0.0.0
Port 80
SubscriptionName test
Exec log_info(to_json());
<QueryXML>
<QueryList>
<Query Id="0" Path="Application">
<Select Path="Application">*</Select>
<Select Path="Security">*</Select>
<Select Path="Setup">*</Select>
<Select Path="System">*</Select>
<Select Path="ForwardedEvents">*</Select>
<Select Path="Windows PowerShell">*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
This example Input module instance collects Windows EventLog
remotely. Two EventLog queries are specified, the first for hostnames
matching foo*
and the second for other hostnames.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<Input wseventing>
Module im_wseventing
ListenAddr 0.0.0.0
Port 5985
Address https://linux.corp.domain.com:5985/wsman
HTTPSCertFile %CERTDIR%/server-cert.pem
HTTPSCertKeyFile %CERTDIR%/server-key.pem
HTTPSCAFile %CERTDIR%/ca.pem
<QueryXML>
<QueryList>
<Computer>foo*</Computer>
<Query Id="0" Path="Application">
<Select Path="Application">*</Select>
</Query>
</QueryList>
</QueryXML>
<QueryXML>
<QueryList>
<Query Id="0" Path="Application">
<Select Path="Application">*</Select>
<Select Path="Microsoft-Windows-Winsock-AFD/Operational">*</Select>
<Select Path="Microsoft-Windows-Wired-AutoConfig/Operational">*</Select>
<Select Path="Microsoft-Windows-Wordpad/Admin">*</Select>
<Select Path="Windows PowerShell">*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>