Forums: SplunkAdministration: Snare Syslog Windows Clients

(Originally posted in the wrong section)

New to Splunk...

I'm in a pure Windows environment using Snare agents to forward events to my Splunk v4.0.9 Server which is not part of the domain (segregated). I'm successfully getting logs/events to the server but the only Windows host it sees (based on the Windows App which I'm really interested in using) is the Splunk server itself.

I've followed all of the guides I can find that detail setting up a data input for Snare agents, and they are getting events to me, but what do I need to do for the Windows App to see them as valid data inputs?

Agent info:
Snare Agent 3.1.6
Using UDP 6161
Syslog Headers Enabled

Thanks in advance.

I should add that I am not interested in pulling logs/anything via WMI. The only traffic allowed between the production network and the Splunk enclave is UDP6161. I'm willing to make adjustments as necessary, but not full WMI connectivity.

The Windows app is written somewhat specifically to pull information from the Splunk WinEventLog:* sourcetypes, not snare-syslog, and the field names are the ones that are used by the Splunk WinEventLog collector unfortunately. It would take a slight rewriting of each of the searches behind the Windows app to make it work with Snare data. Structurally, the searches would be the same, but the names of the sources, sourcetypes will be different. It's certainly possible to set up the field names in Snare data to match the ones that the Splunk Collector uses.

The Splunk Snare app unfortunately has not been updated in a while, so I'm not sure if it is set up this way.

I am currently in the process of doing this very thing. I am logging Snare syslog data to an rsyslog server, and using rsyslog templates to clean up the format of the logs. I have set up Splunk to index the log files that rsyslog writes.

gkanapathy is correct. This is requiring a lot of tweaking and some reverse engineering of the Windows app to have the data indexed in a useful way. My starting point was having rsyslog log into different directories by server, then based on data in the syslogtag property, I had it split the logs into the appropriate log files.

This is what I ended up with:

...current/windows/server1/application.log
...current/windows/server1/security.log
...current/windows/server1/system.log
...current/windows/server2/application.log
...current/windows/server2/security.log
...current/windows/server2/system.log

I was then able to monitor those with Splunk , obtaining host from the segment on path. I added this to $SPLUNK_HOME/etc/apps/windows/local/props.conf:

[source::.../current/windows/*/security.log]
sourcetype = WinEventLog:Security

[source::.../current/windows/*/system.log]
sourcetype = WinEventLog:System

[source::.../current/windows/*/application.log]
sourcetype = WinEventLog:Application

I should mention that I have other provisions for "special" log files for DNS, AD, etc. I have not included them here, though, for simplicity's sake. A catch-all "other.log" could be used as well, and might not be a bad idea.

Anyway, from there I am having to ensure that fields are detected appropriately for the Windows app( gkanapathy touched on this as well). This is the biggest challenge, IMO, and one that I am unable to work one due to other rsylog work that takes precedence for me.

This is a lot of work, but I think it's definitely possible, and I know the payoff for Windows logs indexed by splunk (windows app or not) is high. My old rsyslog/Splunk 3.x server was set up in a similar manner and it was wonderful.

[Revised on Wed, 31 Mar 2010 13:09:30 -0700]

Edit: I should also warn you that if you do try out rsyslog, be forewarned that its configuration file syntax is extremely picky, and the documentation for different versions is not split like, say splunk documentation. It can be frustrating to work with, but the incredibly powerful templates system makes it well worth it for me.

[Revised on Wed, 31 Mar 2010 13:34:05 -0700]

Edit number 2: The windows app consistently uses stuff like [source::WinEventLog...]. If, instead, it used [sourcetype::WinEventLog...], I think this would be much simpler to do. As it is, I am having to modify everything to use the second method. Maybe I am going about this the wrong way, I don't know.

Hey JPriceIt, did you get anywhere with this? I'm interested in helping if you're willing to share your changes.