Quantcast
Channel: Splunk Blogs
Viewing all articles
Browse latest Browse all 2319

Forwarding Windows Event Logs to another host

$
0
0

Let’s face it – sometimes, it just isn’t possible to install the Universal Forwarder on all hosts.  Mistrust of new software, proof of concepts and security concerns all play into the decision to install a Universal Forwarder or not.  What do you do when you can’t install a Universal Forwarder?  In this article, we will discuss how to configure a Microsoft Windows host to forward the Windows Event Logs somewhere else.

Throughout this article, we will refer to the “source” when we mean the system that is generating the logs in the first place, and we will refer to the “collector” when we mean the system where you are centralizing the logs.

Step 1: Configure WinRM

Your first step will be to configure remote management, and most especially remote windows event log management on the systems.  On each source and the collector, you will want to type the following at an elevated PowerShell command prompt:

winrm quickconfig
$computer = (Get-WmiObject win32_computersystem).Name.ToUpper()
$collector = 'DOMAIN/COLLECTOR$'
$adsi = [ADSI]"WinNT://$computer/administrators,group"
$adsi.add("WinNT://$collector,group)

Make sure you replace DOMAIN and COLLECTOR with appropriate values for your environment.  Also:

  • If you are using Windows Firewall, then add a Windows Firewall exception for Remote Event Log Management on each source computer
  • Create a domain account (let’s call it “DOMAIN\LogAdmin” and add it to the Event Log Readers group on each source computer.

Configuring the collector is similar:

wecutil qc
winrm set winrm/config/client @{TrustedHosts="SOURCE"}

This last line adds the source to the list of systems that is allowed to use NTLM authentication to communicate with the collector via WinRM.

Step 2: Create an Event Subscription

Our second step is to create the subscription to transfer the logs from the source to the collector.  On the collector:

  1. Run Event Viewer as an Administrator
  2. Click Subscriptions in the console tree
  3. On the Actions menu, click “Create Subscription”
  4. Fill in the Subscription Name and Description with appropriate values
  5. In the Destination Log box, select the log file where collected events are stored.
  6. Click Add and select the source
  7. Click Select Events to display the Query Filter – specify which events are to be collected
  8. Click OK

Normally, the Destination Log will be “ForwardedEvents”, but you can create new ones or just munge all the logs together.  My recommendation is to create a new log for each channel.  For instance, if your source is “SOURCE” and you are collecting the Security events, then create a log “SOURCE-Security”.  You can then use the Universal Forwarder inputs.conf settings to read that log and set the sourcetype and host to the appropriate thing to ensure your apps don’t see any difference.

Step 3: Advanced Settings

You probably saw the Advanced button.  This is actually fairly important.  There are two things you can do.  The first is to configure event delivery optimization.  With “Normal” optimization, the collector uses a pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes.  When using “Minimize Bandwidth” optimization, a push delivery and a delivery timeout of 6 hours is used.  The final option is “Minimize Latency” – it also uses push and a batch timeout of 30 seconds.  Select the appropriate setting for the particular scenario.

The other element you can configure is the user and password.  We created a domain user called LogAdmin earlier – you can enter the credentials here to deal with that, and it is a recommended setting.

Step 4: Install a Universal Forwarder

You can now install a Windows Universal Forwarder on the collector.  If you have followed the instructions here, then you have created a new log file for the events from the source and you can see those events flowing in by utilizing the Event Viewer on the collector.  Now it’s time to configure the Universal Forwarder.  Use the following inputs.conf entry:

[WinEventLog://SOURCE-Security]
sourcetype = WinEventLog:Security
host = SOURCE
disabled = false

Push this to the Universal Forwarder and restart the service.  You should see the events from your source computer appearing in the appropriate Splunk instance.

If you have thrown all of your Security logs into the Security log, then you need to do some post-processing on the indexer to ensure that the host field is set properly.  Start with the following props.conf entry:

[WinEventLog:Security]
TRANSFORMS-sethost = Set-Host-By-ComputerName

then, in transforms.conf:

[Set-Host-By-ComputerName]
REGEX = (?m)ComputerName=(.*?)\n
FORMAT = host::$1
DEST_KEY = MetaData:Host

A Final Note

The features that the Universal Forwarder provides – secure and timely delivery of logs – should not be under-emphasized here.  The Universal Forwarder is the best method of collecting Windows Event Logs for delivery to Splunk, and best practice is to install a Universal Forwarder on each host.  You do not save any bandwidth, CPU or memory by setting up log forwarding – quite the opposite is true.  You will use more bandwidth when using log forwarding and my own experiments show more CPU and memory for log forwarding as well.  However, this mechanism is still better than using WMI to collect logs (which stores the logs in a different format).

This isn’t the last word on this subject either.  There are quite a few methods of forwarding logs, including HTTPS transport for secure delivery and custom configuration of the push/pull subscription model.   Those subjects are left as future research.


Viewing all articles
Browse latest Browse all 2319

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>