For source-initiated subscriptions, which tool do you use to configure event forwarding?

Introduction

The Windows Event Collector (WEC) acts as a log collector and forwarder tool for the Microsoft Windows platform. It collects the log messages of Windows-based hosts over HTTPS (using TLS encryption and mutual authentication), and forwards them to a syslog-ng PE server. In Windows terminology, this tool allows you to define source-initiated push subscriptions, and have them forwarded to a syslog-ng PE server. For details on the limitations of WEC, see Limitations

Unlike the syslog-ng Agent for Windows, the Windows Event Collector is a standalone tool that does not require installing on the Windows-based host itself. This can be an advantage when your organization's policies restrict or do not allow the installation of third-party tools.

Another difference between the Windows Event Collector tool and syslog-ng Agent for Windows is that WEC forwards logs only about Windows events, while syslog-ng Agent forwards both Windows event logs as well as files from Windows hosts to the syslog-ng PE server.

The Windows Event Collector sits between your Windows hosts and your syslog-ng Premium Edition server, accepting log messages from the remote Windows side with WinRM and feeding them to syslog-ng Premium Edition 7.0.

Figure 1: How Windows Event Collector works in syslog-ng PE 7.0

At a high level, this is how you can get Windows event logs to be forwarded to your syslog-ng Premium Edition server using the WEC tool:

1. Configure Windows event source computers.

   For details on how to configure your Windows hosts, see Configure event source computers.

2. Set up the Windows Event Collector as the server that collects and forwards event logs.

   For details on how to set up and configure the Windows Event Collector tool, see Install the Windows Event Collector, Generate SSL certificates for Windows Event Collector, and Configure Windows Event Collector.

3. The Windows Event Collector accepts incoming event log subscription requests from the Windows hosts.

4. The Windows Event Collector handshakes the event forwarding settings with the Windows hosts, for example, which events to forward.

5. The Windows Event Collector accepts the forwarded event logs, and writes the raw logs to a Unix datagram socket.

6. syslog-ng PE reads the Unix datagram socket using a source called windowsevent().

   For details on how to configure your syslog-ng PE server, see Configure syslog-ng PE.

7. syslog-ng PE parses the logs into key-value pairs using the XML parser.

   For details on the XML parser, see "Options of XML parsers" in the Administration Guide.

Install the Windows Event Collector

• syslog-ng PE version 7.0.6 or newer

• glibc version 2.12 or newer

  glibc version 2.12 is available on all platforms supported by syslog-ng Premium Edition 7.0. However, in the case of Red Hat Enterprise Linux, an upgrade to version 6.9 or newer is required.

Purpose:

The Windows Event Collector is bundled into the syslog-ng PE installers from version 7.0.6 onward. A SysV init script and a systemd service file are provided and installed automatically, so by installing syslog-ng PE, you also install WEC. However, syslog-ng-wec is not registered to start at boot.

Steps:

1. To start syslog-ng-wec at boot, register the init script using the following commands:

   • On systemd-based systems: systemctl enable syslog-ng-wec

   • On SysV-based systems: chkconfig or update-rc.d

   For details on how to start syslog-ng-wec manually, see Start/stop Windows Event Collector.

Generate SSL certificates for Windows Event Collector

When the Windows-based host and the Windows Event Collector start communicating for the first time, they authenticate each other by exchanging and verifying each other's certificates. The process begins with the Windows host requesting and verifying the WEC tool's certificates. After successful verification, the Windows host sends its own certificates for verification to WEC.

TIP: If the Windows host fails to authenticate the WEC tool's certificates for some reason, check the Windows event logs for details. For details on which event logs to look at, see Troubleshoot Windows Event Collector.

The example described in this section uses OpenSSL for certificate generation. Note, however, that you can generate certificates using the Windows Public Key Infrastructure (PKI).

To generate the SSL certificates for WEC, complete the following steps:

Steps:

1. Create two certificate template files for both the server and the client(s).

   NOTE: The templates shown here are examples only. Not all elements of the example *opts.cnf files are mandatory, for example, you do not need to define two DNS instances.

   The contents of server-certopts.cnf:

   [req]
   default_bits = 4096
   default_md = sha256
   req_extensions = req_ext
   keyUsage = keyEncipherment,dataEncipherment
   basicConstraints = CA:FALSE
   distinguished_name = dn
   
   [ req_ext ]
   subjectAltName = @alt_names
   extendedKeyUsage = serverAuth,clientAuth
   
   [ alt_names ]
   DNS.1 = <1st DNS hostname of server (preferably FQDN)>
   ...
   DNS. = 
   IP.1 = <1st IP of server>
   ...
   IP. = 
   
   [dn]

   For example:

   [req]
   default_bits = 4096
   default_md = sha256
   req_extensions = req_ext
   keyUsage = keyEncipherment,dataEncipherment
   basicConstraints = CA:FALSE
   distinguished_name = dn
   
   [ req_ext ]
   subjectAltName = @alt_names
   extendedKeyUsage = serverAuth,clientAuth
   
   [ alt_names ]
   DNS.1 = windowseventcollector.widgits
   DNS.2 = wec.widgits
   IP.1 = 10.64.10.2
   
   [dn]

   The contents of client-certopts.cnf:

   [req]
   default_bits = 4096
   default_md = sha256
   req_extensions = req_ext
   keyUsage = keyEncipherment,dataEncipherment
   basicConstraints = CA:FALSE
   distinguished_name = dn
   
   [ req_ext ]
   subjectAltName = @alt_names
   extendedKeyUsage = serverAuth,clientAuth
   
   [ alt_names ]
   DNS.1 = <1st DNS hostname of client (preferably FQDN)>
   ...
   DNS. = 
   IP.1 = <1st IP of client>
   ...
   IP. = 
   
   [dn]

   For example:

   [req]
   default_bits = 4096
   default_md = sha256
   req_extensions = req_ext
   keyUsage = keyEncipherment,dataEncipherment
   basicConstraints = CA:FALSE
   distinguished_name = dn
   
   [ req_ext ]
   subjectAltName = @alt_names
   extendedKeyUsage = serverAuth,clientAuth
   
   [ alt_names ]
   DNS.1 = windowsclient01.widgits
   DNS.2 = client01.widgits
   IP.1 = 10.64.10.11
   
   [dn]

2. Generate the certificate authority (CA):

   $ openssl genrsa -out ca.key 4096
   
   $ openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt -subj ''

   For example:

   $ openssl genrsa -out ca.key 4096
   
   $ openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt -subj '/C=AU/ST=Victoria/L=Melbourne/O=Internet Widgits Pty Ltd/OU=Operations/CN=Operations Root CA'

   Place a copy of the ca.crt file in a directory of your choice. Take a note of the directory because you need to reference it in the cadir option of the WEC configuration file.

3. use the CA thumbprint you saved earlier

   Save the thumbprint of the CA:

   $ openssl x509 -in ca.crt -fingerprint -sha1 -noout | sed -e 's/\://g'

4. Create the server certificate:

   NOTE: The Common Name must be the FQDN (or IP address) of the Windows Event Collector server.

   $ openssl req -new -newkey rsa:4096 -nodes -out server.csr -keyout server.key -subj ''
   
   $ openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -extfile server-certopts.cnf -extensions req_ext -days 365

   For example:

   $ openssl req -new -newkey rsa:4096 -nodes -out server.csr -keyout server.key -subj '/C=AU/ST=Victoria/L=Melbourne/O=Internet Widgits Pty Ltd/OU=Operations/CN=windowseventcollector.widgits'
   
   $ openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -extfile server-certopts.cnf -extensions req_ext -days 365

5. Create client(s') certificates:

   NOTE: The Common Name must be the FQDN (or IP address) of the client.

   $ openssl req -new -newkey rsa:4096 -nodes -out client.csr -keyout client.key -subj ''
   
   $ openssl x509 -req -in client.csr -out client.crt -CA ca.crt -CAkey ca.key -CAcreateserial -extfile client-certopts.cnf -extensions req_ext -days 365

   For example:

   $ openssl req -new -newkey rsa:4096 -nodes -out client.csr -keyout client.key -subj '/C=AU/ST=Victoria/L=Melbourne/O=Internet Widgits Pty Ltd/OU=Operations/CN=windowsclient01.widgits'
   
   $ openssl x509 -req -in client.csr -out client.crt -CA ca.crt -CAkey ca.key -CAcreateserial -extfile client-certopts.cnf -extensions req_ext -days 365

6. Export the client(s') certificate(s) to the format recognized by the Windows Certificate Manager tool.

   $ openssl pkcs12 -export  -inkey client.key -in client.crt -certfile ca.crt -out client.p12

Configure event source computers

• Microsoft Windows 7 or newer

Purpose:

When collecting event logs from Windows hosts, the Windows clients sending logs act as the event source computers. The WEC tool collects and forwards messages from the standard Windows eventlog containers.

There is no restriction on the number of Windows hosts that can connect to the Windows Event Collector.

To configure your event sources, complete the following steps.

Steps:

1. Open the Microsoft Management Console (mmc.exe), select File > Add/Remove Snap-ins, and add the Certificates snap-in.

2. Select Computer Account.

3. Right-click the Personal node, and select All Tasks > Import.

4. Find and select the client certificate (client*.p12) and import this file.

5. The PKCS #12 archive contains the CA certificate as well. Move the CA certificate to the Trusted Root Certification Authorities node after the import.

   NOTE: Make sure that you only move the CA certificate and not the client certificate.

6. Give NetworkService access to the private key file of the client authentication certificate:

   NOTE: Make sure that you modify the access rights of only the private key file of the client certificate and not the CA certificate.

   1. In certmgr, right-click the client certificate, select All Tasks > Manage Private Keys....

   2. Add read permission to "NETWORK SERVICE".

      Figure 2: Adding read permission to "NETWORK SERVICE"

7. To forward security logs:

   1. In CompMgmt.msc, under Local Users and Groups, click Groups > Event Log Readers to open Event Log Readers Properties.

   2. Add the "NETWORK SERVICE" account to the Event Log Readers group.

      Figure 3: Adding the "Network Service" account to the Event Log Readers group.

   3. Reboot the client computer.

8. Run the following commands from an elevated privilege command prompt:

   winrm qc -q
   winrm set winrm/config/client/auth @{Certificate="true"}
   

9. Open gpedit.msc.

10. Under the Computer Configuration node, expand the Administrative Templates node, then expand the Windows Components node, and then select the Event Forwarding node.

11. Select the SubscriptionManagers setting and enable it. Click the Show button to add a subscription (use the CA thumbprint you saved earlier):

    Server=https://:5986/wsman/SubscriptionManager/WEC,Refresh=,IssuerCA=

    For example:

    Server=HTTPS://wec.balabit:5986/wsman/SubscriptionManager/WEC,Refresh=60,IssuerCA=A814E609311FD3A89FFD0297974524E4F2D2BA9D
    

    Figure 4: Adding the subscription in SubscriptionManagers

    NOTE: If you wish to set up multiple subscriptions because you want to forward Windows events to multiple event collectors (such as WEC), then you can do that here.

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating

Which tool do you use to configure event forwarding?

How do you set up forwarding events?

What is source initiated subscription?

Which two types of service accounts must you use to set up event subscriptions?